Quick answer

The Proxmox VE 8 to 9 upgrade is an officially supported in-place upgrade: get every node to 8.4.1+, run pve8to9 –full until clean, take a tested backup, switch repositories from Debian bookworm to trixie, then apt dist-upgrade and reboot. Today it lands you on 9.2 (kernel 7.0). PVE 8 support ends August 2026.

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

Proxmox VE 9 has been out since August 2025, and the current release — 9.2, built on Debian 13.5 “Trixie” with Linux kernel 7.0 — is what a fresh in-place upgrade from 8 lands you on today. The 8-to-9 in-place upgrade is officially supported. It is also a real version jump, not a point release, and it ships a handful of breaking changes that can leave a node off the network or refusing to boot if you walk in unprepared.

There’s a clock on it now, too: Proxmox VE 8 reaches end of standard support in August 2026, which is why upgrade searches are climbing through the summer. This is the pre-flight guide: what to check before you start, the gotchas that actually bite, and the upgrade steps themselves — built from Proxmox’s official Upgrade_from_8_to_9 documentation and the issues the community has reported hitting. The mechanism is not scary. 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.

Proxmox VE 8 to 9 in-place upgrade flow: get every node to PVE 8.4.1 or later, run pve8to9 --full and clear every warning, take a tested backup, switch the repositories to Debian 13 Trixie, then dist-upgrade and reboot.
Proxmox VE 8's support clock
The 8→9 upgrade isn't urgent because 9 is shiny — it's urgent because 8 runs out of official support. A homelab box keeps booting afterward, but with no more security or bug fixes.
End of standard support
August 2026
Jul 2026 — you are here ▼
Supported · since Jun 2023
Unsupported
● Jun 2023 — PVE 8 released Aug 2026 — EOL →
PVE 9 has been available since August 2025, so there's a mature 9.x line (now 9.2) to land on — you're not an early adopter. Waiting for a point release you trust is still fine; just remember that wait now has a hard deadline a few weeks out.
techfuelhq.com · dates per Proxmox's official support-lifecycle table

The short version

  • Get every node to PVE 8.4.1 or later first.
  • Run pve8to9 --full and clear every warning before touching repositories.
  • Back up all VMs/containers (ideally a tested 3-2-1 backup) and make sure you have IPMI or physical console access.
  • Switch repos from bookworm to trixie, apt update && apt dist-upgrade, reboot into the new kernel (7.0 on the current 9.2).
  • On a cluster: one node at a time, keep quorum, Ceph to Squid first.
  • Expect possible NIC renames and LVM autoactivation changes — handle them before you reboot.

What you’re actually upgrading to

When you point your repositories at Trixie and run apt dist-upgrade, APT installs the current Proxmox VE 9 packages — you don’t get to choose 9.0. As of mid-2026 that means you land directly on Proxmox VE 9.2 (released May 21, 2026), not 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 as the new default for hyperconverged clusters, 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 that migrates guests across a cluster from 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 upgrade procedure — but it’s worth knowing you jump straight to the current release, and that the newer kernel is what drives the NIC-rename and PCI-passthrough gotchas further down.

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.
  • Tested backups of every guest. Test a restore in a lab if you can.
  • 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: upgrade PBS to version 4 first.

Run the checklist: pve8to9 --full

Before changing a single repository line, run:

pve8to9 --full

It flags common incompatibilities — repository state, LVM, boot configuration, known package conflicts — but it does not fix anything for you. Work through every warning, then run it again until it’s clean. This one command prevents the majority of failed upgrades.

The gotchas that actually 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 in shared-LVM setups. Existing volumes keep their old behavior, but this trips people on shared storage. There’s a migration helper at /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation, and some LVM thin pools need a manual repair afterward:

lvconvert --repair pve/data

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. Proxmox ships pve-network-interface-pinning to lock your current names in place — run it before the upgrade, and keep console access handy just in case.

If you run a Ceph Full Mesh with post-up /usr/bin/systemctl restart frr.service, that line will deadlock on 9 — switch it to a conditional restart.

Boot and systemd changes

  • Remove the systemd-boot meta-package where proxmox-boot-tool manages booting (the upgrade notes call this out).
  • 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.

