Datastore Migrations in vCloud Director – Part 3 of 3: Datastore Clusters

This article is the last in the series.

Part 1: Introduction
Part 2: Individual Datastores
Part 3: Datastore Clusters

In this scenario we are exposing to vCloud Director only datastore clusters. vCloud Director cannot disable individual datastores, on the other hand we could leverage SDRS Maintenance Mode. We can also break the cluster and remove the old datastore from it and basically be in the Scenario 1 but there is no fun in that.

To leverage SDRS Maintenance Mode we need to add the new datastores to the Datastore Cluster (beware of limit of maximum of 32 datastores per cluster). Note: it is not possible to mix NFS and block based datastores. Obviously Storage DRS must be enabled (manual mode is enough).

1. When we put the old datastore to SDRS Maintenance Mode following will happen: vCloud Director will not deploy any new VMs or store media on it.

2. Storage DRS will either automatically or will wait for confirmation (if in manual mode) migrate all VMs away from the datastore. As of vSphere 5.1 this also supports linked clones (vCloud Director Fast Provisioning). Meaning that it will not inflate a linked clone, instead it will try to first migrate the link clone to a datastore with shadow VM (copy of the base image). If there is none, it will first copy the base image and then create linked clone. This has some limitation though. If we are migrating VM2 and VM3 which are linked clones of VM1 at the same time we will have two times full clone of VM1 and then from each linked clone VM2 and VM3 respectively. Therefore I would advise to limit number of concurrent Storage vMotion operations per datastore – see here.

All regular VMs, catalog VMs, expired VMs and vShield Edges will be migrated.

Note: If VAAI accelerated Fast Provisioning is used (hardware snapshots) this will not work!!! As mentioned in Part 1 vSphere 5.1 does not support vMotion of hardware clones.

3. Catalog media files will not be migrated as they are not vSphere objects. Here we need to use the same procedure as mentioned in the Scenario 1, step 3.

In my opinion there is strong case for using Datastore Clusters with vCloud Director to simplify vCloud storage management. The important consideration is on which level we want to do the management – vSphere of vCloud? Depending on the internal politics and separation of duties this might be the decisive factor.

3 thoughts on “Datastore Migrations in vCloud Director – Part 3 of 3: Datastore Clusters

  1. Hi Tom, when chaning storage profile for a VM to a new storage profile which has different storage capability, it generates alerts complaining about Virtual Machine r is NOT_COMPLIANT against Storage Profile xxx. But the SDRS finishes successfully and the VM runs on the new storage profile without any issues. Do you think the alerts can be ignored?
    -George

  2. Hi Tom, in the StorageCluster method, how do you handle the “shadow-VMs” where SDRS are turned off by vCD? I’m not shure that i should overwrite SDRS policy to “fully automated” for this particular VMs…

    1. You cannot move shadow-VM and it should not be moved. Once it is created it stays on the datastore for any possible linked clone deployments. You can delete shadow VM from VCD GUI, if there are clones linked to it the files will stays on the datastore until the clones are removed/migrated.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.