Free Nutanix NCP-BC-7.5 Practice Exam with Questions & Answers | Set: 2

Post-failover cleanup is a vital operational step to ensure that the environment remains optimized and that resources are not being wasted on workloads that are no longer part of the production environment. When virtual machines are removed from a Protection Policy after a failover, the orchestration engine stops creating new recovery points for them; however, the existing schedule metadata and historical snapshots may still consume space on both the primary and recovery clusters. Reconfiguring the replication schedule (Option B) is the specific task that refreshes the policy ' s state and forces the system to re-evaluate the storage requirements for the remaining entities. This action ensures that the background cleanup processes (managed by Cerebro and Curator) can properly identify and purge the snapshots associated with the removed VMs once their retention period has passed. Failing to reconfigure the schedule or the associated protection policy can leave " orphaned " snapshots in the storage tier, leading to a steady increase in storage utilization over time. By reconfiguring the schedule, the administrator confirms the new steady-state of the DR environment, ensuring that storage is only consumed by the active, required workloads.

Nutanix 2-node clusters are often used in small remote office (ROBO) environments to provide high availability with a smaller hardware footprint. However, the reduced node count introduces specific limitations on advanced data protection features compared to standard 3-node or larger clusters.

One of the key limitations of a 2-node cluster is the support for high-frequency replication. Technologies like NearSync (which provides RPOs from 1 to 15 minutes) and Synchronous replication (0 RPO) require a minimum of three nodes to manage the necessary metadata overhead, storage consistency, and lightweight snapshot (LWS) engine requirements. In a 2-node cluster, the system is restricted to using standard Asynchronous replication. The minimum RPO supported for standard Asynchronous replication in these small cluster configurations is typically 1 hour (60 minutes). An administrator attempting to set a more aggressive RPO will find that the system does not support the necessary lightweight snapshot infrastructure. Therefore, while a 2-node cluster provides excellent local availability, its off-site disaster recovery capability is limited to a 1-hour RPO, which should be considered during the initial architectural design and risk assessment phase for critical workloads.

Cross-Cluster Live Migration (CCLM) is an advanced feature that allows a running VM to move between two clusters without downtime, provided they are linked by synchronous replication. However, CCLM has specific technical prerequisites and limitations regarding the VM ' s hardware configuration. One of the primary constraints in many Nutanix versions is the support for specific disk controllers.

In many CCLM implementations, the migration engine requires the VM to use modern VirtIO controllers for its disks to ensure that the memory-state transfer and storage-handoff can occur seamlessly across clusters. If MarketVM was configured with legacy SCSI controllers (or certain types of shared disks), the migration task might fail during the validation phase. While storage capacity (Option B) and bandwidth (Option C) are essential for general replication, they would typically prevent the " Synchronous " status from being achieved in the first place, rather than failing a CCLM task specifically. Memory overcommit (Option D) is generally handled by the hypervisor and would not inherently block the migration unless the destination host had zero available physical memory. Troubleshooting CCLM requires an administrator to audit the VM ' s virtual hardware against the supported Nutanix compatibility matrix to ensure all components are eligible for live cross-site movement.

Virtual GPUs (vGPUs) are hardware-dependent resources that are tied to specific physical GPU cards installed in the Nutanix nodes. While Nutanix Disaster Recovery can replicate the VM ' s virtual disks and general configuration, the specific mapping to a physical vGPU profile is often not automatically preserved across clusters due to potential differences in hardware availability or GPU generations at the recovery site.

When the VM fails over and boots up at the secondary site, the guest OS may see the NVIDIA driver but will find that the " backed " hardware resource is missing or incorrectly mapped, leading to a failure in hardware acceleration. To resolve this, the administrator must manually edit the VM ' s hardware settings at the recovery site and re-assign a compatible vGPU profile from the local cluster ' s available GPU resources. This post-failover cleanup task is essential for workloads like VDI (Virtual Desktop Infrastructure) or CAD applications that depend on GPU processing. Relying on NGT (Option A) or reinstalling the OS (Option B) will not fix the underlying missing hardware assignment in the hypervisor, highlighting the need for specialized knowledge when protecting VMs with specialized hardware pass-through or vGPU requirements.

In the Nutanix Disaster Recovery orchestration workflow, Network Mapping is a critical step that tells the system which production VLAN at the primary site corresponds to which VLAN at the recovery site. This ensures that when a VM is recovered, its virtual NIC (vNIC) is " plugged in " to a functional and valid network at the new location.

If an administrator leaves the Network Mapping section blank, the Nutanix orchestrator has no information about where to connect the VM ' s network interface. In this scenario, the priority of the system is to ensure the VM can boot and start its services without causing a " network storm " or security risk. If the system were to simply attach the VM to a random or default network, it could cause IP address conflicts or expose the VM to the wrong security zone. Therefore, the built-in behavior for a failover without a valid mapping is to recover the VM with all its network adapters in a " disconnected " state. The vNIC still exists on the VM, but the " connected " checkbox in the hypervisor is unchecked. This explains why the application owners report that the VMs are " isolated. " To fix this, the administrator must either update the Recovery Plan with the correct mappings and re-run the task or manually connect each VM ' s vNIC to the correct local VLAN in the recovery site ' s Prism interface.

