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

computernews at rambler.ru computernews at rambler.ru
Tue Jul 12 15:29:02 UTC 2011


Thanks for your time. I needed this really feature badly.
Looking forward to test the final version.

Best regards
Oleh Paliy

> 2011/7/12 computernews at rambler.ru <mailto:computernews at rambler.ru> 
> <computernews at rambler.ru <mailto: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 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.
>     --
>     libvir-list mailing list
>     libvir-list at redhat.com <mailto: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/233116e0/attachment-0001.htm>

More information about the libvir-list mailing list