Proxmox VE 8 end of life: why upgrade now and what changes in version 9

If your company has a server running virtual machines, there is a good chance it runs Proxmox VE 8: released in June 2023, it was the version everyone installed for three years. On 31 August 2026 it leaves support. From that day on Proxmox publishes no more fixes for version 8, neither for bugs nor for security holes. The web interface of version 8 has been showing a notice in the top bar for a while now, with the exact date.

Nothing visible happens. Servers stay on, virtual machines keep running, no counter expires. That is precisely the problem: a hypervisor (the software that runs virtual machines on a physical server) sits underneath everything else, and when it stops receiving patches the risk quietly moves onto every service it hosts.

Below: what end of support means in practice, what you risk by staying on 8, what breaks when moving to 9 and how to handle the upgrade without stopping the business. Everything comes from official Proxmox sources, linked at the bottom.

End of support: what it means for a hypervisor

Proxmox’s rule is public: every Proxmox VE version is supported at least as long as the Debian release it is built on is supported by the Debian security team, that is roughly three years from first release. Proxmox VE 8 is built on Debian 12 “Bookworm”, whose regular security support ended in mid 2026, and the official lifecycle table sets the end of support for Proxmox VE 8 at August 2026. The last update of the 8 branch, version 8.4.21, is dated 14 August.

One detail that creates confusion: Debian 12 now moves to LTS support, run by a separate group of volunteers and companies, until mid 2028. That support covers Debian packages, not Proxmox. The kernel, QEMU (the engine behind the virtual machines), LXC (containers), ZFS and the whole cluster management layer are packages maintained by Proxmox, and in version 8 they are no longer maintained. Relying on Debian LTS for an end-of-life hypervisor is a misunderstanding.

It is the same mechanism we described for PHP at end of life: the software does not stop working, it stops being defended. Only here the exposed surface is not a website, it is the whole server.

What you risk by staying on 8

Vulnerabilities with no fix. Flaws keep being discovered after support ends: only the distribution of fixes stops. Even in 2026 the 8.4 branch kept receiving security-relevant updates: in April the authentication of VNC and SPICE consoles was hardened, in August the privileges required to abort backups were tightened and some interface fields were protected from unfiltered content. From September, fixes of this kind no longer reach version 8. And a hole in the hypervisor is worth as much as a hole in every machine it hosts.

The ecosystem moves on. Proxmox Backup Server is already at version 4, the latest Ceph release (the integrated distributed storage) is only available from 9.2, third-party storage plugins are being adapted to 9. Support for new hardware arrives with recent kernels: Proxmox VE 9.2 ships kernel 7.0, version 8 stays on 6.8 (6.14 as an option). Whoever buys a server today and installs 8 on it may find that network cards or controllers are not recognized.

No shortcut later. Proxmox documents and supports only the step from one major version to the next: from 7 you go through 8, from 8 you reach 9, and the jump gets longer with every year you wait.

Compliance. For anyone processing personal data the GDPR asks for measures “appropriate to the state of the art”: as we saw when discussing GDPR from the infrastructure side, a component abandoned by its vendor is hard to defend as appropriate, and in case of an incident the hypervisor version ends up in the report.

What Proxmox VE 9 brings

Upgrading is not just removing a risk. Proxmox VE 9 came out in August 2025 on Debian 13 “Trixie” and is already at its third release (9.2, May 2026): a platform proven for a year, not a novelty to wait for.

Snapshots on shared thick-provisioned LVM storage, the typical setup of SANs over iSCSI or Fibre Channel: it was impossible before, now it works through volume chains (a technology preview, but it covers a very common case in small businesses with network storage). If those volumes are new to you, we explained what LVM is and how it manages disks.
Affinity rules for high availability: you declare that certain VMs must stay on certain nodes, or that two VMs must never land on the same node. With 9.2 comes dynamic load balancing, which moves VMs on its own from the busiest node to the least busy one.
ZFS 2.3 (2.4 in 9.2), which allows adding a disk to an existing RAID-Z without rebuilding it from scratch.
SDN fabrics (OpenFabric and OSPF, WireGuard and BGP from 9.2) to connect nodes with routed networks instead of hand-configured crossed cables: useful for full-mesh Ceph clusters.
Containers from OCI images (from 9.1): the same formats used for Docker become templates for LXC containers.
Updated kernel, QEMU and LXC (kernel 6.14 in 9.0 and 7.0 in 9.2, QEMU 10 then 11) and a new mobile interface.

