From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8ZYU-00065E-8X for qemu-devel@nongnu.org; Fri, 16 Mar 2012 11:59:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8ZYN-00027d-Rd for qemu-devel@nongnu.org; Fri, 16 Mar 2012 11:59:01 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:49285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8ZYN-00027N-LL for qemu-devel@nongnu.org; Fri, 16 Mar 2012 11:58:55 -0400 Received: by dadp14 with SMTP id p14so6460463dad.4 for ; Fri, 16 Mar 2012 08:58:53 -0700 (PDT) Message-ID: <4F636339.3090101@codemonkey.ws> Date: Fri, 16 Mar 2012 10:58:49 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1331899989-7756-2-git-send-email-stefano.stabellini@eu.citrix.com> <4F636123.5010901@redhat.com> In-Reply-To: <4F636123.5010901@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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, Luiz Capitulino , avi@redhat.com On 03/16/2012 10:49 AM, 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? Maybe we should call this xen-save-devices-state. As far as I'm concerned, this is a Xen specific interface, not an interface for general consumption. I would not expect libvirt to use this interface. If libvirt wants an interface that only saves device state, I'd much rather do it properly through QMP such that what was returned was well structured and in JSON. Regards, Anthony Liguori > > 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) > > 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). >