VMware ESXi and vSphere Cluster Management

Required DRS Rules in VMware vSphere

Learn how required VM-to-host DRS rules control placement, vMotion, host failures, maintenance mode, licensing, capacity, and rule compliance in vSphere.

Required Distributed Resource Scheduler (DRS) rules are hard placement constraints for virtual machines in a vSphere cluster. They connect a VM DRS group to a host DRS group and restrict the ESXi hosts that may run those VMs.

These rules can enforce licensing, hardware, security, or other operational policies. They also reduce placement flexibility. If all compliant hosts fail or lack capacity, vSphere cannot use an otherwise available host that violates the rule.

What DRS and VM-to-Host Rules Do

vSphere Distributed Resource Scheduler (DRS) evaluates cluster resources and can select hosts for initial VM placement or recommend and perform live migrations with vMotion. DRS considers resource availability, compatibility, automation settings, and configured policies.

A VM-to-host affinity rule governs the relationship between a selected VM group and a selected host group. It does not directly describe whether two VMs should run together or apart.

  • VM DRS group: A named collection of virtual machines covered by a rule.
  • Host DRS group: A named collection of ESXi hosts that defines an allowed or prohibited host set.
  • VM-to-host rule: The policy linking the VM group and host group.

This differs from VM-to-VM affinity and anti-affinity rules. VM-to-VM affinity attempts to keep selected VMs together, while VM-to-VM anti-affinity attempts to separate them. VM-to-host rules instead control which hosts are eligible.

Required Rules Versus Preferential Rules

A required rule is a hard placement constraint. During normal DRS placement and migration decisions, DRS must honor it. A preferential rule is a soft preference: DRS tries to satisfy it but may violate it when resource availability, balancing, or recovery requires a different placement.

Enforcement level: Required rules are hard constraints; preferential rules are soft preferences.

Can DRS violate the preference: Required rules must not be violated during normal DRS decisions; preferential rules may be overridden.

Effect on host failure recovery: A required rule can prevent restart or migration when no compliant host remains. A preferential rule can be ignored if another host is needed.

Effect on load balancing: Required rules reduce the eligible host pool. Preferential rules generally leave DRS more flexibility.

Suitable use cases: Use required rules for strict licensing, hardware, security, or policy boundaries. Use preferential rules for a placement preference where availability and balancing are more important.

Operational risk: Required rules can create unavailable capacity and blocked maintenance. Preferential rules have lower availability risk but do not guarantee placement.

Required Rule Directions

There are two required VM-to-host directions. Verify the direction carefully before enabling the rule; selecting the opposite direction changes the eligible host set.

Must run on hosts in group: The VM group may run only on members of the selected host group. Hosts in the group are eligible; hosts outside it are disallowed. This is commonly used to restrict licensed workloads to licensed hosts.

Must run on hosts outside group: The VM group may run on hosts outside the selected host group. Members of the selected host group are prohibited destinations. This can keep general-purpose VMs away from hosts reserved for a special workload category.

Example: Licensed Application VMs

Suppose several application VMs require a software entitlement that applies only to selected ESXi hosts:

  1. Create a VM DRS group named Group A and add the application VMs.
  2. Create a host DRS group named ISV-Licensed and add only the hosts covered by the entitlement.
  3. Create a required VM-to-host rule stating that Group A must run on hosts in the ISV-Licensed group.

DRS can then place or migrate those VMs only among the licensed hosts. It cannot use an unlicensed host as a normal destination under that rule.

Configuring a Required VM-to-Host Rule

Configure the rule at the target cluster level. The exact labels can vary between vSphere Client versions, but the workflow is consistent.

  1. Open the target cluster and locate its DRS configuration.
  2. Ensure DRS is enabled. Review the cluster automation mode before relying on automatic migration actions.
  3. Create a VM DRS group and add every VM subject to the policy.
  4. Create a host DRS group and add the hosts that are allowed or prohibited.
  5. Add a VM-to-host rule and select the VM group and host group.
  6. Select the required direction: must run on hosts in group or must run on hosts outside group.
  7. Save the rule and confirm that it is enabled.
  8. Review current VM placement, rule compliance, DRS recommendations, tasks, and events.

Before changing production placement, test the configuration with non-production objects or a controlled migration. Confirm the group memberships and intended eligible-host set first.

Initial Placement, vMotion, and Load Balancing

Initial placement is the host selection process when a VM is powered on or restarted. DRS evaluates the required rules before selecting a destination. A host outside the permitted set is not a valid normal destination.

For automated DRS actions, recommendations or migrations must preserve required-rule compliance. This can limit balancing choices: a less-loaded host is not useful if it is outside the VM's eligible host set.

vMotion is the live migration of a running VM between compatible ESXi hosts. A manual migration to a destination that violates a required rule may be rejected or require an approved policy change, depending on the operation and vSphere behavior. Select a compliant destination and confirm that the host has sufficient resources and compatibility.

Host Failure and Capacity Consequences

Required rules make resilience dependent on the eligible host group, not merely on total cluster capacity. If every host allowed by an in-group rule fails, becomes disconnected, enters maintenance mode, or lacks sufficient resources, the affected VMs cannot be restarted or migrated to hosts outside that group.

For example, licensed hosts may fail while unlicensed hosts still have substantial free capacity. The protected VMs can nevertheless remain unavailable because the available hosts are noncompliant.

Plan N+1 or greater resilience within the eligible host group. A cluster-wide N+1 calculation is insufficient when a hard rule excludes part of the cluster. Consider host failures, maintenance capacity, admission control, reservations, compatibility, and simultaneous failure scenarios.

