Proxmox VE 9: What's Actually New, What Breaks, and Whether to Upgrade Now

If you've been running Proxmox VE 8 on your home lab and haven't pulled the trigger on upgrading to 9 yet, May 2026 is a reasonable time to do it. Version 9.1.8 landed in April with automatic HA rebalancing — the last meaningful gap in the 9.x series for most home lab use cases. The upgrade path is well-documented, the community has flushed out the edge cases, and there are a handful of genuinely useful features waiting on the other side.

Here's an honest breakdown of what changed, what will break, and how to do the upgrade without destroying your lab.

---

What's Actually New in Proxmox VE 9

Linux Kernel 6.14

The jump from kernel 6.8 (PVE 8.x) to 6.14 is meaningful for newer hardware. If you're running a 12th/13th/14th gen Intel mini PC like the Minisforum MS-01 or a recent Beelink SER7, you'll see better thermal management, improved NVMe power states, and fewer quirks with USB NICs. AMD Zen 4 and 5 users get cleaner power management too.

For servers with Intel Arc GPUs — increasingly popular for Jellyfin transcoding — kernel 6.14 ships with significantly improved i915 driver support, including GuC/HuC firmware loading that was flaky on 6.8.

cgroup v2 is Now Mandatory

This is the biggest breaking change and the one most home labbers will hit. Proxmox VE 9 drops cgroup v1 entirely — there's no kernel parameter to opt back in.

What this means practically: any LXC container running systemd < 230 will not boot on PVE 9. The main casualties are CentOS 7, Ubuntu 16.04, and Debian 8. If you still have any of these running (maybe an old Pi-hole clone or legacy app container you've been meaning to migrate), deal with them before upgrading. Proxmox VE 8 has an estimated EOL of July 2026, so you have time — but not infinite time.

For modern containers (Ubuntu 22.04+, Debian 11+, Alpine 3.16+), cgroup v2 has been the default for years. You won't notice the difference.

RAIDZ Expansion (Finally)

This landed in ZFS 2.3.0 and makes it to PVE 9 as a first-class feature. RAIDZ expansion lets you add a single drive to an existing RAIDZ vdev — something that was literally impossible in ZFS for its first ~20 years.

If you have a 3-bay RAIDZ1 pool with 3×8TB drives and you want to add a 4th drive to expand capacity without rebuilding from scratch, PVE 9 makes that possible. The expansion process is online, non-destructive, and slow (plan for several days on large arrays). It's not instant — ZFS has to reflow every RAIDZ stripe — but it works and it's safe.

This feature alone is worth serious consideration if you've been managing ZFS storage on PVE 8 and running out of space.

OCI Containers in LXC (Tech Preview)

The headline feature of 9.1 is the ability to pull Docker Hub images directly into Proxmox and run them as LXC containers — no VM, no Docker daemon, no Portainer.

In the PVE web UI, go to your node → local storage → CT Templates → Pull From OCI Registry. Enter an image like nginx:alpine or ghcr.io/immich-app/immich-server:latest, and Proxmox converts it to an LXC template you can deploy like any other container.

The underlying runtime is still LXC, not Docker. This means no Docker Compose natively, no swarm, no overlay networks. What you get is a lightweight, Proxmox-managed container with the image you want — snapshotable, backupable via PBS, reachable through the same firewall and SDN rules as your other LXCs.

It's a tech preview, which means the rough edges are real:

For simple, stateless containers — an Nginx reverse proxy, a Redis instance, a small FastAPI app — it works well and significantly reduces the overhead of managing the full Docker stack. Worth experimenting with for single-service deployments.

HA Rebalancing in 9.1.8

If you run a multi-node Proxmox cluster with HA enabled, 9.1.8 is the release you've been waiting for. Previously, when a failed node came back online, its VMs stayed wherever HA had migrated them — meaning your cluster could end up with one node pinned at 80% RAM and another at 15% indefinitely.

9.1.8 adds automatic HA rebalancing: when a node recovers, Proxmox will migrate VMs back if doing so improves balance across the cluster. It's configurable — you can set affinity rules to control which VMs land where — and it runs without disrupting running workloads beyond a live migration.

For single-node home labs this is irrelevant, but for 3-node Proxmox clusters (increasingly common with cheap used mini PCs) it closes a genuine operational gap.

---

The Upgrade Process

Proxmox provides an in-place upgrade script. The process is well-tested and the tooling is solid. Here's the condensed version:

Pre-flight Checklist

Run the checker first — it will flag most of the issues before you touch anything:

pve8to9 --full

Install it if you don't have it:

apt install pve-upgrade-checker

Address every WARN and FAIL it outputs before proceeding. Common flags:

Snapshot Everything

Before you run the upgrade, snapshot your critical VMs:

# For each critical VM (replace 100, 101 with your VMIDs)
qm snapshot 100 pre-pve9-upgrade --vmstate 0
qm snapshot 101 pre-pve9-upgrade --vmstate 0

If you have Proxmox Backup Server, run a manual backup job now. A USB 3.0 external drive is cheap insurance if you don't have off-node storage.

Run the Upgrade

# Update current sources and packages
apt update && apt dist-upgrade -y
Switch to PVE 9 sources
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's|bookworm|trixie|g' /etc/apt/sources.list.d/pve-no-subscription.list
If you're on the enterprise repo:
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list
Update and upgrade
apt update
apt dist-upgrade -y
Reboot into the new kernel
reboot

The dist-upgrade will pull in the new kernel (6.14), updated QEMU, updated LXC tools, and all the PVE-specific packages. On a fast NVMe-based system this takes about 15–20 minutes plus the reboot.

After reboot, verify:

pveversion
Should output: pve-manager/9.1.x
uname -r
Should output: 6.14.x-x-pve

Post-Upgrade Verification

# Check all VMs are accessible
qm list
Check LXC containers
pct list
Check cluster status if applicable
pvecm status
Check storage pools
pvesm status

Start your containers one by one and watch journalctl -fu pve-container@ for any cgroup-related errors.

---

Should You Upgrade Now?

If you're on PVE 8.3 or 8.4, yes — 9.1.x is stable for home lab use. The upgrade tooling is mature, the documentation is solid, and the community has had months to shake out the edge cases.

If you have any of these, wait or resolve them first:

For most home labbers running a single-node Proxmox with a handful of Ubuntu/Debian LXCs and some VMs, the upgrade is routine. Run pve8to9 --full, fix what it flags, snapshot your VMs, run dist-upgrade, reboot. You'll be on 9.1 in an hour.

The RAIDZ expansion alone is worth it if you have a ZFS storage pool and any chance of needing to grow it. The OCI container support is legitimately interesting even in tech preview. And kernel 6.14 with cgroup v2-only is the right direction — the compatibility debt of supporting cgroup v1 forever had to end somewhere.

---

Hardware Worth Having for a PVE 9 Lab

If you're thinking about building or expanding your lab alongside the upgrade:

---

Proxmox VE 9 isn't a dramatic reinvention — it's a solid maturity release. cgroup v2 enforcement clears technical debt. RAIDZ expansion fixes a decades-long ZFS limitation. OCI containers open up a genuinely new workflow even in tech preview. And the kernel bump makes newer hardware actually work the way it should.

Run the checker, fix what it flags, and get off PVE 8 before July.

---

Disclosure: This post contains affiliate links. If you purchase through these links, I may earn a small commission at no extra cost to you.