Bug#1003835: udev: XEN domU: Guest RX stalled, unreachable due to nw device naming change

[Michael Biebl]

Am 16.01.22 um 18:18 schrieb Felix Odk:
> log messages on dom0:
>      12:36:35 felix: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0
>      12:36:35 kernel: [2348158.091840] xenbr0: port 4(vif18.0) entered blocking state
>      12:36:35 kernel: [2348158.091846] xenbr0: port 4(vif18.0) entered disabled state
>      12:36:35 kernel: [2348158.091991] device vif18.0 entered promiscuous mode
>      12:36:35 felix: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif18.0, bridge xenbr0.11:58:39
>      12:37:14 kernel: [2348197.078134] vif vif-18-0 vif18.0: Guest Rx ready
>      12:37:14 kernel: [2348197.078164] IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: link becomes ready
>      12:37:14 kernel: [2348197.078235] xenbr0: port 4(vif18.0) entered blocking state
>      12:37:14 kernel: [2348197.078238] xenbr0: port 4(vif18.0) entered forwarding state
>      12:38:49 kernel: [2348292.051684] vif vif-18-0 vif18.0: Guest Rx stalled
>      12:38:49 kernel: [2348292.051759] xenbr0: port 4(vif18.0) entered disabled state
> 
> Workaround:
> After logging into the vm using 'xl console 18', interface could be
> identified by 'sudo ip a' and manually brought up using 'sudo ip link set enX0 up'.
> 
> ROOT CAUSE:
> udev package changed the naming of the primary network device on a XEN
> domU from "eth0" to "enX0". Since /etc/network/interfaces is not
> updated, nw interface is not automatically brought up anymore, rendering
> the vm unreachable.

This is probably a result of
https://github.com/systemd/systemd/commit/d6eda677b32a0063a77cb639f37c9a454b180da9

See also the relevant NEWS entry:
"
* The predictable naming logic for network interfaces has been extended
   to generate stable names from Xen netfront device information.
"

To switch back to the v249 behaviour, you can add
net.naming-scheme=v249 to the kernel command line.

You can find further information in "man systemd-udevd.service" and "man 
systemd.net-naming-scheme"

> POSSIBLE FIX:
> devise a postinst script that (1) checks whether updated udev will change
> the name of the networking device, and (2) updates
> /etc/ntework/interfaces accordingly.


I don't think we want to get into the business of mangling other 
packages configuration files (which would be a policy violation anyway). 
Also keep in mind that ifupdown is by no means the only network 
configuration scheme.

At most we could let postinst generate a warning message.
That said, I have no idea if such a script would be feasible and how 
reliable the detection would be.
I'm happy to take suggestions how this could be implemented.
Even better, if you have an idea, please submit a MR.

Regards,
Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20220117/3636ad07/attachment.sig>