Did you know that when you create a VM from a template in XenServer, it actually generates a FAST CLONE of the disk?  What’s the big deal?  This could have a storage impact because this process will generate a linked VHD clone disk. This means that the VM created from a template will have its disk linked to the template’s disk. If you have an operational process that creates VMs from templates, over time this could create a long linkage tree!

Impact

When this is done excessively, performance could degrade.  Here is one example of a real life situation where this could occur and become problematic:

When deploying a LARGE XenDesktop environment:

  • Most likely there would be many different vLANs and as a result there would be one template per vLAN.  It’s common to have one vLAN to spread out the DHCP traffic and avoid a DHCP storm.  In this case, you would most likely want a different template for each virtual network (as the virtual network would be the different).
  • The process for creating these additional templates could utilize a manual process:
    1. “create VM from a template + convert to new template” method.  Each iteration of this would introduce an additional generation of linked VHDs.
    2. The XDSW, as input, takes a template.  When you generate a large number of VMs using the XDSW (assuming PVS is in use and each VM has a “write cache disk”), all of the disks for these VMs would be linked clones of the template’s disk. This process introduces an additional generation of linked VHDs.

Spread this out across many different iterations of templates and the lifecycle of a XenDesktop site, and you could end up with a complicated linkage tree. After speaking with Product Management, long chains of VHDs clones can in fact cause performance degradation. XenServer has a built-in limitation of 30 linked clones to avoid this issue (from the XenServer Administrators guide):

When cloning VMs based on a single VHD template, each child VM forms a chain where new changes are written to the new VM, and old blocks are directly read from the parent template. If the new VM was converted into a further template and more VMs cloned, then the resulting chain will result in degraded performance. XenServer supports a maximum chain length of 30, but it is generally not recommended that you approach this limit without good reason. If in doubt, you can always “copy” the VM using XenServer or the vm-copy command, which resets the chain length back to zero.

Mitigation

As the Admin guide snipit indicates, when excessive linking could be a concern, use the full copy method. To create a new template that is based on an existing template, perform the following for new templates: right click template -> copy -> full copy:

screenshot of creating a template copy using "full copy" option

screenshot of creating a template copy using "full copy" option

 

Useful tools

A good way to determine if you have an excessive tree of cloned VHDs is using the vhd-util scan command:

# vhd-util scan -f -m “VHD-*” -l VG_XenStorage-<UUID_of_StorageRepository> -p

This will list all of the VHDs in your Storage Repository.  The “-p” switch is awesome because it will display the disks in a hierarchical structure:

From this output you can see which disks are fast clones of others.  The hidden column tells us which disks will be displayed in XenCenter when you look at the disks in a Storage Repository.

For kicks, you can use the xe vbd-list command to map the disks back to VMs:

#xe vbd-list vdi-uuid=<UUID_of_disk>

The UUID of the disk is what is displayed in the output from vhd-util scan.