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

[isi]

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

 

[TheGoat]

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.

 

[snakeoilos]

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 , but now problem solved.

---
AMD Ryzen 5 5600G, 64 GB RAM

 

[Bent]

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:

[...]
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.

 

[monkfish]

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 , but now problem solved.

---
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!

 

[panji19m]

Doesnt work on my 245K

[    4.241268] i915 0000:00:02.0: driver does not support SR-IOV configuration via sysfs<br>

Even when lspci is showing it is supported

    Capabilities: [320 v1] Single Root I/O Virtualization (SR-IOV)
        IOVCap:    Migration- 10BitTagReq+ IntMsgNum 0
        IOVCtl:    Enable- Migration- Interrupt- MSE- ARIHierarchy- 10BitTagReq-
        IOVSta:    Migration-
        Initial VFs: 7, Total VFs: 7, Number of VFs: 0, Function Dependency Link: 00
        VF offset: 1, stride: 1, Device ID: 7d67
        Supported Page Size: 00000553, System Page Size: 00000001
        Region 0: Memory at 000000b010000000 (64-bit, prefetchable)
        VF Migration: offset: 00000000, BIR: 0

But intel website states its unsupported on Meteor Lake

https://www.intel.com/content/www/us/en/support/articles/000093216/graphics/processor-graphics.html

Try use the sriov DKMS driver. They have build for Kernel 7.00

https://github.com/strongtz/i915-sriov-dkms/actions/runs/24812325328/artifacts/6592469285

 

[meyergru]

Never mind this post - as it turned out, it was a glitch of one container that caused this.


I have tried kernel 7.0.0-2-pve now and it works - with a big caveat; I found my machine to hover at 8.5% load instead of 5.8% with 6.17.13-3-pve, which in turn uses ~40W more (i.e. 230W instead of 190W) for the whole machine:



(in this picture, the first period is with 6.17.3, then 7.0, then 6.17.3 again)

The machine is an i5-14600K with 128 GByte DDR4 and two 2TB NVME disks with 8x18 TByte SATA disks in raidz2 running 10 VMs and 5 LXCs.

What was most surprising is the fact that most VMs and LXCs had a lower load with 7.0:



with only the Docker VM (Ubuntu 24.04) with ~20 containers being the outlier:



I find that strange, because it is a VM with its own kernel (6.8.0-110-generic) that has not changed between runs.
Also, I have another docker VM that showed less load with 7.0...