Description of problem: As of the 5.3 update any 5.3 guest installs end up picking up two network cards instead of the single network card specified in the configuration files as specified in /etc/xen/system-name. The 8192 module picks up eth0 The xen netfront picks up eth1 Both of these devices have the same MAC address, As only one of them is "up" at run time, (until you attempt to bring it up). As these both have the same MAC address this can do really odd things for networking. Customers may rely on eth0/eth1 being present in the post 5.3 release, but I don't think they can rely on them -both- as its not sane to use both of them with one single mac address. What is the best line of attack to bring this problem back to a sane resolution for 5.4 ? Steps to Reproduce: 1. Install 5.3 Server 2. Install 5.3 guest, specify a single NIC 3. reboot after install. Actual results: The eth0 and eth1 are available. Expected results: eth0 claimed by either the xen netfront or the 8192 driver, but not two ethernet devices. Additional info: I'm not sure where to go from here, if I invest time in fixing the bug, it will change expected behavior. If I change a NIC MAC address that would also be wrong. What options do we have ?
This seems to have happened because of the paravirt-drivers included with the kernel. To fix the problem, either configure the system to use the xen-vnif driver by replacing the 'alias eth0 8139cp' with the following line in /etc/modprobe.conf alias eth0 xen-vnif or disable the xen-vnif driver with the following line in /etc/modprobe.conf blacklist xen-vnif
To add on to comment #2, you can also blacklist 8139cp & 8139too if you want the xen-vnif as the networking device as well.
You should be able to disable the rtl8139 network interface by using "type=pv" in your guest's configuration file instead of "type=ioemu". Removing "type=ioemu" doesn't help as ioemu is the default type.
So I guess we could implement something similar to <model type="virtio"/> used for qemu/kvm. That is, for xen the configuration could look like: <interface ...> ... <mode type="xenpv"/> </interface> this would disable the emulated network device. It should be fairly simple to implement. I just need to check upstream how the handle vif device type. In RHEL, everything except "ioemu" disables the emulated device.
Created attachment 375021 [details] Support for interface model netfront
Created attachment 375023 [details] Tests for interface type model configuration
Patches sent upstream as https://www.redhat.com/archives/libvir-list/2009-November/msg00778.html https://www.redhat.com/archives/libvir-list/2009-November/msg00779.html https://www.redhat.com/archives/libvir-list/2009-November/msg00780.html Also in virtualist as http://post-office.corp.redhat.com/archives/virtualist/2009-December/msg00012.html http://post-office.corp.redhat.com/archives/virtualist/2009-December/msg00013.html http://post-office.corp.redhat.com/archives/virtualist/2009-December/msg00014.html
libvirt-0.6.3-24.el5 has been built in dist-5E-qu-candidate with the fixes Daniel
The bugs has been fixed on libvirt-0.6.3-28.el5 Steps: 1, install a rhel5.4 guest on rhel5.4 host(virt-install or virt-manager) 2, boot up the rhel5u4 guest after install 3, check the NIC infor using "ip link show" as follows: # ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:16:36:66:a2:15 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 00:16:36:66:a2:15 brd ff:ff:ff:ff:ff:ff 4: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 4, then, shutdown the guest and dump xml definition of the guest, add "<model type='netfront'/>" into the NIC section of domain xml description: ... <interface type='bridge'> <mac address='00:16:36:66:a2:15'/> <source bridge='xenbr0'/> <script path='vif-bridge'/> <model type='netfront'/> </interface> ... 5, redefine the domain description and boot the guest to check NIC infor: # ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:16:36:66:a2:15 brd ff:ff:ff:ff:ff:ff 3: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 6, check the config file under /etc/xen foler: ... disk = [ "file:/var/lib/xen/images/rhel5u4.img,hda,w", ",hdc:cdrom,r" ] vif = [ "mac=00:16:36:66:a2:15,bridge=xenbr0,script=vif-bridge,type=netfront" ] parallel = "none" serial = "pty" ...
Event posted on 03-03-2010 11:54am EST by Glen Johnson ------- Comment From zorek.com 2010-03-03 11:45 EDT------- Tester reports this is resolved with 5.5 snap2 and can be closed out. This event sent from IssueTracker by jkachuck issue 247222
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0205.html