VMware ESXi and vSphere Cluster Management

vSphere Distributed Resource Scheduler (DRS) Requirements

Learn the vCenter, ESXi, CPU, vMotion, shared storage, capacity, networking, and VM prerequisites for enabling and validating vSphere DRS.

vSphere Distributed Resource Scheduler (DRS) is a vCenter Server cluster feature that manages virtual machine placement and helps balance workloads across ESXi hosts. Before enabling DRS, verify that the cluster has the compute, network, storage, and virtual machine compatibility required for migration.

DRS monitors host resource demand, especially CPU and memory demand. When powered-on virtual machines create an uneven load, DRS can recommend or perform placement changes. Live rebalancing depends on vMotion, which moves a running virtual machine from one ESXi host to another without a planned guest operating system shutdown.

How DRS Uses vCenter Server

An ESXi host is a VMware hypervisor server that runs virtual machines. A vSphere cluster is a logical group of ESXi hosts managed as a unit. DRS operates at the cluster level, not on an isolated ESXi host.

All participating hosts must be added to and managed by vCenter Server. vCenter provides the inventory, cluster configuration, resource analysis, migration recommendations, and automation controls used by DRS. A standalone ESXi host can run VMs, but it cannot provide cluster-level DRS balancing.

Before proceeding, review adding an ESXi host to vCenter Server inventory and creating clusters. DRS is then enabled on the vCenter-managed cluster; configuration is not performed independently on each host.

Core DRS Infrastructure Requirements

Hosts must belong to one cluster

DRS can redistribute workloads only among ESXi hosts that are members of the same vSphere cluster. Each host should be a suitable destination for the VMs that may be placed on it. A consistent design normally includes comparable host capabilities, compatible CPU features, common networking, and common datastore access.

Hosts do not have to be identical in every hardware detail, but differences must not prevent the intended migrations. A host in maintenance mode, disconnected from vCenter, constrained by rules, or missing required resources is not an eligible destination.

CPU compatibility is required

During a powered-on migration, the destination processor must support the CPU features exposed to the VM. Vendor branding alone is not enough: processor generations and feature sets must be checked for the particular hosts and workloads.

Compatible processor families can often support vMotion directly. When supported hosts have different CPU generations, Enhanced vMotion Compatibility (EVC) can establish a common CPU feature baseline by masking selected newer features from VMs. This improves migration compatibility, but it does not make fundamentally unsupported hardware interchangeable.

Review CPU compatibility for vMotion and EVC concepts. Select an EVC mode appropriate for the least capable processor generation that must receive the workload, and validate the setting against the actual hosts and VM requirements.

Every host needs a vMotion VMkernel path

A VMkernel adapter is an ESXi network interface used for host service traffic. For DRS to move powered-on VMs, every participating host should have a VMkernel adapter with the vMotion service enabled.

The vMotion network must provide:

Mutual IP reachability between the vMotion VMkernel interfaces.
Correct VLAN assignment and switching configuration.
Consistent port, MTU, routing, and security settings where applicable.
Sufficient bandwidth for memory transfer and concurrent migrations.
Enough isolation from ordinary traffic to avoid congestion.

Test the migration network before relying on automated balancing. A DRS recommendation may be valid from a resource perspective but impossible to execute if the vMotion interfaces cannot communicate.

Network mappings must also exist for the VM itself. The destination host needs the VM's required port group, or an equivalent valid mapping, so that the guest retains network connectivity after migration. See VLAN configuration and distributed switches for related networking concepts.

Hosts need common datastore access

A datastore is a vSphere storage container that holds virtual machine files. Shared storage is a datastore accessible by more than one ESXi host. Standard live migration within a DRS cluster normally requires the destination host to access the VM's files, including its configuration files and virtual disks.

Common shared-storage designs include:

VMFS datastores on SAN storage.
NFS datastores.
vSAN datastores.

All intended hosts should see the same datastore presentation, have correct permissions, and maintain healthy storage connectivity. A datastore visible from one host but absent or inaccessible from another is not a suitable common destination.

For implementation-specific storage work, see creating a VMFS datastore, configuring an NFS datastore, and configuring vSAN.

