VMware - Virtual Export or Virtual Standby fails with error 'Sequence contains no matching element' (4044979)

When performing a one-time virtual export or configuring a continuous virtual standby to a VMware ESXi host, the job fails shortly after starting. The job log in the Rapid Recovery Core Console displays the following error:

Job 'Export of volumes [...] to [...] for '...' (VMware ESXi export)' failed

System.AggregateException depth 0: One or more errors occurred. (0x80131500)
---> (Inner Exception #0 depth 0) Replay.Core.Contracts.Export.ExportException depth 1: Cannot perform an export task (0x80131500)
---> System.InvalidOperationException depth 2: Sequence contains no matching element (0x80131509)
   at System.Linq.Enumerable.First[TSource](IEnumerable`1 source, Func`2 predicate)
   at Replay.Common.Implementation.Virtualization.ESXi.ESXiVirtualMachine.AddNewDisk(...)
   at Replay.Core.Implementation.Export.ExportJob.ExportTask()

The key error message is System.InvalidOperationException: Sequence contains no matching element.

This error indicates that the Rapid Recovery Core was unable to find a required resource on the target ESXi host to create the new virtual machine's disks. There are two primary causes for this issue:

Cause 1: No Datastores Available
The ESXi host selected for the export has no datastores presented to it. The error occurs because Rapid Recovery queries the host for a list of available datastores to create the VMDK files and the sequence it receives is empty.

Cause 2: Network Connectivity Block
There is a network communication failure between the Rapid Recovery Core server and the target ESXi host. Rapid Recovery requires access to the host over specific TCP ports to orchestrate the export. If these ports are blocked by a firewall, incorrect VLAN/port group assignment, or a routing issue, the Core cannot get the necessary information (like datastore lists), leading to the failure.

The required ports for communication are:

• TCP 443 (HTTPS): For API calls and general management.
• TCP 902 (vSphere Management): For data transfer and console access.

Follow these steps to diagnose and resolve the issue.

Step 1: Verify Datastore Availability

1. Log in to the VMware vSphere Client.
2. In the inventory, select the target ESXi host that was chosen for the export.
3. Navigate to the Configure > Storage > Datastores section.
4. Confirm that at least one datastore is mounted and accessible to this specific host.
5. If no datastores are listed, you must provision storage to the host before re-running the export job.

Step 2: Verify Network Connectivity

If datastores are correctly configured on the host, test the network path from the Rapid Recovery Core server to the ESXi host.

1. Log on to the Rapid Recovery Core server.
2. Open an administrative PowerShell window.
3. Run the following commands to test connectivity to the required ports. Replace <ESXi_Host_IP_or_FQDN> with the IP address or fully qualified domain name of the target ESXi host.

   Test-NetConnection <ESXi_Host_IP_or_FQDN> -Port 443

   Test-NetConnection <ESXi_Host_IP_or_FQDN> -Port 902

4. Review the output. A successful test will show TcpTestSucceeded : True. If the result is False or the command times out, there is a network block.

5. [Placeholder: Insert a screenshot of a successful PowerShell Test-NetConnection output here]

6. If the connection test fails, work with your network administrator to troubleshoot and resolve the connectivity issue. Key areas to investigate include:
   • Firewall Rules: Check network firewalls between the Core and the ESXi host, as well as the local firewall on the ESXi host itself.
   • VLAN and Port Group Assignments: Ensure the ESXi host's management VMkernel adapter is in the correct VLAN and port group to communicate with the Rapid Recovery Core server. As confirmed in a customer case, an incorrect port group assignment can isolate the host.
   • Routing and Switching: Verify that network switches and routers are correctly configured to pass traffic between the two systems on TCP ports 443 and 902.

Once network connectivity is confirmed and both Test-NetConnection commands succeed, cancel the failed job in the Rapid Recovery Console and run the virtual export again.

Step 3: Refreshing Settings for an Existing Virtual Standby

If the error occurs on a pre-existing, continuous virtual standby job, the stored configuration for that job may be pointing to an invalid resource (e.g., a datastore that was renamed or a host that was moved). You can resolve this by editing the job to re-select the correct resources.

1. In the Rapid Recovery Core Console, navigate to the Virtual Standby tab.
2. Locate the protected machine that is failing and click the drop-down arrow to the left of its name.
3. Select Edit from the menu.
4. The Virtual Machine Export Wizard will open. Proceed through the wizard, re-confirming or re-selecting the correct vCenter/ESXi host, compute resources, and datastore.
5. Save the changes. The next scheduled virtual standby export for that machine should complete successfully.