Network interfaces naming changes in domUs with >10 vifs (Debian bug 1042842)

[zithro <slack@xxxxxxxxx>]

Hello all,

I report here following a discussion on #xen-devel about Debian bug 
1042842 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042842).
When using more than 10 vifs in a domU on Xen 4.14 (deb11), the 
attributions are like :
vifX.0 <> eth0
vifX.1 <> eth1
vifX.2 <> eth2
[...]
vifX.10 <> eth10

With Xen 4.17 (deb12), it changes to :

vifX.0 <> eth0
vifX.1 <> eth1
vifX.10 <> eth2
vifX.2 <> eth3
[...]

Both tests are using oxenstored (the default in Debian 11/12), I don't 
know for the bug reporter. I didn't try cxenstored.
The bug reporter mentionned commit 
"http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=fce6999";, I don't 
know if it's related or not.
For now, he's using "/etc/network/interfaces" to force the attribution.

If I understood correctly, all people who answered on IRC think this is 
"not-a-Xen bug", but I was asked to post here for all to discuss.
For more context, I extracted some comments from IRC (I removed 
usernames as I didn't know if I was allowed to quote them).
Thanks !

--------------
IRC DISCUSSION
--------------

- 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

--
zithro / Cyril