SRM Server cannot connect to VR Management Server at 'https:/x.x.x.x.com.au:8043'. A runtime error occurred in the vSphere Replication Management Server.
Hms.log
2025-05-28 21:40:02.904 ERROR com.vmware.hms.HmsService [hms-main-thread-6] (..vmware.hms.HmsService) [] | stage 2 starting...FAILED
HMS Server failed to start successfully:
com.vmware.vim.vmomi.client.exception.ConnectionException: https://x.x.x.x:8123/ invocation failed with "org.apache.http.conn.HttpHostConnectException: Connect to x.x.x.x:8123 [/x.x.x.x] failed: Connection refused"
at com.vmware.vim.vmomi.client.common.impl.ResponseImpl.setError(ResponseImpl.java:265) ~[vlsi-client-9.0.2.jar:?]
......
2025-05-29 00:43:29.745 INFO com.vmware.hms.HttpServiceStarter [main] (..vmware.hms.HttpServiceStarter) [] |
HMS SERVER STARTED
VMware vCenter 7.0.3
vSphere replication 9.0.2
This is because hms service depends on embedded hbrsrv while it was not running at that time. As the certificate was replaced, hbrsrv failed to login all ESXi servers in the vCenter, it took long time to loop all of the ESXi servers during startup. Once hbrsrv was active, hms was started successfully. HMS pushes the new certificate to ESXi servers, then hbrsrv can login them.
Tagging com.vmware.vr.disallowedHost for a host can make hbrsrv not connect to it any more, after tagging ESXi, user needs to wait some time to take it effect and remove tag after certificate renewal This is an expected behaviour the more ESXi servers, the more time we should wait.
Workaround : Delete the Esxi host entries from hbrsrv db which are not part of replication and the hms pushing the certificate process will be quicker
Reference Article : vSphere Replication HBR service takes a long time to start
Reference Article : Deleting Esxi host from hbrsrv db