VMware ESXi and vSphere Cluster Management
vSphere Distributed Resource Scheduler (DRS) Explained
Learn how vSphere DRS balances VM workloads across ESXi hosts, uses vMotion, selects automation levels, applies placement rules, and handles common troubleshooting cases.
vSphere Distributed Resource Scheduler (DRS) is a vCenter Server cluster capability that places and redistributes virtual machines across ESXi hosts. Its goal is to reduce CPU and memory contention while maintaining useful balance across the cluster.
DRS works at the vSphere cluster level, not on an isolated ESXi host. A cluster is a logical group of ESXi hosts managed together by vCenter Server. DRS evaluates the hosts and workloads in that group when deciding where VMs should run.
What vSphere DRS Does
An ESXi host is a physical server running the VMware ESXi hypervisor. Each host provides CPU, memory, networking, and storage access to its virtual machines. When several hosts are grouped into a vSphere cluster, DRS can make placement decisions using the resources and policies of the entire group.
DRS primarily considers CPU and memory demand. It attempts to prevent one host from experiencing excessive resource pressure while another compatible host has useful spare capacity. This does not mean that every host will have the same number of VMs or exactly the same utilization.
- A host with two compute-intensive VMs may be busier than a host with ten lightly used VMs.
- DRS evaluates workload demand and available capacity, not just VM counts.
- DRS cannot create additional physical CPU or memory capacity.
- DRS behavior depends on vMotion readiness, storage, networking, CPU compatibility, capacity, and placement policies.
How DRS Operates
1. Initial placement
Initial placement is the decision about where a VM should run when it is powered on. DRS evaluates compatible hosts and selects a suitable destination based on factors such as CPU and memory availability, configured rules, network access, storage access, and migration compatibility.
For example, suppose a three-host cluster has the following conditions:
- Host A has many lightly loaded VMs.
- Host B has fewer VMs but several compute-intensive workloads.
- Host C has the most available CPU and memory.
DRS may place a new application VM on Host C. It does not simply choose the host with the fewest registered VMs.
2. Ongoing load balancing
After VMs are powered on, DRS continues to evaluate cluster conditions. If demand rises on one host while another compatible host has available capacity, DRS may identify a migration that improves balance.
In a mode that permits automatic migrations, DRS can use vMotion to move a suitable running VM. In recommendation-based modes, it presents the proposed movement for administrator review instead.
3. Response to changing demand
Workloads change over time. A database, build server, or application tier may temporarily consume more CPU or memory than usual. DRS can respond to relative overutilization when a beneficial and permitted destination exists. If every host is close to capacity, balancing alone cannot resolve the shortage.
Resource Contention and Balance
Resource contention is competition among virtual machines for finite CPU or memory resources on an ESXi host. Contention can increase VM performance delays even when all VMs remain powered on.
DRS attempts to reduce this pressure by redistributing demand. A balanced cluster is not necessarily one in which each host has an equal VM count. Instead, balance means that workload demand is distributed appropriately within the limits of host capacity and cluster policies.
| Situation | Why VM count can be misleading | How DRS interprets it |
|---|---|---|
| Two VMs on one host | Both may be CPU-intensive and consume most of the host's capacity. | The host may be more pressured than a host with many idle VMs. |
| Many VMs on another host | The VMs may have low current demand. | The host may still have capacity for additional work. |
| All hosts are heavily loaded | There may be no useful destination for migration. | DRS cannot solve a cluster-wide capacity shortage. |
vMotion: The Migration Mechanism
vMotion is VMware live migration technology. It moves a running VM from one compatible ESXi host to another without planned VM downtime. DRS uses vMotion when it needs to relocate a powered-on VM for balancing.
- DRS: evaluates placement and recommends or initiates a change.
- vMotion: carries out the live relocation.
- Cluster configuration: determines whether the target host is eligible.
Live migration requires more than two hosts being members of the same cluster. vMotion networking must work, the destination must provide the VM's required network and storage access, and the hosts must satisfy CPU and other compatibility requirements.
DRS Automation Levels
The automation level controls how much authority DRS has to apply its decisions.
| Automation level | Initial placement behavior | Ongoing migration behavior | Administrator involvement | Typical use case |
|---|---|---|---|---|
| Manual | DRS recommends a host for a powered-on VM. | DRS presents migration recommendations. | Administrator reviews and applies placement or migration actions. | Environments requiring maximum change control. |
| Partially automated | DRS automatically selects the initial host. | DRS provides recommendations for later balancing migrations. | Administrator approves or applies ongoing migrations. | Workloads needing controlled changes after startup. |
| Fully automated | DRS automatically selects the initial host. | DRS can automatically perform suitable vMotion migrations. | Administrator monitors policies, activity, and exceptions. | Stable clusters with validated compatibility and operational confidence. |
Select an automation level according to operational control, workload sensitivity, and confidence in the cluster configuration. Strictly controlled business applications may favor partially automated or manual operation. A well-tested cluster with suitable migration infrastructure may use fully automated operation.
DRS Recommendations
A migration recommendation is a DRS-proposed VM movement intended to improve cluster resource balance. Recommendations are especially important in manual and partially automated modes.
Before applying a recommendation, review:
- Current CPU and memory demand on the source and destination hosts.
- Whether the workload is entering a maintenance or change window.
- Whether vMotion traffic and destination capacity are available.
- Whether affinity, anti-affinity, or other rules influence the proposal.
- Whether the proposed move provides a meaningful benefit rather than merely changing VM location.
Recommendations should be interpreted in the context of current demand. A visible difference in host utilization may not justify a migration if the difference is temporary, small, or blocked by compatibility constraints.
DRS Requirements and Dependencies
Use this checklist before expecting DRS to balance powered-on VMs automatically.
| Requirement | Why it matters | How to validate | Effect if missing |
|---|---|---|---|
| ESXi hosts in one vCenter-managed cluster | DRS evaluates and manages resources at the cluster level. | Check cluster membership in the vSphere Client. | Hosts cannot participate in the same DRS decisions. |
| Working vMotion configuration | Running VMs need a live migration path. | Perform or validate a vMotion between eligible hosts. | DRS may recommend no migration or fail to apply one. |
| Migration-compatible VM storage | The destination host must access the VM's files and virtual disks. | Verify shared datastore or otherwise supported migration-compatible storage access. | The VM cannot be moved to that destination. |
| CPU compatibility | Source and destination processors must support the migration requirements. | Review host CPU compatibility and any configured compatibility controls. | Candidate hosts may be excluded or the vMotion may fail. |
| Consistent VM networking | The destination must provide the required port groups and connectivity. | Check port group availability and VLAN or network configuration on each host. | The VM may not be eligible for the destination. |
| Spare cluster capacity | A destination must have enough CPU and memory for the VM's demand. | Review host utilization, reservations, limits, and available capacity. | DRS cannot relieve the overloaded host. |
Placement and Migration Constraints
DRS cannot move a VM to every host indiscriminately. A destination must be compatible, have adequate resources, and satisfy the environment's networking, storage, and policy requirements.
| Factor or constraint | Impact on placement or migration | Example |
|---|---|---|
| Available CPU and memory | Eliminates hosts that cannot accept the workload. | A destination lacks enough spare memory for a large VM. |
| vMotion compatibility | Determines whether a running VM can be moved between hosts. | Host CPU features or migration configuration are incompatible. |
| Storage accessibility | Requires the destination to access the VM's required storage. | The target host cannot see the datastore containing the VM files. |
| Network and port groups | Requires the VM's virtual networks to exist on the destination. | The target host lacks the VM's application port group. |
| Affinity rule | Can keep selected VMs together or associate VMs with particular hosts. | Two cooperating VMs are required to remain together. |
| Anti-affinity rule | Can keep selected VMs apart to improve availability. | Redundant application VMs must run on separate hosts. |
| Capacity and reservations | May restrict moves even when average utilization appears low. | A reservation prevents the destination from accepting another VM. |
Rules can override an otherwise attractive balancing move. For example, if two redundant application VMs have an anti-affinity rule, DRS must keep them on separate hosts. If no host satisfies both the resource and policy requirements, the preferred migration cannot occur.
Benefits and Limitations
Benefits
- Improves use of available CPU and memory across a cluster.
- Reduces manual effort involved in choosing VM placement.
- Responds to changing workload demand.
- Supports controlled recommendations or automatic migrations.
- Works with placement policies to reflect application requirements.
Limitations
- DRS does not add physical CPU, memory, storage, or network bandwidth.
- It is not a replacement for capacity planning.
- It cannot compensate for badly sized VMs, unsuitable reservations, or persistent cluster-wide demand.
- It cannot migrate a VM when vMotion, storage, networking, CPU compatibility, or policy requirements are not satisfied.
- Its results depend on accurate configuration and meaningful performance monitoring.
If all hosts are busy and no destination can accept a large VM, possible solutions include reducing workload demand, correcting VM sizing, adding host capacity, or changing an appropriate resource policy. DRS alone cannot manufacture capacity.
Basic Administration Workflow
- Create or select a vSphere cluster. Use a vCenter Server-managed cluster intended to share DRS services.
- Add compatible ESXi hosts. Confirm that the hosts have suitable CPU, networking, storage, and management configuration.
- Configure and validate vMotion. Check VMkernel connectivity and test migration readiness between eligible hosts.
- Verify destination access. Confirm that potential hosts can access the required VM networks and storage.
- Enable DRS at the cluster level. Open the target cluster's configuration settings in the vSphere Client and enable the DRS service.
- Choose an automation level. Select manual, partially automated, or fully automated operation.
- Review cluster and VM settings. Check cluster-level DRS settings, VM-level automation overrides, and affinity or anti-affinity rules.
- Monitor activity. Review recommendations, migrations, utilization, tasks, events, and rule conflicts.
vSphere Client workflow
1. Select the target vSphere cluster.
2. Open Cluster configuration settings.
3. Enable DRS.
4. Select Manual, Partially automated, or Fully automated.
5. Review VM overrides and placement rules.
6. Monitor recommendations and migration tasks.DRS Versus Related vSphere Capabilities
| Capability | Primary purpose | How it relates to DRS | Example outcome |
|---|---|---|---|
| DRS | Place and balance VM workloads across cluster hosts. | Uses resource analysis and may use vMotion. | A busy host is relieved by moving a suitable VM. |
| vMotion | Live-migrate a running VM between compatible hosts. | Provides the migration mechanism DRS can use. | A VM changes hosts without planned service interruption. |
| vSphere HA | Restart VMs after certain host failures. | Addresses availability after failure, while DRS addresses placement and balance. | VMs restart on surviving hosts after a host failure. |
| Distributed Power Management | Reduce host power use when cluster demand is low. | May power hosts down or up based on demand; it is distinct from DRS balancing. | An underused host is placed into a lower-power state. |
| Resource pools | Organize and allocate CPU or memory resources. | Resource policies can affect the capacity available to DRS decisions. | A business unit receives a defined resource share. |
Troubleshooting DRS
DRS recommends migrations but does not move VMs automatically
Likely causes include manual or partially automated cluster operation, a VM-specific automation override, or a requirement for administrator approval.
- Review the cluster DRS automation setting.
- Inspect VM-level DRS automation overrides.
- Check the recommendation list and recent migration tasks.
DRS cannot move a VM away from an overloaded host
Check whether any destination has enough CPU and memory. Then validate vMotion networking, destination storage, VM port groups, CPU compatibility, and affinity or anti-affinity rules.
- Compare host demand and available capacity.
- Validate vMotion connectivity and migration compatibility.
- Confirm storage and network access on candidate hosts.
- Review DRS rules and VM placement constraints.
The cluster appears uneven even though DRS is enabled
The apparent imbalance may be based on VM counts rather than actual demand. It may also be below the threshold for a beneficial migration, constrained by rules, or caused by limited spare capacity.
- Compare CPU and memory demand instead of only VM totals.
- Review DRS recommendations and their reasoning.
- Check active placement rules and host compatibility.
- Consider capacity expansion or VM resizing if demand is consistently high.
A vMotion task initiated by DRS fails
Review the failed task details and event messages. Confirm VMkernel vMotion connectivity, shared datastore visibility, port group consistency, CPU compatibility, and destination capacity.
Exam-Relevant Notes
- DRS is a vCenter Server cluster feature, not a standalone ESXi host feature.
- DRS handles placement and balancing decisions; vMotion performs live VM movement.
- Manual mode requires administrator action for placement and migration recommendations.
- Partially automated mode automates initial placement but leaves later balancing migrations as recommendations.
- Fully automated mode can automate both initial placement and suitable ongoing migrations.
- Equal VM counts do not prove balanced resource use.
- DRS cannot overcome missing vMotion compatibility, inaccessible storage, unavailable networks, placement rules, or insufficient cluster capacity.
- DRS improves placement and utilization but does not replace capacity planning or performance monitoring.
For a concise reference, see vSphere Distributed Resource Scheduler (DRS) Explained.