Badges

gestaltitbadge

follow-me-twitter

Subscribe to me on FriendFeed

Comments / DISQUS
Feedjit.com

VI Client Open Console Attempt Fails

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:

  1. type #nano /etc/vmware/config
  2. Add the line to the end of the file
  3. Press ctrl+x to save the changes
  4. enter “yes” when prompted
  5. 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.

Related Posts

  • http://www.yellow-bricks.com Duncan

    had an issue like this a while ago, but unfortunately the above mentioned solution did not work. still looking for a solution.

  • http://www.yellow-bricks.com Duncan

    had an issue like this a while ago, but unfortunately the above mentioned solution did not work. still looking for a solution.

  • bigwave

    This solution worked great for me:
    VMware Infrastructure Client Version 2.5.0

  • bigwave

    This solution worked great for me:
    VMware Infrastructure Client Version 2.5.0

  • Nate

    This worked perfectly. Thank you so so much!!

  • Nate

    This worked perfectly. Thank you so so much!!

  • http://vmetc.com rbrambley

    Big wave, Nate,

    Glad to hear it worked, and thanks for confirming the resolution with your comments.

    Duncan,

    It’s curious that there is still an unexplained scenario where this doesn’t work. Maybe one day “the missing link” that causes it will be discovered.

  • http://vmetc.com Rich

    Big wave, Nate,

    Glad to hear it worked, and thanks for confirming the resolution with your comments.

    Duncan,

    It’s curious that there is still an unexplained scenario where this doesn’t work. Maybe one day “the missing link” that causes it will be discovered.

  • Eric

    Hey man, this worked for me as well. You just saved me a lot of time!

  • Eric

    Hey man, this worked for me as well. You just saved me a lot of time!

  • Viral

    Superb !! This worked perfectly for me.
    It saved a whole lot of my time.

  • Viral

    Superb !! This worked perfectly for me.
    It saved a whole lot of my time.

  • http://vmetc.com rbrambley

    Eric, Viral,

    Thanks for the confirmations! Good to know VM /ETC helped saved you guys some time on such a frustrating issue.

  • http://vmetc.com Rich

    Eric, Viral,

    Thanks for the confirmations! Good to know VM /ETC helped saved you guys some time on such a frustrating issue.

  • Tom

    Worked great for me on ESX 3.5 w/out Update 1. Thanks!

  • Tom

    Worked great for me on ESX 3.5 w/out Update 1. Thanks!

  • Martin

    Unfortunately the line “vmauthd.server.alwaysProxy = “TRUE””

    has already been in my etc/vmware/config file… so adding it was not necessary. (using esxi 3.5 update 2)

    any other suggestions?

  • Martin

    Unfortunately the line “vmauthd.server.alwaysProxy = “TRUE””

    has already been in my etc/vmware/config file… so adding it was not necessary. (using esxi 3.5 update 2)

    any other suggestions?

  • http://www.tandberg.com Michael

    I am running ESX 2.5 and this fixed my problem. Thank-you.

  • http://www.tandberg.com Michael

    I am running ESX 2.5 and this fixed my problem. Thank-you.

Get My Podcast On iTunes!
Support VM /ETC
Support VMETC.com

Support VMETC.com

Free Business and Tech Magazines and eBooks
@rbrambley tweets
VMTN Roundtable Podcasts
Subscribe



Add to Google Reader or Homepage
Subscribe in NewsGator Online
Add to netvibes
Add to Plusmo