Thank you very much for your reply!! I will follow your suggestions.

 

Regards,

 

Simone Cariani

 

 

 

Da: Dave Scott [mailto:[email protected]] 
Inviato: lunedì 15 novembre 2010 11.55
A: 'Simone Cariani'; [email protected];
[email protected]
Oggetto: RE: [Xen-API] problem with snapshot unallocation

 

Hi Simone,

 

Whenever you create a snapshot disk it will increase the length of the
“snapshot chain” by 1 and there is a hard length limit of 30. However
whenever you delete a snapshot disk the background “coalesce” process should
be able to reduce the “snapshot chain” length again. So your procedure
(create snapshot; export snapshot; delete snapshot) ought to work fine. This
is in fact the same process followed by the “VM protection and recovery”
feature which will be part of XCP 1.0.

 

The problem you linked to is related but not quite the same: it refers to a
limitation within the “coalesce” process where it cannot reduce a chain of
length 2 into a chain of length 1. The only reason people worry about this
is because a chain of length 2 can take up a lot more space on LVM where
there is no “thin provisioning” – this isn’t a problem for you on NFS.

 

Given your observation that this only happens to VMs with more than 1
attached virtual disk, I think you’ve found a bug in the tool which you used
to add the second disk to the VM. When you delete a VM snapshot (or
uninstall a VM or template generally), only those disks which have a special
flag set are actually deleted (specifically those with
VBD.other-config:owner IIRC). If you use the “xe vm-disk-add” CLI command it
should set this flag. If this flag isn’t set then it would cause the
additional disks not to be deleted… this would cause your “snapshot chain”
to get ever bigger, hit 30 and then fail.

 

I think a workaround is to identify the disk (VDI not VM) snapshots which
haven’t been deleted and delete them manually, possibly via the CLI (“xe
vdi-destroy”). After a short while the background “coalesce” process should
kick in and reduce your chain lengths again.

 

Cheers,

Dave

 

_______________________________________________
xen-api mailing list
[email protected]
http://lists.xensource.com/mailman/listinfo/xen-api

Reply via email to