NCP-MCI v7.5: Nutanix Certified Professional — Multicloud Infrastructure

When a volume group uses CHAP authentication and is protected for disaster recovery (including synchronous replication scenarios), the CHAP secret is also referenced within the recovery plan configuration used to bring up resources at the recovery site. If the CHAP password is rotated on the source but not updated in the recovery plan, the target site continues to use the old password, causing a mismatch after failover and loss of connectivity for VM clients accessing the volume group. To ensure the new password is retained and applied correctly after failover, the administrator must update the CHAP password value within the associated recovery plan.

Nutanix clusters must maintain a minimum number of usable nodes to satisfy the configured replication/resiliency factor while data is being evacuated from a node marked for removal. Rather than reducing the replication factor (which lowers data resiliency) or forcibly removing the node (which risks data loss), the supported hardware refresh procedure is to first add the replacement node to the cluster, bringing the usable node count above the required minimum, and only then remove the original node. This allows the cluster to redistribute and re-protect data using the newly added node's capacity before the old node is taken out of service.

When a VM is reverted to a recovery point in Prism Central, only the VM's disk/data state is rolled back to match the recovery point. Metadata attributes such as categories and ownership are managed independently by Prism Central's IAM and policy engine and are not part of the snapshot data captured in the recovery point. As a result, these attributes remain at their current (post-recovery-point) values and are not reverted along with the VM's data.

Nutanix storage containers control NFS access through a filesystem whitelist (allowlist) of permitted client IPs/subnets. For a temporary, single-host migration scenario, best practice is to add only that host's specific IP address to the whitelist using a /32 (255.255.255.255) netmask. This limits access strictly to the intended host, following the principle of least privilege, and the entry can easily be removed once the migration is complete. Enabling broad subnet access or using the container as a general NFS share unnecessarily expands the attack surface and is not the Nutanix-recommended practice for temporary external access.

Nutanix Data Protection remote site configuration includes vStore Mapping, which associates a source storage container (vStore) with a destination storage container so that replicated data lands in the correct container at the remote site. Since the source container (Marketing) and destination container (Backups) have different names, an explicit vStore mapping must be configured on the remote site so replication traffic is directed to the Backups container instead of failing or defaulting incorrectly. Network Mapping instead maps source and destination networks for VM failover, not storage containers, and 'vStore PD' is not a valid Nutanix configuration construct.