Whenever you create a VM from a template in XenServer, it actually generates a FAST CLONE of the disk.
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!
Limitations:
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 snippet 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 as shown below;
# 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.
# vhd-util scan -f -m “VHD-*” -l VG_XenStorage-<UUID_of_StorageRepository> -p | grep parent=VHD
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!
Limitations:
- When this is done excessively, performance could degrade.
- Also if the link breaks anywhere, then all the VMs under the Linkage tree will lose its data.
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 snippet 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 as shown below;
Useful Commands
Command 1:
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.
Command 2:
You can also use this command to determine the VDIs that is dependent on parent VHD.# vhd-util scan -f -m “VHD-*” -l VG_XenStorage-<UUID_of_StorageRepository> -p | grep parent=VHD
No comments:
Post a Comment