Proxmox VE 8 hits end of support: plan the VE 9 migration as two windows, not one weekend
The Proxmox VE 8 branch, released in June 2023 on Debian 12, reaches end of life in August 2026: hypervisor patches stop even though Debian LTS continues. For anyone running Ceph or old containers, the VE 9 upgrade is two separate projects — and a rollback that goes through restore, not reverse migration.
August 2026. The Proxmox VE 8 branch, released in June 2023 on a Debian 12 (Bookworm) base, reaches its end of life — the official documentation sets the deadline at August 2026. The reflex is to block out a weekend to jump to Proxmox VE 9. For a good share of fleets, that is the wrong call: the migration hides two chained projects, and a rollback plan that does not exist.
What actually stops, and what continues
The lifecycle table in the Proxmox FAQ is unambiguous. Proxmox VE 8 (base Debian 12, first release 2023-06) has an end of life of 2026-08; Proxmox VE 9 (base Debian 13 Trixie) shipped in 2025-08. The document speaks in months, not days: nothing switches off on September 1, no license expires, and the cluster keeps booting. What stops is the arrival of new packages: fixes for the Proxmox kernel, for QEMU, for the pve-* packages themselves.
This is where the nuance matters. Debian 12 left regular security support on July 12, 2026 and moved to the LTS team, maintained until June 30, 2028. That safety net is real — but it only covers Debian packages. The hypervisor is not one of them: pve-manager, qemu-server, the Proxmox kernel, and the Ceph packaging all come from Proxmox’s own repositories. When branch 8 falls, it is precisely the part that runs your machines that stops receiving fixes. You keep getting OpenSSL patches; not hypervisor ones.
The rollback trap
The official 8 → 9 migration states a rule that reads fast and sinks in late: moving a VM or container from an older version to a newer one always works; the other direction « may work, but is generally not supported ». Translated into Saturday night: the moment you upgrade the first node and move workloads onto it, you can no longer count on moving that workload back to the node still on 8.
That changes the nature of plan B. Plenty of people walk into the window thinking their rollback is « I migrate the VMs back to the other node ». It is not: the rollback is restoring from backup, with the restore time that implies and the hours of data lost in between. If you have never timed a full restore of the three machines that actually matter, you do not have a plan B — you have a hope.
Ceph: not one window, but two
The requirement sits in the wiki, in bold: if you run hyperconverged Ceph on Quincy or Reef, you must take it to Ceph 19.2 Squid first, before starting the Proxmox upgrade. Before, not during. And upgrading Ceph on a cluster with live data has its own rhythm: OSD by OSD, checking cluster health between steps, without rushing — because rushing under Ceph is paid for in backfill.
Anyone with this still pending while staring at the August calendar already knows the answer: it does not fit in a weekend. The first half fits, the second half lands in September. Checking costs one command and avoids an unpleasant conversation halfway through the window:
# Ceph version on the cluster
ceph --version
ceph versions
# Official checker, on EVERY node, with --full
pve8to9 --fullpve8to9 ships with recent 8.4 packages and only checks and reports: by default it changes nothing. It is the most underrated tool in the whole process — run it today, not the night of the window, because its value is handing you the homework list while there is still time to do it.
The containers that will not start
This is the blocker that always shows up late. Proxmox VE 9 does not support containers running systemd 230 or older — a 2016 release — which in practice means CentOS 7, Ubuntu 16.04, and their relatives. And those containers exist: they are precisely the ones nobody wants to touch, running the application whose author has since retired.
Sorting it out means moving that application onto a new operating system, with the testing and sign-off from its users that this implies. If you find out at eleven on Saturday night, your realistic option is to leave that container on a node you do not upgrade, and end up with a half-upgraded cluster. If you find out today, you have a month to decide whether that application deserves a migration, a dedicated VM, or retirement.
When August is not the moment
The rule is simple: if any one of these is true, the migration moves to September, with a containment plan for the month without patches.
- Ceph still on Quincy or Reef. Squid first, in its own window.
- Old-systemd containers with no decision on where they go.
- No out-of-band access to the node (IPMI, iDRAC, iLO) — the new kernel can rename network interfaces.
- A restore that has never been timed — plan B runs through restore.
pve8to9 --fullreturns warnings you do not understand.- The window lands on a month-end close, a payroll run, or a business peak, or the people who know the system are on holiday.
Verdict
If you run a single-node homelab with no Ceph and no exotic containers, move to Proxmox VE 9 this month on the wiki’s in-place path: latest 8.4, 5 GB free on root (preferably 10), a tmux session, one node at a time. You gain a supported branch with little risk. If you run a cluster with Ceph or old containers, split the job into two windows — Ceph to Squid first, Proxmox after — and drain each node before touching it: the node you touch should carry nothing when it breaks. And if the calendar does not fit, own it cleanly: management interface off the internet, restores actually timed before the new window, and August spent on preparation — pve8to9 --full, container inventory, Ceph to Squid. Being late with a standing cluster is recoverable; being on time with a node that will not boot is not.