Xenserver snapshot chain is too long error occurs when we reach the maximum number of snapshots that a single VM can have.

As part of our Server Management Service, Bobcares responds to all queries, no matter how small.

Let’s look more closely at how our Support team fixed the issue: The xenserver snapshot chain is too long.

Xenserver snapshot chain is too long

When we reach the maximum number of snapshots that a single VM (or its VDIs) can have with XenServer, we may see an error message similar to the ones listed below (around 30).

• First one is The snapshot chain is too long.
• Then, SR_BACKEND_FAILURE_109
• Finally, Xen reported this VM has too many snapshots

Until some snapshots are deleted, Xen is unable to take new (additional) snapshots of the affected VM. The VM’s snapshot tab in XenCenter is the first place to look for a solution to this problem. Remove any unnecessary snapshots if there are any.

Solutions 1

But frequently, XenCenter displays far too few snapshots to cover the full chain limit (30). The “extra” snapshots in this chain are actually being used by Xen itself, behind the scenes. Usually, XenServer will make an effort to automatically collapse (auto-coalesce) these snapshots, consolidating them down in the background.

Then, Xen will take care of this issue for us if we just wait a little while. It is up to Xen to choose when to try this auto-coalescing process because it can, unfortunately, take some time. It might take a while on systems that are extremely busy.

We can manually run a “leaf coalesce” to get around the automatic process’ arbitrary scheduling. The disadvantage of this manual procedure is that in order to finish its task, it will briefly suspend or pause the target VM. The console of a host in the pool hosting the concerned VM can be used to execute this command.

An example of command line usage

xe host-call-plugin host-uuid=[host uuid] plugin=coalesce-leaf fn=leaf-coalesce args:vm_uuid=[vm uuid]

Finally, the script mentioned above might not work in some situations. This typically indicates either a backend VDI/VHD storage error of some kind or a more complicated snapshot chain heirarchy (involving other VMs or templates). In these situations, performing a full (XVA) export/import of the affected VM through XenCenter is the only practical way to resolve this error.

If we have access to it, we could also use Alike to restore a previous version of the VM. This effectively creates a brand-new VM (complete with a new UUID) and a brand-new snapshot chain.

Solutions 2

Make sure the coalesce process has already been completed. There are numerous ways to verify that everything went smoothly.

1. Firstly, ssh into the XenServer main node and perform the following actions:

   xe sr-list
2. Obtain the UUID for the storage repository containing the VMs that we are working with. After that, use vhd-util to see if any chained VHD files exist.

   vhd-util scan -f -m "VHD-*" -l "VG_XenStorage-${UUID-Of-Your-SR}" -p

   Substitute the SR UUID from the first command for {$UUID-Of-Your-SR}
3. The output will include all VHDs in the SR, and those that have a VHD chain will be displayed as a tree. We can determine whether Xe is still processing the VHDs by seeing if the tree still exists. Simply type: xe task-list to accomplish that.
4. Observe the results as well. If the output was blank, we should check to see if the vhd-utilprocess is active on each server in our pool. If so, the Xe Toolstack should handle it as a problem.

Solutions 3

Another approach to the issue is to make a copy of the problematic VM disc and attempt to start a new VM with it. Since it will be copied, XenServer will scan the VHD chain and produce a single VHD image that contains all of the VHDs as one.

[Looking for a solution to another query? We are just a click away.]

Conclusion

In conclusion, the error happens when we reach the XenServer limit for the number of snapshots that a single VM (or its VDIs) can have. The error: xenserver snapshot chain is too long was fixed by our Support team in a number of different ways.