Proxmox Upgrade 8 to 9: Preflight Checks and Gotchas

By LK Wood IV · Published 2026-06-17 · Updated 2026-10-11 · ~10 min read · St. Louis County, MO

Proxmox VE 9 has been out since August 2025. The release checked on September 26, 2026 is 9.2, built on Debian 13.5 “Trixie” with Linux kernel 7.0. It is what the Trixie repositories supply.

Upgrading Proxmox 8 to 9 in place is officially supported. It is also a major version jump. It ships breaking changes that can leave a node off the network or refusing to boot if you walk in unprepared.

The support deadline has passed. Proxmox VE 8’s end of standard support was 2026-08, and its Debian 12 “Bookworm” base carries a 2026-07 end date in Proxmox’s lifecycle table.

This is the pre-flight guide. It covers what to check before you start, the gotchas most likely to bite, and the commands themselves. It is built from Proxmox’s official Upgrade_from_8_to_9 documentation and from issues the community has reported. The mechanism is routine. The preparation is the whole job.

Back up first, always. Proxmox’s own guidance is blunt: “A valid and tested backup is always required before starting the upgrade process.” If you take one thing from this page, take that.

Upgrade planning overview

This 68-second original animation maps the preparation and upgrade sequence from Proxmox’s official guide.

Video transcript

1. 0:00–0:05 — Plan the upgrade. Proxmox VE 8 to 9 upgrade planning overview. This original animation explains the preparation sequence.
2. 0:05–0:13 — Start current. Start with every node fully updated to Proxmox VE 8.4, with pve-manager version 8.4.1 or later.
3. 0:13–0:21 — Make recovery possible. Verify external guest backups. Keep IPMI or physical console access, or use SSH inside tmux or screen. Do not rely on the web interface console.
4. 0:21–0:30 — Run the full preflight. Run pve8to9 --full. Stop on failures, act on every warning that applies, and rerun the checker after each fix. The checker reports; it does not perform the upgrade.
5. 0:30–0:38 — Protect cluster state. On a cluster, move guests away, upgrade one node at a time, and keep quorum. Hyperconverged Ceph must be on Squid 19 before the Proxmox upgrade.
6. 0:38–0:47 — Switch repositories deliberately. Change the Debian and Proxmox repositories from Bookworm to Trixie. Run apt update and apt policy, then continue only when there are no errors and only the intended repositories appear.
7. 0:47–0:54 — Stop on a removal conflict. Stop if APT wants to remove the proxmox-ve package. Repair the repository or package conflict before continuing.
8. 0:54–1:01 — Upgrade with the prompts in view. Run apt dist-upgrade. Read each configuration-file prompt and choose deliberately instead of accepting every default.
9. 1:01–1:08 — Check, reboot, verify. Rerun pve8to9, reboot, then verify the Proxmox version, storage, network, services, and guests. The full guide covers the gotchas and recovery paths.

The short version

• Get every node to PVE 8.4.1 or later first.
• Run pve8to9 --full. Resolve every failure and act on every warning that applies to the node before touching repositories.
• Back up all VMs and containers to external storage, preserve the host configuration, test a restore, and make sure you have IPMI or physical console access.
• Switch repositories from bookworm to trixie. Inspect apt update and apt policy before apt dist-upgrade. Reboot into the new kernel (7.0 on the current 9.2).
• On a cluster, go one node at a time and keep quorum. Move Ceph to Squid first.
• Expect possible NIC renames and LVM autoactivation changes. Handle both before you reboot.

What you are upgrading to

When you point your repositories at Trixie and run apt dist-upgrade, APT installs the current Proxmox VE 9 packages. You do not get to choose 9.0. As checked September 26, 2026, that means Proxmox VE 9.2 (released May 21, 2026) instead of the original 9.0 from August 2025. The stack underneath you becomes:

• Debian 13.5 “Trixie” and Linux kernel 7.0 (up from the 6.14 that shipped with 9.0)
• QEMU 11.0, LXC 7.0, ZFS 2.4
• Ceph Tentacle 20.2 available as a stable option, with Squid 19.2 still available (you still upgrade existing Ceph to Squid before the PVE jump — see the cluster section)

The headline 9.2 additions over 9.0 are a dynamic load balancer for HA-managed guests that uses live CPU/RAM utilization while respecting your HA rules, native WireGuard and BGP in the SDN stack, and custom CPU model management in the web UI.