What breaks: the backward incompatibilities

This is the part the official guide calls breaking changes, and it must be read before, not after. Translated into concrete situations:

Old containers. Version 9 drops support for cgroup v1, the old mechanism the kernel uses to assign resources to containers. Consequence: containers whose operating system is based on systemd version 230 or older (from 2016) no longer start. The examples Proxmox cites are CentOS 7 and Ubuntu 16.04. If you have any, the operating system inside the container must be migrated before upgrading the host, not after.
Network interface names can change with the new kernel, and if the configuration points to the old name the server comes back up without network. Proxmox provides a tool to pin the names before upgrading (pve-network-interface-pinning) and recommends an access path independent of the network (IPMI, iKVM or a physical console) so nobody has to rush to the server room.
Storage. GlusterFS is no longer supported: data must be moved elsewhere. Third-party storage plugins only work if their author adapted them to 9. On shared LVM volumes the official script that disables volume autoactivation must be run, to prevent several nodes from activating the same disks.
Old hardware. Proxmox states that hardware older than ten years is not thoroughly tested with the new kernel, cites AMD Opteron and Turion CPUs from 2009-2010 on which Ceph stops with an illegal instruction error, and reports that in some cases PCI passthrough (for example a GPU assigned to a VM) does not start with kernel 6.14. NVIDIA vGPU cards need at least the GRID 18.3 driver.
Third-party backup. Veeam does not work with VMs using QEMU machine version 10 or later; the workaround is pinning the machine version to 9.2 until Veeam catches up. Anyone running Proxmox Backup Server on the same machine must upgrade that too, to version 4, following its dedicated guide.
System details that do not forgive. The file /etc/sysctl.conf is no longer read (settings go into /etc/sysctl.d/), /tmp becomes an in-memory folder cleaned periodically, some permissions change (the VM.Monitor privilege disappears, VM.Replicate appears, creating privileged containers requires Sys.Modify), the maxfiles backup option is removed, VirtIO network cards without an explicit MTU inherit the bridge’s instead of 1500. Nothing dramatic, but all of it must be known in advance.

The point is not to scare: each of these items either does not concern you or gets solved before starting, and the difference is made by having checked them.

How to upgrade without stopping the business

Proxmox provides an official step-by-step guide and a tool, pve8to9, that checks the host and flags in advance everything listed above. The method we follow:

Inventory. How many hosts, which version (at least 8.4.1 is required), which storage, which Ceph (it must already be Squid 19.2), which containers and with which operating system, which hardware and from which year.
pve8to9 --full checklist on every node, fixing every warning before moving on. The tool only checks, it corrects nothing on its own.
Safety net. Verified backups of all VMs and containers following the 3-2-1 rule, a copy of the /etc configuration, out-of-band access to the server and at least 5 GB free on the system partition.
One node at a time. In a cluster you move the VMs to the other nodes with live migration, upgrade the empty node, reboot, verify, move to the next: services never stop. On a single host you need a maintenance window: the apt dist-upgrade alone takes from under five minutes on SSDs to over an hour on spinning disks, plus the reboot.
Final check. Reboot into the new kernel, check network and storage, automatic migration of HA groups into rules, browser cache cleared for the new interface, repositories moved to the new format.

For a clean install (for example on new hardware) there is also the reinstall-from-ISO path with VMs restored from backups: often the fastest route when you change server together with the version.

In short

Proxmox VE 8 does not switch off on 31 August 2026, but from that day every new flaw stays open on the server that holds all your virtual machines, and Debian LTS does not cover the Proxmox components. Version 9 has been mature for a year, brings snapshots on shared storage, smarter high availability and support for recent hardware, and the upgrade is a documented path: the delicate part is the incompatibilities (old containers, network names, storage, old hardware, third-party backup), all of which are found before starting with an inventory and the official checklist.

# Proxmox VE 8 end of life: why upgrade now and what changes in version 9