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