None of this changes the procedure. It does mean you jump straight to the current release. The newer kernel is also what drives the NIC-rename and PCI-passthrough gotchas further down.

Two ways to move from 8 to 9

Proxmox’s wiki (read 2026-10-10) lists two paths:

• In-place: update to the latest 8.4, switch the repositories to Trixie, and run apt dist-upgrade. This page covers it.
• Fresh install: back up every guest to external storage, back up /etc (especially /etc/pve, /etc/passwd, /etc/network/interfaces and /etc/resolv.conf), install the latest 9.x from the ISO, rebuild the cluster if you had one, then restore /etc/pve/storage.cfg, the firewall configuration and the guests. The ISO install erases the host’s existing data.

The wiki presents the fresh install as the path for new hardware.

Before you touch anything

The prerequisites from the official guide:

• Be on PVE 8.4.1+ on every node. The pve8to9 checklist ships in the latest 8.4 packages.
• Rehearse it. Proxmox suggests installing PVE 8.4 on test hardware or in a VM, updating it to the latest 8.4 minor version, copying over the relevant configuration, and running the upgrade there first.
• Check third-party sources. Custom packages and third-party repositories must also work with Debian Trixie.
• Tested backups of every guest on external storage. Also copy the host configuration needed for a fresh install: /etc/pve, /etc/passwd, /etc/network/interfaces, /etc/resolv.conf, and any custom configuration. Test a guest restore before the upgrade.
• At least 5 GB free on the root filesystem (10+ GB recommended) for the package transition.
• Console access that isn’t the web GUI. Use IPMI/iKVM or a physical console, or SSH inside tmux/screen — never the GUI’s noVNC console, which dies with the services mid-upgrade.
• Ceph users: upgrade Ceph to 19.2 Squid before upgrading Proxmox.
• Co-installed Proxmox Backup Server: bring PBS to the latest 3.4 release, run pbs3to4 --full, and read the PBS 3-to-4 guide. Proxmox says a co-installed PVE/PBS system can upgrade both in one go by synchronizing the APT repository-change steps. Do not upgrade PBS first as a separate major-version step.

Run the checklist: pve8to9 --full

Before changing a single repository line, run:

pve8to9 --full

It flags common incompatibilities in repository state, LVM, boot configuration and known package conflicts. It does not fix anything for you. Resolve every failure. Read every warning or notice, apply its documented fix when it matches the node, and run the checker again.

A remaining notice can describe a condition you deliberately reviewed. The requirement is no unresolved failure and no ignored applicable warning. A cosmetically empty report is not the goal.

The pve8to9 upgrade checklist

pve8to9 without a flag runs the quick checks. Proxmox says to run pve8to9 --full at least once before the upgrade, and to rerun the script after each fix and again after apt dist-upgrade. The wiki’s “Checklist issues” section covers two findings you are likely to see:

• proxmox-ve package is too old. Confirm the repositories still point at PVE 8.x on Bookworm, then run apt update and apt dist-upgrade to reach the latest 8.4.
• LVM or LVM-thin guest volumes with autoactivation enabled. The script suggests the pve-lvm-disable-autoactivation migration described in the next section.

Its suggestions can also include removing the systemd-boot meta-package, covered under boot changes below.

The gotchas most likely to bite

These are the changes most likely to cause a bad day. Most are easy to handle if you handle them before the reboot.

LVM autoactivation is now off by default

On Proxmox 9, LVM autoactivation is disabled by default for new logical volumes on LVM and LVM-thin storage. Existing volumes keep their old behavior. The change avoids activation failures on shared LVM storage such as iSCSI or Fibre Channel.

Proxmox provides /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation. Running it is strongly recommended for shared LVM and optional for local-only storage.

Do not run lvconvert --repair as routine preparation. The official guide gives lvconvert --repair pve/data only when boot reports the exact failure Check of pool pve/data failed (status:64). Manual repair required!; Proxmox says that failure’s cause is still under investigation.

Network interfaces can get renamed

The newer kernel can recognize additional NIC hardware features, which changes the predictable interface name. If your vmbr0 bridge points at the old name, the host boots with no network.

On a PVE 8 node, you can pin a stable name with Proxmox’s manual systemd .link method. The steps:

1. Match the physical NIC by MAC address and Type=ether.
2. Assign a non-conflicting en... name.
3. Update /etc/network/interfaces.
4. Run update-initramfs -u -k all and reboot.
5. Confirm networking before the major upgrade.

