RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 608485 - no eth0 after switch NIC
Summary: no eth0 after switch NIC
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2010-06-28 03:28:44 UTC
Target Upstream Version:
Embargoed:


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):
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 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
inclusion.

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'/>
    </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 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.