Hello,
On Sun, Apr 03, 2022 at 06:43:13PM -0400, Ian Kelling wrote:
> +1 for net.ifnames=0 by default. The "predictable names" are more
> complicated, and less predictable for Bitfolk customers.
Yep; the order of the network interfaces in a Xen guest is fixed by
the order defined in its config file so that will never change as
long as order is preserved there.
> I did a systemd upgrade on one machine and the "predictable name"
> changed. I was done with it after that.
Separating the issue of whether the idea is a good one in general,
from whether it makes sense for a BitFolk VM, as it's really only
the latter I wanted to talk about…
In theory you're only expected to see a change once, then the
interface has its new "predictable name", and it never changes
again.
This name should be based on the bus and slot it's on, so on most
machines it would be something like enp0s31f6 or wlp3s0. If it can't
work out the topology but knows what type it is then it might end up
being based on the MAC address like enxb03af2b6059f.
The problem it's trying to solve is that if you have more than one
network device then it's possible that they flip names even between
reboots when no change to system configuration or hardware setup has
happened. It mostly does solve that problem.
It does however introduce new problems, such as:
- The names it will pick are hard to predict the first time, so on
an upgrade that can be problematic.
- If you add hardware that has its own PCI bus this can reorder the
bus numbers that the kernel sees, which then renames all network
interfaces even though no network configuration change has
happened. It can be disturbing to plug in a USB device and then
have all interface names change at next boot.
If you only have the one network interface of a particular type,
like one Ethernet and/or one wifi, and don't expect to add more, I
think there is a strong argument for net.ifnames=0 because
"predictable naming" is trying to solve a problem that you don't
have.
> you can't reliably predict what the predictable name is going to
> be without actually booting systemd.
If you do have several network interfaces, or expect to, then you
might theoretically in future have the problem that "predictable
naming" is trying to solve. You could go with "predictable naming"
and hope for the best, or you could explicitly name your interfaces
using .link files. Then they will never be renamed again:
https://wiki.debian.org/NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES
The only thing I would add is that the example there isn't great as
it only matches on MAC address. If you add a bridge or VLAN
or bond etc interface it'll also have the same MAC address as the
"real" interface, so then udev will try to rename it as well,
causing havoc. You are best to also add a match on the type of
interface:
[Match]
MACAddress=01:23:45:67:89:ab
Type=ether
[Link]
Name=lan0
The various kinds of pseudo interfaces won't have Type=ether.
Going back to how this affects BitFolk…
A BitFolk VM also doesn't have the problem that "predictable naming"
is trying to solve, even if it has multiple network interfaces, so I
can see a strong argument for using net.ifnames=0 maybe even by
default.
At the moment the only downside I see is the divergence from
expected normal behaviour of a newly installed Debian bookworm /
Ubuntu 22.04 system. In the past we have actually had questions why
the network interface is still eth0, or if one needs to be careful
about this changing on upgrade.
If people don't think it's a big deal then I think I'd probably
rather make net.ifnames=0 the default.
If people don't like that though, it's not going to be that
difficult for me to adapt the post-install scripts. Either the
installer environment will know the network interface name, or else
it'll also be very predictable¹. So I don't really mind.
Either way, I can't do anything about the number of people who'll
encounter this issue for the first time when they upgrade their
existing Debian 11 or Ubuntu 20.04 VMs and their networking breaks
due to renamed interfaces. Fun times ahead!
I agree with you about the difficulty in predicting these
"predictable names". This command can help some:
$ udevadm info -q all /sys/class/net/eth0
P: /devices/pci0000:00/0000:00:04.0/virtio2/net/eth0
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:04.0/virtio2/net/eth0
E: INTERFACE=eth0
E: IFINDEX=2
E: SUBSYSTEM=net
E: USEC_INITIALIZED=1418948
E: ID_NET_NAMING_SCHEME=v247
E: ID_NET_NAME_MAC=enxf23c926b1fff
E: ID_NET_NAME_PATH=enp0s4
E: ID_BUS=pci
E: ID_VENDOR_ID=0x1af4
E: ID_MODEL_ID=0x1000
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Red Hat, Inc.
E: ID_MODEL_FROM_DATABASE=Virtio network device
E: ID_PATH=pci-0000:00:04.0
E: ID_PATH_TAG=pci-0000_00_04_0
E: ID_NET_DRIVER=virtio_net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:
On this system (a KVM guest) net.ifnames=0 is set so the interface
is eth0, but it can be seen here that if udev was to have its way it
may end up being enp0s4 or enxf23c926b1fff. You do of course already
have to have the new version of udev installed to get the useful
output of course…
Cheers,
Andy
¹ I think for Xen vifs it ends up being based on MAC which we also
know of course, but I will check.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
