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

[Guannan Ren]

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