Proxmox 8 to 9 Upgrade: The Complete Post-EOL Guide (Without Bricking Your Cluster)

A Proxmox 8 to 9 upgrade is no longer optional. Proxmox VE 8 reached end of life in August 2026. Since then, the Proxmox-specific packages on the 8 branch get no fixes. That includes the kernel, QEMU, the container stack and the Ceph builds.

The tricky part is that nothing tells you. Your Debian 12 base still gets security updates through Debian LTS until 30 June 2028, so apt upgrade keeps installing patches and looks healthy. The Proxmox kernel is built from Ubuntu’s kernel, not Debian’s, so Debian LTS doesn’t cover it. A node on 8.x can sit with open kernel advisories while every dashboard shows green.

This guide covers the full upgrade path for standalone hosts and clusters. It includes the pre-flight checks, the repository changes, Ceph, and the failure modes that cause most broken upgrades.

Table of Contents

1. Technical Overview & Background
2. What Changed in Proxmox VE 9
3. Core System Prerequisites
4. Step-by-Step Implementation Guide
5. Cluster Rolling Upgrade Procedure
6. Architecture & Component Breakdown
7. Real-World Use Cases & Enterprise Examples
8. Troubleshooting, Edge Cases & Best Practices
9. FAQ
10. Summary & Key Takeaways

Technical Overview & Background

Proxmox Virtual Environment (Proxmox VE) is an open-source virtualization platform from Proxmox Server Solutions GmbH in Vienna. It combines KVM/QEMU for full virtual machines and LXC for system containers. Both are managed through one web interface, a REST API and a CLI.

Every major Proxmox VE release follows a major Debian release:

So a major Proxmox upgrade is really two upgrades at once: a Debian dist-upgrade (Bookworm → Trixie) and a Proxmox stack upgrade (kernel, QEMU, LXC, ZFS, Ceph, pve-manager). Most failures come from that Debian layer: repositories, bootloaders, network naming and removed legacy features.

Why “it still works” is not a strategy

After EOL, three risks build up quietly:

• Unpatched hypervisor kernel. Any guest-to-host escape CVE stays open.
• Unpatched QEMU. Device-emulation bugs are the classic VM-escape path.
• Vendor support. Proxmox enterprise support and most MSP insurance or compliance frameworks (Cyber Essentials, ISO 27001 audits) expect a supported release.

If you got to Proxmox through a VMware exit, staying on a stale branch brings back exactly the risk you left VMware to avoid. You can read more in our VMware licensing in 2026 breakdown. If the migration itself is still giving you trouble, start with five reasons VMware to Proxmox migrations fail.

What Changed in Proxmox VE 9

Proxmox VE 9 is more than a rebuild on a new Debian. These are the changes that matter for planning:

