[systemd-devel] on the default for PredictableNetworkInterfaceNames

[Xen]

Martin Pitt schreef op 11-04-16 10:40:
> Reindl Harald [2016-04-10 17:44 +0200]:
>>> Because we had a mechanism for stable (but not predictable) interfaces
>>> names, the 75-persistent-net-generator.rules thingy. Without either,
>>> the first time you plugged in a second card/USB dongle/add an ibmveth
>>> etc., chaos would start.
>>
>> that worked perfectly
> 
> Hahahahno. :/
> 
> It had an inherent race condition of renaming devices to the same
> namespace than the kernel uses (thus creating collisions), and did not
> work at all in virtualized environments (see the long and ever-growing
> MAC blacklist).

So you can use a different namespace, and use hardware addresses right
(PCI bus etc.).

Even if you use BIOS device names you can get something stable even if
it is not "predictable".

> Apart from that it had several design problems: it was not predictable
> (names changed across reinstalls), prevented the ability of creating
> one OS image and installing it on many pieces of hardware (as the MAC
> addresses are device specific) and needed constant writability of
> /etc.

The predictability issue seems to be due to using a MAC address.

AFAIK a reinstall will not change PCI bus devices etc.

When you say "one OS image and installing it on many pieces of hardware"
you are apparently talking about identical hardware. That too is solved
by using a real hardware address.

What benefit has the "predictable" naming scheme when you consider:

1. It is going to be different from computer to computer
2. An enumeration scheme based on real hardware addresses will only
   change when hardware is removed/added (assuming for the moment
   adding usb dongles does not change "hard" components).

The only situation I can readily imagine is when someone repeatedly
plugs in 2 different networking devices and wants routing to be
different for each one of them.

In the scenario I describe you would not be able to have persistent
rules for these removable devices because they would be reordered or
might change order when plugging back in. (Then again, creating
persistent rules based on removable devices might be a pain anyway).

So where is the usage scheme where: having a persistent important
firewall or routing configuration agrees with a scenario of regularly
changing or adding/removing hardware in such a way the number of devices
actually change (most important scenario).