On 10/25/2012 03:14 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? > > 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). Just expanding on Eric's very lucid detail. David, here's some examples I posted with 'blockcommit' & 'blockpull'(with QEMU git & Libvirt git as of 21st OCT) -- - http://kashyapc.fedorapeople.org/virt/blockcommit/recursive-blockcommit-base-raw.txt - http://kashyapc.fedorapeople.org/virt/blockpull/test-blockpull.txt Hope that helps. > >> >> 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvirt-users > -- /kashyap _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users