From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38143) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8dRj-0006JP-Gg for qemu-devel@nongnu.org; Fri, 16 Mar 2012 16:08:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8dRh-0004Mq-Jm for qemu-devel@nongnu.org; Fri, 16 Mar 2012 16:08:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8dRh-0004Ml-Bd for qemu-devel@nongnu.org; Fri, 16 Mar 2012 16:08:17 -0400 Date: Fri, 16 Mar 2012 14:28:27 -0300 From: Luiz Capitulino Message-ID: <20120316142827.03907931@doriath.home> In-Reply-To: <4F636123.5010901@redhat.com> References: <1331899989-7756-2-git-send-email-stefano.stabellini@eu.citrix.com> <4F636123.5010901@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 2/6] Introduce "save-devices-state" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: xen-devel@lists.xensource.com, Stefano Stabellini , jan.kiszka@siemens.com, qemu-devel@nongnu.org, avi@redhat.com, anthony@codemonkey.ws On Fri, 16 Mar 2012 09:49:55 -0600 Eric Blake wrote: > On 03/16/2012 06:13 AM, Stefano Stabellini wrote: > > - add an "is_ram" flag to SaveStateEntry; > > > > - register_savevm_live sets is_ram for live_savevm devices; > > > > - introduce a "save-devices-state" QAPI command that can be used to save > > the state of all devices, but not the RAM or the block devices of the > > VM. > > > > > +QEMU has code to load/save the state of the guest that it is running. > > +These are two complementary operations. Saving the state just does > > +that, saves the state for each device that the guest is running. > > + > > +These operations are normally used with migration (see migration.txt), > > +however it is also possible to save the state of all devices to file, > > +without saving the RAM or the block devices of the VM. > > + > > +This operation is called "save-devices-state" (see QMP/qmp-commands.txt) > > Is there a complimentary load-devices-state? > > Just to make sure I'm clear, there are three things to save before you > have a complete picture of a running VM: > > disk state (can be saved with 'savevm' to internal qcow2 snapshots, or > with 'transaction' and 'blockdev-snapshot-sync' by creating external > snapshots, or by 'migrate' to a file) > > RAM state (can be saved with 'savevm' to internal qcow2 snapshot, or > with 'migrate' to a file; it is also possible to start qemu with a > command line parameter telling which backing file tracks RAM state) The maybe-to-be-added 'dump' command also saves RAM state, but to elf file format. > > device state (can be saved with 'savevm' to internal qcow2 snapshot, or > with 'migrate' to a file, and now with 'save-devices-state') > > That is, 'migrate' does all three at once to an external file, 'savevm' > does all three at once to an internal qcow2 snapshot, and you are now > making it possible to do any one of the three independently to an > external file while the VM continues to run. > > Is this something that libvirt should be exposing in the near future? > > > +SQMP > > +save-devices-state > > +------- > > + > > +Save the state of all devices to file. The RAM and the block devices > > +of the VM are not saved by this command. > > + > > +Arguments: > > + > > +- "filename": the file to save the state of the devices to as binary > > +data. See save-devices-state.txt for a description of the binary format. > > + > > +Example: > > + > > +-> { "execute": "save-devices-state", "arguments": { "filename": "/tmp/save" } } > > Can we at least reserve something for future extension to add things > like 'fd:name' to refer to a named fd received earlier via 'getfd'? You > could do that by documenting up front that if "filename" does not start > with "/", then any pattern of letters followed by a ':' as the initial > pattern of the filename is an error (and you avoid the error by using > ./foo:... or an absolute path). >