[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 07/12/2011 09:17 AM, Matthias Bolte wrote:
Here's the preliminary patch.



  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

snapshot=yes persistent=no probably does not make sense for any hypervisor (if you are going to throw away the disk changes at next boot, then creating a snapshot would make the data persistent after all). More specifically, both the ESX and QEMU implementations of a non-persistent disk (create a wrapper .vdsk or qcow2 file with the original file as backing, and throw away the wrapper when the domain quits running) would imply turning the temporary file into the backing file of yet another image, but as soon as the temporary file is deleted, that other image is rendered broken.

  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.



  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.

If we argue that only three modes make sense (1. ESX "persistent" - participates in snapshots and changes survive boots; 2. ESX "independent-persistent" - changes survive boots but does not participate in snapshots; 3. ESX "independent-nonpersistent" - changes are thrown away at boot), then maybe this is better rendered as a single attribute:

<disk persistence='snapshot|independent|none'>

Or can someone make the case that independence and persistence are orthogonal, and that there ever would be a use case for a disk that participates in snapshots but gets reverted at next boot?

--
Eric Blake   eblake redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]