VI Client Open Console Attempt Fails
June 2nd, 2008 | 
Author: I ran into an issue today with the open console command from the VI Client. I was already connected to a stand alone ESX3.5 host. I had just finished creating a new VM, configuring the virtual CD to use the OS install media .iso, and I had powered on the new virtual machine. When I right clicked on the VM and selected “open console” I got the following error message:
“error connecting: can not connect to host x.x.x.x: a connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.”
Once again the VMware Communities forum came to the rescue.
VMware Communities: Getting error when opening console … is a thread that was started back in April 2006 but has it’s most recent reply (as of this writing) from May 2008. It turns out that this problem has been an issue starting with ESX3.0 and has continued across several ESX versions. It is basically unexplained. There does not seem to be a solid understanding of what conditions cause this problem. There are replies from users who have experienced the issue whether connected to an ESX host or to VirtualCenter. There is a resolution that makes it go away, however.
To fix the problem add the following line to the /etc/vmware/config file:
vmauthd.server.alwaysProxy = “TRUE”
I used nano from the Service Console to add the line to the file, and the problem instantly went away. I did not even have to restart any services. The steps for using nano to change this file are:
- type #nano /etc/vmware/config
- Add the line to the end of the file
- Press ctrl+x to save the changes
- enter “yes” when prompted
- hit enter to overwrite the file with the same file name
updated 09.10.08 – John Troyer hosted a “Ask the VMTN Communities Experts” podcast that I submitted this issue as a topic for discussion. John posted a summary of the discussion on his VMTN blog. Listen to the podcast, but here is a copy of John’s summary:
- The most likely possibility was this: The OS on which the VIC resides must be able to resolve not only the VC server but also each ESX Server. If they can not resolve via name the ESX servers you get this message. This is regardless of whether VC can resolve the name. However, proxying fixes this problem. Another fix is to add the information to the static hosts file.
- However, a guest on the call had the same problem, and fixed it by disconnecting the ESX server from VC cluster, restarting the agent on ESX server, and then reconnecting.
Posted in 
Tags: 
Pingback: Daily Digest for 2009-02-10 | Mingle Mangle of my mind