VMware ESXi and vSphere Cluster Management

Required VM-Host DRS Rules in VMware vSphere

Learn how required VM-host DRS rules restrict virtual machines to approved ESXi hosts, including configuration, licensing, availability, maintenance, and troubleshooting.

A required VM-host rule creates a strict placement boundary for selected virtual machines. It tells vSphere Distributed Resource Scheduler (DRS) that the VMs may run only on hosts in a specified host DRS group.

This design is useful when workloads must remain on particular physical hosts, such as hosts with the required software licenses. It also creates an availability trade-off: capacity outside the permitted host group cannot be used while the required rule remains active.

This lesson assumes familiarity with vSphere clusters, ESXi hosts, virtual machines, DRS, vMotion, resource capacity, and maintenance mode.

What a VM-host DRS rule does

vSphere Distributed Resource Scheduler (DRS) is a cluster service that places workloads and makes migration decisions to help balance resources. A VM-host affinity rule adds a placement policy to those decisions.

A VM-host rule determines which ESXi hosts may or should run a defined group of VMs. The rule is implemented by connecting two named groups:

  • VM DRS group: A named group of virtual machines subject to the policy.
  • Host DRS group: A named group of ESXi hosts that are authorized or preferred for those VMs.

The rule then defines the relationship between the groups. The common behaviors are must run on hosts in group and should run on hosts in group.

VM-host rules versus VM-to-VM rules

VM-host rules control placement between virtual machines and physical ESXi hosts. VM-to-VM affinity and anti-affinity rules control placement between virtual machines.

  • A VM-host affinity rule can keep application VMs on licensed or specially equipped hosts.
  • A VM-to-VM affinity rule can keep related VMs together.
  • A VM-to-VM anti-affinity rule can keep selected VMs apart, such as redundant application nodes.

These policies can coexist, but their combined constraints can reduce the set of eligible hosts. Review them together when diagnosing placement or evacuation problems.

Required versus preferential placement

A required rule is an enforced VM-host placement rule. When a VM belongs to the governed VM DRS group, a host outside the specified host DRS group is not eligible under that rule. DRS will not move the VM there merely to improve cluster balance.

A preferential rule is a best-effort placement preference. DRS normally favors the specified host group, but may override the preference when necessary to preserve availability or satisfy other operational conditions.

Rule behavior: Must run on hosts in group

Placement requirement: Strictly confines the VM group to the specified host group.

Can DRS place the VM outside the host group? No, not while the required rule is active and applicable.

Best use cases: Non-negotiable licensing, hardware, regulatory, or physical-placement constraints.

Availability impact: Capacity outside the host group cannot be used for the governed VMs.

Rule behavior: Should run on hosts in group

Placement requirement: Favors the specified host group but permits an exception when needed.

Can DRS place the VM outside the host group? Yes, when operational conditions require it.

Best use cases: Performance locality or preferred placement where availability has priority.

Availability impact: Provides an escape path to other eligible hosts, but may not satisfy a hard licensing or regulatory restriction.

How required rules affect DRS decisions

DRS considers required VM-host rules during initial VM placement and during automated migration recommendations or actions. A governed VM can be placed on, or migrated to, an eligible host in its assigned host group when other requirements are satisfied.

A host outside the permitted group is ineligible for that VM under the rule. DRS therefore will not migrate the VM there just because the host has spare CPU or memory. This remains true during normal balancing and during migration workflows supported by the vSphere environment.

A required rule does not override every other placement condition. The destination must also be operationally suitable, with adequate CPU and memory capacity, compatibility, networking, storage access, and any required vMotion capabilities. Reservations, limits, other DRS rules, and host state can further restrict placement.

Eligible hosts

An eligible host is a host that is permitted by active placement rules and has sufficient operational capacity and compatibility to run the VM. For a VM governed by a required VM-host rule, membership in the host DRS group is a necessary condition, not a guarantee that placement will succeed.

Designing a required VM-host rule

  1. Identify every workload that must obey the restriction.
  2. Create a VM DRS group containing those virtual machines.
  3. Create a host DRS group containing only the authorized ESXi hosts.
  4. Create a VM-host DRS rule connecting the VM group and host group.
  5. Select the required behavior equivalent to must run on hosts in group.
  6. Enable the rule.
  7. Review group membership, rule state, and compliance before relying on the policy in production.

Object type: VM DRS group

Example name: Group A

Members: Application VMs requiring licensed hosts

Purpose: Identifies the restricted workloads.

Object type: Host DRS group

Example name: ISV-Licensed

Members: ESXi hosts carrying the required independent software vendor licenses

Purpose: Defines the permitted execution hosts.

Object type: VM-host rule

Example name: Group A must run on ISV-Licensed

Members: Group A and ISV-Licensed

Purpose: Enforces licensed-host placement.

vSphere Client workflow

  1. Open the target DRS-enabled cluster in the vSphere Client.
  2. Create a VM DRS group and add all affected virtual machines.
  3. Create a host DRS group and add only the authorized ESXi hosts.
  4. Create a VM-host affinity rule using the two groups.
  5. Choose the required behavior that requires the VM group to run on hosts in the host group.
  6. Enable the rule and verify its compliance state.

Exact menu names can vary between vSphere releases and Client layouts. The important configuration elements are the VM group, host group, VM-host relationship, required behavior, and enabled state.

Host-based licensing example

Host-based licensing is a licensing model in which software rights depend on the physical ESXi host where a workload runs. If only certain hosts are licensed for an application, the application VMs must not run on other hosts.

Consider a six-host cluster in which only two ESXi hosts are licensed for a third-party application:

  1. Create a VM DRS group named Group A containing the application VMs.
  2. Create a host DRS group named ISV-Licensed containing only the two licensed hosts.
  3. Create a required VM-host rule stating that Group A must run on hosts in ISV-Licensed.

