Hi all, it's possible to do an internal snapshot with the --disk-only option (for qcow2 images)?

The following command virsh snapshot-create-as my-dom my-snap my-description creates an internal snapshot but the following

virsh snapshot-create-as my-dom my-snap my-description --disk-only creates an external snapshot.

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'm trying to backup (live) machines with the shortest downtime possible.

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.

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

> > 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(a)redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users

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-b... - 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(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-users > -- /kashyap