[virt-tools-list] Saved VM state not part of snapshot?
michael at weiser.dinsnail.net
Fri Oct 25 18:28:25 UTC 2019
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. So does Cole Robinson's Blog article
about snapshots. 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?
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)
- create a snapshot of this suspended state including disk and memory
- let it sit for some time
- resume the VM and work with it, suspending and resuming it some more
- revert it to the saved state for or at the next time I want to use it
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
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
Is there any functionality I could activate to implement my use case,
e.g. external snapshots?
Sorry if this is a dumb question.
More information about the virt-tools-list