Re: [Libvir] FYI: bug in remote code
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.
I reproduced it on todays CVS bits on FC7 by commenting out
qemu's
network register..
int qemudRegister(void) {
virRegisterDriver(&qemuDriver);
/* virRegisterNetworkDriver(&qemuNetworkDriver); */
virRegisterStateDriver(&qemuStateDriver);
return 0;
}
I'll give that a try.
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 -=|