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 neither feasible nor desirable in the age of ai-assisted hacking.

 

[meyergru]

Apart from the fact that some of these updates are necessary security fixes, what exactly is the problem?

If you're running critical VMs, your infrastructure should already be designed to allow host maintenance without downtime. Simply live-migrate your VMs to another PVE host, update and reboot the first one, then rinse and repeat.

Having security and bug fixes available promptly is an advantage, not a problem. When to deploy them is up to you.

 

[Docop2]

You throw code at ai, hire any with 'coding' into their cv, push the crap over the user. Then do a patch if any complain too much.
The mania of updating every 2min is quite a joke. Just like ms win11 as basic function are not even tested and then people got no audio, no printer, black screen error.. All because of push update. A server is not a phone. Same as esxi6.7 do work fine and win10 dec24 version run perfect. That was also true for Windows Chicago as being the stronger.
Get the proper version for your system. If you put that over internet, ask why and then re-ask why putting internet on a system server.
Those 7.14 version got issues with the e810 ntwrk, but once you find a proper one, that's it. No reason to update.

 

[webreakthings]

I think people should not complain so much......

1. Either isolate your internal network infrastructure and run old software

2. keep updating your "free software"

3. pay MS a shed load of money and still apply the >1,000 patches for October... to your whole user base of win 11 machines...

4. get back into "bed" with VMWARE and STILL have to update your software.

The issue is that the software is highly complex, and the average human mind cannot do 100 tests at once in their head in a matter of minutes to see why software will break. "LLM's" are great at splitting off sub-tasks without , distractions.

Eventually we will hit a break over point where all the low hanging fruit is harvested, until that time just all sit back and remember thank god.. that you were not one of the "rockstars" that created much of this mess.

Personally I don't use LLM's to find bugs or exploits, only testing, and still manage to come-up with complete mind blowing exploit concepts..... sometimes it takes months.

I saw one on my "opencode" instance on a "airgapped" machine this week, completely locked out OS & disk write protection ,where the "open code" LLM actually wrote a python disk editor to change the binary content of a file I had asked it to run a test PLAN R/O on it.
then proudly exclaimed "it had fixed the problem"

and I shudder to think of these tools in the hands of 300 ordinary users, because the CEO said "I want the whole company on AI"

So.... there's plenty more to come yet!!!.

I have one at MS where I can internally re-route a lot of the 3rd party customers 365 & Azure cloud endpoints... then traffic into a dummy Azure hosting...
been 2 months and they still aint replied., generally they file my reports under "expected behavior" or " users won't use it like that"
takes 10 minutes to setup manually... scripted a few seconds...

at-least with linux you are not dealing with that attitude.

If it's broken , supply a fix, it's then unto the user when & where to apply it...

 

[Johannes S]

You throw code at ai, hire any with 'coding' into their cv, push the crap over the user. Then do a patch if any complain too much.

How does this relate to ProxmoxVE?

The mania of updating every 2min is quite a joke. Just like ms win11 as basic function are not even tested and then people got no audio, no printer, black screen error.. All because of push update. A server is not a phone. Same as esxi6.7 do work fine and win10 dec24 version run perfect. That was also true for Windows Chicago as being the stronger.

So you shouldn't update systems with known security issues due to a "server is not a phone"?

Those 7.14 version got issues with the e810 ntwrk, but once you find a proper one, that's it. No reason to update.

Thanks for making the world easier for hackers and thus worse for everybody else.

 

[proxuser77]

Get the proper version for your system. If you put that over internet, ask why and then re-ask why putting internet on a system server.

Just FYI: Multiple KVM escape vulnerabilities have been found this year alone. So, even if you completely air-gap your Proxmox VE hosts, an attacker could still escape from a compromised VM and gain access to the host systems this way.

But you do you! No one is forcing you to install updates. However, I think you really shouldn't use EOL or unpatched software anywhere. No one should, unless we're talking about systems that are completely self-sufficient and isolated, preferably without any network connection at all. ;-)

 

[nvanaert]

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.

1. Why not purchase the community edition? There you'll have less frequent updates (as they're delayed or not delivered at all), and then you're sure they're stable. On the Enterprise repository we went from 7.0.14-19 to 7.0.14-23 (which I missed) so went to 7.0.14-24. Then you'll have updates less frequently and you'll know they're thoroughly tested be fore applying.
2. Also have a look at the CVE score before just installing the patch, not every CVE is instantly critical and requires you to patch immediately.

 

[bzed_debian.org]

2. Also have a look at the CVE score before just installing the patch, not every CVE is instantly critical and requires you to patch immediately.

In theory that is a nice idea, but

• the score alone does not give you an appropriate answer, as it might be a critical bug in a module you never ever use, or one that you can blacklist.
• Good luck with checking every CVE, one of the last Debian security kernel updates fixed ~1800 CVEs.

 

[nvanaert]

In theory that is a nice idea, but

• the score alone does not give you an appropriate answer, as it might be a critical bug in a module you never ever use, or one that you can blacklist.
• Good luck with checking every CVE, one of the last Debian security kernel updates fixed ~1800 CVEs.

You can automate all of that easily using AI:
1. Let AI make a hardware inventory of your systems and which modules you have loaded.
2. Make a task that let's AI check the latest CVE's and look at the severity and compare it to your system.
3. Instruct it well to give an honest assessment on how important the specified patch is for your environment (based on loaded modules etc.).
4. Let it generate a daily / weekly summary with update advice.

 

[santiagobiali]

I like and appreciate the way Proxmox handles kernel updates and vulnerabilities. They backport vulnerability pathes from other branches into 7.0 way faster than other vendors.
Proxmox also informs ways to mitigate without reboot when available.

 

[kkuubboo]

There were issues with kernels 7.0.14–19, and after that. They were working hard to fix it, just read threads of non-enterprise repositories.