I’ve been asked several times in the past as to why it takes so much longer to create or update a pool when the master image has multiple snapshots and since I’m sure I’m going to have to explain it again in the future, I thought writing a blog post would be a good idea so I could point my colleagues or clients to.
Let’s look at the following thin provisioned master image template that has 3 snapshots:
If we were to browse the folder in the datastore containing this virtual machine, you will see that there are 3 vmdk files each with a value for the Size and Provisioned Size columns:
Note the following file sizes for the 3 vmdk files:
- XPProFS-Tmp.vmdk = 17GB
- XPProFS-Tmp-000001.vmdk = 656MB
- XPProFS-Tmp-000002.vmdk = 443MB
- XPProFS-Tmp-000003.vmdk = 508MB
As you probably already suspected, each of the 00000x.vmdk files represent the snapshot containing the changes you’ve made to the original virtual machine.
To fully understand why it takes more time when you have more snapshots, let’s begin by creating a new test pool and browsing into the base disk folder that’s created when the XenDesktop DDC clones the master image into a separate folder so that your desktop catalog virtual desktops can use it as the base operating system disk:
Notice how the base disk created is a single flat file (non thin-provisioned)? This is exactly why it takes longer when you use a master image that has multiple snapshots—the cloning process needs to consolidate all of the snapshots prior to the snapshot you chose to create your desktop catalog. If the snapshot you chose is 3 levels deep, the XenDesktop DDC will combine all of the snapshots and create a thick base image disk:
What’s also worth mentioning, although it’s not related to the additional time required to create the desktop catalog is that the virtual machine metadata files (vmx, vmxf, vmsd) are all created on the same LUN that the master image resides (Desktops-Lun2):
… while the base disk image is created in the LUN that you specified for the virtual machine files (Desktops_XP_Lun5):
Also note the 0.00KB vmx file in the same folder as the base disk folder and how it disappears after cloning is completed:
This isn’t quite the usual problem and solution post that I typically write but I feel that by getting a better understanding of what goes on under the hood, you’ll be able to better troubleshoot issues when they arise. For more information about what files and folders get created during the provisioning process of Citrix XenDesktop catalogs with PvDs, see my previous post here:
Storage consumption when provisioning Citrix XenDesktop 5.6 with personal vDisks (PvD) with MCS (Machine Creation Services)