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

Tue Jul 12 15:17:48 UTC 2011

2011/7/12 computernews at rambler.ru <computernews at rambler.ru>

> **
> Hello,
>
> So what I see from the discussion is that I have to reimplement my patch
> one way or another (attribute / sub-element). So I am eager to do that as
> soon as the choice is made (unless you decide otherwise and want someone
> else to implement that).
>

Oh, I already went ahead and implemented a first version of this (3 days
ago) while thinking about how this could integrate with Eric's
checkpointing, but didn't post it yet. It's a bit incomplete and lacks
documentation, support for the legacy modes is incomplete and test coverage
is incomplete.

Here's the preliminary patch.

> Now that you have explained the bigger picture with more details (other
> hypervisors but the ESX)  let me summarize an upcoming changes into a
> specification:
>   Value in .vmx file
>  representation in <domain> XML" as attributes
>  representation in <domain> XML" as sub-items Description
>   scsi0:0.mode = "persistent" <disk ... snapshot='yes' persistent='yes'>
>
>  Default. Snapshots are in use, changes survive power cycles
>   scsi0:0.mode = "independent-persistent" <disk ... snapshot='no'
> persistent='yes'> <independent/> No snapshot logic is applicable, changes
> remain
>   scsi0:0.mode = "independent-nonpersistent" <disk ... snapshot='no'
> persistent='no'> <independent/> <nonpersistent/> No snapshots, changes
> lost after domain power cycles
>   scsi0:0.mode = "undoable" <disk ... snapshot='no' persistent='yes'>
> <independent/> for backwards compatibility  scsi0:0.mode = "nonpersistent" <disk
> ... snapshot='no' persistent='no'> <independent/> <nonpersistent/> for
> backwards compatibility
> Also the reverse conversion has to be implemented (<domain> XML -> vmx
> file).
>
> Obviously the appropriate <domain> XML format description changes has to be
> made here: http://libvirt.org/formatdomain.html#elementsDisks. I can do
> that as well.
>
> Best regards
> Oleh Paliy
>
>
>
>  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 alsohttps://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.
>
>
>
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>

-- 
Matthias Bolte
http://photron.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110712/02caf8bb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-vmx-Add-snapshot-preset-and-persistent-options-for-d.patch
Type: text/x-patch
Size: 23277 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20110712/02caf8bb/attachment-0001.bin>