NPS common mistakes
NPS · Understand the traps and how to avoid them.
Answering redundancy questions by counting nodes instead of mapping nodes to the actual redundancy factor - e.g., claiming a 3-node cluster is "RF3" or that a 3-node RF2 cluster can absorb two simultaneous failures.
Candidates memorise "RF2 = tolerate a failure" but never link the factor to the minimum cluster size needed to rebuild, so they confuse node count, replication factor and failure tolerance.
What to do instead
Learn the pairs explicitly: RF2 tolerates one simultaneous component failure and needs at least 3 nodes to sustain it; RF3 tolerates two and needs at least 5 nodes. Practise by predicting what happens to a given N-node cluster at RF2 vs RF3 when one node is removed.
Sizing or overcommitting AHV host memory without leaving room for the controller VM HA reservation, then being surprised when a host failure does not trigger CVM restart.
Candidates treat the CVM like an ordinary guest VM and assume the hypervisor can always schedule it, forgetting that CVM HA depends on reserved capacity being available on surviving hosts.
What to do instead
Check the cluster's CVM HA reservation and admission-control settings and confirm each host has capacity to host a peer CVM. When a question involves powering on VMs or overcommitting memory, evaluate the effect on the HA reservation first.
Assuming Erasure Coding can be switched on for any container, including containers with deduplication enabled, or on small clusters.
Erasure Coding is presented as a generic space-saving feature, so candidates apply it without checking its prerequisites and compatibility constraints.
What to do instead
Remember EC requires RF2 and roughly four or more nodes to be worthwhile, and is not supported on containers with deduplication enabled. When asked about space efficiency, first check container settings and cluster size before naming EC.
Treating a clone as an immediate full independent copy, or assuming a snapshot consumes space equal to the VM's provisioned capacity.
vSphere-style mental models (thick copies, snapshot files) leak into Nutanix answers, obscuring the metadata-based redirect-on-write model.
What to do instead
State the model explicitly: snapshots and clones are metadata operations, and space is consumed only as the source or clone diverges into new blocks. Use that to reason about capacity questions and about why deleting a snapshot is fast.
Assuming guest VLAN traffic will pass as soon as a VLAN is typed into the VM NIC, without verifying that the VLAN is trunked to the host uplinks and that the correct virtual switch/bridge path exists.
Candidates focus on the VM-side setting and skip the physical uplink and bond configuration that actually carries tagged frames.
What to do instead
Trace the full path: uplink switch port must trunk the VLAN, the bond must carry it, and the guest NIC must be attached to the default bridge br0 with the VLAN specified (or delivered through the OVS configuration). Verify each hop rather than only the VM NIC.
Conflating the CVM IP, the AHV host IP and the Prism Element cluster virtual IP - for example expecting SSH to the CVM address to reach the hypervisor, or using a host IP for Prism Element access.
All three addresses look like "the node" and candidates never build a clean mental map of what answers on which address.
What to do instead
Memorise the roles: each CVM has its own management IP, each AHV host has a separate IP, and Prism Element is reached through a cluster virtual IP that can move between CVMs. When troubleshooting connectivity, name which of the three you are testing.
Assuming live migration or VM high availability requires shared storage or a vMotion/DRS equivalent, or that a VM must be powered off to move hosts.
Prior vSphere experience makes candidates look for a shared datastore and a DRS cluster before they will accept that a VM can be migrated.
What to do instead
Answer from the AHV model: the Distributed Storage Fabric presents storage to every host, so migration is a live compute operation governed by host affinity and dynamic scheduling, and VM HA restarts guests on surviving hosts without shared LUNs.
Confusing Nutanix Guest Tools with the VirtIO drivers, or assuming application-consistent snapshots and in-guest file restore work without NGT installed.
Both are "things you install in the guest", so candidates collapse them into one concept and over- or under-claim what NGT does.
What to do instead
Separate them: VirtIO drivers are the default paravirtualised devices for AHV guests, while NGT enables IP reporting in Prism, VSS-based application-consistent snapshots and self-service file restore. Check NGT installation status before promising guest-level features.
Treating Prism Central as a drop-in replacement for Prism Element, expecting to configure or inspect per-cluster settings there, or assuming PC features apply to a cluster that was never registered.
Both are called "Prism", so candidates blur the single-cluster UI with the multi-cluster control plane and its policy/category/project model.
What to do instead
Scope each question: Prism Element is the per-cluster management plane (storage, networking, VM operations on that cluster), while Prism Central adds multi-cluster categories, policies, projects and orchestration for registered clusters only. Confirm registration before attributing a PC capability to a cluster.
Declaring a cluster healthy because the dashboard looks green, without running NCC or collecting logs, and not knowing which tool produces the diagnostics bundle.
Candidates answer troubleshooting questions from visual impressions and never learn the command-level health and log-collection workflow.
What to do instead
Build a routine: run the full NCC health-check suite to surface configuration and best-practice issues, and use the log-collection utility (logbay) to gather CVM diagnostics. In scenario questions, name the check and the artifact you would collect before proposing a fix.