A Minimal Storage DRS Design for a Small vSphere Cluster

Storage DRS (SDRS) is easy to over‑configure. Teams enable it with default aggressive automation, watch VMs shuffle during business hours, and then disable it entirely. The useful middle ground is a deliberately small design: one datastore cluster, conservative thresholds, and manual or partially automated mode until you trust the recommendations. This note walks through that minimal design, where the trust boundaries sit, and how to verify it is doing what you expect.

Requirements and assumptions

Storage DRS is a vCenter feature, not an ESXi host feature. Before designing anything, confirm:

• vCenter Server manages the cluster (SDRS does not exist on standalone hosts).
• At least two shared datastores visible to the same hosts — SDRS balances between datastores in a datastore cluster, so a single datastore gives it nothing to do.
• Datastores of compatible type (mixing VMFS and NFS in one datastore cluster is allowed but limits some recommendations; mixing with vVols has its own rules — check your vSphere version's documentation).
• Storage vMotion licensing, since SDRS migrations are Storage vMotion operations under the hood.

Version assumption: behavior described here matches vSphere 7.x/8.x. Earlier releases differ in default thresholds and I/O metric handling.

The smallest suitable design

Resist the urge to tune everything. A minimal, defensible configuration is:

1. Create one datastore cluster containing only the datastores that should genuinely be treated as interchangeable capacity for the same VM population.
2. Set automation level to No Automation (Manual Mode) initially. SDRS will generate placement and migration recommendations but not execute them.
3. Leave space utilization threshold at the default (80%) and I/O latency threshold enabled at its default (15 ms) unless you have a measured reason to change them.
4. Keep SDRS affinity rules empty until a real requirement appears (e.g., two VMs that must not share a datastore for failure‑domain reasons).

After one to two weeks of reviewing recommendations in the vSphere Client (Datastore Cluster > Monitor > Storage DRS > Recommendations), switch to Fully Automated if the recommendations consistently match what you would have done yourself. This staged approach directly addresses the common failure of unexpected data movement: you see what SDRS would do before letting it do anything.

Trust and data boundaries

SDRS decisions happen entirely inside vCenter. The relevant boundaries:

• vCenter to storage array: SDRS acts on capacity and latency metrics vCenter collects; it does not need array credentials. Array‑level credentials (for vendor tools or VASA providers) should live only in vCenter or the vendor plug‑in, never in host‑level scripts or cron jobs on ESXi.
• SDRS to hosts: migrations execute as Storage vMotion, which moves data through the host (or offloads via VAAI where the array supports it). The data path is host‑to‑storage; no VM data transits vCenter.
• Administrative boundary: anyone with datastore cluster modify rights can change automation level. Treat that as a change‑controlled action, because flipping to Fully Automated can start moving terabytes without further prompting.

Operational checks

These checks assume vSphere Client access with at least read‑only rights on the datastore cluster:

• Confirm SDRS is enabled and review its mode: Datastore Cluster > Configure > Storage DRS. Verify the automation level matches what change control says it should be.
• Review recommendations history before and after enabling automation. A healthy minimal setup produces few recommendations outside of initial placement.
• Watch datastore utilization in the cluster's Monitor view. SDRS acting correctly looks like utilization converging toward balance, not oscillation.
• For migration errors, check vCenter tasks and the vpxd log on the vCenter appliance (/var/log/vmware/vpxd/vpxd.log), filtering for Storage DRS or RelocateVM events. Requires shell access to the VCSA.

Note that SDRS status is a vCenter‑side view; there is no reliable per‑host CLI that reports SDRS cluster state, so operational checks should center on vCenter rather than esxcli.

Failure modes

• Array or path degradation: if a target datastore's array is degraded, Storage vMotion migrations can stall or fail, and SDRS may keep generating recommendations against an unhealthy target. Mitigation: monitor array health with vendor tooling and set SDRS to Manual during any storage maintenance window.
• Migration network contention: Storage vMotion consumes host and network resources. On hosts without dedicated provisioning traffic, large migrations during peak load can affect VM performance. Mitigation: keep automation off during business hours, or use SDRS scheduling (available in the datastore cluster settings) to run fully automated only in a defined window.
• Threshold oscillation: if datastores hover near the space threshold, SDRS can repeatedly migrate the same VMs. Mitigation: raise free space so utilization sits comfortably below threshold, rather than tuning the threshold itself.

Conditions that would change this design

Revisit the minimal design when any of these become true: you add datastores with different performance tiers (split into separate datastore clusters per tier); you adopt vVols or vSAN (SDRS applies differently or not at all — vSAN does its own balancing); VM count grows enough that manual recommendation review becomes a bottleneck; or you need anti‑affinity between specific VMs' disks for availability reasons, which is a legitimate use of SDRS rules.

The core principle: SDRS is a recommendation engine first and an automation engine second. Run it in manual mode until its judgment is proven against yours, keep the blast radius of a mode change in mind, and the feature earns its keep without surprising you.