Logging in gives the error "The remote name could not be resolved:RemoteVC.domain.com"

But I swear I can!!

This was a fun one. I had a case today where we were getting this when trying to log into the remote vCenter server through SRM:

The remote name could not be resolved:RemoteVC.domain.com

The odd thing about this was, we could (or so we thought). We checked all kinds of connectivity.

ProdVC > ProdSRM = good
ProdVC > DRSRM = good
ProdVC > DRVC = good
DRVC > DRSRM = good
DRVC > ProdSRM = good
DRVC > ProdVC= good

So we checked these, what did we check? We checked the ports (see VMware KB 1009562 for a list of ports) via telnet, we checked the nslookup, both forward and reverse from all to all worked, we checked pings. So what was going wrong?!

Since all of the connectivity looked good, we tried connecting to the vCenter directly on the vCenter (opened the vSphere client on the vCenter server, pointed it to localhost). Once we did that, BAM, we were connected! In the end, it turned out the DNS server IP address on the workstation we were connecting from was wrong. Changed this, and everything connected.

It did raise one very interesting questions (that I still can't figure out myself). Why were we able to point a web client to the FQDN of the remote vCenter server and connect and we were also able to connect via FQDN to the remote vCenter server via the thick client. Here is my guess. I think that the FQDN of the remote vCenter Server was saved in the local DNS on the workstation itself. This meant we could still resolve the name even though we weren't hitting the DNS server. Once we were logged in, the DNS resolve was going through vCenter and vCenter forced the DNS lookup to go out to the DNS server instead of looking in the workstation's DNS entries. If anybody has a better explanation, put it in the comments!



**********************************************Disclaimer**********************************************
This blog is in no way sponsored, supported or endorsed by VMware. Any configuration or environmental changes are to be made at your own risk. Casey, VMware, and any other company and/or persons mentioned in this blog take no responsibility for anything.