Hi Eric, ----- Original Message ----- > From: "Eric Blake" <eblake@xxxxxxxxxx> To: "Andrew Martin" > <amartin@xxxxxxxxxxx> Cc: libvirt-users@xxxxxxxxxx Sent: Thursday, > January 31, 2013 6:25:42 PM Subject: Re: 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 _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
