From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MK7zK-0002PN-7b for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:44:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MK7zF-0002Ld-Dv for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:44:53 -0400 Received: from [199.232.76.173] (port=33679 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MK7zD-0002L7-NV for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:44:47 -0400 Received: from mx1.redhat.com ([66.187.233.31]:47740) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MK7zD-0004jO-6B for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:44:47 -0400 Date: Fri, 26 Jun 2009 10:44:40 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090626094440.GF28206@redhat.com> References: <4A43768A.2090604@eu.citrix.com> <4A438FDD.5060206@redhat.com> <4A43935D.6000506@codemonkey.ws> <4A4395B8.4010401@redhat.com> <4A43AE13.4030900@eu.citrix.com> <4A43BD9C.8070304@codemonkey.ws> <20090625190302.GA11937@redhat.com> <4A448E46.1000707@redhat.com> <20090626091012.GD28206@redhat.com> <4A4491F6.8020502@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4491F6.8020502@redhat.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "ehabkost@redhat.com" , Stefano Stabellini , "jan.kiszka@siemens.com" , "dlaor@redhat.com" , "qemu-devel@nongnu.org" , Luiz Capitulino , Filip Navara , Vincent Hanquez On Fri, Jun 26, 2009 at 12:16:38PM +0300, Avi Kivity wrote: > On 06/26/2009 12:10 PM, Daniel P. Berrange wrote: > > > >>Let's turn this around. IIRC libvirt uses an RPC interface for its > >>clients. How would you estimate the effort to port this interface to > >>QMP, and adapt all its clients? > >> > > > >The libvirt RPC interface is a binary message based protocol, using XDR > >to encode arguments/return values, and emit signals. The libvirt for > >handling this is quite complex because it has to deal with TLS, and > >SASL for data encryption, as well as alllowing overlapping RPC requests > >on a single TCP connection ( to allow multi-threaded clients to have > >parallelized method calls without opening multiple connections). So > >it would be a fairly significant amount of work, in comparison to the > >current QMP proposal. > > > > You're describing an RPC with asynchronous commands and notifications, > with support for authentication and authorization. While qemu doesn't > need auth*, it does need the other features, so RPC looks like a good fit. > > >The existing libvirt code to talk to QEMU's monitor is actually rather > >simple by comparison to our native RPC code. The problems we have > >historically had with the QEMU monitor were, ill defined data printed > >when an error occurs, the changing of monitor commands between QEMU > >releases in incompatible ways, the lack of quoting for arguments and > >no support for async events. > > > > No doubt RPC is complicated if you implement it yourself, but surely you > used a library? Actually using the RPC is simpler than a line protocol. We only used a library for the data serialization/de-serialization. It would have been nice to use libdbus.so in peer-to-peer (non-bus) mode, but sadly it still lacks any useful form of encryption, or authetnication for TCP, and the windows port is still an incomplete hacked up fork of the code. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|