If your community infrastructure runs on Proxmox VE 8.4, the clock is running out. Security updates for the 8.x line end this month — August 2026. That's not a future concern. It's a this-week concern.

The upgrade path from 8.4 to 9.x is supported, tested, and documented. The tool is pve8to9, a checklist program shipped in the latest 8.4 packages that scans your cluster for potential upgrade issues before you start. You run it, you read the warnings, you fix what it flags, you upgrade. The wiki page at pve.proxmox.com/wiki/Upgrade_from_8_to_9 walks through the full procedure.

But the question isn't whether to upgrade — it's what you're upgrading to. And 9.2, released May 21, 2026, is the first release in the 9.x line that justifies the move on operational merits alone. Not because of Arm64 support, which we covered two weeks ago. Because of what it does for the cluster you're already running.

Dynamic Load Balancing

This is the biggest cluster feature in Proxmox since CRS rules were introduced.

Until 9.2, the Cluster Resource Scheduler decided statically where a HA guest starts. If a node failed and its workloads migrated to survivors, they stayed there. After failover, you had to manually rebalance — move guests back to the recovered node, redistribute load across the cluster, restore the configuration you wanted. For a 3-node community cluster running a handful of LXCs and VMs, this meant logging in after every failover event and manually migrating guests back. Not catastrophic, but not nothing. It's the kind of task that gets deferred until someone notices a node at 90% CPU and another at 12%.

9.2 adds a Dynamic Load Balancer (DLB) to the CRS. It monitors real-time CPU and memory pressure per node and actively migrates HA guests when a node falls out of balance. Configurable hysteresis and cool-down prevent ping-ponging — a guest doesn't bounce back and forth because one node is momentarily 3% lighter than another. The thresholds are tunable.

For a community operator, this means: after a failover, the cluster self-heals. When the failed node comes back online, workloads migrate back without manual intervention. After a maintenance reboot, load redistributes automatically. You stop doing capacity planning as a manual task and start letting the scheduler handle it. This is the feature that closes the last operational gap between Proxmox and commercial hypervisors with DRS. It's built in, it's free, and it works on the 3-node cluster you already have.

WireGuard as an SDN Fabric

Proxmox's Software-Defined Networking has supported OSPF and BGP as fabric protocols for inter-node connectivity. 9.2 adds WireGuard.

This sounds like a networking feature. It's actually a community infrastructure feature.

The use case: a multi-site cluster. Two fire halls, a community center, and a town office, each running a Proxmox node, clustered together. Previously, connecting these nodes securely across untrusted networks — the internet, a shared WAN, a municipal fiber ring you don't fully control — required a VPN overlay. You'd run WireGuard or IPSec manually, manage keys, configure routes, and then build the Proxmox SDN on top. Two layers to operate, two layers to break.

With WireGuard as a native SDN fabric protocol, key management is automated across cluster nodes. The encrypted tunnels between nodes are provisioned by the SDN layer itself. BGP and EVPN run transparently on top. You get encrypted node-to-node connectivity as part of the SDN configuration, not as a separate overlay to maintain.

For community networks without L2 connectivity between sites — which is most of them — this makes multi-site Proxmox clusters practical without a dedicated network backbone. The fabric encrypts itself. The routing configures itself. The operator manages one layer instead of two.

HA Disarm for Planned Maintenance

Two new CRM commands: ha-manager arm-ha and ha-manager disarm-ha.

The problem this solves: planned maintenance on an HA node used to risk unwanted fencing. You'd stop the HA service to avoid it, which meant the node's guests had no HA protection during the window. Or you'd gamble on the HA stack not triggering during a controlled reboot. Neither option was good.

Disarm mode is the middle path. The HA stack keeps running — it detects temporary node outages — but it won't fence. You can apply firmware patches, reconfigure networking, reboot a node, and the HA stack watches without acting. When maintenance is done, you re-arm.

For a community operator doing rolling upgrades or network rework on a 3-node cluster, this removes the tension between "I need to do maintenance" and "if the HA stack fences this node, I'm in trouble." It's a small feature with outsized operational impact.

One caveat: a disarmed node must be re-armed before a cluster upgrade, or HA resource migration must be complete. Otherwise the HA manager can stall. Fixed in 5.2.4+, but worth knowing.

LXC 7.0 — The Container Jump That Matters

LXC 7.0 is the reason for the version bump, and it's the most significant container update in years.

OCI image support. Both system and application containers can now use OCI images. For operators who've been building custom container images, this means you can pull and run standard OCI images directly in LXC — the same format Docker uses, the same format Kubernetes consumes. No more translating between image formats. Your container registry serves LXC and Docker from the same images.

Per-mountpoint UID/GID mapping. The idmap option lets you map user IDs per mountpoint — the clean way to share volumes between containers with different user mappings. Previously, sharing a storage volume between two LXCs with different UID schemes required workarounds or matching UIDs. Now it's a mount option.

