[Pkg-xen-devel] Bug#1042842: network interface names wrong in domU (>10 interfaces)
zithro
slack at rabbit.lu
Tue Aug 8 21:11:03 BST 2023
On 08 Aug 2023 16:59, Hans van Kranenburg wrote:
> I didn't read the other mailthread on the xen list fully yet.
You gave me the idea to post the IRC digest, so the report here is more
complete, and people not tracking the xen-devel ML can read it nicely.
For those who do, the mail is dated "02 Aug 2023 18:19", and titled
"Network interfaces naming changes in domUs with >10 vifs (Debian bug
1042842)".
The ML post got no answer yet.
[--- IRC ---]
- AFAIK, there is no sorting in Xenstored. And you should not expect
that even if libxl sorted properly it will be seen in the same order on
the other end.
- is the ethN number in domU related to vif number in xenstore, or to
device detection order?
- there's no order to eth names at all. they're allocated
first-come-first-serve, so it entirely depends on how parallel the
probing of nic drivers are. even if netfront is serialised around
xenstore accesses, it probably allocates in the order that XS_DIRECTORY
comes back with
- from simple tests, it looks like VIFs are created in Xenstore in the
order of the config file, but if you "xenstore-ls /[...]/vif", you can
see vifs are ordered like vif1,vif10,vif11,vif2,etc
- the order is different between Xen 4.14 and 4.17 (ie. the "expected"
order works on 4.14, not 4.17)
- But really, Debian should have never relied on how the nodes are
ordered. This is not something we guarantee in the Xenstored API
- the last big batch of XSA content for the xenstoreds did some major
rearranging of oxenstored. We dropped a NIH second garbage collector,
and a NIH weakref system IIRC. I could entirely believe that the
apparent sort order changed as a result
- generally, I think Linux world established quite some time ago that
ethN names are not stable
- It's definitely a complicated issue. Perhaps best to post to
xen-devel so we can have a discussion. I expect the answer is not-a-Xen
bug, but I don't think we have a clear understanding of the problem yet
[--- /IRC ---]
I'll report back when having tested the 111 vifs domU ... if my system
agrees o_O
As it requires a script to populate the cfg, one could also enhance it
to try how dynamically adding/removing vifs is handled.
(BTW, before this report I thought Xen had a hard limit of 8 vifs per
domU. Or was that only on FreeBSD domUs ? Can't remember).
More information about the Pkg-xen-devel
mailing list