Proxmox VE 9.2 introduced dynamic load balancing through the Cluster Resource Scheduler, and out there it's been summed up as the cluster finally balancing itself. Proxmox never promised that: its own release notes say "HA-managed guests" twice, and the manual closes it off entirely — "Currently, these migrations are issued only for HA resources and executed sequentially". What isn't written in either place is what it costs to get a VM into that club, and that's where a watchdog and a node willing to reboot in sixty seconds show up.
We run Proxmox VE clusters with Ceph storage in production, spread across several datacenters. On the dynamic balancer we're not going to hand you a statistic about how many migrations it has saved us, because it would be made up. What follows is something else: exactly what the 9.2 documentation says, which values ship by default, and the criteria we use to decide whether to switch it on or leave it off in a given cluster.
Three modes, and the one you have is not the one for this
The CRS decides which node each HA resource lands on. It has three modes, configurable under Datacenter → Options → Cluster Resource Scheduling:
- 1
basic— counts how many active guests are on each node. Nothing else. It's the default. - 2
static— uses the CPU and memory quotas configured on active guests. What the VM config says, not what it actually burns. - 3
dynamic— adds the real average CPU and memory usage on top. This is the mode 9.2 introduced and the one that makes the balancer meaningful.
Here's the first misunderstanding: the automatic balancer does not switch itself on when you upgrade. It requires static or dynamic mode, plus its own switch, ha-auto-rebalance, which ships as 0. If you upgraded to 9.2 and touched nothing, you're still on basic with balancing off. The "Proxmox now balances your cluster" headline describes a capability, not something you will find already running.
The default arithmetic: 30%, three rounds, 10%
The balancer doesn't move anything the moment one node runs hotter than another. Three chained filters have to be cleared, and all three have numbers. Cluster imbalance is derived from the standard deviation and mean of node loads, normalised to a 0–100% range:
| Parameter | Default | What it decides |
|---|---|---|
ha-auto-rebalance | 0 | Off out of the box. |
ha-auto-rebalance-threshold | 30 | Imbalance in % you must exceed before the clock starts. |
ha-auto-rebalance-hold-duration | 3 | Consecutive rounds above the threshold. Each round lasts about 10 s. |
ha-auto-rebalance-margin | 10 | Minimum RELATIVE improvement, in %, for the chosen migration to be worth it. |
ha-auto-rebalance-method | bruteforce | How candidate migrations are scored. The alternative is topsis. |
auto-rebalance (per resource) | 1 | Every HA resource is in scope unless you opt it out. |
Translated: with factory values, the cluster must sit above 30% imbalance for roughly 30 consecutive seconds, and on top of that the migration the CRS picks must promise at least a 10% improvement. That is deliberate: a balancer that reacted to the first spike would be shuffling machines all night while backups run. The practical effect is worth saying out loud, because it's counter-intuitive: the balancer is built not to fix your short spikes. If your problem is one node pinning between 2 and 4 a.m., this is not the tool.
The reach: only what you declared
The documentation leaves no room for interpretation: rebalancing migrations "are issued only for HA resources and executed sequentially". Two things in one line. First, a VM that isn't an HA resource is invisible to the balancer no matter how hard it's eating the node. Second, migrations go one at a time: a badly skewed cluster doesn't get fixed in one breath, it gets fixed gradually. And the manual itself leaves the escape hatch open: "It is planned that load balancing will also include non-HA resources in the future". Planned. Not today.
There's a fine detail worth knowing before it surprises you: rebalancing migrations obey affinity rules, and if you disable auto-rebalance on one resource, any other resource with positive affinity towards it also drops out of the pool. It's coherent —if two machines must live together you can't move just one— but it means excluding one VM can silently exclude its whole group. If you've been wrestling with the 9.x affinity rules, we already wrote about how the cluster counts guests when it applies anti-affinity.
The price of admission: 60 seconds
This is where it stops being a conversation about performance. For the balancer to move a VM, that VM must be an HA resource. And Proxmox's HA stack rests on a watchdog: as long as a node has active HA services, its LRM keeps the watchdog open and keeps resetting it. When that node drops out of cluster quorum, the LRM waits for a new one to form and, until there is one, it cannot reset the watchdog. The documentation finishes the sentence bluntly: that "will trigger a reboot after the watchdog has timed out (this happens after 60 seconds)".
The flip side of that rule is in the same manual and almost nobody quotes it: "If no service is configured for more than 15 minutes, the CRM automatically returns to the idle state and closes the watchdog completely". In other words: a cluster with no HA resources declared eventually closes the watchdog and does not self-reboot. That node, facing a network cut, degrades and waits. Yours, the moment that node has active HA services, reboots. It's worth keeping the exact qualification, because it doesn't apply to every node equally: the manual warns that a node with an active CRM but an idle LRM does not trigger self-fencing, since the LRM only holds its watchdog while it has its agent lock. The clock runs on the node where the HA services are actually running, not across the whole cluster.
And now the conclusion that isn't written in any manual, because it's ours and it falls out of putting the two pieces together: the balancer's reach is smaller than its blast radius. It moves only the VMs you declared HA, but the reboot it brings along takes down everything on that node, declared or not. The HA VMs get recovered elsewhere; the ones you never declared come back when the node comes back. Put differently: switching balancing on signs you up to prefer an isolated node rebooting over it carrying on alone. There are clusters where that signature is obviously right and clusters where it isn't, but the signature goes in the resilience column and gets charged there, even though you sign it from the performance panel.
What it won't move even if you declare it
A rebalance is a migration, and a migration needs the destination to be able to run that VM. The manual lists the HA stack requirements plainly: at least three nodes, shared storage and hardware redundancy. And, for the HA Manager to treat every node as eligible, it asks that the guest:
- ✓uses options compatible with every node in the cluster;
- ✓uses only shared storage reachable from every node;
- ✓uses only network interfaces that exist on every node;
- ✓uses only device passthroughs present on every node.
Read that list with your real estate in mind and the problem shows up: the machine that actually skews your cluster is usually the one breaking at least one of those four points. The one with its disk on local storage because "it needs the IOPS". The one with a passthrough card. The one hanging off a bridge that exists on two of your five nodes. The manual gives those cases a way out, and it's worth not overstating the sentence: if a dependency only exists on a subset of nodes, you restrict the resource to that subset with a strict node affinity rule, and the HA Manager then limits placement, recovery and migration to those nodes. Which means that VM does get rebalanced, but only between the two nodes where it can live. The balancer spreads the set of machines that were already easy to move, and the boring work of getting shared storage right remains where the real win is. If Ceph is your case, it pays to be clear first about what a three-node cluster actually survives, and if you're coming from further back, why Proxmox HA doesn't prevent downtime, it shortens it.
The 9.2 feature that matters most to us isn't the balancer
The same release brought two CRM commands, disarm-ha and arm-ha, which disarm the HA stack cluster-wide. They exist for planned maintenance, such as touching the cluster network, "without triggering any node fencing events", and HA resource state is preserved through the window so everything returns to where it was. You invoke it picking a resource mode: ha-manager crm-command disarm-ha freeze or ignore, then arm-ha when you're done. We find it more useful than the balancing, because anyone who has had to swap a switch under a live HA cluster knows the countdown of "if this takes more than a minute, my nodes reboot".
With its fine print, which the manual flags as important: while the stack is disarmed "no automatic recovery, failover, or fencing takes place", and a node failure inside that window is neither detected nor handled by HA. So you open the window short, with a healthy cluster, and close it as soon as you're done.
When we wouldn't switch it on
Not out of distrust of the tool, but because in these cases it would not solve the problem actually in front of the client:
- —Three-node cluster running near capacity. If all three are tight, the headroom you need isn't the headroom that evens out the average: it's the headroom that absorbs losing a whole node. Rebalancing your way out of it optimises the good day at the cost of the bad one.
- —Corosync sharing a cable with something else. If the cluster network lives alongside replication or VM traffic, quorum drops stop being theoretical; and now every quorum drop has a 60-second clock next to it. Network first, balancing after.
- —When the uneven load has a name. If what skews the cluster is one specific, well-known VM, moving it once with your head beats building a system that moves it on its own every time it crosses the threshold. Automating a decision you make twice a year hides it rather than solving it.
Six questions before you flip the switch
Each answers with a yes, a no or a number. If you cannot answer one of them, that is this week's task, not the balancer:
- 1.How many VMs on this node are not HA resources? That's the collateral damage the day it reboots.
- 2.Does Corosync have its own network, separate from storage and VM traffic? Yes or no.
- 3.Of the VMs you're about to declare HA, how many have local disk, passthrough or a bridge missing on some node? Those won't move.
- 4.If a whole node goes down, do its VMs fit on the rest? If the answer is "just about", rebalancing will eat that margin.
- 5.Does your real imbalance exceed 30% for more than half a minute at a stretch, or are they ten-second spikes? Measure before, not after.
- 6.Is
disarm-hawritten into your network maintenance procedure, or are you trusting that nobody takes longer than a minute?
The 9.2 dynamic balancing is a good piece of work and does what it says. Our criterion for switching it on fits in one line: when the cluster network is where it should be and there is spare headroom to lose a whole node. And we leave it off, with no embarrassment whatsoever, when there isn't.
At everyWAN we design and operate infrastructure and cloud on Proxmox VE with distributed Ceph storage in production. We don't resell anyone's licences, so when we say a feature isn't for you, we're not turning down revenue by saying it.
Sources (verified on 2026-11-06): the Cluster Resource Scheduling, CRS Load Balancer, Requirements, Resources and Cluster Resource Manager sections (the latter being the source of the watchdog, 60-second and 15-minute quotes) of the Proxmox VE administration guide, version 9.2.13 (document last updated 24 Sep 2026) — pve-docs: HA Manager; default values for crs (the per-resource auto-rebalance default lives in the manual's Resources section, not here) — datacenter.cfg(5); Proxmox VE 9.2 highlights and date (21 May 2026), including dynamic balancing and disarm-ha/arm-ha — Proxmox VE Roadmap. The English quotes are taken verbatim from those pages. The reading about the reboot's blast radius is ours, not the documentation's, and follows from the watchdog acting on the node rather than on the resource.
About to declare half a dozen VMs as HA and not sure what changes on the node?
We review the cluster design, the Corosync network and the real headroom you have to lose a node. With your numbers, not a brochure's.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN