Bug 608485 - no eth0 after switch NIC
Summary: no eth0 after switch NIC
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Virtualization Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-27 19:04 UTC by Qian Cai
Modified: 2010-06-28 03:28 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-06-28 03:28:44 UTC

Attachments (Terms of Use)
guest xml (2.15 KB, application/xml)
2010-06-27 19:04 UTC, Qian Cai
no flags Details

Description Qian Cai 2010-06-27 19:04:52 UTC
Created attachment 427254 [details]
guest xml

Description of problem:
I have just realized after upgraded the system, if changed the guest NIC (from virt-manager), the eth0 was gone.

# cat /var/log/dmesg
udev: starting version 147
piix4_smbus 0000:00:01.3: SMBus Host Controller at 0xb100, revision 0
8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
8139cp 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, high) -> IRQ 11
eth0: RTL-8139C+ at 0xffffc90000d0a000, 52:54:00:73:74:a8, IRQ 11
8139cp 0000:00:04.0: setting latency timer to 64
8139too Fast Ethernet driver 0.9.28
udev: renamed network interface eth0 to eth3
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11

# cat /etc/udev/rules.d/70-persistent-net.rules

# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
# You can modify it, as long as you keep each rule on a single line.

# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rule written by anaconda)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:e4:21:bf", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# net device ()
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:b8:79:a5", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10ec:0x8139 (8139cp)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:12:a5:1b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x10ec:0x8139 (8139cp)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:73:74:a8", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

Version-Release number of selected component (if applicable):
host & guest (x86_64):

How reproducible:

Steps to Reproduce:
1. changed guest NIC (via virt-manager)
Actual results:
no eth0

Expected results:
have eth0

Comment 1 RHEL Product and Program Management 2010-06-27 19:22:55 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 2 Alex Williamson 2010-06-28 02:47:46 UTC
I'm not sure I understand the problem.  The guest xml lists a nic:

    <interface type='network'>
      <mac address='52:54:00:73:74:a8'/>
      <source network='default'/>
      <target dev='vnet0'/>
      <model type='rtl8139'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>

Which matches the eth3 entry in the persistent udev file, and we can see in dmesg that udev renamed eth0 to eth3.  If you're expecting the nic to show up as eth0, you'd at least need to change the mac address to 52:54:00:e4:21:bf.  What exactly was changed about the nic in virt manager and why should it still be expected to be eth0?

Comment 3 Qian Cai 2010-06-28 03:28:44 UTC
Thanks for pointing out. I was stupid.

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