Storage Capacity Planning

Datastore visibility is not the same as adequate capacity. The destination datastore must have enough usable space for the VM's complete footprint and operational overhead.

Account for:

Virtual disk files, including growth of thin-provisioned disks.
Snapshot delta files when snapshots are used.
VM swap files.
Configuration files, logs, and related VM files.
Temporary migration requirements and organizational free-space policy.

Monitor free space continuously because disks can grow and VMs can be moved into the cluster over time. If a destination can see a datastore but cannot accommodate the VM, migration will fail or placement will be rejected. Capacity may need to be expanded, reclaimed, or assigned to another datastore. See expanding a VMFS datastore and consolidating snapshots.

Virtual Machine vMotion Eligibility

A VM must satisfy vMotion prerequisites before DRS can relocate it automatically or through a recommendation. At a high level, the VM must have compatible virtual hardware, a supported guest operating state, and a destination that can provide its required resources.

Check the following VM-level conditions:

The destination CPU is compatible with the VM's exposed CPU feature set.
The destination host can access every datastore required by the VM.
The required VM port group or equivalent network mapping exists on the destination.
Mounted devices and host-local resources do not require unavailable hardware.
Unsupported device configurations do not block migration.
DRS affinity, anti-affinity, or VM-to-host rules do not exclude the destination.
The VM's virtual hardware and guest operating state support the intended migration.

Examples of migration blockers include a host-local CD/DVD or passthrough device, an unavailable network, inaccessible storage, an incompatible CPU feature, or a rule that intentionally restricts placement. Review DRS affinity rules and virtual machine settings when a particular VM is excluded.

Pre-Enable DRS Checklist

Requirement	Why It Is Needed	How to Validate	Effect if Missing
vCenter Server management	DRS is controlled at the vCenter cluster level.	Confirm every ESXi host is connected in the same vCenter inventory.	No DRS cluster operation for standalone hosts.
Multiple hosts in the same cluster	DRS needs more than one eligible placement destination.	Inspect cluster membership and host connection state.	No cross-host balancing.
Compatible CPUs or EVC	A running VM must execute correctly on the destination CPU.	Run compatibility checks and review processor generations or EVC.	Some hosts cannot receive the VM.
vMotion-enabled VMkernel connectivity	Powered-on VM movement uses the vMotion network.	Verify service enablement, VLANs, IP reachability, and a test migration.	Recommendations cannot be executed.
Shared datastore visibility	The destination must access VM configuration and disk files.	Check datastore mounts, permissions, paths, and storage health on every host.	Migration or placement fails.
Sufficient datastore capacity	The VM requires space for disks and operational files.	Compare usable free space with the VM footprint and growth policy.	Placement is rejected or runs out of space.
Destination VM network availability	The VM needs a valid network after migration.	Confirm matching or equivalent port groups on all candidate hosts.	Migration may be blocked or connectivity may be lost.
Individual VM vMotion eligibility	Each VM has its own hardware, device, rule, and state constraints.	Review vCenter compatibility checks and test a controlled vMotion.	DRS cannot move that VM even if the cluster is enabled.

DRS Functions and Their Dependencies

DRS Function	Underlying Dependency	Example Validation
Initial VM placement	vCenter cluster membership, host resources, datastore access, and network mappings.	Place a test VM and verify that candidate hosts provide its required resources.
Migration recommendation generation	DRS monitoring data plus eligible alternative hosts.	Review a manual recommendation and inspect its reason and destination.
Automatic live rebalancing	Executable vMotion paths, CPU compatibility, shared storage, and VM eligibility.	Perform a controlled vMotion before enabling full automation.
Placement on shared storage	Common datastore presentation, permissions, connectivity, and free capacity.	Confirm the VM's files are accessible from each intended destination.
Migration to a compatible CPU host	Matching CPU feature support or an appropriate EVC baseline.	Run host and VM CPU compatibility checks.

DRS Automation Levels

Meeting the infrastructure prerequisites enables DRS capabilities but does not require immediate fully automated migration. The DRS automation level determines how placement and migration actions are handled.

