How to Perform an In-Place Upgrade when Using Kernel-Assigned NIC Names
Environment
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 8
- Red Hat Enterprise Linux 9
- leapp
Issue
- In-place upgrade process is inhibited when the Leapp upgrade tool detects presence of any Network Interface Card (NIC) with a name based on the the kernel-assigned prefix (eth) if multiple NICs exist on the system (ignoring virtual NICs). Stability of such names can not be guaranteed, and the system would likely lose network connectivity after the upgrade.
Resolution
To prepare the system for an in-place upgrade, you must migrate it to another naming scheme.
To do so, you can apply:
- A naming scheme provided by systemd-udev (see [1] for more details)
- Your own interface names
Red Hat suggests to use your own naming scheme, because having sensible NIC names on machines with multiple interfaces can also simplify the system administration and maintenance.
Use either the manual method or Ansible-based method to migrate to the new naming scheme.
Manual method
You can implement your own name scheme using udev rules, as shown in the example below:
- Create a udev rules file in the /etc/udev/rules.d/ directory, such as /etc/udev/rules.d/10-persistent.rules
# MAC address match. Will name the device with the specified MAC address the value given in the NAME property:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{type}=="1", KERNEL=="*", NAME="my_nic_2"
You can see this article for more information on how to assign a specific interface name
To make sure that interfaces have the correct names during the early boot phase, include the udev rules to an initrd image:
# mkdir -p /etc/dracut.conf.d
# echo install_items+=\" /etc/udev/rules.d/10-persistent.rules \" > /etc/dracut.conf.d/include-nic-names-rules.conf
# dracut -f
On the following kernel upgrade, the rules will be included to the initrd image automatically.
If the old interface names were embedded in both local configuration files (ifcfg-* files, NetworkManager configuration, firewalld configuration, iptables rules) and remote configuration, such as playbooks stored in Ansible Tower, you must migrate them to account for the new names.
IMPORTANT After making the above changes, reboot the system and then check the output of # ip a to verify the NIC names have changed to the new prefix.
[1] Consistent Network Device Naming
Ansible-based method
The 4067471_predictable-nics.yml attachment is a playbook that migrates all NICs with the eth prefix to a new naming scheme. The playbook includes the following operations:
- Adds a udev rules file with the new NIC name to MAC address assignments
- Renames and updates all
ethdevice files to the new NIC naming scheme - Renames and updates all
ethroute files to the new NIC naming scheme - Performs a final regex on all
ifcfg-*files to convert anyethdevices to the new naming scheme
The 4067471_predictable-nics.yml playbook accommodates most networking scenarios that use Ethernet devices, bridges, and bonds. If your environment requires additional configuration beyond these device types, follow these recommendations before proceeding:
- Test the playbook on a system with a similar networking configuration to production systems
- Modify the playbook to accommodate renaming the eth prefix within the configuration of other device types
- Check the networking configuration of your systems after you run the playbook
To use this playbook, download the attached playbook to your Ansible control host (saving it as 4067471_predictable-nics.yml) and run the playbook against an inventory of your hosts:
$ ansible-playbook -i ~/inventory 4067471_predictable-nics.yml
The playbook renamed eth interfaces to em by default. To use different source and destination names, use the src_prefix and dst_prefix variables when running the playbook:
$ ansible-playbook -i ~/inventory -e dst_prefix="mynic" 4067471_predictable-nics.yml
When the playbook completes its tasks, reboot your systems and check that the NICs on each system use the new naming scheme.
Root Cause
Due to changes in udev between in RHEL 7 the use of unpredictable kernel-assigned NIC names on systems with multiple NICs is not considered safe by Red Hat on Red Hat Enterprise Linux 7 and newer, as it it no longer possible to guarantee persistant interface names across reboots. This is true even if interfaces load in the correct order in reboot in some instances, as the problem can potentially occur on any reboot but is not guaranteed to do so. For more on this issue, please see the following pages:
Diagnostic Steps
To determine whether the upgrade will be inhibited due to NIC naming, run this shell script:
$ [ $(ip link | egrep '^[0-9]+: eth[0-9]+:' | wc -l) -ge 1 ] && [ $(readlink /sys/class/net/* | grep -v '/virtual/' | wc -l) -ge 2 ] && echo 'In-place upgrade will be inhibited!'
leapp pre-upgrade outputs following messages.
Risk Factor: high (inhibitor)
Title: Unsupported network configuration
Summary: Detected multiple physical network interfaces where one or more use kernel naming (e.g. eth0). Upgrade process can not continue because stability of names can not be guaranteed. Please read the article at https://access.redhat.com/solutions/4067471 for more information.
Related links:
- How to perform an in-place upgrade to RHEL 8 when using kernel NIC names on RHEL 7: https://access.redhat.com/solutions/4067471
- RHEL 8 to RHEL 9: inplace upgrade fails at "Network configuration for unsupported device types detected": https://access.redhat.com/solutions/7009239
Remediation: [hint] Rename all ethX network interfaces following the attached KB solution article.
Key: d3050d265759a79ce895e64f45e9c56e49b3a953
Attachments
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments