[libvirt-users] Managing Live Snapshots with Libvirt 1.0.1

[Andrew Martin]

Hi Eric,

----- Original Message -----

> From: "Eric Blake" <eblake at redhat.com> To: "Andrew Martin"
> <amartin at xes-inc.com> Cc: libvirt-users at 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?]

Done. :)

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

Here's the full command I've been using: 
virsh snapshot-create-as --domain "$VM_NAME" --name "$SNAP_NAME" --disk-only --atomic

Can you elaborate on the difference between internal and external
snapshots? The snapshots I created with the above command are contained
in separate qcow2 backing files, which I would think to be external, but
snapshot-info shows them as internal?

>From what I can see there are 3 different types of snapshots:  
1. internal (offline) qcow2 snapshots created with qemu-img snapshot 
2. external (live) snapshots with --disk-only 
3. external (live) snapshots with --memspec and/or --diskspec

Or, am I misunderstanding what --disk-only and --diskspec do?

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

Since they are separate copy-on-write snapshots, this means I could
revert to snap1, make changes, and then later revert to snap3?

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

Thanks,

Andrew