This behavior is separate from vSphere HA policy. HA may identify a restart target, but a required DRS placement constraint can leave no compliant target. Review admission control and the cluster's restart capacity together with the DRS rule design.

Maintenance Mode Planning

Maintenance mode is an ESXi host state used for servicing. Entering maintenance mode generally requires affected VMs to be evacuated or otherwise handled.

If a VM has a required in-group rule, evacuation can succeed only when another permitted host is available, compatible, connected, and sufficiently resourced. Maintenance may be blocked when the host group has too few remaining eligible hosts.

Before maintenance, verify:

  • Membership of the VM and host DRS groups.
  • Available capacity on every possible compliant destination.
  • DRS status, automation mode, and rule status.
  • Compatibility and connectivity of evacuation destinations.
  • Whether the remaining eligible hosts can tolerate the maintenance event and a subsequent failure.
  • Recovery options if evacuation cannot complete.

Rule Design Limitations and Conflicts

Rules combine with group membership and other cluster constraints. Overlapping VM groups, overlapping host groups, and multiple required rules can produce an unexpectedly small or empty eligible-host set.

  • A VM in multiple VM groups may be governed by several rules.
  • Required rules that point to different host sets may be incompatible.
  • Outside-group rules can interact with in-group rules and eliminate destinations.
  • Adding or removing a host from a group changes the eligible capacity immediately.
  • Removing a host from the cluster or editing group membership can make existing placements noncompliant or reduce recovery options.

Minimize overlapping hard rules. Document the intended policy, the eligible hosts, the reason for the constraint, the owner, and the capacity and failure assumptions. Re-evaluate the design after cluster membership changes or host-group edits.

Validation and Monitoring

Rule compliance indicates whether a VM's current host placement satisfies all applicable DRS rules. Validate the configuration at several levels:

  1. Verify that each protected VM is in the expected VM DRS group.
  2. Verify that each allowed or prohibited ESXi host is in the expected host DRS group.
  3. Map each VM to its eligible hosts after all applicable rules are considered.
  4. Confirm that every protected VM is currently running on a compliant host.
  5. Review DRS recommendations, tasks, events, and compliance indicators after rule changes, migrations, failures, and maintenance operations.
  6. Perform a controlled migration test before applying the rule to critical production workloads.

Operational Readiness Checklist

DRS enabled: DRS must be active before relying on its placement and migration behavior. Example verification: Review cluster DRS settings.

Correct VM group membership: Ensures the intended workloads are governed. Example verification: Compare the VM inventory with the VM DRS group.

Correct host group membership: Defines the actual eligible or prohibited hosts. Example verification: Audit host membership and host state.

Eligible-host capacity: Prevents power-on, restart, or evacuation failures. Example verification: Check usable CPU, memory, reservations, and compatibility on eligible hosts.

Failure-domain resilience: Keeps protected VMs recoverable after host failures. Example verification: Model N+1 capacity inside the eligible host group.

Maintenance evacuation path: Prevents blocked servicing operations. Example verification: Identify a compliant destination for every affected VM.

No conflicting rules: Avoids an empty or unexpectedly small host set. Example verification: Review all rules affecting each VM group.

Rule compliance monitoring: Detects drift and failed operations. Example verification: Review compliance indicators, tasks, events, and DRS recommendations.

Troubleshooting Required DRS Rules

A VM Cannot Be Powered On

Other cluster hosts may have free resources, but all hosts allowed by the required rule may be unavailable, incompatible, in maintenance mode, disconnected, or out of capacity. The VM may also be in an unexpected group.

  • Identify every required VM-to-host rule affecting the VM.
  • List the hosts in each applicable host group.
  • Check connectivity, maintenance state, compatibility, and usable capacity.
  • Review DRS events and placement messages.
  • Restore or add compliant capacity, correct group membership, or change the rule only through an approved operational and licensing process.

A Host Cannot Enter Maintenance Mode

A protected VM may have no other compliant destination, or the remaining permitted hosts may lack capacity.

  • Determine which VMs must be evacuated.
  • Validate capacity and eligibility on the remaining hosts in the relevant group.
  • Check for additional rules that further restrict destinations.
  • Provide another compliant host or free capacity within the allowed group before retrying.

DRS Does Not Balance to a Less-Loaded Host

The less-loaded host may be outside the VM's allowed group, or another required rule may make the migration noncompliant. Compare the VM's rules with the proposed destination and review DRS recommendations. Do not expect DRS to bypass a required rule for load balancing.

A Manual vMotion Is Rejected

Confirm the rule direction and the destination's host-group membership. Check all rules attached to the VM through its group memberships. Choose a compliant destination or correct the configuration only after confirming the intended policy.

Placement Behavior Seems Unexpected

The wrong VM group or host group may have been selected, the rule direction may be reversed, or overlapping groups may create a combined constraint.

  • Audit every group member and every DRS rule in the cluster.
  • Map the affected VM to its final eligible-host set.
  • Simplify conflicting hard rules, correct memberships or direction, and retest in a controlled environment.

When to Use a Required Rule

Use required VM-to-host rules when a strict constraint justifies reduced flexibility. Typical reasons include software licensing, hardware dependencies, security zoning, regulatory placement, or a host-specific operational policy.

Use preferential rules when workload availability, recovery, and resource balancing should take priority over the placement preference. If hard constraints apply to many workloads or leave too few eligible hosts, consider a dedicated cluster or another architecture that provides an adequately sized host pool.

A sound design treats every required rule as a capacity and availability boundary. The rule should have a documented purpose, verified group membership, tested migration behavior, and enough eligible-host capacity for normal operations, maintenance, and failure recovery.

Related Administration Topics