VMware ESXi and vSphere Cluster Management

Create a VM-to-Host DRS Rule in VMware vSphere

Learn how to create VM and host DRS groups and configure a VMware vSphere VM-to-host rule for mandatory or preferred VM placement.

A VMware DRS VM-to-host rule controls which ESXi hosts are eligible to run selected virtual machines within a DRS cluster. This is useful when a workload must remain on licensed hardware, requires a particular host capability, or must stay within a security or compliance boundary.

What a VM-to-Host DRS Rule Does

VMware DRS, or Distributed Resource Scheduler, is a vSphere cluster feature that evaluates virtual machine placement and cluster load. A VM-to-host rule associates a VM DRS group with a host DRS group and applies a placement policy to that association.

A VM DRS group contains one or more virtual machines. A host DRS group contains one or more ESXi hosts. The rule then controls whether the VMs must, should, must not, or should not run on those hosts.

This is different from VM-to-VM affinity and anti-affinity rules:

  • VM-to-host rules control where VMs may run in relation to ESXi hosts.
  • VM-to-VM affinity rules prefer or require selected VMs to run together.
  • VM-to-VM anti-affinity rules prefer or require selected VMs to run on different hosts.

Common reasons to use VM-to-host rules include:

  • Keeping licensed application VMs on hosts covered by a software license.
  • Placing workloads near required hardware, such as GPU-capable hosts.
  • Maintaining security, compliance, or data-location boundaries.
  • Assigning dedicated hosts to a workload or business unit.
  • Ensuring a VM runs only where required CPU, memory, device, or other host capabilities are available.

Requirements and DRS Behavior

VM-to-host rules are configured at the cluster level and require VMware DRS to be enabled for the target cluster. The cluster must contain the VMs and ESXi hosts used by the groups.

DRS evaluates placement and may generate a DRS recommendation, which is a suggested placement or migration action. Depending on the cluster automation setting, DRS may:

  • Recommend a migration for an administrator to approve.
  • Automatically perform a vMotion migration.
  • Evaluate the rule but defer action when no suitable placement is available.

vMotion is the live migration mechanism that moves a running VM between compatible ESXi hosts. A rule cannot create a valid placement where the underlying infrastructure does not support one. Suitable hosts must be connected, available, and able to run the VM.

Before creating a mandatory rule, verify the following:

  • Cluster DRS is enabled and its automation behavior is understood.
  • Eligible hosts have sufficient CPU, memory, and other required capacity.
  • vMotion networking is configured between possible source and destination hosts.
  • Hosts can access the VM's storage, or otherwise meet the storage requirements for migration.
  • Host CPU compatibility, virtual hardware, attached devices, networking, and other VM restrictions permit migration.
  • Other DRS rules, reservations, admission controls, or maintenance operations do not create a conflict.

DRS Group Types

Group typeContainsUsed forExample
VM DRS groupOne or more virtual machinesIdentifies the workloads controlled by a ruleLicense-Controlled-VMs
Host DRS groupOne or more ESXi hostsIdentifies the hosts allowed, preferred, or excluded by a ruleLicensed-ESXi-Hosts

Groups simplify administration. You can add or remove a VM or host from a group without redesigning the rule itself. However, membership changes can immediately change placement eligibility, so review the resulting impact before saving.

Pre-Implementation Checklist

CheckWhy it mattersHow to verify
DRS enabledVM-to-host rules are DRS cluster features.Select the cluster and review its DRS configuration.
Eligible hosts availableA mandatory rule needs at least one valid destination host.Review host connection state, availability, and maintenance state.
Adequate capacityEvery permitted host must be able to run the assigned VMs.Check CPU, memory, reservations, admission control, and failover capacity.
vMotion readinessDRS may need to migrate a running VM to enforce or improve placement.Verify vMotion networking and host-to-host compatibility.
Storage and VM compatibilityStorage access, devices, and VM configuration can prevent migration.Check datastore access, attached devices, CPU compatibility, and networking.
No conflicting rulesMultiple constraints can make a placement impossible.Review other DRS rules, VM restrictions, reservations, and host policies.

Create the VM DRS Group

  1. Select the target DRS cluster in the vSphere Client.
  2. Open the cluster's configuration or management settings.
  3. Locate the DRS groups section. Depending on the vSphere release, it may be labeled VM/Host Groups or similar.
  4. Choose to create a new group and select the VM group type.
  5. Enter a clear administrative name, such as License-Controlled-VMs or GPU-Workloads.
  6. Add every VM that the placement policy applies to.
  7. Save the group.
  8. Reopen or review the finished group and verify that all intended VMs appear as members.

Use names that describe the workload or business purpose rather than an unclear name such as Group1. A well-named group makes later audits and troubleshooting easier.

Create the Host DRS Group

  1. Remain in the same target cluster's DRS group settings.
  2. Create another group and select the host group type.
  3. Give it a name based on its placement purpose or host class, such as Licensed-ESXi-Hosts, GPU-Capable-Hosts, or Host-Group-A.
  4. Add one or more eligible ESXi hosts.
  5. Verify that each member is connected, not unintentionally in maintenance mode, and capable of running the VM group.
  6. Save the group and review its membership.

For a mandatory policy, include enough hosts to support normal load, host failures, and planned maintenance. A group with only one host may satisfy the rule during normal operation but create a serious availability and maintenance constraint.

Create the VM-to-Host Rule

  1. Open the target cluster's DRS rule settings.
  2. Choose to add a rule.
  3. Enter an unambiguous name that states both the workload and the placement policy, such as License-Controlled-VMs-Must-Run-on-Licensed-Hosts.
  4. For the rule type, choose Virtual Machines to Hosts.
  5. Select the VM DRS group created earlier.
  6. Select the host DRS group created earlier.
  7. Choose the required placement policy.
  8. Enable the rule.
  9. Save the rule.

