libvirt users - Jan 2013 - Managing Live Snapshots with Libvirt 1.0.1

Hello,

I recently compiled libvirt 1.0.1 and qemu 1.3.0 on Ubuntu 12.04. I have
performed live snapshots on VMs using "virsh snapshot-create-as" and
then later re-merge the images together using "virsh blockpull". I am
wondering how I can do a couple of other operations on the images while the VM
is running. For example, VM1 is running from the snap3 image, with the following
snapshot history (backing files):

[orig] <-- [snap1] <-- [snap2] <-- [snap3]

1. Can I revert VM1 to use snap2 while it is live, or must it be shutdown? After
shutting it down, is the best way to revert to snap2 to just edit the xml file
and change the block device to point to snap2? Afterwards, I believe snap3 would
become unusable and should be deleted?

2. If I would like to start a new VM from snap1, is there a way to extract a
copy of this snapshot from the chain, to an independent image file? I tried to
use "virsh blockcopy" but it returned this error:
# virsh blockcopy VM1 vda snap1.qcow2 --wait --verbose
error: Requested operation is not valid: domain is not transient


Thanks,

Andrew

On 01/31/2013 04:09 PM, Andrew Martin wrote:
> Hello,
[Can you convince your mailer to wrap long lines?]
> 
> I recently compiled libvirt 1.0.1 and qemu 1.3.0 on Ubuntu 12.04. I have
performed live snapshots on VMs using "virsh snapshot-create-as" and
then later re-merge the images together using "virsh blockpull". I am
wondering how I can do a couple of other operations on the images while the VM
is running. For example, VM1 is running from the snap3 image, with the following
snapshot history (backing files):
> 
> [orig] <-- [snap1] <-- [snap2] <-- [snap3]
Are you using the --disk-only and/or --memspec options when you use
snapshot-create-as?  Or put another way, are your snapshots internal or
external?
> 
> 1. Can I revert VM1 to use snap2 while it is live, or must it be shutdown?
After shutting it down, is the best way to revert to snap2 to just edit the xml
file and change the block device to point to snap2? Afterwards, I believe snap3
would become unusable and should be deleted?
For internal snapshots, it should just work; when reverting, it
shouldn't matter whether the domain is live or shutdown, because you are
going to change state anyway.  Internal snapshots are not invalidated
(the way qcow2 works, each internal snapshot increments a reference
counter on all clusters in use at the time of the snapshot, with no
intrinsic relation between snapshots; executing from the point of a
given snapshot does a copy-on-write allocation for any cluster with a
reference count larger than 1).

Peter and I kind of got stalled on the code to do reverts of external
snapshots.  You may want to take a snapshot just prior to reverting if
you want to be able to toggle between snapshot branches rather than
abandoning the current state that existed prior to the revert action.
With external snapshots, reverting to an earlier point has two
possibilities - modify the backing file, which invalidates all later
files that were based on the backing file, or create a new qcow2 wrapper
around the backing file.

One of the features I'd like to add (but did not make into 1.0.2) is the
ability to do a revert-and-create atomic operation, where a new external
snapshot is created in parallel to the existing atomic snapshot, so that
you aren't invalidating other branches of the snapshot tree.  The other
alternative is that a revert must discard any branches of the snapshot
tree that get invalidated by modifying a backing file earlier in the chain.

But without full libvirt support for revert of external snapshots, some
of these actions will require manipulations of domain xml and/or calls
to qemu-img to affect the changes you want (in this case, while the
domain is offline).
> 
> 2. If I would like to start a new VM from snap1, is there a way to extract
a copy of this snapshot from the chain, to an independent image file?
If you did an internal snapshot, then the only current way to extract
the information from that snapshot is to have the guest offline, then
use a series of qemu-img commands to temporarily switch which snapshot
is active, clone the image, then undo the temporary switch.  I have
requested that qemu developers add a way to extract snapshot contents
via an NBD server, even for an in-use image, but we aren't there yet
(certainly not for qemu 1.4, and probably not even for qemu 1.5).

For external snapshots, all you have to do is create a new qcow2 file
with the same backing image that you want to branch from.
> I tried to use "virsh blockcopy" but it returned this error:
> # virsh blockcopy VM1 vda snap1.qcow2 --wait --verbose
> error: Requested operation is not valid: domain is not transient
Yeah, until qemu 1.5 introduces persistent bitmaps, this is an
unfortunate limitation in libvirt blockcopy.  Libvirt refuses to do a
blockcopy on a persistent domain, because current qemu can't restart a
blockcopy operation; it is possible to temporarily make your domain
transient (virsh undefine), then do the blockcopy, then restore the
domain persistence (virsh define).  Or wait until persistent blockcopy
is added to qemu, and libvirt gains the counterpart code to make use of
persistent bitmaps in order to allow a restartable blockcopy even across
actions like 'virsh save'.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20130131/9f0abd1e/attachment.sig>