From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Dfh-0005bK-0D for qemu-devel@nongnu.org; Thu, 01 Mar 2012 16:36:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3Dff-0000fv-5g for qemu-devel@nongnu.org; Thu, 01 Mar 2012 16:36:20 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:51183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Dfe-0000fi-Vo for qemu-devel@nongnu.org; Thu, 01 Mar 2012 16:36:19 -0500 Received: by pbcuo5 with SMTP id uo5so251860pbc.4 for ; Thu, 01 Mar 2012 13:36:16 -0800 (PST) Message-ID: <4F4FEBCB.7020509@codemonkey.ws> Date: Thu, 01 Mar 2012 15:36:11 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1330600908-16202-1-git-send-email-pbonzini@redhat.com> <4F4FE5B7.2080306@codemonkey.ws> <4F4FEA65.2080903@redhat.com> In-Reply-To: <4F4FEA65.2080903@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 0/6] Mirrored writes using blockdev-transaction List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, stefanha@linux.vnet.ibm.com, jcody@redhat.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, fsimonce@redhat.com, Paolo Bonzini On 03/01/2012 03:30 PM, Eric Blake wrote: > On 03/01/2012 02:10 PM, Anthony Liguori wrote: >>> 2) Execute the following QMP command >>> >>> { "execute": "qmp_capabilities" } >>> { "execute": "blockdev-transaction", "arguments": >>> {'actions': [ >>> { 'type': 'snapshot', 'data' : >>> { 'device': 'ide0-hd0', 'snapshot-file': >>> '/home/pbonzini/base.qcow2' } }, >>> { 'type': 'mirror', 'data' : >>> { 'device': 'ide0-hd0', 'target': '/home/pbonzini/mirror.qcow2' >>> } } ] } } >>> { "execute": "cont" } >> >> We don't have schema introspection today. How would one determine when >> new transaction types are available? >> >> I think we need some sort of introspection method too in order for >> clients to figure out when the command is extended. >> > > I agree that introspection is necessary. Up till now, libvirt could get > by with query-commands (either a command exists or it doesn't). But now > we have the case where blockdev-transaction might exist, but doesn't > support the particular union action such as 'mirror' that libvirt wants > to use. > > Could this be something we wire up to the query-commands command? > > Something like: > > { 'type': 'CommandInfo', 'data': {'name': 'str', '*syntax': 'str'} } > { 'command': 'query-commands, > 'data': { '*syntax': 'bool', '*names': ['str'] }, > 'returns': ['CommandInfo'] } > > where the normal {"execute":"qemu-commands"} just returns the list of > command names, but {"execute":"qemu-commands", "arguments": { "syntax": > "true", "names" : [ "blockdev-transaction" ] } } then returns: > > {"return":[{"name":"blockdev-transaction", "syntax":"{ 'command' ... > }"}], "id":"..."} > > that is, return back the qapi-schema.json description of the command. > Actually, I'd guess you'd also want to be able to query 'type' listings, > not just 'command's, so maybe this deserves a new monitor command rather > than shoe-horning it onto an existing one. Yes, this is what I would like to do, but it's a requires a bit of work to implement. You'd have to either install qapi-schema.json and read it at run time or serialize it to a C data structure that can then be used to initialize a QObject. Nothing Earth shattering, just a fair amount of bit moving. Regards, Anthony Liguori >