VMware ESXi and vSphere Cluster Management

How to Create a VMware vSphere DRS VM Anti-Affinity Rule

Learn how to create, enable, and validate a VMware vSphere DRS VM anti-affinity rule that keeps selected virtual machines on separate ESXi hosts.

A VMware vSphere DRS VM anti-affinity rule tells Distributed Resource Scheduler (DRS) to avoid placing selected virtual machines on the same ESXi host. This protects paired or replicated workloads from a single host failure.

This guide covers the requirements, vSphere Client workflow, DRS behavior, validation steps, and troubleshooting. For a concise configuration reference, see Create a DRS anti-affinity rule.

What a DRS VM anti-affinity rule does

vSphere DRS is the vSphere Distributed Resource Scheduler, a cluster service that evaluates virtual machine placement and can recommend or perform migrations. An ESXi host is the hypervisor server that runs virtual machines.

A VM anti-affinity rule instructs DRS to keep designated virtual machines on different ESXi hosts whenever the cluster can satisfy the policy. For example, two application-server VMs that provide the same service can be placed on separate hosts. If one host fails, the failure should not take both application instances offline.

Anti-affinity is different from affinity:

  • VM anti-affinity: attempts to keep selected VMs apart on different hosts.
  • VM affinity: attempts to keep selected VMs together on the same host.
  • VM-host affinity or anti-affinity: controls whether a VM runs on members of a specified host group. This is different from a VM-to-VM anti-affinity rule.

Common use cases

  • Separate two redundant application-server VMs.
  • Keep an active service node and its standby or replica VM on different hosts.
  • Reduce the chance that one ESXi host outage interrupts every member of a small application pair.

Do not apply anti-affinity indiscriminately to every VM. Each rule reduces placement flexibility and can make balancing, maintenance, or recovery more difficult.

DRS rule types and intended placement behavior

VM anti-affinity
Objects: selected virtual machines
Desired behavior: keep selected VMs on separate ESXi hosts when possible
Typical use: redundant application servers or active and standby nodes

VM affinity
Objects: selected virtual machines
Desired behavior: keep selected VMs together on the same ESXi host when possible
Typical use: workloads that benefit from close placement

VM-host affinity or anti-affinity
Objects: virtual machines and host-group members
Desired behavior: allow or prevent VM placement on specified hosts
Typical use: licensing, hardware, geographic, or workload placement requirements

Requirements and planning

DRS rules are configured at the cluster level. Before creating the rule, confirm that the environment meets these conditions.

Requirement: vCenter Server-managed cluster
Why it matters: DRS cluster policies are managed through vCenter Server.
How to verify: Confirm the target ESXi hosts are members of the same vCenter inventory cluster.

Requirement: DRS enabled
Why it matters: A cluster cannot evaluate or apply DRS placement rules when DRS is disabled.
How to verify: Open the cluster management or configuration area and review the DRS settings.

Requirement: At least two eligible ESXi hosts
Why it matters: Two protected VMs need at least two eligible destinations to remain separate.
How to verify: Check that hosts are connected, available, and not excluded by host groups or VM-host rules.

Requirement: Sufficient CPU and memory capacity
Why it matters: A destination host must be able to run a VM without violating resource constraints.
How to verify: Review cluster and host capacity, reservations, admission conditions, and current contention.

Requirement: vMotion readiness
Why it matters: DRS may need to move a running VM to resolve a placement violation.
How to verify: Confirm vMotion networking, shared or otherwise compatible storage, CPU compatibility, device compatibility, and other applicable migration prerequisites.

Requirement: No conflicting placement rules
Why it matters: Affinity, VM-host rules, reservations, and other constraints can limit or contradict separation.
How to verify: Review related DRS rules, host groups, reservations, and workload policies before enforcing the new rule.

Plan for failure and maintenance conditions

Consider what happens during host failure, maintenance mode, resource contention, and hardware incompatibility. Maintenance mode is a host state used before servicing a host; workloads are typically evacuated to other hosts. If only one eligible host remains, an anti-affinity rule involving two or more VMs may be temporarily impossible to satisfy.

For a rule containing more than two VMs, DRS attempts to distribute the members across distinct hosts. The result depends on the number of eligible hosts and on resource, compatibility, host-group, and other placement constraints. If there are fewer eligible hosts than governed VMs, complete separation cannot be achieved.

Create the VM anti-affinity rule

1. Open the cluster DRS rules area

  1. Sign in to the vSphere Client with permissions to manage the target cluster.
  2. Select the DRS cluster that contains the protected VMs.
  3. Open the cluster management or settings area.
  4. Locate the DRS rules section.
  5. Choose the option to add or create a rule.

The exact labels can vary between vSphere Client releases, but the rule is created from the selected cluster rather than from an individual VM.

2. Choose the VM-to-VM anti-affinity type

  1. Enter a clear, operationally meaningful name, such as Separate-App-Primary-and-Standby.
  2. Select the VM-to-VM rule type that keeps virtual machines separate. It may be labeled VM anti-affinity or similar.
  3. Do not select a VM-host affinity or anti-affinity rule for this use case. That type controls placement against host groups, not separation between selected VMs.

The intended result is that each selected VM runs on a different ESXi host whenever DRS can satisfy the rule.

