Implementing vSphere Storage DRS for automatic tiering

vSphere Storage DRS places virtual machines across storage tiers using datastore capacity, Storage I/O Control metrics and VM storage policies. It can recommend or automatically apply Storage vMotion moves that keep latency-sensitive workloads on faster media and capacity-heavy workloads on economical storage. This removes the need to manually track which VM belongs on which array.

Automatic tiering here means workload-level placement, not movement of individual hot blocks between SSD and HDD. Array caching and vSAN cache policies tier data below the hypervisor. Storage DRS moves eligible virtual disks between datastores, so policies should describe the placement outcome your organisation needs.

Design storage tiers around workload requirements

Treat tiers as service levels, not media labels. A performance tier might use enterprise NVMe datastores for SQL or VDI; a capacity tier might use lower-cost VMFS or NFS for test systems and archives. Tag datastores by service level, then use VM storage policies to express the requirement. This avoids assuming every datastore in a cluster offers equal latency, throughput and resilience.

Keep each datastore cluster within a sensible failure and latency boundary. Spanning Sydney with Melbourne or Brisbane over a WAN can make Storage vMotion long and fragile. Use separate clusters for distant sites, with replication or disaster-recovery tooling providing copies. Tiering must preserve the datastore, replica and site constraints already assigned to a workload.

A small proof of concept can confirm these assumptions. The two-node vSAN guide provides a compact vSAN example, although production design still requires fuller fault-domain and support planning.

Build the datastore and policy foundation

Create a datastore cluster, add datastores that can safely serve the same policy tier, and apply capacity reporting before enabling balancing. Keep datastores backed by different storage systems in separate management groups unless they genuinely share acceptable performance and availability. Confirm free-space thresholds, datastore heartbeat health and spare-capacity headroom before production balancing begins.

Build tag-based VM storage policies in Storage Policy-Based Management (SPBM) for each placement outcome, such as fast-local, balanced-local and capacity-local. A policy should match datastore tags and, where relevant, a vSAN storage policy or array capability. Assign workloads, then verify placement. Storage DRS cannot resolve contradictory rules, such as demanding flash performance while every eligible datastore has a capacity-only tag.

Enable and tune placement behaviour

Enable Storage DRS at cluster level, choose automatic or manual recommendations according to change-control needs, and schedule balancing for a maintenance window. Review initial placement separately from runtime balancing: automatic placement reduces surprise at VM creation, while scheduled balancing moves existing disks with Storage vMotion. Observe recommendations before granting broader autonomy.

Storage I/O Control supplies latency and throughput measurements to placement decisions. Set shares according to service tiers, reserve capacity for critical systems, and avoid promising fixed IOPS figures that the array cannot sustain. Keep database and latency-sensitive VMs pinned only where evidence shows policy cannot place them correctly; excessive pinning reduces the value of Storage DRS.

Test and automate the workflow

Validate the design in a non-production environment or representative lab. Replicate datastore tags, policies, SIOC settings and anti-affinity rules, then test the VM life cycle: create, power on, migrate, evacuate and fail over. The pilot should include datastore maintenance mode, Storage vMotion failure handling and a rollback before production use.

Automate evidence collection rather than every placement decision. Scheduled vCenter tasks, vROps or PowerCLI can expose datastore cluster balance, Storage DRS recommendations, policy compliance and free-space trends. For background on the wider platform, the VMware series is a practical companion. Record accepted moves in the change register so performance shifts and storage-tier outcomes remain auditable.

Plan for Australian operating conditions

Australian footprints add constraints. Sydney and Melbourne often host primary datacentre regions, while Brisbane can provide a recovery location. Tie tiers to data-sovereignty and latency requirements, and document which systems may cross an inter-capital path. National internet routes can vary, so a Storage DRS recommendation is not a substitute for tested disaster recovery.

Schedule movement outside business hours using local daylight-saving rules. NSW, Victoria, Tasmania and the ACT use AEST and AEDT, while Queensland and Western Australia keep standard time. Automations tied to UTC, local time or an external scheduler can drift by an hour twice a year. Test those transitions, alert on failed Storage vMotion tasks, and define a rollback that leaves source files intact.

Security and governance matter as much as performance. Australian organisations may need to map tier placement to Privacy Act 1988 duties, Australian Privacy Principles and applicable ACSC ASD Essential Eight controls. Confirm data location, administrative access and encryption with the security owner. For commercial deployments, check current VMware subscription packaging and support terms through the Australian reseller market, including how AUD quotes and GST are handled.

Roll out tiering with a controlled pilot

Apply the rollout with a small, measurable sequence rather than switching on full automation across the datacentre. These practices reduce operational risk:

• Test each storage policy against representative VM workloads and confirm that the selected datastore satisfies latency, capacity and resilience requirements.
• Keep a documented buffer of free capacity and verify that datastore maintenance mode can evacuate the tier without exhausting spare space.
• Review Storage DRS recommendations daily during the pilot, then fit recurring balancing into the approved maintenance calendar.
• Audit policy compliance, failed migrations, SIOC latency and datastore utilisation through one operations dashboard.

Move from pilot to production by starting with one application tier, capturing a baseline of latency, throughput and recovery time, and expanding when the evidence supports it. Review the design after major array, hypervisor or licensing changes, and involve storage, network, security and service owners in sign-off.

Choose a representative workload now, build its datastore cluster and storage policy in a safe test environment, and schedule the first Storage DRS recommendation review. That small exercise turns tiering from an abstract objective into a controlled operating change.