VMware ESXi and vSphere Cluster Management

VMware DRS Affinity Rules: VM Placement, Availability, and Host Constraints

Learn how VMware vSphere DRS affinity, anti-affinity, and VM-to-host rules control VM placement, availability, compatibility, and host constraints.

VMware vSphere Distributed Resource Scheduler (DRS) influences where virtual machines run within a DRS-enabled cluster. DRS balances workloads across ESXi hosts, while placement rules add application, licensing, hardware, or availability requirements to that decision.

This lesson explains VM-VM affinity, VM-VM anti-affinity, VM-to-host rules, DRS groups, rule enforcement, conflicts, migration compatibility, and operational validation.

What DRS affinity rules do

A DRS rule is a cluster-level placement policy. It tells DRS whether selected VMs should share a host, remain on separate hosts, or use only a defined set of ESXi hosts. DRS evaluates these rules during initial VM placement and may consider them when recommending or performing migrations.

The exact behavior depends on the rule type, enforcement level, and DRS automation mode. A preference gives DRS flexibility, while a required rule can block placement or migration when no compliant destination exists.

• Performance locality: Keep VMs with high internal traffic together when reducing cross-host communication is valuable.
• Workload separation: Place redundant service nodes on different hosts.
• Licensing restrictions: Restrict licensed workloads to hosts covered by the license.
• Hardware restrictions: Keep GPU-dependent or otherwise specialized workloads on capable hosts.
• Maintenance planning: Ensure placement behavior is understood before evacuating a host.
• Availability: Reduce the chance that one host failure affects redundant VMs.

Prerequisites and scope

DRS rules require vCenter Server and a cluster with DRS enabled. The eligible ESXi hosts must belong to that same cluster; rules do not manage placement across unrelated standalone hosts or separate clusters.

DRS is part of cluster resource management. vMotion is the live migration capability DRS uses or recommends for moving a running VM between compatible ESXi hosts. A rule can identify an acceptable placement, but it does not override vMotion prerequisites or host compatibility.

• Hosts must provide compatible CPU features, often supported by Enhanced vMotion Compatibility (EVC).
• The destination must have suitable datastore access, networking, devices, and available resources.
• Reservations, reservations-related capacity limits, host connectivity, and maintenance state can make a permitted host unusable.
• HA restart behavior and admission control can further affect whether a VM can be restarted after a failure.

For background on host inventory and cluster administration, see adding an ESXi host to vCenter Server inventory and vSphere HA admission control.

Comparison of DRS affinity rule types

VM-VM affinity rules

A VM-VM affinity rule attempts to keep specified virtual machines running together on the same ESXi host. For example, an application server VM and a latency-sensitive supporting service VM may benefit from reduced cross-host traffic.

Co-location is not automatically better. Sharing a host can reduce network latency, but it also means the VMs share the host failure domain. It can also prevent DRS from moving one VM independently when the cluster is unbalanced.

Use affinity only when the locality benefit is clear and greater than the availability and balancing tradeoffs. Test the behavior during vMotion, maintenance mode, and host failure.

VM-VM anti-affinity rules

A VM-VM anti-affinity rule attempts to keep selected VMs on different ESXi hosts. A common example is separating two nodes of a redundant application service so that a single host outage does not stop both nodes.

Anti-affinity reduces exposure to one host failure, but it does not replace application-level clustering, backups, replication, or broader fault-domain design. The application must still be able to fail over and maintain service.

Capacity is important. To keep several protected VMs separate, enough healthy, compatible hosts must be available. Maintenance, host failures, device requirements, and other rules can reduce the usable host count and make separation impossible.

VM-to-host rules

A VM-to-host rule controls whether a set of VMs may or must run on a selected set of ESXi hosts. These rules use DRS groups:

• A VM group is a DRS-defined collection of one or more virtual machines.
• A host group is a DRS-defined collection of one or more ESXi hosts.
• A VM-to-host rule pairs the VM group with the host group and defines whether the relationship is required, preferred, allowed, or prohibited according to the selected rule behavior.

Groups are easier to maintain than many individual VM-to-host mappings. When a workload is added, retired, or moved between categories, update the relevant VM group. When hosts are added, replaced, or repurposed, update the host group.

Typical uses include software license restrictions, specialized hardware, compliance boundaries, dedicated host pools, and workloads requiring particular capabilities. A GPU workload, for example, may be associated with a host group containing hosts with the required accelerator hardware.

Preferential versus required rules

A preferential rule is a soft placement preference. DRS tries to honor it when feasible but can choose another compliant option when resources, compatibility, another rule, or cluster conditions prevent the preference.

A required rule is a hard placement constraint. If no suitable host satisfies it, DRS may be unable to power on, restart, or migrate the VM. Required rules therefore need explicit capacity and failure planning.

Before using a required rule, confirm that eligible hosts have sufficient CPU, memory, storage, networking, and device access. Also model a host failure and planned maintenance event. A rule that works at full capacity may prevent HA restart after losing one host.

DRS groups and group maintenance

Groups provide an administrative abstraction for VM-to-host placement. For example, a VM group named Licensed-App-VMs can be paired with a host group named Licensed-App-Hosts. The rule then applies to the groups rather than requiring a separate rule for every VM.

Review group membership whenever:

• A VM is created, deleted, retired, or moved to another workload category.
• An ESXi host is added, replaced, retired, or moved to another operational pool.
• Licensing terms or compliance boundaries change.
• Hardware capabilities such as GPUs or other devices change.
• The cluster is expanded or its failure-capacity assumptions change.

