Description of problem: When a bare metal host is converted from discovered to managed, the NIC identifiers change (in our case, from eno1-4 to em1-4). Satellite never gets the updated NIC identifier (host.interfaces has a list of interfaces, with identifiers eno1-4). One of our puppet modules requires the provisioning interface name as a parameter, but it is getting the wrong name because Satellite's list of interfaces does not match the actual interfaces on the machine. We tried provisioning a machine with the "Ignore Puppet facts for provisioning" set to true, but it had no effect. How reproducible: 100% (on our BM host) Steps to Reproduce: 1. Let a BM host with the discovery image get discovered by Satellite 2. Check the names of the NICs 3. Convert the host from discovered to managed and build it 4. After the build, check the names of the NICs 5. Run foreman-rake console on Satellite, find your host, and run host.identifiers Actual results: names of NICs after build != names of NICs in Satellite names of NICs when first disovered == names of NICs in Satellite Expected results: names of NICs after build == names of NICs in Satellite,
We do have a workaround for now.
Hello, the discovery image is based on RHEL 7.2. What version of RHEL your node was installed with? And have you turned off "predictable NIC names" feature via kernel command line with Anaconda? If this was turned off, we can't do much about it. You can turn it off also for your discovered hosts via kernel command line too.
em is for 'EMbedded ethernet' or 'Ethernet on Motherboard' depending where you read and is from one of the consistent network naming schemes. en is for 'EtherNet' and o for 'Onboard' and is from another naming scheme. As to why discovery gets something different from the OS: You don't have biosdevname installed on the Foreman Discovery image and we do on the OS. With consistent network names enabled and biosdevname installed and enabled I get em1. With consistent network names enabled and biosdevnames=0 or the biosdevname package uninstalled I get eno1. My initial instinct is that biosdevname should be on the discovery image and if people want to disable biosdevname then they can do biosdevname on the APPEND line for discovery in /var/lib/tftpboot/pxelinux.cfg/default and either not install it or set biosdevname=0 in grub via their kickstart, especially since the Satellite Kickstart Default ks installed biosdevname as part of @Core so people are basically condemned to this behavior by default.
Jason, thanks for analysis. This is indeed a bug, biosdevname was supposed to be installed. I thought it is part of the base installation and I thought "eno1" is actually the correct name, but you explained it here. We will fix this.
Upstream bug component is Discovery Plugin
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/16526 has been resolved.
From "Consistent Network Device Naming Using biosdevname"[1] in the RHEL7 Networking Guide Note that unless the system is a Dell system, or biosdevname is explicitly enabled as described in Section 8.6.2, “Enabling and Disabling the Feature”, the systemd naming scheme will take precedence. [1]https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html
Verified. Version Tested: Satellite-6.3 Snap 14 biosdevname is now in the list of packages through `yum list installed`
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. > > https://access.redhat.com/errata/RHSA-2018:0336