Skip to content

Balance VM Load Across a Cluster (CRS)

CRS (Compute Resource Scheduler) watches a cluster's hosts and live-migrates VMs off busy hosts onto quieter ones. It's off by default and turned on per cluster. Turning it on needs a license edition that includes HA.

Turn it on

  1. Click the cluster in the inventory tree and open its Summary.
  2. In the CRS Auto-Balance card, Status → Enable.
  3. Check the two settings that then appear:
    • CPU spread: how far apart the busiest and quietest hosts must be before CRS acts. Default 20%, range 5–80%. Edit to change it.
    • Automation: what CRS does with a move it has picked. See Automation levels.

Dry run → Preview shows what the next pass would do right now. Nothing is migrated, queued or recorded. Use it before turning on Fully Automated.

How it decides

Every 5 minutes, CRS looks at each enabled cluster's live CPU and memory load. It acts only when both of these are true on either CPU or memory:

  • the busiest host is at 40% or more, so an idle cluster is never shuffled over a meaningless swing, and
  • the gap between the busiest and quietest host is at least the cluster's CPU spread setting (the same value is used for memory).

It then picks up to 2 VMs per pass from the busiest host and moves each to the quietest host that has room for it. A destination has to be clearly quieter than the source, by at least half the spread setting, which stops VMs bouncing between two similar hosts. If no host has room, nothing moves.

On a cluster where no host ever gets busy, CRS also evens out the number of running VMs when one host has several more than another.

Last pass, under the status, shows what the most recent pass decided: for example Balanced — nothing to do, the CPU and RAM spread it measured, or the moves it made.

Automation levels

Level Periodic balancing When a host leaves Maintenance
Manual — recommend only Recommends Recommends
Partially Automated Recommends Moves automatically
Fully Automated (default) Moves automatically Moves automatically

Recommendations appear in the cluster's CRS Recommendations card. Apply checks the move is still valid (the VM hasn't moved, the destination is still Active) before migrating. Dismiss drops it, and CRS won't recommend that VM again for 4 hours. Recommendations nobody acts on expire after 24 hours.

What CRS never moves

  • VMs on local disk (local qcow2 or ZFS). CRS only live-migrates VMs on shared storage: Ceph, NFS or LINSTOR.
  • LINSTOR / DRBD VMs to a host without a replica. They only move to a host that already holds one.
  • VMs tagged CRS: exclude. Add the tag from the VM's right-click menu → Tags. The VM list shows a badge for it.
  • VMs with PCI or USB passthrough devices, or shared folders. They can't be live-migrated.
  • A VM CRS moved in the last 60 minutes.
  • VMs that aren't running.
  • VMs whose required host labels the destination doesn't have. A VM keeps the Required Host Labels it was deployed with.

CRS also waits while 2 of its own migrations are still in progress in the cluster, so a slow migration can't trigger a pile-up of new ones.

When a host leaves Maintenance

When you right-click a host → Exit Maintenance, the console moves VMs back onto it until it holds about as many as before. This happens whether or not CRS is turned on for the cluster, and at every automation level, because it undoes the evacuation that Maintenance did. It still respects CRS: exclude, the 60-minute cooldown, local disks and LINSTOR replicas. The VMs that move back aren't necessarily the ones that left.

Predictive trigger (optional)

Predictive (ML) → Enable lets CRS act on a forecast as well as on current load. Every 6 hours it trains a forecast model on each host's recent load (Retrain now does it straight away). If the model expects a host that's below 40% CPU to go over it, CRS can move VMs off before it gets busy.

The CRS Predictive Trigger (ML) card shows how each model scores. A model is used only if it beats a plain "load won't change" guess by at least 5%. The card also shows how many times a host actually went over 40% during the test period, and how many of those the model saw coming. If no host went over, the card says the model hasn't been tested on that yet.

See also