DRS can balance or migrate the application VMs between the two licensed hosts, subject to capacity and compatibility. It cannot place them on the other four hosts because those hosts are outside the permitted host group.

This technical configuration supports placement control, but licensing interpretation and compliance obligations should also be confirmed with the software vendor and the organization’s compliance team.

Availability and failure consequences

Strict enforcement reduces the number of hosts available to the affected VMs. This is the central trade-off between compliance enforcement and workload availability.

If every host in the permitted host group fails or becomes unavailable, the governed VMs cannot be relocated to other cluster hosts while the required rule remains in force. Free capacity elsewhere in the cluster does not make those hosts eligible.

Event: Normal balancing

Expected DRS behavior: The VM remains within its allowed host group.

Administrator consideration: Ensure the group has enough compute capacity for normal demand.

Event: An allowed host enters maintenance mode

Expected DRS behavior: VMs can move only to another allowed host.

Administrator consideration: Validate evacuation capacity before starting maintenance.

Event: All allowed hosts are unavailable

Expected DRS behavior: VMs cannot be placed on non-member hosts.

Administrator consideration: Plan redundant eligible capacity or a controlled emergency exception.

Capacity planning must cover normal operations, intended host failures, maintenance evacuation, restart or failover requirements, and temporary workload peaks. A design with only one permitted host may satisfy placement policy but provide little or no host-level resilience.

Maintenance and operational planning

  • Plan enough licensed and eligible hosts to tolerate the host failures and maintenance scenarios defined by the availability design.
  • Before placing a host into maintenance mode, verify that the remaining permitted hosts can accommodate every governed VM.
  • Confirm that reservations, resource pools, limits, compatibility, storage, networking, and other rules will not prevent evacuation.
  • Use admission control and capacity planning consistent with the cluster’s vSphere HA and failover objectives.
  • Review the rule and group membership after adding, removing, replacing, or relicensing hosts.
  • Document who may change the rule during a licensing or availability emergency.
  • Document the required licensing and compliance checks after any emergency exception or temporary rule change.

A controlled exception process should specify authorization, incident recording, the permitted duration, the compliance impact, and the steps for restoring the required rule.

Validation and monitoring

Validate the policy before using it for critical workloads. A configuration checklist should include:

  • DRS is enabled for the target cluster.
  • The VM DRS group contains every workload requiring the restriction.
  • The host DRS group contains only hosts permitted by the licensing or placement policy.
  • The VM-host rule is enabled.
  • The behavior is required, not preferential.
  • Eligible hosts have enough capacity for planned failures and maintenance.
  • No unintended conflict exists with other placement policies.

For each governed VM, check its current ESXi host and confirm that the host belongs to the intended host DRS group. Review DRS recommendations, rule compliance status, and migration failures for indications of insufficient eligible capacity or conflicting policies.

Before production use, test a controlled vMotion or maintenance workflow. Confirm that the VM can move between appropriate members of the allowed host group and that an unauthorized host is rejected or excluded from the operation.

Choosing a preferential rule instead

Use should run on hosts in group when the preferred hosts provide better locality, performance, or administrative convenience, but the workload is legally and technically allowed to run elsewhere during an outage.

Preferential behavior may allow a VM to run outside the preferred group. That makes it unsuitable for hard software licensing, regulatory, hardware, or security requirements unless the exception is explicitly acceptable.

  • Choose required: The VM must never run outside the authorized host set.
  • Choose preferential: The VM should normally use the preferred host set, but availability may override the preference.

Troubleshooting required-rule behavior

A VM cannot migrate to a host with spare capacity

The destination host may not be a member of the host DRS group required by the VM-host rule.

  1. Check the VM’s membership in VM DRS groups.
  2. Check the destination host’s membership in host DRS groups.
  3. Review the VM-host rule’s enabled state and behavior.
  4. Check compatibility, reservations, resource limits, storage, networking, and other placement policies.

Use an eligible host, add an appropriately licensed host to the allowed group, or follow the approved exception process before changing the rule.

A host cannot enter maintenance mode

Governed VMs may be unable to evacuate because the remaining hosts in their permitted group lack capacity or are unavailable.

  1. Identify all VMs on the host that are governed by required rules.
  2. Check the availability and capacity of other hosts in the same allowed group.
  3. Review reservations, limits, compatibility, storage, networking, and additional affinity rules.

Restore or add eligible capacity, reduce demand, schedule maintenance differently, or make a controlled policy change only when authorized.

DRS does not move a VM to improve balance

The hosts that would improve balance may be outside the VM’s required host group. Review DRS recommendations and rule compliance information, then confirm which hosts are eligible.

Accept the constrained placement, expand the authorized host group if compliant, or use a preferential rule only if strict enforcement is unnecessary.

A workload is unavailable even though other hosts have free capacity

All hosts allowed by the required rule may be unavailable, while the hosts with free capacity are outside the permitted group.

Determine whether any permitted host remains operational. Confirm that the rule is preventing placement on other hosts, then assess the licensing and policy implications before overriding the constraint. Recover eligible hosts, provide redundant licensed capacity, or invoke the documented emergency exception process if organizational policy permits it.

Exam-relevant notes

  • A VM-host rule connects a VM DRS group to a host DRS group.
  • Must run on hosts in group is the strict, required behavior.
  • Should run on hosts in group is the best-effort, preferential behavior.
  • DRS does not use an outside host for a governed VM merely to improve resource balance when the rule is required.
  • A required rule can prevent failover or evacuation to otherwise available hosts.
  • Host-group capacity must support normal operation, maintenance, and planned failure scenarios.

For a related summary of the configuration pattern, see Required DRS rules.