Skip to content

Predictive Load Balancing

DRS-style trend-based VM migration before nodes become overloaded

PegaProx's Predictive Load Balancing goes beyond reactive threshold-based migration. It analyzes resource trends over time and preemptively migrates VMs before nodes reach critical load - similar to enterprise DRS solutions.

How It Works

  1. PegaProx continuously records CPU, RAM, and disk metrics per node (288 data points = ~24 hours at 5-min intervals).

  2. An exponentially weighted moving average (EWMA) calculates the trend - recent data points matter more than old ones.

  3. When a node's trend score exceeds the predictive threshold (default: 75) with sufficient confidence (≥60%), a preemptive migration is triggered.

  4. The least-loaded node is selected as the target, respecting affinity rules, CPU compatibility, and excluded nodes.

Configuration

Enable in Cluster Settings → Options:

Setting Default Description
Predictive Load Balancing Off Enable trend-based preemptive migration
Predictive Threshold 75 Score above which a node is considered trending towards overload (50–95)
CPU Weight 1.0 How much CPU contributes to the balancing score (0–2)
RAM Weight 1.0 How much RAM contributes (0–2)
Disk I/O Weight 0.0 How much disk usage contributes (0–2)

CPU Compatibility Mode

Set a cluster-wide CPU baseline to prevent migrations between incompatible CPU generations. VMs with a CPU type above the baseline will not be automatically migrated. VMs using cpu: host are checked for vendor compatibility (Intel vs AMD).

Baseline Intel Minimum AMD Minimum
x86-64-v2 Nehalem Opteron G3
x86-64-v2-AES Westmere Opteron G4
x86-64-v3 Haswell EPYC
x86-64-v4 Skylake-Server EPYC-Genoa

ProxLB VM Tags

An opt-in, per-cluster option that lets PegaProx derive placement rules from ProxLB-convention VM tags. It is off by default - when off there is zero behaviour change.

Enable it under the cluster's Balancing settings by turning on the ProxLB VM Tags toggle.

When on, PegaProx reads ProxLB-convention VM tags (PVE stores tags semicolon-separated) and derives the following placement rules:

  • plb_affinity_<group> - keep all guests sharing that group on the same node (affinity / "together").
  • plb_anti_affinity_<group> - spread guests sharing that group across different nodes (anti-affinity / "apart").
  • plb_ignore (or plb_ignore_<suffix>) - never auto-migrate this guest (added to the balancing-exclusion set).
  • plb_pin_<node> - restrict this guest to the named node(s). The node name is validated against actual cluster membership, and an unknown name is ignored (not silently trapping the VM).

Note

Derived affinity/anti-affinity rules are treated as enforced rules and feed the same engine as PegaProx's own affinity rules, plus the balancing-exclusion set and target selection. They are used by both the load balancer and maintenance evacuation.

Pins during a node drain (from 1.3)

When a node is drained (maintenance or a rolling update), a pinned guest goes to another node of its pin first, and to a node outside its pin only as a last resort, so a pin does not block maintenance. HA affinity rules and storage availability are applied before the pin. Two switches in the cluster settings (shown when ProxLB VM Tags are on) change that:

  • Strict pins: a pin also vetoes the evacuation; a pinned guest with no free pinned node stays where it is and the drain says so.
  • Move back automatically: guests that ended up off their pin are moved back by the balancer (a few per cycle). Off by default: PegaProx only reports them.

The cluster settings list the guests that are currently off their pin with the reason; users with the right to migrate them on the whole cluster can move them back now.

API Endpoints

Method Endpoint Description
GET /api/clusters/{id}/predictive-analysis Get predictive analysis for all nodes
GET /api/clusters/{id}/cpu-compatibility CPU compatibility matrix