Re: [Libvir] Remote & the problem with qemu deadlock

[Daniel Veillard <veillard redhat com>]

On Wed, Apr 18, 2007 at 03:21:55PM +0100, Richard W.M. Jones wrote:
> As I wrote here: 
> https://www.redhat.com/archives/libvir-list/2007-April/msg00114.html 
> remote access to qemu:/// URLs currently deadlocks.  A bit of 
> explanation follows as to why this happens in the current architecture 
> of the remote patch.
> 
> If you apply the remote patch right now, you'll get a modified 
> libvirt_qemud server which can handle both qemu and remote requests over 
> the same socket.  (Basically both qemu_internal.c and remote_internal.c 
> connect to the same Unix domain socket, then depending on the "program 
> number" encoded within the RPC messages, they get dispatched accordingly 
> inside libvirt_qemud).  The server is written to handle multiple 
> connections at once using non-blocking poll[1], but once the server has 
> assembled a whole incoming message, it then blocks while dealing with 
> that message.
> 
> The problem occurs in the qemu case when the remote server issues a call 
> into qemu_internal (now linked into the server), and qemu_internal then 
> tries to connect out to the qemu daemon.  Unfortunately the qemu daemon 
> /is/ the remote server, which is blocked handling the current call. 
> Thus it is unable to accept the new connection (from itself) and 
> completely deadlocks.

  Can we recognize that the connection is on localhost and just serve
the request directly and synchronously instead ?

[...]
> I'd really like to see the qemu case not require a daemon.  At the 

  Sure !


  I still don't understand why we can't determine a call is local and
serve it directly, I must be blind ...

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/