[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] FYI: bug in remote code



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  -=| 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]