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.
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:
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.
- 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 shadow 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: @CormacJHogan