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

[Programmingkid]

On Oct 6, 2016, at 3:59 PM, Eric Blake wrote:

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

Virt-manager is a Linux exclusive. This program doesn't run on Windows or
Mac OS.

> 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).

There are multiple variables to consider. Hardware might be added or taken
away in between save states. Ensuring consistency between save states
is what the user should do.

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

The save states would be stored in the qcow2 image file of the guest
operating system. Multiple operatings could be managed this way by one
gui.

> 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).

The savevm feature is anything but perfect, but that doesn't mean we
shouldn't provide easy access to it. This feature is already there in
QEMU, so why not help the user be able to use it?