Using VMware vSphere DRS VM‑VM Affinity Rules to Control Placement

Problem: Keeping latency‑sensitive VMs together (or apart) without manual intervention

When you run a multi‑tier application—say a web front‑end and a database tier—you often need the VMs to stay on the same ESXi host to minimize network latency, or you need them spread across hosts for fault tolerance. Manually moving VMs after each DRS rebalance is error‑prone and doesn’t scale.

Thesis: VM‑VM affinity and anti‑affinity rules let DRS enforce placement automatically, but you must choose the right enforcement level (Required vs Preferred) and watch for conflicts that can block VM power‑on or cause unnecessary migrations.

How affinity rules work in DRS

DRS evaluates affinity/anti‑affinity constraints during the initial power‑on of a VM and in each subsequent rebalance cycle. The scheduler treats the constraint as another resource demand, weighing it against CPU/memory load, host maintenance mode, and existing VM‑to‑host affinities.

Two enforcement levels exist:

• Required – DRS must satisfy the rule; if no host can meet all Required constraints, the VM fails to power on or DRS raises a red alarm.
• Preferred – DRS tries to satisfy the rule but may violate it to relieve resource pressure; a violation appears as a yellow recommendation.

When multiple rules conflict, Required rules outrank Preferred ones. If a Required rule conflicts with another Required rule (or with a host affinity rule), DRS cannot place the VMs and will generate an alarm.

Worked example: Enforcing co‑location of a web and DB VM

Assume a DRS‑enabled cluster running vSphere 8.0 Update 2 with two ESXi hosts (HostA and HostB). You have two VMs: web01 and db01. You want them to stay on the same host to reduce latency.

1. In the vSphere Client, navigate to the cluster → Configure → vSphere DRS → VM‑VM Affinity Rules → Add.
2. Set VMs to web01 and db01, choose Affinity, and select Required.
3. Click OK. The rule is stored in the cluster’s DRS configuration.
4. Power on both VMs (if they are off). DRS will place them together on whichever host has sufficient resources.
5. To verify, select each VM → Summary tab → Host. Both should show the same host name (e.g., HostA).

If you later run a CPU‑intensive workload on HostA that pushes its utilization above the DRS migration threshold, DRS will attempt to rebalance. Because the rule is Required, DRS will keep the pair together and may instead migrate other VMs or suggest adding resources. If no host can satisfy the Required rule (e.g., HostA is in maintenance mode and HostB lacks free memory), DRS will raise a red alarm: "Affinity rule violation: Required VM‑VM affinity rule cannot be satisfied."

Trade‑offs and limitations

While Required rules guarantee placement, they can fragment the cluster:

• Hosts may become over‑committed with the paired VMs while other hosts sit under‑utilized, limiting DRS’s load‑balancing ability.
• During host maintenance mode, Required rules are ignored unless the VM also has a "Must run" host affinity rule, which can cause unexpected migrations.
• Complex rule sets increase the chance of conflicts; a single mis‑configured Required rule can block power‑on of many VMs.

Preferred rules avoid hard blocking but offer no guarantee. In periods of high contention, DRS may violate a Preferred anti‑affinity rule to relieve pressure, potentially increasing latency for latency‑sensitive services.

Practical way to check the result

After configuring a rule, you can validate its effect without waiting for a rebalance:

1. In the vSphere Client, select the cluster → Monitor → vSphere DRS → Recommendations.
2. Look for entries with the type "Affinity Rule". A Required rule that is satisfied shows no recommendation; a violated Required rule appears as a red alarm under Monitor → Alarms.
3. For Preferred rules, a violation shows as a yellow recommendation that you can choose to apply or dismiss.

You can also run a quick CLI check (if you have access to the vCenter Server Appliance shell):

# List all VM‑VM affinity rules for the cluster
vim-cmd hostsvc/drs_adv_info 

Replace with the cluster’s managed object reference (obtainable from the URL when viewing the cluster). The output includes the rule’s enforcement level and the VMs involved.

Actionable closing

Start with a small set of Required affinity rules for truly latency‑critical pairs, monitor DRS alarms for any violations, and use Preferred rules for softer guidelines where occasional separation is acceptable. Regularly review the cluster’s resource distribution (Host → Summary → Resource Usage) to ensure that affinity rules are not causing persistent hotspots. By tuning the enforcement level and keeping the rule set simple, you let DRS do the heavy lifting while you retain control over placement where it matters most.