Re: [Libvir] FYI: bug in remote code

On Tue, Oct 16, 2007 at 03:29:26PM -0400, Mark Johnson wrote: > > > > 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. Oh of course. The Xen driver only provides the core VM apis. The networking APIs are provided by the QEMU driver impl & re-used by the Xen driver. This means that the QEMU driver is called indirectly whenever using the Xen driver. So if you want any of the networking APIs to work, you need to have the QEMU driver enabled. That said, it should still not call itself recursively when the QEMU driver is disabled, so I'll try & figure that out. The long term solution is probably to properly separate the QEMU vm vs network driver so we can have the latter without the former.