From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsWYc-0006L5-AE for qemu-devel@nongnu.org; Fri, 07 Oct 2016 10:55:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsWYY-0000wT-SN for qemu-devel@nongnu.org; Fri, 07 Oct 2016 10:55:30 -0400 Received: from mail-io0-x241.google.com ([2607:f8b0:4001:c06::241]:36712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsWYY-0000wH-I8 for qemu-devel@nongnu.org; Fri, 07 Oct 2016 10:55:26 -0400 Received: by mail-io0-x241.google.com with SMTP id o141so5619ioe.3 for ; Fri, 07 Oct 2016 07:55:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Programmingkid In-Reply-To: <20161007090912.GC26332@redhat.com> Date: Fri, 7 Oct 2016 10:55:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6EBED6CB-95BE-41BC-A996-0188B53A1759@gmail.com> References: <42B37FE3-87E1-42CA-A089-B090F37FF7D5@gmail.com> <20161007090912.GC26332@redhat.com> Subject: Re: [Qemu-devel] Adding Save States menu items List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Eric Blake , Peter Maydell , qemu-devel qemu-devel 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. >>=20 >> 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. >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >=20 > 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. >=20 >> 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 > 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.=20 http://wiki.qemu.org/Features/SnapshottingImprovements This pages shows that someone is trying to fix several migration issues.=