[Pkg-xen-devel] Bug#1042842: Bug#1042842: network interface names wrong in domU (>10 interfaces)

[Valentin Kleibel]

> On [0], you can read "In both cases the device naming is subject to the 
> usual guest or backend domain facilities for renaming network devices".
> It says "naming/renaming", but you can assume "detecting".
> 
>> I also checked which net_ids udev knows about and the only things that 
>> pop up are:
>> ID_NET_NAMING_SCHEME=v247
>> ID_NET_NAME_MAC=enx00163efd832b
>> ID_OUI_FROM_DATABASE=Xensource, Inc.
> 
> Is it from dom0 or domU ?
> Are you using "net.ifnames=0" on the domU kernel command line ?
> "v247" looks like systemd "predictive naming scheme" (eth -> enX).
>  From bookworm on, domUs vifs get named enXN (enX0, enX1, ...).
> Read on :
> https://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#xen-network

This is from the domU, running bullseye with a bookworm dom0.

> See how ethN interfaces get messed up, like in your setup, but 
> predictable names would work, as you can see in "altname enXN" :
> eth1 (:01) -> enX1
> eth2 (:10) -> enX10
> eth3 (:02) -> enX2

I could not get our bullseye domU to show the "predictable names" even 
though i tried installing the bullseye-backports kernel 6.1.
After you wrote this i installed udev 252.5 from backports and it now 
uses the correct enXn interface names, even with kernel 5.10.

> So, my answer does not tell you if something changed in Xen itself, only 
> in Debian.
> But I guess it relates to what Xen devs told us : vifs detection order 
> cannot be relied upon, that's why "predictable names" were invented.
> The vif detection part is related to the domains kernels, not Xen itself 
> (at least that's what I understood).
> 
> Using eth0 nowadays is a bit like using /dev/sda for hard drives, it's 
> considered legacy as it may create problems in some setups, like yours 
> (ie. for disks, it's recommended to use UUIDs or /dev/disk/by-*).
> 
> I hope this answers your question.

Thank you, yes it does.

In our case the dom0 was updated to bookworm while the domU is still 
running bullseye.
-> updated Xen so the vif detection order changed (which we relied on)
-> the predictable network names for Xen don't work with bullseye

So my new resolution for bullseye domUs on a bookworm dom0 is to install 
udev from backports and change the domUs network config to use the new 
enXn naming scheme instead of ethn.