3.3 Distributed Resource Scheduler (DRS) & EVC Configuration

3.3 Distributed Resource Scheduler (DRS) & EVC Configuration

Modern enterprise virtual infrastructures require dynamic workload distribution to eliminate performance hotspots, support service level objectives (SLOs), and optimize physical hardware efficiency. vSphere Distributed Resource Scheduler (DRS) continuously monitors compute and memory utilization across ESXi clusters, automating workload placement and live vMotion migrations. When paired with Enhanced vMotion Compatibility (EVC) and Stretched Clusters, DRS ensures seamless workload mobility across heterogeneous hardware generations and geographically separated datacenters.

---

vSphere DRS Architecture & The VM Happiness Metric

vSphere DRS aggregates physical CPU and memory resources from multiple ESXi hosts into unified, logical cluster resource pools. DRS executes an evaluation algorithm on a periodic evaluation cycle, or immediately on demand when a virtual machine is powered on.

The Shift to VM-Centric DRS Happiness

Historically, DRS evaluated cluster load balancing using a host-centric metric based on standard deviation of host utilization. If all hosts were equally loaded at 80% CPU, DRS considered the cluster balanced, even if individual virtual machines were starved of CPU cycles or suffering memory contention.

In modern vSphere releases, DRS operates on a VM-Centric Happiness Metric (represented as the DRS Score, ranging from 0% to 100%):

• Evaluation Basis: DRS calculates the execution efficiency of each individual virtual machine by measuring resource contention:
  • CPU Contention: Time spent waiting in the VMkernel ready queue (%RDY), CPU latency (%LAT_C), and CPU entitlement.
  • Memory Contention: Memory granted versus memory demanded, swap-in rate from .vswp files, and memory ballooning pressure (vmmemctl).
  • vMotion Cost-Benefit Analysis: DRS calculates the "cost" of migrating a VM (CPU cycles and network bandwidth consumed during vMotion stun) against the predicted "gain" in VM happiness on the destination host. DRS recommends or executes a migration only if the performance improvement significantly outweighs the migration overhead.
• Cluster DRS Score: The cluster view displays the percentage of VMs residing in each happiness bucket (0-20%, 20-40%, 40-60%, 60-80%, and 80-100%). Use the score to investigate workload efficiency together with demand and contention; there is no universal percentage of VMs that proves application health.

DRS Automation Levels & Migration Thresholds

Administrators configure how aggressively and independently DRS manages virtual machine placement through two primary settings: Automation Level and Migration Threshold.

Cluster Automation Levels

Individual VM Overrides: DRS allows administrators to override cluster-wide automation levels for specific virtual machines. For example, in a Fully Automated cluster, a critical database VM can be set to Partially Automated or Manual to prevent unexpected vMotion events during high-transaction periods.

Migration Threshold Slider (1 to 5 Stars)

The Migration Threshold slider controls the sensitivity of the cost-benefit algorithm, dictating which priority recommendations DRS automatically executes in Fully Automated mode:

• Priority 1 (Level 1 - Conservative): Mandatory requirements only. DRS applies migrations strictly necessary to satisfy host maintenance mode evacuations, resource pool reservations, or hard affinity rule violations.
• Priority 2 (Level 2): Applies Priority 1 recommendations and migrations that deliver extremely high performance improvements for severely constrained VMs.
• Priority 3 (Level 3 - Default Setting): The recommended balance for enterprise clusters. Applies Priority 1, 2, and 3 recommendations, executing migrations that offer good performance improvements relative to vMotion overhead.
• Priority 4 (Level 4): Applies Priority 1 through 4 recommendations, accepting moderate performance gains.
• Priority 5 (Level 5 - Aggressive): Applies all recommendations (Priority 1 through 5). DRS aggressively moves virtual machines to resolve even minor differences in host utilization or VM happiness. This can lead to excessive vMotion network traffic and frequent hypervisor CPU overhead.

