ONTAP for VDI & Virtual Desktops: Design, Provisioning & Performance

Virtual desktop infrastructure is one of the most storage-sensitive workloads ONTAP runs: hundreds of near-identical VMs hammer the array in a boot storm every morning, then idle. ONTAP is a natural fit because it was built for exactly this pattern — shared gold images, copy-on-write clones, inline deduplication, and QoS that keeps noisy pools from starving production. This guide covers the workload math, clone and protocol design for VMware and Citrix, performance guardrails, antivirus offload, cloud VDI on FSx for ONTAP, and a CLI runbook with ONTAP 9.x commands.

1. The VDI workload profile

Understanding what VDI actually does to storage is the difference between a design that works and one that melts at 9:00 AM:

• Boot storms: when a shift starts (or after a maintenance reboot), hundreds of desktops boot simultaneously. Each desktop bursts 20–60 IOPS of small (<8 KB) random reads for 3–10 minutes as the OS loads.
• Login storms: profile loads, group policy, and antivirus definition refresh add sustained small-block I/O on top of the boot burst.
• Steady state: after the storm, most desktops idle at 0–2 IOPS with occasional application activity. This is why average-IOPS sizing fails — you must size for the peak, then use QoS to smooth it.
• AV storms: on-access antivirus scanning inside every desktop multiplies read/write amplification. Offload it to the array with FPolicy (below).

A rough planning figure: a typical knowledge-worker desktop needs ~10 IOPS steady state and 30–60 IOPS at boot; a 1,000-desktop pool booting in 15 minutes peaks around 20,000–40,000 IOPS for that window. Flash (AFF or ASA) absorbs this trivially; the design work is making sure clones, QoS, and protocol settings convert that IOPS into fast logins rather than queueing.

2. Storage layout: gold images and clones

The core trick of VDI on ONTAP is that 99% of a desktop's disk content is identical to every other desktop. Store it once, clone it cheaply:

• Gold (master) image: one volume containing the prepared, sysprepped desktop OS with applications installed. Keep it in its own volume so it can be snapshotted, updated, and rolled back independently.
• Clones: ONTAP FlexClone creates a writable point-in-time copy of a volume in seconds, consuming only the blocks that change (copy-on-write). Clone the gold image volume per desktop pool, then let the hypervisor layer its own linked/instant clones on top.
• Space efficiency: enable deduplication and compression on clone volumes — dedupe collapses identical blocks across all desktops (often 50–90% savings on OS data), and compression helps the boot image. Inline dedupe means the savings happen at write time with no background job.

Gold image updates become a 15-minute operation: maintain a new gold image, snapshot it, clone it to a test pool, validate, then re-point the pool's parent. Because the old clones reference the old gold image's blocks, you can roll back instantly by re-pointing to the previous snapshot — no mass re-copy ever happens.

3. Protocol choice: NFS vs SMB

Key settings per protocol:

• NFS datastores: create the volume with -vserver <svm> -volume <vol> -junction-path /vdi, enable NFS export with vserver nfs create, and export with vserver export-policy rule create restricted to the ESXi host subnet. Set volume efficiency on for dedupe.
• SMB shares: create the CIFS server and a share with vserver cifs share create -share-name vdi$ -path /vdi -share-properties oplocks,continuous-availability. Continuously available shares require the volume to have the cifs option and the SVM's CIFS server to be configured for SMB 3.0.
• Enable vserver cifs options modify -vserver <svm> -smb3-encryption enabled where compliance requires encrypted SMB.

4. Provisioning models

• VMware instant clones: on NFS datastores, Horizon clones a VM in seconds by leveraging the array's snapshot + copy-offload. ONTAP supports VAAI (vStorage APIs for Array Integration): hardware-assisted cloning (clone-blocks) and space reclamation (UNMAP) are the two that matter for VDI. Verify with vserver nfs on -vserver <svm> and vserver nfs show that NFSv4/VAAI copy offload is available.
• Citrix MCS: provisioning writes a base disk copy per VM; put the identity disk and write cache on an ONTAP SMB share with a per-pool QoS policy so cache-heavy pools can't affect others.
• Citrix PVS: desktops boot from a shared vDisk in RAM — storage sees mostly read bursts. Place vDisks on a dedicated volume with dedupe and snapshot protection.
• FSLogix (AVD/M365): profile containers are single-user VHDX files on SMB. They behave like database files — random small-block I/O with locks — so keep them on flash-backed volumes with compression enabled, and exclude them from dedupe if you see fragmentation-related latency (dedupe on VHDX is usually still a win; test with volume efficiency show).

5. Performance guardrails: QoS, Flash Pool, and latency targets

• QoS policy groups: never let the VDI pool burst into production storage. Create a policy group per pool with a ceiling, and give power-user pools a floor:

  qos policy-group create -policy-group pg_vdi_std -vserver <svm> -max-throughput 1500IOPS,300MB/s
  qos policy-group create -policy-group pg_vdi_power -vserver <svm> -min-throughput 2000IOPS -max-throughput 8000IOPS,1GB/s
  volume modify -vserver <svm> -volume vdi_pool_std -qos-policy-group pg_vdi_std
  volume modify -vserver <svm> -volume vdi_pool_power -qos-policy-group pg_vdi_power

  Adaptive QoS (qos adaptive-policy-group create) scales the ceiling with used space — handy for clone pools that grow organically.
