I have already looked over this KB article; this was the first thing I did. Anyway for the sake of thoroughness lets go through all the steps:
This issue can occur, if your network contains a firewall between the ESX host and the client running the workstation.
There is no firewall on the client; and the ESXi host does not come with a firewall, at least that is my understanding.
To resolve this issue and connect to the virtual machine console, Port 903 needs to be open in any firewall between the the workstation running VI Client and the ESX host. This applies even if VI Client is connected to VirtualCenter and not directly to ESX host.
The error I received was for port 902, but neither port 902 or 903 are open on the ESXi host. I verified this with both telnet and nmap.
Note: Before performing the steps in this article:
F or more information on restarting the Management agents, see Restarting the Management agents on an ESX Server (1003490) .
For more information on editing configuration files, see Editing configuration files in VMware ESX (1017022).
To resolve this issue:
Log in to the VirtualCenter Server directly through Terminal Services or a Remote KVM and attempt a connection using VI Client from this system. If this method works, the firewall is likely preventing the console from working.
We don't have a virtualcenter server. This is a stand-alone ESXi host.
Configure your firewall to allow communications on port 903 between the ESX host and the workstation running VI Client. For more information, See Testing port connectivity with Telnet (1003487).
There are no firewalls between the client and server.
If port 903 is not open or cannot be opened in your environment, enable the vmauthd proxy. This forces remote console communication to be sent on port 902 on the Service Console, instead of 903.
Note: By enabling this setting there may be degradation in the performance under heavy usage while communicating to the ESX host service console.
To enable the proxy:
Log in to the ESX host's service console as root .
Open /etc/vmware/config with a text editor.
Add this line:
vmauthd.server.alwaysProxy = "TRUE"
Run this command to restart xinetd:
service xinetd restart
This server has no service console; my understanding is this functionality was removed by VMware in this version
Verify the ESX firewall policy. For more information, see Troubleshooting the firewall policy on an ESX Server (1003634).
There is no firewall.
Verify that the ESX host and the workstation running VI Client are correctly synced to an NTP service. This is required to satisfy SSL handshaking between VI Client and ESX. For more information, see Verifying time synchronization across environment (1003736).
NTP is working fine. IT is port 902 that is not listening at all on the host.
DNS problems are a common cause of virtual machine console problems. Verify name resolution in your environment. For more information, see:
Identifying issues with and setting up name resolution on ESX Server (1003735)
Configuring name resolution for VMware VirtualCenter (1003713)
We are not using dns. I am connecting directly to the ip address.
After verifying DNS, open a command prompt on the VI Client machine and perform the following:
ipconfig /flushdns
ipconfig /registerdns
Verify /var partition is not full.
Verify that the permissions for the virtual machine's .vmx file are set correctly. To set the permissions, run the command:
chmod 755 </full/path/to/virtual machine.vmx>
If your ESX host has more than one service console configured, verify that they are not on the same network.
Check if the Service Console IP is routing traffic to the workstation running the vCenter. For more information on configuring the Service Console Gateway, see Changing the IP address, default gateway, and hostname of the Service Console in ESX (4309499).
Note: If your problem still exists after trying the steps in this article, please file a support request with VMware Support and note this KB Article ID in the problem description. For more information, see How to Submit a Support Request.
I cannot ssh to the host, this is not enabled on ESXi 4.0