3. Add the protected virtual machines

  1. Use the VM selection control to add the VMs that must not share a host.
  2. Verify that the list contains the correct production instances.
  3. Exclude unrelated VMs unless they have the same separation requirement.
  4. For an application pair, confirm that both the primary and standby or replica VM are included.
  5. Save or complete the rule creation workflow.

When more than two VMs are included, DRS attempts to place the members on distinct hosts. This is subject to the number of available hosts, capacity, compatibility, maintenance state, and other policies.

4. Confirm that the rule is enabled

After saving, confirm that the new rule appears in the cluster DRS rules list and that its enabled state is on. A disabled rule remains configured but does not actively guide DRS placement.

Administrators can later edit the rule, disable it temporarily, or remove it when workload requirements change. Review the effect of any change before applying it to production workloads.

What DRS does after configuration

After a rule is created or changed, DRS evaluates current VM placement. If protected VMs share a host, DRS may identify a migration needed to satisfy the new policy.

A DRS recommendation is a suggested placement action, commonly a vMotion migration, generated to improve balance or comply with a rule. The result depends on the cluster's DRS automation level:

  • Fully automated: DRS can perform eligible migrations automatically after evaluating the rule and other constraints.
  • Manual or partially automated: DRS presents a recommendation, but an administrator may need to approve or apply the migration.

vMotion is the live migration of a running VM between compatible ESXi hosts. If vMotion prerequisites are not met, DRS may be unable to move a VM even when the anti-affinity rule identifies a preferred placement.

Rules work alongside resource availability and other cluster constraints. DRS must consider CPU and memory capacity, reservations, host compatibility, VM-host rules, maintenance state, connected-host status, and other placement policies. A rule does not override those conditions.

Validate the rule and current placement

Review DRS monitoring or recommendations

  1. Select the cluster containing the rule.
  2. Open the DRS monitoring, recommendations, or related cluster view.
  3. Look for an anti-affinity violation, a placement compliance message, or a recommendation to migrate one of the protected VMs.
  4. If the cluster uses manual recommendations, review the proposed destination and apply it only after checking its impact.
  5. If the cluster is fully automated, allow time for an eligible migration, then review the resulting events and placement.

Verify each VM's host

  1. Open the summary information for each protected VM, or use the cluster inventory view.
  2. Record the current ESXi host for every VM in the rule.
  3. Confirm that the protected VMs are running on separate hosts.
  4. Recheck the DRS view after migration to confirm that the rule is compliant.

For example, if App-Primary and App-Standby initially run on esxi-01, DRS may recommend moving one VM to esxi-02. Validation is complete when the VMs are confirmed on different eligible hosts and the rule no longer reports a violation.

Before-and-after placement example

Before:                         After remediation:
ESXi-01                         ESXi-01
  App-Primary                     App-Primary
  App-Standby                   ESXi-02
                                  App-Standby

Troubleshooting anti-affinity rules

Symptom: The rule is created but both VMs remain on one host.
Likely cause: DRS is using manual recommendations, the recommendation has not been applied, no eligible host has capacity, vMotion is blocked, or another policy conflicts with the rule.
Checks: Review DRS recommendations, cluster events, automation level, host connectivity, capacity, vMotion prerequisites, and related VM or VM-host rules.
Resolution: Apply the recommendation when approved, restore an eligible destination, resolve migration prerequisites, or review conflicting policies.

Symptom: DRS reports that the rule cannot be satisfied.
Likely cause: There are not enough eligible hosts, a host is in maintenance mode or unavailable, or host groups, reservations, and compatibility restrictions reduce placement choices.
Checks: Count eligible hosts, inspect host connection and maintenance state, review capacity and reservations, and inspect other placement rules.
Resolution: Restore or add eligible capacity, adjust conflicting policies after assessing availability impact, or reduce the rule scope if the requirement exceeds the cluster design.

Symptom: A maintenance operation cannot evacuate a host cleanly.
Likely cause: The remaining hosts cannot preserve the required separation, or capacity and compatibility restrictions block vMotion.
Checks: Review DRS recommendations, remaining host capacity, vMotion readiness, and the number of eligible destinations after evacuation begins.
Resolution: Ensure enough hosts remain available, resolve migration constraints, or temporarily adjust the rule only with workload-owner approval and according to operational policy.

Operational cautions

  • Avoid creating contradictory VM affinity and anti-affinity rules for the same workloads.
  • Review VM-host affinity or anti-affinity rules because they can eliminate the hosts needed to satisfy VM-to-VM separation.
  • Check reservations and other resource policies before assuming that an apparently idle host is an eligible destination.
  • Plan for fewer eligible hosts during outages, maintenance mode, disconnections, or hardware compatibility problems.
  • Expect a rule to be temporarily impossible to satisfy when the cluster lacks enough capacity or hosts.
  • Review DRS rules periodically. Remove outdated policies so they do not unnecessarily restrict balancing, maintenance, or recovery operations.
  • Use separation for workloads that have a meaningful host-failure risk, rather than applying it to every VM.

Exam-relevant points

  • DRS rules are configured at the vCenter-managed cluster level.
  • A VM anti-affinity rule keeps selected VMs apart; a VM affinity rule attempts to keep them together.
  • A VM-to-host rule is not the same as a VM-to-VM anti-affinity rule.
  • DRS automation level determines whether a migration is automatically performed or presented as a recommendation.
  • vMotion, host compatibility, capacity, and other placement policies can prevent DRS from satisfying a rule.
  • Always validate both DRS compliance and the actual ESXi host assigned to each protected VM.