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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list