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.
