2.2 Distributed Resource Scheduler (DRS) & Resource Pools

Distributed Resource Scheduler (DRS) & Resource Pools

VMware vSphere Distributed Resource Scheduler (DRS) aggregates computing capacity across an ESXi cluster to balance workloads, optimize resource distribution, and enforce governance policies. By continuously analyzing virtual machine resource consumption and host utilization, DRS automates initial virtual machine placement and dynamically migrates running workloads via vMotion to eliminate bottlenecks.

---

DRS Architecture & The VM DRS Score

In vSphere 7.0 and later, DRS runs every 60 seconds (earlier releases ran every 5 minutes), and it also acts on events such as a VM power-on or a host entering maintenance mode.

Historically, DRS focused primarily on balancing cluster-wide host utilization metrics. Modern vSphere DRS centers its scheduling decisions around the VM DRS Score, which measures the execution efficiency of each virtual machine independently of host utilization.

Metrics Driving the VM DRS Score

The VM DRS Score ranges from 0% to 100% and is displayed in five 20% buckets (0-20%, 20-40%, 40-60%, 60-80%, and 80-100%). A higher score means the VM gets the resources it demands with little contention. DRS computes an efficiency for CPU, memory, and network (what the VM actually gets divided by what it demands) and multiplies them together. Along the way it applies costs such as:

• CPU Run Time vs. CPU Ready Time (%RDY): Measures how frequently a virtual machine is ready to execute instructions but must wait in the hypervisor scheduling queue due to physical core saturation.
• CPU Latency (%MLMTD / %CSTP): Tracks time lost to hypervisor throttling or co-scheduling skew on multi-vCPU virtual machines.
• Memory Swap & Ballooning Latency: Quantifies performance penalties incurred when a host forces the VM to reclaim memory via the vmmemctl balloon driver or hypervisor .vswp paging.
• Memory Granted vs. Active Working Set: Evaluates whether the virtual machine has sufficient physical memory allocated to service its active cache and working set without thrashing.

When a virtual machine's DRS score degrades into a lower bucket, DRS searches for a destination host in the cluster where migrating that VM will improve its score without degrading the scores of existing workloads on the target host.

---

Automation Levels & Migration Thresholds

DRS behavior is governed by two primary cluster configuration parameters: the Automation Level and the Migration Threshold.

DRS Automation Levels

Migration Threshold Slider

The Migration Threshold slider controls how aggressively DRS applies recommendations to rectify cluster imbalance and improve VM DRS scores. The slider defines five discrete priority levels:

1. Priority 1 (Conservative): Applies only mandatory recommendations. These include vacating hosts entering maintenance mode, resolving DRS rule violations, or satisfying hard affinity constraints.
2. Priority 2: Applies Priority 1 recommendations and migrations that deliver extremely significant performance improvements.
3. Priority 3 (Default): Applies Priority 1, 2, and recommendations offering moderate performance gains. This level represents the optimal balance between performance optimization and vMotion network overhead.
4. Priority 4: Applies recommendations that provide even minor performance enhancements.
5. Priority 5 (Aggressive): Applies all recommendations (Priority 1 through 5). DRS aggressively rebalances workloads even for slight statistical gains, which can introduce unnecessary vMotion network traffic and hypervisor stun events.

---

Predictive DRS (pDRS)

Traditional DRS is reactive: it detects resource contention, high CPU ready times, or memory exhaustion after they manifest, and only then calculates migration recommendations. In contrast, Predictive DRS (pDRS) is proactive.

How Predictive DRS Operates

pDRS integrates vCenter Server DRS with VMware Aria Operations (formerly vRealize Operations). Aria Operations continuously analyzes historical performance patterns, learning daily, weekly, and monthly utilization cycles for every workload.

1. Aria Operations identifies recurring usage spikes (for example, a payroll batch process that drives a database VM to 95% CPU utilization every Friday at 08:00 AM).
2. Aria Operations transmits predictive forecast models to vCenter Server.
3. Predictive DRS schedules and executes a vMotion migration before the spike occurs (e.g., at 07:45 AM), moving the VM to an ESXi host with deep resource headroom. Contention is prevented entirely.

