Study guide
2.2 Distributed Resource Scheduler (DRS) & Resource Pools
VMware Certified Professional - Data Center Virtualization VCP-DCV
Track your progress as you read
Finished sections get a check mark.
1 Introduction: VCP-DCV Exam Overview
About the VCP-DCV Exam (2V0-21.23)
2 Chapter 1: vSphere Architecture & Core Platform Technologies
1.1 vSphere 8.x Architecture and Components Overview 1.2 vCenter Server Appliance (vCSA) Architecture & Deployment 1.3 vSphere Distributed Services Engine (DSE) & DPUs 1.4 vSphere Products, Solutions & Workload Platform 1.5 vCenter Topology: SSO Domains & Enhanced Linked Mode 1.6 vSphere with Tanzu: Supervisor, Namespaces, Zones & Lifecycle 1.7 vSphere in the SDDC: vCenter Converter, vSphere Replication & SRM
3 Chapter 2: Compute Resources & Cluster Management
2.1 vSphere High Availability (HA) Architecture 2.2 Distributed Resource Scheduler (DRS) & Resource Pools 2.3 vMotion & Enhanced vMotion Compatibility 2.4 Virtual Machine Advanced Compute Configuration 2.5 Fault Tolerance, Proactive HA & Advanced Cluster Options 2.6 vSphere Cluster Services (vCLS) & Retreat Mode 2.7 Migration Types: Cold Migration, Storage vMotion & Cross vCenter Export
4 Chapter 3: Storage Technologies & VMFS Datastores
3.1 Storage Access Protocols & Multipathing 3.2 VMFS Datastore Architecture & Management 3.3 Storage Policies (SPBM) & Virtual Volumes (vVols) 3.4 Storage DRS & Storage I/O Control 3.5 RDM, PMem, NVMe, NVMe-oF & iSER Use Cases
5 Chapter 4: VMware vSAN Architecture & Operations
4.1 vSAN Core Architecture & Disk Groups 4.2 vSAN Fault Domains & Stretched Clusters 4.3 vSAN Storage Policies & Data Protection 4.4 vSAN Maintenance, Health Checks & Monitoring
6 Chapter 5: Virtual Networking Architecture & Configuration
5.1 Standard Switches (vSS) vs Distributed Switches (vDS) 5.2 Port Group Policies & NIC Teaming 5.3 VLAN Configuration & Security Policies 5.4 Network I/O Control (NIOC) & TCP/IP Stacks
7 Chapter 6: Security, Identity & Access Control
6.1 vCenter Single Sign-On (SSO) & Identity Sources 6.2 Role-Based Access Control (RBAC) & Global Permissions 6.3 Virtual Machine Encryption & Key Management 6.4 ESXi Host Security & vSphere Trust Authority 6.5 vSphere Certificate Management 6.6 VM Firmware, Secure Boot, vTPM & Virtualization-Based Security
8 Chapter 7: Lifecycle Management & Host Configuration
7.1 vSphere Lifecycle Manager (vLCM) Cluster Images 7.2 Baseline-Based Lifecycle Management 7.3 Host Profiles & Cluster Quickstart 7.4 Content Libraries & Virtual Machine Deployment 7.5 ESXi Host Configuration: Time, Services, Product Locker & Boot Options 7.6 vCenter Lifecycle: Update Planner, VAMI Patching & Upgrades 7.7 Virtual Machine Snapshots & VM Creation Methods
9 Chapter 8: Monitoring, Performance Tuning & Troubleshooting
8.1 Performance Monitoring & Metrics 8.2 Command-Line Diagnostics & esxtop 8.3 Log Analysis & Diagnostic Data Collection 8.4 Troubleshooting Common Infrastructure Scenarios 8.5 Alarms & vCenter Appliance Health Monitoring
2.2 Distributed Resource Scheduler (DRS) & Resource Pools
Key Takeaways Explain This Topic AI
In vSphere 7.0 and later, DRS runs every minute and scores each VM (0-100%) on how efficiently it gets the CPU, memory, and network resources it demands, then moves VMs whose score another host can improve.
Automation levels range from Manual (recommendations only) and Partially Automated (automated initial placement, manual migration) to Fully Automated (automated initial placement and dynamic load balancing).
The DRS migration threshold slider spans five priority levels (1 Conservative to 5 Aggressive), balancing standard deviation improvements against vMotion overhead.
Predictive DRS integrates vCenter Server with VMware Aria Operations to forecast recurring workload spikes and trigger proactive migrations before contention occurs.
Shares use a 1:2:4 Low:Normal:High ratio (500/1,000/2,000 CPU shares per vCPU for a VM; 2,000/4,000/8,000 for a resource pool) and matter only under contention; reservations are guaranteed and limits are hard caps.
Last updated: September 2026
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
Automation Level Initial Placement (Power-On) Dynamic Load Balancing (Runtime) Administrative Intervention
Manual DRS generates recommendations DRS generates recommendations Administrator must manually view and click "Apply Recommendations" for all actions.
Partially Automated Fully automated DRS generates recommendations Initial power-on placement occurs automatically; ongoing balancing migrations require manual approval.
Fully Automated Fully automated Fully automated DRS places VMs at power-on and migrates running VMs dynamically without administrative confirmation.
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:
Priority 1 (Conservative) : Applies only mandatory recommendations. These include vacating hosts entering maintenance mode, resolving DRS rule violations, or satisfying hard affinity constraints.
Priority 2 : Applies Priority 1 recommendations and migrations that deliver extremely significant performance improvements.
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.
Priority 4 : Applies recommendations that provide even minor performance enhancements.
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.
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).
Aria Operations transmits predictive forecast models to vCenter Server.
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:
- Setting Relative Weight VM CPU Shares (per vCPU) VM Memory Shares (per MB) Resource Pool CPU / Memory Shares
- Low 1x 500 5 2,000 / 81,920
- Normal 2x 1,000 10 4,000 / 163,840
- High 4x 2,000 20 8,000 / 327,680
- Custom User Defined Any value Any value Any value
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:
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.
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.
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.