Node Fairness, technically known as “Virtual Machine Load Balancing,” is the native Windows Server feature designed to prevent specific cluster nodes from carrying too much weight.1 Think of it as a built-in, lightweight alternative to System Center Virtual Machine Manager (SCVMM) Dynamic Optimization.
While SCVMM offers granular control (like powering down nodes to save electricity), Node Fairness provides the essential functionality: monitoring host resources and Live Migrating VMs from overloaded nodes to idle ones. It serves as a critical “set and forget” feature for clusters that don’t utilize the full System Center stack.
How It Actually Works
Node Fairness runs directly inside the Failover Cluster service. It evaluates the load on each host using two specific heuristics:
- Memory pressure: This is usually the primary trigger. Since Hyper-V hosts typically exhaust RAM long before they run out of CPU cycles, memory distribution is the main driver for balancing events.
- CPU utilization: Averaged over a five-minute window.
If a node exceeds your configured threshold and another node has capacity, the cluster initiates a Live Migration. Crucially, this process respects your affinity rules, Fault Domains, and “Possible Owner” settings. It will not break anti-affinity rules just to balance RAM usage.
The 30-Minute Interval
By default, the cluster evaluates load every 30 minutes. This interval is hard-coded.
It is vital to understand that Node Fairness is not a real-time scheduler. It will not save you from a sudden CPU spike or a “noisy neighbor” VM that acts up for ten minutes. It is designed solely to correct long-term drift, such as the imbalance that occurs naturally as VMs grow over weeks, or the “morning after” scenario following a maintenance window.
Operating Modes (AutoBalancerMode)
You have two ways to run this, controlled by the AutoBalancerMode property.
Balance on node join (Mode 1)
The cluster only balances when a node joins (or rejoins) the cluster. This is specifically useful for patching cycles. If you reboot Node A for updates, it returns to the cluster empty. Mode 1 ensures Node A picks up its share of the work immediately, but the balancer goes dormant afterwards.
Always balance (Mode 2)
This is the default for Server 2022. The cluster checks on node join and runs the 30-minute timer continuously. If you have unpredictable workloads, this ensures the cluster self-corrects throughout the day.
Balancing Aggressiveness: Avoiding the “Ping-Pong” Effect
You can tune the balancer’s sensitivity via the AutoBalancerLevel. Choosing the right level is a trade-off between perfectly distributed resources and the performance penalty of Live Migrations.
- Low (Level 1 – Default): Moves VMs only when a host is >80% utilized.
- Medium (Level 2): Threshold is >70%.
- High (Level 3): Moves VMs if a host is >5% above the cluster average.
Recommendation: Stick to Low or Medium.
Setting aggressiveness to High is a common issue. It often leads to “VM churn” or ping-ponging, where VMs constantly migrate to chase a perfect 5% balance. Live Migration is not free, it consumes significant network bandwidth and CPU cycles on both the source and target hosts. You do not want to burn resources just to balance resources.
Note: The threshold applies to either CPU or Memory. If a host has 10% CPU load but 85% RAM usage, a Low setting (80% threshold) will still trigger a migration.
Configuration: PowerShell vs. GUI
While you can configure this in Failover Cluster Manager (Right-click Cluster > Properties > Balancer), PowerShell provides a cleaner way to verify settings across the cluster instantly.
Check current status:
PowerShell Get-Cluster | Format-List AutoBalancerMode, AutoBalancerLevel
Configure for “Always Balance” with “Medium” aggression:
PowerShell (Get-Cluster).AutoBalancerMode = 2 (Get-Cluster).AutoBalancerLevel = 2
To disable it completely:
PowerShell (Get-Cluster).AutoBalancerMode = 0
Note on Windows Admin Center (WAC): You can also configure this in WAC under Cluster Settings > Virtual Machine Load Balancing. It simply writes to the same PowerShell properties in the background.
Operational Realities
The “Memory Bully” Problem
Real-world logs often show that if you have a single massive VM (e.g., a 128GB SQL server) on a host, Node Fairness often hesitates to move it. The “cost” calculation of live migrating such a large memory footprint is high. If you have “Monster VMs,” use Anti-Affinity rules to pin them to separate hosts rather than relying on the balancer to figure it out.
Don’t Confuse Balance with Capacity
A common mistake is assuming that a “balanced” cluster is a “safe” cluster. Node Fairness spreads the load, but it does not create extra RAM. If you have 3 nodes running at 80% load, your cluster is balanced, but it is not redundant. If one node fails, the remaining two cannot absorb the workload (you need 120% capacity). Use Node Fairness to optimize performance, but always calculate your N-1 capacity for failover manually.
Verdict
Node Fairness is a competent tool for maintaining cluster hygiene without manual intervention. For most environments, the default Always Balance mode with Low (80%) aggressiveness is the correct configuration. It keeps hosts from red-lining without causing unnecessary migration traffic. Just remember that it corrects drift on a delay—it is not a replacement for proper capacity planning.
