[Libvir] Re: Asynchronous notifications of domain start/stop

[Richard W.M. Jones]

Daniel Veillard wrote:
> On Wed, Jul 18, 2007 at 01:23:22PM +0200, Gerd Hoffmann wrote:
>>> That way except for the fd everything is synchronous and
>>> purely within the application flow of control. The problem is how to
>>> then feed the fd when "something occurs" especially since the something is
>>> happening in a different process or even a different domain.
>> What troubling events do you have in mind?  For remote you'll have the
>> socket to select() on.  As I far I know the very same protocol is used
>> for qemu, so you probably have a socket too, right?  For xen you can
>> just use the xenstore fd.  Dunno on the network stuff.  Who manages the
>> network?  Probably the libvirtd daemon too?  Then the notifications can
>> go through the libvirt <-> libvirtd socket connection, so you have a fd too.
> 
>   If you give directly the fd of the socket used to talk internally to the
> daemon then you must allow for case where there is data to read but no
> even will be generated in the function, because since you don't have the
> library filtering you can't be sure what's available is something the
> application is interested in.
>   For example if doing a migration a lot of traffic may happen on multiple
> sockets before the user see an event he's actually interested into.
> There is so much nastyness once you break the purely synchronous model.

I think, specifically with migration, the problem case is:

   client   -- sends domainMigrate -->   source server
     migration starts
     domain disappears from source server
   source server  -- sends domainStop event --> client

     later, domain appears on destination server
   destination server   -- sends domainStart event --> client

   source server   -- sends reply to domainMigrate -->   client

The domainStop event from the source server is the problem message.  It 
appears in between the request and the reply for an ordinary RPC.

This argues for having two separate connections, one for synchronous 
RPC, one for events.  That in itself is not very pleasant, particularly 
if the connections are going over ssh, or if connections are otherwise 
expensive to set up or maintain (hello TLS).

Oh and BTW, writing and reading TLS messages does not translate simply 
into write(2) and read(2) on the underlying fd.  TLS tends to chat 
backwards and forwards.  The remote driver goes to a lot of trouble to 
deal with this.

>> What might be needed is allowing multiple file handles (one socket to
>> xenstore, one socket to libvirtd) so libvirt can collect events from
>> different sources.  It becomes a bit difficuilt at that point.  avahi
>> has that problem too.  They have a "give me functions to register and
>> unregister filehandles"-style api for that.  And some helper functions
>> to make that easy for apps using the event loops of the usual gui libs
>> (glib/gtk, qt).
> 
>   Could be a possibility, the other one is to create one thread internal
> to the library but limited purely to doing I/O, still I find this disgusting.

Mmmm, not nice.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070718/44c78655/attachment-0001.bin>