Re: [Qemu-devel] Adding Save States menu items

[Eric Blake]

On 10/06/2016 09:22 AM, Programmingkid wrote:
> Would you accept a patch that added "Save State" and "Restore State" menu 
> items to the cocoa interface? They would allow the user to save the running 
> state of the emulator.

Doesn't virt-manager already do this?  What do we gain by duplicating
GUI functionality at this level that is already implemented at higher
levels?  Not that I'm opposed to the idea, but having a solid reason why
it is useful is important.

Speaking with libvirt experience: saving a guest is somewhat easy.  But
once you have a save-state file, then what?  Remember, the qemu GUI is
associated with a SINGLE qemu process.  When libvirt manages save files,
it is managing MULTIPLE qemu processes.  The sequence of 'create a save
file, hot-plug a device, then reverting to the save file' currently
REQUIRES that you destroy one qemu process and create another one, where
the new process is back to the pre-hotplug configuration that was in use
when the save file was created.  Otherwise the qemu 'loadvm' command
will likely fail (and worse, if it does not fail, you are likely to
trigger even-harder-to-diagnose guest corruptions that only strike down
the road, rather than at the time of the loadvm).

If your gui (whether cocoa or GTK) is associated with a single qemu
process, then you will have a VERY tough time figuring out how to start
a new qemu process to replace the current one while still keeping the
gui unchanged.  And the work to convert qemu over to managing multiple
VMs itself is rather pointless, when you already have libvirt and
virt-manager and other wrappers that are already good at that.

Libvirt also learned that the qemu 'migrate-to-disk' format (used by
'savevm' or 'migrate') is NOT self-descriptive - in order to fully and
safely revert to an earlier state, you HAVE to store the command line
(or a way to regenerate the command line) that was associated with the
qemu whose state you saved, along with tracking all hotplugs.  Since a
mere 'savevm' REQUIRES external information to safely be restored, you
would have to figure out a way to store this additional information
alongside whatever save files you plan on creating (and please don't
change the qcow2 file format to become a dumping grounds for this
additional information).

Your idea may be noble, but I think you are going down a rabbit's hole
of unimplementable misery, and advise that you probably won't succeed.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature