Red Hat Bugzilla – Bug 213991
xen networking doen't bring bridge up with xen 3.0.3
Last modified: 2008-02-26 18:38:46 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060930 Fedora/1.5.0.7-1.1.fc5.im Firefox/1.5.0.7 Description of problem: After upgrading FC5 to the current versions of kernel and xen, the virtual hosts finally start again. However, the networking does not work. brctl show xenbr0 8000.feffffffffff no peth3 vif0.0 vif2.0 vif2.1 if you run "ifconfig vif2.0 up", network starts working. In the dmesg file of the host I found: device vif2.0 entered promiscuous mode audit(1162642195.512:11): dev=vif2.0 prom=256 old_prom=0 auid=4294967295 ADDRCONF(NETDEV_UP): vif2.0: link is not ready xenbr0: port 3(vif2.0) entering disabled state That seems to be the problem. Version-Release number of selected component (if applicable): xen-3.0.3-1.fc5 kernel-2.6.18-1.2200.fc5 (xen0 and xenU) How reproducible: Always Steps to Reproduce: 1. update FC5 with all patches 2. start a xen client with bridged networking 3. look at dmesg Actual Results: networking does not work Expected Results: the bridge should pick up the topology changes (client interface coming up) and networking should work. It worked up to 2187 Additional info: Set prio to high because this breaks existing xen installations.
Created attachment 140350 [details] dmesg of the xen host
Created attachment 140351 [details] dmesg of the xen client
Do you have a network interface that uses a Broadcom chipset? I too had the same problem and i had to upgrade the firmware for my broadcom NIC. See the following thread that describes the problem. http://lists.xensource.com/archives/html/xen-users/2006-08/msg00553.html The following page (mywiki.ncsa.uiuc.edu was down at the time of writing this comment, hence google cache) described how to upgrade the firmware. http://72.14.253.104/search?q=cache:ZJlR5NbKrHIJ:mywiki.ncsa.uiuc.edu/wiki/Dell_PE1950_NIC_Firmware_Workaround+Dell_PE1950_NIC_Firmware_Workaround&hl=en&ct=clnk&cd=3 IBM had a patch released for the broadcom chipset which fixed this error for me.
No, I'm using Intel EEPro 100 cards. Actually the problem was that the networking config no longer detects reliably to which a card a bridge is connected. Adding the mac addresses explicitly now works. In my /etc/xen/auto/<host> I have vif = [ "mac=00:16:3e:3e:05:af,bridge=xenbr0", "mac=00:16:3e:3e:05:ae,bridge=xenbr1" ] and that works well. Without the mac=<xxx> parameters it does not. Seems to be more of a documentation issue than a real bug.
change QA contact
This report targets FC6, which is now end-of-life. Please re-test against Fedora 7 or later, and if the issue persists, open a new bug. Thanks