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