How to Upgrade Proxmox VE 8 to Proxmox VE 9 (Complete Step-by-Step Guide)

Proxmox VE 9.0 moved the platform onto a Debian 13 "Trixie" base, brought a newer 6.14 kernel, refreshed Ceph to the Squid release, and reworked how High Availability rules are defined. If you're still running a Proxmox VE 8.x node or cluster, the in-place upgrade path is well supported, but it touches enough moving parts — repositories, the kernel, Ceph, HA configuration, and LVM behavior — that it pays to plan the upgrade rather than just running apt dist-upgrade and hoping for the best.

This guide walks through a complete, safe upgrade from Proxmox VE 8 to Proxmox VE 9: what to check beforehand, how to update your repositories, the actual upgrade commands, cluster- and Ceph-specific considerations, and the post-upgrade cleanup that people most often skip.

What's New in Proxmox VE 9

Before upgrading, it helps to know what actually changed under the hood:

• Debian 13 "Trixie" as the base operating system, replacing Debian 12 "Bookworm."
• Linux kernel 6.14.8 as the new default, improving hardware support but also changing some driver and network interface naming behavior.
• Updated core components: QEMU 10.0.2, LXC 6.0.4, Ceph Squid 19.2.3, and OpenZFS 2.3.3.
• Snapshots on thick-provisioned shared LVM storage, closing a long-standing gap for Fibre Channel and iSCSI SAN users.
• ZFS RAIDZ expansion, allowing new devices to be added to an existing RAIDZ vdev without rebuilding the pool.
• SDN "fabrics", a new building block for more complex software-defined network topologies.
• HA resource affinity rules, replacing the older HA groups model with more flexible placement rules.

Several of these — especially the HA rules migration and the kernel change — directly affect how the upgrade behaves, so keep them in mind as you go through the steps below.

Prerequisites Before You Start

Proxmox's own upgrade tooling won't stop you from skipping these, but skipping them is how upgrades turn into outages. Confirm the following before touching a single repository file:

1. Every node must already be on Proxmox VE 8.4 (the last 8.x point release) or later. Older 8.x releases are not a supported starting point.
2. Hyper-converged Ceph clusters must be on Ceph 19.2 "Squid" before you touch the Proxmox VE packages. Upgrading Proxmox VE out from under an older Ceph release is a common way to break a cluster.
3. Co-installed Proxmox Backup Server needs to be upgraded to PBS 4 separately — it does not ride along with the PVE upgrade automatically.
4. Out-of-band access (IPMI, iKVM, iDRAC, or physical console) should be available and tested for every node you're upgrading. SSH is fine until it isn't — a kernel or network change is exactly the kind of thing that can lock you out of a remote-only session.
5. At least 5 GB of free disk space on the root filesystem, with 10 GB or more recommended, especially if you're keeping old kernels around during the transition.
6. Valid, tested backups of every VM and container. Proxmox is explicit about this in their own documentation: a tested backup is required, not optional, because there is no formal rollback procedure for an in-place major upgrade.
7. Check your hardware against known issues for the 6.14 kernel (see the Known Issues section below) — GPU passthrough and some NVIDIA vGPU configurations have specific caveats.

Step 1: Run the Pre-Upgrade Checker

Proxmox ships a dedicated checklist tool, pve8to9, that inspects your configuration and flags anything likely to cause problems. Run it before you change anything:

pve8to9 --full

This is a read-only diagnostic — it does not modify your system. It checks things like your repository configuration, storage setup, cluster state, installed third-party packages, and known hardware quirks, and prints warnings or failures you should resolve first. Re-run it after making changes, and again once the upgrade itself is done, since the same tool remains useful for post-upgrade verification.

Pay particular attention to any warning about third-party storage plugins or backup integrations (see the Known Issues section) — those often need an update from their maintainer before they'll work correctly on Proxmox VE 9.

Step 2: Update to the Latest Proxmox VE 8.4 Packages

Before switching repositories to Trixie, make sure the node is fully patched on 8.4 first. This avoids mixing an outdated 8.x package state with the jump to 9.

apt update
apt dist-upgrade
pveversion

Reboot if the kernel changed, and confirm pveversion reports a current 8.4.x build before continuing.

Step 3: Disable Audit Socket Logging (Recommended)

