Proxmox VE 8 to 9 Upgrade: Guide for Clusters with Ceph, PBS and HA

Proxmox Management & Maintenance by WZ-IT? We assess the current state and plan the upgrade to PVE 9, including existing dependencies on Ceph, PBS, and HA. Ongoing Proxmox maintenance costs from €179.90 net per node and month; major upgrades such as PVE 8 to 9 are confirmed in advance as a separate scope. Schedule a free initial call

Proxmox VE 8: end of support in August 2026

Proxmox VE 8 reached end of life in August 2026 (support lifecycle). Since then Proxmox ships no security updates, no bugfixes and no support for PVE 8; this covers the kernel, QEMU, LXC and all Proxmox packages. The Debian 12 base ("Bookworm") still receives security updates via Debian LTS until 30 June 2028 (Debian announcement), but the Proxmox layer on top stays unpatched. If you still run production workloads on PVE 8, schedule the upgrade immediately (as of October 2026).

This guide walks you through the upgrade to Proxmox VE 9 (Debian 13 "Trixie") step by step - with special focus on enterprise setups with Ceph clusters, Proxmox Backup Server and High Availability.

Table of Contents

• Proxmox VE 8: end of support in August 2026
• What's new in Proxmox 9? Differences from PVE 8
• Prerequisites
• Step 1: Ensure PVE 8.4.1
• Step 2: Create backups
• Step 3: Run the upgrade check with pve8to9
• Step 4: Upgrade Ceph to Squid
• Step 5: Upgrade PBS to version 4
• Step 6: Update APT repositories
• Step 7: Run the upgrade
• Step 8: Post-upgrade checks
• Cluster upgrade strategy
• Common mistakes and how to avoid them
• How WZ-IT handles upgrades

What's new in Proxmox 9? Differences from PVE 8

Proxmox VE 9.0 was released on 5 August 2025. The current version is PVE 9.2, released on 21 May 2026 (roadmap). Key improvements across the 9.x series and the current release compared with PVE 8 include:

Infrastructure:

• Debian 13.5 "Trixie" as the base (PVE 8: Debian 12 "Bookworm")
• Linux kernel 7.0
• QEMU 11 and ZFS 2.4

Enterprise features:

• Dynamic load balancer: The cluster resource scheduler considers current utilization when placing HA-managed guests
• HA arm/disarm: The HA stack can be suspended and re-enabled in a controlled way for planned work
• WireGuard and BGP fabrics: New SDN fabric protocols and more granular BGP and EVPN filters
• Custom CPU models: CPU profiles and supported flags can be managed and reviewed centrally in the interface
• HA Rules replace HA Groups: More flexible resource-to-node and resource-to-resource affinity introduced with PVE 9.0
• OCI containers in LXC: OCI images can be used as LXC templates since PVE 9.1; the feature still needs to be assessed for the specific workload

Prerequisites

Before starting, verify this checklist:

Step 1: Ensure PVE 8.4.1

Update all nodes to the latest version first:

apt update && apt dist-upgrade
pveversion

Output must show pve-manager/8.4.1 or higher.

Step 2: Create backups

Non-negotiable. Before every major upgrade:

# Back up all VMs and containers (PBS or local storage)
vzdump --all --mode snapshot --storage your-backup-storage

# Back up Proxmox configuration
tar czf /root/pve-config-backup-$(date +%Y%m%d).tar.gz /etc/pve/

# If using Ceph: document Ceph status
ceph status > /root/ceph-status-pre-upgrade.txt
ceph osd tree > /root/ceph-osd-tree-pre-upgrade.txt

Step 3: Run the upgrade check with pve8to9

Proxmox ships a diagnostic tool that detects potential issues before the upgrade:

pve8to9 --full

The tool checks repository configuration, storage settings, deprecated options, package versions and container compatibility.

Resolve FAIL entries before upgrading. Assess each WARN entry individually and implement the required actions. For affected volumes on shared LVM storage, Proxmox strongly recommends disabling autoactivation using /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation.

For clusters: run pve8to9 --full on every node before upgrading the first one.

Step 4: Upgrade Ceph to Squid

If you're running Ceph, this step is mandatory before the PVE upgrade. The starting point is Ceph Reef (18.2.4-pve3 or newer) on PVE 8.2.8 or newer, and the cluster must be healthy. The procedure follows the official guide Ceph Reef to Squid:

# Check Ceph status (must be HEALTH_OK)
ceph status

