Reply to post: Predictable names

You love Systemd – you just don't know it yet, wink Red Hat bods

Dazed and Confused

Predictable names

It renamed network interfaces so they would have predictable names.

Hmmmm nice idea, but that's not how it works in practice and I'm not sure this is a core systemd feature. The new naming conventions in RHEL7 don't work in all cases. It has 5 different naming schemes or which it only uses 4 by default.

Firstly it tries to find out whether a network device is an "onboard" one, and looks in 2 different places to make this decision.

Secondly it looks to see whether the NIC is in a named PCI slot, well again there are 2 different places it seems to look, one of which doesn't appear to be readable from the files under /sys, at least not with any of the NIC drivers I've ever tried. Great if you can read it from SMBIOS, not otherwise.

Failing those it then looks to see if the driver is a PCI one and then uses the PCI address, well these aren't natively persistent nor are they consistent. Persistence can be requested from the firmware configuration, but it often isn't enabled by default.

Failing all that it just uses the kernels non persistent & non consistent naming without the benefit of udev rules to provide persistence. Given the asynchronous driver initialization in the Linux 3 & 4 kernels this is particularly bad as if you've got 2 different sorts of NICs then it's anyone's guess which one with get to be eth0 before systemd starts to play it's games.

Now if you run this lot inside a VM then virtio drivers for KVM don't provide the identifiers used by schemes 1 & 2 and they're not PCI to scheme 3 is out too. Scheme 4 is never used by default so we drop through to the kernel names. If you also have emulated NICs in you VM and you've got random naming for your network cards.

The situation with VMWare is just as bad, if not worse. It doesn't provide persistent or even sensible onboard device numbers or you end up with name for you NICS like eno167654321 (something over 2^24). So they put a kludge in the systemd code to spot the ridiculous onboard device numbers and then drop through to scheme 2, but the version of SMBIOS emulated does allow the slot numbers to be pulled from the type 9 records and the field that is used can't be read from /sys and doesn't seem to be consistent, so I can't find a way to know in advance what a NIC will be called so how the *&^% am I supposed to write kickstart files for these things?

And all of this has nothing to do with the job of PID 1, which is the orphan catcher, without which the kernel will die.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon