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

Peter Krempa pkrempa at redhat.com
Wed Nov 14 11:06:23 UTC 2012


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.

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

It can't be a total duplicate of that one. The disk images have to be 
different otherwise this whole exercise wouldn't make sense.

>
>         Guannan
>
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list




More information about the libvir-list mailing list