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