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

[Eric Blake]

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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org