I guess the next big tech preview at this year’s VMworld was around Virtual Volumes. Yes, we’ve done this before, but this year there were so many vendors showing demos of their VVol implementation, and so many presentations/sessions on the topic that I believe folks are beginning to realize that we are very close indeed to finally having this feature ready. It’s hard to believe that this was first discussed at VMworld 2011, and I alluded to this when I presented a VVol session that I co-delivered with the folks from Nimble Storage at this year’s VMworld.
This topic is going to be huge, and it is going to change the way storage is designed for virtualization environments. And I think almost every storage partner I spoke to at the show is on-board. In fact, “The Register” asked the question last month if there was ANY storage vendor that wasn’t doing a VVol implementation?
I’m not going to get into any technical details of Virtual Volumes in this post – there will be lots of time for this later. Instead, I’m going to share how we believe VVols will now enable Software Defined Storage (SDS) for SAN & NAS arrays, similar to how we have achieved this already with VSAN.
In this next test of vSphere Data Protection (VDP) interoperability, I wanted to see if a restored vCenter Server appliance would still be able to work with pre-configured vCloud Suite products such as vCenter Operations (vCops), vCloud Automation Center (vCAC), vSphere Orchestrator VCO and Network Virtualization (NSX). All of these products were running to some extent in my environment; vCAC had a simple blueprint for VM deployment, VCO had a simple workflow for renaming a VM and NSX included an Edge device providing a DHCP service. If all of this functionality was still in place post restore, then the backup and restore will have worked. Testing was done with vCenter Server appliance version 5.5U1 and VDP version 220.127.116.11.
In this third article in the series of backing up the vCloud Suite, we turn our attentions to NSX, VMware’s Network Virtualization product. Before starting, I should point out that NSX has a recommended way of backing up and restoring configuration information via the use of an FTP server, which you need to configure in your infrastructure to hold this exported metadata. However this exercise looks at how you might be able to use VDP to back up and restore an NSX configuration using image level backups. Once again, I wanted to see whether I could restore the NSX environment to a particular point in time, in-place and also by restoring to a new location. This is the same infrastructure that I used for backing up and restoring vCops and backing up and restoring vCAC and VCO. On this occasion, I was using NSX version 6.0.4, vCenter 5.5U1 and VDP version 18.104.22.168.
This post is a follow on to a previous post I did on vCops and VDP interop. In this scenario, I am going to try to use vSphere Data Protection (VDP), which is VMware’s Backup/Restore product, to back up and restore a vCloud Automation Center (vCAC) v6.0.1. and vCenter Orchestration (VCO) v5.5 deployment.
In this particular scenario, there are nine virtual machines making up my vCAC and VCO deployment. VCO has been deployed in a HA configuration, which accounts for two VMs. The others make up the DEM, Manager, Web, vCAC, SSO and various databases for vCloud Automation Center.
I just recently received my credentials to VMware’s vCloud Hybrid Services. One of the first things I was interested in testing out was the Disaster Recovery Service, which uses VMware’s vSphere Replication technology to protect VMs in your on-premise DC to vCHS. The following post provides the steps to configure the replication target as your vCHS VDC (virtual data center), and then configuring replication on a VM.
Although I didn’t attend EMC World this year, there were a lot of interesting announcements. I managed to catch up with Matt Cowger (who sorts of sits between both the EMC & VMware camps) and ran through some of the main highlights from this year’s conference. There has been a lot written about EMC World already (and I mean a lot) so I’m going to try to keep the highlights to a minimum, and provide links to where you can read more.
Another feature which was introduced in vSphere 5.1 & vCloud Director 5.1 was the interoperability between vCloud Director & Storage DRS. Now vCloud Director can use datastore clusters for the placements of vCloud vApps, and allow Storage DRS do what it does best – choose the best datastore in the datastore cluster for the initial placement of the vApp, and then load balance the capacity and performance of the datastores through the use of Storage vMotion.