Proxmox VE 9: what changed, and what to test

The node from Install Proxmox VE 9 on bare metal is already on 9.2. After apt-get dist-upgrade and a reboot, pveversion printed proxmox-ve: 9.2.0, pve-manager 9.2.24, and the running kernel 7.0.14-26-pve. The ISO itself had booted 7.0.2-6-pve. The manager package and the running kernel stay different facts until the node comes back up.

Proxmox VE 9.2, the release those packages belong to, is Debian 13.5 with QEMU 11.0, LXC 7.0, and ZFS 2.4. The change on a node that already has guests is the Cluster Resource Scheduler. In dynamic mode it reads live node and guest utilization and can migrate HA-managed guests to pull an unbalanced cluster back together. A one-node lab has a single legal placement, so the install can finish while the balancer stays idle.

What changed from 9.0 to 9.2

The roadmap splits the major release into three dates. Each one moves the kernel, and 9.2 is the one that starts moving guests.

9.0 is the Debian 13 base and the upgrade path from 8.4. Thick-provisioned LVM, the kind of LUN you get from a storage box over iSCSI or Fibre Channel, can keep VM snapshots as volume chains. That setting is still marked a technology preview. HA affinity rules say which nodes a guest may land on, and whether a set of HA guests should stay together or stay apart. SDN fabrics in that release are OpenFabric and OSPF. The checklist binary is pve8to9.

9.1 adds LXC from OCI images, including a technology-preview path for application containers, and it stores virtual TPM state as qcow2 so a Windows guest with a TPM can snapshot on NFS or CIFS. The nested-virt CPU flag turns on nested virtualization for the host vendor's CPU type, which is the lever for a Windows guest that wants Virtualization-based Security on the vendor CPU type, with host left for guests that need every host flag.

9.2 is the release the 21 May 2026 announcement describes: kernel 7.0 as the stable default, Ceph Squid 19.2.3 still supported, and Ceph Tentacle 20.2.1 as the stable extra. The 9.2 changelog says a fresh pveceph install, and the wizard on a Ceph-free cluster, pre-select Tentacle. A cluster that already runs Squid keeps Squid when a new node joins. The arm64 build landed on 5 August 2026 for NVIDIA Grace and NVIDIA Vera, with other UEFI ARMv9-A hardware on a best-effort basis. Device-tree boards such as the Raspberry Pi stay off that list. Live migration stays inside one architecture. SeaBIOS, AMD SEV, and Intel GVT-g are x86-only.

What the HA balancer moves

Dynamic scheduling uses real-time node and guest metrics and migrates HA-managed guests. The sensitivity lives in the HA panel or the datacenter options. The roadmap names the mode and the panel, and leaves the threshold, the hold time, and the scheduler name on the HA panel of the node you are about to enable.

HA-managed guests are the ones it can move. Ordinary guests stay where you put them. On a single node the scheduler has one legal placement, which is why a nested install can sit on 9.2.24 with a running VM and still show zero balancer migrations. The test that proves the feature is a second node, after the first node has already cloned, firewalled, backed up, and rebooted cleanly.

disarm-ha and arm-ha are the CRM commands that suspend the HA stack for planned work, such as a cluster-network change, and then put it back. The resource state is kept, so guests return to the state and placement they had. The 9.2 known-issues list has a narrow stall: if the stack is disarmed while HA resources are still migrating, an upgrade from a pve-ha-manager older than 5.2.4 can stop on the package triggers. The documented recovery is to re-arm, and the upgrade continues. The same note says enterprise-repository users were clear of that stall, and so was any cluster that left HA armed. Wait for in-flight migrations to finish, or leave the stack armed, before you upgrade a cluster that has used disarm.

Custom CPU models are created under Datacenter, Guest Resources/Hardware. The flag selector shows which flags the cluster nodes actually share, which is the check you want before a live migrate between two different CPUs. On Intel, Windows 11, Windows Server 2022, and Windows Server 2025 guests that use CPU type host with Virtualization-based Security can freeze for a stretch, with the summary pinned at 100% CPU. qemu-server 9.2.0 adds machine version 11.0+pve2. Guests created from the 9.2 ISO, or from an older qemu-server, on machine 11.0 or 11.0+pve1 need that package and a move to 11.0+pve2 or newer. The Ubuntu guest in the install used CPU type host and is a Linux VM, so the freeze case is a Windows guest with VBS.

The same 9.2 VM changelog records PSA-2026-00017-1: dumping the cloud-init password requires VM.Config.Cloudinit. Create a Proxmox API token and separate privileges measured qemu-server 9.2.13 on this node and the narrower cloud-init privileges that build sits on. A token that could read the password on 8.4 needs the privilege checked again after the upgrade.

What to test before the second node

