By: Chris Colotti, Consulting Architect, VMware Global Center of Excellence
This is a repost from Chris' personal blog, ChrisColotti.us.
A while back I was messing around with Fast Provisioning in vCloud Director and I noticed something I wanted to dig a little deeper into. My Co-Worker Cormac Hogan (@VMwarestorage) also wrote a little about this as well which does a great job showing the linked clone aspect. Also William Lam (@lamw) wrote up some nice scripts to find the linked chains. However, it took me up until now to get my home lab back into a clean state to test things a little differently specifically with how these interact with the vCloud Director Catalogs. The premise of what I am looking at is a very simple setup, but could change some operational ideas about how and when you enable Fast Provisioning, which is a great, and handy thing to have in test and development environment. However, you need to understand a little about how they work before you check the box to enable them.
There is a couple of things you need to know first about vCloud Director Fast Provisioning.
- It is Enabled on a PER organization vDC level so it is either on or off.
- ONLY System Administrators can consolidate Fast Provisioned virtual machines, Organization Administrators cannot
- Once disabled existing machines will remain fast provisioned
The real key that I wanted to look at here was deploying items back and forth from the catalog with the feature enabled. So what I setup was pretty basic.
- Master Organization with a published catalog and Fast Provisioning DISABLED
- Customer organization with local catalogs and Fast Provisioning ENABLED
- Both Organization vDC’s are Pay-As-You-Go for reference
- The template is CentOS 6.2 minimal exported/imported from vCenter.
The rest of this post will be various operations in certain orders to see what happens with and without fast provisioning enabled on a consumer organization.
The Shadow Virtual Machine
In some cases, in order for fast provisioning to work it will use the concept of a Shadow VM on each datastore where a linked clone will live, but in many cases it may not get created for some time. This VMware KB has a lot of good information, and a couple of key points taken from it are as follows:
- The source template virtual machines are called primary virtual machines
- Shadow virtual machines are created on demand
- Subsequent copies to the same datastore are fast
- Org Admin/User only sees the ‘source’ virtual machine. Shadow virtual machines are an implementation detail that are only visible to vCloud Director administrators.
- Shadow virtual machines stored in System vDC
- Shadow virtual machines disk space billed to the service provider
Shadow virtual Machines are only created once a clone needs to be placed on a storage volume different from where the original one is located. Until that needs to happen everything else is done on the same storage.
Initial vApp Template Import Into the Catalogs
The first thing I wanted to see was taking an OVF, and importing to each catalog to see what happens. Obviously on the Master organization the catalog item will be imported as a thick copy, but I was not 100% sure on the Fast Provisioned vDC. Interestingly, From what I saw both vApp templates were brought in as full copies into the catalog by the initial import from OVF.
However I actually tested COPYING the vApp template from the Master Catalog to the Org’s local catalog. In this case the copy was actually a linked clone. It created the initial snapshot and then made the local Org’s catalog version a linked clone to the original just as if it was deployed to the cloud itself. I found this interesting as it leads me to something we will discuss later about updating and re-adding items to the catalog.
The Use Case
What we see is a pretty common use case for why I am testing this. It has also been asked how does someone deal with patching and updates once these catalog’s are linked together. The consumer wants to deploy the Guest Operating System from the provider’s published catalog, customize it, and save a copy to their local organization catalog. The consumer’s organization is enabled for Fast Provisioning, but they may want to ensure their local catalog chain does not link back to the master catalog.
Deploying from vCloud Director Shared and Local Catalogs
Where this gets really interesting is on the deployment of each version of the vApp Catalog item. Now we are going to only work off the Master Shared Catalog since that’s what most people would do. The first time a deploy operation of a vApp Template to a Fast Provisioned vDC is requested, the original virtual machine is put into snapshot mode. This means the actual virtual machine that is the catalog vApp in the master organization is now in snapshot mode indefinitely. If there happens to be a Shadow VM required, that would be created, then a snapshot taken. At this point forward anything deployed from that catalog virtual machine will be deployed from the base snapshot.
Now that we have a deployed vApp as a linked clone, we can update it, patch it, add new applications to it, whatever we want to treat it like a normal virtual machine. Let’s say we want to save this to our LOCAL catalog at this point. When we make that copy to the local catalog, we will get a full copy however there is a catch. The full copy appears to be a full copy of the deployed virtual machine’s Delta Disk as you can see in the info below. As we can see below the VMDK is still pointing back to the original catalog base disk.
Let’s take this one step further, and now deploy a vApp from this new local catalog virtual machine. What we see here is that the newly deployed virtual machine from the local catalog is also linked back to the original master VMDK. This means that as this consumer edits, saves, and re-deploys they are always saving Delta files and referencing back to the original disk.
Master Catalog VM (Orange)
First Consumer VM (Green):
Consumer Local Catalog VM (Green):
Consumer Re-Deployed Catalog VM (Purple):
Something to Consider – Break The Chain
Based on now knowing how some of this works, you want to decide how you to handle fast provisioned Org vDC’s since once they are enabled you can see how everything from that point on will be based on linked clones. Something many providers and consumer organizations alike may want to do is break the link chain of their local catalog so they are always deploying from a full copy within their local organization catalog.
This can in fact be done with a few steps. Remember in the beginning when I stated that only a System Administrator can consolidate? That comes into play here, as once a vApp is checked into the local catalog a system admin OR something with system administrator credentials, like vCenter Orchestrator or other scripting method, can consolidate the virtual machines in the consumer’s local catalogs. Below you can see the vCloud Director interface option on the virtual machine in the consumer’s catalog. Using a service to do this for you would certainly be a better way to go.
This will break the chain so that only the deployed virtual machines will have a link to the local catalog VMDK only instead of back to the master catalog’s VMDK. This would isolate the local consumer’s deployed virtual machines and catalog chains from the Master Catalog. However, this process will still exist anytime a virtual machine is deployed for updates then placed back into the catalog in the fashion described above. The advantage to this is that the consumer’s can all deploy in this fashion and in THeory the provider can have nothing linked to their original templates allowing them to patch them and replace them as they need:
- Start with the provided templates
- Customize them
- Add them to their catalog
- Consolidate to break the chain
- Remove the linked customized vApp
To accomplish this of course you need some custom intervention and have your consumer’s deploying via custom tools that interface with things like vCenter Orchestrator. Either way it can be done such that the original virtual machines have no links to them and the consumer’s all have the links to their own local copies. Figuring out all the hooks to leverage the API’s to make this happen…..well….that’s for you to figure out.
It should be noted that vCloud Director is smart enough to know that if you delete the item from the catalog and there are virtual machines linked to it, the base disks will remain on storage. They will not be removed from storage until all linked VMDK’s are eventually removed. So you can deploy, patch, and remove a catalog virtual machine from vCloud Director, and the linked ones will still function.
Chris is a Consulting Architect with the VMware vCloud Delivery Services team with over 10 years of experience working with IT hardware and software solutions. He holds a Bachelor of Science Degree in Information Systems from the Daniel Webster College. Prior to VMware he served a Fortune 1000 company in southern NH as a Systems Architect/Administrator, architecting VMware solutions to support new application deployments. At VMware, in the roles of a Consultant and now Consulting Architect, Chris has guided partners as well as customers in establishing a VMware practice and consulted on multiple customer projects ranging from datacenter migrations to long-term residency architecture support. Currently, Chris is working on the newest VMware vCloud solutions and architectures for enterprise-wide private cloud deployments.