[Libvir] FYI: bug in remote code
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? :-) 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; } MRJ
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 -=|
On 10/16/07, Daniel P. Berrange <berrange@redhat.com> 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. MRJ
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 -=|
On Tue, Oct 16, 2007 at 03:29:26PM -0400, Mark Johnson wrote:
On 10/16/07, Daniel P. Berrange <berrange@redhat.com> 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.
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. 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 -=|
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 -=|
participants (2)
-
Daniel P. Berrange -
Mark Johnson