Issues after latest kernel update or packages?

Stimpy68

Member
Jan 25, 2024
9
1
8
Hi Guys, I installed the latstest updates last friday on my cluster to:

Linux 7.0.14-15-pve (2026-08-26T14:21Z)

But ran into some strange issues after that:

Rebooting a node migrates the HA VMs to the other node, no issue, but when the node is online again migrating back fails with an error that states that there is no route to host,

task started by HA resource agent
ssh: connect to host xxx.xxx.xxx.xxx port 22: No route to host
TASK ERROR: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=yyyy' -o 'UserKnownHostsFile=/etc/pve/nodes/yyyy/ssh_known_hosts' -o 'GlobalKnownHostsFile=none' root@xxx.xxx.xxx.xxx pvecm mtunnel -migration_network xxx.xxx.xxx.xxx/24 -get_migration_ip' failed: exit code 255


After soms troubleshooting I added a delay in the pve-ha-lrm of 15 seconds, that fixed it, For reference, a friend of mine has the same setup as me (2 nodes and a Qdevice) but running on different hardware, and he has no issues.

Other problem since the upgrade is that 1 host keeps disappearing from the cluster GUI, everything is marked with "?" , but all VMs run etc. When restarting pvestatd it came back in de GUI. Investigating the logging of that service I found that I have errors stating that my PBS server storage can't be reached pvestatd[1599]: ProxmoxBackupServer: error fetching datastores - 500 Can't connect to pbs.xxxxxx:8007 (Temporary failure in name resolution), also sometime other NFS shares.
That wasn't the case before the upgrade.

After some searching I found this old thread: https://forum.proxmox.com/threads/proxmox-freezes-random-no-clue-in-the-log.89212/#:~:text=* log.zip. 406.3 KB · Views: 4.

I have these NICs:

Intel Corporation Ethernet Controller I226-V (rev 04)

6 per node

EDIT: I reverted to the kernel I was running before (and removed the delay), but issues are still there.
 
Last edited:
Could you share the network configs from 2 nodes where you observed the migartion issue and PBS connection problem:
cat /etc/network/interfaces

Just a hunch maybe its related to:
https://pve.proxmox.com/wiki/Roadmap#9.0-known-issues

VirtIO vNICs: Changed default for MTU field​


Leaving the MTU field of a VirtIO vNIC unset now causes the vNIC to inherit the bridge MTU. Previously, the MTU would default to MTU 1500. The pve8to9 checklist scripts will detect vNICs where the MTU would change after upgrade. If you want affected vNICs to keep using MTU 1500, you need to manually configure MTU 1500 before upgrade.
 
@longer

It is a 2 node cluster with a QDevice.

Here they are:

Host 1:
cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface enp2s0 inet manual
#LAN

iface enp3s0 inet manual
#WAN

auto enp4s0
iface enp4s0 inet static
address 192.168.100.2/24
#Replicatie

iface enp5s0 inet manual

iface enp6s0 inet manual

iface enp7s0 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.0.10/24
gateway 192.168.0.95
bridge-ports enp2s0
bridge-stp off
bridge-fd 0
#LAN

auto vmbr1
iface vmbr1 inet manual
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
#WAN

source /etc/network/interfaces.d/*

Host 2:

cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface enp2s0 inet manual
#LAN

iface enp3s0 inet manual
#WAN

auto enp4s0
iface enp4s0 inet static
address 192.168.100.1/24
#Replicatie

iface enp5s0 inet manual

iface enp6s0 inet manual

iface enp7s0 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.0.1/24
gateway 192.168.0.95
bridge-ports enp2s0
bridge-stp off
bridge-fd 0
#LAN

auto vmbr1
iface vmbr1 inet manual
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
#WAN

source /etc/network/interfaces.d/*
 
My hunch was wrong, based on the shared config, the mtu is default to 1500.

For the second mentioned issue where you see connection to PBS fails, does Ping to pbs works from the affected host?
You can check also using the command:
root@pve ~# proxmox-backup-client status --repository <backup_user>@pbs@<pbs_server_ip>:8007:<datastore>
 
Well, the issue is, that it looks like that some services of nics take a bit longer, so the network is not fully ready yet, it is trying to mount PBS for instance and it can't do a DNS lookup yet. Same is true for the migration back, I think it sees the other host on the corosync and tries to start the migration but the network is not ready. Thats why the delat in the service fixes that issue.
I have had this on the version prior to this one, but going back 1 kernel version didn't solve it. So it must be one of the other packages that was installed
 
These were installed on the 4th
grep "upgrade " /var/log/dpkg.log
2026-09-04 06:23:59 upgrade linux-libc-dev:all 6.12.105-1 6.12.107-1
2026-09-04 06:24:05 upgrade proxmox-kernel-7.0:amd64 7.0.14-14 7.0.14-15
2026-09-04 06:24:05 upgrade pve-container:all 6.1.13 6.1.14
2026-09-04 06:24:05 upgrade pve-edk2-firmware-ovmf:all 4.2025.05-3 4.2026.08-1
2026-09-04 06:24:06 upgrade pve-edk2-firmware-legacy:all 4.2025.05-3 4.2026.08-1
2026-09-04 06:24:06 upgrade pve-edk2-firmware:all 4.2025.05-3 4.2026.08-1


But could be upgrades before that, that didn't need a reboot