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:44:40 +0100
User-agent: Mutt/1.4.1i

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




reply via email to

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