Does the Dynamic Load Balancer move non-HA VMs and containers?

No. Only HA-managed guests are ever migrated. A plain VM or LXC that is not registered as an HA resource is never touched, even if it is the workload pinning a node at 100 percent CPU. Keeping a guest out of HA is the supported way to exclude it from the balancer.

Is this the same as VMware vSphere DRS?

Functionally, yes. It is the Cluster Resource Scheduler running in dynamic mode, using real-time CPU and memory utilization to live-migrate guests and keep node load even, while respecting your HA, affinity, and anti-affinity rules.

What are safe threshold and hold-duration values?

Start with the defaults: a 30 percent imbalance threshold, a 3-round hold of about 30 seconds, and a 10 percent margin. If guests flap between nodes, raise the hold duration to 6 rounds first, then nudge the threshold and margin up before changing anything else.

Do I need to restart any services after changing the settings?

No. datacenter.cfg lives on the pmxcfs cluster filesystem, so saving it replicates to every node instantly. The CRM master picks up the new values on its next round, roughly 10 seconds later, with no restart.

How long does a rebalancing migration take?

It is a normal live migration. An approximately 8 GB guest over a 10 GbE network takes roughly 20 to 40 seconds, plus a brief stun at cut-over. That cost is why you want conservative thresholds rather than chasing every small imbalance.

Proxmox VE 9.2 Dynamic Load Balancer for HA Clusters

Proxmox VE 9.2 ships a Dynamic Load Balancer that continuously watches real-time CPU and memory pressure across every node and live-migrates HA-managed guests off the busiest hosts automatically. Flip one toggle and your cluster keeps its own utilization even, shifting workloads before a single node starts thrashing while another sits half idle, with no cron jobs and no manual qm migrate. Below is exactly what it does, the datacenter.cfg knobs that steer it, and the handful of places it will bite you if you tune it carelessly.

Key Takeaways

Dynamic CRS: The Dynamic Load Balancer is Proxmox's Cluster Resource Scheduler running in a new dynamic mode, directly comparable to VMware vSphere DRS.
HA only: Only HA-managed guests are ever migrated; plain VMs and LXC containers are never touched, no matter how hot a node gets.
Six knobs: Everything lives on the crs: line in datacenter.cfg, with conservative defaults (threshold 30%, hold 3 rounds, margin 10%).
No restart: Settings replicate through pmxcfs instantly and the CRM master applies them on its next ~10-second round.
Tune for calm: Raise the threshold, margin, and hold duration to stop guests flapping between nodes over trivial imbalance.

What is the Proxmox VE 9.2 Dynamic Load Balancer?

Proxmox VE 9.2 landed on 2026-05-21 on top of Debian 13.5 "Trixie", Linux kernel 7.0, QEMU 11.0, LXC 7.0, and ZFS 2.4, and the headline feature is the Dynamic Load Balancer. Under the hood it is not a new daemon; it is the existing Cluster Resource Scheduler (CRS) running in a new dynamic mode. Instead of only scoring node placement when a guest starts or fails over, it now samples real-time per-node CPU and memory utilization on an ongoing basis and acts on it.

When the balancer sees the cluster drift out of balance, it live-migrates HA-managed guests to quieter nodes to reduce overall imbalance. Imbalance here is a cluster-wide measure of how unevenly CPU and memory are spread across nodes, expressed as a percentage, where 0% would be a perfectly even distribution. Crucially, it does this while strictly respecting every user-defined HA rule, affinity and anti-affinity rule, and resource restriction you have configured; it will never break a placement constraint just to even out load. If you have run VMware vSphere DRS, the mental model is identical: the scheduler keeps hosts evenly loaded on its own.

The feature first landed in pve-ha-manager 5.2.0 / pve-manager 9.1.8 back in April 2026, and 9.2 promotes it to a headline capability. If you are still cataloguing what changed across the major release, it sits alongside the other items worth turning on in Proxmox VE 9: New Features Every Admin Should Enable.

The one limitation that catches everyone

Read this twice: only HA-managed guests are ever migrated. A plain VM or LXC that is not registered as an HA resource is invisible to the balancer and will never be moved, even if it is the exact workload pinning a node at 100% CPU. This is deliberate, and it is also the single most useful lever you have. Anything you never want auto-migrated (a GPU-passthrough VM, a latency-sensitive database, a guest bound to host-specific hardware) simply stays out of HA. If you are still building out failover, get Proxmox High Availability Setup for Automatic VM Failover solid first, then add the balancer on top.

Static CRS vs dynamic CRS: what actually changed?

The older CRS was a placement scheduler: it decided where a guest should land when it started or failed over, then left it alone. Dynamic mode adds a continuous feedback loop on top of that. Here is the contrast:

Aspect	Static CRS	Dynamic Load Balancer (dynamic CRS)
When it acts	Only at guest start / HA failover	Continuously, every HA Manager round (~10s)
Trigger	A scheduling event	Live node imbalance above a threshold
Data used	Static resource counts from config	Real-time per-node CPU + memory utilization
Guests affected	HA-managed only	HA-managed only
Live migrations	None on its own	Automatic, one at a time
Config key	`crs: ha=static`	`crs: ha=...,ha-auto-rebalance=1`

Note the last two rows: dynamic mode does not replace your placement scheduler choice. The ha=basic or ha=static setting still selects how placement is scored; the ha-auto-rebalance* options layer automatic rebalancing on top of it.

How to enable the balancer in the GUI

The click-path is short. In the web UI, open Datacenter -> Options, find the CRS / HA settings, and enable the toggle labelled Automatically rebalance HA resources. That single switch sets ha-auto-rebalance=1 for you; the remaining knobs keep their defaults until you decide to tune them. The HA panel exposes the same settings if you prefer to configure it there.

