There are many different design options available when deploying vCloud Director, which makes it both flexible and confusing at the same time. One topic I wanted to touch on is configuring storage for an Organization with Fast Provisioning enabled. In setting up an environment for software development the provisioning speed and repetitive build requirements made fast provisioning a must. While testing multiple setups some issues arose with each setup but one was a clear winner.
More background on system/process requirements:
– 1 Organization
– 1 Org. Virtual Datacenter with Fast Provisioning & Thing Provisioning enabled
– VCD 5.1.1
– vCenter 5.1.0 (shared with other non-VCD clusters)
– 4 ESXi 5.1 Hosts
– 4 datastores on same array
– 2 vApp Templates – each are chain length 1 and on different datastores.
– PowerCLI script used to deploy 15 vApps from each vApp Template
One main concept to remember is automated continuous improvement builds/software tests are running multiple times each day based off of these parent templates. Some builds get captured back to catalogs for a couple days when done and others are deleted right away. The goal is to balance storage usage and performance with time to deploy as well as eliminating as much infrastructure administration as possible.
Setup #1 – *(Any) storage profile, no storage cluster. This is the “out-of-box” setup and works well if you only have one compute cluster and all hosts use all datastores.
Pros: When importing or creating vApps VCD places VM’s on datastores as it sees fit and does a pretty good job. Fast-provisioned vApps use the same datastore as the parent VMDK by default and will create shadow-copies when running out of space.
Cons: When this isn’t the only cluster within your vCenter VCD will see and monitor all other datastores, even ones not seen by the cluster in use (including ESXi local datastores). It will send alerts on datastore usage thresholds for them as well.
Setup #2 – Two storage profiles, one storage cluster per profile. The thought was to separate storage clusters and profiles to specific hosts within cluster and only license part of the cluster for MS Datacenter 2012, in turn saving lots of MS licensing costs.
Pros: Storage DRS does a great job of load balancing VM placement upon creation. It also is VERY handy when evacuating a datastore. Multiple storage profiles allows you to place VM’s within a vApp on different datastores. This helps reduce software costs as you could place Windows VM’s on one set of hosts and Linux VM’s on another set so you don’t have to buy MS Datacenter licenses for all hosts within the cluster.
Cons: All VM’s get deployed to the DEFAULT storage profile within the Organization, no matter which storage profile the parent is on. A shadow-copy VM is created for this to happen, which takes much longer than the standard linked-clone does. Also, with storage clusters a parent VM gets a shadow-copy to all datastores in the cluster as it gets used more often. This is due to the placement algorithm of SDRS. This is great for non linked-clone VM’s but defeats the purpose of the Fast Provisioning feature. We tried to script this but had issues and a lot of VCD UI users wouldn’t know how to follow this properly.
VM disk layout for this setup is just like that of setup #3 below. You can see screenshots from VMware lctree fling of this below.
Setup #3 – One storage profile, one storage cluster.
Pros: Same as setup #2 but all datastores are presented to all hosts and in the same storage cluster.
Cons: As time goes by a Shadow VM is created on every datastore within the cluster (other than the datastore where the parent resides) for each vApp Template.
Here are the datastore layouts after 15 copies of the vApp Template based on the first datastore are created. Notice the Shadow VM’s on datastore 02 and 03.
After creating 15 copies of the vApp Template on datastore 02 you now have Shadow VM’s for it on datastore 01 and 03.
Looking at the vApp Templates within the Catalogs view it lists 2 Shadow VM’s for each vApp Template.
Setup #4 – One storage profile, no storage cluster.
Pros: When importing or creating vApps VCD places VM’s on datastores as it sees fit and does a pretty good job. Fast-provisioned vApps use the same datastore as the parent VMDK by default and will create shadow-copies when running out of space.
Cons: Can’t use SDRS or change the Storage Profile of a VM to evacuate a datastore.
This is the desired layout once 15 vApps are deployed from each vApp Template.
The last setup seems to work best for this environment. Within Lab Manager I would put the Library entry on multiple datastores, check all datastores to see which one has the most free space and use the corresponding entry for that build. With setup #4 VCD will take care of this issue for me on new build process. I can still run out of space with Fast-Provisioning though if I don’t have alerts setup.
If you have any questions about this please ask them below. Again, this setup is way different based on needs than most VCD environments are.
vEric: 
Leave a Reply