Exact labels and available options vary by vSphere release. The important distinction is whether the rule is mandatory or preferential.

VM-to-Host Rule Policy Comparison

PolicyPlacement meaningEnforcement levelTypical use caseOperational risk
Must run on hosts in groupVMs in the VM group are required to run on hosts in the selected host group.MandatoryLicensed hosts, strict compliance boundary, or required hardware.Can prevent placement, vMotion, or maintenance when no eligible host has capacity.
Should run on hosts in groupDRS attempts to place the VMs on hosts in the selected host group.PreferentialPreferred hardware locality or a workload placement preference.DRS may leave or move a VM elsewhere when needed.
Must not run on hosts in groupVMs in the VM group are excluded from the selected host group.MandatoryKeeping workloads away from restricted or unsuitable hosts.Reduces the available host pool and can make placement impossible.
Should not run on hosts in groupDRS prefers not to place the VMs on the selected hosts.PreferentialAvoiding a host class when practical.The preference can be overridden during contention or other constraints.

Practical Examples

Licensed Application Hosts

Create a VM group named License-Controlled-VMs and a host group named Licensed-ESXi-Hosts. Use Must run on hosts in group. The application VM can then run only on hosts allocated for that software license.

Preferred GPU-Capable Hosts

Create GPU-Workloads and GPU-Capable-Hosts. Use Should run on hosts in group when those hosts are preferred but the workload can operate elsewhere if necessary. This preserves more DRS flexibility than a mandatory rule.

Correcting an Incorrect Placement

Suppose Linux-Application-VMs must run on Host-Group-A, but one member is currently running outside that group. With a Must run on hosts in group rule, DRS can report the placement problem or recommend migration to an eligible host in Host-Group-A. Whether migration occurs automatically depends on DRS automation and the availability of a compatible destination.

Validate and Monitor the Rule

  1. Open the cluster monitoring area and review DRS recommendations.
  2. Look for a recommendation or migration involving a VM whose current host does not satisfy the intended placement.
  3. Apply the recommendation if the cluster is operating in a mode that requires administrator approval.
  4. Confirm the VM's current host after DRS acts or the recommendation completes.
  5. Review the rule's compliance status.
  6. Inspect cluster events and task details for the rule, VM, source host, destination host, and any failure reason.

Rule compliance indicates whether the current VM placement satisfies the configured rule. A compliant rule does not necessarily mean that the VM is optimally balanced; it means the placement constraint is currently satisfied.

Operational Impacts and Safe Administration

Restrictive rules reduce the number of hosts DRS can use. This can affect load balancing, maintenance, failover planning, and availability. Before enabling a mandatory rule, plan sufficient capacity across every host allowed by the rule, including capacity for a host failure where required by your service-level objectives.

  • Review VM group membership when deploying new VMs or changing workload ownership.
  • Review host group membership when adding hosts, retiring hosts, changing hardware classes, or changing licensing boundaries.
  • Document the business reason, technical owner, and review date for each mandatory rule.
  • During host maintenance, confirm that another eligible host has capacity before evacuating a host.
  • Temporarily modify or disable a rule only through an approved operational process when maintenance would otherwise leave no valid placement.
  • After maintenance, restore the intended rule state and verify compliance.

Troubleshooting

The Host Group Cannot Be Selected

Common causes are that the corresponding group was not created, the wrong group type was used, or the administrator is editing a different cluster.

  • Confirm both groups exist under the same DRS cluster.
  • Confirm the VM group contains VMs and the host group contains ESXi hosts.
  • Recreate an incorrectly typed group if necessary.

DRS Does Not Migrate a VM for a Preferred Placement

A should rule is preferential, not mandatory. DRS may also be operating in manual or partially automated mode, may lack a compatible target host, or may be resolving another constraint.

  • Review the rule's policy and enabled state.
  • Review DRS recommendations and the cluster automation setting.
  • Check target-host capacity, connectivity, maintenance state, vMotion readiness, storage access, and compatibility.
  • Review other DRS rules and VM-specific restrictions.

A Mandatory Rule Prevents Maintenance

The host group may contain too few hosts, all eligible hosts may be unavailable or in maintenance mode, or the VM may have a storage, device, network, or compatibility limitation.

  • Add an appropriately capable host to the host group where policy permits.
  • Restore an eligible host to service or provide additional capacity.
  • Schedule maintenance with a temporary, approved rule adjustment.
  • Resolve VM portability limitations before relying on DRS migration.

A VM Runs on an Unexpected Host

  • Verify that the VM is a member of the intended VM DRS group.
  • Verify that the selected host is not accidentally included in or excluded from the host group.
  • Confirm that the rule is enabled and determine whether it is mandatory or preferential.
  • Inspect the current placement, DRS events, and recommendations.
  • Refresh the inventory view and allow any in-progress migration task to finish.

Command-Line and Automation Note

No command-line steps are required for the core workflow; VM-to-host rules are primarily configured in the vSphere Client. If you automate the process, use VMware PowerCLI cmdlets and parameters supported by the installed vCenter Server and PowerCLI versions. Verify the supported syntax in a nonproduction environment before applying changes.

Exam-Relevant Notes

  • A VM-to-host rule links one VM DRS group with one host DRS group.
  • The rule is configured at the DRS cluster level and requires DRS.
  • Must and must not express mandatory constraints.
  • Should and should not express preferences that DRS may override.
  • DRS recommendations and vMotion migrations depend on automation settings and valid host compatibility.
  • Groups are membership containers; changing membership changes which VMs or hosts the rule affects.