Your message dated Thu, 21 Mar 2024 18:02:31 +0100
with message-id <[email protected]>
and subject line Re: Bug#1042842: network interface names wrong in domU (>10
interfaces)
has caused the Debian Bug report #1042842,
regarding network interface names wrong in domU (>10 interfaces)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1042842: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042842
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: xen-utils-4.17
Version: 4.17.1+2-gb773c48e36-1
Severity: important
Dear Maintainers,
On one of our domUs we discovered that the network interface names were
wrongly assigned since recreating the domU after an upgrade to bookworm.
If over 10 network interfaces are configured the mapping (dom0) vifX.10
<-> eth10 (domU) does not apply anymore.
Instead the interfaces on dom0 are sorted primarily by the leftmost
digit. so for 11 interfaces we will end up with:
vifX.0 <> eth0
vifX.1 <> eth1
vifX.10 <> eth2
vifX.2 <> eth3
vifX.3 <> eth4
....
This was observed with linux-kernel versions 5.10.179-3 and 6.1.38-2
(all combinations of domU and dom0) and xen 4.17.1+2-gb773c48e36-1.
You can find a config snippet and "xl network-list" + "ip a" command
output demonstrating the issue below.
Booting the host with Xen 4.14.5+94-ge49571868d-1 restored the expected
behaviour.
Looking for relevant changes i found commit fce6999 [0] which changes
the way libxl__device_list works, but i'm not sure that's the cause of
this issue.
Thanks for your help,
Valentin
[0] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=fce6999
Sample vif configuration (ascending MACs):
vif = [
'mac=00:16:3e:fd:83:2f,bridge=lanbr',
'mac=00:16:3e:fd:83:30,bridge=lanbr',
'mac=00:16:3e:fd:83:31,bridge=lanbr',
'mac=00:16:3e:fd:83:32,bridge=lanbr',
'mac=00:16:3e:fd:83:33,bridge=lanbr',
'mac=00:16:3e:fd:83:34,bridge=lanbr',
'mac=00:16:3e:fd:83:35,bridge=lanbr',
'mac=00:16:3e:fd:83:36,bridge=lanbr',
'mac=00:16:3e:fd:83:37,bridge=lanbr',
'mac=00:16:3e:fd:83:38,bridge=lanbr',
'mac=00:16:3e:fd:83:39,bridge=lanbr',
]
dom0# xl network-list 3
Idx BE Mac Addr. handle state evt-ch tx-/rx-ring-ref BE-path
0 0 00:16:3e:fd:83:2f 0 4 -1 -1/-1
/local/domain/0/backend/vif/3/0
1 0 00:16:3e:fd:83:30 1 4 -1 -1/-1
/local/domain/0/backend/vif/3/1
10 0 00:16:3e:fd:83:39 10 4 -1 -1/-1
/local/domain/0/backend/vif/3/10
2 0 00:16:3e:fd:83:31 2 4 -1 -1/-1
/local/domain/0/backend/vif/3/2
3 0 00:16:3e:fd:83:32 3 4 -1 -1/-1
/local/domain/0/backend/vif/3/3
4 0 00:16:3e:fd:83:33 4 4 -1 -1/-1
/local/domain/0/backend/vif/3/4
5 0 00:16:3e:fd:83:34 5 4 -1 -1/-1
/local/domain/0/backend/vif/3/5
6 0 00:16:3e:fd:83:35 6 4 -1 -1/-1
/local/domain/0/backend/vif/3/6
7 0 00:16:3e:fd:83:36 7 4 -1 -1/-1
/local/domain/0/backend/vif/3/7
8 0 00:16:3e:fd:83:37 8 4 -1 -1/-1
/local/domain/0/backend/vif/3/8
9 0 00:16:3e:fd:83:38 9 4 -1 -1/-1
/local/domain/0/backend/vif/3/9
domU# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether 00:16:3e:fd:83:2f brd ff:ff:ff:ff:ff:ff
inet X.X.X.X/16 brd X.X.X.X scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fefd:832f/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:30 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:39 brd ff:ff:ff:ff:ff:ff
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:31 brd ff:ff:ff:ff:ff:ff
6: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:32 brd ff:ff:ff:ff:ff:ff
7: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:33 brd ff:ff:ff:ff:ff:ff
8: eth6: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:34 brd ff:ff:ff:ff:ff:ff
9: eth7: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:35 brd ff:ff:ff:ff:ff:ff
10: eth8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:36 brd ff:ff:ff:ff:ff:ff
11: eth9: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:37 brd ff:ff:ff:ff:ff:ff
12: eth10: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:16:3e:fd:83:38 brd ff:ff:ff:ff:ff:ff
--- End Message ---
--- Begin Message ---
On 19 Mar 2024 17:34, Valentin Kleibel wrote:
Hello,
I'm currently in the process of cleaning up and i noticed this bug i
reported is still open.
Based on what we know now i think the bug can be closed.
To summarize:
* the ordering of network interfaces (and therefore the ethn names) was
never meant to be stable and changed with Xen 4.17
* domUs starting with bookworm use enXn by default and their order
matches the config
* bullseye domUs on a bookworm dom0 with more than 10 network interfaces
need a workaround:
* use udev from bullseye-backports and enXn naming scheme
* use custom udev rules to get fixed interface names
Thanks for your help with this issue,
Valentin
Thank you for the follow-up, and the bonus summary !
Closing bug, please re-open if you think that was a mistake.
--
++
zithro / Cyril
--- End Message ---
