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

[zithro]

On 08 Aug 2023 12:08, Valentin Kleibel wrote:
>> I posted on xen-devel, you can follow from :
>> https://lists.xenproject.org/archives/html/xen-devel/2023-08/msg00244.html
>> (Unfortunately, the formatting is weird via html, split the IRC part 
>> on "- ").
> 
> Thank you for posting upstream.

No prob, although if that very answer does not answer your question, I 
guess you'd be better off replying on xen-devel ML (reply to my post or 
at least reference it).

> All documentation i found found on the Xen wiki suggests that interfaces 
> are connected vifX.Y <-> ethY. [0] [1]
> The only other way i know of for identifying the interfaces are MAC 
> Addresses which can be randomly assigned if you don't configure them.

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

> Either i am missing the way you're supposed to do this, or there is a 
> bug somewhere in the toolchain.
> Unfortunately i'm not able to pinpoint the source of the issue, any help 
> would be appreciated.

I made some tests with a domU using many interfaces, like :

[...]
vif = [ 'bridge=xbr-tst,mac=00:16:3e:de:bd:00,type=vif,vifname=domu-a' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:01,type=vif,vifname=domu-b' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:02,type=vif,vifname=domu-c' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:03,type=vif,vifname=domu-d' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:04,type=vif,vifname=domu-e' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:05,type=vif,vifname=domu-f' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:06,type=vif,vifname=domu-g' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:07,type=vif,vifname=domu-h' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:08,type=vif,vifname=domu-i' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:09,type=vif,vifname=domu-j' ,
         'bridge=xbr-tst,mac=00:16:3e:de:bd:10,type=vif,vifname=domu-k' ,
         ]
[...]

-----
This is dom0's corresponding dmesg:

[...]
xbr-tst: port 3(domu-b) entered blocking state
xbr-tst: port 3(domu-b) entered disabled state
device domu-b entered promiscuous mode
xbr-tst: port 4(domu-i) entered blocking state
xbr-tst: port 4(domu-i) entered disabled state
device domu-i entered promiscuous mode
[...]

Here you can see :
port 3 <-> domu-b
port 4 <-> domu-i

We learn here that dom0 did not detect vifs serially.

-----
In the domU, "ip link" shows :

[...]
eth0
     link/ether 00:16:3e:de:bd:00
     altname enX0
eth1
     link/ether 00:16:3e:de:bd:01
     altname enX1
eth2
     link/ether 00:16:3e:de:bd:10
     altname enX10
eth3
     link/ether 00:16:3e:de:bd:02
     altname enX2
[...]

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

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.