The newer kernel's audit subsystem can flood the journal with noise during and after the upgrade if the audit socket is left enabled. Proxmox recommends disabling it beforehand:

systemctl disable --now systemd-journald-audit.socket

Step 4: Update APT Repositories from Bookworm to Trixie

Proxmox VE 9 is built against Debian 13 "Trixie," so your APT sources need to point at Trixie instead of Bookworm. If you're using the classic .list file format, you can do a straightforward find-and-replace:

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

Proxmox has also moved toward the newer deb822 .sources format. If you want to modernize while you're in there, create the appropriate file for your subscription status.

Enterprise repository (paid subscription):

cat > /etc/apt/sources.list.d/pve-enterprise.sources << EOF
Types: deb
URIs: https://enterprise.proxmox.com/debian/pve
Suites: trixie
Components: pve-enterprise
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

No-subscription repository:

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

If you run a hyper-converged Ceph cluster, update the Ceph repository too, matching the same enterprise or no-subscription pattern but against the ceph-squid path:

• Enterprise: https://enterprise.proxmox.com/debian/ceph-squid
• No-subscription: http://download.proxmox.com/debian/ceph-squid

Make sure you don't end up with duplicate entries — if you create the new deb822 .sources file, remove or comment out the old .list entry for the same repository so APT doesn't fetch the same packages from two sources.

Step 5: Perform the Major Upgrade

With repositories pointed at Trixie, refresh the package index and run the actual dist-upgrade:

apt update
apt dist-upgrade

This is the step that pulls in the new kernel, QEMU, LXC, and the rest of the Proxmox VE 9 stack. It will take a while, and APT will periodically stop to ask what to do about modified configuration files. The most common prompts and the recommended answers are:

• /etc/issue — cosmetic only; keep your existing version if you've customized it.
• /etc/lvm/lvm.conf — accept the maintainer's new version unless you've made specific local changes you need to preserve.
• /etc/ssh/sshd_config — accept the new version; it deprecates legacy SSH options that Trixie's OpenSSH no longer supports well.
• /etc/default/grub — review this one carefully if you've added custom kernel parameters (IOMMU flags for PCI passthrough, for example); merge your custom options into the new file rather than blindly overwriting it.
• /etc/chrony/chrony.conf — accept the new version unless you've heavily customized your NTP configuration.

Step 6: Handle the GRUB + LVM + UEFI Edge Case

If your system boots in UEFI mode with the root filesystem on LVM, install the EFI-specific GRUB package to avoid a broken bootloader after the kernel switch:

[ -d /sys/firmware/efi ] && apt install grub-efi-amd64

Step 7: Reboot Into the New Kernel

Once dist-upgrade completes without errors, reboot:

reboot

Do this even if you were already running a 6.14 kernel under Proxmox VE 8 — the Proxmox VE 9 kernel build uses a newer compiler and ABI version, so the old 6.14 build is not equivalent to the new one.

Because the newer kernel can rename network interfaces (particularly on systems with multiple NICs or unusual naming schemes), verify network connectivity through your out-of-band console before assuming the reboot succeeded cleanly. If an interface renames itself, your bridge configuration in /etc/network/interfaces may need a manual fix.

Step 8: Re-run the Checker and Verify

After rebooting, confirm the new version and re-run the checklist tool:

pveversion
pve8to9 --full

Then clear your browser cache and force-reload the web UI (Ctrl+Shift+R on Windows/Linux, ⌘+Option+R on macOS) — cached JavaScript from the old UI version is a common source of "the interface looks broken" reports after an upgrade that otherwise succeeded.

Upgrading a Cluster

If you're running more than one node in a cluster, upgrade one node at a time rather than all at once:

1. Migrate critical VMs and containers off the node you're about to upgrade.
2. Run through steps 1–8 above on that single node.
3. Confirm the node rejoins the cluster cleanly and shows a green status before moving to the next node.
4. Repeat for each remaining node, one at a time.

A Proxmox VE 9 node can still migrate VMs to a node still running Proxmox VE 8, but not the other way around — older nodes cannot receive migrations from newer ones. Plan your migration order around that constraint, and avoid running a mixed-version cluster for any longer than necessary; treat it as a transient state during the rollout, not a stable configuration.

High Availability: Groups Become Rules