# On each node: switch the Ceph source from Reef to Squid (PVE 8, Bookworm)
sed -i 's/reef/squid/' /etc/apt/sources.list.d/ceph.list

# Once per cluster: set the noout flag
ceph osd set noout

# On each node: upgrade the packages (the services still run Reef afterwards)
apt update
apt full-upgrade

# Restart monitors, one node at a time, then check the status
systemctl restart ceph-mon.target
ceph mon dump | grep min_mon_release   # expected: min_mon_release 19 (squid)

# Restart managers and OSDs (OSDs on one node at a time, check ceph status afterwards)
systemctl restart ceph-mgr.target
systemctl restart ceph-osd.target

# Once all OSDs report Squid: enable Squid-only functionality
ceph osd require-osd-release squid

# Remove the noout flag again
ceph osd unset noout

With CephFS, the MDS daemons follow the section "Upgrade all CephFS MDS daemons" of the guide.

After the PVE upgrade, Proxmox describes the move from Ceph Squid to Tentacle (20.2) as a separate step for PVE 9.1 or newer: Ceph Squid to Tentacle. PVE 9.2 lists Tentacle 20.2 as a stable option next to Squid 19.2 (roadmap). Design and operation of Ceph clusters: Proxmox Ceph.

Step 5: Upgrade PBS to version 4

If Proxmox Backup Server runs co-installed on a PVE node, the official upgrade path refers to the separate guide PBS 3 to 4; both can be upgraded together by combining the step in which the APT repositories are changed. The guide does not list a separate PBS host as a prerequisite; we still upgrade it beforehand so client and server are on the same level. PBS 4 is also based on Debian 13 and is compatible with PVE 9. For a separate PBS host the procedure of the PBS guide applies; the prerequisite is PBS 3.4.2 or newer:

# On the PBS host: run the upgrade check and verify the version
pbs3to4 --full
proxmox-backup-manager versions

# Switch the Debian base sources to Trixie
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

# Create the PBS 4 repository in Deb822 format (no-subscription;
# enterprise: URIs https://enterprise.proxmox.com/debian/pbs, Components pbs-enterprise)
cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

# Remove or comment out the old PBS 3 source (.list), check the result, then upgrade
apt update
apt policy
apt dist-upgrade
reboot

More on PBS: What is Proxmox Backup Server and Set up and operate Proxmox Backup Server.

Step 6: Update APT repositories

All sources switch from Bookworm to Trixie. For PVE 9, Proxmox describes the Deb822 format (.sources) and removes the old .list files after the switch (upgrade guide, APT repositories section):

# Switch the Debian base sources and (if present) the old enterprise source to Trixie
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

# Create the PVE 9 repository in Deb822 format (no-subscription;
# enterprise: file pve-enterprise.sources, URIs https://enterprise.proxmox.com/debian/pve, Components pve-enterprise)
cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

# Ceph only: Ceph Squid repository for Trixie (no-subscription;
# enterprise: URIs https://enterprise.proxmox.com/debian/ceph-squid, Components enterprise)
cat > /etc/apt/sources.list.d/ceph.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/ceph-squid
Suites: trixie
Components: no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

# Remove or comment out the old Bookworm sources (pve-enterprise.list, ceph.list, pve-install-repo.list),
# remove backports lines, then check the result
apt update
apt policy

Important: Remove all references to enterprise.proxmox.com if you don't have an active subscription key. Don't mix enterprise and no-subscription repos. Remaining .list entries can be converted to Deb822 after the upgrade with apt modernize-sources; the old files are kept as .list.bak. On choosing the repository and on the "No valid subscription" notice: Remove the Proxmox subscription notice.

Step 7: Run the upgrade

apt dist-upgrade

Read the planned installations and removals before confirming. If proxmox-ve is scheduled for removal, abort and investigate dependency resolution. Answer configuration-file prompts using the PVE upgrade guide.

According to the upgrade guide, the duration depends heavily on the performance of the system, especially the IOPS and bandwidth of the root filesystem. Plan a maintenance window per node.

After completion:

reboot

# After reboot: verify version
pveversion
# Expected: pve-manager/9.x.x

Step 8: Post-upgrade checks

After the reboot, verify these items:

# Kernel version
uname -r
# Expected on PVE 9.2: 7.0.x (PVE 9.1: 6.17, PVE 9.0: 6.14)

# Any failed services?
systemctl --failed

# Web interface accessible?
curl -k https://localhost:8006

