Re: [libvirt] [RFC PATCH 1/n] snapshot: add revert-and-create branching of external snapshots

On 11/09/2012 12:47 PM, Eric Blake wrote: > Right now, libvirt refuses to revert to the state at the time > of an external snapshot, because doing so would reset things so > that the next time the domain boots, we are using the backing > file; but modifying the backing file invalidates all qcow2 > files that are based on top of it. There are three possibilities > for lifting this restriction: > 1. delete all snapshot metadata and qcow2 files that are > invalidated by the revert (losing changes since the snapshot) > 2. perform a block commit (such as with qemu-img commit) to > merge the qcow2 file back into the backing file (keeping the > changes since the snapshot) > 3. create NEW qcow2 files that wrap the same base file as > the original snapshot (keeping the changes since the original > snapshot) > > This patch documents the API for option 3, by adding a new flag > to virDomainSnapshotCreateXML (the only snapshot-related function > that takes XML, which is required to pass in new file names > during the branch), and wires up virsh to expose it. Later > patches will enhance virDomainRevertToSnapshot to cover options > 1 and 2. > > API wise, an application wishing to do the revert-and-create > operation must add a <branch>name</branch> element to their > <domainsnapshot> XML, and pass VIR_DOMAIN_SNAPSHOT_CREATE_BRANCH > in the flags argument. In virsh, snapshot-create gains a new > boolean flag --branch that must match the XML passed in, and > snapshot-create-as gains a new --branch=name argument along > with a --current boolean for creating such XML. Sorry, I don't quite understand well the revert-and-create operation for a new branch. For example there is a snapshot chain like baseimage->snap1->snap2->snap3 If we plan to go back to snap1, it will become as follows, is it right? baseimage-->snap1-->snap2-->snap3 \ snap1.1(new branch) If snap1.1 is a new snapshot taken of snap1, is it a live external disk snapshot or offline external disk snapshot?

And if user wants to revert back to snap1, and finally he got snap1.1(), it doesn't look good. I am wondering whether we can ensure the snap1.1 is totally a replicate of snap1.

Guannan -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list