Proxmox VE 9 replaces HA groups with a more flexible HA rules and resource affinity model. You don't need to migrate anything manually — once every node in the cluster is running Proxmox VE 9, existing HA groups are automatically converted into equivalent HA rules. Until every node has been upgraded, though, this conversion doesn't happen, which is another reason to avoid leaving a cluster half-upgraded for long stretches. If HA behavior looks off after the cluster-wide upgrade completes, check the pve-ha-crm logs on the current CRM master node:

journalctl -u pve-ha-crm -f

Ceph-Specific Notes

For hyper-converged Ceph clusters, the Ceph upgrade to Squid (19.2) must happen before the Proxmox VE 9 upgrade — not alongside it, and not after. Upgrading Proxmox VE packages against an older Ceph release is unsupported and can leave the cluster in an inconsistent state.

If you're running Ceph over a full-mesh network (common in small hyper-converged clusters using routed or broadcast full-mesh setups with FRR), update your interface post-up hooks to avoid a restart deadlock during the upgrade:

post-up /usr/bin/systemctl is-active --quiet frr.service && \
  /usr/bin/systemctl restart frr.service || true

Without this guard, restarting the networking stack mid-upgrade can hang waiting on a service that isn't active yet, particularly on the first node in the mesh to reboot.

LVM Autoactivation on Shared Storage

If you use shared LVM or LVM-thin storage (common with iSCSI or Fibre Channel SANs), Proxmox VE 9 changes how logical volumes are auto-activated at boot. Left unaddressed, this can cause guest creation or live migration failures on shared storage. Run the provided migration script to disable autoactivation for guest volumes correctly:

/usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation

This is safe to run on any node using shared LVM storage and is strongly recommended rather than optional if that describes your environment.

Known Issues to Check Against Your Environment

Area	Issue	What to do
Third-party storage plugins	May not load until the plugin author releases a Proxmox VE 9-compatible update	Check with the plugin vendor before upgrading a node that depends on it
NVIDIA vGPU	Requires driver 570.158.02 or later (GRID 18.3+)	Update the vGPU host driver before or immediately after the upgrade
VM memory reporting	Now includes host overhead; reported usage can exceed 100%	Expect this in monitoring dashboards; it's cosmetic, not a leak
Veeam Backup	Incompatible with QEMU machine version 10.0+	Pin affected VMs to machine version 9.2+pve1 until Veeam adds support
PCI passthrough	Occasional failures reported on kernel 6.14 for specific hardware	If passthrough breaks post-upgrade, boot the previous 8.x kernel as a temporary workaround while you investigate
Legacy containers	cgroupv2-only; containers with systemd older than ~2016 (CentOS 7, Ubuntu 16.04) are unsupported	Plan to migrate or retire these containers before upgrading the host
/etc/sysctl.conf	No longer read directly	Move custom kernel parameters into a file under /etc/sysctl.d/

Post-Upgrade Cleanup

Once the node (or the whole cluster) is confirmed healthy on Proxmox VE 9, tidy up loose ends:

• Run apt modernize-sources to convert any remaining legacy .list repository files to the deb822 .sources format.
• Remove old kernel packages once you're confident you won't need to roll back to them, to reclaim disk space: apt autoremove --purge.
• Re-verify backup jobs actually ran successfully post-upgrade — don't assume the schedule survived unchanged, especially if you touched PBS separately.
• If you disabled the audit socket in Step 3 and rely on auditd for compliance logging elsewhere, re-enable it deliberately rather than leaving it off by accident.

What If Something Goes Wrong?

Proxmox does not provide a formal in-place rollback path from 9 back to 8 — this is exactly why a tested backup is a prerequisite, not a suggestion. If a node becomes unusable after the upgrade:

• Use out-of-band console access to diagnose — this is why IPMI/iKVM access was on the prerequisites list.
• For kernel-specific regressions (PCI passthrough, unusual hardware), you can often boot the previous 6.8 (Proxmox VE 8) kernel entry from the GRUB menu as a stopgap while you investigate, since dist-upgrade typically leaves the old kernel installed alongside the new one.
• If the node itself is unrecoverable, restore VMs and containers from your pre-upgrade backups onto a freshly installed Proxmox VE 9 host rather than attempting to repair a broken package state under time pressure.

Planning a Maintenance Window

Even though the upgrade itself is well-trodden, it's worth treating it like any other change to production infrastructure rather than something you squeeze in between meetings. A few practical planning notes:

