Description of problem:
We have a rack of PXE-booted servers that use a .link files for persistent naming of interfaces. It appears that udev successfully renames the interfaces, but systemd-networkd later renames them again using the default systemd naming scheme.
Version-Release number of selected component (if applicable):
On every boot.
Steps to Reproduce:
1. Provide .network file to configure interface via DHCP
2. Provide .link file to rename interface
3. Reboot system
Interface(s) have names of form enp1s0f* after systemd-networkd starts, but eth* beforehand.
Udev should rename interfaces to have persistent eth* names, based on the value of ID_PATH.
The output of "udevadm info /sys/class/net/enp1s0f0" shows that ID_NET_PATH=eth0, as expected. However, the system isn't using that name. It also shows ID_NET_LINK_FILE=/etc/systemd/network/10-rename-eth0.link.
The output of "journalctl -u systemd-networkd" shows:
eth0: renamed to enp1s0f0
eth1: renamed to enp1s0f1
Why is systemd-networkd renaming the interfaces? Isn't that supposed to be handled by udev earlier in the boot process?
Running "journalctl -u systemd-udevd" doesn't show anything about network interface renaming, but it appears to be working, until systemd-networkd later overrides it.
rebooting it again, "journalctl -u systemd-networkd" shows:
enp1s0f0: renamed to eth0
enp4s0: renamed to eth1
enp1s0f1: renamed to eth2
eth0: renamed to enp1s0f0
eth1: renamed to enp4s0
ent2: renamed to enp1s0f0
I have no idea what's going on here.
Using a rule file in /etc/udev/rules.d, instead of link files, boots correctly most of the time, but every few boots the rules are ignored and the names get switched around. So maybe the rules were never used to begin with, it's just ended up correct by chance.
This is not the message that networkd renamed that device, that is a message that the device was renamed and networkd got a notification from kernel.
Please do *not* use kernel names. We do not support persistent eth names.
Unfortunately, that's not my prerogative. We only support a much larger RHEL consumer that does use them, and we need to match their environment.
The procedure for doing this is still documented, so I assumed it was still supported.
However, as creating a custom udev rule doesn't work consistently, I'm trying to do it using networkd link files instead. So what you're saying then, is that this functionality of systemd is unsupported in RHEL 7?
If you want to use kernel names, then just specify net.ifnames=0 on kernel cmdline, but you need to leave the interface the name that it got from kernel.
Swapping the kernel names by udev was always broken and it is really not supported.
By the way renaming with the link files is also done by udev, which reads them, but we don't include rule for that in supported rhel packages.
The .link files don't work no matter what name I give the interface. I tried elink0 instead of eth0. ID_NET_NAME gets set, but the interface still uses the systemd name.
It matches using the value of ID_PATH, which doesn't seem to be set early enough. Even reverting back to the udev rules file, and using ID_PATH, I get an "unknown key ID_PATH" error in the output of "journalctl -u systemd-udevd".
So it's seems that the link-file functionality is broken.
Here's the contents of my link file:
Can you please attach sos report from your machine.
Our security policy doesn't permit me to copy logs off of that machine. Is there anything in particular I should be looking for? I'm not sure what an sos report is.
I have a similar problem with devices that use the vmxnet3 driver (=on VMWare machines).
This is probably not the issue David had, but in case somebody sees this, with VMWare (vmxnet3 drivers) a systemd upgrade scriptlet creates /etc/udev/rules.d/90-eno-fix.rules. This was done to avoid loss of connection when matching on device names (both in NetworkManager and systemd-networkd). More here:
Still, you can't use systemd-networkd to change name on vmxnet3 devices.
Even if you leave [Match] empty, you at least get the error log that "lo" can't be renamed.
[root@identity ~]# cat /etc/systemd/network/00-cool.link
Feb 28 09:12:09 identity.example.com systemd-udevd: Error changing net interface name 'lo' to 'cool': Device or resource busy
Feb 28 09:12:09 identity.example.com systemd-udevd: could not rename interface '1' from 'lo' to 'cool': Device or resource busy
You don't get anything whatsoever about the vmxnet3 device, with or without precise matching.
This bugzilla should be closed as this is a support/configuration discussion and not a true bug report.
As of RHEL 7.3 systemd-networkd components are *not* currently shipped nor supported.
Consistent network naming, particularly with ethX style naming, is notoriously troublesome and the new network device naming in systemd is designed to correct that and requires users to adapt to the new naming conventions.
It is possible to revert back to old naming if you are willing to accept inconsistent device naming, and this process is well document. See the various links and reference explaining all in this blog post.
Future questions and configuration guidance should be filed via a support ticket, not bugzilla.
systemd-networkd *is* shipped in the RHEL 7 Optional channel, but that channel is for unsupported packages offered as a convenience to customers.
Regardless, the device naming questions are addressed outside of the scope and need for systemd-networkd and is addressed in the documentation and other KB articles in the support portal.