vSphere Distributed Resource Scheduler can balance workloads across cluster hosts, but many environments need placement rules that are stronger than pure resource optimization. Licensing boundaries, fault-domain separation, application dependencies, hardware characteristics, and compliance requirements can all require some virtual machines to run together, apart, on a defined host group, or away from a host group.
For engineers working with 2V0-17-25, the important distinction is between a preference and a constraint. VMware supports VM-VM affinity and anti-affinity rules and VM-Host rules with hard “must” or soft “should” semantics. Those choices affect DRS recommendations, manual migration, maintenance, and vSphere HA behavior.
Current Broadcom guidance is explicit that hard VM-Host rules can keep a VM powered off after a host-group failure if no compliant host remains, while soft rules can be violated to preserve availability. That makes rule design an availability decision, not just a placement preference.
Use rules only when placement carries business meaning
Do not create affinity rules to express every administrator preference. DRS already optimizes placement using resource demand. A rule is justified when the location itself matters: separating clustered nodes, pinning licensed software to entitled hosts, keeping latency-sensitive components together, or avoiding hardware that lacks a required device.
Each rule should have an owner and a reason. If the reason cannot be stated without referencing a person’s habit or an obsolete topology, the rule is a candidate for removal.
The broader vSphere DRS is useful, but production rules should be tied to operational requirements that can be reviewed.
Licensing rules deserve written evidence from the software vendor or contract owner. Administrators sometimes create hard host pinning based on an assumption that later proves unnecessary, sacrificing availability for no legal benefit. Conversely, treating a real license boundary as a soft preference can create compliance exposure. The infrastructure configuration should reflect an explicit licensing decision.
Know the difference between VM-VM and VM-Host rules
VM-VM rules express relationships among virtual machines: keep selected VMs together or keep them separate. VM-Host rules first define VM and host groups and then specify whether the VM group must or should run on that host group or must or should avoid it.
These models solve different problems. Anti-affinity between application nodes distributes them across hosts, while a VM-Host rule can enforce a licensing or hardware boundary. Combining them can create constraints that are individually sensible but collectively impossible.
Before adding a rule, model the remaining legal placements after one host is lost.
Rule naming should identify the protected requirement rather than the implementation detail. Names such as `Separate-DB-Quorum-Nodes` or `License-Boundary-Oracle-Hosts` explain why the rule exists. Generic names such as `Rule-12` or a former project code make later cleanup dangerous because administrators cannot tell whether deletion would remove a real control.
Hard rules trade flexibility for certainty
A “must run” or “must not run” VM-Host rule is mandatory. DRS will not place the VM outside the allowed relationship, and vSphere HA respects the hard boundary. If every allowed host is unavailable, the VM can remain down rather than violate the rule.
That behavior can be exactly correct for a software license or regulatory boundary, but it is dangerous when administrators expect HA to restart everything anywhere in the cluster. The rule description and runbook should state that availability is intentionally subordinate to the constraint.
This interaction is part of the wider vSphere HA architecture and should be tested with the actual cluster.
Soft rules preserve a preferred topology
A “should” or “should not” rule expresses a preference. During normal operations, DRS attempts to satisfy it, but availability events can override the preference. That is often appropriate for performance, locality, or administrative grouping where service continuity matters more than exact host placement.
Soft does not mean irrelevant. Persistent violations may indicate insufficient capacity, a disabled DRS host, incompatible hardware, or other constraints. Monitor violations and understand whether the cluster can return to the preferred state after maintenance or failover.
Use hard rules only when a violation is genuinely unacceptable.
Anti-affinity needs enough hosts to remain feasible
Separating two VMs requires at least two eligible hosts. Separating three critical nodes while also tolerating one host failure requires more capacity and often more hosts than teams initially assume. If the cluster shrinks during maintenance, DRS may have no legal placement that satisfies every rule.
Calculate feasibility in the degraded state. Consider host maintenance, failure, resource reservations, EVC or CPU compatibility, datastore access, network connectivity, and device passthrough. A rule that is satisfiable only when all hosts are healthy can become an outage multiplier.
The availability thinking in advanced vSphere cluster operations is especially relevant here.
Resource size matters as much as host count. Three VMs may have three eligible hosts, yet large reservations or CPU requirements can still make one legal placement impossible after failure. Evaluate placement with the actual reservations, NUMA needs, device dependencies, datastore access, and network connectivity that constrain each VM.
Maintenance should include rule review
Broadcom guidance notes that hard rules can obstruct host upgrades because automatic relocation cannot violate them. Before planned maintenance, identify mandatory rules that bind workloads to the host being drained. Decide whether the business permits temporarily disabling the rule or whether the workload must be shut down.
Do not disable rules casually across the cluster. Record the original state and restore it after maintenance. Validate that DRS has returned workloads to an acceptable placement and that no temporary host groups remain.
A maintenance plan that ignores placement policy is incomplete.
If a rule must be disabled temporarily, capture evidence of the exception: which rule, why, who approved it, when it should be restored, and how compliance will be verified afterward. Temporary exceptions are a common source of permanent drift when maintenance ends before the original constraint is re-enabled.
HA and DRS do not enforce every rule in the same way
DRS optimizes placement during normal cluster operation, while HA focuses on restart after failure. Broadcom documentation distinguishes how operations treat affinity, anti-affinity, and hard or soft VM-Host rules. Some conditions that DRS can repair later may not be fully enforced during a failover event.
That is why tests should include power-on, vMotion, host failure, and maintenance mode rather than assuming one rule has identical behavior in every workflow.
Capture the actual post-failover placement and confirm that DRS can converge the cluster afterward without violating a business requirement.
After a failover, DRS may need time and vMotion capacity to restore the preferred distribution. During that period, anti-affinitized services can temporarily share a host or soft rules can remain violated. Application owners should know whether that temporary state is acceptable and whether the service itself has safeguards against correlated failure.
Monitor rule health as configuration drift
Rules can become stale when VMs are renamed, decommissioned, cloned, or moved between clusters. Host groups can also become inaccurate after hardware refreshes. Periodically review rule membership, enabled state, violations, and descriptive metadata.
Use the same mindset as configuration drift and policy conflicts: the value is in the effective state, not in the existence of a configuration object.
Automation that creates or edits rules should validate group membership and current cluster capacity before making a change.
Include rule validation in cluster migration and VM onboarding workflows. Cloning a VM does not necessarily add the clone to the same DRS group, and moving a VM between clusters can leave the old rule irrelevant. Automation should explicitly manage membership so critical placement constraints are not lost during routine provisioning.
Alerting should focus on violations that matter. A soft preference violation during a short maintenance event may be expected, while a hard-rule configuration error that leaves a protected VM powered off is urgent. Classify rules by business impact so operations can distinguish informational placement drift from service risk.
Prefer the smallest rule set that expresses real constraints
VMware clusters become easier to operate when DRS is free to balance workloads except where placement truly matters. Too many rules reduce the scheduler’s solution space and make maintenance harder.
Document the business reason, choose hard or soft semantics consciously, confirm degraded-state feasibility, and test how HA behaves. If a placement preference can safely be broken during failure, encode it as a preference rather than as an absolute rule.
The best affinity design is not the one that produces a perfect steady-state diagram. It is the one that still produces an acceptable service when a host is gone and the scheduler has fewer choices.
When several rules describe the same business requirement, consolidate them where possible. A simpler rule graph is easier to test during maintenance and easier for DRS to satisfy. Complexity should come from real placement requirements, not from years of incremental exceptions that no one is willing to remove.
Review the complete rule graph before expanding the cluster or changing licensing. New hosts can make old hard boundaries unnecessary, while hardware specialization can make a previously soft preference more important. Placement policy should evolve with the infrastructure rather than remain frozen from the first deployment.
