VMware ESXi and vSphere Cluster Management

vSphere Distributed Resource Scheduler (DRS) Requirements

Learn the vCenter, host, CPU, vMotion, storage, VM, and capacity prerequisites for configuring vSphere DRS safely.

vSphere Distributed Resource Scheduler (DRS) helps distribute virtual machine workloads across ESXi hosts in a vSphere cluster. Before enabling it, verify that the cluster has the management, CPU, networking, storage, and virtual machine compatibility required for successful vMotion operations.

DRS depends on vCenter Server. vCenter analyzes resource demand, manages the cluster, generates placement recommendations, and coordinates migrations. A standalone ESXi host does not provide DRS cluster functionality.

What vSphere DRS Does

vSphere DRS is a vCenter-managed feature for a vSphere cluster, which is a logical group of ESXi hosts managed together. DRS evaluates virtual machine demand and host capacity, then helps place or move virtual machines so resource use is more appropriate across the cluster.

DRS uses two related behaviors:

Initial placement: DRS recommends or selects an ESXi host when a virtual machine is powered on.
Ongoing balancing: DRS recommends or performs vMotion migrations when moving a running virtual machine could improve resource distribution.

In a migration, vMotion moves a powered-on virtual machine from one ESXi host to another. DRS does not directly move the VM files or bypass vMotion requirements.

vCenter Server and Cluster Prerequisites

Deploy vCenter Server and add every participating ESXi host to the same vCenter inventory. The hosts must be connected and healthy before they are placed in the same DRS cluster.

Create or select a vSphere cluster in vCenter Server.
Add the eligible ESXi hosts to that cluster.
Confirm that each host is connected and not in an unsuitable maintenance or disconnected state.
Enable DRS only after host, network, storage, and migration checks are complete.

Managing hosts independently through separate ESXi interfaces does not provide shared cluster analysis, DRS recommendations, or coordinated DRS migrations.

Host Consistency and Cluster Membership

DRS operates only on hosts in the same cluster. Hosts do not need to be identical, but consistent infrastructure makes more placement options available and reduces migration failures.

Compare the following across hosts:

Processor vendor, family, generation, and exposed CPU features.
vMotion VMkernel network configuration and host-to-host reachability.
Datastore mounts, storage paths, permissions, and available capacity.
Virtual machine port groups and network backing.
ESXi versions, virtual hardware support, host connection state, and cluster policies.

General consistency recommendations are broader than strict vMotion compatibility. A host can be generally similar to another yet still fail a particular VM migration because of CPU features, storage visibility, network availability, or a device-specific restriction.

CPU Compatibility and EVC

DRS may need to move a running VM to another host when one host is busy or a different host offers a better placement. The source and destination CPUs must therefore provide a compatible execution environment for that VM.

Enhanced vMotion Compatibility (EVC) establishes a common CPU feature baseline for hosts in a cluster. With EVC, newer processors can hide selected features that older processors in the cluster do not provide. This can allow migration between compatible CPU generations from the same vendor.

Before enabling fully automated DRS:

Review the processor vendor, family, generation, and supported features on every host.
Check whether mixed CPU generations require EVC.
Select an EVC baseline supported by every host if EVC is appropriate.
Do not assume that different vendors or unrelated processor families are migration-compatible.
Validate representative VM migrations before relying on automatic balancing.

CPU compatibility does not make all hardware configurations portable. The VM must also have accessible storage, available networks, and supported virtual devices on the destination.

vMotion Networking Requirement

DRS load balancing relies on vMotion to relocate running virtual machines. Every host that may participate in a migration needs a functioning VMkernel adapter with the vMotion service enabled.

A VMkernel adapter is an ESXi network interface used for host services such as management, vMotion, storage, and fault tolerance. For DRS migrations, verify:

Each participating host has a vMotion-enabled VMkernel adapter.
The vMotion interfaces have host-to-host reachability.
VLAN, routing, MTU, firewall, and physical-switch settings are consistent with the network design.
The migration network has enough bandwidth for the expected VM memory transfer rate and concurrent migrations.
Every possible source and destination host pair can communicate over the intended vMotion path.

Many designs isolate vMotion traffic from management and production virtual machine traffic. Separation can improve security, performance, and troubleshooting, but it must be implemented consistently across all participating hosts.

Shared Storage Requirement

Traditional vMotion-based DRS assumes that the destination host can access the virtual machine's files while the VM is moved. A datastore is a logical storage container presented to ESXi for VM files. Shared storage is simultaneously accessible to multiple ESXi hosts.

Supported shared-storage examples include:

VMFS on Fibre Channel.
VMFS on iSCSI.
VMFS on FCoE.
VMFS on shared SAS.
NFS datastores.

For each datastore used by a VM that DRS may move:

Mount or present it to every eligible destination host.
Rescan storage adapters and confirm datastore visibility.
Check storage paths and permissions on every host.
Confirm that the datastore has enough free capacity for VM disks, configuration files, snapshots, and expected growth.
Verify that storage health and connectivity are consistent across the cluster.

