Opt-in Linux 7.0 Kernel for Proxmox VE 9 available on test and no-subscription

Kernel 7.0.0-2 running in our Test Cluster with no Problems until now.
Fujitsu PRIMERGY RX2540 M5
Xeon(R) Silver 4215R CPU
Intel Ethernet Adapters: I350, X550, X710, X722
 
Kernel 7.0.0-2 running good. 3 nodes in a cluster and 2 PBS servers. IO Delay and IO Pressure Stall was higher than normal. Restored pve-qemu-kvm=10.1.2-7 in the cluster and systems were back to normal.
 
Kernel 7.0.0-2-pve will freeze the host if total free RAM becomes low (< 5 to 10% free). Any one seeing this issue? I just have to back off the RAM requirements for my VMs a little (now around 87% usage) and everything works again.

Host do not freeze when on `6.17.13-4-pve` though.

FYI. Been meaning to tidy up this host anyway o_O, but now problem solved. :D

---
AMD Ryzen 5 5600G, 64 GB RAM
 
Testing since 2026-04-11 on four hosts.

So far so good overall — io_wait accounting issue still present / data unreliable, but aside from that stable (no crashes) on 3/4 hosts.

The fourth host (used for game streaming to a client via Moonlight/Sunshine, with a Windows 11 VM and an AMD RX 6900 XT passed through) shows a clear regression on kernel 7.x: the Moonlight client connects, negotiates the session, and initializes the Vulkan decoder successfully, but then video frames never fully arrive. Client log:

Code:
[...]
00:00:47 - SDL Info (0): Frame pacing disabled: target 240 Hz with 240 FPS stream
00:00:47 - SDL Info (0): Using Vulkan video decoding
00:00:47 - SDL Info (0): FFmpeg-based video decoder chosen
00:00:47 - SDL Info (0): Dropping window event during flush: 6 (3840 2160)
00:00:47 - SDL Info (0): IDR frame request sent
00:00:50 - SDL Info (0): Received first video packet after 2500 ms
00:00:50 - SDL Info (0): Unrecoverable frame 268: 0+1=1 received < 77 needed
00:00:50 - SDL Info (0): Unrecoverable frame 271: 0+1=1 received < 77 needed
00:00:50 - SDL Info (0): Unrecoverable frame 274: 0+1=1 received < 77 needed
00:00:50 - SDL Info (0): Unrecoverable frame 277: 0+1=1 received < 77 needed
00:00:50 - SDL Info (0): Unrecoverable frame 279: 0+1=1 received < 77 needed
00:00:50 - SDL Info (0): Unrecoverable frame 283: 0+1=1 received < 77 needed
00:00:50 - SDL Info (0): Unrecoverable frame 285: 0+1=1 received < 77 needed
[...]

The "0+1=1 received < 77 needed" pattern indicates massive packet loss on the video stream (1 of 77 expected FEC/data packets per frame arriving) — so this is almost certainly a networking regression rather than a GPU passthrough issue. Control/audio/session traffic works, only the high-pps UDP video payload is affected.

Most likely related to the networking changes in kernel 7.x interacting with our specific setup:
  • Mellanox ConnectX-5 (MCX512A-ACAT-ML), mlx5_core driver
  • OVS bridge (vmbr0)
  • OVS bond over both NIC ports, bond_mode=balance-tcp, LACP active
  • virtio-net in the VM with queues=8
Pinning back to kernel 6.17 on that host resolves it immediately — same VM config, same hardware, no other changes. Happy to provide pveversion -v, ethtool -S output on both kernels, dmesg diffs, or test patches if useful.
 
  • Like
Reactions: SInisterPisces
Kernel 7.0.0-2-pve will freeze the host if total free RAM becomes low (< 5 to 10% free). Any one seeing this issue? I just have to back off the RAM requirements for my VMs a little (now around 87% usage) and everything works again.

Host do not freeze when on `6.17.13-4-pve` though.

FYI. Been meaning to tidy up this host anyway o_O, but now problem solved. :D

---
AMD Ryzen 5 5600G, 64 GB RAM
Well... not so much freezing but I have something - non-issue I am proper pushing that box to its limits, its only a dev box. There is no bug or no reason why other than I have, purposely, crammed that box full. This is not on Debian, Proxmox or anything except my empty wallet to add another host. For shame.

I see much better KSM occuring when all kernel types of linux hosts and all Windows versions are same patch level. During patching this month with kernel version 7, I saw a huge decrease in overall KSM whilst machines were differing versions. Once all patching completed and Windows in particular same patch level, KSM kicks back in again and memory availabilty increases once again.
I guess, the clue is in the name "Same Page Merging"...

This month that really overloaded box struggled. Must find a better paying job to afford another machine!
 
  • Like
Reactions: Johannes S