The upgrade from 8 to 9 wants every node on Proxmox VE 8.4.1 or newer before pve8to9 means anything. A hyper-converged Ceph cluster has to be on Squid 19.2 before the Debian 13 upgrade. The script is in the 8.4 packages:

pveversion
pve8to9
pve8to9 --full

Run it before the upgrade and again after apt-get dist-upgrade, then reboot. On the install guest the manager moved from 9.2.2 to 9.2.24 and the running kernel stayed 7.0.2-6-pve until that reboot. uname -r afterwards was 7.0.14-26-pve, which is the build covered in CVE-2026-98432: the Proxmox kernel to boot. The ISO kernel 7.0.2-6 is also the one the 9.2 known issues call out for megaraid_sas and some NVMe drives in JBOD mode. That bug is fixed from kernel 7.0.14-15. On hardware that hits it, the roadmap's advice is to install from the 9.1 ISO and upgrade to 9.2, so the first boot uses a kernel that already has the fix.

apt-get update
apt-get dist-upgrade
reboot
uname -r

Clone the cloud-init template and SSH in. Build a cloud-init template on Proxmox is that template. A clone that comes up with the wrong address, or with the guest agent missing, is an image problem you want on one VMID before every customer VM is a clone of it. Tiernan O'Toole's cloud-image note says the package virt-customize needs is dhcpcd-base. The full dhcpcd package also starts a DHCP client, and on his node that client took leases on bridges and left extra default routes. Check ip route if that package was installed on the host.

The datacenter firewall policy is the one customers already bought. Confirm it is still the policy after the upgrade, on one guest, with a port you expect to be open and a port you expect to be closed.

One backup job, then a restore you can log into. PBS vs vzdump vs snapshots: restore times is the timing on a small disk. The 9.2 API drops the legacy starttime and dow fields from backup jobs in favor of schedule. A script that still reads the old fields needs a look before the job is the only copy of a VM.

One live migrate. A single node has one legal placement, so this row waits until node two is up and empty of customers. Migrate a Linux guest first. A Windows guest on host with VBS is the freeze case above, and it wants 11.0+pve2 before it is the guest you move between CPUs.

CPU type is the last row because it changes what the other four mean. host is what the install used for Ubuntu. A custom model, or x86-64-v2-AES, is what you want when the next node is a different generation and the guest has to keep running through the move. The same cloud-image note says AlmaLinux 10 wants x86-64-v3, so a template built for it needs that CPU type or host.

What pve8to9 will flag

An unset VirtIO MTU used to mean 1500. In VE 9 it inherits the bridge MTU. pve8to9 detects the vNICs that would change. Set MTU 1500 on those NICs before the upgrade if the guest stack was built for 1500.

Network interface names can change across the kernel jump from 6.8 to 6.14. When the old name remains available as an alternative name, VE 9 can keep using it in the network config and in firewall rules. A bridge pinned to a name that disappeared is a console job, so the --full run before you start is the cheap version of that discovery.

VM.Monitor leaves the privilege list. QEMU HMP monitor access uses Sys.Audit, and guest-agent commands use finer privileges. Custom roles that named VM.Monitor need an edit. The checklist detects them. Creating a privileged container now requires Sys.Modify. GlusterFS leaves the storage list, and the backup maxfiles setting leaves the job config. VE 9 boots cgroup v2. Containers on systemd 230 or older, the examples in the upgrade guide are CentOS 7 and Ubuntu 16.04, need a newer guest OS. The guide puts the remaining VE 8 window at an estimated end of life in July 2026, which is the window those containers have to move.

Custom OpenFabric or OSPF fabric config in /etc/frr/frr.conf.local stops working after the first SDN apply, because the SDN stack disables the daemons it now owns. The upgrade guide's repair is /etc/default/frr with ospfd=yes or fabricd=yes. Remove that file if you later switch to the built-in fabrics. Most one-node hosts keep a Linux bridge and leave the fabric page alone. WireGuard and BGP fabrics, BGP and EVPN route maps, and an IPv6 underlay for EVPN all arrived in 9.2. They are there when a cluster needs them. A single Linux bridge is enough for a one-node host.

ZFS on root with proxmox-boot-tool gained a memtest86+ boot entry in 9.2. On OVH, hosts installed through IPMI, outside the OVH template, can land in memtest because the boot path uses iPXE. The roadmap's fix is to set efiBootloaderPath to the loader efibootmgr -v shows, commonly \efi\proxmox\shimx64.efi or \efi\systemd\systemd-bootx64.efi. Systems that skip proxmox-boot-tool skip that entry. ext4 on LVM, which is what the install guest used, is in that second group.

The second node is the same sequence with one extra constraint: it joins a cluster that already has customers, so pve8to9 --full and the five checks happen while the first node is still the one serving them. The balancer stays a datacenter option you turn on after a Linux guest has migrated once and come back.