[Libvir] Remote & the problem with qemu deadlock
Daniel Veillard
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:
> 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 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
mailing list