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.
