vCloud Director 5.1 & Storage Profiles

In my 10 part series of posts on the new vSphere 5.1 Storage Features, I called out in part 3 that there was now even greater interoperability between features like Profile Driven Storage and vCloud Director. The purpose of this blog is to highlight this particular interoperability in even more detail.

Let’s take it from the top – in my vSphere environment, I built out two datastore clusters, each with 3 datastores. Each datastore in its respective datastore cluster has the same storage capability associated with it. This is the only way storage profiles will work with datastore clusters – all datastores in the datastore cluster must have the same capability. CloudDatastoreCluster datastores has the User-defined Storage Capability called Cloud-Store; DatastoreClusterT2 datastores has the User-defined Storage Capability called Cloud-Store-T2.

My next step in the vSphere client is two create two separate VM Storage Profiles, each profile containing one of the capabilities.

That completes the setup from the vSphere side of things. Lets now see how this integrates with vCloud Director. The datastore clusters and storage profiles now show up as vSphere resources in the vCloud Director System > Home view:

When I create my ProviderVDC, I can now include the datastore clusters (we’ll look at Storage DRS integration with vCloud Director at a later date) and the Storage Profiles.

The same is true now for your ORG-VDC; datastores and profiles can now be included at the ORG level. Be sure you assign a reasonable quota to your ORG-VDC or you might bump into this issue. Now when it comes to deploying vApps from the catalog, selecting the appropriate profile will provision the vApp on the datastore or datastore cluster which matches the capabilities defined in the profile.

This vApp, win7x64-vApp was deployed with the Cloud-Store-T2 profile selected, which mean that the VM was deployed on a datastore with a matching capability – vCloud-DS6. That in itself is a great feature to have – you no longer need to worry about the specific underlying capabilities of the datastore, you simply select the correct profile and it determines that for you. Some simplified profile naming will make the provisioning of vApps from vCloud Director error free each and every time.

What is even better however is the ability to change the VM’s profile in its properties view. In this example, I change the storage profile from Cloud-Store-T2 to Cloud-Store-Profile (the other profile we defined earlier), & now the VM is automatically migrated to a new datastore with this matching capability:

In the Virtual MAchine’s status window in vCloud Director, we see a status change to Updating. In the vSphere Task Console, we can see a Relocate virtual machine task underway. So all we did was change the profile associated with the VM, and a migration operation is automatically initiated to move the VM to a compatible datastore. This is ideal for situations where an organization may start on a lower tier of storage, but after a while realise that they may need a higher tier (or indeed vice-versa). The administrator simply changes the profile, and the VMs are seamlessly migrated to the new storage tier.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage

The requested operation will exceed the VDC’s storage quota

vSphere 5.1 introduced a number of vCloud Director (vCD) interoperability features from a storage perspective, namely ability to take VM snapshots from within the vCD UI, interoperability with Storage Profiles and interoperability with Storage DRS. Admittedly, its been a while since I played with vCD and I am a little rusty, but I wanted to see how well these storage features worked with vCD 5.1. I’ll follow-up with some future posts on how this all integrates, but this first post is just to highlight an issue I ran into in my haste to get the environment up and running.

The Storage DRS and associated datastore cluster, along with Storage Profiles all showed up just fine when building my Provider VDC. These must be created in vSphere in advance however – they cannot be setup from vCD. I then rolled out my ORG VDC and uploaded a virtual machine from my vSphere environment to use in my vApp. The vApp deployed just fine on the datastore cluster – so far, so good. To continue my Storage DRS & Storage Profile testing, I decided to put this vApp into a catalog so that other ORGs could use it. That when I hit this error.

The requested operation will exceed the VDC's storage quota

Now, vCD aficionados will probably recognise this immediately, but this error threw me initially. I thought first that maybe my datastore cluster didn’t have enough space for the vApp & catalog entry. So I checked my datastore cluster & it had plenty of space:

Datastore Cluster

I then went back to check if there was some sort of limit on my storage allocation. And yes, there was. I found it in the ORG-VDC Administration section in the Storage Profiles tab (click on the screen-shot to enlarge it if it is difficult to read):

Storage Profiles in vCloud Director

In my haste to roll out my environment, I guess I missed the point where a storage limit is set. A quick edit of the Storage Profile associated with the ORG-VDC let me change the Storage Limit on the fly – I bumped it up to 120GB:

ORGVDC Storage Profile Limit

This now allowed me to successfully add the imported vApp to my catalog for sharing with other ORGs.

I’ll follow-up with some additional posts which will look at vCloud Director 5.1 and the new integration features (VM Snapshots, Storage DRS, Storage Profiles) in more detail. Nice to see some integration between some of these products and features.

My colleague Tom Stephens (@vCloud_Storm) has a detailed whitepaper highlighting the new vCD 5.1 features if you’d like to check it out.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage