Re: Proposal v2: enable stateless persistant network interface names
[ sorry for replying late, I wasn't subscribed, but I read both threads
and I hope I got the In-Reply-To / References right ]
As someone with decent experience deploying RHEL/Centos and Debian on
anything from ARM boards, through x86 desktops/servers (HP/IBM/Dell),
IBM POWER, to IBM System Z (s390), I thought I'd share some thoughts.
Please stop calling ifnames "predictable" or "persistent", they are
neither - the logic upon which the name changes is different, but
that's it - in my experience, they're far less "persistent" than
static udev rules.
Also, don't assume everyone has access to a mouse to easily copy-paste
the 12-character interface names, things like z/VM (x3270 term) don't
even have screen clear support and typing the interface manually for the
tenth time is very ... CAPTCHA-like.
It doesn't matter how many excuses you make or how many managers you
layer on top, interface names are a *frontend* and critical for any
slightly complex network firewall setup (xtables/nftables) - think of
a multihomed 30-VLAN-using VM host with 64 bridges, various containers,
openvswitch, ... in a HA setup. You can't rely just on IP addresses and
rp_filter, using interface names also vastly simplifies things, not
mentioning ebtables.
About the actual persistence or which approach is the best - the thing
is that every setup is different. While the idea of biosdevname is nice
and it mostly works, there are cases where it doesn't, so it's
an invalid choice by design.
Amongst others:
* regular desktops are fine with PCI, BIOS or MAC addr
* x86/ppc servers you service - MAC addr (more stable on reboots or
network-unrelated hw changes)
* servers you don't - PCI or MAC addr (depending on the person
servicing it)
* USB NICs - MAC addr
* QEMU VMs - MAC addr (libvirt/cmdline assigns a static one)
or PCI (specified on cmdline or in libvirt XML)
* "containers" (Linux namespaces) - none (veth generates random MACs)
or MAC addr (depending on management software)
* simple ARM boards - MAC addr or none
* z/VM - qeth ccwgroup magic (ifnames: enccw0.0.4100)
* ...
It kind of becomes clear that any consensus on PCI bus/slot/function/dev
or MAC addr based numbering cannot be universally reached.
The "none" above means "don't mess with it" - leave the kernel specified
device name. This may sound crazy, but is actually the most universal
and in a lot of cases the most user-friendly thing to do, especially
on systems that change HW every time (live distros - "dhclient eth0"
is so much easier than ifnames) and/or systems that have just one NIC
(simple ARM boards, most VMs, most "containers", a lot of mass-deployed
virtual cluster nodes, ...).
In fact, I found that removing the generator when provisioning hundreds
of identical single-NIC virtual systems simplified things a lot - the
virtual hardware could be diverse & changed over time and "eth0" was
always "eth0" (no biosdevname-enforcing drivers, fortunately).
Which kind of leaves us where we are now (in Debian) - the best
persistence is achieved though udev rules, where you can even use
multiple rules per one interface name to express OR relationships,
with the generator creating a stable enough template until the sysadmin
changes the iface names.
None of the above is made impossible with ifnames, which are simply
a new default for device names, but my issue is that *they aren't any
better than the old system* in terms of persistence, they are actually
worse in my experience. If you want static /etc, sure, use
/var/lib/udev for the generated rules. If you find $setup with variable
MAC addresses, but some persistent property, you can at least use it in
the generator, whereas with ifnames, you don't (AFAIK) have much choice.
The usability issue is not in using some generator (and fixing the
race), but in the default names being *easy to use* for the user and
the rename an optional operation whereas with
enpff5d605a-c543-43fd-9777-0989f3879a2e it's pretty much mandatory.
Disk (filesystem) UUIDs worked, because people could still use
/dev/sda for fdisk.
Not denying that ifnames can be useful in some scenarios (I can imagine
a few), but should they be opt-out rather than opt-in?
If you decide to use ifnames as default, please at least make renaming
interfaces easier, like providing commented-out examples in the .rules
file (in /etc or /usr/share/doc).
Just my .. err, $2.
Thanks for reading.
Reply to: