On 10/25/2012 02:44 AM, Eric Blake wrote:
On 10/24/2012 03:01 PM, Davide Guerri wrote:
Thank you Eric for the quick reply!
Do you know if there's a way to remove (not revert) an external snapshot on
a live domain?

I had the same needs as yours. Eric answered the questions I had.
So I wrote up live snapshots part of this wiki.
Would save your time though.

https://wiki.archlinux.org/index.php/Kvm#Live_Snapshots

There is also an article of live snapshots on Fedora's wiki too.

--
abbas

Depends on what version of libvirt and qemu you are using :)

Qemu 1.2 and libvirt 0.9.10 provide the virDomainBlockRebase (qemu
'block-stream') for flattening an external snapshot chain by pulling
into the active image, while the guest is running.  You have to deal
with the fact that every time you take a snapshot, the active image name
changes, but it's fairly reliably as a way of reducing the impact of a
long chain of external snapshots.

Qemu 1.3 (due in December) will be adding a new 'block-commit' monitor
command, which libvirt 1.0.0 (due next week) will also be able to reduce
backing chains by committing data from a snapshot back into the backing
image, while the guest is running.  As of now, qemu.git is limited to
committing just read-only portions of the backing chain, but we hope to
expand that to also committing the read-write active layer of the chain.

You can pair these chain-shortening commands with 'virsh snapshot-delete
$dom $snapname --metadata' to make it appear as if the snapshot never
happened.  It is even possible to do a sequence of snapshots and
pulls/commits to get back to the original file name (of course, with
twice the work as you go through a temporary file name).

I'm trying to backup (live) machines with the shortest downtime possible.
Then you may also be interested in Peter's and my recent patches, which
make it possible to back up machine RAM state in addition to disk state,
with very minimal downtime, and which also enhance what you can do with
revert and delete of those snapshots:
https://www.redhat.com/archives/libvir-list/2012-October/msg01290.html
It's definitely faster than the current downtime of 'virsh
snapshot-create' without --disk-only, which can take seconds or even
minutes where the guest is paused.

Since Peter posted his series after the 1.0.0 freeze, I'm not quite sure
whether we will take his patches this late in the release cycle, or if
it will be another month (and 1.0.1) before they are available.

You may also be interested in qemu 1.3 adding the 'drive-mirror'
command, which allows for taking a copy of a disk ('virsh blockcopy')
without affecting the backing chain in the first place.

The script I'm using makes a (full) snapshot of a VM, restore its state,
copies (with qemu-img convert) the snapshot out of the qcow file and
removes the snapshot.
So you want to convert back to raw?  'blockpull' can't do that, but
'blockcommit' (if it gains support for committing the active layer) and
'blockcopy' will be able to do so.

Oh, and if you want an early preview of 'blockcopy', check out RHEV 3.0,
where the qemu-kvm and libvirt versions as patched by Red Hat have
already been using an early backport of the blockcopy code for several
months now.



_______________________________________________
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users