VMware ESXi and vSphere Cluster Management

Preferential VM-to-Host DRS Rules in VMware vSphere

Learn how preferential VM-to-host DRS rules guide VM placement, when vSphere can override them, and how to design resilient VM and host groups.

A preferential VM-to-host Distributed Resource Scheduler (DRS) rule expresses where selected virtual machines should normally run in a vSphere cluster. It guides placement without making the preferred location an absolute requirement.

This distinction is important when a workload benefits from a particular host pool, blade chassis, or hardware domain but must still be able to start, recover, or migrate elsewhere during failures, maintenance, or resource pressure.

Prerequisites and key terms

These rules are configured at the vSphere cluster level. They are not properties of an individual ESXi host. The cluster must be managed by vCenter Server, and DRS must be enabled.

• DRS: Distributed Resource Scheduler, the vSphere service that helps place and balance virtual machines across hosts in a cluster.
• VM-to-host DRS rule: A cluster rule that associates a VM group with an ESXi host group for placement control.
• VM group: A named collection of virtual machines used by a DRS rule.
• Host group: A named collection of ESXi hosts used as the preferred or permitted placement scope.
• Initial placement: Host selection when a VM is powered on.
• vMotion: Live migration of a running VM from one ESXi host to another.
• VMware HA: High Availability, which restarts affected VMs on surviving hosts after a host failure.
• DPM: Distributed Power Management, which can consolidate workloads and place hosts into or out of power-saving states.

For background, review the vSphere and ESXi course, HA admission control concepts, and communication between vCenter Server and ESXi.

Purpose of VM-to-host DRS rules

VM-to-host rules connect a workload group to a host group. They are useful when placement has operational meaning, such as keeping application VMs near a particular hardware pool, maintaining locality within a blade chassis, or separating workloads between infrastructure domains.

The two building blocks make the design scalable:

1. Create a VM group containing the VMs that share a placement objective.
2. Create a host group containing the ESXi hosts that provide the preferred or permitted destination.
3. Create a VM-to-host rule associating the two groups.

Because the rule belongs to the cluster, DRS can consider it during power-on placement, balancing decisions, vMotion migrations, maintenance operations, and recovery workflows. Adding or removing hosts from a host group changes the placement scope for all associated rules.

What a preferential rule means

A preferential rule is a soft placement preference. DRS attempts to keep the VMs in the associated host group during initial placement and load-balancing migrations when cluster conditions allow.

For example, a rule can express:

VM Group A should preferably run on hosts in Blade Chassis A.

Under normal conditions, DRS tries to satisfy that preference. If the preferred hosts are unavailable, full, incompatible, or otherwise unsuitable, vSphere can select an eligible host outside the preferred group.

A soft rule therefore provides locality without converting that locality into a service availability barrier.

Why vSphere can violate a preferential rule

Leaving the preferred group is not automatically a configuration failure. vSphere can override a soft preference when doing so is necessary to preserve or improve overall cluster operation.

DRS balancing

DRS may move a VM outside its preferred group if cluster balancing requirements make that the better operational choice. Resource contention, uneven utilization, or a lack of suitable capacity can make strict preference impractical.

VMware HA recovery

After a host failure, HA must restart affected VMs on surviving, eligible hosts. If the preferred host group is unavailable, HA and DRS may use another host group. Availability takes precedence over a soft placement preference.

HA admission control helps reserve capacity for recovery, but it does not make a preferential rule a guarantee that every VM will remain in its preferred group. See HA admission control policies for related planning considerations.

DPM decisions

DPM can consolidate workloads and power hosts down or up. A soft VM-to-host preference may be overridden if DPM needs to consolidate VMs, wake a different host, or maintain an operationally viable cluster.

Maintenance and resource constraints

When preferred hosts enter maintenance mode or do not have enough CPU or memory, DRS may evacuate a VM to a compatible host outside the preferred group. This can avoid an unnecessary outage.

Preferential versus required VM-to-host rules

A required rule is a hard constraint. It does not allow the associated VM group to run outside the specified host group. A preferential rule allows exceptions when vSphere needs flexibility for balancing, maintenance, power management, or recovery.

Design example: two blade chassis

Consider a cluster containing two host pools that represent separate blade chassis:

• VM Group A: VMs for workload A.
• VM Group B: VMs for workload B.
• Blade Chassis A: ESXi hosts in the first chassis.
• Blade Chassis B: ESXi hosts in the second chassis.

Create two preferential associations:

1. Associate VM Group A with Blade Chassis A.
2. Associate VM Group B with Blade Chassis B.

In steady state, each group normally runs in its corresponding chassis. If all hosts in Blade Chassis A become unavailable, Group A VMs can be restarted or moved to Blade Chassis B. That exception is the intended benefit of a preferential rule.

Configuring the rule in vSphere Client