Nutanix storage is often accessed by external backup solutions (like Veeam, Commvault, or HYCU) using the iSCSI protocol. This allows the backup server to mount snapshots and read data directly from the storage tier. The error message " iscsiadm... discovery... timeout " specifically indicates that the backup server ' s iSCSI initiator is unable to communicate with the Nutanix Data Services IP or the Controller VMs (CVMs) over the network.

When a Nutanix cluster is expanded, it is essential that all networking and firewall configurations applied to the existing nodes are also applied to the new nodes. The iSCSI protocol relies on specific TCP ports: port 3260 is the standard port for iSCSI traffic, and port 3205 is often used for iSCSI discovery and metadata operations within Nutanix. If these ports are not open in the physical firewall or the host-based security rules for the newly added nodes, the backup server will be unable to discover the targets on those specific nodes, leading to the timeout errors . This highlights a common " Day 2 " operational trap: cluster expansion requires careful auditing of network security groups and firewall whitelists to ensure that external integrations—especially BCDR and backup services—continue to have uninterrupted access to the expanded storage fabric. Verifying and opening ports 3205 and 3260 for the new node IPs is the first step to resolving this timeout issue.

When failing over a virtual machine between different physical locations or availability zones, it is common for the network topology at the recovery site to differ from the primary site. If a VM is recovered into a site where its original subnet is unavailable, it will lose connectivity.

To resolve this, Nutanix Recovery Plans include a " Network Mapping " section. The administrator must configure these mappings to explicitly define which production subnet at the source site corresponds to which valid subnet at the recovery site. During the failover process, the orchestrator uses this mapping to automatically re-configure the VM ' s virtual network interface (vNIC) to connect to the correct local VLAN or overlay network at the destination. While " matching subnet names " (Option D) can simplify management, it is not a requirement if the mapping is correctly defined. Synchronous replication (Option B) does not address the networking layer, as it is a storage-level feature. Network mapping is therefore the essential task for ensuring that workloads are not only recovered but also accessible following a failover.

Nutanix NearSync replication provides low RPOs (1 to 15 minutes) by using " Lightweight Snapshots " (LWS). NearSync has higher performance and hardware requirements than standard Asynchronous replication because it must handle metadata operations and data transfers much more frequently.

For a cluster to support NearSync, it must have sufficient high-performance storage to handle the additional I/O load associated with LWS. On hybrid nodes (those with both SSDs and HDDs), Nutanix has a specific hardware requirement: each node must have at least two SSDs. This is because the NearSync LWS metadata and incoming replicated data are initially written to the SSD tier to ensure low latency and high throughput. A single SSD per node is typically insufficient to handle both active VM production I/O and the high-frequency NearSync overhead without performance degradation. Therefore, adding a second SSD to each node (Option D) is the mandatory modification. While upgrading to NVMe (Option A) or adding more nodes (Option B) would also improve performance, adding a second SSD is the minimum " cost-effective " requirement specified by Nutanix engineering for NearSync support on hybrid clusters. Meeting these hardware prerequisites is essential to ensure that the cluster can maintain the 15-minute RPO without transitioning back to an hourly schedule due to resource constraints.

Migrating from legacy Protection Domain (PD) based management to the modern Prism Central (PC) based Protection Policies is a recommended best practice for scaling Nutanix Disaster Recovery. This migration involves moving VMs from a " Prism Element " centric management model to a centralized, category-based model in Prism Central.

To ensure that no data is lost during this transition, the most critical prerequisite is to verify that a successful, full replication (backup) of the Protection Domain has recently completed. This ensures that the recovery site already possesses a complete and consistent set of data for the VMs before they are unlinked from the old policy and attached to the new one. While adding VMs to a category (Option A) is a step in the process, it is not the first verification step required for data safety. If an administrator attempts to migrate while a replication is incomplete or failing, the transition to the new policy might leave the VMs unprotected for an extended period, or recovery points might be missing if a disaster occurs mid-migration. By completing a full backup of the PD first, the administrator creates a " safety net " of recovery points that can be used if the migration itself encounters issues. This ensures that the transition to modern DR is performed with minimal risk to the business ' s data protection objectives.

When designing disaster recovery to a cloud environment (such as NC2 on AWS or Azure), organizations must choose a compute model that aligns with their Recovery Time Objective (RTO). The " Zero Compute " model is the most cost-efficient because it stores only the data (snapshots) in low-cost Object Storage (S3 or Blob) and does not maintain a running cluster. However, the RTO for Zero Compute is high because, in a disaster, the organization must first deploy a new Nutanix cluster, configure it, and then begin the process of hydrating data from the Object Storage.

In contrast, the " Pilot Light " model involves keeping a minimal, active Nutanix cluster (e.g., 3 nodes) running at the recovery site. While this carries a moderate ongoing cost, it significantly reduces the RTO. Because the cluster already exists, the management plane (Prism Central), the storage containers, and all metadata are already active. When a failover is triggered, the system only needs to power on the VMs or perform a small amount of data hydration. This allows the organization to meet aggressive RTO targets of under 15 minutes, which is generally impossible with the Zero Compute model. Pilot Light provides the " ready-to-go " infrastructure needed for mission-critical applications that cannot afford the multiple hours required to provision a fresh cluster from scratch during an emergency.