Choosing vSphere DRS Automation Levels and Affinity Rules for License Compliance and HA

The problem: DRS defaults can break licensing and HA guarantees

vSphere Distributed Resource Scheduler (DRS) runs fully automated by default. That works for generic workloads, but it can place a Microsoft SQL Server Enterprise VM on an unlicensed host, or keep two domain controllers on the same host — defeating the very HA protection you paid for. The fix isn’t a single toggle; it’s a combination of cluster‑wide automation level, migration‑threshold tuning, and carefully scoped affinity/anti‑affinity rules.

1. Automation levels — what each actually does

• Manual – DRS only produces recommendations; you must approve every vMotion.
• Partially Automated – Initial placement is automatic; ongoing migrations still need approval. Good for strict change‑control windows or workloads tied to specific sockets.
• Fully Automated – Placement and ongoing migrations happen without intervention. Default for most production clusters.

Set the level cluster‑wide in Cluster → Configure → vSphere DRS → Edit or via PowerCLI:

Get-Cluster -Name 'Prod-Cluster' | Set-Cluster -DrsAutomationLevel FullyAutomated -DrsMigrationThreshold 3

The DrsMigrationThreshold (1‑5) controls aggressiveness. Level 3 (default) moves only when the benefit clearly outweighs the cost. Level 5 often triggers migration storms in dense, bursty clusters.

2. Affinity and anti‑affinity rule types

Rule type	Scope	Typical use
VM‑VM Affinity (keep together)	VM group	Low‑latency app+DB tiers, per‑host socket licensing
VM‑VM Anti‑Affinity (separate)	VM group	HA pairs (DCs, load balancers), spreading license‑heavy VMs
VM‑Host Affinity (must / should)	VM group → Host group	Hardware‑specific workloads (GPU, local NVMe), license‑bound sockets

Must rules are hard enforcement — DRS will never place the VM outside the host group, even during maintenance. Should rules add a cost penalty, allowing placement elsewhere if the group is full.

3. Worked example: License‑bound host group for Oracle / SQL Enterprise

1. Create a host group that contains only the hosts you have licensed for the database product.

   New-DrsClusterGroup -Cluster 'Prod-Cluster' -Name 'Licensed-DB-Hosts' -Type Host -Host (Get-VMHost -Name 'esxi01','esxi02','esxi03')

2. Create a VM group for the licensed database VMs.

   New-DrsClusterGroup -Cluster 'Prod-Cluster' -Name 'Licensed-DB-VMs' -Type VM -VM (Get-VM -Name 'sql-prod-01','sql-prod-02','oracle-prod-01')

3. Apply a VM‑Host Must rule so those VMs can only run on the licensed hosts.

   New-DrsRule -Cluster 'Prod-Cluster' -Name 'DB-Must-Run-On-Licensed' -Type 'VMHost' -VMGroup 'Licensed-DB-VMs' -HostGroup 'Licensed-DB-Hosts' -Mandatory $true

4. Add a VM‑VM Anti‑Affinity rule among the same VMs to spread them across the licensed hosts.

   New-DrsRule -Cluster 'Prod-Cluster' -Name 'DB-AntiAffinity' -Type 'VMVM' -VMGroup 'Licensed-DB-VMs' -Mandatory $true

5. Leave the rest of the cluster Fully Automated with threshold 3 and add VM‑VM anti‑affinity rules for each HA pair (e.g., two domain controllers).

Result: licensed VMs never land on unlicensed hosts, they are distributed across the licensed pool, and general‑purpose VMs still benefit from DRS balancing.

4. Trade‑offs and limitations you must accept

• Overusing “must” rules fragments capacity. During host maintenance DRS cannot evacuate VMs, and HA admission control may report insufficient failover capacity.
• Migration threshold 5 in clusters >12 hosts with mixed workloads often causes churn during backup windows or batch jobs.
• VM‑VM anti‑affinity is not enforced during HA failover. When a host fails, HA restarts VMs on any available host. Pair anti‑affinity with VM‑Host should rules or use vSphere Availability Zones (vSAN stretched clusters) for site‑level separation.
• DRS only sees CPU/RAM. It cannot detect JVM GC pauses, DB lock contention, or storage latency. Supplement with vRealize Operations or custom scripts for app‑aware placement.
• vSphere 8.0+ integration with vLCM: a host entering remediation goes into maintenance mode; DRS evacuates per automation level. Partially Automated clusters need approval workflows that finish within the remediation window.
• Content Library / template deployments do not auto‑apply DRS rules. Apply rules post‑deployment via PowerCLI or vCenter Orchestrator workflows.

5. Actionable checklist before you go live

1. Verify current DRS settings: Get-Cluster | Select Name, DrsAutomationLevel, DrsMigrationThreshold.
2. List all existing rules: Get-DrsRule -Cluster 'Prod-Cluster' | Format-Table Name, Type, Enabled, Mandatory, VMNames.
3. Run a DRS simulation (Predictive DRS or manual “DRS Run”) and review recommendations in the DRS tab.
4. Check HA admission control after rule changes: Cluster → Monitor → vSphere HA → Advanced Runtime Info → Current Failover Capacity.
5. Test a host maintenance evacuation: place a host in maintenance mode and watch Tasks & Events for vMotions or rule violations.
6. Cross‑reference the VMware vSphere Licensing Guide with your host groups to confirm per‑core compliance.

Follow these steps, adjust the migration threshold to 3 (or 2 for very stable clusters), and you’ll keep DRS working for performance while satisfying licensing auditors and HA requirements.