• Flash: on hybrid (FAS) systems, the boot storm is served by Flash Cache (read cache) and Flash Pool (write cache). On AFF/ASA everything is flash — size for the storm's peak IOPS and you are done. Typical targets: boot/login completes in 30–90 seconds; steady-state desktop latency under 5 ms; sustained queue depth low enough that statistics show -object vserver -instance <svm> never shows read latency above 10 ms during storms.
• Antivirus offload with FPolicy: instead of every desktop scanning locally, use FPolicy to redirect on-access scans to external vScan servers (or an appliance such as OPSWAT MetaDefender that integrates with ONTAP). Files are scanned once at the storage tier and the results cached; desktops skip local scans. See the FPolicy guide for the full setup.

6. Data protection for VDI

• Snapshots: snapshot the gold image volume before every update and the pool volumes on a schedule. Reverting a corrupted pool is a single snapshot restore — the fastest desktop repair there is.
• SnapMirror: replicate gold images and FSLogix/profile volumes to a DR SVM with snapmirror create. VDI DR is usually about recovering the service (gold images + broker config), not every desktop clone — clones are re-created from the gold image, so replicate gold first, profiles second.
• Backup: NDMP or SnapCenter for the gold images and any persistent data (see SnapCenter and NDMP). Stateless clones need no backup — their parent snapshot is the backup.

7. VDI in the cloud: FSx for ONTAP and ANF

The same patterns carry to cloud-hosted desktops. AWS published a governed enterprise-reporting architecture that puts VDI workloads on Amazon FSx for NetApp ONTAP as a centralized shared-storage repository: granular access controls and compliance enforcement on analytical datasets, with ONTAP multi-protocol access and Snapshot-based protection for cloud-hosted desktop reporting. On Azure, Azure NetApp Files serves AVD pools (NFS) and FSLogix profiles (SMB) with the same dedupe, snapshots, and QoS knobs. The design rules are identical to on-premises — gold image, clones, QoS, FPolicy, SnapMirror to a second region — only the SVM lives in a cloud account. See FSx for ONTAP and Azure NetApp Files.

8. End-to-end CLI runbook (ONTAP 9.x)

# 1. SVM and protocols
vserver create -vserver vdi-svm -data-protocol nfs,cifs -root-volume-data-aggregate aggr1
vserver nfs create -vserver vdi-svm -v3 enabled -v4.1 enabled
vserver cifs create -vserver vdi-svm -cifs-server VDI -domain corp.example.com
vserver cifs options modify -vserver vdi-svm -smb3-encryption enabled

# 2. Gold image volume (dedupe+compression inline)
volume create -vserver vdi-svm -volume gold_win11 -aggregate aggr1 -size 300GB \
  -junction-path /vdi/gold -space-guarantee none
volume efficiency on -vserver vdi-svm -volume gold_win11
volume efficiency modify -vserver vdi-svm -volume gold_win11 -compression inline

# 3. NFS export restricted to ESXi hosts
vserver export-policy create -vserver vdi-svm -policy esxi
vserver export-policy rule create -vserver vdi-svm -policy esxi -protocol nfs \
  -clientmatch 10.1.20.0/24 -rorule sys -rwrule sys -superuser sys

# 4. Clone the gold image per pool
volume clone create -vserver vdi-svm -volume vdi_pool_std -parent-volume gold_win11 \
  -parent-snapshot-policy default -junction-path /vdi/pool_std

# 5. QoS guardrails
qos policy-group create -policy-group pg_vdi_std -vserver vdi-svm -max-throughput 1500IOPS,300MB/s
volume modify -vserver vdi-svm -volume vdi_pool_std -qos-policy-group pg_vdi_std

# 6. SMB share for FSLogix / Citrix write cache
vserver cifs share create -vserver vdi-svm -share-name fslogix$ -path /vdi/fslogix \
  -share-properties oplocks,continuous-availability,browsable

# 7. Protection
snapshot policy create -vserver vdi-svm -policy hourly-daily \
  -schedule hourly -count 6 -schedule2 daily -count2 7
volume modify -vserver vdi-svm -volume gold_win11 -snapshot-policy hourly-daily
snapmirror create -source-path vdi-svm:gold_win11 -destination-path drsvm:gold_win11 \
  -type DP -schedule hourly
snapmirror initialize -destination-path drsvm:gold_win11

# 8. Verify
volume show -vserver vdi-svm -fields volume,size,used,percent-used,dedupe-space-saved,compression-space-saved
qos policy-group show -vserver vdi-svm
statistics show -object volume -instance vdi_pool_std -sample-id 5

9. Triage matrix

Related: WAFL & copy-on-write · QoS on ONTAP · FPolicy (AV/vScan) · FSx for ONTAP · Azure NetApp Files · SnapMirror · Storage efficiency · VMware vSphere on ONTAP