PVE 9 also documents pve-network-interface-pinning. It does not keep the current names. Its default generated names are nic1, nic2, and so on. It writes .new configuration files for review, does not update Datacenter firewall references in /etc/pve/firewall/cluster.fw, and requires a reboot. Use that workflow only when the command is installed and you intend to adopt its generated names.

If you run a Ceph Full Mesh with post-up /usr/bin/systemctl restart frr.service, that line will deadlock on 9. The wiki’s replacement is a conditional restart:

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

If the host is already stuck, boot the PVE ISO’s Rescue Boot from the Advanced menu and edit /etc/network/interfaces.

Boot and systemd changes

• Remove the systemd-boot meta-package where proxmox-boot-tool manages booting, if pve8to9 suggests it. Trixie splits systemd-boot into systemd-boot-efi, systemd-boot-tools and a meta-package that changes the bootloader configuration automatically.
• GRUB on LVM in UEFI mode can fail to install; the fix is [ -d /sys/firmware/efi ] && apt install grub-efi-amd64.
• /etc/sysctl.conf is no longer honored by systemd-sysctl. Move any custom kernel tunables into /etc/sysctl.d/<NN>-name.conf. The wiki notes this affects EVPN exit-node rp_filter settings and IP forwarding.
• /tmp is now a tmpfs on Debian Trixie, up to 50% of memory, and files in /tmp and /var/tmp are cleaned regularly while the system runs. Do not keep anything you need there.
• VM memory can look higher. PVE 9 counts VM memory overhead, so usage may read above 100%. A new “Host memory usage” field shows the host’s view.

Containers, passthrough, and migration

• cgroup v1 is removed. Containers running systemd 230 or older (including CentOS 7 and Ubuntu 16.04) won’t start — migrate those guests first.
• PCI passthrough can break on the newer kernel (first widely reported on 6.14; the current 9.2 ships kernel 7.0). If a passthrough VM misbehaves, the known workaround is pinning an older kernel until it’s resolved.
• Live migration between different CPU vendors (Intel↔AMD) can leave guests unresponsive — plan maintenance windows accordingly.
• NVIDIA vGPU compatibility is a matrix, not a minimum-driver rule. For a PVE 9.2 kernel 7 host, choose the exact PVE/kernel row in Proxmox’s current NVIDIA vGPU compatibility table and use its matching vGPU branch and host driver. Veeam is incompatible with QEMU machine version ≥10.0.

Known failure after upgrading: a Windows VM that won’t boot. Since the kernel-7.0 rollout on 9.2, Windows guests running SeaBIOS with MBR disks have been reported failing with 0xc0000001, and OVMF guests dropping to the UEFI boot menu. If that’s where you’ve landed, don’t reinstall anything — the signature-by-signature fixes (kernel pin, boot-path repair, UEFI conversion) are in Windows VM won’t boot after the Proxmox 9 upgrade.

Stop, continue, or recover

This is the decision point before apt dist-upgrade. The signals and recovery commands below come from Proxmox’s official 8-to-9 guide, not from a generic Debian upgrade recipe.

The upgrade itself

Once pve8to9 --full has no unresolved failure and you have handled every applicable warning above:

1. Migrate guests off the node you are about to upgrade (on a cluster). Proxmox says migrating from an older to a newer version works. Migrating from newer to older may work but is unsupported.

2. Update PVE 8 to the latest 8.4 and confirm the version:

   apt update
   apt dist-upgrade
   pveversion
   

   pveversion should report 8.4.1 or newer. With hyperconverged Ceph, ceph --version should report Squid (19).

3. Point repositories at Trixie. Switch bookworm to trixie across your APT sources and the Proxmox repository. The deb822 .sources format is the one Proxmox shows for 9. Update the Ceph repositories to Squid/trixie if applicable. Remove or disable the old Bookworm entries. The commands are in the next section.

   On a host with PBS installed alongside PVE, follow the PBS guide and switch its repository in this same stage, after both pve8to9 --full and pbs3to4 --full have been reviewed.

4. Audit the repositories before upgrading:

   apt update
   apt policy
   

   Continue only when apt update has no repository errors and apt policy shows the expected Trixie/PVE package candidates.

5. Upgrade:

   apt dist-upgrade
   

   Answer the config-file prompts deliberately. The prompt choices are listed below.

