VMware ESXi and vSphere Cluster Management

Preferential VM-to-Host DRS Rules in VMware vSphere

Learn how preferential VM-to-host DRS rules map VM groups to preferred ESXi host groups, when vSphere may override them, and how they differ from required rules.

What Preferential VM-to-Host DRS Rules Do

vSphere Distributed Resource Scheduler (DRS) is a cluster service that recommends or performs virtual-machine placement and balancing actions. A VM-to-host affinity rule associates a group of virtual machines with a group of ESXi hosts.

A preferential rule is a soft placement policy. It tells DRS where a workload should preferably run, but it does not create an absolute placement boundary. In vSphere terminology, this behavior is commonly expressed as “should run on hosts in group.”

During normal operation, DRS attempts to place and retain the selected VMs on hosts in the preferred host group. If doing so would prevent recovery, reduce necessary cluster flexibility, or conflict with operational conditions, DRS may allow the VMs to run elsewhere.

VM Groups, Host Groups, and VM-to-Host Rules

VM-to-host rules are based on two named DRS groups. The rule does not directly target arbitrary placement decisions without those groups.

VM DRS group: A named collection of selected virtual machines.
Host DRS group: A named collection of selected ESXi hosts.
VM-to-host rule: A policy that maps one VM DRS group to one host DRS group.

For example, a VM group named Group A can be associated with a host group named Blade Chassis A. DRS then evaluates the placement of the VMs in Group A against the hosts in Blade Chassis A.

Membership is therefore fundamental. If a VM is not in the VM group, or a host is not in the host group, that VM-to-host rule does not define the intended relationship for that object.

How Preferential Placement Behaves

When the preferred hosts are healthy and eligible, DRS seeks to honor the rule during initial placement and automated migration decisions. It may recommend or perform vMotion to improve placement, depending on the cluster’s DRS automation settings and current resource conditions.

A preferential rule can be overridden when strict enforcement would negatively affect cluster operation. Examples include a host failure, insufficient capacity, maintenance evacuation, power-management state, or a migration and compatibility constraint.

At startup, DRS attempts to select a host from the preferred host group.
While a VM is running, DRS attempts to keep it in that group when the placement remains practical.
If no suitable preferred host is available, DRS can use another eligible host.
After the preferred domain becomes available again, DRS may later recommend a return migration rather than moving the VM immediately.

Example: Two Workload and Host Domains

Consider a cluster divided into two logical host domains:

VM Group A: virtual machines for one workload domain.
VM Group B: virtual machines for a second workload domain.
Blade Chassis A: the preferred ESXi hosts for Group A.
Blade Chassis B: the preferred ESXi hosts for Group B.

Configure these preferential rules:

Group A should run on hosts in Blade Chassis A.
Group B should run on hosts in Blade Chassis B.

VM DRS group: Group A; Preferred host DRS group: Blade Chassis A; Rule type: Should run; Normal goal: Keep Group A on Blade Chassis A; Failure behavior: Use eligible hosts in Blade Chassis B if necessary.
VM DRS group: Group B; Preferred host DRS group: Blade Chassis B; Rule type: Should run; Normal goal: Keep Group B on Blade Chassis B; Failure behavior: Use eligible hosts in Blade Chassis A if necessary.

During normal operation, DRS seeks to keep each VM group on its corresponding chassis. If all hosts in Blade Chassis A become unavailable, vSphere HA can restart affected Group A VMs on available hosts in Blade Chassis B. That placement violates the preference but preserves service availability. The same logic applies independently to Group B.

Why a Preferential Rule Can Be Violated

Host failure and vSphere HA

vSphere High Availability (HA) restarts affected virtual machines after an ESXi host failure. If the preferred host group is unavailable, HA and DRS can use another eligible host group. A soft rule must not prevent recovery when an alternate host can safely run the VM.

Capacity and resource balancing