If a datastore is mounted only on the current host, DRS may detect an imbalance but cannot perform a standard vMotion migration to a host that cannot access the VM files.

Virtual Machine vMotion Readiness

Each VM must satisfy vMotion requirements before DRS can move it. Common migration blockers include:

CPU features unavailable on the destination host.
Datastores or storage volumes unavailable to the destination.
Required VM port groups missing on the destination host.
Attached local devices or host-specific dependencies.
Unsupported virtual hardware or device configurations.
Affinity rules, reservations, limits, resource pools, or host policies that exclude the destination.

When constraints prevent a valid move, DRS may leave the VM on its current host even when the cluster appears imbalanced. Test vMotion with representative, noncritical VMs before enabling aggressive automation.

Capacity Planning for DRS

DRS redistributes existing demand; it does not increase the aggregate resources in a cluster. Plan enough CPU and memory capacity for normal workloads, demand spikes, maintenance operations, and expected host failures where appropriate.

Capacity planning should account for:

Aggregate physical CPU and memory capacity.
ESXi overhead and host reservations.
Operational headroom for bursts and migration activity.
Host maintenance and failure scenarios, often together with vSphere HA planning.
Network bandwidth for VM traffic, storage, management, and vMotion.
Datastore capacity for all VM files and operational growth.

Placement options can also be restricted by reservations, limits, shares, resource pools, and affinity rules. A resource pool is a logical allocation of cluster CPU and memory resources. An affinity rule is a placement policy that keeps VMs together, keeps them apart, or constrains VMs to selected hosts. Review these settings before concluding that DRS is not balancing correctly.

DRS Prerequisites Checklist

Requirement: vCenter Server
Why it is needed: DRS analysis, cluster management, recommendations, and migration coordination are vCenter functions.
How to validate: Confirm all ESXi hosts are connected in one vCenter inventory.
Impact if missing: No DRS cluster functionality.

Requirement: Cluster membership
Why it is needed: DRS evaluates hosts within one vSphere cluster.
How to validate: Confirm eligible hosts are members of the intended cluster.
Impact if missing: Hosts are not considered together for DRS.

Requirement: Compatible CPUs or EVC
Why it is needed: Running VMs must be executable on candidate destination hosts.
How to validate: Check CPU compatibility and the EVC baseline.
Impact if missing: vMotion and DRS placement options are restricted.

Requirement: vMotion-enabled VMkernel networking
Why it is needed: DRS uses vMotion for live relocation.
How to validate: Check service enablement, addressing, reachability, MTU, VLAN, routing, and bandwidth.
Impact if missing: Automated or recommended migrations fail.

Requirement: Shared datastore access
Why it is needed: VM files must remain available after the host changes.
How to validate: Compare datastore mounts, paths, permissions, health, and free space across hosts.
Impact if missing: The destination cannot run the VM through standard vMotion.

Requirement: Adequate compute and memory capacity
Why it is needed: A destination must have enough resources for the VM and cluster headroom.
How to validate: Review demand, reservations, capacity, maintenance needs, and failure scenarios.
Impact if missing: DRS cannot find a safe placement.

Requirement: VM network availability
Why it is needed: The destination must provide the VM's required port groups and backing.
How to validate: Compare virtual switches, port groups, VLANs, and uplinks across hosts.
Impact if missing: vMotion is rejected or the VM would lose network connectivity.

Requirement: VM vMotion compatibility
Why it is needed: VM hardware and attached devices must support migration.
How to validate: Test a controlled vMotion and review compatibility checks.
Impact if missing: DRS leaves the VM in place or reports a migration restriction.

Configuring DRS After Prerequisites Are Met

Create and prepare the cluster

Create a cluster in vCenter Server.
Add the intended ESXi hosts.
Confirm that hosts are connected, healthy, and consistently configured.
Validate CPU compatibility, vMotion networking, shared storage, and VM networks.

Choose an automation level

Manual: DRS provides recommendations for initial placement and ongoing migrations. An administrator approves actions.

Partially automated: DRS handles initial VM placement automatically and provides recommendations for ongoing load balancing.

Fully automated: DRS handles initial placement and can automatically perform ongoing migrations according to its migration threshold and cluster constraints.

Start with manual or partially automated operation when introducing a cluster, especially when migration compatibility has not yet been proven. Move to fully automated operation after reviewing recommendations, vMotion results, migration history, and operational impact.

Set migration behavior

The migration threshold, sometimes called aggressiveness, controls how readily DRS recommends or performs migrations. A more aggressive setting can respond to smaller resource imbalances but may increase migration frequency and network use. A conservative setting reduces movement but may leave more uneven utilization.

Initial placement and ongoing load balancing are distinct behaviors. A cluster can automatically select a host for a new VM while still requiring approval for later balancing migrations.

Common Conditions That Restrict DRS Migrations

Condition: Incompatible CPU features
Affected requirement: CPU compatibility or EVC
Typical result: A host is excluded from placement or vMotion fails.
Corrective action: Resolve CPU differences, apply a supported EVC baseline, or use compatible hosts.