• Debian 13 “Trixie” base. It brings newer system libraries, deb822-format APT sources, and /tmp on tmpfs by default (sized up to half your RAM).
• Newer kernel series. 9.0 shipped with Linux 6.14, and later point releases moved to newer kernels. Always confirm with uname -r rather than assuming.
• cgroup v1 removed entirely. There is no kernel parameter to bring it back.
• HA groups replaced by HA rules. Existing groups migrate automatically once every cluster node is on 9.
• ZFS 2.3+ with RAIDZ expansion. You can add a single disk to an existing RAIDZ vdev online.
• OCI images as LXC templates (tech preview, 9.1+). You can pull container images from registries and run them as LXC.
• /etc/sysctl.conf is no longer read. Settings must live in /etc/sysctl.d/*.conf.
• Ceph Squid (19.2) is the supported Ceph release for the upgrade path.

Core System Prerequisites

Don’t start a Proxmox 8 to 9 upgrade until every item below is checked.

Version and platform requirements

1. Every node on the latest Proxmox VE 8.4. pve-manager must be 8.4.1 or newer. Don’t jump straight from 8.2 or older.
2. Hyper-converged Ceph on Squid 19.2 before you touch Proxmox. Reef → Squid is a separate, mandatory first step.
3. Proxmox Backup Server. If you use PBS, plan to move it to PBS 4 (also on Trixie). PBS 3 can still receive backups during the transition.
4. At least 5 GB free on /, ideally 10 GB or more.
5. Console access that doesn’t depend on the host’s network: IPMI, iDRAC, iLO or a physical KVM. Network interface names can change during this upgrade.

Data-safety requirements

• A verified backup of every guest, restore-tested at least once.
• A copy of /etc, especially /etc/pve, /etc/network/interfaces and /etc/apt/.
• A maintenance window. Plan 5–10 minutes per node on SSD and modern hardware, or 30–60+ minutes on older HDD-based systems, plus a reboot.

Guest compatibility requirements

• No LXC containers running systemd 230 or older. That means CentOS 7, Ubuntu 16.04, Debian 8 and similar. They won’t boot without cgroup v1. Upgrade or migrate them into VMs first.
• NVIDIA vGPU users: move to a driver branch that supports the new kernel before upgrading.

Step-by-Step Implementation Guide

The steps below cover a Proxmox 8 to 9 upgrade on a single node. For clusters, repeat them node by node using the rolling procedure in the next section.

Step 1 — Bring the node fully up to date on 8.4

apt update && apt dist-upgrade -y
pveversion
# Expect: pve-manager/8.4.x (8.4.1 or newer)

Step 2 — Run the upgrade checker

pve8to9 only reads and reports. It changes nothing.

pve8to9 --full

Fix every FAIL and read every WARN. The common findings are:

Run the checker again until it’s clean.

Step 3 — Back up configuration and snapshot critical guests

tar czf /root/pre-pve9-etc-$(hostname)-$(date +%F).tar.gz /etc

# Optional: quick rollback point for VMs on snapshot-capable storage
for id in $(qm list | awk 'NR>1 {print $1}'); do
  qm snapshot "$id" pre-pve9-upgrade --vmstate 0
done

Snapshots are not backups. Use them only for a quick guest rollback. Your real safety net is the restore-tested PBS or vzdump backup.

Step 4 — Pin network interface names

Trixie’s newer kernel and systemd can rename NICs, for example eno1 to enp1s0f0. If that happens, vmbr0 comes up with no port and the node drops off the network. Pin the current names first:

pve-network-interface-pinning generate
# Review the generated .link files and the updated /etc/network/interfaces

If the tool isn’t available on your 8.4 build, write systemd .link files by hand that match each MAC address to its current name.

Step 5 — Remove packages that block the upgrade

# A Debian stock kernel meta package makes apt want to remove proxmox-ve
dpkg -l | grep linux-image-amd64 && apt remove linux-image-amd64

# On UEFI + LVM systems, make sure the GRUB EFI package is present
[ -d /sys/firmware/efi ] && apt install grub-efi-amd64

Step 6 — Switch repositories to Trixie (deb822 format)

Proxmox VE 9 uses deb822 .sources files. First, comment out or delete the old .list entries so the two releases never mix. Then create the new files.

/etc/apt/sources.list.d/debian.sources:

Types: deb
URIs: http://deb.debian.org/debian/
Suites: trixie trixie-updates
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://security.debian.org/debian-security/
Suites: trixie-security
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

/etc/apt/sources.list.d/proxmox.sources (no-subscription example):

Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

With a subscription, use URIs: https://enterprise.proxmox.com/debian/pve and Components: pve-enterprise instead. Never enable both.

/etc/apt/sources.list.d/ceph.sources (only if you run Ceph):

Types: deb
URIs: http://download.proxmox.com/debian/ceph-squid
Suites: trixie
Components: no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Then check that no Bookworm entries are left:

grep -rn bookworm /etc/apt/sources.list /etc/apt/sources.list.d/ || echo "clean"
apt update

Tip: Once the node runs Trixie’s APT, apt modernize-sources can convert any leftover .list files to deb822 automatically.

Step 7 — Run the distribution upgrade

Run this inside tmux or screen, or from the IPMI console, so an SSH drop doesn’t kill dpkg halfway through:

apt install -y tmux && tmux new -s pve9
apt dist-upgrade

When asked about configuration files:

• /etc/issue: accept the maintainer’s version (Y).
• /etc/lvm/lvm.conf: accept the maintainer’s version unless you made deliberate custom filters.
• /etc/ssh/sshd_config: keep yours (N) if you hardened it. Otherwise accept.
• /etc/default/grub: keep yours if you added kernel parameters such as IOMMU flags.

Stop and investigate if APT says it wants to REMOVE proxmox-ve. That almost always means mixed repositories or a stock Debian kernel package is still installed.

Step 8 — Reboot and verify

reboot

After boot:

pveversion                 # pve-manager/9.x.x
uname -r                   # a 6.14+ -pve kernel
systemctl --failed         # should list 0 units
pvesm status               # all storages active
qm list && pct list        # guests visible
curl -sk https://localhost:8006 >/dev/null && echo "GUI OK"

Step 9 — Clean up after the upgrade

# Move legacy sysctl settings (sysctl.conf is ignored on Trixie)
[ -s /etc/sysctl.conf ] && grep -v '^\s*#' /etc/sysctl.conf | grep . \
  > /etc/sysctl.d/99-legacy.conf && sysctl --system

# Drop old snapshots once you are confident
for id in $(qm list | awk 'NR>1 {print $1}'); do
  qm delsnapshot "$id" pre-pve9-upgrade 2>/dev/null
done
apt autoremove --purge

Cluster Rolling Upgrade Procedure

A clustered Proxmox 8 to 9 upgrade runs one node at a time. Quorum and running workloads stay up the whole time.

Phase A — Preparation (all nodes)

1. Run pve8to9 --full on every node and fix the findings.
2. Upgrade Ceph Reef → Squid cluster-wide:

ceph status                       # must be HEALTH_OK
ceph osd set noout
# upgrade Ceph packages node by node, restarting MONs, then MGRs, then OSDs
ceph versions                     # all daemons report 19.2.x
ceph osd unset noout

3. Upgrade PBS to version 4 if needed.

Phase B — Per node, one at a time

# 1. Drain the node (HA-managed guests migrate automatically)
ha-manager crm-command node-maintenance enable <node>

# 2. Live-migrate any remaining guests
qm migrate <vmid> <target-node> --online

# 3. Perform Steps 3–8 above on this node

# 4. Confirm cluster health, then return the node to service
pvecm status
ha-manager crm-command node-maintenance disable <node>

Migration direction matters. Live migration from an 8 → 9 node works. 9 → 8 isn’t supported. Upgrade the nodes you’ll move workloads onto first.

Phase C — After the last node

• HA groups are converted to HA rules automatically. Check them under Datacenter → HA → Rules.
• Run pvecm status (Quorate: Yes) and ceph status (HEALTH_OK).
• Set ceph osd require-osd-release squid if your Ceph upgrade notes call for it.

Architecture & Component Breakdown

Knowing what each layer does during a Proxmox 8 to 9 upgrade makes it easier to diagnose failures:

Diagram — upgrade decision flow (summary)

[8.4.1+ on all nodes?] --no--> upgrade within 8.x
        | yes
[pve8to9 --full clean?] --no--> fix FAIL/WARN, rerun
        | yes
[Ceph in use?] --yes--> Reef -> Squid first
        |
[Backups verified + console access?] --no--> stop
        | yes
Pin NICs -> deb822 repos -> dist-upgrade -> reboot -> verify -> next node

Real-World Use Cases & Enterprise Examples

1. MSP with ~40 standalone client hosts

For MSPs, the Proxmox 8 to 9 upgrade is mostly a fleet problem. Small-office Proxmox boxes (one node, local ZFS, nightly PBS sync) are the easy case but the most numerous. The usual pattern:

• Script Steps 1–6 with Ansible and stage them across the fleet.
• Run Step 7 by hand during each client’s maintenance window, from out-of-band console.
• Track progress with a simple pveversion inventory pulled from your RMM.

The main risk is the NIC rename. One unpinned host with no IPMI means a site visit. Pin first, every time.

2. Three-node hyper-converged cluster (Ceph) — mid-market

This is the classic VMware vSAN replacement. Done properly, the upgrade takes two maintenance windows: one for Ceph Reef → Squid, one for the Proxmox rolling upgrade. Because guests are live-migrated, planned VM downtime should be close to zero.

3. Homelab or lab clusters with legacy containers

Labs often still run a CentOS 7 LXC or an Ubuntu 16.04 build agent. Those are exactly the guests that fail silently after the upgrade. Convert them to VMs or rebuild them on a supported distribution beforehand.

4. Compliance-driven organisations

For audits, an EOL hypervisor is usually a finding even when no CVE is open. Write down the upgrade (date, pveversion output, checker results) as evidence of a supported platform.

Troubleshooting, Edge Cases & Best Practices

apt wants to remove proxmox-ve

Cause: mixed Bookworm/Trixie repositories, or linux-image-amd64 is installed.
Fix: answer No. Then run grep -rn bookworm /etc/apt/, remove the stock kernel meta package, apt update, and try again.

401 Unauthorized from enterprise.proxmox.com

Cause: the enterprise repository is enabled without a valid subscription.
Fix: disable it, or use the pve-no-subscription component.

Node boots but has no network

Cause: the interface was renamed, so vmbr0‘s bridge-ports points at a name that no longer exists.
Fix: from the console, run ip -br link to find the new name. Then either update /etc/network/interfaces and ifreload -a, or pin the old name with a .link file.

Host drops to the GRUB rescue prompt (UEFI + LVM)

Cause: the GRUB EFI package wasn’t installed or refreshed.
Fix: boot from the Proxmox ISO’s rescue mode, chroot in, run apt install grub-efi-amd64, then update-grub or proxmox-boot-tool refresh.

LXC container won’t start

pct start <ctid> --debug
journalctl -u pve-container@<ctid> -b

If the logs mention cgroup or systemd failures on an old distribution, the guest needs an OS upgrade or a move to a VM.

LVM-thin pool fails to activate

lvchange -an pve/data
lvconvert --repair pve/data
lvchange -ay pve/data

Take a backup of the PV metadata first (vgcfgbackup). If the thin pool looks full while guests report free space, that’s a separate discard problem. See why Proxmox shows the disk 100% full.

VM won’t start on the upgraded node during a rolling upgrade

Cause: the VM’s CPU type isn’t available on the target, or there’s a machine-version difference.
Fix: use a common baseline CPU model (for example x86-64-v2-AES) on mixed-hardware clusters.

Best practices

• Upgrade a test or least-critical node first and let it run under load for 24–48 hours.
• Never have two nodes down at once in a three-node cluster.
• Keep the old kernel bootable until you’re confident in the new one.
• Re-run backups right after the upgrade to confirm PBS integration still works.
• Record everything (checker output, config prompts and their answers) for the next major upgrade.

FAQ

Summary & Key Takeaways

Proxmox VE 8’s end of life is quiet. Nothing breaks on the day support ends. Instead, the risk builds up in the unpatched kernel and QEMU layers while apt keeps reporting success. A Proxmox 8 to 9 upgrade done in the right order is a routine maintenance task. Done carelessly, it can leave nodes without a network or a bootloader.

Key takeaways:

• PVE 8 EOL: August 2026. Debian LTS doesn’t cover the Proxmox kernel.
• Prerequisites: 8.4.1+ on every node, Ceph Squid 19.2, verified backups, and out-of-band console access.
• Always run pve8to9 --full until there are no FAILs left.
• Pin NIC names before upgrading. This is the most common cause of a lost node.
• Switch to deb822 Trixie repositories and never mix suites or enterprise/no-subscription repos.
• Clusters: use rolling upgrades with maintenance mode, migrate 8 → 9 only, and never take two nodes down at once.
• After the upgrade: move sysctl settings, check the HA rules, re-test backups and document the run.

Next in this series: Proxmox Backup Server 4 Setup: Dedup, Retention and Offsite Sync Done Right and Proxmox Cluster Setup: Quorum, QDevice and HA Rules Explained.

Editorial note: Commands were checked against the official Proxmox VE 8 to 9 upgrade wiki and the Proxmox VE roadmap and release notes. Always read the notes for your exact point release before production use.