During your day-to-day management of a vCloud Director infrastructure, there may come a time where you need to add additional datastores to an organization to consume. This is typically driven by an exhaustion of the currently connected storage by vApps and templates. Or, you may have acquired a new storage array and wish to migrate the vApps over as part of your cut-over plan. So, how does one balance the storage consumption across a variety of datastores inside of the same Storage Profile, especially without the use of a datastore cluster?
The simple answer is to kick off a Storage vMotion from the vSphere environment just like you normally would. I was a little surprised to see this listed as a supported method for relocating vApps, as the VMware Horizon View product actually has a “rebalance” task to seek out a level storage consumption – this is quite handy. But don’t just take my word for it:
For validation, check out section 5.4.7 of the vCloud Architecture Toolkit (vCAT) entitled “Relocate Existing vApps” for a list of steps. This is an awesome resource that requires you to register the first time you sign in, and provides a great amount of architectural thought leadership around vCloud by some sharp folks at VMware.
Rebalance Example Workflow
In this example, I have a vApp with a single VM named CloudyApp in my Developers Org virtual data center. I’d like to migrate it to another datastore.
To begin with, make sure that the destination datastore for the vApp is defined by the storage profile that is given to the organization virtual data center – for example, don’t migrate the vApp to storage that the Org vDC has no authority to use, or storage that is only presented to hosts that are not defined by the Provider vDC that the Org is consuming. In the screenshot below, I’ve identified two storage profiles that have been mapped to the Developers Org vDC, and will have to make sure any vApp I move will land in one of those two.
I tend to prefer using the VMs view inside of the vSphere Web Client to find the vApp folder, locate the VMs inside, and do the migration. You can also get properties on the vApp in the Org to see exactly what the full name of the vApp is (with the long GUID strings). Below is a photo of the properties on the CloudyApp VM within my lab – towards the bottom is the exact name in vSphere (highlighted in yellow). Also note that the CloudyApp currently lives on a datastore called Tier0-SSD, which lives inside the storage profile called Tier0-Disk.
I can now go into the vSphere web client and find the VM object so that I can kick off a storage migration. Note that each time you try to initiate a migration you will be warned that the vApp is being managed by vCloud Director and warned not to do anything dangerous.
Once the storage migration is completed the location of the VM datastore will update to reflect the new home. In this case, my CloudApp has moved from Tier0-SSD to Tier0-SSD1 and shows the new home (highlighted in yellow). Keep in mind that the VM has not changed Storage Profiles (it’s still in the Tier0-Disk profile) but has migrated across datastores.
Thoughts
It would be really snazzy if there was a button or built-in workflow natively found within vCloud Director to balance the vApp storage usage within a Storage Profile without having to potentially leverage a datastore cluster set to automatically watch capacity usage. Perhaps in the future?
