VMware ESXi and vSphere Cluster Management

vSphere Distributed Resource Scheduler (DRS) Explained

Learn how vSphere DRS selects VM placement, balances workloads across ESXi hosts, uses vMotion, applies automation levels, and handles resource constraints.

vSphere Distributed Resource Scheduler (DRS) is a vCenter Server cluster feature that selects virtual machine placement and balances compute workloads across ESXi hosts. It evaluates CPU and memory demand, available capacity, VM resource settings, compatibility, and placement rules.

The goal is not simply to make every host show the same CPU or memory percentage. DRS seeks to provide VMs with suitable resources, reduce avoidable contention, and improve the overall resource state of the cluster.

What vSphere DRS Does

An ESXi host is a physical server running the VMware hypervisor and hosting virtual machines. A vSphere cluster is a logical collection of ESXi hosts managed together by vCenter Server. DRS operates at this cluster level rather than making independent decisions on each host.

DRS evaluates the relationship between VM demand and host capacity. Its decision inputs can include:

Current and expected CPU demand.
Current and expected memory demand.
Available CPU and memory capacity on each host.
Reservations, limits, shares, and resource-pool policies.
VM-host affinity and anti-affinity rules.
Host compatibility and migration readiness.
Required VM networks and datastore access.
The configured DRS automation level and migration sensitivity.

When the cluster state can be improved, DRS may select a different host for a VM, recommend a migration, or perform an eligible migration automatically. It does not create additional CPU or memory. If every host lacks sufficient capacity, the remedy is capacity planning, workload reduction, or adding resources.

DRS During Virtual Machine Power-On

Initial placement is the host-selection process that occurs when a VM is powered on. DRS compares eligible hosts and chooses one that can satisfy the VM's requirements. For example, it may avoid a host with little remaining memory when another compatible host has substantially more available capacity.

Eligibility is more than a utilization comparison. A host must also satisfy applicable reservations, placement rules, network availability, datastore access, compatibility requirements, and other operational constraints.

Initial placement is different from later balancing. Initial placement answers, “Where should this VM start?” Workload balancing answers, “Would moving a running VM improve the cluster now?”

Example: Initial Placement

A three-host cluster contains several busy database VMs on one host. That host has limited remaining memory, while a second compatible host has available CPU and memory. When a new application VM powers on, DRS selects the less-constrained eligible host rather than placing the VM arbitrarily.

DRS Workload Balancing

After VMs are running, DRS evaluates the cluster continuously or periodically, depending on the vSphere version and configuration. It considers resource demand, host capacity, and contention across the cluster.

An overutilized host and an underutilized host can produce a migration recommendation. The recommendation identifies a VM that could move from the first host to the second host and estimates the benefit. In fully automated mode, DRS can initiate the move if the migration is valid and expected to improve the cluster state.

DRS does not blindly equalize raw CPU or memory percentages. A host with high utilization may still be meeting VM demand efficiently, while a host with lower utilization may not be a suitable destination because of reservations, rules, missing networks, or incompatible hardware. DRS focuses on demand, capacity, and contention rather than a single utilization number.

Example: Automatic Rebalancing

A batch-processing VM causes one host to become heavily loaded. Another compatible host has spare capacity and access to the required VM network and storage. DRS identifies a suitable VM to move. In fully automated mode, vMotion can relocate that running VM to reduce contention without a planned application outage.

How vMotion Works with DRS

vMotion is the technology that live-migrates a powered-on VM between eligible ESXi hosts. DRS makes the placement decision or recommendation; vMotion performs the actual migration.

A successful vMotion is designed to keep the workload running while its execution state transfers to the destination host. The guest operating system and application should not experience a planned shutdown, although migration still consumes network and host resources and should be monitored.

Before DRS can relocate a VM, the environment must support the migration. Typical requirements include:

A correctly configured VMkernel adapter for vMotion on each relevant host.
IP connectivity and sufficient network capacity between vMotion endpoints.
Compatible CPU and hardware characteristics, or an appropriate compatibility configuration such as EVC where applicable. See CPU compatibility for vMotion and EVC.
Destination access to the VM's required networks and port groups. A distributed switch can help provide consistent virtual networking across hosts.
Destination access to the VM's required datastore or other storage supported by the selected vMotion design.
Enough destination CPU and memory capacity after reservations and policies are considered.
Appropriate vSphere licensing and permissions.

DRS Automation Levels

The DRS automation level determines whether DRS only reports a recommendation or acts on it. The setting can be configured in the vSphere Client under the cluster's DRS service settings. Use the version-specific migration sensitivity or threshold options available in that client.

