I ran into an interesting problem the other day when deploying vSphere Replication where the Appliance couldn’t register the service with vCenter. It turns out to be a combination of factors about the network configuration that can produce this problem. The problem is most likely to occur if you are using the vCSA.
As far as I can tell, the sequence of events for registering with vCenter is the following:
-
use the address or IP currently in use for the active Web Client session to contact vCenter
-
request the value of the Runtime settings vCenter Server name
-
contact the vExtension service based on the name returned in the previous step
And there is where the problem comes from. By default, when you install the vCSA, the value stored in the Runtime settings is the short name of the server, not the FQDN. At least this is the case on the v5.x versions. I haven’t yet tested the 6.0 vCSA.
The net result depends on how your network is configured and whether you are using DHCP or not. I was running into the problem and able to reproduce it with the following sequence of actions:
-
Configure DNS correctly with proper forward and reverse entries for the vCSA and the Replication Appliance
-
On a subnet with no DHCP services, deploy the vCSA with a fixed IP address
-
On the same subnet, deploy the vSphere Replication appliance with a fixed IP address
This will fail since when you configure the vSphere Replication appliance with a fixed IP there’s no place to enter DNS search domains so there’s no way the name resolution will work for a short name returned by the vCSA. If you are deploying using DHCP, you will probably be sending search domains to the client so the resolution will work properly.
When you try to go to the VAMI console of the replication appliance and try to manually connect to the vCenter server you will get the following somewhat misleading error message:
“Unable to obtain SSL certificate: Bad server response; is a LookupService listening on the given address?”
It would have been nice if the message mentioned the address that it was trying to contact which would have highlighted the fact it was looking at a short name.
The workaround is to simply update the runtime settings vCenter name to the FQDN. It’s also probably a good idea to verify that the FQDN in Advanced settings is has the correct value as well.
So if you ever see an appliance that has to register an extension to the vCenter web UI and it isn’t working, checking the value of the Runtime settings vCenter name might be the solution.