A preferred group may lack enough CPU or memory for a VM, especially during a workload spike or after one or more hosts fail. DRS can choose an alternate host if that is necessary to keep the cluster operating or to satisfy resource placement requirements.

Maintenance mode

When preferred hosts enter maintenance mode, DRS may evacuate their VMs to hosts outside the preferred group. This is expected behavior for a soft rule when evacuation within the preferred domain is not possible.

Distributed Power Management

Distributed Power Management (DPM) can place hosts into or out of power-saving states according to demand. A preferred host may not currently be powered on or available for placement. DRS can therefore use another eligible host rather than waiting for the preferred host.

Migration and compatibility constraints

vMotion is the live migration technology DRS uses to move running VMs between hosts. CPU compatibility, network availability, storage connectivity, VM configuration, or another migration dependency can prevent a VM from moving to a preferred host.

Condition: Preferred host failure; Why DRS may deviate: No preferred host can run or recover the VM; Administrator response: Check host health and accept alternate placement during recovery.
Condition: Insufficient capacity; Why DRS may deviate: The preferred group cannot provide required CPU or memory; Administrator response: Review capacity, admission control, and workload demand.
Condition: Maintenance mode; Why DRS may deviate: Evacuation requires another destination; Administrator response: Confirm that the evacuation is expected and temporary.
Condition: DPM host state; Why DRS may deviate: A preferred host is powered down or unavailable through power management; Administrator response: Review DPM state and power policy.
Condition: Migration or compatibility constraint; Why DRS may deviate: vMotion or destination requirements are not satisfied; Administrator response: Check CPU, storage, network, and VM compatibility.

Do not use a preferential rule for an absolute licensing, hardware, security, or compliance boundary. If operation outside the designated hosts is unacceptable, the design requires a strict control or another enforcement mechanism rather than a soft preference.

Preferential Rules Versus Required Rules

A required rule is a hard placement policy. In vSphere terminology, it is commonly expressed as “must run on hosts in group.” The VM is required to run only on hosts in the designated host group.

Characteristic: Enforcement level; Preferential rule: Soft; DRS tries to honor it; Required rule: Hard; compliant placement is mandatory.
Characteristic: Behavior during host failure; Preferential rule: VMs can run on another eligible host group; Required rule: VMs cannot use a host outside the required group.
Characteristic: Effect on HA restart options; Preferential rule: HA retains more restart choices; Required rule: HA may have no compliant restart host.
Characteristic: Effect during maintenance; Preferential rule: DRS may evacuate VMs outside the preferred group; Required rule: evacuation or startup can be blocked if no compliant host exists.
Characteristic: Best-fit use cases; Preferential rule: Chassis locality, performance preference, or normal operating separation; Required rule: Enforced licensing, hardware, security, or regulatory placement.
Characteristic: Risk when compliant hosts are unavailable; Preferential rule: Temporary rule deviation; Required rule: VM startup or restart may fail.

Choose a preferential rule when the workload benefits from a host domain but can safely operate elsewhere during failure, maintenance, or capacity pressure. Choose a required rule only when running outside the host group is unacceptable and the organization accepts reduced recovery and maintenance flexibility.

Planning and Design Considerations

Verify that every preferred host has sufficient CPU and memory capacity for its assigned workloads.
Confirm storage connectivity, network connectivity, device access, and compatibility for both normal placement and failover destinations.
Plan for N+1 capacity when the preferred host domain must tolerate the loss of one host. N+1 means that the domain has enough spare capacity to continue after one host fails.
Ensure the fallback host group can support recovery when the preferred group is unavailable.
Confirm vMotion compatibility and shared datastore access, or another supported migration design, across all potential destinations.
Avoid overlapping or contradictory VM group memberships and rules unless their combined effects are fully understood.
Consider maintenance mode: a preferential policy can intentionally allow evacuation outside the preferred domain.
Use names that communicate intent, such as Payments-VMs, Chassis-A-Hosts, or Licensed-Hosts.
Review HA admission control and available capacity against the planned host-failure scenario.

