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