Re: [Libvir] FYI: bug in remote code

On 10/16/07, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: > On Tue, Oct 16, 2007 at 02:52:27PM -0400, Mark Johnson wrote: > > I ran into a bug in the remote code... > > > > I was doing > > # virsh -c xen_tcp://<ip_addr>/ > > > > It you don't have qemu compiled in, you will hang in in libvirtd in > > > > do_open() > > res = virNetworkDriverTab[i]->open (ret, name, flags); > > > > when trying to open the remote network driver. Usually qemu > > returns success and you fall out of the loop before you call > > this (which is why you won't see it with qemu support built in). > > > > You hang in libvirtd trying to read from the libvirtd PF_UNIX > > socket. You read from the socket because you hit this code > > path in doRemoteOpen() > > > > if (!uri->server && !transport_str) { > > if (flags & VIR_DRV_OPEN_REMOTE_UNIX) { > > transport = trans_unix; > > > > No idea what it should be doing? :-) > > That means if you don't specify a server / transport, it'll try to use > the local libvirtd daemon. ie, it supports qemu:///system URIs > So this is the correct thing to be doing, but the open question is why > it would hang. If libvirtd isn't running locally it should give you > back an immediate rejection / failure, not hang in read. libvirtd is running locally.. This is libvirtd opening the socket a second time and trying to talk to itself.