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

Re: [libvirt] RFCv2: virDomainSnapshotCreateXML enhancements

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.


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

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