Condition: No vMotion network connectivity
Affected requirement: VMkernel networking
Typical result: Live migration cannot start or complete.
Corrective action: Enable vMotion, correct VLAN or routing issues, and verify host-to-host reachability.

Condition: Datastore not visible to the destination host
Affected requirement: Shared storage
Typical result: The VM cannot be relocated using standard vMotion.
Corrective action: Present and mount the datastore, then verify paths, permissions, and health.

Condition: Destination host lacks the VM port group
Affected requirement: VM network availability
Typical result: vMotion is blocked or network connectivity would be lost.
Corrective action: Create consistent network backing or revise the VM network design.

Condition: Host or VM affinity rule conflict
Affected requirement: Placement policy
Typical result: DRS cannot select a rule-compliant destination.
Corrective action: Review and adjust VM-Host or VM-VM rules when operationally safe.

Condition: Insufficient destination capacity
Affected requirement: CPU and memory capacity
Typical result: DRS leaves the VM in place or cannot satisfy reservations.
Corrective action: Add capacity, reduce demand, or reassess reservations and limits.

Condition: VM device or configuration migration restriction
Affected requirement: VM vMotion readiness
Typical result: The VM is excluded from a migration.
Corrective action: Remove or reconfigure unsupported devices and test again.

Troubleshooting DRS and vMotion

DRS reports an imbalance but does not move a VM

Check the DRS recommendation and its stated reason. Common causes include incompatible CPU features, unavailable storage, insufficient destination resources, affinity rules, reservations, resource pool constraints, or a conservative migration threshold. A controlled vMotion attempt with a noncritical VM can identify migration-specific errors.

vMotion fails during a DRS migration

Verify the vMotion-enabled VMkernel adapters on both hosts. Check addressing, VLANs, routing, MTU, firewall rules, physical-switch settings, and host-to-host reachability. Then review the vMotion task error and inspect the VM for attached local devices or unsupported hardware.

A target host is unavailable for placement

Compare datastore mounts, storage paths, VM port groups, CPU compatibility, EVC status, host connection state, maintenance state, and DRS rules. One missing dependency can exclude an otherwise suitable host.

DRS generates excessive migrations or little balancing

Review migration history, demand trends, recommendations, and threshold settings. Rapidly changing workloads, strict placement policies, reservations, and limited capacity can reduce the number of valid destinations. Adjust the threshold only after confirming that the vMotion network and storage infrastructure can support the expected activity.

Production Validation Checklist

Verify vCenter Server connectivity and confirm cluster membership.
Verify CPU compatibility or select an EVC baseline supported by all hosts.
Verify a vMotion-enabled VMkernel adapter and host-to-host connectivity on every participating host.
Verify shared datastore visibility, healthy paths, permissions, and adequate free capacity.
Verify that required VM networks and port groups exist on possible destination hosts.
Validate vMotion with a representative noncritical VM.
Review DRS rules, reservations, limits, shares, resource pools, and operational policies.
Start with an appropriate automation level, then review recommendations and migration history after activation.
Confirm that capacity remains sufficient for normal demand, maintenance, and relevant failure scenarios.

Practical Examples

Two-host cluster with shared VMFS storage

Two ESXi hosts are managed by one vCenter Server and belong to one DRS-enabled cluster. Both access the same VMFS datastore through a shared SAN, and both have reachable vMotion VMkernel adapters. After CPU compatibility is confirmed, DRS can recommend or execute vMotion from a CPU-constrained host to the other host.

Mixed CPU-generation hosts

A cluster contains older and newer processors from the same vendor. The administrator selects an EVC baseline supported by every host before enabling automated balancing. The baseline hides unsupported newer features from VMs, preserving migration compatibility across the supported generations.

Migration blocked by storage visibility

A VM is stored on a datastore mounted only on its current host. DRS identifies an imbalance but cannot use standard vMotion because the destination cannot access the VM files. The datastore must be made available to eligible hosts, or an appropriate storage migration approach must be used.

Manual validation before full automation

An administrator starts DRS in manual mode, reviews recommendations, and tests vMotion for representative VMs. After correcting networking, storage, CPU, and policy exceptions, the cluster can move to partially or fully automated operation.

Exam-Relevant Notes

DRS requires vCenter Server; standalone ESXi management does not provide DRS.
DRS operates on ESXi hosts in the same vSphere cluster.
DRS migrations of running VMs depend on vMotion.
vMotion requires compatible CPU features, reachable vMotion VMkernel networking, accessible storage, and suitable destination networking.
EVC provides a common CPU feature baseline for supported mixed CPU generations.
DRS balances placement; it does not add physical capacity.
Reservations, limits, shares, resource pools, and affinity rules can restrict DRS choices.
Initial placement and ongoing load-balancing migrations are related but separate DRS behaviors.

For the broader feature context, see vSphere Distributed Resource Scheduler (DRS) Requirements.