[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/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.

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

Attachment: signature.asc
Description: OpenPGP digital signature


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