Last weekend was raining, which meant perfect opportunity to spend some time in the lab and upgrade my Proxmox environment to the newly released 9.2. This version introduces some neat features that I’m sure you’ll all be excited about.
We’re talking features that will make cluster management easier, custom CPU model management and native WireGuard and BGP support backed right into SDN (Software Defined Network)
Dynamic Load Balacing – Cluster Resource Scheduler (CRS)
The Cluster Resource Scheduler (CRS) has been part of Proxmox for a while, but up until now it only did static placement. When a VM started, CRS would look at your nodes, pick the one with the most headroom, and that was it. If workloads shifted and one node ended up doing all the heavy lifting an hour later, CRS wasn’t going to do anything about it.
Version 9.2 changes that with a new Dynamic Load scheduling mode. Instead of a one-time decision at startup, CRS now continuously monitors real-time resource utilisation across your nodes and guests. When it detects that things have become unbalanced beyond a threshold you configure, it will automatically live-migrate HA-managed guests to level the load across the cluster.
You get a set of tuning controls to dial in the behaviour for your environment:
- Rebalance on Start – A lighter touch option. CRS will select the least-loaded node when an HA resource first starts, but won’t continue migrating things after that. Good starting point if you’re not ready for fully automatic rebalancing.
- Automatic Rebalance – Enables the ongoing live migration behaviour. CRS will act whenever node imbalance exceeds your configured threshold.
- Imbalance Threshold – How uneven things need to get before CRS acts. The default is 35%. If your workloads are naturally spiky, you’ll want to nudge this higher to avoid unnecessary migrations.
- Hold Duration – The minimum time between rebalance cycles. This prevents CRS from migrating the same guests back and forth in environments with fast-changing workload patterns.
- Minimum Imbalance Improvement – CRS will only perform a rebalance if doing so will improve the situation by at least this percentage. Stops it from making migrations that barely move the needle.
One important thing to understand: dynamic rebalancing only applies to guests that are managed by the HA stack. Non-HA VMs won’t be touched regardless of how loaded a node gets. CRS also respects all your existing HA rules, affinity configurations, and resource restrictions — it won’t violate constraints to achieve balance.
Cluster-wide HA Arm and Disarm
Anyone who has done node maintenance on a Proxmox cluster will have had this experience at least once. You’re doing a planned drain and reboot of a node, and the HA Manager decides your controlled action is actually a failure event. Next thing you know it’s fencing the node and migrating VMs everywhere before you can intervene.
Proxmox 9.2 finally gives us a proper fix for this. There are now dedicated Arm HA and Disarm HA buttons right at the top of the HA status page. Hitting Disarm HA puts the HA Manager into a cluster-wide standby mode. It will not fence nodes, it will not trigger failovers, and it will not try to restart any guests it thinks have gone offline. Your maintenance window proceeds without interference. When you’re done, hit Arm HA and normal HA operation resumes.
After disarming, you’ll notice the fencing row in the cluster status changes to “standby (CRM watchdog standby)” — that’s your visual confirmation that the watchdog is suspended and the cluster won’t take any automated action.
This might sound like a small addition, but it closes a frustrating gap. Previously your options were to set each individual HA resource to “ignored” one by one (tedious and easy to miss something), or just accept that HA might act unexpectedly and have a recovery plan ready. A single cluster-wide toggle is the right answer and it works exactly as you’d expect.
Don’t leave the cluster running in a disarmed state any longer than necessary. It’s a maintenance mode, not a permanent configuration.
Custom CPU Models – Now Manageable From the Web UI
Custom CPU type definitions have been technically possible in Proxmox for years, but creating and managing them meant manually editing config files on disk, not something you’d want to do routinely or hand off to someone else on the team.
In 9.2, there’s now a dedicated ‘Custom CPU Models’ section in the Datacenter left nav, with proper Add, Edit, and Remove controls. You can create a custom CPU profile, give it a name, select a base model to build from, and fine-tune the CPU flags — all from the web UI.
The standout part of the new dialog is the CPU flag table. It shows every flag available in your cluster with four key columns:
- State – Whether the flag is enabled, disabled, or set to default
- Flag – The flag name (e.g. aes, nested-virt, amd-ssbd)
- Description – A plain-language explanation of what the flag does
- Supported On – Which nodes in your cluster actually expose this flag
That last column is the one that makes this genuinely useful. If you’re running a mixed-hardware cluster — say, newer nodes alongside an older box, you can see at a glance which flags are available everywhere versus which ones only exist on some nodes. Assigning a CPU flag to a VM that the destination node doesn’t support means that VM can’t live-migrate there. The “Supported On” column lets you make that call with full information rather than finding out the hard way at 2am.
There’s also a checkbox at the bottom of the dialog, “Only show flags supported by at least one node”, that filters the list down to flags that are actually relevant to your hardware. Tick that first and the table becomes much easier to work with.
SDN Fabrics – WireGuard, BGP, and OSPF Built Right In
The SDN subsystem in Proxmox has been gaining capability steadily over recent releases, and 9.2 adds something new to the SDN section – Fabrics. You’ll spot it in the left nav under SDN alongside Zones, VNets, and the rest.
A Fabric in Proxmox terms defines the underlay network, the physical or tunnelled connectivity layer that your SDN Zones and VNets sit on top of. Prior to 9.2, options like WireGuard tunnels and BGP routing were achievable on a Proxmox cluster, but they required external tooling, FRR configurations, custom systemd units, manual WireGuard peer management, none of which Proxmox managed or had visibility of.
In 9.2, all of that moves into the Proxmox web UI. Click Add Fabric and you’ll see four options:
- OpenFabric – IS-IS based routing, designed for large-scale flat Layer 3 network architectures
- OSPF – Classic dynamic IGP routing, with support for route redistribution into EVPN fabrics
- WireGuard – Native encrypted tunnel underlay between cluster nodes, no external daemon required
- BGP – eBGP and iBGP with full EVPN support, including IPv6 underlay
Also new in the SDN left nav: Route Maps and Prefix Lists. These support BGP/EVPN policy filtering, controlling which routes get advertised or accepted, without needing to drop into the FRR CLI.
The WireGuard fabric support is worth highlighting for anyone running multi-site setups or clusters across untrusted network segments. Being able to define your encrypted inter-node tunnels inside Proxmox, have them managed as part of the cluster config, and not need a separate peer management system is a real simplification.
If you’re new to Proxmox SDN, it’s worth spending some time with the documentation before enabling fabrics in a production environment. The SDN subsystem is powerful but it does have some depth to it, and the fabric layer adds another dimension to manage.
Platform Stack Updates
Alongside the feature additions, 9.2 brings the following platform component updates:
- OS: Debian 13.5 “Trixie”
- Kernel: Linux 7.0 (new stable default)
- QEMU: 11.0
- LXC: 7.0
- ZFS: 2.4
- Ceph Squid: 19.2.3 (existing stable option)
- Ceph Tentacle: 20.2.1 (now available as a stable option)
A couple of things worth being aware of before you upgrade. QEMU 11.0 removes support for some older machine types. If you have VMs that have been running since Proxmox 6.x or 7.x without ever having their machine type updated, it’s worth checking those before you pull the trigger on the upgrade. You can review the machine type in each VM’s Hardware settings.
On the Ceph side, Tentacle 20.2 is now available as a stable release alongside Squid 19.2. You can select which Ceph version to deploy or upgrade to directly from the Proxmox Ceph management UI no manual repo additions needed.
Should You Upgrade?
My philosophy for upgrades is let someone else do the testing first, give it some time to mature, then upgrade. However for LAB environments, the sooner the better, start getting familiar with the new options. The HA arm/disarm controls alone are worth the upgrade for anyone who’s had the HA Manager interfere with a planned maintenance window. The dynamic load balancer is a meaningful operational improvement for environments where workload placement impacts performance, and the Custom CPU Models UI finally makes that workflow something you can manage properly without editing files by hand.
The SDN fabric additions are more niche but significant for anyone building multi-site setups or moving toward more complex network virtualisation.
Kernel 7.0 is the main reason to be a little deliberate about timing. It’s not a reason to hold off indefinitely, the upgrade path from 9.x is clean, but testing on non-critical hardware before touching production clusters is always good practice with a kernel bump of this size. Check your hardware support and any out-of-tree kernel modules before committing.
Be the first to comment