DRS rules look trivial in the UI — two radio buttons and a VM list. The semantics behind those buttons decide whether a host failure means a routine failover or a night of manual vMotions, and the gap between should and must is where most designs quietly go wrong.
Placement is not load balancing
DRS evaluates rules at two distinct moments: initial placement (power-on, restart after a failover) and the periodic load-balancing pass. A rule that is easy to satisfy at placement time can become unsatisfiable later — when a host enters maintenance mode or the cluster shrinks. Design rules for the degraded cluster, not the healthy one.
"Should" breaks loudly, "must" breaks quietly
An anti-affinity rule created as preferential (should) can be violated by DRS when no compliant target exists — the violation lands as an event you can alarm on, and the VM keeps running. A mandatory (must) rule differs in kind, not degree: it is enforced at the vCenter compatibility level, so it also binds manual vMotion and HA restarts — and it stays in force even with DRS switched off. Must doesn't fail; it makes other operations fail instead.
Three ways this bites
- The maintenance-mode deadlock. N VMs under a mandatory anti-affinity rule, spread across N hosts: the moment one host tries to enter maintenance mode, no compliant evacuation target exists — and the task hangs at a suspicious percentage until someone finds the rule.
- HA restarts vs. preferential rules. Whether HA respects VM–VM anti-affinity during a failover depends on version and configuration (see
das.respectVmVmAntiAffinityRulesand its default on your build) — verify on the cluster you actually run, not in the docs of the latest release. Baseline assumption: after a failover, expect violations and let the next DRS pass clean them up. - Rule sprawl. Rules outlive their authors. The UI shows them one cluster at a time; an audit is one pipeline away:
Get-Cluster PROD | Get-DrsRule |
Select-Object Name, Enabled, Mandatory, Type |
Sort-Object -Property Mandatory -Descending
Creating a new rule — preferential unless compliance says otherwise:
New-DrsRule -Cluster PROD -Name 'sql-separate' `
-KeepTogether:$false -VM (Get-VM sql01, sql02)
Rule of thumb: default to should plus an alarm on violation events; reserve must for cases where an external constraint — licensing, compliance, physical topology — genuinely forbids co-residency, and document each one next to the rule name.
Lab walkthrough
A recorded walkthrough of the maintenance-mode deadlock and the PowerCLI audit will be embedded here.