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

[zithro]

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).