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.

At most we could let postinst generate a warning message.

I'm happy to take suggestions how this could be implemented.
Even better, if you have an idea, please submit a MR.

Regards,
Michael

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. That said, I have no idea if such a script would be feasible and how reliable the detection would be.

OpenPGP_signature
Description: OpenPGP digital signature