Automation level	Initial VM placement	Running VM migration behavior	Administrator responsibility	Typical use case
Manual	DRS recommends a host.	DRS recommends migrations.	Review and apply placement and migration recommendations.	Change freezes, tightly controlled production operations, or learning environments.
Partially automated	DRS places a powering-on VM automatically.	DRS provides migration recommendations for approval.	Review and approve or reject running-VM moves.	Environments that want automatic startup placement but controlled live migrations.
Fully automated	DRS places a powering-on VM automatically.	DRS can automatically perform eligible vMotion migrations.	Define policies, monitor actions, and investigate exceptions.	Stable clusters where automatic balancing is acceptable.

For a configuration walkthrough, see enabling DRS and setting the DRS automation level. VM-level overrides should be used only when there is a documented workload reason, such as a sensitive application or a migration policy requirement.

Cluster Requirements and Prerequisites

Create or select a cluster managed by vCenter Server. DRS requires a cluster containing multiple ESXi hosts; it is not an independent feature configured separately on each host.
Enable DRS in the cluster service settings and select an appropriate automation level.
Confirm that the hosts are compatible for the VMs that may migrate. EVC or other compatibility planning may be necessary in mixed-hardware clusters.
Configure and test a vMotion VMkernel adapter on each intended host.
Verify vMotion IP connectivity, network capacity, and firewall or switching requirements.
Make required VM networks available on destination hosts, including matching standard-switch port groups or distributed-switch connectivity as applicable.
Confirm that destination hosts can access the VM's required datastore or supported storage resources. Review VMFS datastore access or the relevant storage design.
Maintain enough CPU, memory, and operational headroom for migrations to relieve contention.
Verify licensing, permissions, and vCenter-to-ESXi communication. See assigning permissions when access is missing.

Test vMotion with a noncritical VM before using fully automated behavior for sensitive workloads.

Resource Controls and Placement Constraints

DRS must honor resource controls and placement policies. These controls can make a host appear available while still making it ineligible for a particular VM.

Reservation: A guaranteed amount of CPU or memory assigned to a VM or resource pool. A destination may be rejected if it cannot provide the required unreserved capacity.
Limit: The maximum CPU or memory that a VM or resource pool may consume. A limit can prevent a VM from using otherwise available capacity.
Shares: Relative priority used when workloads compete for a constrained resource. Shares do not reserve a fixed amount of capacity.
Resource pool: A logical grouping that allocates and prioritizes CPU and memory for workloads. Its settings can affect host eligibility and VM behavior.
VM-host affinity rule: A policy that keeps specified VMs on, or away from, specified hosts.
VM-VM affinity or anti-affinity: A policy that guides whether VMs should run together or apart. Anti-affinity is useful for separating redundant application instances.

Hard constraints take priority over a convenient balancing move. If mandatory rules conflict with available resources, DRS may report limited options or leave the cluster apparently imbalanced.

Decision Inputs and Effects

Input or constraint	How it affects placement or migration	Example operational consequence
CPU and memory demand	Helps DRS identify contention and estimate the benefit of a move.	A busy VM may be considered for movement away from a pressured host.
Available host capacity	Limits which hosts can accept the VM and its policies.	A host with spare CPU but insufficient memory may not be eligible.
Reservations	Require guaranteed capacity on the destination.	A VM may have no valid destination if unreserved memory is insufficient.
Limits and shares	Shape the VM's maximum use and priority during contention.	Moving a VM may not help if its configured limit remains the bottleneck.
VM-host affinity rules	Keep or place VMs on specified hosts, or prevent those placements.	Some hosts are excluded even when they have available capacity.
Host compatibility	Determines whether the VM can run on the candidate destination.	CPU incompatibility can block vMotion until compatibility is addressed.
Network and datastore availability	Requires the destination to provide the VM's connected networks and storage access.	A migration fails or is not proposed when a required port group or datastore is missing.
vMotion readiness	Determines whether the live migration mechanism can execute the DRS decision.	A missing or misconfigured vMotion VMkernel network prevents relocation.

Configuring DRS in the vSphere Client

Create or select a vCenter-managed cluster and add compatible ESXi hosts.
Open the cluster's service or configuration settings and enable DRS.
Choose manual, partially automated, or fully automated operation.
Review the migration threshold or balancing sensitivity offered by the installed vSphere version.
Configure VM-level automation overrides only for a documented exception.
Review VM-host affinity and anti-affinity rules. Confirm that mandatory rules are intentional and achievable.
Validate vMotion networking, storage access, VM networking, and CPU compatibility.
Start with a noncritical VM and inspect recommendations, tasks, and events before expanding automation.

