When a Recovery Plan orchestrates a failover of VMs using Volume Groups (VGs) with in-guest iSCSI attachments, the plan ensures the VG data is replicated and made available on the recovery site. However, the DR orchestration does not automatically re-establish the iSCSI session inside the guest operating system. After the failover, the VM powers on, but the iSCSI initiator within the guest OS is still configured with the old site's iSCSI target information. An administrator must manually or via script re-scan and reconnect the iSCSI initiator to the new target IP at the recovery site to bring the database volumes online.

A. The failover task completed successfully, which indicates that replication was configured and working correctly.

C. Volume Groups are fully supported entities for protection and recovery within Nutanix Recovery Plans.

D. A missing storage network mapping would likely cause the failover orchestration itself to fail, not succeed with an offline database.

- Nutanix Disaster Recovery Guide v6.0, Chapter: "Recovery Plan Management", Section: "Volume Group Recovery". The guide notes that for VGs attached using in-guest iSCSI, you must manually re-establish the connection from within the guest OS after a failover.

SR-IOV provides VMs with direct access to physical NIC hardware, a configuration that is specific to the host. During a failover to a recovery site, the specific physical hardware cannot be guaranteed to be present or available. To ensure the VM can successfully start and have network connectivity, Nutanix Disaster Recovery automatically replaces the SR-IOV virtual NIC with a standard, hypervisor-based virtio-net adapter. As part of a planned failover, the VM is then powered on to restore service, albeit without the performance benefits of SR-IOV.

A. In a planned failover, the goal is to resume operations, so VMs are powered on. Leaving them powered off would defeat the purpose of the recovery plan.

B. The SR-IOV configuration is tied to the source host's physical hardware and is not transferred or guaranteed to exist on the recovery cluster hosts.

D. Nutanix DR is designed to handle VMs with SR-IOV. It does not fail the recovery process but instead gracefully reverts the NIC to a compatible virtual adapter.

1. Nutanix Prism Central Disaster Recovery Guide (pc.2023.4), "Entity Support and Limitations" section, subsection "VMs with SR-IOV". The documentation states: "You can protect the VMs with SR-IOV enabled. At the recovery AZ, the recovered VMs have the SR-IOV NICs replaced by standard NICs."

Planned Failover performs a controlled, graceful migration that fully synchronizes protected VMs, powers them on at the recovery cluster, and optionally shuts them down on the source. Because the target VMs are already running before the maintenance begins, no downtime is seen when the primary network is taken offline.

A. Unplanned Failover starts immediately without final sync and is intended for unexpected outages, risking data loss and VM pause.

C. Validate Recovery Plan only checks configuration; it does not power on VMs at the target.

D. Test Failover isolates recovery VMs in a fenced network for validation, not for production continuity.

1. Nutanix Data Protection & Disaster Recovery Guide v6.5, “Performing a Planned Failover”, p. 132–134.

2. Nutanix University NCP-BC Courseware Module 5, “Failover Types and Use-Cases”, slide 18.

3. Nutanix Leap Admin Guide v6.5, section 6.3.1 “Planned vs. Unplanned Failover”.

In a Nutanix multisite DR configuration, a Protection Policy defines what VMs are protected and where their snapshots are replicated (e.g., to AZ1 and AZ2). However, a Recovery Plan defines the orchestration, boot order, and network mappings for failing over a specific set of VMs to a single, specific recovery AZ. To be able to fail over to the second recovery AZ, a separate and distinct Recovery Plan targeting that second AZ must be created. The inability to select the second AZ as a target indicates that no Recovery Plan has been configured for it.

A. Missing IP mapping would cause networking issues after failover is initiated but would not prevent the selection of a correctly configured Recovery Plan.

C. The snapshot retention count determines how many recovery points are available, not whether a site can be selected as a failover target.

D. The replication type (synchronous, asynchronous, etc.) does not restrict the creation of a Recovery Plan for a valid replication target.

1. Nutanix Prism Central Disaster Recovery Guide (pc.2023.4), "Recovery Plan Management". The documentation states: "A recovery plan orchestrates the recovery of protected VMs at a recovery AZ... A recovery plan specifies the recovery AZ." This implies a one-to-one mapping between a recovery plan and a target AZ. To target a second AZ, a second plan is needed.

Nutanix Disaster Recovery allows for failing over virtual machines between sites with different network configurations. The Recovery Plan is the orchestration entity where you define how VMs are recovered. A key feature within the Recovery Plan is Network Mapping, which allows an administrator to map a source network (at the production AZ) to a different target network (at the recovery AZ). During failover, the recovered VMs' network interface cards (NICs) are automatically connected to the specified target network.

A. A local-only schedule in the protection policy: Local schedules are for creating snapshots that remain at the primary site and are not replicated; they are irrelevant to failover networking at a remote site.

B. A new protection policy with synchronous replication: The replication type (synchronous, nearsync, or async) determines the RPO but does not solve the issue of mismatched network subnets between sites.

D. A required matching subnet name at the recovery AZ: While possible, it is not a requirement. The system is designed to handle dissimilar network configurations through explicit network mapping in the recovery plan.

