Re: [libvirt] Disk snapshot mode proposal: patch for storing the snapshot mode from .vmx to .xml

On 07/09/2011 09:52 AM, Matthias Bolte wrote: > Anyway, you decided to add an snapshot_mode attribute to the disk > element and exposed the VMX values there. I'm not sure that this is a > good idea as scsi0:0.mode affects two aspects. > > scsi0:0.mode can basically have three different modes > > - persistent, the default, a disk with this mode will take part in > snapshots and changes to the disk's content persist domain power > cycles and snapshot restoring. > > - independent-persistent, a disk with this mode will not take part in > snapshots, but changes to the disk's content persist domain power > cycles and snapshot restoring. > > - independent-nonpersistent, a disk with this mode will be not take > part in snapshots and changes to the disk's content don't persist > domain power cycles and snapshot restoring. This is realized by > writing all changes into an additional .vmdk instead of the original > .vmdk. This additional .vmdk is automatically deleted on domain power > cycles and snapshot restoring. > > There are two additional but outdated modes undoable and nonpersistent > that aren't supported anymore. > > So the two aspects scsi0:0.mode affects is snapshot and the > persistence of changes. I think it makes more sense to use two > attributes for the disk element to expose this. > > <disk ... snapshot='yes|no' persistent='yes|no'> > > - snapshot=yes persistent=yes maps to scsi0:0.mode=persistent > > - snapshot=yes persistent=no is unsupported for ESX > > - snapshot=no persistent=yes maps to scsi0:0.mode=independent-persistent > > - snapshot=no persistent=no maps to scsi0:0.mode=independent-nonpersistent Hmm, this indeed seems like it might be reasonable to represent both aspects in XML. See also https://www.redhat.com/archives/libvir-list/2011-May/msg00315.html. At stake is whether a disk has a snapshot taken by default, and whether a disk is treated as temporary for the life of the domain (qemu has a -snapshot command line option that treats all disks as temporary, but with better per-volume snapshot abilities, libvirt could certainly offer the same fine-tuning of per-disk as esx appears to offer). So yes, I'll need to fold something like this into my v2 proposal for snapshot handling. > The more important question is: Is this an general concept or is it > too ESX specific? It's sounding generic enough that it will be worth getting it right in the XML. > Eric is currently discussing/designing an extension to libvirt's > snapshot/checkpoint capabilities. At the moment libvirt supports > checkpointing a complete domain including RAM image and all storage > volumes, but it doesn't support snapshotting of single storage volumes > or a subset of the storage volumes of a domain. > > https://www.redhat.com/archives/libvir-list/2011-June/msg00761.html > > Eric suggest to extend the<domainsnapshot> and virStorageVol* APIs to > allow to include only a subset of the domain's storage volumes in a > checkpoint. This approach allows to specifiy for each checkpoint which > storage volumes to include. ESX allows something similar with the > independent modes, but you cannot define this on a per snapshot basis, > but have to decided this before. Eric's approach is more flexible but > doesn't work for ESX. I wonder if we could add the snapshot > attribute/subelement to the disk element. This allows to set the > independent mode for ESX and allows to define a preset for other > hypervisors like QEMU that will support Eric's more flexible approach. > > So when you don't explicitly define which disk to include in a > checkpoint in the<domainsnapshot> XML then the snapshot setting from > the the<domain> XML apply. If there are no presets for snapshot it > defaults to yes. For QEMU you could override the snapshot setting from > the<domain> XML in the<domainsnapshot> XML, for ESX you either don't > specify this in the<domainsnapshot> XML or have to match the settings > from the<domain> XML due to the way ESX works. Yes, having a per-disk default in the<domain> XML (applicable to both qemu and ESX), as well as a per-disk override in the<domainsnapshot> (here, qemu can take advantage, but ESX would have to fail if the override is not identical to the domain defaults). does make sense. > The persistence setting might be more ESX specific, but I think > libvirt could realize this for QEMU too, when the domain is using > qcow2 images with a base image. In that case libvirt could clear the > qcow2 image when the domain is restarted to realize persistent=no. I > might be incorrect here as I'm not the QEMU expert here. You're exactly right - qemu can implement per-disk persistent=no by doing a qcow2 wrapper around just the disks that should be reverted when the VM stops running. There might be some interactions with migration to worry about, though. > On a second thought we might want to use negative word so we don't add > subelements for the defaults, for example > > <disk type='file' device='disk'> > <source file='[datastore] test1/test1.vmdk'/> > <target dev='sda' bus='scsi'/> > <independent/> > <nonpersistent/> > <address type='drive' controller='0' bus='0' unit='0'/> > </disk> Now we're doing a bit of bike-shedding - I think there's definitely consensus that this has to be in the XML somewhere, but whether as an attribute or as a sub-element still remains to be decided.