• Stagger cluster nodes across separate windows if needed. There's no requirement to upgrade an entire cluster in one sitting. Upgrading one or two nodes, confirming stability for a day, and then continuing is a perfectly reasonable approach for risk-averse environments — just don't stretch a mixed 8/9 cluster out for weeks, since some behaviors (like the HA rules conversion) only activate once every node matches.
• Snapshot or export critical guest configs separately from your regular backup job. A full VM/container backup covers disk data, but exporting /etc/pve/qemu-server/*.conf and /etc/pve/lxc/*.conf to a location outside the cluster gives you a fast way to recreate configuration if something goes sideways with cluster filesystem state specifically.
• Notify anyone with GUI or API access. Automation scripts hitting the Proxmox API, monitoring integrations, and anyone with a browser tab open to the web UI will see a brief interruption during the reboot step, and stale cached UI assets afterward if they don't hard-refresh.
• Check firmware and BIOS settings aren't scheduled to reset. This isn't a Proxmox concern per se, but IOMMU, SR-IOV, and virtualization extensions settings in BIOS occasionally get reset by out-of-band firmware updates bundled with server maintenance — worth a quick sanity check if you're doing broader maintenance at the same time as the OS upgrade.

Validating the Upgrade Actually Worked

"The upgrade finished without errors" and "the upgrade actually succeeded" are not the same claim. After each node reboots, run through a short validation pass before declaring it done and moving to the next node:

1. Confirm the version string. pveversion -v should report a pve-manager version in the 9.x series and a kernel in the 6.14 line. If it still shows 8.x packages, the dist-upgrade didn't fully apply — check /var/log/apt/history.log for what actually got installed.
2. Check cluster quorum. On a clustered install, run pvecm status and confirm the node rejoined with quorum intact rather than sitting isolated.
3. Verify storage is reachable. Open Datacenter → Storage in the web UI and confirm every configured storage backend shows green, particularly shared NFS, iSCSI, or Ceph pools — a repository or kernel module mismatch can silently leave a storage plugin unable to mount.
4. Test a live migration. If this is a cluster, migrate a small non-critical VM onto the freshly upgraded node and back off again. This exercises networking, storage, and the cluster filesystem in one pass, which is a more realistic check than eyeballing the dashboard.
5. Confirm scheduled backup and replication jobs still fire. Check Datacenter → Backup and any storage replication jobs after the next scheduled run, since silently broken automation is the kind of thing nobody notices until the day they actually need a restore.
6. Re-run pve8to9 --full one more time. A clean pass here, with the earlier warnings resolved, is a reasonable signal that the node is ready for normal production use again.

Frequently Asked Questions

Do I need to reinstall Proxmox VE to get to version 9?

No. The in-place apt dist-upgrade path described above is the officially supported route from 8.4 to 9. A fresh install is only necessary if you want a clean slate or your current install has accumulated configuration drift you'd rather not carry forward.

Can I skip straight from Proxmox VE 7 to 9?

No. Proxmox major version upgrades are sequential — you must be fully upgraded to 8.4 before starting the 9 upgrade. There is no supported direct path from 7 to 9.

How long does the upgrade take per node?

This varies with hardware and network speed, but budget at least 30–60 minutes per node for the package upgrade and reboot, plus time for VM/container migration if you're doing a rolling cluster upgrade. Don't rush a Ceph cluster upgrade — verify cluster health (ceph -s) between nodes rather than upgrading back-to-back.

Will my existing HA configuration break?

Existing HA groups keep working during a mixed-version cluster state and convert automatically to HA rules once every node is on Proxmox VE 9 — no manual migration is required, but double-check resource placement afterward against the new rules if you had complex group priorities configured.

Is downtime required for VMs during the upgrade?

Not necessarily. If you're running a cluster, live-migrate VMs off each node before upgrading it, then migrate them back (or let HA rebalance them) afterward. Standalone single-node installs will need to reboot the host into the new kernel, which does interrupt any VMs running on that node unless you have somewhere else to migrate them to first.

What happens to my no-subscription vs enterprise repository choice?

Nothing changes about which repository tier you're entitled to use — you're simply pointing the same tier (enterprise or no-subscription) at the new Trixie/Squid package suites instead of Bookworm/Reef.