Bug 608485 - no eth0 after switch NIC
no eth0 after switch NIC
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.0
All Linux
low Severity high
: rc
: ---
Assigned To: Virtualization Maintenance
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-27 15:04 EDT by CAI Qian
Modified: 2010-06-27 23:28 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-27 23:28:44 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)
guest xml (2.15 KB, application/xml)
2010-06-27 15:04 EDT, CAI Qian
no flags Details

  None (edit)
Description CAI Qian 2010-06-27 15:04:52 EDT
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):
kernel-2.6.32-37.el6
virt-manager-0.8.4-5.el6.noarch
libvirt-0.8.1-9.el6.x86_64
qemu-kvm-0.12.1.2-2.78.el6.x86_64
udev-147-2.18.el6.x86_64

How reproducible:
always

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 15:22:55 EDT
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
inclusion.
Comment 2 Alex Williamson 2010-06-27 22:47:46 EDT
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'/>
    </interface>

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 CAI Qian 2010-06-27 23:28:44 EDT
Thanks for pointing out. I was stupid.

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