unable to connect to esxi using vsphere client

[WasimShaikh]

Hello Friends,

I am in need of a little help.

have 2 esxi 5.0 host and a vcenter as VM.

My lab was working good since days, but all of a sudden not sure why I am not able to connect to ESXi Hosts using vSphere Client.

Error:: The request failed because the remote server took too long to respond.

Call "ServiceInstance.RetrieveContent" for object "ServiceInstance" on Server "192.168.1.101" failed.

Yes, I am able to connect to vCenter server, when connected to vCenter and opening the VM console, nothing shows up, its a Black screen, as if the VM is off. This is with all VMs on both hosts.

1st I thought it might have to do something with vCenter and I tried connecting to Host individually which I was not able to.

After going through some KBs on vmware and some articles, I checked the firewall state on both hosts.(attached screenshot)

Checked if my workstation can talk to esxi host on port 80, 443, 902. all ports are accessible.

Disabled Symantec endpoint protection and checked. no positive results.

Lastly, I tried browsing the ESXi host via web browser i.e., http://ESXi-IP-Address which redirects me to HTTPS connection with certificate error, when I continue with the cert error, the URL keeps loading and the Host page does not shows up as it should.

This issues are on both hosts. :-(

Can you guys point me to right direction to troubleshoot this issue.

Thanks.

[pierreLx]

Hi,

Have you tried to restart the management service in the DCUI of the hosts?

[WasimShaikh]

Yes, I did restart mgmt service many times, also i tried reboot on both hosts, none of these worked for me.

[pierreLx]

Maybe you can restore the network configuration, or add another management vmkernel port using CLI on one host and connect to it with vsphere client.to check if this is a vmkernel connection problem.

[WasimShaikh]

Well, I don't think I wil be able to go with the option to reset the network config, as I have 2 NICs in each host, 1 for vmkernel and other for vDS, to properly reset, I will need to break the vDS config.

I will try to install a fresh Win7 VM in vmware workstation and will see if vsphere client on fresh machine gives the same issue.

Can it be the SSL certificates? how do i force each host to generate a new self signed SSL, so that when I "Add" hosts again to vCenter, I will be prompted for new certs, same goes with accessing Hosts directly using client.

I did check the time on both hosts and client machine.. hardly 30 sec difference.

[pierreLx]

I don't think its a certificate problem but if you want to regenerate the certiifcate:

-access the console of you esx

-run the command /sbin/create_certificates, this will replace both the private key ssl and the certificate of the host. these files are located in /etc/vmware/ssl

- then you have to reboot the host

[WasimShaikh]

Thanks for your instant reply to help me here, I will give this a try later in evening. once I check with a newly setup client workstation will update the post.

[pierreLx]

Ok, keep me informed if you solve your problem.

[WasimShaikh]

tried with a fresh workstation, still same error and also tried by regenerating new SSL.

I am not sure why the url https://hostname is not working after continuing with SSL error.

[WasimShaikh]

Finally things started working now.

The problem was with the workstation NIC configuration.

The link speed on NIC was set to Auto Negotiate (Default) but the speed was detected as 100Mbps instead of 1Gbps and MTU was set to 9014 which I did set manually long back.

Things use to work in this configuration as I have configured Hosts with MTU 9000 and the cisco SMB switch does have Jumbo enabled by default.

the LinkSpeed of 100Mbps was bugging me, after changing it to 1Gbps (manual setting) the NIC got disabled, and this made me think of switch!!.

So I set the LinkSpeed to Auto Negotiate, MTU to 9014, shutdown both hosts, restart the switch. restarted the workstation.

Things were back to normal condition as it use to.

Even the console issue (Black Screen) is gone. :-)