vCloud Director 5.1 & Storage DRS

Posted on October 19, 2012 by Cormac — 15 Comments ↓

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.

However, what about Fast Provisioned vCloud vApps which are based on link clones? Well yes, this is also supported. Storage DRS now understands how to handle linked clones objects which it didn’t do previously.

Shadow VMs

To begin with, let’s talk a little about Fast Provisioned vCloud vApps and shadow VMs. If a fast provisioned vCloud vApp is deployed from the catalog to a different datastore, a shadow VM of the vApp is instantiated from the catalog on the datastore. A shadow VM is an exact copy of the base disk. The fast provisioned vCloud vApp (which is effectively a linked clone) then references the local shadow VM on the same datastore; it does not reference the version of the vApp in the catalog. There is a great KB article here which discusses Fast Provisioned vCloud vApps in more detail.

However, I haven’t seen much documentation in the way of Storage DRS & vCloud Director 5.1 interoperability. Therefore I decided to investigate some of the behaviour on my own environment. My setup had the Fast Provisioned option enabled for my ORG-VDC:

In this example, I imported a VM from vSphere into my catalog on a Storage DRS datastore cluster. I am using this catalog entry to fast provision (fp) vCloud vApps. I next deployed a vApp from my catalog, but changed the Storage profile so that a new, fully automated Storage DRS datastore cluster becomes the destination. I observed the clone virtual machine task running, and the shadow VM folder being created on one of the datastores in the datastore cluster. When the operation completed, I saw the shadow VM and the fp vCloud vApp deployed to that datastore in the datastore cluster:

I made some subsequent deployments of that fp vCloud vApps to this datastore cluster to see if other shadow VMs are instantiated automatically on other datastores. Note that fp vCloud vApps to the same datastore in the datastore cluster will not need a new shadow VM; they simply reference the existing shadow VM as their base disk. My second fp vCloud vApp went to the same datastore. This is expected as there would be some overhead and space consumption to instantiate another shadow VM. The next 4 fp vCloud vApps also went to the same datastore. At that point I decided to go to the Storage DRS Management view and Run Storage DRS Now. At that point a number of Storage vMotion operations executed and my fp vCloud vApps were balanced across all the datastores in the datastore cluster. One assumes that this would have eventually happened automatically since Storage DRS does need a little time to gather enough information to determine correct balancing of the datastore cluster.

Storage DRS Migration Decisions

In the case of fast provisioned vCloud vApps, Storage DRS initial placement recommendations will not recommend an initial placement to a datastore which does not contain the base disk or shadow VM, nor will Storage DRS make a recommendation to migrate fast provisioned vCloud vApps to a datastore which does not contain the base disk or a shadow VM copy of the base disk. Preference is always going to be given to datastores in the datastore cluster which already contain either the base disk or shadow VMs as observed in my testing.

However, if Storage DRS capacity or latency thresholds are close to being exceeded on some datastores in the datastore cluster, new shadow VMs can be instantiated on other datastores in the datastore cluster by Storage DRS. This allows additional fp vCloud vApps to be initially placed or migrated to this datastore. This is also what I observed during testing. When I clicked on Run Storage DRS Now, I noticed new shadow VMs get instantiated on other datastores in the datastore cluster. Now fp vCloud vApps (based on linked clones) can be placed on any datastore in the datastore cluster.

If there is a cross–datastore linked clone configuration (created via APIs for example) and the linked clone vCloud vApp references a base disk on a different datastore, you may find that Storage DRS will not surface recommendations for this vApp. In fact, such configurations should be avoided if you want to use Storage DRS with vCloud Director.

So what about migration decisions? The choice of migrating a VM depends on several factors such as:

The amount of data being moved
The amount of space reduction in the source datastore
The amount of additional space on the destination datastore.

For linked clones, these depend on whether or not the destination datastore has a copy of a base disk or if a shadow VM must be instantiated. The new model in Storage DRS takes the link clone sharing into account when calculating the effects of potential moves.

On initial placement, putting the linked clone on a datastore without the base disk or shadown VM is more costly (uses more space) than placing the clone on a datastore where the base disk or shadow VM resides.

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

vCloud Director 5.1 & Storage Profiles

Posted on October 17, 2012 by Cormac — 12 Comments ↓

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

Posted on October 4, 2012 by Cormac — 6 Comments ↓

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.

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:

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):

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:

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

vSphere 5.1 Storage Enhancements – Part 9: Storage DRS

Posted on September 18, 2012 by Cormac — 5 Comments ↓

This post will look at Storage DRS enhancements in vSphere 5.1.

vCloud Directory Interoperability

In part 3 of this series on vSphere 5.1, I covered the storage enhancements to vCloud Director. One of the improvements in vSphere 5.1 for vCloud Director was Storage DRS interoperability. vCloud Director will use Storage DRS for the initial placement of vApps during Fast Provisioning vCloud Director will also use Storage DRS for the ongoing management of space utilization and I/O load balancing of the datastores in the Storage DRS datastore cluster. This is a great feature to have included with vCD, as it will offload many of the manual storage management tasks which an administrator has to carry out right now.

