Nutanix Core Architecture and Cluster Components
The building blocks
Every Nutanix node runs a hypervisor (AHV, ESXi, or Hyper-V) and a Controller VM (CVM). The CVM owns the node's local disks - the hypervisor itself never writes directly to them - and pools them with the disks of every other node into a single Distributed Storage Fabric (DSF). That is the core idea: storage is physically local to each node but presented cluster-wide, so a VM on node A can read a vDisk whose data currently sits on node C.
Processes worth knowing
Each CVM runs a set of services. Stargate handles data I/O and is the process that touches disks. Curator scans vDisks, detects failures, and rebalances data. Cassandra, accessed through Medusa, stores cluster metadata such as vDisk locations and configuration. Genesis starts and supervises CVM services and handles bootstrap, which is why it is an early thing to check when a node misbehaves. Prism Element provides the per-cluster UI and API.
Traps
Questions often imply the hypervisor manages storage, or that an external SAN or LUN is involved - both are false. Another favourite is assuming a node can be added or removed at any time regardless of cluster health, or that the CVM is optional. A three-node cluster is the practical minimum for RF2 redundancy; a single node is a valid deployment but gives none.
Rule of thumb
One node = one CVM = one set of local disks. If asked where the data lives, the answer is 'across the fabric, with a preferred local copy'.