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

Guannan Ren gren at redhat.com
Wed Nov 14 11:33:13 UTC 2012

On 11/14/2012 07:06 PM, Peter Krempa wrote:
> On 11/14/12 10:29, Guannan Ren wrote:
>> 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?
> That depends on what snap1 was originally. snap1.1 at the point of 
> creation snap1 and snap1.1 will be identical, but they will eventually 
> diverge when the machine is booted up in either of the branches.

       Get it, but how to make the snapshot of snap1.1 that will be 
identical with snap1 if snap1 is live external disk snapshot originally.
       If we boot up the machine using snap1, then do the snapshot, the 
snap1.1 will be not totally identical as least I think.

More information about the libvir-list mailing list