1. Nutanix Disaster Recovery Guide v6.8, "Creating a Recovery Plan" section. The guide details the steps for configuring a recovery plan, including "Specify Network Mappings for Recovery AZ". It states: "You can create new mappings or use existing network mappings for the source and recovery AZs."

2. Nutanix University, "Nutanix Business Continuity and Disaster Recovery (NCP-BC) 6.5" courseware, Module 4: Nutanix Disaster Recovery. The module explains that network mappings in a recovery plan are used to connect VMs to appropriate networks at the recovery site, which may be different from the source site.

Nutanix VM replication requires every source storage container to be mapped to a destination container. The Linux VMs succeed because their source container has an existing mapping on the remote cluster, whereas the Windows-based Marketing VMs reside in a container that has no mapping. In that circumstance, Prism blocks replication even though network connectivity, free capacity, and scheduling parameters are all valid.

B. Replication mode (Async vs NearSync) does not influence whether a container is addressable on the target; mode changes merely affect RPO.

C. Cluster capacity is reported healthy; a missing mapping—not lack of space—prevents the transfer.

D. Linux VMs replicate successfully, proving that the replication mode in use is not the root cause.

1. Nutanix Data Protection & Disaster Recovery Guide v6.5, “Container Mapping Requirements,” p. 37-38.

2. Nutanix Prism Web Console Help, “Create Storage Container Mapping,” Section 8.3: “Replication fails if the source container is not mapped.”

3. B. Selvaraj & G. Subramanian, “Advanced DR with Nutanix,” Proc. VMworld 2022, slide 16.

Nutanix backup tools connect to each new node’s CVM via iSCSI. Discovery occurs on TCP 3205 (Stargate discovery) and data transfer on the standard iSCSI port 3260. If these two ports are blocked to the newly added nodes, iscsiadm discovery times out and every backup that mounts the vDisk fails.

A. 3502/3620 are used by Nutanix Files, unrelated to image-level backups.

B. 3202/3206 are internal replication/control channels, not iSCSI.

C. 3302/3360 are support and LCM ports, not used for backup disk export.

1. Nutanix Port Usage Reference Guide v6.5, Table 2-7 “Stargate iSCSI,” p.18.

2. Nutanix AHV Backup Facilities Guide v6.5, §4.2 “iSCSI Export Workflow,” p.37.

After an unplanned failover, replication is automatically reversed so AZ2 now protects AZ1. Failback therefore requires that recovery points exist on AZ1—either newly replicated ones (C) or any snapshots that still reside locally from before the outage (B). If either set is available, the same recovery plan can be used to return workloads.

A. Failback is initiated from the current recovery site (AZ2), not from AZ1.

D. New recovery points coming from AZ2 are sufficient; pre-outage snapshots on AZ1 are not strictly required.

1. Nutanix Data Protection & Disaster Recovery Guide v6.5, §9.4 “Unplanned Failover Workflow,” p.298-301.

2. Same guide, §9.6 “Failback Requirements and Reverse Replication,” p.305-307.

For Nutanix Disaster Recovery, paired Prism Central instances manage the disaster recovery configuration, including protection policies and recovery plans. This management communication between the two Prism Central availability zones (AZs) occurs over TCP port 9440. This port must be open bidirectionally to allow for initial pairing, subsequent configuration synchronization, and orchestration of failover and failback operations.

A. 2009: This port is used for communication between Controller VMs (CVMs) within a cluster for data replication, not for Prism Central to Prism Central management.

B. 2020: This port is used for communication between CVMs for configuration tasks, not for inter-Prism Central communication.

C. 2074: This port is used specifically for the Nutanix DRaaS (Xi Leap) VPN gateway connection and is not required for DR between two on-premises Prism Central instances.

1. Nutanix Port and Protocol Reference v2.6, "Prism Central Based Disaster Recovery (DR)" section, Page 11. The table specifies that for communication between a source Prism Central and a remote Prism Central, TCP port 9440 is required.

2. Nutanix Disaster Recovery Guide v6.8, "Prerequisites for Disaster Recovery Between On-Prem AZs" section. It states, "Ensure that the Prism Central instances at both the primary and recovery AZs can communicate with each other over the port 9440."

Nutanix Self-Service Restore (SSR) enables end-users to recover their own files from VM snapshots. For the SSR tool to successfully mount a snapshot disk inside the guest OS, the VM's virtual disks must be attached to a supported controller. SSR supports virtual disks attached to either a SCSI or an IDE controller. The SSR agent attaches a clone of the vDisk from the snapshot to the VM, and these are the only two controller types supported for this operation.

C. PCI: PCI is a peripheral component interconnect bus standard, not a virtual disk controller type like SCSI or IDE in the context of VM disk configuration.

D. VGs: Volume Groups (VGs) are a Nutanix Volumes feature for providing block storage to external clients or in-guest iSCSI and are not used for standard VM disks that SSR manages.

1. Nutanix University - Nutanix Data Protection and Recovery (NDPR) 6.5 courseware, Module 4: Self-Service Restore. The courseware specifies the prerequisites for SSR, including supported disk types.

2. Nutanix Data Protection and Recovery Guide v6.5, "Self-Service Restore (SSR)" section, under "Prerequisites and Limitations". It states: "SSR supports virtual machines with IDE and SCSI disks."