Proxmox VE 9.2: what changes before you upgrade a cluster

9.2 adds dynamic HA load balancing, disarm/arm HA, WireGuard and BGP SDN, and a 7.0 kernel. An upgrade order and probe for an existing cluster.

By the Maborak engineering team · 2026-10-29 · 3 min read

Proxmox VE 9.2 was released on 21 May 2026, with the first arm64 build following on 5 August. It is a point release on the 9.x line, based on Debian 13.5, with kernel 7.0, QEMU 11.0, LXC 7.0 and ZFS 2.4. The upgrade is routine only if the HA and network changes are planned before the packages move.

Checked 29 October 2026. Release contents and known issues are from the Proxmox VE roadmap and release history.

Background

Proxmox VE 9.0 moved the base to Debian 13 and added snapshots as volume chains. 9.2 continues that line and adds cluster scheduling and SDN features. It also documents upgrade defects, which is the part to read first.

Known issues listed for 9.2 include a transient upgrade problem with a disarmed HA stack, systems at OVH booting into memtest86+ under proxmox-boot-tool, Windows 11/2022/2025 VMs with host CPU and VBS intermittently freezing on Intel, and installer-kernel compatibility with some megaraid_sas RAID controllers.

Mechanics

Cluster Resource Scheduler. In dynamic mode, the scheduler uses live node and guest utilisation to rebalance HA-managed guests. It is an HA behaviour, so its effect appears during and after the upgrade rather than at install.
Disarm and arm HA. The disarm-ha and arm-ha CRM commands stop and resume HA actions cluster-wide while preserving resource state. This is the supported way to do cluster-network maintenance without triggering fencing.
SDN. WireGuard and BGP join the fabric protocols, with route maps and prefix lists for filtering. A fabric change is a network change; treat it as one.
Kernel 7.0 becomes the stable default. Check third-party modules (ZFS is in-tree here, but storage and GPU drivers may not be).

Impact

Upgrading a node restarts its guests unless they are migrated first. The release notes’ known issues are specific: an OVH host that reboots into memtest is an outage with a clear cause, and an Intel host whose Windows VMs freeze under VBS is harder to attribute after the fact. Read both lists before scheduling.

Probe

Run on every node before the first upgrade and keep the output:

pveversion -v
pvecm status
ha-manager status
cat /etc/pve/.members 2>/dev/null

Then confirm the cluster is healthy: quorum, all nodes online, no failed HA service. An upgrade started on a cluster without quorum turns a package problem into a fencing problem.

Mitigation

Read the 9.2 known issues and check the hardware: OVH boot method, Intel VBS guests, megaraid_sas controllers.
Back up /etc/pve and the guest configurations, and confirm a restore.
Evacuate a node, upgrade it, reboot, verify, then move to the next. Do not upgrade the whole cluster at once.
For a planned cluster-network change, disarm-ha first and arm-ha after, then confirm the HA state returned.
Keep the pre-upgrade package versions available for rollback. A Debian point release is not trivially reversible once guests have run on the new kernel.

Verification

pveversion -v
pvecm status
ha-manager status
pvesm status

Then migrate one guest each way, start a stopped guest, and take and remove a snapshot on a volume-chain storage. The version output proves the packages; the guest operations prove the cluster still works.

Sources

Proxmox VE roadmap and release history (checked 29 October 2026).
Proxmox VE 9.2 announcement.
Proxmox VE administration guide.

Topics: infrastructure

Back to all articles