This article is 2nd part of the series.
Part 1: Introduction
Part 2: Individual Datastores
Part 3: Datastore Clusters
In this scenario we are presenting to vCloud Director individual datastores, not datastore clusters. New datastores were provisioned with the same Storage Capability and to the same hosts as the old ones which we want to evacuate and subsequently remove both from vCloud Director and vSphere.
1. Disable the old datastores in vCloud Director (System > Manage and Monitor > vSphere Resources > Datastores & Datastore Clusters).
2a. To relocate a VM its storage profile needs to be updated. Even if the storage profile remains the same when it is updated vCloud Director will verify that current VM location complies with given storage profile. If it is on disabled datastore it will move it to a different datastore of the same storage profile. This can be accomplished either from GUI or with vCloud API.
a. GUI – deployed VM: Open VM Properties, scroll down, change the Storage Profile to another and then back again. This will activate the OK button. Obviously we need at least two Storage Profile assigned to the Org VDC.
b. GUI – VM in catalog: The process is almost the same. Open the VM properties in the catalog and assign the default storage profile and click OK button.
c. GUI – Expired VM: For expired regular or catalog VM it is not possible to update storage profile from within the GUI.
d. API: The process for regular, catalog or expired VMs is identical. Retrieve the Vm element with GET request and then update the Vm with PUT request with identical body. http://pubs.vmware.com/vcd-51/topic/com.vmware.vcloud.api.doc_51/GUID-E56EEEEA-EDED-4EBC-8095-08AD2668F0D2.html
2b. As an alternative to the relocation initiated from vCloud Director we could accomplish the same with Storage vMotion at the vSphere layer. However there are same caveats:
- Make sure that the new datastores have the correct Storage Capability and are assigned to the same hosts. There is no vCloud Director placement engine verification!
- As stated in the Part 1 this is not recommended for Fast Provisioned VMs as they will be inflated to full clones
- As stated in Part 1 this is not possible for VAAI Fast Provisioned VM as vSphere cannot storage vMotion them
- You will need to manually load balance the VMs based on their size and available disk space of the new datastores
3. Other objects that can be stored on datastore we need to evacuate are vCloud Director catalog media (ISO and FLP files). These files are stored in special directory with following name structure: <VCD Instance Name>/media/<org ID>/<org VDC ID>/media-<media ID>.<ISO|FLP>.
a. GUI: In the catalog find the media object, right click and select Move to catalog. Pick the same VDC it resides in currently and select storage profile: Same As Source. Note: you will see vCenter Copy task right away; the deletion of the source media does not happen immediately upon the file copy completion, but can take a few minutes as it is asynchronous cleanup operation.
b. API: The process is identical to the Storage Profile update of a VM. Retrieve the Media element with GET request and update it with PUT request with identical body.
There is no other way to move media files. Manual file transfer will make the media unavailable to vCloud Director as it references the target datastore in its database.
4. Last vCloud Director objects stored on to be evacuated datastore might be vShield Edges. The current (VCD 5.1.2) behavior is that Edge can be deployed to any datastore of the Provider VDC the Org VDC resides in. This is not very intuitive. On top of that it can end up even on disabled datastore, which is a bug and is going to be fixed in the next bug fix release. This means that redeploy from vCloud Director does not help. We need to either Storage vMotion it from vSphere to the new datastore or redeploy it from vShield Manager while specifying the datastore placement for the Edge appliance.
The Part 3 of the series will discuss if usage of Datastore Clusters and Storage DRS might simplify the process.
Go to part 3.