Site icon Chris Colotti's Blog

[INFO] vCloud Director Fast Provisioned Catalog Virtual Machines

Chris Colotti

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.

  1. It is Enabled on a PER organization vDC level so it is either on or off.
  2. ONLY System Administrators can consolidate Fast Provisioned virtual machines, Organization Administrators cannot
  3. 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.

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:

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 then 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. We can also see this from the ParentHint information that the machine in the local catalog is also linked to the consumer’s deployed virtual machine itself.

 

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 in turn linked to the virtual machine in the catalog. This means that as this consumer edits, saves, and re-deploys they are always creating links from the previous virtual machine.

Below we can see the disk headers for each virtual machine in the various steps. One thing that I want to point out is you will see the “parentFileNameHint” which shows that each disk is linked to a disk in the previous step.

Master Catalog VM (Orange)

# cat CentOSMinimal\ \(ff68332f-8a07-4739-9c75-4d945dbec22b\).vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=a01c48e3
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 33554432 VMFS "CentOSMinimal (ff68332f-8a07-4739-9c75-4d945dbec22b)-flat.vmdk"

First Consumer VM (Green):

# cat CentOSMinimal\ \(14775f16-7089-4a8e-8993-3045bed173e7\).vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=a01c48e3
parentCID=a01c48e3
isNativeSnapshot="no"
createType="vmfsSparse"
parentFileNameHint="/vmfs/volumes/4f316743-5041e641-2229-005056890004/CentOSMinimal (ff68332f-8a07-4739-9c75-4d945dbec22b)/CentOSMinimal (ff68332f-8a07-4739-9c75-4d945dbec22b).vmdk"
# Extent description
RW 33554432 VMFSSPARSE "CentOSMinimal (14775f16-7089-4a8e-8993-3045bed173e7)-delta.vmdk"

Consumer Local Catalog VM (Blue):

# cat CentOSMinimal\ \(f308e901-60b2-406b-88a1-fb3bcc58540a\).vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=a01c48e3
parentCID=a01c48e3
isNativeSnapshot="no"
createType="vmfsSparse"
parentFileNameHint="/vmfs/volumes/4f316743-5041e641-2229-005056890004/CentOSMinimal (14775f16-7089-4a8e-8993-3045bed173e7)/CentOSMinimal (14775f16-7089-4a8e-8993-3045bed173e7).vmdk"
# Extent description
RW 33554432 VMFSSPARSE "CentOSMinimal (f308e901-60b2-406b-88a1-fb3bcc58540a)-delta.vmdk"

Consumer Re-Deployed Catalog VM (Purple):

# cat CentOSMinimal\ \(f5b612e7-512b-4730-aff8-ee9489012ffe\).vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=a01c48e3
parentCID=a01c48e3
isNativeSnapshot="no"
createType="vmfsSparse"
parentFileNameHint="/vmfs/volumes/4f316743-5041e641-2229-005056890004/CentOSMinimal (f308e901-60b2-406b-88a1-fb3bcc58540a)/CentOSMinimal (f308e901-60b2-406b-88a1-fb3bcc58540a).vmdk"
# Extent description
RW 33554432 VMFSSPARSE "CentOSMinimal (f5b612e7-512b-4730-aff8-ee9489012ffe)-delta.vmdk"

So what happens then if the GREEN virtual machine is deleted from the vCloud Director user’s cloud?  That’s a great question, since you would hope that the underlying disk would not be removed.  That is in fact the case.  The underlying disk remains on storage consuming space since there are other machines, namely the one in the catalog that is linked to it.

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 links from the previous virtual machine. 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.

Consolidating the customized vApp (Green) first however, will convert the virtual machines to full copies before you save it to the local Catalog, but the copy in the catalog would still be linked. You want to Consolidate in the catalog after for best results.  The advantage to this is that the consumer’s can all deploy in this fashion and in theory the provider can have very little linked to their original templates allowing them to patch them and replace them as they need:

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.

Remember that vCloud Director is smart enough to know that if you delete the item from the catalog or the user’s cloud if 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.

Exit mobile version