From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=32876 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Px0xr-0005jE-Ct for qemu-devel@nongnu.org; Tue, 08 Mar 2011 12:44:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Px0xp-0001JW-2s for qemu-devel@nongnu.org; Tue, 08 Mar 2011 12:44:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Px0xo-0001JL-P2 for qemu-devel@nongnu.org; Tue, 08 Mar 2011 12:44:53 -0500 Message-ID: <4D766B0E.9030908@redhat.com> Date: Tue, 08 Mar 2011 19:44:46 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1 References: <1299460984-15849-1-git-send-email-aliguori@us.ibm.com> <4D7500C8.1080101@codemonkey.ws> <4D760F2B.7030004@redhat.com> <4D7630BA.4010609@us.ibm.com> <4D763311.5030905@redhat.com> <4D763525.2030700@codemonkey.ws> <4D763674.8000600@redhat.com> <4D7638BE.60808@codemonkey.ws> <4D763A61.2020809@redhat.com> <4D763F76.2020003@codemonkey.ws> <4D7642C1.90604@redhat.com> <4D764551.4000409@codemonkey.ws> In-Reply-To: <4D764551.4000409@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, Luiz Capitulino , Michael D Roth , Adam Litke , Markus Armbruster On 03/08/2011 05:03 PM, Anthony Liguori wrote: >> We may want to use a different way of separating the namespaces - >> enacapsulation: >> >> { >> 'command': 'guest-command', >> arguments: { >> 'command': 'read-file', >> 'arguments': { >> 'path': '/var/log/messages' >> } >> } >> } >> >> This serves to decouple the two protocols, which may have different >> support lifetimes (hopefully not). > > > We could also have a more proper namespace in the protocol. Like: > > { 'execute': { 'namespace': 'guest', 'command': 'read-file' }, > 'arguments': { 'path': '/var/log/messages' } } Yeah, looks better. > > I'm not sure I see this as all that critical though. I sort of like > the idea of it being transparent to the client whether a guest agent > implements a command or QEMU does. A qemu command is guaranteed to be executed faithfully, modulo bugs and runtime errors. A guest command is guaranteed to be executed (or not) in the most hostile way possible to the management agent. It's important to make that clear in the ABI. We should also have separate schemas, one including the other. So we can have a monitor channel that only executes guest commands, for instance. > >> In addition to commands we may also implement a key-value store. A >> large number of commands may be easy to implement using a single >> key/value, and it's also easy to live migrate (key/values being >> stored in but not understood by qemu). > > Do you mean the guest querying QEMU for key-values? QMP doesn't have > a reverse direction RPC. It only has events which is one of the > things that makes live migration work nicely. Both the guest and the management agent (and both can listen for events). I don't see why guest->qemu RPC is problematic for migration - at least when qemu terminates it. -- error compiling committee.c: too many arguments to function