Manual: DRS provides recommendations; an administrator decides whether to apply them.
Partially automated: DRS can automate initial VM placement while migration recommendations are reviewed manually.
Fully automated: DRS can select initial placement and perform eligible migrations according to cluster policy.

Manual or recommendation-driven operation is useful during initial validation. After testing networking, storage, CPU compatibility, VM port groups, and workload behavior, an administrator can decide whether full automation is appropriate. See setting the DRS automation level and enabling DRS.

Practical Two-Host Example

Consider a two-host DRS cluster used to balance production VMs:

Add both ESXi hosts to the same vCenter-managed cluster.
Configure a vMotion-enabled VMkernel adapter on each host.
Confirm mutual IP connectivity, correct VLAN settings, and adequate migration bandwidth.
Present the production datastore to both hosts and verify permissions, health, and free capacity.
Make the production VM's network port group available on both hosts.
Validate CPU compatibility or configure an appropriate EVC baseline if the processor generations are mixed.
Choose a test VM and complete a controlled live migration.
Start with manual or partially automated DRS, review recommendations, and move to full automation only after the design is trusted.

Common Readiness Failures

Symptom	Likely Cause	Verification Area	Corrective Direction
vMotion migration fails	Broken vMotion connectivity, inaccessible storage, CPU incompatibility, missing network, or a VM configuration restriction.	Review the vCenter migration task and compatibility checks.	Correct the failing dependency and retest with a controlled migration.
Host is not an eligible destination	Host state, DRS rules, resource limits, CPU features, storage, or network mismatch.	Inspect cluster and VM compatibility information.	Review host state, rules, resources, and all destination mappings.
Datastore is inaccessible	The datastore is not mounted, storage paths are unhealthy, or permissions differ.	Check datastore visibility and connectivity from the destination host.	Correct presentation, permissions, paths, or storage health.
Insufficient free storage space	The datastore is visible but lacks space for disks, snapshots, swap, logs, or growth.	Compare usable free space with the VM footprint and policy reserve.	Free or expand capacity, select another datastore, or revise placement.
CPU incompatibility message	The destination lacks a CPU feature exposed to the VM.	Compare host CPU generations and EVC configuration.	Use a supported EVC baseline, select another host, or prevent that migration path.
Required VM network is absent	The destination lacks the VM port group or a valid equivalent mapping.	Compare networking configuration on candidate hosts.	Create or correctly map the required network before migration.

Troubleshooting DRS Recommendations

A recommendation exists but migration fails

Read the migration task error and vCenter compatibility checks rather than relying only on the DRS recommendation text.
Confirm that the vMotion VMkernel adapters have the service enabled and can communicate over the intended network.
Verify that the destination sees every required datastore and has sufficient free capacity.
Compare CPU compatibility and assess whether the EVC baseline is appropriate.
Confirm the required VM port group exists and review mounted devices, passthrough hardware, rules, and other VM constraints.

A host cannot receive a VM

Check the VM's compatible host list, destination datastore access, network mappings, host connection and maintenance state, DRS rules, and resource constraints. A host may be healthy for other VMs but unsuitable for this particular VM.

DRS does not effectively balance the cluster

Identify which VMs can migrate to which hosts. If many VMs are not vMotion-compatible, only some hosts can access the required datastores, migration traffic is congested, or affinity rules are restrictive, DRS has fewer legal placement choices. Test vMotion, review storage and network reachability, and examine CPU and rule limitations.

Final Validation Procedure

Confirm vCenter Server manages all intended ESXi hosts.
Confirm the hosts are members of one cluster and are connected and operational.
Validate CPU compatibility and EVC, if required.
Verify vMotion VMkernel configuration, VLANs, IP reachability, bandwidth, and network consistency.
Verify common datastore visibility, permissions, health, and usable capacity.
Confirm destination port groups and equivalent network mappings.
Review individual VM hardware, devices, guest state, snapshots, rules, and migration compatibility.
Use a manual DRS recommendation or controlled vMotion test.
Review compatibility checks and migration error messages.
Choose the DRS automation level appropriate for the confidence gained from testing.

For a broader learning path, see the VMware ESXi online course, EVC requirements, and vSphere HA requirements if that page is available in your course navigation.