# Ceph status (if applicable)
ceph status

# VM/CT status
qm list
pct list

Cluster upgrade strategy

For production clusters with HA, we recommend this sequence:

1. Preparation (all nodes)

• Run pve8to9 --full on every node
• Upgrade Ceph to Squid (if applicable)
• Upgrade PBS to version 4 (if applicable)

2. Rolling upgrade (node by node)

Node 1 → Maintenance Mode → Upgrade → Reboot → Verify → Exit Maintenance
Node 2 → Maintenance Mode → Upgrade → Reboot → Verify → Exit Maintenance
Node 3 → ...

3. Per node:

• Set node to Maintenance Mode (HA services will be migrated)
• Live-migrate VMs/CTs to other nodes
• Run the upgrade
• Reboot
• Post-upgrade checks
• Exit Maintenance Mode

4. After the last node:

• HA Groups are automatically migrated to HA Rules
• Verify cluster status: pvecm status
• Verify Ceph status: ceph status

Important: VMs can always be migrated from an older to a newer PVE node. The reverse (PVE 9 → PVE 8) is not officially supported.

Common mistakes and how to avoid them

1. Ceph not upgraded before PVE

The upgrade fails or Ceph becomes unreachable after reboot. Fix: Always follow the order: Ceph Squid first, then PVE 9 (a co-installed PBS per its own guide).

2. Enterprise repository without subscription

apt dist-upgrade fails with 401 errors. Fix: Remove enterprise repo, use no-subscription repo.

3. Meta-package proxmox-ve marked for removal

APT wants to uninstall proxmox-ve. Action: Stop the upgrade here and inspect dependency resolution. Incorrect or mixed repository configuration is one possible item to check, but the message alone does not establish the cause. Are all required sources set to trixie, and are any Bookworm entries left? Do not remove the meta-package to bypass the message.

4. Containers with old systemd (≤230) won't start

CentOS 7, Ubuntu 16.04 and similar containers with systemd ≤230 no longer work under PVE 9. Fix: Migrate to newer OS versions before upgrading. PVE 8 support ended in August 2026 - this step cannot be postponed any longer. The prerequisite is listed under "cgroup V1 Removal" in the Known Upgrade Issues.

5. systemd-boot package

The pve8to9 check flags the systemd-boot package. For PVE 8.1-8.4 installations it was automatically included. Fix: Safe to remove unless manually configured (Known Upgrade Issues).

6. VM migration fails in mixed cluster

During the rolling upgrade, VMs may sometimes not start on the target node. Fix: Start VM manually, check CPU type (must be supported on both nodes).

How WZ-IT handles upgrades

We upgrade Proxmox clusters for enterprises using a standardized process:

1. Analysis - Inventory: cluster topology, Ceph layout, PBS version, container OS versions
2. Planning - Define maintenance windows, establish sequence, document rollback strategy
3. Backup - Complete backup of all VMs/CTs, configurations and Ceph status
4. Upgrade - Rolling upgrade node by node with monitoring
5. Verification - Post-upgrade checks, performance baseline, HA test
6. Documentation - Updated infrastructure documentation

The upgrade is performed by an experienced engineer - not by a script. If issues arise, we're directly on the system.

Rather hand off the Proxmox upgrade? We assess your environment and plan the upgrade to PVE 9 from analysis through technical acceptance. Scope and maintenance window are confirmed in advance. Schedule a consultation | View maintenance and upgrade

Related Guides

• Proxmox Backup Server 4.2: S3 Storage Exits Tech Preview - What's new in PBS 4.2
• Encrypted Proxmox Backups with Hetzner Storage Box - Set up offsite backups
• Install Proxmox on Hetzner: Auto-Install Script - Fresh PVE 9 installation
• VMware to Proxmox Migration - Switch from VMware ESXi to PVE
• Private Cloud for SMEs: HA Proxmox Cluster - Cluster architecture for enterprises

Update Proxmox covers regular package updates without a major release change. The cluster update guide describes the per-node procedure with HA maintenance mode and acceptance.

Sources

As of October 2026.

• Proxmox VE 9.2 release notes
• Official upgrade path from Proxmox VE 8 to 9
• Proxmox VE support lifecycle
• Proxmox VE FAQ with lifecycle table
• Proxmox VE roadmap with version details
• Ceph Reef to Squid
• Ceph Squid to Tentacle
• Proxmox Backup Server: upgrade from 3 to 4
• Proxmox VE Administration Guide: system software updates