Per-mountpoint attribute inheritance. The keepattrs option controls attribute inheritance per mountpoint. Fine-grained control over what gets preserved when you mount a volume.

AF_ALG seccomp filtering. This closes a known privilege escalation class in unprivileged containers (PSA-2026-00018-1). Security fix, not a feature, but important.

cgroup v1 deprecation warnings. The final step before cgroup v1 support is removed. If you're maintaining old LXC configurations with raw cgroup v1 entries, migrate now. One of the next releases drops support entirely.

For community operators running application stacks in LXC — Nextcloud, Matrix, Keycloak, Postgres — OCI image support is the change that simplifies deployment workflows. You stop building LXC-specific templates and start using the same images your Docker-using colleagues already publish. The container format convergence is real, and LXC is now part of it.

Ceph Tentacle 20.2

Fresh clusters default to Ceph Tentacle 20.2.1. Squid 19.2.3 remains available for existing clusters and continues receiving security patches.

Tentacle brings improved RGW (RADOS Gateway) performance, more stable OSD recovery in large clusters, and consolidated telemetry. For existing clusters, the guidance is conservative: Squid stays the safe default for upgrades. Tentacle migration only on fresh pools or after thorough testing. Don't migrate a production cluster's storage backend on the same day you upgrade the hypervisor.

9.2 also fixes several Ceph-specific GUI bugs — pool edit dialog replication size, incorrectly assigned monitor log owners on fresh clusters, and more robust OSD creation when auth_client_required is missing from ceph.conf. Small fixes, but the kind that cause real confusion when you hit them.

Kernel 7.0 and the Security Patches

The jump to Linux Kernel 7.0 brings refreshed drivers, MBEC and GMET support for hardware virtualization branch targets, Spectre and VMScape hardening, and reworked AppArmor paths. Bigger than the 6.17 step in 9.1.

9.2 also addresses several serious security findings:

  • PSA-2026-00014-1: VNC session hijacking and password guessing. VNC API clients may need adjustments — this is a breaking change.
  • PSA-2026-00015-1: HA resource creation now requires Sys.Console privilege.
  • PSA-2026-00018-1: AF_ALG socket privilege escalation in containers.
  • Cloud-init password dump now requires VM.Config.Cloudinit.
  • VM start after create/restore now requires VM.PowerMgmt.

Plus kernel CVE backports and patches for Crackarmor, copy.fail, DirtyFrag, Fragnesia, ssh-keysign-pwn, and pintheft. The kind of patch list that reminds you why running a supported version matters.

The Upgrade

From 9.1 → 9.2: apt update && apt full-upgrade. Standard. Web GUI update works too.

From 8.4 → 9.2: Move to 8.4 with all current updates applied. Run pve8to9 and address its warnings. Then upgrade to 9.x. Direct jump from 8.4 to 9.2 is supported.

The overlap period between 8.4 updates and 9.x is roughly one year, ending August 2026. That's now. If you haven't started the upgrade, this is the month to plan it.

What This Means for Community Operators

Most readers of this site run Proxmox on a few nodes — a fire hall, a community center, a town office. Three-node clusters, local storage or a small Ceph pool, a handful of LXCs running the services the community depends on. You're not running vSphere. You don't have a DRS license. You don't have a dedicated network team to manage VPN overlays between sites.

9.2 is the release where Proxmox's feature set caught up to what community operators actually need:

  • The cluster rebalances itself after failover. You stop manually migrating guests back after every HA event. The DLB does it, with thresholds you control.
  • Multi-site clustering works without a network engineer. WireGuard SDN fabric means encrypted inter-node tunnels are part of the SDN config. No separate VPN layer.
  • Planned maintenance doesn't risk fencing. Disarm, patch, re-arm. The HA stack watches without acting.
  • Containers use standard images. OCI support means LXC and Docker share the same image format. Your deployment pipeline gets simpler.
  • The kernel and userspace are current. Kernel 7.0, LXC 7.0, QEMU 11.0, Ceph Tentacle. The base layers are on recent releases, which means the security patches land cleanly.

If you're on 8.4, the upgrade is overdue — not because 8.4 is broken, but because the security update window closes this month. If you're on 9.0 or 9.1, the 9.2 upgrade is a routine apt full-upgrade with real feature upside.

Proxmox is AGPLv3. The code is public. The patches are public. No one decides you're not allowed to upgrade. The upgrade path is documented, tested, and supported by the community. For the communities we work with: run pve8to9, read the output, and plan the move. The features you get on the other side are worth the Saturday morning.

Sources: Proxmox VE 9.2 release — DATAZONE overview, Proxmox VE upgrade from 8 to 9 — wiki, Proxmox VE features, Proxmox downloads