Hello everyone!
I am deploying VSphere Replication to 2 VCenter servers with 1 host each in a lab environment. I have successfully deployed and registered VRM Appliances to both VCenter servers. I have also installed the SRM agent on the same VCenters servers as well. Both plugins are showing up in both VCenter servers. When I attempt to connect to the target site from either VCenter, I get the following error below after I click "OK." What log file should I be looking at to determine my issue?
I resolved this issue today.
I had both VCenter servers setup to both use TCP 8080 for HTTP traffic, I uninstalled/reinstalled VCenter on both ends. I accepted the default HTTP TCP 80 this time around and I was able to connect to my remote/target VCenter within the connections part.
What's odd is that the VRM Appliances stated that they were using TCP 8080 to register the VRM instance/database on the Platform Service Controller (VCenter) and everything registered fine. I was able to perform local replication just fine with TCP 8080 configured.
My company sometimes view TCP 80 a vulnerability and try to use other ports when possible.
Hi,
Check here:
https://kb.vmware.com/kb/2013091
But that is a Connection Refused, seems like a communication/Firewall issue.
So which of these logs will the connection details of why it's refusing to connect?
Hi
Here you can see how to troubleshoot some of the issues with VRM https://kb.vmware.com/kb/2081078
Initial logs that we should see are the ones inside /var/log/vmware/
That is the folder that contains the Sphere Replication server log files. Used to track replication problems.
More information about logs
VMware vSphere Replication 6.1 Documentation Center
Hope this helps.
Is the "/var/log/vmware/" located on VCenter Server (Windows VM) or is this log located on the VRM Appliance?
This seems overly complicated and VMware doesn't provide a straight forward message on why it will not connect to the target site.
My environment is all on the same LAN at the moment. My gateway for all devices is a layer 3 switch. This is testing environment so I am trying to make this as simple as possible. I have attempted to implement this on 2 separate VLANs but I have the same error.
Here is how I have my lab setup. I have all my devices setup to use my 10.0.1.2 gateway but I am still getting connection refused.
So here is an update
Both of my VCenter servers are version 6.0.0 build 265760
Both of my hosts are version 6.0.0 build 3620759
Both appliances are version 6.0.0.1 build 2718739
Again all my devices have the SAME gateway 10.0.1.2 and Preferred DNS 10.0.1.31.
VCenter2.lab.local can ping by hostname to VCenter3.lab.local, VRM3.lab.local and to the ESXi-DR3.lab.local
VCenter3.lab.local can ping by hostname to VCenter2.lab.local, VRM2.lab.local and to the ESXi-DR2.lab.local
I have attempted to use the hostname, the FQDN and the local ip address of the my VCenter3 device. I get the connection refused no matter what I use. I have attempted the reverse config by trying to add VCenter2 as a target on VCenter3. But I still get the connection refused.
As you can see, all my devices are on the same domain. I am only using administrator@vsphere.local to add the target sites.
Any help/advice would be greatly appreciated.
Hi Clary,
Sorry to not return to this question earlier, been very busy.
Ping doesn't prove that you have a connection between the 2 hosts.
Ports need to be open between both sides (did you take a look at the KB and did you tested?)
Also did you look at the logs??
I resolved this issue today.
I had both VCenter servers setup to both use TCP 8080 for HTTP traffic, I uninstalled/reinstalled VCenter on both ends. I accepted the default HTTP TCP 80 this time around and I was able to connect to my remote/target VCenter within the connections part.
What's odd is that the VRM Appliances stated that they were using TCP 8080 to register the VRM instance/database on the Platform Service Controller (VCenter) and everything registered fine. I was able to perform local replication just fine with TCP 8080 configured.
My company sometimes view TCP 80 a vulnerability and try to use other ports when possible.