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/