Major version bumps in Proxmox VE aren’t vanity releases. They mean a new Debian base, a kernel jump, and breaking changes that ripple through Ceph, SDN, and backup schedules. When 9.0 dropped on August 5, 2025, I read the release notes twice before I even considered touching my three-node cluster.
What 9.0 actually brings
Proxmox VE 9.0 is built on Debian 13 Trixie, which brings a newer Linux kernel, updated userland libraries, and the usual cascade of dependency changes. According to the Proxmox training video and wiki, headline items include a kernel bump to the 6.12 LTS series, Ceph updates, web UI refinements, and improved SDN integration. The installer also shifts away from legacy BIOS boot paths on certain media. That matters if you’re still deploying on older hardware.
Backup and restore saw attention too. The vma/zstd stack got tweaks that affect compression throughput on high-core-count hosts. I haven’t benchmarked it yet, but the changelog suggests faster restore times for large Windows guests.
Why I’m waiting
My home lab runs a mix of Debian LXCs, Ubuntu VMs, and a small Ceph pool for VM disks. A major Debian base change means I need to verify every custom repository, every Ansible role that pins packages, and every LXC template I built from scratch. Ceph is the biggest risk. Moving between major Proxmox versions often requires a careful Ceph upgrade sequence, and I don’t have a secondary cluster to burn down.
My sources are still pinned to Bookworm:
# /etc/apt/sources.list.d/pve.list
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscriptionI’m not changing that until I’ve tested everything.
Actionable takeaways
Audit Ceph before you touch anything
If you’re running CephFS or RBD pools, the upgrade path from Reef to the version shipping with 9.0 isn’t automatic. Run ceph health detail and confirm your OSDs are on compatible firmware. Check the Proxmox Ceph migration notes twice. One wrong ceph orch command and your storage layer is offline.
Validate your backup chain
Before any major Proxmox upgrade, I run a full vzdump cycle and copy archives to off-cluster storage. 9.0’s backup format changes might be backward-compatible, but I don’t trust that until I’ve done a test restore into a 9.0 VM. Paranoia is a feature, not a bug.
Check hardware compatibility
The kernel bump to 6.12 LTS is great for newer NICs and GPU passthrough, but it can drop support for older chipsets. I keep a Supermicro X9 generation node in the cluster for cold storage. If 9.0 drops drivers I need, that node stays on 8.x until I retire it.
Use a canary node
Don’t upgrade the production cluster first. I run a single-node test instance on a Dell OptiPlex. That’s where 9.0 lives until I’ve verified networking, Ceph, and my Ansible playbooks against the new package versions. If the canary dies, the cluster stays untouched.
What I decided
I waited ten months. The cluster stayed on 8.x while I watched the Proxmox forums, bug tracker, and r/homelab for edge cases. By early 2026, the Ceph migration path was well-documented and the initial NIC driver regressions were patched. I built a fresh 9.0 single-node test lab on a spare NUC, ran my Ansible roles against it, and verified my LXC templates boot clean on Debian Trixie.
My plan is to start the rolling upgrade this weekend. Node 1 gets wiped and reloaded with 9.0 first. If it stays stable for two weeks and Ceph remains in HEALTH_OK, I’ll bring nodes 2 and 3 online. I’m keeping the Supermicro X9 on 8.x until I retire it. No rush. Infrastructure doesn’t age out in ten months, but patience keeps you from rebuilding clusters on Sunday night.