Upgrade Proxmox VE 8 to Proxmox VE 9 Before August 2026

Proxmox VE 8 stops receiving security patches on August 31, 2026, so the only way to keep your nodes patched is to upgrade to Proxmox VE 9 before that date. This guide takes you through the whole path — auditing the cluster, fixing the apt sources for the bookworm-to-trixie jump, upgrading one node at a time while keeping quorum, verifying every VM and container, and recovering a node that breaks mid-upgrade — so you land on a supported release with your workloads intact.

Key Takeaways

• EOL math: Proxmox VE 8 reaches end-of-life on August 31, 2026; no security updates ship after that, so the clock is already running.
• Audit before you upgrade: Take a version and guest inventory, then prove your backups by restoring one VM to a throwaway ID.
• Fix the suites early: Every repo entry has to move from bookworm to trixie or apt quietly keeps you on 8.x.
• One node at a time: Migrate workloads off each node and preserve quorum before moving to the next.
• Keep a rollback plan: Snapshot VMs and containers, and back up the host, so a broken upgrade is reversible.

Why the August 31, 2026 deadline matters

Proxmox VE follows a roughly three-year support window per major release. Proxmox VE 8, which ships on top of Debian 12 "Bookworm," stops being maintained on August 31, 2026. From September 1, the pve-no-subscription and enterprise repositories stop serving new packages for the bookworm suite, and no security advisories or bug-fix patches are released for 8.x.

That means a node still on 8.x after the deadline is exposed to unpatched vulnerabilities in the kernel, QEMU, LXC, and the web stack. There is no "extend the subscription" option for a dead release — the fix is to move to Proxmox VE 9, which rides Debian 13 "Trixie."

This is not a routine point upgrade. Moving from 8 to 9 is a distro-level jump: the kernel, glibc, and a large chunk of the userland change at once. Treat it like a platform migration, not a dist-upgrade you can blindfold and do overnight. Plan the window, back everything up, and verify the restore before you touch a single node.

How to audit your cluster before you touch a node

Start by capturing exactly what you are running. pveversion -v lists the kernel, pve-manager, qemu-server, and pve-docs versions across the cluster, and pvecm status confirms quorum and lists every node.

pveversion -v
pvecm status

Then inventory the guests so you know what has to survive the upgrade. qm list shows KVM VMs and pct list shows LXC containers; note which ones are on local storage, which run as Proxmox HA resources, and which hold the most important workloads.

qm list
pct list

This is also the moment to sanity-check footprint. The right-sizing thinking in Avoid DDR5 RAM Surge: Right-Size Proxmox VMs & Containers applies here, because a major upgrade is the worst time to discover a VM that silently eats 16 GB of RAM and leaves no headroom on the new kernel.

If you already run the homelab scripts from Automate Proxmox VE: Essential Scripts for Homelab Backups, Health Checks & VLANs, reuse its health-check and backup functions to baseline connectivity and storage before the upgrade.

Now prove your backups actually work. A backup you have never restored is a hypothesis, not a safety net. Create a snapshot-mode backup of a representative VM and restore it to a throwaway ID:

vzdump 100 --storage local --mode snapshot --compress zstd

The command prints the archive path, usually /var/backups/vzdump-qemu-100-2026_08_30-03_00_00.vma.zst. For a three-node homelab with around 40 VMs and a few hundred containers, those backups often total between 500 GB and 2 TB, so confirm your target storage can hold a full set. Restore the archive to VMID 199, boot it, and confirm it comes up and reaches the network:

vzdump --restore /var/backups/vzdump-qemu-100-2026_08_30-03_00_00.vma.zst local 199
qm start 199

Log in, verify the application and its data, then tear the test VM down so it never accidentally competes with the real one during the upgrade:

qm stop 199
qm destroy 199 --purge

If your backups already live on Proxmox Backup Server, review the sync model in Automated Backups with Proxmox Backup Server and confirm the latest snapshot exists and is intact before you proceed.

The repository fix nobody likes to talk about

