In this 17th part of the VMware vSphere 8 Nested Home Lab series, we will learn to configure VMware vSphere DRS or Distributed Resource Scheduler.
What Is DRS?
Distributed Resource Scheduler (DRS) is a vSphere feature that automatically balances VM workloads across a cluster of ESXi hosts. It uses real-time metrics to decide when and where to migrate VMs using vMotion, ensuring optimal resource utilization and performance.
Think of DRS as your cluster’s tactical strategist—always watching, always optimizing.
How DRS Works
DRS evaluates CPU and memory usage every few minutes. If it detects imbalance, it initiates live migrations to redistribute VMs across hosts.
Key Metrics:
- VM Memory Demand: Active + swapped + shared + idle buffer
- CPU Demand: Historical and real-time CPU usage trends
DRS uses these to calculate host load and decide whether to migrate VMs.
Step-by-Step: Enabling DRS in vSphere 8
Let’s walk through the process of activating DRS in a vSphere 8 cluster. Login to vCenter Server at https://vcenter01.virtshinobi.local/ui using admin credentials.
In the Hosts and Clusters view, select Cluster-01. On the right side pane navigate to Configure tab and select vSphere DRS under Services. Click on Edit.
Toggle vSphere DRS to ON.
Automation Level:
DRS offers three modes of operation:
| Mode | Description |
|---|---|
| Manual | Admin reviews and applies all placement/migration recommendations manually |
| Partially Automated | Initial placement is automatic; migrations require manual approval |
| Fully Automated | DRS handles everything—placement and migrations—autonomously |
Select Fully Automated.
Migration Threshold:
You can also fine-tune Migration Thresholds from conservative to aggressive, controlling how sensitive DRS is to imbalance.
Predictive DRS (with vRealize Ops)
When paired with vRealize Operations Manager, DRS becomes clairvoyant. It predicts future resource demands and migrates VMs before contention occurs.
Example: If a VM spikes in CPU usage every morning at 9 AM, Predictive DRS will preemptively migrate it to a better host at 8:55 AM.
We will leave it disabled for this case.
Virtual Machine Automation:
VM Overrides & Affinity Rules
DRS allows granular control:
- VM Overrides: Customize automation settings per VM
- Affinity Rules:
- Keep VMs together (for chatty apps)
- Separate VMs (for HA scenarios)
- VM-Host Affinity (for licensing or hardware constraints)
Enable Virtual Machine Automation.
VM Device Stun Time Limits:
In vSphere 8 Update 2 and later, VMware introduced enhanced control over VM device stun time limits—especially relevant for VMs with vGPU profiles that undergo vMotion during DRS operations.
What Is VM Device Stun Time?
Stun time refers to the brief pause a VM experiences during the final phase of vMotion, when memory pages and device states are synchronized between source and destination hosts. For VMs with vGPU devices, this can be significantly longer due to the large framebuffer memory involved.
Why It Matters in DRS
DRS uses stun time estimates to decide whether a VM migration is safe and acceptable. If the estimated stun time exceeds the configured limit, DRS may skip the migration to avoid service disruption.
Since this is a Home Lab environment, we will not configure and custom VM Device Stun Time Limits.
Passthrough VM DRS Automation:
In vSphere 8, Passthrough VM DRS Automation is a specialized enhancement designed to support vGPU-enabled virtual machines during DRS-driven vMotion operations. These VMs often have large device memory footprints, which can lead to longer stun times during migration. This feature ensures that DRS can safely and automatically migrate such VMs—but only if the estimated stun time is within acceptable limits.
What It Does
When enabled, Passthrough VM DRS Automation allows DRS to:
- Evaluate stun time estimates for VMs with passthrough devices (e.g., vGPU)
- Automatically migrate VMs only if the stun time is below the configured threshold
- Skip migrations that could cause performance disruption due to excessive stun time
Again since this is a Nested Home Lab environment, we don’t have any passthrough devices and hence we will not be enabling it.
Next click on the Additional Options tab.
VM Distribution:
The VM Distribution option in VMware DRS is a subtle but powerful setting that influences how evenly virtual machines are spread across hosts in a cluster. It’s especially useful when you’re aiming for high availability or want to minimize the blast radius of host failures.
What VM Distribution Does
When enabled, this option:
- Encourages even distribution of VMs across all ESXi hosts in the cluster
- Reduces the chance of VM concentration on a single host
- Can lower the number of migrations triggered by DRS, especially when paired with a conservative migration threshold
Considerations and Potential Drawbacks:
- Increased vMotion Activity: Enabling VM Distribution can lead to a slight increase in vMotions as DRS actively works to achieve a more even distribution, even when resources are not severely imbalanced.
- Performance Trade-off: The emphasis on distribution might, in some cases, lead to a marginal degradation in the efficiency of pure load-balancing operations if the system prioritizes distribution over immediate resource optimization for individual VMs.
- Automation Level: DRS offers different levels of automation, from manual to fully automated. For VM Distribution, you’ll want to ensure DRS is configured to actively enforce this setting within your chosen automation level.
In summary: Enabling “VM Distribution” in vSphere DRS is a recommended practice for enhancing the resilience of your virtualized environment against host failures, though it’s important to be aware of the potential for increased vMotion activity as a trade-off.
We will leave this setting at default value of disabled.
CPU Over-Commitment
This setting controls the vCPU:pCPU ratio—essentially how many virtual CPUs can be provisioned per physical core. It’s a strategic lever for balancing performance and consolidation.
For example:
- A ratio of 1 means 1 vCPU per 1 pCPU
- A ratio of 5 allows up to 5 vCPUs per 1 pCPU
DRS uses this ratio to limit VM power-on operations and guide placement decisions, ensuring hosts aren’t overloaded beyond the defined threshold.
Considerations for Enabling CPU Over-Commitment:
- Performance Impact: A CPU over-commitment ratio of 1:1 to 3:1 is generally considered safe with no significant performance issues. However, ratios of 3:1 to 5:1 can start to cause performance degradation depending on the workload type.
- Workload Characteristics: CPU over-commitment is more viable for workloads with low average CPU utilization, as it allows for better consolidation and resource sharing. Highly CPU-intensive workloads may not benefit or could suffer performance hits.
- DRS Balancing: Disabling CPU overcommit can force DRS to rebalance VMs to hosts with 1:1 usage of physical CPUs, even if memory is available on other nodes, potentially preventing proper rebalancing, so re-enabling a modest level of overcommit might be necessary for optimal balancing.
- Virtual Machine Power-On: When CPU over-commitment is enabled, VMs will only power on if the over-commitment ratio is not violated at the time of power-on.
- High Availability (HA) Failures: CPU over-commitment is not enforced during high availability event scenarios, such as a host failure.
- Hyper-Threading (HT): Be aware that enabling Hyper-Threading can double the count of total logical cores and may impact performance, so consider this when configuring CPU over-commitment.
- Licensing: While a separate concern from technical configuration, remember that VMware’s per-CPU licensing rules and minimum purchase requirements (72 cores per product as of March 2025) are distinct from CPU over-commitment settings, according to Licenseware.
Recommendation:
Start with a conservative CPU over-commitment ratio and gradually increase it while closely monitoring your virtual machine performance. It’s advisable to disable it if performance issues arise or if your environment requires consistent high CPU performance for critical applications.
Since this is a Home Lab environment we will set the CPU Overcommit ratio to 5:1. In a production environment you can start with 3:1 ratio and increase or lower it depending the behavior of the virtual machine workloads.
Scalable Shares:
Scalable Shares is a game-changing feature introduced in vSphere 7 that dynamically adjusts resource pool shares based on the number and size of workloads inside each pool. It solves the classic “priority pie paradox,” where fewer VMs in a lower-priority pool could unfairly receive more resources per VM than a busier, higher-priority pool.
What Are Scalable Shares?
Traditionally, resource pools had static share values (e.g., High = 8000 CPU shares), which were divided equally among all VMs in the pool. This could lead to unintended resource distribution, especially when pools had different VM counts.
Scalable Shares changes that by:
- Auto-scaling share values based on the number of VMs and their configured shares
- Maintaining intended priority ratios between resource pools
- Recalculating entitlements dynamically as VMs are added or removed
Why It Matters
Without scalable shares:
- A pool with fewer VMs might give each VM more resources than a busier pool
- Admins had to manually adjust shares to maintain fairness
With scalable shares:
- Resource pools behave more like QoS classes
- Entitlements reflect both priority level and workload density
- Ideal for high-churn environments like Kubernetes namespaces or dynamic labs
We will leave this option disabled and move on to next section.
Next click on the Power Management tab.
DPM or Distributed Power Management:
Distributed Power Management (DPM) is a complementary feature to DRS that helps optimize energy usage across the cluster. It’s like giving your ESXi hosts the ability to meditate—powering down when demand is low and waking up when the action heats up.
You can configure DPM in three ways:
| Mode | Description |
|---|---|
| Disabled | DPM is turned off; hosts remain powered on regardless of demand |
| Manual | DPM suggests host power actions; admin must approve |
| Automatic | DPM autonomously powers hosts on/off based on cluster demand |
DPM Threshold:
The threshold slider ranges from Conservative (1) to Aggressive (5):
| Level | Behavior |
|---|---|
| 1 (Conservative) | Only high-priority recommendations (e.g., critical power-on for HA) |
| 5 (Aggressive) | Includes low-priority suggestions (e.g., minor power savings) |
Each level adds more recommendation types:
- Level 1: Priority 1 only
- Level 2: Priority 1–2
- …
- Level 5: Priority 1–5
We will leave it at the default disabled state.
Next click on the Advanced Options tab.
VMware DRS offers a rich set of advanced options that let you fine-tune cluster behavior beyond the standard automation and migration thresholds. These settings are ideal for power users.
You will see that the advanced option MaxVcpusPerCore value is already set to 5. This is because of the CPU Overcommit ratio we configured earlier. Click Ok to close the configuration wizard and enable DRS on the vSphere cluster.
We will not be configuring any other advanced options. Below is a breakdown of the most impactful advanced settings. Feel free to explore them out.
| Option | Purpose |
|---|---|
PercentIdleMBInMemDemand | Adjusts how idle memory affects VM demand calculation |
MinPoweredOnCpuCapacity | Ensures minimum CPU capacity stays online (MHz) |
MinPoweredOnMemCapacity | Ensures minimum memory capacity stays online (MB) |
MaxVcpusPerClusterPct | Limits CPU overcommitment ratio across the cluster |
VgpuVmConsolidation | Packs smaller vGPU VMs to free up GPU space for larger workloads |
LBMaxVmotionPerHost | Limits vMotion operations per host during load balancing |
PassthroughRequireDrs | Ensures vMotion stun time fits within DRS estimates |
PassthroughDrsAutomation | Enables automatic DRS for vGPU VMs if stun time is acceptable |
PassthroughForceDrsAutomation | Forces DRS automation even if stun time exceeds default limits |
Use Cases & Tips
- vGPU Workloads: Use
VgpuVmConsolidationandPassthroughDrsAutomationto optimize placement and maintenance mode evacuations. - Burst-prone clusters: Tune
PercentIdleMBInMemDemandto make DRS more responsive to real-time demand. - Mission-critical apps: Set conservative values for CPU/memory thresholds to avoid performance dips.
- Lab environments: Experiment with aggressive migration thresholds and override settings for granular control.
Once the Cluster Reconfigure task is complete, you should see that DRS is enabled and a summary of the various configuration options we selected while configuring it.
