[Libvir] Remote & the problem with qemu deadlock
veillard at redhat.com
Wed Apr 18 15:18:46 UTC 2007
On Wed, Apr 18, 2007 at 03:21:55PM +0100, Richard W.M. Jones wrote:
> As I wrote here:
> 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, 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
I still don't understand why we can't determine a call is local and
serve it directly, I must be blind ...
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the libvir-list