A major Proxmox upgrade fails most often at the apt stage, not the upgrade itself. The free pve-no-subscription repository on PVE 8 points at the bookworm suite, and if you forget to move it to trixie, apt full-upgrade simply resolves against the old suite and keeps you on 8.x — sometimes with a warning you skim past.

Inspect the current sources before changing anything. Back them up first, then look:

cp /etc/apt/sources.list.d/pve-no-subscription.list /etc/apt/sources.list.d/pve-no-subscription.list.bak
cat /etc/apt/sources.list.d/pve-no-subscription.list
cat /etc/apt/sources.list

The PVE 8 entries read ... bookworm main contrib. You need trixie in every suite line. Edit /etc/apt/sources.list.d/pve-no-subscription.list so it reads:

deb http://ftp.proxmox.com/debian/pve trixie main contrib

Do the same for the Debian main entries in /etc/apt/sources.list, moving every bookworm, bookworm-updates, and bookworm-security line to trixie, trixie-updates, and trixie-security:

deb http://deb.debian.org/debian trixie main contrib
deb http://deb.debian.org/debian trixie-updates main contrib
deb http://security.debian.org/debian-security trixie-security main contrib

If your distribution includes a backup repository, update it too:

deb http://ftp.proxmox.com/debian/backups trixie main contrib

Here is the no-subscription pitfall on the enterprise side: /etc/apt/sources.list.d/pve-enterprise.list is commented out by default for non-subscription users, and if you have ever uncommented it, apt update will start erroring on a repo you cannot authenticate against. Leave it commented unless you hold a valid subscription:

# deb http://enterprise.proxmox.com/debian/pve trixie main

Run apt update and confirm the package lists resolve to trixie with no errors before moving on. This single step is what separates a clean upgrade from a half-migrated node.

The node-by-node rolling upgrade order

Upgrading a cluster means temporarily taking nodes offline, so the whole game is quorum. A three-node cluster needs two nodes online to hold quorum, which means you can only ever take one node down at a time. Take two offline and the cluster splits; HA may then start your VMs on the remaining node, or worse, leave them stopped.

Decide an order and stick to it. For a three-node cluster (pve1, pve2, pve3) the order is flexible, but upgrade the node holding the fewest critical workloads first so a problem there costs the least. Always keep at least two nodes online between steps.

Before you upgrade a node, move its guests off it. If HA is enabled, those VMs relocate automatically; if not, migrate them manually. For guests on shared storage:

qm migrate 100 pve2 --online

For guests that live on local storage only, add --with-local-disks so the migration copies the disk:

qm migrate 100 pve2 --online --with-local-disks

Once the node is empty of active workloads, run the upgrade on it, then verify quorum returns before touching the next node.

pvecm status

You want to see all remaining nodes listed and Quorum: Yes. If a node stays down longer than expected, HA will relocate its VMs — fine when HA is on, a problem when it is not, which is exactly why you migrate first. Never start the upgrade while a large backup or a storage resync is running; let those finish so the upgrade has CPU and disk headroom.

How do you actually run the upgrade?

There are two paths, and both end at the same place. The choice is between an interactive helper and a manual, fully visible sequence.

Aspect	proxmox-upgrade	Manual sources + apt
Suite switching	The script guides the bookworm-to-trixie move	You edit each sources file yourself
Visibility	Mostly a black box	You see every package change
Speed	Faster end to end	Slower, but you control each step
Best for	A quick, single jump	An audited, controlled cluster upgrade

If you trust the helper, run it and follow the prompts:

proxmox-upgrade

It updates the repository suites and walks you through the dist-upgrade. If you prefer full visibility — which I recommend for a first 8-to-9 run — do it by hand. Make sure you are on the latest 8.x first, then reboot if the kernel changed:

apt update
apt full-upgrade

Then perform the major jump. With the suites already pointed at trixie (see the previous section), run:

apt update
apt full-upgrade

apt will pull in the new pve-kernel, pve-manager, and qemu-server packages. The new kernel installs but does not run until you reboot, so plan for one restart per node. From apt full-upgrade to the