On Tue, Oct 16, 2007 at 08:32:54PM +0100, Daniel P. Berrange wrote:
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.
Try this patch.... Basically when running inside the libvirt daemon there is an extra set of drivers that are invoked for 'stateful' startup. This patch implements this driver API for the remote driver setting a global flag to disable itself. This ensures the remote driver is only activated when used outside the daemon Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|