Choosing the Right DRS Automation Level in vSphere
Learn how vSphere DRS automation levels work, see a concrete three‑host example, understand the trade‑offs, and verify your choice with the vSphere Client or PowerCLI.
08 Oct 2025, 03:12 UTC

Problem: CPU spikes keep you chasing manual VM moves
In a production vSphere cluster, you notice that one host’s CPU usage regularly climbs above 80 % during peak hours, while other hosts sit idle. Manually migrating VMs to rebalance the load is time‑consuming and error‑prone, especially when the cluster runs dozens of workloads with varying priorities.
Thesis: Matching the DRS automation level to your operational tolerance gives you automatic load‑leveling without unnecessary overhead.
1. DRS automation levels – what they actually do
VMware Distributed Resource Scheduler (DRS) evaluates host CPU, memory, and (when Storage DRS is enabled) storage I/O every few minutes. Based on configurable thresholds it generates migration recommendations. The three automation levels determine how those recommendations are acted upon:
- Manual – DRS only shows recommendations; no vMotion occurs without admin approval.
- Partially Automated – Initial placement of powered‑on VMs and migrations for newly powered‑on VMs are automatic; running VMs require manual approval.
- Fully Automated – DRS continuously runs vMotion to keep host utilization within the target range, with no admin intervention.
The underlying algorithm is the same for all levels; only the decision to execute a recommendation changes.
2. Worked example: three‑host cluster with mixed workloads
Assume a cluster named ProdCluster with three ESXi hosts (A, B, C) sharing a VMFS datastore and having identical CPU generations (EVC mode enabled). The cluster runs a mix of low‑priority web servers and a high‑priority database VM.
Scenario: Host A’s CPU usage rises to 84 % while Hosts B and C are at 45 % and 38 % respectively. The DRS migration threshold is set to the default (medium).
- Manual: DRS displays a recommendation to vMotion a low‑priority web VM from Host A to Host B. No action occurs until an admin approves it.
- Partially Automated: If the web VM is powered off and then powered on, DRS would place it on the least‑loaded host automatically. While it is running, the recommendation stays manual.
- Fully Automated: DRS immediately initiates a vMotion of the web VM. After migration, Host A’s CPU drops to ~66 %, Host B rises to ~55 %, and Host C remains unchanged. The cluster is now more balanced without admin clicks.
This illustrates how the automation level directly influences whether the cluster reacts in real time or waits for human approval.
3. Trade‑offs and practical limitations
While Fully Automated DRS reduces admin effort, it introduces considerations:
- Network traffic: Each vMotion copies the VM’s active memory over the vMotion network. Frequent migrations can increase utilization of the 10 GbE (or 25 GbE) vMotion links and add latency to latency‑sensitive applications.
- Shared storage & CPU compatibility: DRS requires access to a common datastore and compatible CPU features (EVC mode). If hosts differ in CPU generations and EVC is not enabled, DRS will refuse migrations.
- Storage latency blindness: Standard DRS does not monitor storage I/O latency. If a host experiences high storage latency but CPU/memory are balanced, DRS will not act unless Storage DRS is also enabled and configured.
- Over‑aggressive thresholds: Lowering the migration threshold (e.g., to 1 %) causes DRS to trigger vMotion for tiny imbalances, leading to unnecessary network load and possible performance jitter.
These limits mean that the “right” level often depends on workload sensitivity, network capacity, and operational staffing.
4. Verifying and adjusting the automation level
You can view and change the setting from the vSphere Client or via PowerCLI.
Via vSphere Client:
- Select the cluster →
Configure→vSphere DRS→Edit. - In the
Automation Leveldropdown, choose Manual, Partially Automated, or Fully Automated. - Adjust the
Migration Thresholdslider if needed, then clickOK.
Via PowerCLI (requires ViAdmin or ClusterAdmin role):
# Connect to vCenter first
Connect-VIServer -Server vcenter.example.com -Credential (Get-Credential)
# Set the cluster to Fully Automated
Set-Cluster -Name 'ProdCluster' -DrsAutomationLevel FullyAutomated -Confirm:$false
# Verify the change
(Get-Cluster 'ProdCluster').DrsAutomationLevel
To confirm that a migration occurred as a result of the change:
- Open
Monitor → vSphere DRS → Recommendationsin the client; recent vMotion entries show source and destination hosts. - Run:
Get-DRSRecommendation -Cluster (Get-Cluster 'ProdCluster')to see pending or executed recommendations. - Check host CPU usage before and after in
Host → Monitor → Performanceor review the vMotion log undervCenter → Logs → vSphere DRS.
Closing: Pick the level that matches your tolerance for automation
If your team can review and approve each migration, start with Manual or Partially Automated to observe DRS’s behavior. For clusters where admin time is limited and the network can sustain regular vMotion, Fully Automated provides continuous load‑leveling—just watch the migration threshold and ensure shared storage/EVC requirements are met. Validate any change with the steps above, and adjust the threshold if you notice excessive vMotion traffic.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.