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@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