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

[marcio79]

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.

 

[bbgeek17]

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

 

[gabrieljeske]

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.

 

[Kingneutron]

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

 

[Neobin]

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

 

[EllerholdAG]

In a proper HA setup kernel updates and restarts can be applied live. I'd rather have more Bugfixes and security enhancement than not.
It's rather concerning that other platforms don't have this much updates. Doesn't ESXi have the same security problems and they just don't patch it or wait to release the fixes? No update doesn't mean it's secure!
Could be that a lot of eyes are currently on the Linux kernel instead of on the proprietary ESXi kernel and therefore more things get found and fixed in Linux... Which is a good thing IMHO

 

[chrcoluk]

As you said its optional, better to have the updates available, the choice there, than to want a kernel update that desnt exist right?

Also doesnt the enterprise repo have less updates?

Even if you update proxmox for non kernel reasons, and it of course grabs the new kernel as part of the update, you do not have to reboot in to that kernel right away.

 

[uberarchiver]

I don't see a problem in the updates being published. We are in a changing landscape. The system administrator needs to know what is running on the system and how those workloads are accessed. On that knowledge you should base the decision on whether a update is critical for you to push into production or not.

Proxmox is doing it exactly right. Pushing updates to (potentially) critical flaws in a timely manner is what is mandated for their product to remain viable.

I really can not see the logic the op is trying to lure us into.

 

[Johannes S]

The actual elephant in the room is propably that in "enterprise"-environments in regulated areas neglecting updates is seen as a virtue instead of af the gross neglect it is:

One participant in the panel discussion, however, mentioned that the many CVEs are a huge problem in areas where updates are difficult and expensive due to certification regulations –, for example when using Linux in hospitals. Kroah-Hartman explained that US and EU legislators have recognized the problem and are working on solutions, but that this will take time.
https://www.heise.de/en/news/Linux-...s-of-the-CVE-flood-in-the-kernel-9963850.html

Nowadays the same moronic compilance requirements expect you to apply any fix to any high-scored CVE vulnerability as soon as possible.
So for people running a hypervisor in such an environment the lack of patches or just one patch day a month or year is not a bug but a feature: You don't need to convince your change board to to have more downtimes but if you get hit by a ransomware attack you can always fingerpoint to the vendor if you patched to the latest version released one year ago.

Personally I feel their pain but prefer vendors not to care about it. Why should organisations with sane rules suffer due to compilance theater in less sane environments? The obvious solution is having more ransomware attacks in this areas so these moronic rules get changed to something more practical in the age of ai-assisted security research.

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.

This won't help for environments where the rules are "any change=bad, expensive recert audit needed". For the same reason utilizing a cluster to have downtime-less patches won't help.

 

[Johannes S]

I would love to see Proxmox adopt a more conservative kernel release strategy for production environments, while continuing to deliver critical security fixes promptly.

This is not neither feasible nor desirable in the age of ai-assisted hacking.