Configuration Workflow in the vSphere Client

Open the target cluster and verify that DRS is enabled.
Confirm that your account has the privileges needed to configure cluster DRS groups and rules.
Open the cluster configuration area for VM/Host Groups.
Create or edit a VM DRS group and add the target virtual machines.
Create or edit a host DRS group and add the preferred ESXi hosts.
Open VM/Host Rules and add a new VM-to-host rule.
Select the VM group and the host group.
Choose the preferential should-run behavior rather than the required must-run behavior.
Enable the rule and save the configuration.
Review the rule status, DRS recommendations, and automation settings after implementation.

Configuration checklist

DRS is enabled on the cluster.
Normal and fallback hosts meet compute, storage, network, and compatibility requirements.
HA admission control supports the intended failure scenario.
The preferred host group has sufficient normal-operation capacity.
The fallback host group can support recovery if the preferred group is unavailable.

Monitoring and Operational Validation

After configuring the rule, check rule compliance and rule-related recommendations in the vSphere Client. A VM outside its preferred group is not automatically evidence of a configuration error.

First determine whether the deviation is temporary and operationally justified. Review:

Preferred host availability and connection state.
Host capacity and current resource demand.
Maintenance mode status.
DPM power state and host availability.
VM and host DRS group membership.
vMotion compatibility, datastore access, network access, and other migration constraints.
DRS recommendations, events, automation level, and migration thresholds.

If preferred hosts have recovered, DRS may not immediately move every VM back. The cluster may not gain enough benefit from a migration, automation settings may limit the action, or another rule or resource condition may take priority. A recommended or manually initiated vMotion should be evaluated only after confirming that the destination is healthy and eligible.

Troubleshooting Common Symptoms

A VM is running outside its preferred host group

Likely causes include failed, disconnected, powered-down, or maintenance-mode preferred hosts; insufficient capacity; a migration constraint; or an intentional override of the soft rule.

Review rule compliance and DRS events or recommendations.
Check preferred host availability, maintenance state, capacity, and DPM state.
Verify VM and host group membership.
Confirm that the intended hosts can run the VM and support its migration path.

Restore eligible preferred-host capacity or accept the temporary deviation. Change to a required rule only after evaluating its effect on HA recovery and maintenance.

DRS does not immediately move a VM back after recovery

The return migration may offer insufficient benefit, lack a safe migration path, be limited by automation settings or migration thresholds, or conflict with current resource demand and other rules.

Review DRS automation and pending recommendations.
Check current utilization and interacting rules.
Confirm that the preferred hosts are healthy and eligible.

Allow DRS to rebalance when appropriate, or evaluate a recommended or manual vMotion after checking for competing constraints.

A required rule prevents VM startup after a host-group outage

The usual cause is that no compliant host remains in the required host group. Verify whether strict placement is genuinely required, review the host-group outage and HA restart constraints, and restore or add a compliant host if policy allows. If operation outside the group is acceptable, redesign the rule as preferential.

Exam-Relevant Notes

Should run on hosts in group means preferential or soft placement.
Must run on hosts in group means required or hard placement.
A preferential rule may be violated to preserve availability, capacity, or operational flexibility.
After a host failure, HA can restart VMs outside their preferred host group when the preferred group is unavailable.
Required rules can reduce HA restart options and can prevent startup when no compliant host exists.
VM-to-host rules depend on VM DRS groups and host DRS groups; membership defines which objects the policy affects.

Summary

Preferential VM-to-host DRS rules guide normal placement by associating a VM DRS group with a preferred host DRS group. DRS attempts to honor the association during placement and balancing, but it can override the preference for host failure recovery, capacity, maintenance evacuation, DPM state, or migration compatibility. Use preferential rules for desirable locality or normal operating placement. Use required rules only for boundaries that must be enforced, understanding that strict placement can prevent VM startup or HA restart when compliant hosts are unavailable.

For related policy design, see Preferential DRS Rules.