[virt-tools-list] Saved VM state not part of snapshot?

[Cole Robinson]

On 10/25/19 2:28 PM, Michael Weiser wrote:
> Hello,
> 
> as an end user I today realized and was quite surprised that the saved
> VM state of qemu/KVM VMs in virt-manager/libvirt does not seem to be
> part of internal qcow2 snapshots. Is that understanding correct?
> 
> The libvirt Wiki says as much[1]. So does Cole Robinson's Blog article
> about snapshots[2]. Both don't go into detail on the implications
> though because they focus on other points. Is that still the case and
> indeed not mitigated by virt-manager somehow?
>

I will insert some details to make sure I understand what you mean:

> What I tried to do is the following:
> 
> - boot up a VM
> - start some programs and generally configure an initial state
> - suspend the VM to disk (save not pause)

So, clicking the 'Save' option in virt-manager. Behind the scenes, this
saves the runtime memory contents to disk, and force powers off the VM.

> - create a snapshot of this suspended state including disk and memory

Since the VM is shutoff, this is actually only snapshotting disk
contents. So it's no different than snapshotting an offline VM.

> - let it sit for some time
> - resume the VM and work with it, suspending and resuming it some more
>   times
> - revert it to the saved state for or at the next time I want to use it

I assume at this last step, you mean 'revert to the saved snapshot'. So
the disk contents have been reset to the contents at step 3, and the VM
is shutoff. But the disk contents at step 3 were essentially the mid
flight disk contents from the 'save' operation.

> 
> When I tried the last step today while the VM was currently suspended
> (saved) I was able to restore the old snapshot. But when I ran the VM I
> got the current memory state and not the one of the time I took the
> snapshot.

So if in the second to last step, the VM is in the 'saved' state,
snapshot restore changes the disk contents to be mismatched from the
saved memory state. Yes this is could definitely cause disk corruption
if the VM is resumed.

> 
> It works as expected when the VM is snapshot in running state as well as
> (of course) when fully shut down.
> 
> This is with internal snapshots on qcow2 images and virt-manager 2.2.1 and
> a session libvirtd instance (qemu:///session URL).
> 
> Apart from not fitting my use case I wonder if virt-manager allowing me
> to execute this sequence of steps doesn't have the potential for
> massive corruption of my VM in that it allows me to swap out a disk
> state from under a running OS which will then most probably corrupt the
> mounted filesystems in interesting ways upon resume. Indeed I verified
> as much by creating and deleting sets of 100 test files at various
> states and reverting back to older snapshots and running fsck after a
> reboot. As expected it found about 100 unconnected files and placed them
> into lost+found which seems like the best-case outcome to me.
> 
> Shouldn't virt-manager at the very least refuse to restore the old
> disk state as long as there's still saved memory state? Or throw the
> current memory state away and do a cold boot (after a confirmation
> dialog)?
> 

Yes we need fixes here. Libvirt should be rejecting some of these cases
I think but virt-manager can help here too.

* Run/Revert of a snapshot should be rejected if the VM is in the
'Saved' state, aka has been 'virsh managedsave'. This should be done at
the libvirt level for completeness IMO. Maybe the API needs a flag to
override this behavior if users know what they are doing

* virt-manager prompts to discard saved state first otherwise it doesn't
all snapshot revert.

* Maybe reject snapshot creation when VM is in 'saved' state too, to
avoid ambiguity, but it's likely not as bad.

Bug reports and/or patches for these are welcome, I can help provide
patch guidance if needed

> Is there any functionality I could activate to implement my use case,
> e.g. external snapshots?
> 

No there's nothing that 'just works' how you want. External snapshots
may fit your needs some day but they aren't there yet.

But if you have a VM in the "Saved" state that you want to snapshot, you
can 'Run' it, and then snapshot the running instance, which will save
the memory state. Maybe that can be adapted to fit your needs. But for
now you shouldn't use snapshots if your VM is in 'Saved' state at all.
If you want to discard the saved state, just 'run' your VM first, then
revert to the relevant snapshot.

> Sorry if this is a dumb question.
> 

Not at all, this was a very useful email!

Thanks,
Cole