vCloud Director - Moving vApps Between Clusters In the Same PvDC

 I had a request from a customer of mine to be able to move there vApps and VM's between vSphere clusters in the same vCD Provider Virtual datacenter.  The customers first thoughts were to drop down into the vCenter and then just do a normal vMotion, however they get the standard message detailing that this object is managed by vCD.

This should have made the customer think that maybe doing it this way was not the best idea, But they progressed and migrated the VM anyway.  Once they had done this.  It broke the relationship with vCD and the VM became unmanageable in vCD.

Now if this was a simple migrate a VM/vApp between clusters using the same storage we could go to System>Manage And Monitor> Resource Pools and select the VM from source cluster and the select "Migrate" to move the VM to the destination cluster. 

Now the customer I was working with has been using VBLOCK's in there datacenter to build there vCloud environment.  This is brilliant as the VBLOCK is a very impressive bit of kit and after working with them for a number of months I am very happy with recommending them to customers.  But using a VBLOCK did present us with a challenge.

The customer was using a single provider virtual datacenter in vCD.  This was backed by several clusters each cluster corresponded to a single VBLOCK.  The Clusters were 24-32 hosts.  Each VBLOCK has its own VNX SAN and the storage from this is only presented to the hosts in the same VBLOCK.  There is no storage shred between the VBLOCKs, and thus between the clusters.  

So if we have no shared storage between the clusters backing the Provider Virtual Datacenter. How do we move VMs between the clusters.  The answer is using Storage vMotion! Hang On Storage vMotion is not a selectable option in vCD.

After thinking a little more I decided we could select the VMs storage profile and change this.  This should instruct the VM to conduct a joint "Change Host and Change datastore" migration.

In the example below I have my vApp built on a cluster called "Site1".  This cluster has a corresponding storage profile.  The storage for this profile is only mounted on the hosts in the cluster "Site1"

Now the vApp and the VM must be completely shutdown.  If the vApp is showing a status of "Partially Running" then this operation will fail.  The same applies for if the VM is not shutdown.  You will see an error message of "Invalid Parameter" 

Select a host profile that is linked to another cluster in the Provider Virtual Datacenter.  In my lab this is "Site2" and select OK.

Now the VM will show as being "Busy" while the Storage vMotion Is conducted in the background.  If you drop to the vSphere Client you will see more information. The vSphere client will show the VM as being relocated.

 

Once the Storage vMotion has completed you will see the VM in vCD show as normal and examining the vSphere client will show the VM as being moved to another cluster.

This resolved my customers problem, and we integrated this into a rather cool vCO workflow that could be kicked off from the customers Cisco based cloud portal.  The workflow I may detail in another post but it basically looked at the VMs inside a vApp and then changed there storage profile to relocate them based on the input from the user.

My customer then requested that this activity of moving between the clusters was conducted with no downtime.  The ONLY way this is possible is to use a SWING datastore.  This is a datastore that is presented to all the hosts in the Provider.  This breaks a number of VCE design constraints and would result in having to have a datastore equal to the size of the largest VM.  In my customers case this is 8TB.  So this 8TB is going to be sitting there doing nothing most of the time, as a VCE design constraint is not to share storage between VBLOCK's let alone run workloads on it.

I am working to resolve this at the moment but I am not sure I will find a resolution. We are constrained by the CBT technology used in Storage vMotion and the design constraints of VCE.