Re: [libvirt-users] Managing Live Snapshots with Libvirt 1.0.1

From: "Eric Blake" <eblake(a)redhat.com&gt; To: "Andrew Martin" <amartin(a)xes-inc.com&gt; Cc: libvirt-users(a)redhat.com Sent: Thursday, January 31, 2013 6:25:42 PM Subject: Re: [libvirt-users] Managing Live Snapshots with Libvirt 1.0.1 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?

From what I can see there are 3 different types of snapshots:

> 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