[CentOS-virt] xenbr0 isn't created anymore

[Kai Schaetzl]

Ross S. W. Walker wrote on Fri, 28 Mar 2008 09:44:44 -0400:

> Snooping around I found this in /etc/xen/qemu-ifup:

Interesting. That is the one from Xen 3.2 I suppose? It's not what I have 
here with the mint CentOS 5.1 Xen.

I just have:

echo 'config qemu network with xen bridge for ' $*


ifconfig $1 0.0.0.0 up

brctl addif $2 $1

That might be used like "qemu-ifup xenbr0 eth0" or so I guess. I don't know 
if it would work but it sure never gets run (or if it runs it doesn't 
work). There's no "config qemu network with xen bridge" in any of my logs, 
so I'd say it never runs. And it should never run as I'm not using qemu. It 
might indeed only be there for qemu to use.

> 
> #
> # Old style bridge setup with netloop, used to have a bridge name
> # of xenbrX, enslaving pethX and vif0.X, and then configuring
> # eth0.
> #
> # New style bridge setup does not use netloop, so the bridge name
> # is ethX and the physical device is enslaved pethX

Hm, but that sounds like what they do currently. peth0 is supposed to be 
the physical device. But the bridge name is not eth0. So, it might be 
indeed a new way. While doing research I saw a number of complaints about 
their current way of doing it and saw much easier ways. So maybe they 
changed it in this manner.

> #
> # So if...
> #
> #   - User asks for xenbrX
> #   - AND xenbrX doesn't exist
> #   - AND there is a ethX device which is a bridge
> #
> # ..then we translate xenbrX to ethX

That would probably cut it.

> Now I am not sure how the vif0.X and vethX interfaces fit into the
> picture here... Maybe these are no longer used?

Still there I would think, just that xenbr0 (after creation) bridges to 
eth0 and not peth0. I suppose. In ifconfig it will just look the same as 
before. I suppose. Again.

I found a cure for the problem yesterday evening. That bridge-network 
script is crap. It depends on certain output from "ip route list". What 
format do you get as the last line of a "ip route list"?

default via 192.168.1.1 dev eth0  src 192.168.1.231

or

default via 192.168.1.1 dev eth0

I get this appended src on any of my 5.1 setups but not on my 4.6 setups. I 
don't have a 5.0 for comparison handy. The date of the ip file is from 
March 2007, so I'd say it didn't get updated recently. But maybe some 
library that is involved in this got updated. As it used to work until some 
days ago either some update stopped it working or I somehow stopped the 
qemu-ifup (in case it ever really fixed this) from running or from running 
correctly. Or yet something else ...
This is so hard to troubleshoot because those scripts won't add any logging 
to the normal syslog. If at all logging goes to xend.log or xend-debug.log 
and doesn't have any date/time attached, so it's easily mistaken as an 
error that occurred from running the script manually (which I did often 
enough).

Here's the beginning of the code in network-bridge:

#vifnum=${vifnum:-$(ip route list | awk '/^default / { print $NF }' | sed 
's/^[^0-9]*//')}
vifnum=${vifnum:-0}
#bridge=${bridge:-xenbr${vifnum}}
bridge=xenbr0
#netdev=${netdev:-eth${vifnum}}
netdev=eth0
antispoof=${antispoof:-no}

I added the comments and the two lines that set bridge and netdev to fixed 
values. Now it works. Without this it would get "192.168.1.231" as $vifnum 
and try to use devices like eth192.168.1.231 and xenbr192.168.1.231. With 
the old output of "ip route list" it would grab "0" instead of 
"192.168.1.231" and thus use the correct interface names.
With this change I can now start and stop xend and it will take up and down 
the xenbr0 and connected devices correctly. Before it would just silently 
fail. (Or work for starting only once I killed eth0 as then it would take 
the default 0.)

Is this code still the same in your version of the script?
What's the output of the /etc/xen/scripts/network-bridge status? It should 
normally show the bridged devices and two layout versions of the routing 
table. Before the fix it was trying to display "eth192.168.1.231" and found 
that it doesn't exist, of course.

I'm tempted to try out the Xen 3.2. Is it what can be found at 
http://xen.org/download/? What makes me wary is this last paragraph on the 
readme:

> After installation of the binary packages, some adjustment to the
> bootloader (grub) configuration will probably be necessary.

What do they mean? It does not install a new kernel, doesn't it?

Did you notice any improvements with this package? I remember you wrote 
somewhere you can now run 32bit DomUs in a 64bit Dom0 stable. Anything 
else? Any disadvantages?



Kai

-- 
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.co