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