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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
