Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
The rhev-h node will lost network configuration after upgrade due to the
new integrated biosdevname.
Usually, the udev recognizes the ethernet nic as ethX, but the
biosdevname will recognize it as emX, p0pX, then the original network
configuration, such as ip, up/down status, won't be effective.
Version-Release number of selected component (if applicable):
rhev-hypervisor6-6.3-20120516.0.el6
How reproducible:
100%
Steps to Reproduce:
1. install an old(older than rhev-hypervisor6-6.3-20120516.0.el6) rhev-h
to the machine
2. boot the installed rhev-h and configure the network, register to
rhev-m and so on
3. upgrade the rhev-h to latest version
rhev-hypervisor6-6.3-20120516.0.el6 via TUI or cmdline
4. boot the upgraded rhev-h, check the network
Actual results:
The ethernet nic will be recognize as em1, p0pX and so on, and the nic
is down. The connection between rhev-h and rhev-m will be lost.
Expected results:
The ethernet nic should be up, the rhevm bridge ip the connection
between rhev-h and rhev-m remain after upgrade
Additional info:
This is due to biosdevname fix. We need to handle this during upgrade.
Options:
1. somehow block biosdevname from being used on upgraded machines
2. migrate data during upgrade
Note for option 2: This is probably the *right* solution, but we have to be careful that we can fall back to the old scripts if upgrade fails for some reason.
For upgrade of snap3 -> snap5 or any 6.2 version -> snap5, it successes with some machines, such as Dell R510 and Dell optiplex 990, while it also fails with HP 8200E MT and intel-5550-12-2 in lab. The nics of the successful machines are renamed as emX or pXpY, while the nics of the failed machines are still named as ethX.
I also reproduced the bug on my lenovo machine, upgrade from 6.2 GA build (6.2-20111117) to 6.3-20120523.1 in rhevm:
1. after upgrade and reboot, network is not connected and report failed to establish libvirt connection. check the /etc/sysconfig/networking-scripts/, can see both ifcfg-em1, ifcfg-eth0 etc.
ls ifcfg-*
ifcfg-em1 ifcfg-eth1 ifcfg-lo ifcfg-p3p1
ifcfg-eth0 ifcfg-eth2 ifcfg-p2p1 ifcfg-rhevm
2. reboot one more time, check the /etc/sysconfig/networking-scripts/, cannot see ifcfg-ethX now,
$ls /etc/sysconfig/network-scripts/ifcfg-*
/etc/sysconfig/network-scripts/ifcfg-em1
/etc/sysconfig/network-scripts/ifcfg-lo
/etc/sysconfig/network-scripts/ifcfg-p2p1
/etc/sysconfig/network-scripts/ifcfg-p3p1
/etc/sysconfig/network-scripts/ifcfg-rhevm
$ls /sys/class/net/
bond0 bond1 bond2 bond3 bond4 bonding_masters
eth0 eth1 eth2 lo rhevm
under /sys/class/net, can see ethX, but cannot see emX, so the renamed device is not existed, that should be the reason the network cannot up.
3.service network restart
will get error Device em1 does not seem to be present.
Actually do local clean install, the network device did not rename to emX, don't know why upgrade will rename the device name and which cause the network failed up.
Created attachment 587582[details]
ovirt.log
(In reply to comment #16)
> The console keeps hanging on this machine for me, can you save
> /var/log/ovirt.log to a flash drive for me and attach to the bz or some
> other method. Also output of biosdevname would be helpful.
>
> If you need to get the network up on the machine you can. rm -rf
> /config/etc/sysconfig/network-scripts, reboot, setup the network again, just
> make sure to save /var/log/ovirt.log and all the
> /etc/sysconfig/network-scripts to /config by copying rather than persisting.
Attach ovirt.log and biosdevname output:
$biosdevname -i eth0
em1
$biosdevname -i eth1
p2p1
$biosdevname -i eth2
p3p1
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2012-0741.html