Datastore Correlation Detector

Datastore correlation refers to the fact that two distinct datastores could be using the same set of disk spindles at the back-end.

The ability to detect datastore correlation is already in Storage DRS but requires VASA to work. (VASA is short for vSphere Storage APIs for Storage Awareness). The purpose of the datastore correlation feature is to help the decision-making process in Storage DRS when deciding where to move a VM. For instance, there is little advantage moving a VM from one datastore to another if both datastores are backed by the same set of physical spindles on the array. This enhancement to the Datastore Correlation Detector now uses the Storage I/O Control I/O injector to determine if a source and destination datastore are correlated, i.e. using the same back-end spindles. It basically works by monitoring load on one datastore and monitoring the latency on another. If we see latency increases on both datastores when load placed on one datastore, we can assume the datastores are correlated. This decision is made after monitoring the behaviour over a period of time.

The Datastore Correlation Detector can also be used for Anti-Affinity rules, making sure that VMs & VMDKs are not only kept on separate datastores but are also kept on different spindles on the back-end.

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

vSphere 5.1 Storage Enhancements – Part 3: vCloud Director

Posted on September 6, 2012 by Cormac — 16 Comments ↓

In this post, I want to highlight a number of storage improvements made in vSphere 5.1 that are going to be leveraged by the next release of vCloud Director.

Scalability

First off, we have the new file sharing scalability enhancements made in VMFS-5, which now allows up to 32 hosts to share a single file. This is covered in detail in part 1 of this vSphere 5.1 storage enhancements series of blog posts, but what this does mean for vCloud Director is that vApps deployed on linked-clones can now have many more hosts sharing the base disk on a VMFS-5.

VAAI NAS Offload

Sphere 5.0 introduced the offloading of linked clones for VMware View to native snapshots on the array via NAS VAAI primitives. You can read more about this here. vSphere 5.1 NAS VAAI enhancements will allow array based snapshots to be used for vCloud Director vApps based on linked clones, in addition to being used for VMware View.

When VMware vCloud Director does a fast provision of a vApp/VM, it will transparently use VAAI NAS to offload the creation of the subsequent linked clones to VAAI supported arrays.

Just like VAAI NAS support for VMware View in vSphere 5.0, this feature will also require a special VAAI NAS plug-in from the storage array vendor.

At the time of writing this article, NetApp already have this feature included in their next VSC release (4.1) which is currently in beta.

If “Fast Provisioning” is used on the Org vDC Storage settings AND the check box “Enable VAAI for fast provisioning” on the overall system Datastore settings is selected, it will trigger the right commands to use a native array-based snapshot for a linked clone instead of a standard redo log based one.

Profile Driven Storage Interoperability with vCloud Director

Storage Profiles are now represented in vCloud Director. Storage Profiles still must be configured from the vSphere layer, but they now surface up into vCloud Director. The storage profiles must first be added to a Provide vDC. For example, you might have Gold, Silver & Bronze storage profiles created. This then allows storage to be allocated and managed on a per ORG vDC. Again, continuing our example, this organization can only use datastores which are tagged as ‘Silver’. This support for Storage Profiles allows a high level of seperation between organizations at the storage level. Below is a snapshot of an ORG vDC with two storage profiles, one for iSCSI storage and one for NFS storage.

If the Storage Profile associated with a vApp is changed (this can be done via the properties of a vApp), the vApp is automatically Storage vMotion’ed to a compliant datastore. It is great to see vCloud Director leveraging this excellent vSphere feature.

Storage DRS Interoperability with vCloud Director

One of the major enhancements in vSphere 5.1 is to provide interoperability between Storage DRS and vCloud Director. This essentially means that vCloud Director 5.1 now recognises datastore cluster objects from Storage DRS. Just like Storage Profiles, the configuration of Storage DRS is done at the vSphere layer, but the resulting datastore clusters and their respective configuration surface up into vCloud Director. In order for this interoperability to work, Storage DRS now understands linked clones (which it didn’t do previously). Going forward, vCloud Director can now use Storage DRS for initial placement, space utilization and I/O load balancing of vApps based on linked clones.

Snapshots

The last feature introduced in vSphere 5.1 & vCloud Director 5.1 is the ability to take Virtual Machine snapshots from within vCloud Director. Previously one had to take these snapshots at the vSphere layer. As per the screen shot on the left, you can now Create, Remove and Revert a snapshot via the vCloud Director UI.

Although this might be considered a minor improvement, it does alleviate some additional administration which was necessary in previous versions of vSphere/vCloud Director.

I guess the next question then is how do you tell if you have a snapshot on the VM?

By default this information is not displayed on the Virtual Machine view. To show this information, select the option to display the Column headings which is on the right of the screen. Place a tick in the Snapshot column. You will now have a column denoting whether or not there is a snapshot for the Virtual Machine as per the diagram below,

It is nice to see these vSphere storage features being leveraged by vCloud Director. It’s especially nice to see some of the interoperability between products and features.

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