Proxmox VE 7 to 9 Upgrade: Complete Two-Step Guide

If you're running Proxmox VE 7 and want to reach PVE 9, there's no direct upgrade path — you have to land on PVE 8 first, then step up to PVE 9. Each hop corresponds to a Debian major release (Bullseye → Bookworm → Trixie), and APT can't resolve two major-version jumps in a single pass. I've done this on both standalone nodes and three-node clusters, and when you follow the right sequence the whole two-hop process takes two to three hours per node and leaves you running PVE 9.1 with kernel 6.8.x and ZFS 2.3.

Key Takeaways

• Two hops required: PVE 7 (Debian 11) → PVE 8 (Debian 12) → PVE 9 (Debian 13); no skipping allowed.
• Use the check tools: Run pve7to8 --full and pve8to9 --full before each hop — they catch blockers automatically.
• Backup before each hop: A full snapshot of every VM and CT is non-negotiable.
• Cluster sequencing: Complete the 7→8 hop across all nodes before starting 8→9 on any of them.
• Ceph users: Quincy required before PVE 8, Reef required before PVE 9.

Why Two Hops Are Required

Proxmox VE tracks Debian's release cadence exactly. PVE 7 runs on Debian 11 (Bullseye), PVE 8 on Debian 12 (Bookworm), PVE 9 on Debian 13 (Trixie). APT's dependency resolver works one major version at a time. Pointing sources at Trixie while running Bullseye means intermediate library versions don't exist in the repo — dist-upgrade either fails with dependency errors or partially upgrades into an unbootable system.

The two-hop path is what Proxmox officially documents and what the pve7to8 and pve8to9 checker scripts are built to validate.

Before You Start: Pre-Flight Check

# Cluster health (skip if standalone)
pvecm status

# VM and container states
qm list
pct list

# Root disk space — need 5 GB+ free
df -h /

# Held packages that could block the upgrade
dpkg --get-selections | grep hold

# Baseline for comparison after reboot
pveversion -v
uname -r

Backups: If you're using Proxmox Backup Server for automated backups, trigger a manual job now and confirm it completes. If not, run vzdump --all 1 --storage <local-store> --compress zstd as a minimum.

Third-party repos: Comment out any non-Proxmox, non-Debian sources in /etc/apt/sources.list.d/. They conflict with dist-upgrade.

Ceph check: Run ceph --version if you have Ceph. You need Quincy (17.x) before the PVE 8 hop and Reef (18.x) before PVE 9. The checkers flag this, but knowing it ahead saves time.

Step 1: Proxmox VE 7 to 8 Upgrade

Update APT Sources to Bookworm

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list.d/pve-enterprise.list

[ -f /etc/apt/sources.list.d/pve-no-subscription.list ] && \
  sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list.d/pve-no-subscription.list

Verify the result:

deb http://ftp.debian.org/debian bookworm main contrib
deb http://ftp.debian.org/debian bookworm-updates main contrib
deb http://security.debian.org bookworm-security main contrib
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

Ceph repos use release names like quincy rather than Debian codenames — leave those alone. The pve7to8 checker handles them.

Run pve7to8 and Fix What It Finds

apt update
pve7to8 --full

The checker runs about 30 tests and outputs PASS, WARN, or FAIL for each. You need zero FAIL results before proceeding. Common failures:

• Ceph Pacific: Not supported in PVE 8; upgrade to Quincy first.
• ifupdown2: PVE 8 requires ifupdown2; incompatible network config gets flagged.
• Third-party packages: Anything outside official repos triggers a warning.

Fix every FAIL. WARN items are advisory.

Perform the Upgrade and Reboot

apt dist-upgrade

The download is typically 600–900 MB. During install, dpkg will ask about replacing config files. The critical prompt: when asked about /etc/network/interfaces, keep your current version. Accepting the maintainer's version overwrites your custom bridges, bonds, and VLANs. For /etc/ssh/sshd_config and /etc/default/grub, the maintainer's version is generally safe.

reboot

Verify PVE 8 Is Running Correctly

# Should report 8.x
pveversion -v

# Should be 6.5.x or newer
uname -r

pvesm status
zpool status
pvecm status

Log into the web UI at https://<node-ip>:8006 and confirm it loads. Start a few VMs, let them run for 15–30 minutes, check the task log. This is your last clean rollback point before hop two.