Rule interactions and conflicts

DRS rules must describe a placement model that can actually be satisfied. Conflicting rules cannot be enabled together, and overlapping rules can make recommendations difficult or impossible.

Before adding a rule, review existing VM-VM rules, VM groups, host groups, and VM-to-host rules that affect the same VMs or hosts. A rule that is individually sensible can become harmful when combined with another constraint.

EVC and migration compatibility

Enhanced vMotion Compatibility (EVC) establishes a common CPU feature baseline for hosts in a cluster. This helps maintain CPU compatibility when vMotion moves a VM between hosts with different processor generations.

EVC and DRS rules solve different problems. A rule may permit a VM to use a host, but the VM still may not be able to migrate there. Check CPU feature compatibility, EVC status, datastore visibility, network availability, virtual device requirements, reservations, host connectivity, and maintenance state.

Therefore, “permitted by the rule” does not mean “usable as a migration destination.” A host group should contain hosts that are both policy-compliant and technically capable of running the workloads.

Configuring DRS rules in the vSphere Client

1. Open the target DRS-enabled cluster.
2. Create or review VM groups and host groups for VM-to-host placement.
3. Add the appropriate VM-VM or VM-to-host rule.
4. Select the affected VMs or groups and, when applicable, the target host group.
5. Choose preferential or required enforcement where the interface provides that choice.
6. Review existing rules for contradictory VM membership or host constraints.
7. Enable the rule only after checking capacity, compatibility, maintenance, and failure scenarios.
8. Review rule compliance, DRS recommendations, migration history, and actual VM placement after configuration.

Record the affected VM names and workload roles, eligible hosts, enforcement decision, failure and maintenance capacity, EVC status, and storage, network, device, and licensing dependencies before changing production placement.

Design and operational guidance

• Use rules only when a technical or business requirement justifies the constraint.
• Prefer a soft rule when the desired placement is useful but not essential.
• Use required rules cautiously because they can turn a host failure or maintenance event into a power-on or migration failure.
• Do not assume anti-affinity alone provides application availability; validate the application design and failover process.
• Keep host groups large enough to provide capacity after losing a host.
• Document each rule's purpose, owner, enforcement level, affected VMs, allowed or excluded hosts, and expected failure behavior.
• Test maintenance mode, HA restart behavior, host failure, and capacity loss before relying on required rules.
• Review rules after cluster expansion, hardware replacement, application changes, or licensing changes.

Excessive constraints reduce DRS effectiveness. They can leave one host highly utilized while another has spare capacity because the busy VM cannot legally move. Removing obsolete rules or replacing hard constraints with preferences can restore balancing flexibility.

Monitoring and validation

Use the vSphere Client to inspect the cluster's DRS rules, VM groups, host groups, current VM placement, and rule compliance. For unexpected placement, review DRS recommendations and migration history rather than looking only at the VM's current host.

Validation should answer these questions:

• Are VMs intended to share a host actually co-located?
• Are protected VMs on distinct healthy, compatible hosts?
• Are constrained VMs running only on permitted hosts?
• Does every VM group have at least one suitable host, and does every anti-affinity set have enough hosts for separation?
• Can the remaining eligible hosts handle planned maintenance and a host failure?
• Are storage, networking, CPU features, EVC, devices, reservations, and host state compatible with migration?

Rule design validation checklist

Troubleshooting common problems

A new DRS rule cannot be enabled

Review active affinity, anti-affinity, VM group, host group, and VM-to-host rules affecting the same objects. Check whether a VM belongs to multiple groups with contradictory requirements and whether the permitted host set is empty. Remove, disable, or redesign the conflicting rules.

DRS does not move a VM to the preferred host

The rule may be preferential rather than required. Other rules, resource conditions, or migration limitations may also prevent the move. Review the rule's enforcement level, DRS recommendations, EVC and CPU compatibility, datastore visibility, networking, devices, and available resources. Resolve the limiting condition, expand the eligible host set, or reassess the rule.

A VM cannot power on or restart after a host failure

Identify the VM's allowed host group and confirm that at least one permitted host is healthy, compatible, and has capacity. A required rule may restrict the VM to unavailable hosts. Restore an eligible host, expand the host group, adjust the rule if policy permits, or add capacity.

Anti-affinity is not preserved after capacity is reduced

Count healthy eligible hosts and compare that number with the number of VM instances requiring separation. Device requirements and VM-to-host constraints may reduce the usable count further. Restore or add hosts, reduce conflicting constraints, and test the failure-domain design under maintenance and outage conditions.

DRS cannot balance cluster load effectively

Inspect the number, scope, and enforcement levels of rules and compare host utilization with constrained VM placement. Required rules may concentrate workloads on a subset of hosts. Remove obsolete rules, replace hard constraints with preferences where safe, or expand the permitted host pool.

Key exam-relevant points

• DRS rules apply at the cluster level and require vCenter Server with DRS enabled.
• Affinity keeps selected VMs together; anti-affinity attempts to separate them.
• VM-to-host rules use VM groups and host groups to constrain placement.
• Preferential rules are soft preferences; required rules are hard constraints.
• Required rules can prevent VM power-on, HA restart, or migration when no compliant host exists.
• DRS rule compliance does not guarantee vMotion compatibility. EVC, storage, networking, devices, reservations, CPU features, and host state still matter.
• Anti-affinity improves host-failure isolation but does not replace application clustering, backups, or fault-domain planning.
• More constraints mean less freedom for DRS to balance workloads.