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