Monitoring and Placement

VCF Operations can identify performance and capacity risks, while DRS performs cluster placement and balancing within its configured authority. Do not assume every Operations recommendation triggers a migration. Confirm automation levels, enabled integrations and placement constraints.

VM and Host Affinity / Anti-Affinity Rules

Affinity and anti-affinity rules govern the physical placement of virtual machines across ESXi hosts in a DRS cluster. They are essential for application high availability, multi-tier isolation, and software licensing compliance.

1. VM-to-VM Affinity and Anti-Affinity Rules

• VM-VM Affinity Rules: Forces designated virtual machines to reside together on the same physical ESXi host. Useful for latency-sensitive multi-process workloads where virtual machines exchange massive amounts of inter-VM network traffic, allowing communication across local hypervisor memory rather than physical network switches.
• VM-VM Anti-Affinity Rules: Forces designated virtual machines to execute on different physical ESXi hosts. This is standard best practice for redundant application tiers (e.g., placing two Active Directory Domain Controllers, redundant DNS servers, or SQL AlwaysOn cluster nodes on separate physical hardware to prevent a single host failure from taking down both redundant nodes).

2. VM-to-Host Affinity Rules (Rule Groups)

VM-to-Host affinity rules bind a defined VM DRS Group to a defined Host DRS Group. These rules are categorized into two critical operational types:

Enhanced vMotion Compatibility (EVC)

Live vMotion migrations require the destination ESXi host to support the CPU instruction sets exposed to the virtual machine by the source host. If an administrator attempts to vMotion a VM from an Intel 4th Gen Xeon host to an Intel 2nd Gen Xeon host, the migration will fail because the destination CPU lacks the advanced instructions (e.g., AVX-512) already registered by the running guest operating system.

Enhanced vMotion Compatibility (EVC) eliminates this problem by establishing a common CPU feature baseline across all hosts in the cluster:

• Feature Masking Mechanism: EVC uses processor hardware virtualization features to mask out advanced CPU instruction sets. When a VM powers on, ESXi exposes only the CPU instructions corresponding to the selected EVC baseline, ensuring that the VM can vMotion to any host in the cluster regardless of physical CPU generation differences.
• Hardware Vendor Boundary: EVC cannot bridge Intel and AMD processors. Cross-vendor vMotion between Intel and AMD is fundamentally unsupported because their CPU microarchitectures, register configurations, and virtualization extensions (Intel VT-x vs AMD-V) are mutually incompatible.

Cluster-Level EVC vs. Per-VM EVC

1. Cluster-Level EVC: Enforced across all hosts in a vSphere cluster. Any host added to the cluster must support the configured EVC baseline (or a newer processor). If an administrator attempts to add an older host that lacks the baseline features, vCenter blocks the addition.
2. Per-VM EVC (Introduced in vSphere 6.7 / Hardened in vSphere 8 & 9): Configured on the individual virtual machine properties (VM Options -> VM EVC Mode). The EVC baseline becomes an intrinsic attribute of the virtual machine, written directly into its .vmx configuration file:
   • The baseline travels with the VM as it moves across clusters, across independent vCenter Server instances, or into hybrid cloud environments (such as VMware Cloud).
   • Allows high-performance VMs to access bleeding-edge CPU features in a modern cluster while allowing legacy VMs in the same cluster to maintain conservative baselines for future migrations.

Stretched Compute Clusters: Architecture & Engineering

A vSphere Stretched Cluster spans two geographically separated physical sites located across a metropolitan area, creating a single logical compute and storage cluster:

• Active-Active Workload Mobility: Virtual machines can execute on either site and migrate seamlessly between Site A and Site B via live vMotion without downtime.
• Storage Synchronization: Stretched clusters rely on synchronous storage mirroring (such as vSAN Stretched Cluster or synchronous SAN replication). When a VM writes data, the write must be committed to storage at both Site A and Site B before an I/O acknowledgment is returned to the guest operating system.
• Network Latency Constraints: Because storage writes are synchronous, the supported latency depends on the storage design. A vSAN stretched cluster uses a 5 ms data-site RTT limit; a vSphere Metro Storage Cluster using an external array follows its validated vendor design.