Containers, passthrough, and migration

  • cgroup v1 is removed. Containers running systemd older than 230 (CentOS 7, 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 needs driver ≥570.158.02 (GRID 18.3+); Veeam is incompatible with QEMU machine version ≥10.0.
Six green lights before you touch a repo
The 8→9 mechanism is routine. These six pre-flight checks are where the whole risk lives. Get every lamp green before you run apt dist-upgrade — no exceptions.
1 · On PVE 8.4.1+, every nodepveversion
The pve8to9 checker only ships in the latest 8.4 packages.
2 · A tested backup of every guestvzdump / PBS
Not just taken — restore-tested. It is your only real undo.
3 · pve8to9 --full comes back cleanpve8to9 --full
It only reports; you fix each warning, then re-run until it is zero.
4 · NIC names pinnedNIC pinning
The new kernel can rename interfaces; a stale vmbr0 comes up with no network.
5 · Console that isn't the web GUIIPMI / tmux
The GUI's noVNC console dies with the services mid-upgrade. Use IPMI, physical, or SSH in tmux.
6 · Ceph on 19.2 Squid (if hyperconverged)ceph -v
Upgrade Ceph to Squid before PVE. No Ceph? This one is a free pass.
All six green → apt dist-upgrade Miss one and the upgrade can still “succeed” — then the node reboots onto no network, or won't boot at all. The checklist is the job.
techfuelhq.com · prerequisites per Proxmox's official Upgrade_from_8_to_9 guide

The upgrade itself

Once pve8to9 --full is clean and you’ve handled the gotchas above:

  1. Migrate guests off the node you’re about to upgrade (on a cluster).
  2. Point repositories at Trixie. Switch bookworm → trixie across your APT sources and the Proxmox repo (the deb822 .sources format is recommended on 9). Update Ceph repos to Squid/trixie if applicable.
  3. Upgrade:
    apt update
apt dist-upgrade
    Answer the config-file prompts deliberately — for /etc/lvm/lvm.conf the maintainer version is recommended; for /etc/default/grub, diff it if you’ve customized it.
  4. Reboot into the new kernel — required (the current 9.2 ships kernel 7.0). Reboot even if you were already running a 6.x kernel on 8; 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.

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.

Honest 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 you trust is perfectly reasonable — let the edge cases settle. The one thing that’s new in 2026: PVE 8 reaches end of standard support in August 2026, so “wait” now means “wait a few weeks, not indefinitely.” Being a release behind on a homelab is fine; sitting on an unsupported, unpatched hypervisor is a different call. There’s plenty of runway on the mature 9.2 line to land on before the cutoff.

When you do upgrade, the deciding factor isn’t timing, it’s preparation: a tested backup, a clean pve8to9 --full, pinned NIC names, real console access, and a read of the official release notes for your hardware. The upgrades that go sideways are almost always the ones that skipped the checklist — old GPUs, PCI passthrough, and shared-LVM storage are the usual suspects. Do the pre-flight, keep a solid backup you can fall back to, and the jump to 9 is routine.

Sources

Frequently asked questions

Is the in-place Proxmox VE 8 to 9 upgrade safe?
Yes — it is an officially supported in-place upgrade (apt dist-upgrade after switching repositories from Debian Bookworm to Trixie), and the process is well-documented. ‘Safe’ still depends on doing the prerequisites: be on PVE 8.4.1 or later, run the pve8to9 –full checklist and clear every warning, and have a tested backup before you start. The risk is not the upgrade mechanism; it is the handful of breaking changes (LVM autoactivation, NIC renaming, the new kernel) that can leave a node unbootable or off the network if you do not prepare for them.
What are the biggest breaking changes in Proxmox VE 9?
Proxmox VE 9 moves to Debian 13 Trixie and a new Linux kernel (6.14 at the 9.0 launch, 7.0 on the current 9.2 release; a reboot is required). The changes most likely to bite: LVM autoactivation is now disabled by default for new logical volumes in shared-LVM setups; network interfaces can be renamed because the new kernel detects additional hardware features; cgroup v1 is removed (very old containers like CentOS 7 stop working); and PCI passthrough can break on the new kernel, sometimes needing an older pinned kernel. Run pve8to9 –full to see which apply to your node.
Will my network interface names change after upgrading to Proxmox 9?
They can. The newer kernel may recognize additional NIC hardware features, which changes the predictable interface name (for example enp1s0 could become a different name), and if your bridge (vmbr0) references the old name the host comes up with no network. Proxmox ships a pve-network-interface-pinning tool to lock current names before you upgrade. Pin your interface names first, and have IPMI or physical console access in case the host comes up unreachable.
Do I need to back up before the Proxmox 8 to 9 upgrade?
Yes, without exception. The official guidance is that a valid, tested backup is always required before starting. Back up every VM and container (Proxmox Backup Server makes this a 3-2-1 strategy), and ideally test a restore in a lab first. Several gotchas — a failed boot, a renamed NIC, an LVM thin pool needing repair — are fully recoverable if you have backups and console access, and painful if you do not.
How do I upgrade a Proxmox cluster from 8 to 9?
One node at a time, maintaining quorum throughout, and all nodes must be on PVE 8.4.1+ first. Migrate guests off the node you are upgrading, upgrade it, reboot, verify it rejoins healthy, then move to the next. If you run hyperconverged Ceph, upgrade Ceph to 19.2 Squid before starting the PVE upgrade. HA groups are deprecated in favor of HA rules, with automatic migration once every node reaches 9.0. Do not run the upgrade from the web GUI’s console — use a physical console or SSH inside tmux/screen.
Should I upgrade to Proxmox 9 right now or wait?
If your PVE 8 cluster is doing its job and you do not need anything specific in 9, there is no harm in waiting for a point release or two to let edge-case bugs settle — that is standard, conservative homelab practice. The one change to that math in 2026: Proxmox VE 8 reaches end of standard support in August 2026, so ‘waiting’ now has a deadline. If you do upgrade, the deciding factor is preparation, not timing: back up, run pve8to9 –full, pin NIC names, ensure console access, and read the official release notes for your exact hardware (old GPUs and PCI passthrough setups are the most common sources of trouble).
When does Proxmox VE 8 reach end of life?
Per Proxmox’s official support lifecycle table, Proxmox VE 8 (built on Debian 12 Bookworm) reaches end of standard support in August 2026 — roughly three years after its June 2023 release, tracking Debian 12’s security-support window. After that, the 8.x line receives no further Proxmox security or bug-fix updates. Nothing forcibly stops an 8.4 box from running, but you would be on an unpatched, unsupported platform, which is exactly why 8-to-9 upgrade activity climbs through mid-2026. Plan to be on 9.x before the August cutoff.
Which Proxmox VE 9 version do I get when I upgrade, and what is new?
You get whatever is current in the trixie repositories at the moment you upgrade, which as of mid-2026 is Proxmox VE 9.2 (released May 21, 2026) — not the original 9.0 from August 2025. That means you land on Debian 13.5, Linux kernel 7.0, QEMU 11.0, LXC 7.0, and ZFS 2.4. Headline 9.2 additions over 9.0 include a dynamic load balancer that rebalances guests across a cluster from live utilization, native WireGuard and BGP support in the SDN stack, and custom CPU model management in the web UI.

Evidence ledger

Last updated
Methodology
This tutorial was written and edited by Lowell K. Wood IV in St. Louis County, MO. Specs, prices, commands, and version numbers are drawn from the official vendor, reseller, and project documentation current on the date above, and were verified before publishing. First-person hardware claims appear only where the article shows a verifiable artifact — a photo, receipt, or measurement — or links to the TechFuelHQ Open Bench Datasets. Every fact is human-verified against its cited source before publishing; AI assists with first-draft structure and source-gathering, not with the verdict. Full editorial standard: methodology.
Update log
  • 2026-07-13 — Last reviewed and updated.
Corrections
Spotted an error or stale price? Email hello@techfuelhq.com. Confirmed corrections are added to the update log above.

About the author

Written by Lowell K. Wood IV. Lowell builds and runs TechFuelHQ from St. Louis, Missouri, pairing thirteen-plus years of hands-on homelab, PC, server, and networking experience with cited third-party testing and first-party benchmarks on the gear he still runs. He also works ground EMS as a Nationally Registered Paramedic (NREMT).