Still no plans to provide an LTS version of Proxmox 7? Debian 11 will go until 2026 with security updates.
It doesn't hurt to ask if things changed since 4 years ago.
It doesn't hurt to ask if things changed since 4 years ago.
Proxmox VE - Support Lifecycle
- Thread starter martin
- Start date
No plans for a longer term support, Proxmox VE 7 is still planned to become end-of-life after the 31st of July 2024.
I am curious why the underlying Debian version matters to you? Hardware support is mostly contingent on the kernel version, and kernel images are maintained separately by the Proxmox developers. Support software packages such as LXC and QEmu are directly managed by Proxmox. And as long as the Proxmox team provides all the up-to-date security patches for the host's OS, the rest of the system software has relatively little impact on anything. It's not as if you would install a lot of end-user software on the host. All of that goes into containers or VMs.
For all I care, Proxmox could run on a ten year old version of Debian. It wouldn't make much of a difference to me, but it certainly would make backporting of kernels, core infrastructure, and security patches much more difficult for the Proxmox developers. So, I would assume that there naturally is some push to upgrade every once in a while.
You can of course run the newest development release of your favorite distribution in a virtualized environment, even if the host sticks to a very conservative older release.
And yes, there are a couple of pet peeves and things that I would have done differently on the host. Most notably, I am always annoyed by seeing the /etc/network/interfaces file. On all my other systems, I have a strong preference for using systemd-networkd. It feels much more expressive and natural. But honestly, that's not my problem to solve. If the Proxmox developers want to maintain code that manipulates a single configuration file and that uses customized scripts to interpret this file, then that's their prerogative.
For all I care, Proxmox could run on a ten year old version of Debian. It wouldn't make much of a difference to me, but it certainly would make backporting of kernels, core infrastructure, and security patches much more difficult for the Proxmox developers. So, I would assume that there naturally is some push to upgrade every once in a while.
You can of course run the newest development release of your favorite distribution in a virtualized environment, even if the host sticks to a very conservative older release.
And yes, there are a couple of pet peeves and things that I would have done differently on the host. Most notably, I am always annoyed by seeing the /etc/network/interfaces file. On all my other systems, I have a strong preference for using systemd-networkd. It feels much more expressive and natural. But honestly, that's not my problem to solve. If the Proxmox developers want to maintain code that manipulates a single configuration file and that uses customized scripts to interpret this file, then that's their prerogative.
Plans? Yes, we always plan ahead, but as the toolchain freeze for Trixie only happened a few days ago and the soft-freeze is still three weeks away we see no reason to release anything public yet. We will do a post in this forums once there is something available to test, I'd expect that to happen later in Q2, but at this point we cannot give any guarantees for a timeline here.
PVE 8 will be still be supported for at least 15+ months as of today, so is definitively still a good choice to use.
thanks for clarification. I'll monitor the forum. I'll be happy to try out prerelease software, as this is a special case as follows:
Yes, but in my case, it's something special i am trying. Because it's highly experimental and unsupported, i didn't mention it at all.
Short form:
I'm using a frankenstein-debian-proxmox on my desktop.
Debian 12, proxmox repo on top as in the manual, KDE plasma, etc.
Works great for what i am doing, i can migrate VMs from my other regular proxmox hosts to my desktop and vice versa.
Helpful for debugging and other stuff.
Now i've got a new videocard (9070xt) and this card needs Mesa 25 and kernel 6.12+).
I tried compiling mesa, it installed but something is wrong (accelleration not working).
Spent several hours on it.
Proxmox on debian 13 isn't working, as it needs a specific perl-base. Fiddling around didn't help, the modules won't run on any other perl version.
So currently, i can either use the gpu or proxmox, but not both.
Sure, i can work around and leave all VMs on my virtualisation-hosts, but i like trying things out. That's how i learned all i know today.
I'll try to uninstall the nvidia drivers the next days and push mesa25 over it (recompiled with parameters from debian sources) - maybe this will work.
Or i can try to copy all related stuff from my debian trixie test-machine next on my bench over and hope for the best - sometimes this is also working.
Anyway, i don't have high hopes. Yes, the GPU is really new, but it works fine under debian 13.
FWIW, you might get away with using a very privileged/uncontained LXC container to run a clean Proxmox VE itself while being able to use latest unstable Debian on the machine itself, I used that in the past to get a PVE system on a private workstation running Arch Linux.
This is the wrong thread to elaborate here further, but IIRC there are some OK tutorials for creating a LXC container manually out there, basically one just need to use a privileged/uncontained profile and pass through the /dev/kvm and /dev/fuse device nodes.
For some reason, that had never occurred to me. But yes, that works. In fact, it works so well that I now have Proxmox VE running directly on my Chromebook. Took a bit of work to make the the different virtualizations work seamlessly. But with a little effort, I can now access files on my Chromebook from within containers, and I can even open X11 applications in the container that will then render as an app in ChromeOS.
Overall, I am pretty impressed how well this works, and it's certainly another useful tool to have access to, when I can't easily connect to the cloud for some reason.
For my use case, the Debian version matters because I want access to the latest Debian userland repos without having to hack up my repo configuration file and risk instability.
In particular, I have iGPU passthrough working via the i915 DKMS driver, so I need to use the
intel-gpu-tools package on Proxmox to install the intel_gpu_top application to monitor what the iGPU is doing to make sure it's actually accelerating my VMs and LXCs. We pull that package from the Debian repos, so we get the version of the tool that's in whatever repo we're using. The version in the Debian 12 (1.27.1-1) repo is over two years old. It's not exactly stable or fully featured when using a bleeding edge feature like SR-IOV, which is still getting driver updates and related tweaks every couple of months. Trixie is up at 2.0-1. See: https://packages.debian.org/search?keywords=intel-gpu-toolsI really appreciate the PVE dev team pushing the envelope on keeping us up to date with the latest Debian, because it means we get the latest in toolchain support for hardware that the kernel supports.
(Aside: I'd love for there to be a separate, standalone PPA we could use for Intel's GPU tool stack, but I haven't found one and have no idea how to make one.)
We constantly release updates in a rolling release fashion, the ISOs are point releases to summarize the bug fix and feature work and accompany them with polished release notes and some additional testing, both focused for new changes but also for existing features all over the place.
We do not publish a strict plan for planned ISO releases as we want to retain the flexibility to release them as we see fit and users get new fixes already constantly anyway, so waiting for a new point release is not a requirement.
But for most of our projects we target two such stable point releases per year, and FWIW, the next one will be due very soon.
We do not publish a strict plan for planned ISO releases as we want to retain the flexibility to release them as we see fit and users get new fixes already constantly anyway, so waiting for a new point release is not a requirement.
But for most of our projects we target two such stable point releases per year, and FWIW, the next one will be due very soon.
FWIW, you can get the roadmap with changes and intended features on [1] and get detailed changelog of every component checking the debian/changelog file in each git repo, i.e. for pve-manager check [2]. Keep in mind that newest packages might not be present in any repo yet, just be patient
[1] https://pve.proxmox.com/wiki/Roadmap
[2] https://git.proxmox.com/?p=pve-manager.git;a=blob;f=debian/changelog;hb=HEAD
Hi, I'm slightly confused by "supported at least as long as the corresponding Debian Version is oldstable".
Debian 11 Bullseye was still oldstable until 2025 when Debian 13 Trixie was released, wasn't it? I checked archived versions of https://web.archive.org/web/20250720170857/https://wiki.debian.org/DebianOldStable/ and they still read "Bullseye is the current oldstable" up until recently. My understanding is that "oldstable" only becomes "oldoldstable" when a new "stable" version is released, so 4 years after the initial release.
And yet Proxmox VE 7 only supported until 2024 (3 years after the initial release)? Shouldn't the FAQ point to https://www.debian.org/security/faq#lifespan instead and state that Proxmox is "supported at least as long as the corresponding Debian version is supported"?
Debian 11 Bullseye was still oldstable until 2025 when Debian 13 Trixie was released, wasn't it? I checked archived versions of https://web.archive.org/web/20250720170857/https://wiki.debian.org/DebianOldStable/ and they still read "Bullseye is the current oldstable" up until recently. My understanding is that "oldstable" only becomes "oldoldstable" when a new "stable" version is released, so 4 years after the initial release.
And yet Proxmox VE 7 only supported until 2024 (3 years after the initial release)? Shouldn't the FAQ point to https://www.debian.org/security/faq#lifespan instead and state that Proxmox is "supported at least as long as the corresponding Debian version is supported"?
hi,
i think you're correct that we should improve the wording and reference here. If you want you can open a bu on https://bugzilla.proxmox.com/ so that we can better track it (and you can get updates when/if we fix it)
Thanks @dcsapak, I created https://bugzilla.proxmox.com/show_bug.cgi?id=6728.
Hi,
has somebody already verified if Proxmox VE 8.x and 9.0 are impacted by the Shai-Hulud supply chain attack, which Socket and some other channels have reported on since August?
Due to the number of packages, which have apparently been found to being compromised, our partner wanted a confirmation whether Proxmox includes or references any of these packages.
has somebody already verified if Proxmox VE 8.x and 9.0 are impacted by the Shai-Hulud supply chain attack, which Socket and some other channels have reported on since August?
Due to the number of packages, which have apparently been found to being compromised, our partner wanted a confirmation whether Proxmox includes or references any of these packages.
Last edited:
I doubt this since afik ProxmoxVE doesn't use any npm packages and no security advisory on that attack is eported in the related forum section:
https://forum.proxmox.com/forums/security-advisories.26/
The latest advisoryies cover some issue with the default ssl keys in Debian lxc templates, an issue with, a possible vm breakout related to spectre and an issue with vnc/spice-terminals.
This a little bit pointless to be honest. Since ProxmoxVE in the end is a Debian Linux of course one of the administrators could have installed some npm-related package not included in the default install. But this is not covered by the security advisories of ProxmoxVE (you will need to look at the Debian security advisories for that: https://www.debian.org/security/ ) and admins should know whether they installed something related to npm or not. Is your partner the department of energy or another organisation who pester open source projects after their vulnerability scanner/security snakeoil/compilance theater product runs wild? https://daniel.haxx.se/blog/2024/08/14/so-the-department-of-energy-emailed-me/
Last edited:
We do not rely on npm for our user interfaces; the current Proxmox VE web interface uses only ExtJS and our own libraries.
Some of the projects we reuse use npm themselves though, such as xterm.js and noVNC, but we also vendor these completely and only update them when there is a new release, after vetting and testing the newly pulled-in code internally first. Neither of these projects has been updated in the last three months, so they cannot be affected by the attacks you mention even if we had missed something, as those attacks only occurred in the last month, and mainly in the last two weeks.
We mirror anything we rely on internally and publicly on https://git.proxmox.com/. We do not pull any dependencies directly from the internet when building; rather, we use Debian packages as dependencies, which are hosted on our infrastructure and that of Debian.
In other words, while there are always things to re-evaluate and improve as time goes on and attacks become more sophisticated, we try hard to avoid supply chain attacks by strictly controlling and mirroring our dependencies.
For the sake of completeness: The next-generation web user interfaces – i.e. those used for PDM and the new mobile UI for PVE – are based on Yew and written in the Rust programming language. Here, we also mirror relevant dependencies or write and host the code ourselves.
Last edited:
Thank you for the quick and thorough explanation. That confirmation was enough for our partner. Best regards, Florian