If you have not built the cluster yet, the balancer needs a working, quorate cluster underneath it. Walk through Setting Up Your First Proxmox VE Cluster Post-Install Guide first, because a single-node cluster has nothing to balance against.

Tuning datacenter.cfg: the crs: options that matter

Everything the GUI toggles is stored on one line in /etc/pve/datacenter.cfg. A complete, correct line looks like this:

crs: ha=basic,ha-auto-rebalance=1,ha-auto-rebalance-threshold=30,ha-auto-rebalance-hold-duration=3,ha-auto-rebalance-margin=10,ha-auto-rebalance-method=topsis

Each key does exactly one thing:

ha-auto-rebalance — boolean 0/1. Enables automatic CRS balancing of HA resources based on current node imbalance. This is the master switch.
ha-auto-rebalance-threshold — the cluster node imbalance, in percent, that must be exceeded before rebalancing is considered. Default 30.
ha-auto-rebalance-hold-duration — the number of HA Manager rounds the imbalance must stay above the threshold before a migration fires. Default 3. Each round is roughly 10 seconds, so the default hold is about 30 seconds of sustained imbalance.
ha-auto-rebalance-margin — the minimum relative improvement in cluster imbalance, in percent, that a candidate migration must deliver before it is committed. Default 10. This stops the balancer from making moves that barely help.
ha-auto-rebalance-method — the scoring method for candidate migrations. Valid values are exactly bruteforce or topsis. bruteforce scores candidate moves exhaustively; topsis ranks them with a multi-criteria model. Pick one, watch the decisions it makes, and switch only if you disagree with them.

The mechanism, put plainly: on every HA Manager round (~10s) the balancer checks whether current cluster imbalance exceeds ha-auto-rebalance-threshold. If it stays above that line for at least ha-auto-rebalance-hold-duration consecutive rounds, the balancer selects the single migration that most reduces overall imbalance, provided that move clears the ha-auto-rebalance-margin. One move per decision, re-evaluated on the next round.

Because datacenter.cfg lives on the pmxcfs cluster filesystem, saving it replicates the change to every node instantly with no service restart. The CRM master simply reads the new values on its next round and starts applying them. You do not have to edit the file by hand either; the same settings apply from the CLI:

pvesh set /cluster/options --crs "ha=basic,ha-auto-rebalance=1,ha-auto-rebalance-threshold=30,ha-auto-rebalance-hold-duration=3"

Safe starting values for most homelab and small production clusters: leave the threshold at 30 and the margin at 10, and if you see any flapping, push the hold duration from 3 rounds to 6 (about 60 seconds) before touching anything else. Lengthening the hold is the least disruptive knob because it only delays action; it does not change which moves are eligible.

One more distinction worth nailing down: the older ha-rebalance-on-start option is a different thing entirely. It only rebalances a guest at the moment its HA service starts. It is not the continuous dynamic balancer, so do not reach for it expecting ongoing rebalancing.

How do you verify the balancer is actually working?

Do not assume, watch it. The CRM master logs every rebalance decision, so tail its journal:

journalctl -u pve-ha-crm -f

Then confirm overall HA state and see which node currently holds the CRM master role:

ha-manager status

When the balancer decides to move something, it queues a normal live-migration task, so the actual VM motion shows up in the cluster task log in the GUI just like a manual migration would. Between the CRM journal, ha-manager status, and the task log you can trace the full chain: imbalance detected, hold satisfied, migration chosen, live migration executed.

The tradeoffs and gotchas worth knowing up front

The default 30% threshold, 3-round hold, and 10% margin are deliberately conservative, and you generally want them that way. The failure mode when you make the balancer too eager is flapping: a guest ping-pongs between two nodes every time load wobbles across the threshold. Raising the threshold and margin, and lengthening the hold duration, will damp that out, because you are telling the balancer to act only on real, sustained imbalance rather than noise.

Migrations are not free. A live migration of an ~8 GB guest over a 10 GbE network will take roughly 20-40 seconds and consume real bandwidth plus a brief stun at cut-over. Multiply that by an over-eager balancer and you are paying migration cost to chase a few percent of imbalance that would have evened out on its own. That is the honest tradeoff: tighter balance versus migration churn. If your rebalancing traffic shares a link with guest or storage I/O, a burst of moves will contend with production traffic, so a dedicated migration network keeps that isolated. For a refresher on how live migration behaves in a cluster, Proxmox Clustering: Setup, Quorum, and Live Migration covers the moving parts.

Finally, the practical rule that saves the most grief: keep latency-sensitive and GPU-passthrough guests out of HA. Because the balancer only ever touches HA-managed resources, leaving those workloads unmanaged guarantees the scheduler will never live-migrate them out from under a real-time process or a PCI passthrough device. Put your stateless, migration-friendly web and app tiers under HA, let the balancer keep them level, and pin the fragile stuff in place by keeping it non-HA.

Conclusion

The Proxmox VE 9.2 Dynamic Load Balancer turns CRS into a continuous, DRS-style scheduler that keeps your cluster's CPU and memory load even by live-migrating HA-managed guests off hot nodes, respecting every HA and affinity rule you have set. Enable it with the Automatically rebalance HA resources toggle, then tune ha-auto-rebalance-threshold, -hold-duration, and -margin in datacenter.cfg to match how aggressively you want it to act. Start with the defaults, watch journalctl -u pve-ha-crm -f for a few days, and keep anything latency-sensitive out of HA so the balancer only moves what is safe to move.