Integrating DRS and HA in Stretched Clusters

Operating a stretched cluster requires careful coordination between DRS placement rules and HA failover policies:

1. DRS Site Affinity Rules: To avoid "cross-site traffic tromboning" (where a VM runs on Site A compute but accesses storage mirrored from Site B), administrators create Preferential ("Should run on") VM-Host affinity rules. Workloads with storage affinity to Site A are assigned to a Host DRS Group on Site A.
2. HA Cross-Site Failover: In the event of a catastrophic facility failure (e.g., Site A loses power), vSphere HA detects the host crashes. Because the DRS affinity rules were configured as "Should run" (soft rules), vSphere HA temporarily violates the affinity rule and restarts the affected VMs on Site B hosts.
3. Admission Control Sizing: To guarantee that Site B can survive the total failure of Site A, a symmetric two-site design must retain enough usable capacity at either site for the protected workload. Reserving 50% is an illustrative equal-site design, not a universal rule for unequal hosts or all protection scopes.

Realistic DRS & Affinity Troubleshooting Scenarios

Scenario 1: Critical Virtual Machine Blocked from HA Restart

Problem: After a power outage knocks out two hosts in a 6-host cluster, an enterprise financial reporting VM fails to restart. The vSphere Client logs an HA error: Cannot find a compatible host for VM restart due to affinity constraints.

Root Cause Analysis:

• The financial VM was configured with a Mandatory ("Must run on hosts in group") VM-Host affinity rule to comply with per-socket software licensing.
• The two hosts that lost power were the only two members of the designated Host DRS Group.
• Because "Must run" rules are hard constraints, vSphere HA strictly refuses to restart the VM on the four surviving hosts, preserving license boundaries at the expense of workload availability.

Resolution Procedure:

1. Restore an eligible host or expand the licensed/approved eligible host set. Change a mandatory placement rule only after the governing requirement permits it.
2. Recheck placement and power-on eligibility after approved recovery actions.
3. Align software licensing and mandatory placement rules with the intended failure-recovery design, then test the supported recovery path.

Scenario 2: vMotion Blocked by CPU Baseline Mismatch

Problem: An administrator attempts to migrate a virtual machine from a cluster of Intel Sapphire Rapids hosts to a newly added host equipped with Intel Emerald Rapids processors. The vMotion validation check fails with: The target host does not support the virtual machine's current hardware requirements.

Root Cause Analysis:

• EVC was not enabled on the cluster.
• When the VM powered on on the Sapphire Rapids host, it exposed native hardware CPU flags.
• The target host, although newer, had specific virtualization instructions disabled in its physical BIOS/UEFI firmware, preventing the VM from finding matching instruction sets.

Resolution Procedure:

1. Verify and enable all virtualization extensions (Intel VT-x, VT-d, NX/XD) in the target server's BIOS/UEFI firmware.
2. Inspect compatibility checks and select a supported EVC baseline. A running VM cannot shed CPU instructions it already exposed; a controlled power-off/power-on may be needed before a lower baseline takes effect.

Official Reading

Use the official 2V0-16.25 objective guide for scope and Broadcom technical documentation for the installed 9.0 component. This independent lesson was reviewed October 18, 2026; actual deployment support depends on the applicable version and configuration.

Review Takeaways

• DRS evaluates VM placement and resource efficiency; automation settings control which actions execute.
• Partially automated DRS handles initial placement but requires approval for balancing recommendations.
• Mandatory VM-host rules can prevent HA restart when every eligible host is lost.
• EVC establishes a common supported CPU baseline within one processor vendor; running VMs may need a power cycle to adopt changed features.