how to use external snapshots with memory state
Hi all, Best wishes for 2021! :) So I've been reading and playing around with live snapshots and still haven't figured out how to use an external memory snapshot. My goal is to take a disk+memory snapshot of a running VM and, if possible, save it in external files. As far as I understand, I can run: $ virsh snapshot-create $VM ... and that'll take an *internal* live snapshot of a given VM, consisting of its disks and memory state, which will be stored in the qcow2 disk(s) of the VM. In particular, the memory state will be stored in the first disk of the VM. I can then use the full range of snapshot commands available: revert, list, current, delete. Now, an external snapshot can be taken with: $ virsh snapshot-create-as --domain $VM mysnapshot --diskspec vda,file=/home/riccardo/disk_mysnapshot.qcow2,snapshot=external --memspec file=/home/riccardo/mem_mysnapshot.qcow2,snapshot=external ... with as many "--diskspec" as there are disks in the VM. I've read the virsh manual and the libvirt API documentation, but it's not clear to me what exactly I can do then with an external snapshot, in particular with the file containing the memory state. In articles from 7-8 years ago people state that external memory snapshots cannot be reverted... is it still the case today? If so, what's a typical usage for such files? If not with libvirt, is it possible to revert to an external memory + disk state in other ways, for instance through qemu commands? Thanks! Riccardo
On Fri, Jan 01, 2021 at 19:05:55 +0100, Riccardo Ravaioli wrote:
Hi all,
Hi,
Best wishes for 2021! :)
So I've been reading and playing around with live snapshots and still haven't figured out how to use an external memory snapshot. My goal is to take a disk+memory snapshot of a running VM and, if possible, save it in external files.
As far as I understand, I can run: $ virsh snapshot-create $VM ... and that'll take an *internal* live snapshot of a given VM, consisting of its disks and memory state, which will be stored in the qcow2 disk(s) of the VM. In particular, the memory state will be stored in the first disk of the VM. I can then use the full range of snapshot commands available: revert, list, current, delete.
Now, an external snapshot can be taken with: $ virsh snapshot-create-as --domain $VM mysnapshot --diskspec vda,file=/home/riccardo/disk_mysnapshot.qcow2,snapshot=external --memspec file=/home/riccardo/mem_mysnapshot.qcow2,snapshot=external ... with as many "--diskspec" as there are disks in the VM.
I've read the virsh manual and the libvirt API documentation, but it's not clear to me what exactly I can do then with an external snapshot, in particular with the file containing the memory state. In articles from 7-8 years ago people state that external memory snapshots cannot be reverted...
Unfortunately that's still true. The external snapshot code provides enough functionality that you are able to use them, but reverting and deleting needs to be done manually. There are a few manuals floating online but it always depends on what you want to achieve. The unfortunate situation of the implementation not being finished (I've certainly stated it here already, since this question happens from time to time (which also means you should look through the archives and you'll find some pointers how to do certain specific steps)) comes from the fact that it provides enough functionality for higher level management projects to control snapshots (oVirt, openstack) and too much higher priority work.
is it still the case today? If so, what's a typical usage for such files? If not with libvirt, is it possible to revert to an external memory + disk
The memory image created by libvirt this way is actually in the same image format as 'virsh save' and 'virsh restore' uses. This actually does allow you to restore such a snapshot, although manual steps are necessary. The most naive scenario, where you want to return to the past state and you don't require returning back (alternate future is not created) can be reverted simply by simply using 'virsh restore $IMG' and then fixing the persistent definition of the VM to use the same disk images as the memory image recorded. Note that the overlay images which were created as part of the snapshot are invalid after that point and must no longer be used. Similarly, for non-active VMs or vms without memory snapshot you can alter the image locations to use the old images and that effectively reverts the snapshot. Other operations are possible too, but please look through the archives first.
state in other ways, for instance through qemu commands?
Thanks!
Riccardo
On Sun, 3 Jan 2021 at 15:30, Peter Krempa <pkrempa@redhat.com> wrote:
Hi,
Hi Peter, Thanks a lot for the prompt reply and for pointing me to the direction ("virsh restore" among all) and apologies for my very late reply. In the past couple of weeks I had a thorough look at past messages in the mailing list as well as linked tutorials, notes and slides. The memory image created by libvirt this way is actually in the same
image format as 'virsh save' and 'virsh restore' uses. [...]
I think I bumped into two limitations for my particular use case, but I'd like to double check with you, just in case I'm again missing something. 1) When creating an external online snapshot (disks+memory) of a qemu-KVM VM, I'd like to store the backing files in a separate folder and rename the newly-created delta files with the respective names of the original disks (now the backing files). Is this possible at all? Say a VM has a disk vm/disk1.qcow2 and I take an external snapshot, I'd like the backing file to appear in snap/disk1.qcow2 and the new delta disk to appear as vm/disk1.qcow2. Currently I wait for the VM to be shutdown by the user before I move around disks as desired and run qemu-img rebase in unsafe mode to update the delta disks. Can I accomplish the same result while the VNF is running? 2) As you suggested, I now use "virsh restore" to launch a VM with the memory state I had previously backed up. The "virsh restore" API applies to a VM that is not running. However, I see that for internal snapshots, libvirt also supports a snapshot-revert operation on a /live/ VM. Is this possible at all with an external snapshot? If so, what are the commands needed? My current way of automating a snapshot-revert with an external online snapshot only applies to a shutdown VM. It consists in: - shutting down the VM; - erasing all its delta disks, replacing them with new ones; - executing "virsh restore" on the memory state, making sure that the disk paths referenced in the embedded XML file are correct. Does this seem reasonable? Can I do the same while the VNF is running? I suppose that for a snapshot-delete operation on a live VM I just need to run "virsh blockpull" on each disk, but I couldn't figure out how to do a revert. Thanks again! Riccardo
Hi all, Can I get some feedback on these two questions I posted a while back, concerning external snapshots: On Tue, 26 Jan 2021 at 00:15, Riccardo Ravaioli <riccardoravaioli@gmail.com> wrote: [...]
1) When creating an external online snapshot (disks+memory) of a qemu-KVM VM, I'd like to store the backing files in a separate folder and rename the newly-created delta files with the respective names of the original disks (now the backing files). Is this possible at all? Say a VM has a disk vm/disk1.qcow2 and I take an external snapshot, I'd like the backing file to appear in snap/disk1.qcow2 and the new delta disk to appear as vm/disk1.qcow2. Currently I wait for the VM to be shutdown by the user before I move around disks as desired and run qemu-img rebase in unsafe mode to update the delta disks. Can I accomplish the same result while the VNF is running?
2) As you suggested, I now use "virsh restore" to launch a VM with the memory state I had previously backed up. The "virsh restore" API applies to a VM that is not running. However, I see that for internal snapshots, libvirt also supports a snapshot-revert operation on a /live/ VM. Is this possible at all with an external snapshot? If so, what are the commands needed? My current way of automating a snapshot-revert with an external online snapshot only applies to a shutdown VM. It consists in: - shutting down the VM; - erasing all its delta disks, replacing them with new ones; - executing "virsh restore" on the memory state, making sure that the disk paths referenced in the embedded XML file are correct. Does this seem reasonable? Can I do the same while the VNF is running? I suppose that for a snapshot-delete operation on a live VM I just need to run "virsh blockpull" on each disk, but I couldn't figure out how to do a revert.
Thanks a lot! Riccardo
On Fri, Apr 09, 2021 at 19:00:41 +0200, Riccardo Ravaioli wrote:
Hi all,
Can I get some feedback on these two questions I posted a while back, concerning external snapshots:
On Tue, 26 Jan 2021 at 00:15, Riccardo Ravaioli <riccardoravaioli@gmail.com> wrote: [...]
1) When creating an external online snapshot (disks+memory) of a qemu-KVM VM, I'd like to store the backing files in a separate folder and rename the newly-created delta files with the respective names of the original disks (now the backing files). Is this possible at all? Say a VM has a disk vm/disk1.qcow2 and I take an external snapshot, I'd like the backing file to appear in snap/disk1.qcow2 and the new delta disk to appear as
No, this is not possible during the snapshot operation, you can control only the name of the new overlay image.
vm/disk1.qcow2. Currently I wait for the VM to be shutdown by the user before I move around disks as desired and run qemu-img rebase in unsafe mode to update the delta disks. Can I accomplish the same result while the VNF is running?
Very theoretically you can achieve the same during the lifetime of the VM by using 'virsh blockcopy' with the following algorithm: 1) ensure you have a overlay image that is small enough (but that's what the snapshot operation does if you do it right after snapshot). Note that the snapshot target should be something temporary, you'll see why below. 2) symlink/hardlink the original backing image (vm/disk1.qcow2) to the new locaton 3) create an empty qcow2 overlay file with the desired name of the disk _after_ snapshot, pointing to the hardlink of the new backing file destination 4) use shallow 'blockcopy' with --reuse-external operation to move the temp overlay to the file created in 3), this ensures that it's backing image as described in the metadata is used The above has IMO too many moving parts that can go wrong. I'd suggest adapting to the "backwards" naming of the images which happens with external snapshots.
2) As you suggested, I now use "virsh restore" to launch a VM with the memory state I had previously backed up. The "virsh restore" API applies to a VM that is not running. However, I see that for internal snapshots, libvirt also supports a snapshot-revert operation on a /live/ VM. Is this possible at all with an external snapshot? If so, what are the commands
No the operation is not implemented for external snapshots yet. The use of 'virsh restore' is a workaround, which requires manual steps to preserve images in certain scenarios.
needed? My current way of automating a snapshot-revert with an external online snapshot only applies to a shutdown VM. It consists in: - shutting down the VM; - erasing all its delta disks, replacing them with new ones; - executing "virsh restore" on the memory state, making sure that the disk paths referenced in the embedded XML file are correct.
Yes that will sounds reasonable. Note that the XML embedded in the saveimage points to the original base file so you'll always need to modify it to use the new deltas.
Does this seem reasonable? Can I do the same while the VNF is running? I suppose that for a snapshot-delete operation on a live VM I just need to run "virsh blockpull" on each disk, but I couldn't figure out how to do a revert.
No to use 'virsh restore' you must shutdown the VM, but note that in many cases with internal snapshots libvirt will also need to terminate and restart the QEMU process so this situation doesn't really differ. In the internal snapshot code is way more complicated in order to preserve the running process needlessly and I'd probably elect to always restart qemu when reverting them nowadays. The only drawback is that the remote video connection needs to be reopened.
participants (2)
-
Peter Krempa -
Riccardo Ravaioli