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@xxxxxxxxx> > 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.
