VMware ESXi and vSphere Cluster Management
VMware DRS Affinity Rules: VM Placement, Separation, and VM-to-Host Policies
Learn how VMware vSphere DRS affinity, anti-affinity, and VM-to-host rules control VM placement, including groups, enforcement, conflicts, EVC, configuration, and troubleshooting.
VMware vSphere Distributed Resource Scheduler (DRS) places and balances virtual machines across the ESXi hosts in a DRS cluster. By default, DRS considers resource demand, available capacity, automation settings, and migration feasibility. DRS rules add placement policies that influence where VMs should or must run.
This lesson covers VM-VM affinity, VM-VM anti-affinity, VM-to-host rules, DRS groups, required and preferential behavior, rule conflicts, vMotion compatibility, and operational validation. For a concise reference, see DRS affinity rules.
What DRS affinity rules do
DRS is a vSphere cluster service that places and balances virtual machine workloads across ESXi hosts. A DRS cluster is a group of hosts managed as a shared compute resource pool.
Affinity rules are policies that influence DRS placement and migration decisions. They are evaluated when a VM is powered on, when a running VM is moved with vMotion, and when DRS rebalances cluster workloads. A rule does not replace normal DRS resource analysis: the destination host must still have adequate resources and be eligible for the VM.
- Affinity favors placing selected VMs together on one host.
- Anti-affinity favors or requires placing selected VMs on different hosts.
- VM-to-host rules control whether a VM group may run on a host group.
Placement controls can support application design, licensing compliance, performance locality, hardware requirements, compliance zones, or workload isolation. The trade-off is reduced DRS flexibility. The more hosts a rule excludes, the fewer options DRS has for balancing load, evacuating a host, surviving a failure, or completing maintenance.
VM-VM affinity
A VM-VM affinity rule favors placing selected virtual machines on the same ESXi host. For example, an application server VM and a processing VM with heavy east-west traffic might benefit from host-local communication and reduced network traversal.
Affinity may be useful when:
- Two application components communicate frequently.
- Latency between tightly coupled tiers is important.
- A workload has a host-local performance characteristic.
- The application design benefits from keeping related components together.
Co-location has a significant availability cost: a single ESXi host failure can affect every VM in the affinity set at the same time. Therefore, VM-VM affinity must not be treated as an availability mechanism. If the VMs are redundant nodes, separation is usually the more appropriate policy.
VM-VM anti-affinity
A VM-VM anti-affinity rule favors or requires selected VMs to run on different ESXi hosts whenever cluster capacity and rule enforcement allow. Common examples include redundant application nodes, clustered services, replicas, and infrastructure roles that should not share one host.
Separating two nodes reduces the chance that one ESXi host failure interrupts both nodes. It does not replace application-level replication, a supported failover design, backups, or disaster recovery. The application must still be able to fail over correctly, and the cluster must have enough suitable hosts.
If there are too few eligible hosts, or if alternative hosts lack capacity or compatibility, the anti-affinity condition may not be satisfiable. The result depends on the rule's enforcement behavior. A required policy can block a power-on or migration; a preferential policy can be violated when necessary to keep service running or satisfy a more important operational constraint.
| Rule type | What it controls | Typical objective | Common use case | Availability impact | Operational risk |
|---|---|---|---|---|---|
| VM-VM affinity | Relationship between selected VMs | Co-location | High-traffic or tightly coupled application components | Can increase shared-host failure exposure | Reduces placement flexibility |
| VM-VM anti-affinity | Relationship between selected VMs | Separation | Redundant nodes, replicas, clustered services | Reduces exposure to one host failure | Needs enough eligible hosts and capacity |
| VM-to-host | VM group eligibility on host group | Targeting or exclusion | Licensing, GPUs, hardware, compliance, isolation | Depends on the size and resilience of the host set | Can block evacuation or power-on |
VM-to-host affinity rules
A VM-to-host rule links a VM group to a host group. It controls the relationship between a set of VMs and a set of ESXi hosts, rather than the relationship between one VM and another VM.
The two primary policy directions are:
| Policy direction | VM group relationship to host group | Example use | Failure and maintenance consideration |
|---|---|---|---|
| Must run on designated hosts | VMs may run only on hosts in the selected host group | Licensed workloads on entitled hosts | Maintenance or failure can leave no valid destination unless sufficient licensed capacity exists |
| Must not run on designated hosts | VMs may not run on hosts in the selected host group | Keep general workloads away from GPU or specialized hardware hosts | Remaining hosts must have enough capacity for normal operation and evacuation |
Typical reasons for targeting or excluding hosts include hardware devices, licensing boundaries, specialized CPU or GPU capability, compliance zones, and workload isolation. A VM-to-host rule cannot make an incompatible host usable; CPU, device, storage, network, resource, and vMotion requirements still apply.
DRS groups
VM-to-host rules depend on DRS groups:
- A VM group is a logical collection of one or more virtual machines.
- A host group is a logical collection of one or more ESXi hosts in the same DRS cluster.
Groups simplify administration. One rule can cover several licensed VMs and several eligible hosts instead of requiring a separate policy for every VM-host relationship.
Plan membership carefully. A VM group should contain workloads that have the same placement requirement, and a host group should contain hosts that are genuinely interchangeable for that workload. Consider capacity, CPU generation, attached devices, network and datastore access, licensing, maintenance procedures, and failure scenarios before adding members.
Required versus preferential behavior
Placement rules can be mandatory or preference-based, depending on the rule type and vSphere version. A required rule is a strict placement policy. A preferential rule is guidance that DRS attempts to honor without making it an absolute eligibility boundary.
| Enforcement model | DRS behavior | Effect when no compliant host exists | Best-fit use cases | Key caution |
|---|---|---|---|---|
| Required | Attempts to maintain the rule as a hard constraint | Power-on or migration may be blocked, or a VM may be unable to reach the desired placement | Licensing, compliance, hardware eligibility, or a genuine hard boundary | Can prevent balancing, evacuation, or recovery if the eligible set is too small |
| Preferential | Attempts to honor the placement preference while considering service operation and other constraints | DRS may leave or place a VM contrary to the preference | Performance locality, a desirable but nonessential relationship, or soft separation | Do not assume the preference guarantees placement during contention or failure |
Use a required policy only when violating it is unacceptable. A soft preference is often safer when the objective is optimization rather than eligibility. For example, co-locating high-traffic VMs may be useful, but blocking a migration during host maintenance may be worse than temporarily separating them.
Rule conflicts and precedence planning
Rules are compatible only when DRS can find at least one placement that satisfies their combined conditions. Contradictory enabled policies can make a configuration invalid or leave no eligible destination.
| Potential conflict | Why it is invalid or risky | How to investigate | Resolution approach |
|---|---|---|---|
| The same VM pair must stay together and remain separated | No host placement can satisfy both conditions | List every VM-VM rule affecting both VMs | Choose the business objective and disable or redesign the other rule |
| A VM must run on a host group but is also excluded from that group | The VM has no permitted host in the applicable sets | Review all VM-to-host rules and group memberships | Correct membership or remove the contradictory policy |
| A VM group has no eligible host after multiple constraints | Power-on, migration, or evacuation can fail | Intersect allowed hosts with capacity, compatibility, and state checks | Add eligible hosts, relax a rule, or redesign the group |
| Anti-affinity has fewer available hosts than VMs | Separation cannot be maintained | Check host count, host state, capacity, and rule enforcement | Add capacity or use a preference if temporary co-location is acceptable |
Before enabling a new rule, map the affected VMs, VM groups, host groups, and all existing rules. Disabling, changing, or removing a conflicting rule may be necessary before a valid configuration can be activated.
vMotion and EVC requirements
vMotion is the live migration technology DRS uses to move running VMs between compatible hosts. A valid affinity rule does not override vMotion requirements.
Enhanced vMotion Compatibility (EVC) provides a cluster-level CPU feature baseline. In supported configurations, EVC helps hosts with different processor generations expose a consistent set of CPU features to VMs, improving migration compatibility across the cluster.
DRS still cannot move a VM to a destination that fails CPU compatibility, device compatibility, storage or network requirements, maintenance-state checks, resource checks, or another enabled constraint. When designing host-targeting rules, verify EVC coverage and vMotion eligibility across every intended destination host, not just the hosts currently running the VMs.
Configuration workflow in the vSphere Client
- Verify prerequisites. Confirm that the target cluster has DRS enabled and that your vCenter account has privileges to configure cluster settings, groups, and rules.
- Define the objective. Identify application dependencies, availability requirements, capacity needs, licensing boundaries, hardware requirements, and eligible hosts.
- Plan memberships. For VM-to-host policies, create VM groups and host groups whose members share the same eligibility requirement.
- Create the rule. In the cluster's DRS rules and groups area, add a VM-VM affinity or anti-affinity rule by selecting the participating VMs. For a VM-to-host rule, select the VM group, host group, policy direction, and available enforcement level.
- Enable deliberately. Review the scope and choose required or preferential behavior based on the consequence of a violation.
- Validate placement. Check current rule compliance, eligible hosts, DRS recommendations, migration eligibility, resource capacity, and vMotion compatibility.
- Test operations. Under change control, evaluate power-on, vMotion, maintenance-mode evacuation, and host-failure scenarios.
- Document ownership. Record the business justification, affected VMs, group membership, exception behavior, enforcement level, and review owner.
Graphical vCenter configuration is sufficient for the core workflow. PowerCLI or the vSphere API can automate groups and rules at scale, but automation should include validation for conflicting policies and insufficient eligible capacity.
Practical placement examples
High-traffic multi-VM application
Suppose an application server VM and a closely coupled processing VM exchange large volumes of data. A VM-VM affinity rule can favor placing them together. Measure the latency or throughput benefit, then compare it with the increased impact of losing their shared ESXi host.
Two redundant service nodes
For two application nodes that provide failover, use VM-VM anti-affinity so they run on separate hosts. Confirm that at least two compatible hosts have sufficient capacity and that the application itself supports failover. The rule complements, but does not replace, application replication and backup.
Licensed application on specific hosts
Create a VM group for the licensed workloads and a host group containing hosts covered by the license entitlement. A required must-run policy can enforce the boundary. Before using it, confirm that enough licensed hosts remain available during maintenance and host failure.
Exclude general workloads from specialized hosts
Create a host group for hosts reserved for a specialized hardware-backed application, then use a must-not-run policy for general workloads. Combine the policy with capacity planning so the remaining hosts can run those workloads and the reserved hosts remain available for their intended purpose.
Mixed-generation cluster
Before creating a rule that may cause DRS to relocate a VM between processor generations, verify EVC and migration compatibility for every intended destination. A placement rule cannot make an incompatible migration possible.
Troubleshooting DRS rule behavior
A VM cannot power on after a strict VM-to-host rule is enabled
- Check whether any host in the allowed host group has sufficient resources.
- Check whether permitted hosts are connected, available, and not in maintenance mode.
- Check CPU, device, datastore, network, and other compatibility requirements.
- Review whether the policy must remain required or can safely become preferential.
DRS does not move a VM to the intended host
- Review DRS recommendations and the VM's migration-compatibility checks.
- Verify EVC and CPU compatibility between source and destination hosts.
- Check destination capacity and all other rules affecting the VM.
- Determine whether the rule is preferential and whether DRS has a stronger operational reason not to honor it.
An anti-affinity pair is running on the same host
- Verify that the rule is enabled and identify whether it is required or preferential.
- Check whether enough eligible hosts are available.
- Check alternative-host capacity, compatibility, connection state, and maintenance state.
- Review whether another constraint prevents separation.
A new rule cannot be enabled or produces a conflict
- Map every rule affecting each VM.
- Inspect VM and host group membership for overlapping or contradictory assignments.
- Look for simultaneous co-location and separation requirements.
- Remove or redesign contradictory policies before enabling the new rule.
Host maintenance cannot evacuate all VMs
- Check whether required VM-to-host rules restrict VMs to the host entering maintenance or to too few alternatives.
- Confirm that the remaining permitted hosts can accept the workloads.
- Plan a temporary policy change, add eligible hosts, or increase capacity before maintenance.
Design and operational cautions
- Avoid excessive strict rules. They can constrain balancing, reduce maintenance options, and complicate host evacuation.
- Maintain enough eligible hosts for normal capacity, HA recovery, maintenance, and host-failure scenarios.
- Review rules after adding or removing hosts, changing hardware, modifying applications, or redesigning the cluster.
- Keep VM groups and host groups current; stale membership can silently produce unexpected eligibility.
- Use affinity policies alongside, not instead of, HA admission control, resource reservations, application clustering, backups, and disaster recovery.
- Record why each rule exists and who owns its review. A rule without an owner is likely to become an unexplained operational constraint.
Summary
VM-VM affinity keeps related VMs together, while VM-VM anti-affinity separates VMs to reduce shared-host failure exposure. VM-to-host rules associate VM groups with allowed or excluded host groups for requirements such as licensing, hardware, compliance, and isolation.
Required rules provide strict enforcement but can block power-on, migration, and maintenance. Preferential rules provide guidance and preserve more DRS flexibility. Every rule must be evaluated alongside resource capacity, host state, vMotion compatibility, EVC, HA design, and other policies. Effective DRS design starts with a clear objective, uses the least restrictive suitable policy, and validates both routine placement and failure scenarios.