[libvirt-users] Disk-only internal snapshot
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. Thanks, Davide.
On 10/24/2012 02:27 PM, Davide Guerri wrote:
Hi all, it's possible to do an internal snapshot with the --disk-only option (for qcow2 images)?
Not with the current qemu implementation. The qemu folks left room in the 'blockdev-snapshot-async' monitor command to eventually allow for an internal snapshot, but haven't wired it up yet. But if they ever do wire it up, then libvirt is ready to support it.
The following command
virsh snapshot-create-as my-dom my-snap my-description
creates an internal snapshot but the following
Also, be aware that Peter just posted patches to allow for creating an external snapshot without using --disk-only, with much better response time than internal snapshots take: https://www.redhat.com/archives/libvir-list/2012-October/msg01290.html
virsh snapshot-create-as my-dom my-snap my-description --disk-only
creates an external snapshot.
-- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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. Thanks again, Davide. 2012/10/24 Eric Blake <eblake@redhat.com>
On 10/24/2012 02:27 PM, Davide Guerri wrote:
Hi all, it's possible to do an internal snapshot with the --disk-only option (for qcow2 images)?
Not with the current qemu implementation. The qemu folks left room in the 'blockdev-snapshot-async' monitor command to eventually allow for an internal snapshot, but haven't wired it up yet. But if they ever do wire it up, then libvirt is ready to support it.
The following command
virsh snapshot-create-as my-dom my-snap my-description
creates an internal snapshot but the following
Also, be aware that Peter just posted patches to allow for creating an external snapshot without using --disk-only, with much better response time than internal snapshots take: https://www.redhat.com/archives/libvir-list/2012-October/msg01290.html
virsh snapshot-create-as my-dom my-snap my-description --disk-only
creates an external snapshot.
-- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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
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... - 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@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
-- /kashyap
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... - 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@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
-- /kashyap
First of all, I'd like to thank you all for the very detailed replies. Even if I've learnt a lot today about libvirt snapshot features, I'm stuck because I'm currently using Ubuntu Precise which is very "conservative" about libvirt/qemu/kvm versions. :) I'll soon create a new hypervisor for testing purpose and I'll experiment the features/patches you've pointed out. Cheers, Davide. On 25/ott/2012, at 06:26, Kashyap Chamarthy <kchamart@redhat.com> wrote:
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... - 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@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
-- /kashyap
participants (4)
-
Abbas -
Davide Guerri -
Eric Blake -
Kashyap Chamarthy