From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsEph-0002q1-2g for qemu-devel@nongnu.org; Thu, 06 Oct 2016 15:59:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsEpd-0007KC-07 for qemu-devel@nongnu.org; Thu, 06 Oct 2016 15:59:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsEpc-0007JL-N6 for qemu-devel@nongnu.org; Thu, 06 Oct 2016 15:59:52 -0400 References: <42B37FE3-87E1-42CA-A089-B090F37FF7D5@gmail.com> From: Eric Blake Message-ID: Date: Thu, 6 Oct 2016 14:59:49 -0500 MIME-Version: 1.0 In-Reply-To: <42B37FE3-87E1-42CA-A089-B090F37FF7D5@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6eUDFguTawtB2t23QuGDbl3wjtXpmh4dP" Subject: Re: [Qemu-devel] Adding Save States menu items List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid , Peter Maydell Cc: qemu-devel qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6eUDFguTawtB2t23QuGDbl3wjtXpmh4dP From: Eric Blake To: Programmingkid , Peter Maydell Cc: qemu-devel qemu-devel Message-ID: Subject: Re: [Qemu-devel] Adding Save States menu items References: <42B37FE3-87E1-42CA-A089-B090F37FF7D5@gmail.com> In-Reply-To: <42B37FE3-87E1-42CA-A089-B090F37FF7D5@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/06/2016 09:22 AM, Programmingkid wrote: > Would you accept a patch that added "Save State" and "Restore State" me= nu items to the cocoa interface? They would allow the user to save the ru= nning 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --6eUDFguTawtB2t23QuGDbl3wjtXpmh4dP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJX9q01AAoJEKeha0olJ0NqlHEIAKq42jIYini6HoJEtSD4gDrO 8pWAVAc6G/bIs7m2KIL8/ITgNixg5qsA/1yiBgENQCx2GdVV/q0xqni3wVAn0Hy9 P6PAa6g1M0tzEr32veEg/+D8moCFT+O4gM4hemxMt4OTkK99+homUq92WhTxSgIO u17wqr6db/B/pU/ReoDkCcj+W8X0tuDan4MW4i2XYsLTtChpyNAtoI+i6Ic6mksr iSR9fiKj88x1Pb66833Cue7uWLPD9NwSfyjBCktQDdB2dvnCgL29JrhFvAeI29jh 4NcR1zA6GzTUKE3vutZWUvB8oQNSNujVuUtgjyNOnanW389rmP031IOBgnAH3VU= =yahb -----END PGP SIGNATURE----- --6eUDFguTawtB2t23QuGDbl3wjtXpmh4dP--