Step 2: Proxmox VE 8 to 9 Upgrade

Update APT Sources 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

[ -f /etc/apt/sources.list.d/pve-no-subscription.list ] && \
  sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-no-subscription.list

Expected result:

deb http://ftp.debian.org/debian trixie main contrib
deb http://ftp.debian.org/debian trixie-updates main contrib
deb http://security.debian.org trixie-security main contrib
deb http://download.proxmox.com/debian/pve trixie pve-no-subscription

Run pve8to9 and Fix What It Finds

apt update
pve8to9 --full

PVE 9 introduced more substantial changes than the 7→8 hop. Common blockers:

• Ceph Reef required: Quincy is not supported in PVE 9. This is the single most common FAIL.
• Kernel 6.8 DKMS: Custom DKMS modules must build against 6.8.x. Proprietary RAID or NIC drivers need verification.
• OCI LXC templates: PVE 9.1 added native OCI container support; some older template formats need re-downloading.
• SDN deprecations: EVPN configs with deprecated options get flagged for manual review.

Don't proceed past any FAIL.

Perform the Upgrade and Reboot

apt dist-upgrade

Same process as hop one — confirm the package list, keep /etc/network/interfaces when prompted, let it run. Download size is again 600–900 MB.

reboot

Verify PVE 9 Is Running Correctly

# Should report 9.x
pveversion -v

# Kernel 6.8.x or newer
uname -r

pvesm status

# ZFS now running 2.3
zpool status

# Custom DKMS modules
dkms status

pvecm nodes

PVE 9's web UI includes updated panels for OCI LXC deployment and improved task logging. Walk through it before declaring success — the LXC template manager changed enough that anyone managing containers should see the new layout before hitting it in production.

What Actually Breaks Between PVE 7 and PVE 9

Component	7→8 Impact	8→9 Impact	Action Required
Ceph	Pacific → Quincy needed	Quincy → Reef needed	Upgrade Ceph before each hop
DKMS modules	Kernel 6.5 rebuild	Kernel 6.8 rebuild	dkms autoinstall after reboot
Network config	Keep current file	Keep current file	Decline dpkg replacement prompt
ZFS pools	No impact (stays 2.2)	Upgrades to ZFS 2.3	Verify zpool status post-boot
LXC templates	Minor format changes	OCI support added	Re-download if templates error
SDN / EVPN	Mostly unchanged	Deprecated options	Review SDN zones in UI
VM disk formats	No impact	No impact	None
API and automation	Some deprecations	Additional deprecations	Test scripts post-upgrade

If you have Ansible playbooks managing your VMs and infrastructure, test them against the upgraded node before running in production — some pvesh API paths changed between PVE 7 and PVE 9.

How to Handle a Cluster Upgrade

The sequencing rule is firm: complete the 7→8 hop across all cluster nodes before starting 8→9 on any of them. A PVE 7 node and PVE 8 node can coexist temporarily. A PVE 7 node and PVE 9 node cannot share a cluster.

# Live-migrate VMs off the node you're about to upgrade
# Replace 100 with VM ID, node2 with migration target
qm migrate 100 node2 --online

# Check quorum before each node upgrade
pvecm status

For a three-node cluster doing both hops:

1. Migrate VMs off node 1, upgrade to PVE 8, verify
2. Migrate VMs off node 2, upgrade to PVE 8, verify
3. Upgrade node 3 to PVE 8 — all three now on PVE 8
4. Migrate VMs off node 1, upgrade to PVE 9, verify
5. Repeat for nodes 2 and 3

Budget 45–90 minutes per node per hop. A full three-node migration from PVE 7 to PVE 9 realistically takes a full day. Don't schedule it in a window shorter than eight hours.

Conclusion

After both hops you'll have Proxmox VE 9.1 running on kernel 6.8.x with ZFS 2.3 and native OCI LXC support. The pre-upgrade checkers do most of the hard thinking — the only moment where a wrong answer causes real damage is the /etc/network/interfaces prompt during dist-upgrade. Once you're on PVE 9, review your security configuration since some defaults changed; the Proxmox hardening guide covers firewall rules, fail2ban, and SSH hardening to keep your upgraded node locked down.