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

[Programmingkid]

On Oct 7, 2016, at 5:09 AM, Daniel P. Berrange wrote:

> On Thu, Oct 06, 2016 at 02:59:49PM -0500, 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.
>> 
>> 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.
> 
> Even that is not in fact sufficient - most QEMU command lines do not
> contain sufficient info to reliably restart the guest with the exact
> same machine ABI. You have to fully expand and canonicalize the
> command line so that it includes all the extra bits QEMU would silently
> expand - eg device addresses, exact versioned machine type, etc. without
> that, you'll fail to restore the guest on a different version of QEMU,
> even if you used the exact same command line as before.
> 
>> 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.
> 
> Agreed, it isn't a productive use of resources IMHO

This feature could be very helpful to many users. It could help others
to be more productive. 

http://wiki.qemu.org/Features/SnapshottingImprovements
This pages shows that someone is trying to fix several migration issues.