Bug 483884 - Xen 5.3 guests in 5.3 host present two NIC with duplicate MAC addresses, only one configured.
Xen 5.3 guests in 5.3 host present two NIC with duplicate MAC addresses, only...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libvirt (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Jiri Denemark
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-04 00:09 EST by Wade Mealing
Modified: 2011-01-24 18:41 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-30 04:10:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Support for interface model netfront (5.93 KB, patch)
2009-12-01 05:55 EST, Jiri Denemark
no flags Details | Diff
Tests for interface type model configuration (16.18 KB, patch)
2009-12-01 05:56 EST, Jiri Denemark
no flags Details | Diff

  None (edit)
Description Wade Mealing 2009-02-04 00:09:56 EST
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 ?
Comment 1 Sachin Prabhu 2009-04-15 07:14:50 EDT
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
Comment 7 Don Dutile 2009-11-02 17:04:38 EST
To add on to comment #2,
you can also blacklist 8139cp & 8139too if 
you want the xen-vnif as the networking device as well.
Comment 8 Jiri Denemark 2009-11-20 03:18:02 EST
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.
Comment 9 Jiri Denemark 2009-11-20 03:48:17 EST
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.
Comment 10 Jiri Denemark 2009-12-01 05:55:54 EST
Created attachment 375021 [details]
Support for interface model netfront
Comment 11 Jiri Denemark 2009-12-01 05:56:54 EST
Created attachment 375023 [details]
Tests for interface type model configuration
Comment 13 Daniel Veillard 2009-12-10 05:59:15 EST
libvirt-0.6.3-24.el5 has been built in dist-5E-qu-candidate with the fixes

Daniel
Comment 15 Gunannan Ren 2010-01-07 04:07:04 EST
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"
...
Comment 20 Issue Tracker 2010-03-08 11:52:39 EST
Event posted on 03-03-2010 11:54am EST by Glen Johnson

------- Comment From zorek@us.ibm.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
Comment 22 errata-xmlrpc 2010-03-30 04:10:50 EDT
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

Note You need to log in before you can comment on or make changes to this bug.