How to Upgrade Proxmox 8 to 9: pve8to9, Repos, Reboot

Here is how to upgrade Proxmox 8 to 9 in place: update the host to the latest 8.4 (pve-manager 8.4.1 or newer), run pve8to9 --full until it comes back clean, switch your APT sources from bookworm to trixie, run apt dist-upgrade, and reboot. It is the officially supported path in the Proxmox upgrade guide, no reinstall required.

Proxmox VE 9.0 shipped on 5 August 2025 on Debian 13 “Trixie”. The newest x86 release on the Proxmox roadmap at the time of writing is 9.2 (21 May 2026), with a 7.0 kernel as the stable default, and the repos track the latest point release. On a single N100 mini-PC with one NIC, the whole upgrade mostly hinges on whether that NIC keeps its name.

Should you upgrade in place or reinstall?

Upgrade in place if the host is a normal Proxmox install, your guests sit on local ZFS, LVM-thin or a NAS share, and /etc has not become an archaeology site. The upgrade guide also documents the other route: back up guests and /etc/pve, install 9 from the ISO, restore. Pick that if the host started as plain Debian with extras, or you were replacing the boot SSD anyway.

Hold off, or fix things first, if any of these known issues from the guide apply to you:

• Old LXC containers. cgroup v1 is gone, so containers running systemd 230 or older (CentOS 7, Ubuntu 16.04) will not start. Rebuild them on a current template, or move them into a VM.
• Veeam. Backups break for VMs on QEMU machine version 10.0 or newer. Pin affected VMs to 9.2+pve1 or postpone.
• NVIDIA vGPU on drivers older than GRID 18.3 (570.158.02).
• GlusterFS storage, which 9 dropped.

What to do before you touch apt

1. Back up every guest and test one restore. Point vzdump at Proxmox Backup Server or an NFS share on the NAS, then restore one guest to a spare VMID and boot it. Snapshots do not count, because they die with the pool; the Proxmox backup strategy guide covers retention and offsite copies. If PBS runs on the same host, also follow the PBS 3-to-4 upgrade guide and its pbs3to4 checker.
2. Copy /etc off the host, /etc/pve above all: tar czf /mnt/pve/nas-backup/etc-$(hostname).tgz /etc is enough.
3. Get a real console. A monitor and USB keyboard, IPMI, or SSH inside tmux or screen.
4. Check free space. At least 5 GB on the root filesystem, ideally more than 10 GB.
5. Ceph users only: move to Ceph 19.2 Squid first. The Ceph vs ZFS replication guide covers whether you need Ceph at all.

What does pve8to9 check?

pve8to9 is a read-only checklist that ships with the latest 8.4 packages. It changes nothing; it reports what would break, such as outdated packages, guest network settings, custom roles and LVM storage, and tells you which packages to add or remove. Run pve8to9 --full at least once, fix each warning, and rerun it until it is clean.

The warnings worth understanding rather than silencing:

• VirtIO vNIC MTU. In 9, a vNIC with no MTU set inherits the bridge MTU instead of defaulting to 1500. If vmbr0 runs jumbo frames toward your NAS, every flagged guest silently goes jumbo too. Set the MTU explicitly on those vNICs before upgrading.
• LVM autoactivation. New LVs in 9 are created with autoactivation off. For existing guest volumes the checker points at /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation, strongly recommended for shared LVM and optional for local-only storage.
• systemd-boot meta-package. If flagged, remove it, unless you set up systemd-boot by hand.
• Root on LVM in UEFI mode. Install grub-efi-amd64.
• Custom roles using VM.Monitor. That privilege is gone; update the roles after the upgrade.

The upgrade, step by step

1. Get current on 8.4

apt update
apt dist-upgrade
pveversion
pve8to9 --full

2. Pin your NIC names

The roadmap warns that the kernel jump (for example 6.8 to 6.14) can rename network interfaces. On a one-port mini-PC that means vmbr0 loses its uplink and the web UI disappears. The admin guide’s pinning tool writes .link files with stable nic-prefixed names and updates /etc/network/interfaces and the host firewall config to match:

pve-network-interface-pinning generate

The node needs a reboot to apply it. Do that reboot on 8.4 and confirm the bridge comes up, while you still have a known-good kernel.

3. Point APT at 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

Then add the Proxmox repo in the new deb822 format. Most homelabs use no-subscription:

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

Delete the old PVE 8 pve-no-subscription line (usually in sources.list or pve-install-repo.list). Subscription holders create pve-enterprise.sources instead, with component pve-enterprise, and remove the old .list. Replace any ceph.list with a ceph.sources pointing at ceph-squid, and remove backports lines. Then verify:

apt update
apt policy

No errors, and nothing still pointing at bookworm.

4. Run the upgrade

