Command Center

Here’s an old favourite of mine.  When trying to open a console session to a virtual machine within the VMware vSphere Client you may receive a black screen and the following error message: “Unable to connect to the MKS: Host address lookup for server”, “failed: No such host is known”.

Although there are a couple of things that can cause this error the most common reason is that the host is unable to resolve the name of the VMware ESX or ESXi host on which this VM is running.  As you’d expect this is often caused by a DNS issue or lack of an entry for the ESX/ESXi  host which is stopping the host’s name from being resolved.

First of all you may be wondering what the ‘MKS’ part of the error message stands for, well you’ll be disappointed to know that it isn’t an acronym for something high tech and very complicated but rather is stands for; mouse, keyboard, screen.

When you go to request a console session of a VM by clicking ‘Open Console’, the client machine from which you are running the vSphere Client will receive a response back from the ESX or ESXi host providing it’s (ie: the ESX/ESXi host) name to the client machine.  At this point the client then uses the name of the ESX/ESXi host (as provided by the host) to establish communication through to the ESX/ESXi host for the purposes of viewing the VM’s console.

Of course, as you’d expect, if the client machine running the vSphere Client can’t resolve the ESX/ESXi’s host name then the console session cannot be established, hence the “Unable to connect to the MKS”, “Host address lookup” error message.

So how do you resolve this issue I hear you say?  Well, this part is also quite straight forward as all you have to do is enable the PC/laptop running the vSphere Client to resolve the name of the ESX/ESXi host(s).  As you probably know a Windows based PC or laptop will use a local host file or DNS (also WINS with earlier versions of Windows OS) to resolve host names.

To resolve or not to resolve?  That is the question….

Your first step should be to open a command prompt (CMD) on your client and perform a ping to the name of the ESX/ESXi host.  Don’t forget to use the fully qualified domain name (FQDN) of the ESX/ESXi host if this is how the host is registered in the vSphere client.  To avoid any confusion look at the error message as this will contain the name of the ESX/ESXi host, in my example (see below) the name of my ESXi host is ‘esx5-01.domainname’.

The ping should, in theory, successfully resolve the ESX/ESXi’s host name to an IP address, if this doesn’t happen then you should ensure that your client PC or laptop is pointing to the correct, and working, DNS that contains an entry for the ESX/ESXi host. Hint: Your internet service provider (ISP) isn’t going to have the names of your ESX/ESXi hosts in their global DNS  so ensure you are running a local DNS service (eg: on a Windows Server OS VM) with the names of your ESX/ESXi host(s) entered into it or ….

… You could do the following, which is much easier for small vSphere lab environments, and will get you around needing to install a DNS service….  Note: Most people know about the local hosts file on a Windows OS, though I have included a little more detail to benefit those who weren’t aware of it.

Every modern Windows OS will have something called a local hosts file, which can be found in the following directory: C:WindowsSystem32driversetc

Strangely enough this file is called ‘hosts’ – the clue’s in the name. 

The contents of this hosts file will by default look like this:

This local hosts file provides you with the ability to add in your own host names and associated IP addresses to your PC or laptop, which are then used by your Windows OS.  When trying to resolve a host name the Windows OS will by default look at this local hosts file first before using alternative name resolution services such as DNS to resolve a host name.

So, all you need to do is enter, and save, into this local host file the name and IP address of the ESX/ESXi host(s) in your vSphere environment.  Just to be on the safe side ensure you create an entry using the ESX/ESXi host’s FQDN and non-FQDN.  After making these changes make sure you save your changes to the local hosts file.  Here is an example of what the formatting would look like:

Now from a command prompt (CMD) perform a ping to the ESX/ESXi host making sure you use the same name (ie: FQDN or non-FQDN) as seen in the original error message.  Everything going well your client PC/laptop should now be able to successfully resolve the name of the ESX/ESXi host.  If not, take a closer look at your local hosts file again.  Hint:  without the correct read/write permissions set on the hosts file you can’t always save it as it is located in a Windows OS systems directory.

Some people have reported that if the line below has been un-commented (ie: there is no # in front of that line) in the local hosts file then this also causes an issue when trying to establish a console session to a VM:

“# ::1        localhost.localdomain localhost”

At this point you should now be able to open a successful console session via the vSphere Client to your VM.

The resolution to the “Unable to connect to the MKS: Host address lookup for server”, “failed: No such host is known” as outlined above is one of the most common fixes though as with anything in IT there are other things that can cause the same or similar issue.

At this point I should also point out that having a firewall block the TCP/UDP port 902 used by the ‘console’ will also provide you with connectivity issues so double check to see if the firewall on your local PC/Laptop or any other firewall in between your client and the ESX/ESXi are blocking this port.  Check out this useful KB article from VMware for a list of all used ports

I hope this post has helped resolve your console connectivity issue, though if you have any alternative hints, tips or fixes for the “Unable to connect to the MKS: Host address lookup for server”, “failed: No such host is known” error then please share with others by leaving a comment below. Thanks.

REFERENCES

http://techhead.co/unable-to-connect-to-the-mks-vmware-vsphere-console-fix/