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

[Daniel P. Berrange]

On Fri, Oct 07, 2016 at 10:55:23AM -0400, Programmingkid wrote:
> 
> 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.

No one is questioning whether the feature is useful or not. The debate
is about whether it makes sense to spend the time implementing it in
QEMU, as opposed to fixing any portability problems in libvirt and/or
virt-manager and the consensus feeling points towards the latter being
a more productive use of time and resources.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|