Proxmox VE: Are we getting too many kernel updates for an enterprise virtualization platform?

marcio79

Member
Apr 18, 2024
44
13
13
47
Brasil
Let me start by saying that I really appreciate Proxmox VE. It's a great virtualization platform, and I use it in production environments.
However, there's something that has been bothering me lately: the frequency of kernel updates, even on the stable branch.
Just look at the recent 7.0.14 kernel series:
  • 7.0.14-17 — September 14
  • 7.0.14-19 — September 21
  • 7.0.14-20 — September 30
  • 7.0.14-21 / 22 — October 7
  • 7.0.14-23 — October 8
  • 7.0.14-24 — October 10
That's a remarkable number of kernel revisions in just a few weeks.
I completely understand that kernel updates are not mandatory and that nobody is forcing administrators to install every single release.
I also understand that some updates are absolutely necessary. The latest 7.0.14-24, for example, addresses CVE-2026-99999 (PwnEscape), a critical guest-to-host security vulnerability. Security fixes like this should obviously be released as quickly as possible.
But here's my concern.
We're talking about a virtualization platform running production workloads, not a regular desktop Linux distribution.
Updating a kernel often means rebooting the hypervisor, scheduling maintenance windows, coordinating VM downtime, and making sure nothing breaks afterward.
And let's not forget that kernel updates can introduce regressions too.
I don't recall seeing this level of kernel revision frequency with other enterprise virtualization platforms.
Of course, stability doesn't mean avoiding updates. Security must always come first.
But shouldn't an enterprise virtualization platform also prioritize predictability, consolidation of non-critical changes, and longer periods between routine kernel updates?
I would love to see Proxmox adopt a more conservative kernel release strategy for production environments, while continuing to deliver critical security fixes promptly.
I'm genuinely curious how other Proxmox administrators are handling this.
Are you updating the kernel every time a new version appears, or are you deliberately skipping releases and maintaining your own update schedule?
I'd love to hear your thoughts.
 
  • Like
Reactions: Kingneutron
Hey @marcio79,

Your concerns are understandable, particularly if you're used to the update cadence of enterprise platforms from a few years ago. However, the security landscape has changed, and virtualization hosts require a different approach to patching.

I'd distinguish between two broad use cases for Proxmox VE in production:
  • Hosting internal business workloads: If the VMs run trusted applications and are not exposed to untrusted tenants, your risk profile may allow more flexibility in scheduling routine updates. Arguably, if your application (i.e. MSFT) is compromised, protecting against guest to host escape may not be that critical at that point.
  • Providing infrastructure to untrusted tenants: If you're selling VM access or hosting workloads for customers you don't control, the hypervisor is part of your security boundary. In that environment, prompt application of relevant security fixes is a responsibility to your customers.
In either case, if you're running a business where hypervisor maintenance affects production workloads, the infrastructure should be designed to support rolling maintenance. A properly configured PVE cluster, with suitable storage, networking, and sufficient spare capacity, allows you to reboot nodes individually rather than taking the entire environment down at once.

I would love to see Proxmox adopt a more conservative kernel release strategy for production environments, while continuing to deliver critical security fixes promptly.
The kernel updates you've listed are all based on the same major.minor version. The tertiary version increments distinguish successive package releases. I haven't reviewed the diffs between these particular releases, but I'd expect the changes to consist of bug fixes, including security fixes and fixes related to data integrity or virtualization stability, rather than new features.

You can't reduce the number of releases while guaranteeing that known issues are addressed just as promptly. Consolidating changes might reduce the number of updates, but it could also delay fixes that are important to particular environments.

My advice would be to review the release notes for each kernel update and assess its relevance to your environment. If a particular fix isn't relevant to your workloads or risk profile, you can make an informed decision to defer that update.

Cheers.

PS and AI does not only find security issues, data consistency problems are being uncovered upstream as well. It is only responsible of PVE to deliver those.


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Proxmox could launch a system similar to Kernel Care, but their own, to apply patches live. That is something most people would likely be willing to pay for.
 
I tend to agree, but they're fixing active security issues to minimize exploits and bugs.

As long as you're firewalled properly, you could plan a weekly or every-other-week upgrade schedule. Just make sure you have backups.
/ and don't do it on a Friday
 
One complains about too much updates and the next one would complain about bugs and especially vulnerabilities if they were not patched asap.
It is obviously way better to have the updates available; if and when you are installing them and reboot is on the other hand fully up to you...