Re: [Xen-users] Re: network-bridge fails leaving tmpbridge around

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Fri, May 11, 2007 at 03:53:17PM +0200, Weismueller, Jonas wrote:
> Daniel P. Berrange wrote:
> >On Fri, May 11, 2007 at 03:28:48PM +0200, Weismueller, Jonas wrote:
> >  
> >>Richard W.M. Jones wrote:
> >>    
> >>>Richard W.M. Jones wrote:
> >>>      
> >>>>One thing that's a bit strange is the sudden presence of virbr0.  I 
> >>>>don't understand where it comes from.  Note: there is no libvirtd or 
> >>>>qemu running on this machine.
> >>>>        
> >>>Turns out that the mysterious presence of virbr0 was the clue.  Doing:
> >>>
> >>> rm -r /var/lib/xend/state
> >>>      
> >>I've got the same problem. Removing the state directory didn't solve my 
> >>problem. Some output of ifconfig, route, brctl is attached to the mail
> >>    
> >
> >Actually re-reading your logs attached the prescence of 'virbr0' is OK
> >in your case - it was there before starting xend, so should be there
> >after.
> >  
> I already turned of xend in runlevel 5 for the ouput of before. Then I 
> did /etc/init.d/xend start and created the after output. Where does the 
> virbbr0 bridge comes from?

That is a libvirt managed network device - created by libvirtd init script.
You can try turning off the libvirtd initscript temporarily, but I don't
think it will help in this case.

> >Can you try something slightly different.
> >
> > - Turn off xend service so it doesn't start upon boot
> > - Reboot
> > - Run '/etc/xen/scripts/network-bridge start' manually
> >  
> This doesn't work. It results in the attached output.

So the key error message is:

      SIOCSIFNAME: Device or resource busy

Looking at the kernel source -EBUSY is returned based on

        if (dev->flags & IFF_UP)
                return -EBUSY;

And looking at your ifconfig output, tmpbridge is indeed UP

> tmpbridge Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
>           inet addr:172.16.135.156  Bcast:172.16.255.255  Mask:255.255.0.0
>           UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0 
>           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

But given the place in the network-bridge scrpit where you say it is failing,
the tmpbridge device has not been brought up yet, so I've no clue how it
got into that state.

As a nasty hack you can try changing op_start method from

    ip link set ${netdev} name ${pdev}
    ip link set ${tdev} name ${bridge}

To

    ip link set ${netdev} name ${pdev}
    ip link set ${tdev} link down
    ip link set ${tdev} name ${bridge}

But I'd really like to know why it was in the UP state at all. So it'd
be useful if you could edit op_start and put in a call 'ifconfig ${tdev}'
and "echo doing stage ...blah..." in between every step in op_start() to 
see just where it gets into the UP state

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

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users