+--------------------------------------------------------------------------+
|                       Predictive DRS Architecture                        |
+--------------------------------------------------------------------------+
|  VMware Aria Operations (vROps)                                          |
|    └── Analyzes historical utilization trends across days/weeks          |
|    └── Forecasts future compute spike: 'VM-DB1 spikes at 08:00 AM'       |
|         │                                                                |
|         ▼ (Transmits Predictive Model)                                   |
|  vCenter Server Distributed Resource Scheduler (DRS)                     |
|    └── Uses the forecast to act before the anticipated spike           |
|    └── Proactively migrates VM-DB1 to underutilized Host 3 at 07:45 AM   |
|    └── Contention completely avoided                                     |
+--------------------------------------------------------------------------+

---

DRS Affinity & Anti-Affinity Rules

Affinity rules enforce topological placement constraints on virtual machines and ESXi hosts. Configuring these rules correctly ensures compliance, high availability, and software licensing conformance.

1. VM-VM Affinity Rules

• Purpose: Forces specified virtual machines to remain colocated on the same ESXi host.
• Common Use Case: Multi-tier applications (e.g., a web front-end and application service) that communicate with high packet volumes, benefiting from local hypervisor memory-speed networking.

2. VM-VM Anti-Affinity Rules

• Purpose: Mandates that specified virtual machines must reside on different ESXi hosts.
• Common Use Case: Redundant infrastructure services, such as Active Directory Domain Controllers, clustered database instances, or network firewalls. If one host suffers a physical failure, the redundant peer VM remains operational on a separate physical node.

3. VM-Host Affinity Rules

VM-Host rules bind a designated DRS VM Group to a DRS Host Group. These rules are implemented using two distinct enforcement mechanisms:

• "Must Run On" (Hard Rule): The virtual machines in the group must run on hosts within the designated host group under all circumstances. If all hosts in the target host group fail or are placed into maintenance mode, the VMs will not power on or migrate to other hosts in the cluster. vSphere HA will respect the hard rule and will not violate it during a failover event. Essential for strict per-core physical software licensing.
• "Should Run On" (Soft Rule): Virtual machines prefer to run on the designated host group during normal operations. DRS honors this placement during load balancing. However, if target hosts become unavailable due to failure or maintenance, DRS and vSphere HA will violate the rule to restart and keep the virtual machines running on surviving hosts.

---

Resource Pool Architecture: Shares, Reservations, and Limits

A Resource Pool is a logical boundary that partitions physical CPU and memory resources among virtual machines or subordinate pools within a cluster or standalone host.

Core Allocation Parameters

• Reservation: The guaranteed physical allocation of CPU (in MHz) or memory (in MB/GB) that the hypervisor reserves for the resource pool or VM. The hypervisor enforces admission control: if the cluster lacks unreserved physical capacity, virtual machines assigned to the reservation cannot power on.
• Limit: An absolute ceiling on CPU or memory consumption. Even if physical hardware is 90% idle, a VM or resource pool capped by a limit cannot consume resources beyond that ceiling.
• Shares: A relative priority weighting that dictates resource distribution strictly during periods of physical contention.

The 1:2:4 Share Ratio

vSphere defines standard share values using a consistent 1:2:4 ratio across Low, Normal, and High settings:

A resource pool's default shares equal those of a VM with 4 vCPUs and 16 GB of memory, so a pool set to Normal competes with a single mid-sized VM at the same level, not with the combined shares of the VMs inside it.

Exam Trap on Shares: Resource shares have zero operational effect when physical compute resources are plentiful. If physical CPU utilization is at 60%, a virtual machine configured with Low shares receives 100% of its requested CPU cycles. Shares only influence scheduling when physical CPU or memory utilization reaches saturation (100%).

Expandable Reservations Mechanics

When a child resource pool is configured with Expandable Reservation enabled:

1. If a virtual machine inside the child pool powers on and requests a reservation that exceeds the child pool's local unreserved pool capacity, the child pool requests the difference from its parent pool.
2. If the parent pool has unreserved capacity (or is also set to Expandable and can borrow from the cluster root), the reservation request succeeds, and the VM powers on.
3. If Expandable Reservation is disabled on the child pool, any reservation request exceeding the child pool's local reservation ceiling is immediately rejected, even if the parent pool or cluster has gigabytes of unreserved capacity available.