From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtB26-000381-Vo for qemu-devel@nongnu.org; Thu, 10 Jan 2013 00:50:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtB25-0006WZ-K5 for qemu-devel@nongnu.org; Thu, 10 Jan 2013 00:50:30 -0500 Received: from e28smtp02.in.ibm.com ([122.248.162.2]:41622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtB24-0006WH-T1 for qemu-devel@nongnu.org; Thu, 10 Jan 2013 00:50:29 -0500 Received: from /spool/local by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 10 Jan 2013 11:18:50 +0530 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id CBEF0125804C for ; Thu, 10 Jan 2013 11:20:34 +0530 (IST) Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0A5oIGp46792912 for ; Thu, 10 Jan 2013 11:20:18 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0A5oKoB023879 for ; Thu, 10 Jan 2013 16:50:20 +1100 Message-ID: <50EE5692.20604@linux.vnet.ibm.com> Date: Thu, 10 Jan 2013 13:50:10 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <92c5c71b9467824fe0423debd5d62ad6c7321106.1357741229.git.phrdina@redhat.com> <50EDEFFC.9090508@redhat.com> In-Reply-To: <50EDEFFC.9090508@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 07/13] qapi: Convert savevm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Pavel Hrdina , qemu-devel@nongnu.org, phrdina@redhat.c0m, lcapitulino@redhat.com 于 2013-1-10 6:32, Eric Blake 写道: > On 01/09/2013 08:18 AM, Pavel Hrdina wrote: >> Signed-off-by: Pavel Hrdina >> --- >> hmp-commands.hx | 4 ++-- >> hmp.c | 9 +++++++++ >> hmp.h | 1 + >> include/sysemu/sysemu.h | 1 - >> qapi-schema.json | 18 ++++++++++++++++++ >> qmp-commands.hx | 29 +++++++++++++++++++++++++++++ >> savevm.c | 27 ++++++++++++--------------- >> 7 files changed, 71 insertions(+), 18 deletions(-) >> > > For patches 1-6, you may add Reviewed-by: Eric Blake > However, for this patch, I think we may need to think more about the design. > >> +++ b/qapi-schema.json >> @@ -3017,3 +3017,21 @@ >> # Since: 1.3.0 >> ## >> { 'command': 'nbd-server-stop' } >> + >> +## >> +# @vm-snapshot-save: >> +# >> +# Create a snapshot of the whole virtual machine. If tag is provided as @name, >> +# it is used as human readable identifier. If there is already a snapshot >> +# with the same tag or ID, it is replaced. >> +# >> +# The VM is automatically stopped and resumed and saving a snapshot can take >> +# a long time. > > Since my initial review on your earlier RFC, I have changed my mind a > bit and started thinking that merely exposing the existing HMP commands > as raw QMP commands is gross. The HMP design is blocking - you can't > abort the snapshot, and since it is long-running, you can't do anything > else with the guest during that time, either. Of course, the guest is > paused, but why does it have to be? Couldn't we enhance the snapshot > code to use the same principles as live migration to take an internal > snapshot without pausing the guest up front? > > This our chance to make life better by breaking the QMP interface into a > sequence of commands, and merely rewriting the existing HMP command call > the entire QMP sequence under the hood, rather than just exposing the > same clunky one-command design in QMP. In other words, I think it would > be nicer to have a job-based snapshot, where one command starts the > snapshot, and then another command can query status to see if the > snapshot is still underway, an event gets fired when the snapshot > completes, and where yet another command can be used to cleanly abort a > long-running snapshot if it turns out the snapshot is no longer needed > because something else came up that must be dealt with now. > > In other words, I think this series and Wenchao Xia's series[1] need to > coordinate on a common design. > [1] https://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00645.html > I think the job based snapshot may comes later after vmstate live save is implemented, and now this interface is acceptable but mark it in name or comment that it is sync. >> +# >> +# @name: #optional tag of new snapshot or tag|id of existing snapshot >> +# >> +# Returns: Nothing on success >> +# >> +# Since: 1.4.0 >> +## >> +{ 'command': 'vm-snapshot-save', 'data': {'*name': 'str'} } > > But if we insist making the same clunky QMP interface, then this (plus > the followup improvements in 13/13 for adding a force option) seems like > a valid translation from HMP. > -- Best Regards Wenchao Xia