Nutanix VDI Solution Architecture and Components
This domain tests how you map a VDI workload onto Nutanix and where Frame fits. You must separate the infrastructure layer (AOS, AHV, Prism, DSF, NGT) from the desktop-delivery layer (Frame, Citrix, Horizon) and select persistent, non-persistent, session-host, or DaaS designs with the right supporting services.
Core rules
- AOS pools disks across cluster nodes into DSF; AHV runs VMs; Prism Element manages one cluster; Prism Central manages many.
- Frame is Nutanix DaaS. Its control plane brokers sessions; capacity can be AHV, AWS, Azure, or Nutanix cloud infrastructure. Console, Frame App/HTML5 client, Gateway, cloud account, stack, and pool are the terms to know.
- A stack is an image plus configuration; a pool is a group of identical running instances; sessions are user connections. Do not call a stack a running desktop.
- Citrix and Horizon remain the broker in their designs; Nutanix supplies compute, storage, and networking. Frame is the native DaaS alternative.
- Use categories and Prism Central for placement and automation; separate management and desktop clusters when scale or blast radius requires it.
Worked example
A 400-user task-worker group needs non-persistent desktops, rapid burst capacity, and minimal brokering administration. Choose Frame on AHV: publish a hardened golden-image stack, create a pool with autoscale, store profiles on Nutanix Files with FSLogix, and monitor from Prism Central. Reasoning: non-persistent users do not need dedicated VMs; Frame supplies brokering; AHV keeps data local. A CAD group needing GPU and persistence would instead use GPU hosts and a persistent pool.
Traps
Assuming Frame runs only in public cloud; confusing Prism Element with Prism Central; sizing management VMs for user sessions; treating a stack as a live VM; ignoring profile storage in DaaS designs.