I've just installed a brand new Debian 12.4.0 VM on a Hyper-V host, using the ordinary debian-12.4.0-amd64-netinst.iso image.
Logging in to complete the network setup, I'm surprised to find that my two virtualised NICs are named eth0 and eth1 rather than anything following the Predictable Network Interface Names pattern. I'm concerned that this might mean that eth0 and eth1 might not bind to the virtual NICs consistently, which would mess up the static IP address allocations that I need to use for this VM, and result in traffic getting routed to the wrong interfaces or tagged with incorrect VLAN IDs by the hypervisor.
Debian wiki page for Network Interface Names says that when I run udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null, the output should always contain an ID_NET_NAME_PATH element:
By default, the MAC address isn't used for generating interface names, and I'm not confident those will necessarily be stable for a VM anyway.
So this output doesn't contain anything that can be used to generate a predictable interface name; I expect that's why it's falling back to old-school eth0/eth1 naming.
But why aren't these VM network interfaces generating an ID_NET_NAME_PATH element that follows the "Predictable Interface Names" pattern? Is there anything I can do to fix it?
Follow-up question: If I leave the interface names as eth0 and eth1, is there any actual risk that this will result in unstable network interface binding?
More details about the current system configuration follow...
In the Debian installer, I chose to install without any desktop environment, but with an SSH server, since this is to be a remotely-managed server for basic server apps and Docker container hosting, without interactive users. Therefore NetworkManager is not present; I believe the network configuration is being managed by systemd-networkd but I am very far from expert in Linux.
The new system has no files in /etc/systemd/network. So I believe it will be using the the default naming policy order given in /lib/systemd/network/99-default.link? That file's contents are:The output of sudo sysctl -a contains no reference to net.ifnames.
Linux version is Linux [...] 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux. systemd version is systemd 252 (252.19-1~deb12u1).
I have checked the "Virtual Machines" note in the linked Debian NetworkInterfaceNames wiki page, which suggests removing some files under /etc/systemd/network and then rebuilding the initrd in order to trigger re-generation of the interface names. I have no files in those locations. I tried rebuilding the initrd and rebooting anyway. This had no effect on the interface names; they're still eth0 and eth1.
Logging in to complete the network setup, I'm surprised to find that my two virtualised NICs are named eth0 and eth1 rather than anything following the Predictable Network Interface Names pattern. I'm concerned that this might mean that eth0 and eth1 might not bind to the virtual NICs consistently, which would mess up the static IP address allocations that I need to use for this VM, and result in traffic getting routed to the wrong interfaces or tagged with incorrect VLAN IDs by the hypervisor.
Debian wiki page for Network Interface Names says that when I run udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null, the output should always contain an ID_NET_NAME_PATH element:
But that's not what I see! When I run that command, I get only the following output:ID_NET_NAME_PATH= Always present; usually something just complicated enough to be easy to forget, like wlp3s5 or enp1s3f0. Note that all numbers are in hex.
Code:
ID_NET_NAMING_SCHEME=v252ID_NET_NAME_MAC=enx00155dddac06ID_OUI_FROM_DATABASE=Microsoft CorporationSo this output doesn't contain anything that can be used to generate a predictable interface name; I expect that's why it's falling back to old-school eth0/eth1 naming.
But why aren't these VM network interfaces generating an ID_NET_NAME_PATH element that follows the "Predictable Interface Names" pattern? Is there anything I can do to fix it?
Follow-up question: If I leave the interface names as eth0 and eth1, is there any actual risk that this will result in unstable network interface binding?
More details about the current system configuration follow...
In the Debian installer, I chose to install without any desktop environment, but with an SSH server, since this is to be a remotely-managed server for basic server apps and Docker container hosting, without interactive users. Therefore NetworkManager is not present; I believe the network configuration is being managed by systemd-networkd but I am very far from expert in Linux.
The new system has no files in /etc/systemd/network. So I believe it will be using the the default naming policy order given in /lib/systemd/network/99-default.link? That file's contents are:
Code:
[Match]OriginalName=*[Link]NamePolicy=keep kernel database onboard slot pathAlternativeNamesPolicy=database onboard slot pathMACAddressPolicy=persistentLinux version is Linux [...] 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux. systemd version is systemd 252 (252.19-1~deb12u1).
I have checked the "Virtual Machines" note in the linked Debian NetworkInterfaceNames wiki page, which suggests removing some files under /etc/systemd/network and then rebuilding the initrd in order to trigger re-generation of the interface names. I have no files in those locations. I tried rebuilding the initrd and rebooting anyway. This had no effect on the interface names; they're still eth0 and eth1.
Statistics: Posted by Conf-user — 2024-02-01 03:10 — Replies 2 — Views 56