Monitoring DRS Decisions

Administrators review DRS behavior in the vSphere Client. Useful views include cluster resource usage, DRS recommendations, migration history, and vCenter task and event records.

For each recommendation, review:

The proposed source host and destination host.
The VM selected for movement.
The expected resource or contention benefit.
Whether the recommendation is pending, applied, rejected, or unable to run.
Any compatibility, network, storage, capacity, or policy reason that prevents execution.

After an automatic or approved migration, inspect the related vCenter task and event. Confirm that VM performance and application behavior improved. An imbalanced-looking percentage does not automatically mean that a migration is beneficial; unnecessary moves consume resources and may add operational risk.

Troubleshooting DRS

DRS Produces Recommendations but Does Not Move VMs

Likely causes include manual or partially automated operation, a recommendation awaiting approval, or a VM-level automation override.

Review the cluster DRS automation setting.
Review the VM's individual DRS automation setting.
Check pending recommendations, vCenter tasks, and events.

A Recommended Migration Fails

Common causes include unavailable vMotion networking, missing destination network or datastore access, CPU compatibility problems, or insufficient capacity after reservations and current demand are considered.

Validate vMotion VMkernel connectivity on both source and destination hosts.
Verify storage and port-group availability on all intended hosts.
Review migration error events and compatibility information.
Review reservations, resource pools, limits, and available CPU and memory.

The Cluster Remains Imbalanced

Strict affinity or anti-affinity rules may limit placement choices. Other possibilities include insufficient spare capacity, too few movable VMs, or a configured migration threshold that does not consider the imbalance significant enough.

Review DRS recommendations and rule compliance.
Determine whether constraints are mandatory or can safely be adjusted.
Assess whether additional hosts or resources are required.
Review the configured migration sensitivity.

A VM Cannot Power On

DRS cannot power on a VM when no host satisfies its reservation, compatibility, storage, network, or placement-rule requirements, or when cluster capacity is exhausted.

Review the VM power-on task error.
Check reservations and resource-pool limits.
Check host eligibility, affinity rules, and datastore access.
Confirm usable CPU and memory capacity across the cluster.

Operational Guidance and Limitations

DRS is not a substitute for adding capacity. If the cluster lacks enough CPU or memory, moving VMs only rearranges the shortage.
DRS cannot bypass unavailable networks, incompatible hosts, inaccessible datastores, reservations, or mandatory affinity rules.
Aggressive automatic migration should be evaluated against workload sensitivity, vMotion network capacity, maintenance practices, and change-control requirements.
Use VM-level overrides sparingly. Excessive exceptions make cluster behavior harder to predict.
Maintain operational headroom so a migration can complete and the destination can tolerate demand changes.
Monitor application performance after migrations instead of judging success only by host utilization.

DRS, vMotion, and High Availability Compared

Feature	Primary purpose	When it acts	Typical action	Does it balance workloads?
DRS	Cluster resource placement and balancing.	At VM power-on and when cluster resource conditions change.	Selects a host, recommends a move, or starts an eligible vMotion.	Yes.
vMotion	Live migration of a running VM.	When initiated by an administrator, DRS, or another supported workflow.	Moves a powered-on VM between compatible hosts.	No. It performs the move; it does not decide the cluster policy.
vSphere High Availability (HA)	Recovery from ESXi host or VM failure.	When a protected host or VM failure is detected.	Restarts affected VMs on surviving hosts.	No. Its primary purpose is availability and recovery.

DRS and HA can be enabled in the same cluster, but they solve different problems: DRS manages resource placement and balance, while HA responds to failures. See enabling vSphere HA and HA admission control for availability planning.

Key Exam and Operations Notes

DRS is a vCenter-managed cluster feature, not a standalone per-host scheduler.
Initial placement occurs when a VM powers on; balancing concerns already-running VMs.
DRS decides or recommends placement; vMotion executes a live migration.
Manual mode requires administrator action for placement and migration recommendations.
Partially automated mode automates initial placement but requires approval for running-VM migrations.
Fully automated mode can automate both initial placement and eligible balancing migrations.
Reservations, compatibility, networks, storage, and affinity rules can make a host ineligible.
DRS improves placement but cannot manufacture capacity or override hard constraints.
Always verify the recommendation's expected benefit and inspect task or event results after execution.