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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/