Storage, Networking, and Performance for VDI Workloads
This domain tests storage and network design for VDI on Nutanix: DSF behavior, redundancy, efficiency features, cloning, and the network paths that carry boot, logon, and profile traffic.
Core rules
- DSF aggregates local disks into a distributed pool. Replication factor 2 tolerates one node failure; RF3 tolerates two but costs more capacity. Erasure coding saves capacity but is generally for cold or less-active data, not bursty desktop writes.
- Storage containers set resilience and efficiency. Inline compression and deduplication help linked-clone and golden-image fleets; validate with your workload.
- Nutanix shadow clones accelerate provisioning of many similar VMs from a base image without full copies.
- Use 10/25 GbE and redundant bonds. Separate management, storage, and user traffic with VLANs where policy requires; verify bond mode and switch configuration.
- Profile traffic to Nutanix Files or FSLogix shares can dominate logon storms. Size shares and network paths for concurrent logons, not average load.
- Watch CVM latency, IOPS, and network drops; a VM showing low CPU can still be slow because of storage or profile I/O.
Worked example
A 300-desktop non-persistent pool boots at 9 a.m. Use RF2, inline compression, dedupe where validated, and shadow clones from one golden image; keep the VDI container on SSD-tier media; give profile shares their own VLAN and bandwidth. Reasoning: boot storms are read-heavy and highly duplicated; RF3 would add capacity cost without meeting a stated two-failure requirement.
Traps
Enabling erasure coding on hot desktop data; using RF3 by default; ignoring profile I/O; mismatched LACP; sizing storage from average IOPS instead of peak logon; assuming dedupe fixes a network bottleneck.