Set Up the Proxmox VE 9.2 Load Balancer for Smarter VM Placement

Proxmox VE 9.2 can move your HA-managed VMs and containers between nodes on its own. It watches real CPU and memory use. If a node is overloaded, Proxmox moves a VM to a free node, and the VM keeps running.  This guide shows the full Proxmox dynamic load balancer setup.

The balancer is not a new service. It is the Cluster Resource Scheduler (CRS) running in a new dynamic mode. In this mode, the CRS uses real-time node and guest usage data when making decisions.

1. Every HA round, about 10 seconds, the cluster checks how unbalanced the nodes are.
2. If the imbalance stays above a limit for a set number of rounds, the balancer picks the one migration that helps the most.
3. It only makes the move if the gain is big enough.
4. It moves guests one at a time.

Three rules matter before you start:

• HA guests only. Only guests managed by HA are moved. A normal VM that is not in HA is never touched.
• Rules always win. Migrations always follow your HA affinity rules.
• Dynamic or static mode is required. The balancer does not work in basic mode.

The balancer sits on top of HA, so you need a working HA cluster first.

Check this list before you start Proxmox dynamic load balancer setup. Missing one item is the most common reason a test fails.

• A Proxmox VE cluster with at least 3 nodes. HA needs three nodes for a reliable quorum.
• Shared storage for the guests, such as Ceph or NFS. HA guests must be able to run on any node.
• Matching network bridge names on all nodes, so a guest can start anywhere.
• A fast and separate network for migration traffic. This is best practice, not a hard rule.

If you do not have a cluster yet, you can check this guide on how to build a Proxmox HA cluster with Corosync and quorum.

In this guide, the nodes are pve1, pve2, and pve3. Change the names to match yours.

You must make sure every node runs Proxmox 9.2, the same version, and the cluster is healthy. On every node, run this:

You should see pve-manager/9.2.x. If not, update the node:

Then, check the cluster and HA state from any node with the commands below:

You must see Quorate: Yes and quorum OK. Do not proceed until both look fine.

In this step, you must make a small VM template and clone it. These clones give you something to move around later. Replace shared-storage with your own storage name. Run these commands on pve1:

• qm create makes an empty VM with 2 cores and 2 GB RAM.
• import-from loads the Debian disk into your shared storage.
• The cloud-init drive sets the user, password, and DHCP network.
• qm template turns the VM into a template.

Now make six full clones with the following command:

Remember to do not start them yet.

The balancer only sees HA guests. So here you should put all six clones under HA control with the command below:

Use the commands below to check the results:

HA will start the guests. It takes a few seconds because the HA stack works in the background. Each HA resource also has an auto-rebalance option, which is on by default. It decides if the balancer may move that guest.

At this point, you can turn on dynamic mode only and keep auto-rebalance off. This lets you build an unbalanced cluster manually before the balancer reacts.

The cluster file is /etc/pve/datacenter.cfg. It is shared on all nodes, so you edit it once. Open the file with your desired text editor:

Add this single line or edit the existing crs: line:

Save the file. You can also set it from the command line:

This command replaces the whole crs value. If you already use ha-rebalance-on-start=1, add it to the string again.

• ha=dynamic makes the scheduler use real CPU and memory usage. 
• ha-auto-rebalance=0 keeps the balancer off. This is the default.

Verify the saved value with the command below:

Now you can make the cluster unbalanced on purpose. With the balancer off, nothing moves the guests back, so you get a clear before picture. To do this, move all six guests to pve1:

This is a live migration. Wait a minute, then check:

All six service vm:20x lines should show pve1.

Idle VMs look balanced even when they are not, so you must run a stress tool inside each VM. Log in to each VM and run:

This keeps 2 CPU workers and about 70% of the VM's memory busy for 40 minutes. Do it in all six VMs.

This part shows you the numbers the balancer sees. Install jq on the node you work from:

Check CPU and memory per node, refreshed every 5 seconds:

Then, check the load per guest with the command below:

Also, you can check the same numbers in the web UI under Datacenter > Summary, or on each node's page. You should see pve1 very busy, and pve2 and pve3 almost idle. Save this as your before screenshot.

At this point, you must turn the balancer on and set how sensitive it is. The values below are for the lab, so you see results fast. They are not for production. A careful Proxmox dynamic load balancer setup always starts with a short test like this.

If you prefer the GUI method, follow the steps below:

• Open Datacenter > Options.
• Edit Cluster Resource Scheduling.
• Set the scheduling mode to Dynamic Load.
• Enable the automatic rebalance option.
• Set the threshold, hold duration, margin, and method, then click OK.

Label names may differ a little between builds. The CLI option below is the safest way.

Use this if you want exact and repeatable settings:

Or you can edit the file manually with the command below:

This table is a quick guide to every setting:

A round is about 10 seconds. So a hold duration of 3 means about 30 seconds. Your change is copied to all nodes by itself. You do not need to restart anything. The HA manager uses the new values in its next round.

Now you can check the balancer work by watching the logs and the HA state while it fixes the imbalance.

Open two terminals on any node. In terminal 1, watch the HA manager decisions:

In terminal 2, watch the HA state with:

Look for log lines about balancing and migration. The exact wording can change between versions.

What you should see within a few minutes:

• Imbalance is above 15% for 2 rounds.
• The balancer picks one guest and starts a live migration. The service state shows migrate.
• After it finishes, check the node load again. The load on pve1 falls.
• If the imbalance is still above the limit, the next round moves another guest.

You can check the tasks in the web UI under Datacenter > Tasks. Automatic moves show up like manual ones. Then, run the node view from Step 4 again. The six guests should now be spread across the three nodes.

Some guests should never move on their own. Here you can block one guest from automatic moves:

The guest stays HA-protected for failover, but the balancer will not move it. Repeat Step 4 and confirm vm:206 stays put. To turn it back on:

Rules tell the cluster where guests may or may not run. The balancer never breaks them. Rules live in /etc/pve/ha/rules.cfg, and you can create them with ha-manager rules.

Keep two guests on different nodes, which is good for a web pair:

Keep two guests on the same node, which is good for an app and its database:

Limit a guest to certain nodes only:

With --strict 1, the guest must stay on the listed nodes. Without it, the rule is only a preference. Check your rules with:

Rules that conflict are disabled until you fix them. For example, one guest cannot be in two node affinity rules.

Now run the load test again. VMs 201 and 202 should end up on different nodes. VMs 203 and 204 should stay on the same node, although the load may not be shared equally. This shows that your rules are more important than balance.

The lab values from Step 5 are fast, so VMs may usually move too. In this step, you can change the settings to calmer values for real work. You change one value at a time and watch what happens.

• Guests move too often? Raise the hold duration, for example, to 6.
• Still moving for small gains? Raise the margin, for example, to 15 or 20.
• Cluster stays uneven too long? Lower the threshold, for example, to 20.

Here is a calm production example:

Sometimes a VM keeps moving from one node to another again and again. Each move copies the VM's memory over the network, so too many moves waste bandwidth. Change your settings slowly to keep your Proxmox dynamic load balancer setup stable.

Also, you can set a migration network and limit parallel jobs. Both options go in /etc/pve/datacenter.cfg. Replace the subnet with your own migration network:

Use type=insecure only on a fully private network. A lower max_workers helps slow networks.

Sometimes you need to work on a node or on the whole cluster. This can conflict with the balancer, because it may try to move VMs while you work. In this section, you learn how to do maintenance safely and what to check first.

Use this when you only work on one node, for example, a firmware update. Put the node in HA maintenance mode:

HA moves its guests to other nodes. When you finish, run:

Then, run this check on your own cluster:

• Enable maintenance on pve3 and wait until it is empty.
• Watch journalctl -u pve-ha-crm -f and the node view. Confirm the balancer does not send guests back to pve3 while it is in maintenance.
• Disable maintenance. Watch how guests spread again.

Use this for work like network changes. The disarm-ha command turns off the HA watchdogs on all nodes. This stops the nodes from restarting by themselves while you work.

Proxmox VE 9.2 has two modes, including freeze and ignore:

Finish your work, then turn HA back on:

Do not leave HA turned off. While it is off, the cluster cannot move VMs from a failed node to a working one.

If you move a guest manually with ha-manager migrate, the balancer may move it again later. To keep it in place, set --auto-rebalance 0 on that guest, or use a strict node affinity rule.

Plan this before maintenance, so your proxmox dynamic load balancer setup does not conflict with your manual work.

Auto rebalancing is not right for every cluster. In some cases, it can cause problems or do nothing. This section shows when you should wait or keep some VMs out of it.

• Fewer than three nodes. HA needs three nodes for good quorum, and the balancer needs HA.
• No shared storage. HA guests must be able to run on any node.
• GPU or PCI passthrough guests. They are connected to one node's hardware. Keep them out of HA, or set them with a strict node affinity rule.
• Latency-sensitive guests. A live migration causes a short pause at the end.
• Weak migration network. Slow links make each move costly.
• Guests that are not in HA. The balancer ignores them anyway.
• Very different nodes. A small node can still fill up fast. Test first and use node affinity rules.

You can use HA with auto-rebalance for web and app VMs that are easy to move. Keep sensitive VMs on one node. Leaving these VMs out of the balancer is part of a smart Proxmox dynamic load balancer setup.

When you finish, you can remove the test guests and rules. This keeps your cluster clean:

Then, you can set your production values in /etc/pve/datacenter.cfg.

A multi-node PerLod dedicated server cluster gives you full control of the hardware, fast private networking for migrations, and space to test your Proxmox dynamic load balancer setup before you go live. With dedicated nodes, the balancer helps you use all your CPU and RAM, so no node sits idle.

The Proxmox VE 9.2 Dynamic Load Balancer gives you automatic VM placement without scripts. You have learned to set ha=dynamic, turn on ha-auto-rebalance, and tune the threshold, hold duration, and margin. With this, the cluster moves HA guests from busy nodes to calm ones and follows your rules. 

We hope you enjoy this guide. For more detailed information, you can check the Proxmox VE High Availability documentation.