Proxmox VE 9.0 dropped on August 6, 2025. I was still on 8.3.4, so this got my attention. Any release that swaps the underlying Debian release, adds storage features I’ve actually wanted, and touches the SDN stack is not a casual Friday update.
The Headline Items
Proxmox VE 9.0 moves the base OS to Debian 13 “Trixie”. That means kernel 6.12, systemd 257, glibc 2.41, and Python 3.13. It also introduces snapshots for thick-provisioned LVM shared storage, a new Fabrics feature in the SDN stack, and native affinity rules for VM and container placement.
These aren’t cosmetic changes. The Debian jump alone changes driver support, firmware expectations, and container defaults. The rest of the features fix real operational gaps I’ve hit in my own cluster.
Debian 13 Trixie
My three-node lab runs Supermicro X11 boards and a couple of Beelink SER7s. Kernel 6.12 is the big draw here. It brings improved AMD P-State driver behavior and better Intel i226-V NIC stability, which matters because the 6.8 series in Debian 12 gave me occasional soft lockups under IOMMU load.
Systemd 257 and glibc 2.41 also mean container templates built for Debian 13 will default to new library expectations. If you’re running LXCs with custom bind mounts or legacy applications, test them before you migrate. I already caught one side project failing because Python 3.13 removed a few deprecated urllib.parse behaviors.
Thick LVM Snapshots
This is the one I’ve been waiting for. Until 9.0, snapshots on shared LVM required thin provisioning. If you were presenting a raw thick LUN from your NAS or a shared SAS array, you were stuck. Now lvcreate -s works on thick-provisioned shared storage volumes.
In practice, this means I can snapshot a 500 GB Windows VM living on my TrueNAS-backed LVM without converting the entire volume group to thin pools. The snapshot still lives in the same volume group, so plan your extents, but it removes a major architectural constraint.
I tested this on a spare node already. The workflow is identical to thin snapshots in the GUI, but the backend now calls lvm with the correct shared-lock flags:
lvcreate --snapshot --size 100G --name vm-100-disk-0-snap /dev/pve-shared/vm-100-disk-0Verify your lvm.conf has locking_type set appropriately for clustered shared storage if you’re not using SAN-level locks.
SDN Fabrics
The SDN stack in Proxmox has been usable but basic. 9.0 adds Fabrics, which lets you define underlay network fabrics that feed into your VXLAN or EVPN zones. Instead of manually configuring the physical topology per node, you declare a fabric object and attach zones to it.
I haven’t migrated my VXLAN setup yet. My current flat VLAN bridges are stable, and Fabrics seem aimed at larger clusters or anyone running BGP to an upstream switch. Still, it’s nice to see the SDN moving toward declarative underlays instead of per-node ifupdown hacks.
Affinity Rules
Before 9.0, keeping two VMs off the same node meant writing a custom hook or using Ceph-level orchestration. Now you can set affinity and anti-affinity groups directly in the GUI or via API.
This is useful for my Talos Kubernetes worker nodes. I run them as VMs on Proxmox, and I want the control plane spread across physical hosts. The new rules use a groups syntax in the VM config:
pvesh set /nodes/pve1/qemu/100/config --affinity-groups 'anti-control-plane'Then you define the group behavior in the cluster-wide datacenter.cfg. It’s primitive compared to Kubernetes pod anti-affinity, but for bare-metal VM placement, it’s sufficient.
What I’d Verify Before Touching Production
I don’t upgrade production nodes on release day. Here’s my checklist for 9.0.
Test Debian 13 on your NICs and storage HBA first. Boot a standalone Trixie live image and verify dmesg is clean. I found that my older Broadcom BCM5719 needs firmware files that moved from firmware-misc-nonfree to firmware-bnx2 in Trixie. Small packaging changes break unattended installs.
Snapshot your /etc and cluster database. Proxmox upgrades are usually smooth, but the corosync/pve-manager bump in a Debian version jump is a non-trivial migration. I run this before any major release:
tar czf /root/pve-config-backup-$(date +%F).tar.gz /etc/pve /etc/corosync /etc/network/interfacesCheck your backup hooks. If you use vzdump hooks for offsite sync, verify they still run under Python 3.13. I had to update a paramiko call in my post-backup script because of deprecated API changes.
Read the SDN migration notes. If you use the experimental SDN plugin, 9.0 changes how zone configs validate. Back up /etc/network/interfaces.d/* and the SDN JSON in /etc/pve/sdn before the upgrade.
Plan a rolling upgrade. Mixed-version clusters work during rolling upgrades, but only within reason. Upgrade your non-HA nodes first, then migrate VMs off your target node, then run apt dist-upgrade. Never upgrade the node hosting the majority of your quorum simultaneously.
My Plan
I’m going to wait two weeks for the initial bug reports to settle on the pve-user mailing list. Then I’ll upgrade my spare NUC node—the one running nothing but a Pi-hole LXC—to 9.0. If that survives a week of apt upgrade cycles and my ZFS-over-iSCSI storage stays clean, I’ll roll it to the SER7s.
I won’t touch the main Supermicro nodes until 9.0-1 or until I see a clean Ceph Quincy-to-Squid migration path documented. The thick LVM snapshot feature is tempting, but I can wait. My TrueNAS is already snapshotting at the block level; I just wanted the convenience of Proxmox-native snapshots for VM exports.
The affinity rules are going into use immediately on my test cluster, though. I’m tired of manually pinning Talos worker VMs across nodes. If the API stays stable, I’ll script group assignments into my Ansible inventory and retire my qm wrapper scripts.
Still undecided on SDN Fabrics. My home lab isn’t multi-rack, and my switches don’t run BGP. For now, flat VLANs and Linux bridges are good enough.