Hello, On Sun, Apr 03, 2022 at 06:43:13PM -0400, Ian Kelling wrote: 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. 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. 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_FI… 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