32
VHD-based VDIs
VHD files may be chained, allowing two VDIs to share common data. In cases where a VHD-backed VM is
cloned, the resulting VMs share the common on-disk data at the time of cloning. Each proceeds to make its
own changes in an isolated copy-on-write (CoW) version of the VDI. This feature allows VHD-based VMs
to be quickly cloned from templates, facilitating very fast provisioning and deployment of new VMs.
The VHD format used by LVM-based and File-based SR types in XenServer uses sparse provisioning. The
image file is automatically extended in 2MB chunks as the VM writes data into the disk. For File-based VHD,
this has the considerable benefit that VM image files take up only as much space on the physical storage
as required. With LVM-based VHD the underlying logical volume container must be sized to the virtual size
of the VDI, however unused space on the underlying CoW instance disk is reclaimed when a snapshot or
clone occurs. The difference between the two behaviors can be characterized in the following way:
• For LVM-based VHDs, the difference disk nodes within the chain consume only as much data as has
been written to disk but the leaf nodes (VDI clones) remain fully inflated to the virtual size of the disk.
Snapshot leaf nodes (VDI snapshots) remain deflated when not in use and can be attached Read-only
to preserve the deflated allocation. Snapshot nodes that are attached Read-Write will be fully inflated on
attach, and deflated on detach.
• For file-based VHDs, all nodes consume only as much data as has been written, and the leaf node files
grow to accommodate data as it is actively written. If a 100GB VDI is allocated for a new VM and an OS
is installed, the VDI file will physically be only the size of the OS data that has been written to the disk,
plus some minor metadata overhead.
When cloning VMs based off 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 0.

VHD Chain Coalescing

VHD images support chaining, which is the process whereby information shared between one or more VDIs
is not duplicated. This leads to a situation where trees of chained VDIs are created over time as VMs and
their associated VDIs get cloned. When one of the VDIs in a chain is deleted, XenServer rationalizes the
other VDIs in the chain to remove unnecessary VDIs.
This coalescing process runs asynchronously. The amount of disk space reclaimed and the time taken to
perform the process depends on the size of the VDI and the amount of shared data. Only one coalescing
process will ever be active for an SR. This process thread runs on the SR master host.
If you have critical VMs running on the master server of the pool and experience occasional slow IO due
to this process, you can take steps to mitigate against this:
• Migrate the VM to a host other than the SR master
• Set the disk IO priority to a higher level, and adjust the scheduler. See the section called “Virtual disk
QoS settings” for more information.

Space Utilization

Space utilization is always reported based on the current allocation of the SR, and may not reflect the
amount of virtual disk space allocated. The reporting of space for LVM-based SRs versus File-based SRs
will also differ given that File-based VHD supports full thin provisioning, while the underlying volume of an
LVM-based VHD will be fully inflated to support potential growth for writeable leaf nodes. Space utilization