Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Kay Sievers]

On Wed, Jan 23, 2013 at 10:54 PM, Bill Nottingham <notting at redhat.com> wrote:
> Matthew Miller (mattdm at fedoraproject.org) said:
>> On Wed, Jan 23, 2013 at 07:59:07PM +0000, Jaroslav Reznik wrote:
>> > The udevd service has a long history of providing predicatable names for
>> > block devices and others. For Fedora 19 we'd like to provide the same for
>> > network interfaces, following a similar naming scheme, but only as
>> > fallback if not other solution such as biosdevname is installed or the
>> > administrator manually defined network interface names via udev rules or
>> > the old network scripts.
>> [...]
>> > This feature is about enabling this as default in Fedora, but only as a
>> > fallback if the user/administrator did not manually assign names to interfaces
>> > via udev rules, or via the old networking scripts, or if biosdevname is
>> > installed.
>>
>> This seems to invent yet another new naming scheme. We just went through
>> this pain, and the biosdevname scheme went through several iterations in the
>> field and represents real-world lessons learned. Is there a compelling
>> reason to make the systemd/udev policy for Fedora not just follow the
>> existing solution to the same problem embodied in biosdevname? (Then, we
>> could just phase out biosdevname.)
>
> biosdevname naming isn't apparently consistent across versions.
> https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21
>
> The problems are roughly this:
> - biosdevname only provides predictable naming for machines with SMBIOS
>   type 9 & type 41 records
> - For other machines, it does 'best effort' based off of heuristics and
>   attempting to enumerate all the devices... which gives weird/unpredictable
>   results.
>
> This code has the benefit of:
> - covering more device types (not just BIOSes with type 9 & type 41)
> - not attempting to do heuristics that name devices via enumeration
>
> However, it does have the large disadvantage of changing the namespace used.

That's certainly right. Here is a bit of the background that lead us here:

Udev had the facility to try to keep the ethX names by writing out
things to disk from the hotplug path. Looking back at it, it was a big
mistake to ever even try this; it created far more problems than it
has solved. People with virtualization or random MAC addresses ended
up with 1000s of entries, one new for every reboot; in complex setups
the renaming of interfaces in the kernel's namespace raced against the
kernel creating new interfaces, ending up in device names like
rename14, ..., and all these problems. That facility needed to die,
that we are absolutely sure about.

Now biosdevname was the envisioned future, it provided nice short
names, based of static firmware properties or the physical path.

So, that was the plan, but as soon as we started looking at the
internals, it was not that convincing anymore. Biosdevname initially
came up with the physical naming, but to accomplish the goal of "nice"
names it enumerates the entire system and sometimes invents its own
"pretty" numbers based on the *overall* view of the system.

A model like that isn't really feasible for upstream udev, udev
intentionally wants to be dumb and strictly prefers device-*local*
views, and accepts possibly "uglier" hardware-provided properties,
instead of "inventing" less reliable new "pretty" numbers.

We had no better idea really, than to copy the successful model we do
for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was
a well-known scheme, but it was certainly not know for network devices
so far. So we picked up the basic ideas from biosdevname and combined
them with the proven scheme we do for all other subsystems in udev.
This necessarily lead to different names, but from udev's point of
view they are entirely justified.

We will certainly never win a price for the prettiest names with what
we do in udev now, but unlike the earlier solutions, it should be very
simple, reliable and predictable. Just looking at 'lspci' will in most
cases tell you what the name of the network interface will be.

Thanks,
Kay