Re: Proposal: enable stateless persistant network interface names
On Sat, May 09, 2015 at 11:26:14AM +0200, Martin Pitt wrote:
> Bjørn Mork [2015-05-08 16:13 +0200]:
> > PCI buses can be and are hotplugged, similar to network devices.
>
> Yes, that's certainly a valid point. It's not unanimously clear how
> you define the "identity" of an interface, whether it's more like "by
> location" or "by MAC address". There are pros and cons for either POV.
>
> Karsten Merker [2015-05-08 18:31 +0200]:
> > while this probably works resonably well for (semi-)fixed devices
> > like onboard-NICs and PCI/PCIe cards, it results in a completely
> > unsuitable behaviour with pluggable devices such as USB network
> > adapters.
>
> TBH, hotpluggable USB network adapters which change all the time sound
> like a corner case in a server world where you have hand-written
> config files referring to interface names. They are of course common
> on the client side, but there stable interface names don't matter at
> all.
I am sorry but I have to disagree. IMHO stable interface names do
matter on clients - I have not yet seen any proof to the contrary.
Yes, there are some simple setups in which one can get along
without them, but introducing a new naming scheme that breaks
existing setups and fully legit use-cases by only taking simple
setups into account appears simply wrong to me.
> But see below.
>
> peter green [2015-05-09 8:49 +0100]:
> > The "path based names" use the PCI bus number as their "root". PCI bus
> > numbers are dynamically allocated as the bios enumerates the busses.
>
> PCI bus and slot numbers are stable across reboots, unless of course
> you physically change the cards (what Bjørn raised above).
As Peter Green has described in <[🔎] 554DBC0F.3070405@p10link.net>
this assumption appears to be false at least on some laptops with
dual graphics, where simply enabling the "high power" graphics
chip in the BIOS can change the bus numbering.
> But what I do want to get rid of is the current
> 70-persistent-net-names.rules which have the inherent race condition
> and have no configurability at all; and it provides no stable
> interface names for any virtualized environment.
>From what Ben Hutchings has described in
<[🔎] 1431294933.2233.66.camel@decadent.org.uk>, the race condition
could easily be avoided with the current codebase by simply not
using "eth" as the prefix, but e.g. "en".
Could you explain why the existing code does not provide stable
names in virtual machines? As long as the virtual ethernet
controller keeps the same MAC address over time (which I believe
to be the normal case), I see no reason why the existing codebase
should not provide stable names in a VM in the same way it does
on physical hardware.
> With ifnames you can always choose your own policy (see man
> systemd.link), and e. g. say "NamePolicy=onboard mac" if you so
> prefer. We can even discuss preferring "mac" over "slot" by default
> (although I personally think that would be a worse default).
> One could even default to "mac" for USB based hardware and the default
> (kernel database onboard slot path) for others [1].
As "slot" has been shown to be not really stable for a number of
use cases (even for PCI, see above), I think that "mac" is the
only way that works for all cases.
> [1] I don't have USB-ethernet devices myself; if you have one, please
> get in touch with me, I'd like to investigate how they look like in
> udev, and what "udevadm test /sys/class/net/<iface> |grep NAME" says
> about these.
Directly plugged into a host port:
ID_NET_NAME_MAC=enx00606e123456
ID_NET_NAME_PATH=enp0s19f2u6
Plugged into a hub plugged into the same host port:
ID_NET_NAME_MAC=enx00606e123456
ID_NET_NAME_PATH=enp0s19f2u6u2
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
Reply to: