From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MK7S8-0006MT-33 for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:10:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MK7S2-0006M3-Lp for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:10:34 -0400 Received: from [199.232.76.173] (port=39952 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MK7S2-0006M0-Fx for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:10:30 -0400 Received: from mx1.redhat.com ([66.187.233.31]:50294) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MK7S2-0001R9-3s for qemu-devel@nongnu.org; Fri, 26 Jun 2009 05:10:30 -0400 Date: Fri, 26 Jun 2009 10:10:12 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file Message-ID: <20090626091012.GD28206@redhat.com> References: <5b31733c0906241224j50baa7e6lc80b8c79c5d6baa7@mail.gmail.com> <20090624211358.GA14121@shareable.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A448E46.1000707@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:00:54PM +0300, Avi Kivity wrote: > On 06/25/2009 10:03 PM, Daniel P. Berrange wrote: > >On Thu, Jun 25, 2009 at 01:10:36PM -0500, Anthony Liguori wrote: > > > >>Stefano Stabellini wrote: > >> > >>>Clearly I agree with Avi. > >>>I am thinking for example that we could use the RPC protocol directly > >>> > >>>from Xend and I am sure other people will find it useful too. > >> > >>> > >>> > >>But you can also use QMP from Xend. In fact, it should be pretty easy > >>to convert the current code in Xend to use QMP. > >> > > > >AFAIK, the current XenD code doesn't talk to the QEMU monitor at all, > >instead having a add-on to QEMU code which pulls info from XenStored. > >That doesn't alter your point though, it would be pretty easy to make > >XenD talk to the proposed QMP monitor if desired. > > > > All it takes is implementing QMP, and an emitter/parser for each qemu > command. On the other hand, things like xml-rpc require around one line > of code in Python per command. > > 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. 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. 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 :|