[libvirt] RFCv2: virDomainSnapshotCreateXML enhancements

[Eric Blake]

On 08/10/2011 04:08 PM, Eric Blake wrote:

I'm not sure I covered this well earlier, but another useful definition is:

"current snapshot" - if this exists, it is the snapshot that would 
become the parent if a new snapshot were created; or put another way, it 
is the snapshot to which our current running delta is based on.  It is a 
bit confusing that libvirt picked this naming, since a a "current 
snapshot" does not contain the same VM state as what is currently 
running; a better name might be "active snapshot", except we can't 
rename existing libvirt API that calls it current.

> Migration
> +++++++++
>
> The simplest solution to the fact that snapshot metadata is host-local
> is to make migration attempts fail if a domain has any associated
> snapshots. For a first cut patch, that is probably what I'll go with -
> it reduces libvirt functionality, but instantly plugs all the bugs that
> you can currently trigger by migrating a domain with snapshots.
>
> But we can do better. Right now, there is no way to inject the metadata
> associated with an already-existing snapshot, whether that snapshot is
> internal or external, and deleting internal snapshots always deletes the
> data as well as the metadata. But I already documented that external
> snapshots will keep both the new file and it's read-only original, in
> most cases, which means the data is preserved even when the snapshot is
> deleted. With a couple new flags, we can have
> virDomainSnapshotDelete(snap, VIR_DOMAIN_SNAPSHOT_DELETE_METADATA_ONLY)
> which removes libvirt's metadata, but still leaves all the data of the
> snapshot present (visible to qemu-img snapshot -l or via multiple file
> names); as well as virDomainSnapshotCreateXML(dom, xml,
> VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE), which says to add libvirt snapshot
> metadata corresponding to existing snapshots without doing anything to
> the current guest (no 'savevm' or 'snapshot_blkdev', although it may
> still make sense to do some sanity checks to see that the metadata being
> defined actually corresponds to an existing snapshot in 'qemu-img
> snapshot -l' or that an external snapshot file exists and has the
> correct backing file to the original name).

On thinking a bit more, creating a snapshot metadata by _CREATE_REDEFINE 
should never mark that snapshot as "current" (there is no way to tell if 
the currently running qemu descended from the just-created metadata with 
no other snapshot in between), unless the just-defined metadata claims 
that its parent is the same as the domain's current snapshot.  But in 
the case of migrating snapshot metadata, the destination starts with no 
snapshots, and therefore no current snapshot, and therefore no way to 
mark any particular migrated metadata as current.  So while the approach 
of redefining snapshots on the destination to match those on the source 
allows you to recreate the entire snapshot hierarchy, the source might 
have a current snapshot but the destination will not.

However, while I already documented that the migration cookie is not 
large enough to send an arbitrary number of snapshot metadata files, it 
_is_ large enough to send a single name of which snapshot should be 
treated as the "current" snapshot of the just-migrated domain.

I'm reluctant about encoding the name of the "current" snapshot directly 
in domain xml (that is not an aspect of the domain, but of the snapshot 
hierarchy, and creating or deleting snapshots should not require 
rewriting the domain xml except in the case where disk-snapshots change 
the active file to be a new qcow2 wrapper), not to mention that 
<domainsnapshot> will now embed an entire <domain>, so any reference to 
a current snapshot in <domain> could get into nasty circular nesting 
issues.  But I think my plan of using the non-public <active> xml tag in 
the libvirt private-use directory to track which snapshot is current on 
the source [1], coupled with sending a current snapshot name as part of 
the migration cookie, is sufficient to do migration of snapshot 
hierarchies including the notion of the current snapshot, all without 
having to alter the <domain> xml.

[1] https://www.redhat.com/archives/libvir-list/2011-August/msg00337.html

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