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
