From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49763) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoPpF-0004PJ-Q1 for qemu-devel@nongnu.org; Sun, 16 Jun 2013 23:09:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UoPpE-0004Co-LA for qemu-devel@nongnu.org; Sun, 16 Jun 2013 23:09:49 -0400 Received: from e28smtp05.in.ibm.com ([122.248.162.5]:37888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UoPpE-0004CS-0X for qemu-devel@nongnu.org; Sun, 16 Jun 2013 23:09:48 -0400 Received: from /spool/local by e28smtp05.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 17 Jun 2013 08:34:51 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id 521E1125804E for ; Mon, 17 Jun 2013 08:38:36 +0530 (IST) Received: from d28av02.in.ibm.com (d28av02.in.ibm.com [9.184.220.64]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r5H39Yma23265354 for ; Mon, 17 Jun 2013 08:39:35 +0530 Received: from d28av02.in.ibm.com (loopback [127.0.0.1]) by d28av02.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r5H39cfa004061 for ; Mon, 17 Jun 2013 13:09:38 +1000 Message-ID: <51BE7DD2.5020800@linux.vnet.ibm.com> Date: Mon, 17 Jun 2013 11:09:06 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1371209999-15579-1-git-send-email-xiawenc@linux.vnet.ibm.com> <1371209999-15579-9-git-send-email-xiawenc@linux.vnet.ibm.com> <51BC393A.8030106@redhat.com> In-Reply-To: <51BC393A.8030106@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH V2 08/12] qmp: add interface blockdev-snapshot-internal-sync List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, phrdina@redhat.com, famz@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, stefanha@redhat.com, pbonzini@redhat.com, dietmar@proxmox.com 于 2013-6-15 17:51, Eric Blake 写道: > On 06/14/2013 12:39 PM, Wenchao Xia wrote: >> This interface can generate snapshot name automatically if it is not >> specified, since it is a single opertion. > > s/opertion/operation/ > >> >> Snapshot ID can't be specified in this interface. >> >> Signed-off-by: Wenchao Xia >> --- >> blockdev.c | 25 +++++++++++++++++++++++++ >> qapi-schema.json | 23 +++++++++++++++++++++++ >> qmp-commands.hx | 31 +++++++++++++++++++++++++++++++ >> 3 files changed, 79 insertions(+), 0 deletions(-) >> > >> +++ b/qapi-schema.json >> @@ -1689,6 +1689,29 @@ >> '*mode': 'NewImageMode'} } >> >> ## >> +# @blockdev-snapshot-internal-sync >> +# >> +# Synchronously take an internal snapshot of a block device, when the format >> +# of the image used supports it. >> +# >> +# @device: the name of the device to generate the snapshot from >> +# >> +# @name: #optional the new snapshot name. If not specified, a name will be >> +# generated according to time by qemu > > So why is name optional here but mandatory within a transaction? If > qemu is able to generate names, then it should be able to generate names > in both cases. Otherwise, make the name mandatory in both places. A bit different: transaction take multiple requests, if some thing is generated it should return the info, but it didn't, so forbid it. But for this action, it is single, make caller possible to get accurate info by a info query. I'll make name mandatory in both case, it seems better. > > Should this patch be folded in to 7/12? Compare with Stefan's series on I think the two patch can distinguish each other: one is doing the job in "batch" mode, one is doing in "single" mode, and make each patch smaller. After review, I am OK to squash them. > adding block-snapshot as a transaction (for that matter, the two series > have a [trivial] merge conflict since both add a transaction), and make > sure you are using the same approach between the two series at > introducing things. I am OK to rebase if Stefan's patch upstream first. > >> +# >> +# Returns: nothing on success >> +# If @device is not a valid block device, DeviceNotFound >> +# If any snapshot matching @name exists, or the name is a numeric >> +# which may mess up with snapshot ID, generic error will be returned >> +# If the format of the image used does not support it, >> +# BlockFormatFeatureNotSupported >> +# >> +# Since 1.6 >> +## >> +{ 'command': 'blockdev-snapshot-internal-sync', >> + 'data': { 'device': 'str', '*name': 'str'} } > > Ah, so this answers my question in 7/12 about a witness that libvirt can > use for knowing when transaction supports the new action, without > needing introspection. > > >> + >> +SQMP >> +blockdev-snapshot-internal-sync >> +------------------------------- >> + >> +Synchronously take an internal snapshot of a block device when the format of >> +image used supports it. If name is not specified, it will be automatically >> +generated by qemu according to host time. If the name is a numeric string >> +which may mess up with ID, such as "19", the operation will fail. > > Wait a second. If we DON'T pass a name, then the generated name is all Nop, it starts with "vm", like "vm-20130608141726". But I'll make parameter name mandatory in next version. > numeric. But if we DO pass an all-numeric name, it gets rejected. > That's awkward to explain. Maybe you want to instead have a cutoff, > where a number < 64k (is that the right threshold? I just picked a > number out of the air) is rejected, but a number >= 64k is treated as > valid because it might represent a timestamp. Or allow all possible > numbers, and only reject the creation of a name that collides with an > existing id. It may be too hard to predict if a name will collide with > a future id of a later snapshot operation. > > >> +Example: >> + >> +-> { "execute": "blockdev-snapshot-internal-sync", >> + "arguments": { "device": "ide-hd0", >> + "name": "snapshot0" } >> + } >> +<- { "return": {} } > > Evil. If I don't pass a name, then I NEED to know what name got > generated on my behalf. So that argues you need to return something, > rather than nothing. I can see why you can't return a string via > 'transaction', but maybe this is an argument that 'name' should be > mandatory in this QMP command (and any generation of a timestamp id must > be higher up in the stack, at the HMP level, so that HMP can still treat > name as optional). But then you are back to solving the problem of > allowing an all-numeric generated timestamp as a valid name. > -- Best Regards Wenchao Xia