Proxmox VE 9 is here — built on Debian 13 “Trixie” with Linux kernel 6.14 — and the in-place upgrade from 8 to 9 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.

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.

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 kernel 6.14.
  • 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.

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 6.14 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 kernel 6.14. 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.

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 kernel 6.14 (required), 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 or two is perfectly reasonable — let the edge cases settle. There’s no penalty for being a release behind on a homelab.

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, kernel 6.14) 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 Linux kernel 6.14 (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 kernel 6.14, 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. 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).