how to use external snapshots with memory state

[Peter Krempa]

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