Nutanix NCP-MCI common mistakes
Nutanix NCP-MCI · Understand the traps and how to avoid them.
Treating a Nutanix cluster's default replication factor as 2 when sizing usable storage, then discovering capacity is far lower than expected after containers are created.
Candidates carry over RAID intuition from traditional SANs and assume a mirror consumes half the raw capacity, or they confuse RF2 with the per-node redundancy of a three-node cluster. In practice RF2 keeps two copies across failure domains, so usable capacity is roughly half of raw minus metadata and reserved space, and RF3 is required by many candidates' compliance scenarios.
What to do instead
Before sizing, compute usable capacity as raw capacity divided by the replication factor, then subtract metadata and the reserved capacity for the cluster. Practise converting a raw TB figure into usable TB for RF2 and RF3 across three-, four-, and five-node clusters, and remember RF3 needs at least five nodes for full failure-domain tolerance.
Assuming any newly added node automatically rebalances existing data, and answering that adding a node instantly improves performance for already-running VMs.
Candidates conflate capacity addition with automatic data locality. New nodes join the cluster and can host new writes, but existing extents are moved by the Curator service on its own schedule, and some workloads remain remote until rebalancing completes.
What to do instead
State explicitly that new node capacity is available for new writes immediately, while redistribution of existing data is asynchronous and handled by Curator. Check the cluster's data locality and storage rebalancing status after expansion rather than assuming instant balance.
Choosing AHV or ESXi for a new cluster based on personal familiarity without checking the Prism Central management scope, the required guest tools, and whether the chosen hypervisor supports the planned features such as microsegmentation or volume groups.
The deployment domain tests whether candidates know that hypervisor choice constrains later features: ESXi clusters are managed through Prism Element with vCenter integration, while AHV supports native Flow networking and Acropolis volume groups. Candidates often skip the compatibility matrix.
What to do instead
Before answering, map the requirement to the hypervisor: AHV for native Flow microsegmentation and AHV-native volume groups; ESXi when vCenter-based operations are mandated. Verify against the Nutanix compatibility matrix for AOS version, hypervisor version, and Prism Central version.
Configuring VLAN-backed networks on AHV without assigning the correct VLAN ID on the virtual switch and the guest NIC, then blaming the cluster when VMs cannot reach the gateway.
Candidates picture a flat management network and forget that AHV uses Open vSwitch bridges where the VLAN tag must be set on the VM NIC and the uplink must trunk that VLAN. Untagged traffic on a trunked port silently fails.
What to do instead
Walk the path end to end: physical switch port must trunk the VLAN, the AHV bridge must carry it, and the VM NIC must be assigned to the correct VLAN-backed network. Verify with the guest's IP configuration and a ping to the gateway, and check that the default VLAN is not being used as a catch-all.
Assuming Prism Central registration is a one-way convenience and forgetting that Prism Central requires its own sizing, its own network reachability to every cluster, and a matching or compatible AOS version.
Candidates treat Prism Central as a dashboard rather than a separate distributed appliance. Registration failures usually stem from version skew, DNS or NTP mismatch, or a firewall blocking Prism Element to Prism Central communication.
What to do instead
Before registering, confirm the Prism Central version is compatible with each cluster's AOS version, that DNS and NTP resolve consistently on both sides, and that required ports are open between Prism Element and Prism Central. Size Prism Central per the deployment guide for the number of clusters and VMs it will manage.
Answering that deleting a VM immediately frees its storage and that snapshots are the same as clones, leading to wrong answers on space reclamation and snapshot behavior.
Candidates import vSphere habits. In Nutanix, snapshots are metadata-light redirect-on-write references, and deleted VM data is reclaimed asynchronously by Curator, not instantly. Clones created from snapshots share extents until they diverge.
What to do instead
Distinguish three things: a snapshot captures a point-in-time reference, a clone creates a new VM that initially shares extents, and space is reclaimed later by Curator. When asked about capacity after deletion, answer that reclamation is asynchronous, and check storage container usage rather than assuming immediate free space.
Configuring protection domains or async replication without verifying that the remote site has enough free capacity and that the schedule matches the RPO, then claiming the RPO is met.
Candidates memorize the concept of replication but not the operational arithmetic: RPO is set by the replication schedule, and a failed replication due to insufficient remote capacity or a broken network path silently violates it.
What to do instead
For any replication question, check three things: the schedule versus the stated RPO, remote container free space versus the protected data size, and the health of the replication link. Confirm the last successful replication timestamp rather than assuming the schedule guarantees success.
Interpreting a cluster health warning as a hardware failure and recommending node replacement, when the alert is a configuration or capacity condition such as an almost-full container or a clock skew.
Candidates pattern-match on alert severity instead of reading the alert's cause. Many critical alerts in Prism are about capacity thresholds, NTP drift, or certificate expiry, all of which are configuration fixes.
What to do instead
Read the alert detail and its affected entity before proposing remediation. Classify alerts into capacity, configuration, and hardware categories, and check NCC health check output for the specific failing check before recommending any hardware action.
Assuming a VM's high CPU readiness or storage latency is a hypervisor bug, instead of checking host-level contention, storage tiering, and whether the VM's disks sit on a congested container.
Candidates jump to the guest OS or the hypervisor without using Prism's performance charts to localize the bottleneck. Nutanix performance analysis requires reading the right metric: CPU readiness, storage latency at the vDisk level, and network throughput per VM.
What to do instead
Localize first: check host CPU and memory contention, then per-vDisk latency and IOPS in Prism, then network throughput. Compare the affected VM against peers on the same host and container to determine whether the issue is VM-specific, host-specific, or cluster-wide.
Describing Nutanix multicloud as simply 'lift and shift to any cloud' without distinguishing Prism Central management scope, Nutanix Clusters on public cloud, and the role of Calm for automation.
Candidates blur the product boundaries: Prism Central manages registered clusters including those in public cloud, Calm provides application automation and self-service, and Flow provides networking and security policy. Marketing-level familiarity produces vague answers that miss the specific component asked about.
What to do instead
Build a component map: Prism Central for unified management, Calm for blueprint-based automation and self-service, Flow for microsegmentation and network policy, and Nutanix Clusters for running AOS on public cloud infrastructure. When a question names a capability, answer with the component that delivers it and its scope.