vSphere Replication site pairing fails with error "vSphere Replication Management Server could not establish connection to remote vSphere Replication Management Server at 'unknown:-1'"

Products

• VMware Live Recovery

Issue/Introduction

Symptoms:

• After creating a new vSphere Replication site pair, on launching the site recovery page, the summary tab displays the below error message:

 

"vSphere Replication Management Server could not establish connection to remote vSphere Replication Management Server at 'unknown:-1'."

• As can be seen in the above screenshot, remote site details fail to populate on the summary page

• Initiating a reconnect operation for the site pair reports the below error message:

 

No matching pair server found


• Breaking the site pair and recreating it, returns the below error message:

 

Unable to connect or disconnect the vSphere Replication Management server. Details: 'https://<Local-VC-FQDN>:443/lookupservice/sdk invocation failed with "java.net.UnknownHostException: <Local-VC-FQDN>: Name or service not known"

 

Environment

vSphere Replication 9.x

Cause

For successful site-to-site communication, vSphere Replication requires a consistent "two-way" naming resolution. The remote appliance was not able to translate the local FQDN into an IP address, hence the pairing and replication tasks failed. This is caused by missing or misconfigured Forward (A) and Reverse (PTR) lookup entries on the DNS servers at the remote site.

Cause Validation Steps:

• Review the /opt/vmware/support/logs/dr-client/dr.log file on the local vSphere Replication appliance. Look for the operation ID associated with the failed site pairing task. The presence of  java.net.UnknownHostException confirms that the remote appliance cannot resolve the local site's FQDN:

2026-01-09 12:09:09,732 [srm-reactive-thread-69] WARN  com.vmware.dr.client.shared.taskMonitor.WsTaskProgressHandler  48e7d709-xxxx-xxxx-xxxx-xxxxxxxxxxxx  - Task finished with error!
(hms.remote.fault.SitePairingFault) {
   faultCause = (hms.fault.HmsMethodFault) {
      faultCause = (hms.fault.HmsMethodFault) {
         faultCause = null,
         faultMessage = null,
         originalMessage = https://<Local-VC-FQDN>:443/lookupservice/sdk invocation failed with "java.net.UnknownHostException: <Local-VC-FQDN>: Name or service not known"
      },
      faultMessage = null,
      originalMessage = https://<Local-VC-FQDN>:443/lookupservice/sdk invocation failed with "java.net.UnknownHostException: <Local-VC-FQDN>: Name or service not known"
   },
   faultMessage = null,
   originalMessage = https://<Local-VC-FQDN>:443/lookupservice/sdk invocation failed with "java.net.UnknownHostException: <Local-VC-FQDN>: Name or service not known",
   address = <Remote-VR-FQDN>,
   port = 8043,
   name = Remote-Site,
   uuid = eb88fb4d-xxxx-xxxx-xxxx-xxxxxxxxxxxx
}

Resolution

Verify that the Forward (A) and Reverse (PTR) lookup records for the local vCenter Server and vSphere Replication appliances are correctly populated on the remote site’s DNS servers. Successful site pairing and replication management are dependent on consistent FQDN resolution across the network.

Workaround: Static Host Mapping

If immediate DNS updates are not feasible, connectivity can be restored by manually updating the static host files on the affected appliances. This ensures the remote environment can identify the local infrastructure without relying on external DNS queries.

Required Actions:

1. Access the CLI of the remote vSphere Replication and vCenter Server appliances.

2. Append the IP addresses and FQDNs of the local site appliances to the /etc/hosts file. 

Example file post update: 

# Do not modify this file directly, please use esxcli.
127.0.0.1       localhost.localdomain localhost
::1             localhost.localdomain localhost
1#.##.0.##      rvc.local rvc
1#.##.0.##      rvr.local rvr

Note: While this workaround addresses the immediate communication failure, it is recommended only as a short-term measure. For long-term stability and to ensure compatibility during future upgrades, the central DNS infrastructure should be updated as the final solution.