6. Rerun pve8to9, then reboot into the new kernel. The reboot is required (the current 9.2 ships kernel 7.0). Reboot even if you were already running a 6.x kernel on 8, because the 9 kernel is rebuilt against the new compiler and ABI. Then confirm:

   pveversion   # should report 9.x
   

   Hard-refresh the web UI (Ctrl+Shift+R) so you’re not staring at a cached 8.x interface.

Repository commands from the official guide

These are the commands and files on Proxmox’s wiki page (revision last edited 2026-09-17, read 2026-10-10). Run them on the node, from the console, not the web GUI.

Switch the Debian base repositories, then comment out any remaining Bookworm-specific lines:

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

For the no-subscription repository, create /etc/apt/sources.list.d/proxmox.sources:

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

Then remove the PVE 8 no-subscription entry from sources.list, pve-install-repo.list or any other .list file, and verify with apt update and apt policy.

With a subscription, the enterprise file is /etc/apt/sources.list.d/pve-enterprise.sources with URIs: https://enterprise.proxmox.com/debian/pve, Suites: trixie, Components: pve-enterprise and the same Signed-By line. Remove pve-enterprise.list afterwards.

For hyperconverged Ceph, /etc/apt/sources.list.d/ceph.sources uses Suites: trixie with the Squid URI. That is http://download.proxmox.com/debian/ceph-squid and Components: no-subscription, or https://enterprise.proxmox.com/debian/ceph-squid and Components: enterprise. Remove ceph.list afterwards, and remove any backports line. Proxmox says the upgrade has not been tested with backports packages installed. A 401 error on an enterprise repository means the subscription needs a refresh in the web UI or with pvesubscription update --force.

Config-file prompts during dist-upgrade

The run takes anywhere from under 5 minutes on a fast SSD to 60 minutes or more on a slow spinning disk. Expect prompts. Proxmox’s recommendations:

You may also see keyboard-layout and apt-listchanges prompts (press q). The default answer to the service-restart question is fine.

After the reboot

• On a cluster, confirm every node runs the latest packages. If one does not, continue with the next node and start over at the prerequisites.
• Optionally run apt modernize-sources. Answer n first to preview the changes, then rerun it and answer Y. The old .list files stay as .list.bak, and you can delete them once the new files check out.
• Journald may log kernel audit messages during the upgrade. Disable that beforehand with systemctl disable --now systemd-journald-audit.socket, or wait: the messages stop after the reboot.

If you run a cluster

• All nodes on 8.4.1+ before you start.
• One node at a time, maintaining quorum throughout. Upgrade, reboot, confirm it rejoins healthy, then move on.
• Ceph → 19.2 Squid first for hyperconverged setups.
• HA groups are deprecated in favor of HA rules; the migration happens automatically once every node is on 9.0. If HA acts up, check journalctl -eu pve-ha-crm.

If you lean on community automation for cluster nodes, give the helper-scripts safety guide a read first — running anything as root mid-migration deserves the same caution.

Verdict: upgrade now, or wait?

If your Proxmox 8 setup is doing its job and you don’t need anything specific in 9, waiting for a point release was a reasonable conservative choice while PVE 8 remained supported. PVE 8’s end of standard support was 2026-08, and that date has passed. The 9.x line is where supported installs now live. 9.2 was the current release when this page was checked September 26, 2026.

When you do upgrade, preparation decides how it goes. That means tested external backups, saved host configuration, resolved pve8to9 --full findings, pinned NIC names, real console access, and a read of the official release notes for your hardware.

There is no blanket rollback switch. Your recovery plan is the documented repair path for the failure you see, or a fresh PVE 9 install and restore from the backups you verified before starting.

Sources

• Proxmox VE official upgrade guide: Upgrade from 8 to 9 (revision last edited 2026-09-17; commands, repository files, config-file prompts and known issues re-read 2026-10-10)
• Proxmox VE roadmap / 9.x release notes
• Proxmox VE support lifecycle and end-of-life dates (FAQ)
• Proxmox VE backup and restore documentation
• Proxmox VE: Recover From Grub Failure
• Proxmox Backup Server official upgrade guide — Upgrade from 3 to 4
• Proxmox VE network device-name overrides
• Proxmox VE NVIDIA vGPU compatibility matrix
• Proxmox VE 9.2 release announcement (Debian 13.5, kernel 7.0, dynamic load balancer, WireGuard SDN)
• Proxmox forum — PVE 8 to 9 in-place upgrade reports