qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 01/11] QMP: Introduce specification file
Date: Fri, 26 Jun 2009 10:10:12 +0100
User-agent: Mutt/1.4.1i

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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]