[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: XEN domU: Guest Rx stalled, unreachable



On 1/16/2022 7:16 AM, Felix Odenkirchen wrote:
Dear all,

I'm running a stock Debian SID vm on xen, hostname "vm-sid".
Dom0 is on stock Debian Bullseye, hostname "bigiron-one".

apt updating vm-sid packages on 2022-01-13 08:11:00 UTC rendered vm-sid
unaccessible over network upon reboot.
Updated packages:
bsdutils bsdextrautils dbus eject initramfs-tools libblkid1 libc-bin
libfdisk1 libnss-systemd libpam-systemd libpython3.9-minimal
libpython3.9-stdlib libsmartcols1 libsystemd0 libudev1 libuuid1 mailcap
man-db mount python3-pkg-resources python3.9 python3.9-minimal systemd
systemd-sysv systemd-timesyncd udev util-linux

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:

1. Logging in on virtual console
    felix@bigiron-one:~$ sudo xl console 18

2. bringing interface up manually
    felix@vm-sid:~# sudo ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
           valid_lft forever preferred_lft forever
    2: enX0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
        link/ether 00:16:3e:14:07:93 brd ff:ff:ff:ff:ff:ff
    felix@vm-sid:~# sudo ip link set enX0 up
    felix@vm-sid:~# sudo dhclient

3. log on dom0
    12:41:24 kernel: [2348446.972241] vif vif-18-0 vif18.0: Guest Rx ready
    12:41:24 kernel: [2348446.972304] xenbr0: port 4(vif18.0) entered
blocking state
    12:41:24 kernel: [2348446.972308] xenbr0: port 4(vif18.0) entered
forwarding state

4. network running and stable


I fail to see why SID domU stopped bringing up its network interface.
Worked perfectly before.
Another apt update && apt upgrade didn't remove the problem, so no
package fix yet  :-/
All the other domU (Bullseye and Bookworm vm's) are not affected and
running fine,
How can I determine the source of the problem on vm-sid, or the relevant
package?

Regards,
Felix



Hi Felix,

It looks to me like a change in one of the systemd or udev packages in vm-sid is causing the trouble here. In my experience with Debian, the networking startup stuff is not so straightforward, but I do know that systemd and udev are the software components responsible for setting up the network and responding to networking events such as plugging in an ethernet cable or turning on wifi. So I would look in the changelogs of the systemd and udev packages that were updated and see if you can get a clue on what might have changed to break your networking startup configuration. For example, if your network is setup using /etc/network/interfaces and ifup at startup and the systemd configuration changed so that the ifup script that reads /etc/network/interfaces are no longer called correctly at startup, then your network interface would not be brought up automatically at startup. In my experience, once when I changed some packages the network interface name changed and that caused my network interface to not come up properly at startup. To fix it, I had to tweak the systemd configuration.

All the best,

Chuck


Reply to: