Re: Save qemu state

[Peter Maydell]

On Wed, 1 Dec 2021 at 19:28, Leek, Jim <leek2@llnl.gov> wrote:
> So, why doesn't QEMU support external checkpoints?  (ie an option
> where checkpoints each get written to a new file.)

If you really want to save to an external file I think you
can do this by treating it as a migration (which is the same
infrastructure underneath for snapshotting the machine state,
but it sends it over eg a file descriptor or a socket rather
than saving it into a qcow2 file). David Gilbert gives a
set of commands that might work for this in this email thread:
https://lore.kernel.org/qemu-devel/YRvjHiZmPkSuv%2F%2Fz@work-vm/

# (qemu) migrate_set_parameter max-bandwidth 100G
# (qemu) migrate "exec:cat > myfile.mig"
# (qemu) q
#
# qemu -incoming "exec:cat myfile.mig"

I haven't tried them, but this sort of thing is probably a
good place to start if you want to investigate more complicated
things than "just save to the qcow2".

My guess at the reason why savevm requires qcow2 is because qcow2
provides a builtin mechanism for taking a low-cost snapshot of the
state of the disk image -- otherwise you would end up needing to put the
whole of your raw disk image contents in the snapshot, or otherwise
manually arrange to do something to keep a copy of them. So it
probably didn't seem like a big deal to tie the vm save/restore
to qcow2 back when that code was written. (Looking into the depths
of the git history it looks like the very first incarnation of
'savevm' really did take a separate filename to write the state
to. Commit faea38e78 in 2006 is when that changed.)

These days, the migrate command provides the power and flexibility that
is needed by the main use-case of the ability to checkpoint the VM,
ie migrating the VM from one host to another. The use as a
developer-tool convenience is something we get as a handy
side-benefit, not something anybody's actively paid to improve
the ergonomics of.

-- PMM