1. Open the target cluster in vCenter Server.
2. Confirm that DRS is enabled for the cluster.
3. Create the required VM groups, such as VM Group A and VM Group B.
4. Add the appropriate virtual machines to each VM group.
5. Create the host groups, such as Blade Chassis A and Blade Chassis B.
6. Add the appropriate ESXi hosts to each host group.
7. Create a VM-to-host DRS rule for each association.
8. Choose the rule mode that expresses a preference for the designated host group rather than a required placement restriction.
9. Use names that make the relationship obvious, such as Prefer Group A on Blade Chassis A.
10. Review the rule status and confirm that normal placement matches the design.

Interface labels can vary by vSphere release, but the configuration concepts remain the same: cluster, VM group, host group, VM-to-host rule, and enforcement mode.

Design considerations before creating rules

• Maintenance: Determine where VMs can run while the preferred hosts are evacuated.
• Host failure: Model the loss of an entire host group, not only the loss of one host.
• Capacity: Keep enough CPU and memory outside the preferred group for the required failure scenario.
• Infrastructure dependencies: Confirm that alternate hosts can access the VM datastores and required networks.
• Compatibility: Check CPU compatibility, virtual hardware support, passthrough dependencies, and other host-specific requirements.
• Rule interactions: Review other VM-to-host rules, VM-to-VM rules, admission control settings, and VM-specific constraints.
• Documentation: Record the purpose of each rule and the expected behavior when the preference cannot be met.

Capacity and resilience planning

A soft rule does not itself guarantee successful failover. It only avoids imposing a hard placement restriction. The alternate host group must still be capable of running the displaced workloads.

N+1 planning means retaining enough capacity to lose one planned failure unit, such as one host. If the design requirement is loss of an entire blade chassis, calculate N+1 capacity at the chassis level instead. A second chassis may need to run both its normal workload and the displaced workload from the failed chassis.

Operational validation

Verify normal placement

1. Inspect the hosts currently running the VMs in each VM group.
2. Compare their locations with the preferred host group.
3. Review the rule status in the cluster configuration.
4. Check DRS recommendations and recent migrations when a VM is outside its preferred group.

A VM outside its preferred group can be an expected result when the preferred hosts lack capacity, are in maintenance mode, have failed, or cannot provide required storage or networking.

Validate exception behavior

Use a controlled maintenance or failure exercise within change-control procedures. Place preferred hosts into maintenance mode, or model the loss of the preferred host group, and confirm that alternate hosts are compatible and have sufficient capacity.

For a recovery test, verify that HA can restart the VMs on the alternate group and that application, storage, and network services work after restart. Restore the preferred capacity and confirm that DRS can recommend or perform movement back according to the cluster's automation settings.

Troubleshooting

A VM is running outside its preferred host group

• Check whether preferred hosts are unavailable or in maintenance mode.
• Review CPU and memory usage in the preferred group.
• Review recent HA events and DRS recommendations or migrations.
• Confirm the VM group, host group, and rule membership.
• Verify that preferred hosts provide the required storage, networks, and compatibility.

The rule does not keep workloads on the intended chassis during normal operations

• Confirm that the correct VM group and host group are associated.
• Check that every intended ESXi host is in the correct host group.
• Confirm that the rule is enabled and uses the preferential mode.
• Verify that DRS is enabled and functioning for the cluster.
• Inspect resource headroom and destination compatibility in the preferred group.

Workloads cannot restart on alternate hosts

• Confirm shared datastore visibility from the alternate hosts.
• Check required port groups, VLANs, and VMkernel networking.
• Verify CPU compatibility and virtual hardware support.
• Check whether reserved capacity is sufficient after the modeled failure.
• Review other hard constraints or compatibility issues that may block placement.
• Test the planned maintenance and recovery path under controlled conditions.

Exam-relevant notes

• A preferential VM-to-host rule is a soft preference, not a hard boundary.
• A required VM-to-host rule is a hard constraint and can prevent power-on, migration, or HA restart when no permitted host is available.
• VM groups and host groups are cluster-level DRS objects.
• HA recovery, DRS balancing, maintenance evacuation, and DPM can justify violating a preferential rule.
• Alternate placement works only when fallback hosts have adequate capacity, storage, networking, and compatibility.
• A VM temporarily outside its preferred group is not necessarily evidence of a broken rule.

Summary

Preferential VM-to-host DRS rules express normal placement intent while preserving operational flexibility. Use VM groups and host groups to associate workloads with preferred ESXi host pools, such as separate blade chassis. DRS normally honors those associations, but HA recovery, balancing, DPM, maintenance, and resource constraints can cause exceptions.

When availability and recovery capacity matter more than strict isolation, preferential enforcement is usually the appropriate choice. Validate the design by checking alternate-host capacity, datastore access, networks, CPU compatibility, and HA or DRS behavior before relying on it in production.