Optionally run systemctl disable --now systemd-journald-audit.socket first to silence kernel audit noise. Then apt dist-upgrade. Answer the config prompts like this:

Press q if apt-listchanges opens, and accept the default on service-restart prompts.

5. Recheck and reboot

pve8to9 --full
reboot

Reboot even if you already ran the opt-in 6.14 kernel on 8.

Which Proxmox 9 changes break homelabs?

The renamed NIC is the one that strands people: one onboard port, one bridge, and a new interface name leaves the host unreachable until you fix it at the console. Behind it come /tmp moving to RAM, /etc/sysctl.conf being ignored, PCI passthrough regressions, and a memory graph that suddenly reads over 100%.

• Renamed NIC. If you skipped pinning, log in at the console, check ip -br link, correct the name in /etc/network/interfaces, and reboot. The bridge and VLAN guide shows what a sane vmbr0 stanza looks like.

• /tmp on tmpfs. Debian 13 stores /tmp in memory, and the Proxmox guide notes it can use up to 50% of RAM, with /tmp and /var/tmp cleaned periodically. On a 16 GB box, a script that stages ISOs in /tmp now competes with ZFS ARC and your guests.

• /etc/sysctl.conf ignored. systemd-sysctl no longer reads it. Move forwarding or rp_filter settings into /etc/sysctl.d/<NN>-<name>.conf.

• PCI passthrough. The guide lists VMs failing to start on kernel 6.14; the workaround is booting an older kernel and pinning it. The Host Bootloader page documents the tool:

  proxmox-boot-tool kernel list
  proxmox-boot-tool kernel pin <version>
  proxmox-boot-tool refresh

  The GPU passthrough guide covers the IOMMU side if something else breaks.

• Memory over 100%. Cosmetic: the host view now includes VM overhead.

How do you upgrade a Proxmox cluster?

One node at a time, with a healthy cluster before you start. Migrate guests off the node you are upgrading onto another one; moving from an older version to a newer one works, the reverse is unsupported. Live migration between different CPU vendors or models can hang VMs, so test first.

HA groups convert to HA rules automatically once every node runs 9; if HA misbehaves, check journalctl -eu pve-ha-crm on the active CRM node. Quorum basics are in the cluster setup guide. Ceph Squid 19.2.6 and later flag “insecure key types” as HEALTH_ERR; services keep running, and the key migration waits until every node is on 9.

After the reboot

• pveversion should report 9.x. Clear the browser cache and force-reload the web UI.
• Check ip -br link and that every guest starts, especially passthrough VMs.
• Run the LVM migration script if pve8to9 suggested it.
• Optionally run apt modernize-sources to convert leftover .list files to deb822; it keeps the originals as .bak.
• Run a backup job immediately, so your newest restore point matches the version you run.

If it goes wrong

• Interrupted upgrade: apt -f install, then rerun apt dist-upgrade.
• “You are attempting to remove the meta-package ‘proxmox-ve’”: some repo has no Trixie suite. Fix or remove that repo, run apt update, and retry.
• “Manual repair required!” on the thin pool: lvconvert --repair pve/data.
• GRUB failure: follow the “Recover From Grub Failure” page linked from the upgrade guide.

For quorum, storage and VM errors afterwards, see the troubleshooting guide.

FAQ

Is Proxmox VE 8 still supported?

No. The Proxmox VE FAQ lists Proxmox VE 8, built on Debian 12 Bookworm, with a Proxmox end-of-life of 2026-08, one month after Debian’s own 2026-07 cutoff. Hosts keep booting and running guests, but they no longer receive security fixes for the kernel, QEMU or the web stack, so upgrading is overdue.

How long does the Proxmox 8 to 9 upgrade take?

The package upgrade itself takes under five minutes on fast SSD storage and can run past 60 minutes on a slow spinning disk, according to the official upgrade guide. Add time for backups, a test restore, working through pve8to9 warnings and the reboot. The preparation is the slow part, not apt.

Can I upgrade Proxmox 7 directly to 9?

No. The 8-to-9 procedure requires every node to run the latest Proxmox VE 8.4 before you start, and pve8to9 ships with those 8.4 packages. A 7.x host has to complete the 7-to-8 upgrade first, then update to 8.4, then follow the steps above. The alternative is a clean 9.x install plus restores.

Can I run the Proxmox upgrade from the web UI shell?

No. The upgrade guide says not to run it from the GUI’s virtual console, because that session gets interrupted mid-upgrade. Use a physical keyboard and monitor, IPMI, or SSH inside tmux or screen so a dropped connection does not kill apt halfway through. On a mini-PC, an HDMI cable and USB keyboard do the job.

Related across the network

• Proxmox LXC vs VM Explained: Which to Use and When — proxmoxlab.org
• Proxmox on a Mini PC: LXC vs VM, Storage and Backups — minilabhq.com