When was the last time you tried to remote console to a VM only to be greeted with the annoying Unable to connect to the MKS or similar message? Some of the causes leading to this issue range from firewalls blocking the required ports, badly configured DNS, and ESXi services in need of a restart. Today’s post explores a number of ways you can use to remote console to a VMware virtual machine and what you can do when remote connections fail, and you are unable to connect to the MSK.
Speaking of firewalls, adding a persistent firewall rule to ESXi can be daunting. I discuss how to do this in How to create persistent firewall rules on ESXi.
What is MKS?
MKS stands for Mouse, Keyboard and Screen. In vSphere, you can remote console to VMs using the standard vSphere clients and products such as VMware Workstation.
In pre-6.5 vSphere releases, you can use the legacy vSphere client which has now been deprecated for a long time. As shown next, just highlight the virtual machine you want to connect to and click on the Console tab. Alternatively, right-click on the VM and select Open Console. The latter method opens a stand-alone console window for you.
Remote console using the vSphere Client
If you have vCenter installed, the vSphere Web Client provides you with two remote console options, these being VMRC (the standalone VMware Remote Console) and the Web Console.
You can change the default virtual console by clicking on your user in the top right corner > My Preferences > Default Console > You can then select the web or vmrc as your default console.
You also get both options directly underneath the preview of the VM screen in the VM view. VMRC is installed by following the link given in vSphere client or by downloading it from here.
NOTE: Users who have VMware Workstation installed will have noticed that selecting Launch Remote Console brings up Workstation’s VMRC instead of the standalone one. To override this behavior, uninstall the standalone VMRC and reinstall it back.
Back to vSphere Web Client, clicking on the VM’s console screen or selecting Open Console from the VM’s context menu will launch the default remote console.
Choose between the web console and VMRC.
Remote console using the host client (ESXi embedded)
Interestingly, you can configure a virtual machine such that you connect to it using a remote client such as tightVNC. To do this, add the following lines to the VM’s configuration (Edit Settings -> VM Options tab -> Advanced Settings -> Edit Configuration). You must disable the ESXi firewall for this to work or add a rule to allow 5900 through, this being the default VNC port. If memory serves me right, this worked with ESXi 5.x versions but to be honest, I had little time to try it out on 6.x. With ESXi 6.5, I manage to establish a connection but it keeps asking for a password regardless of the one specified in the VM’s configuration.
Configuring a VM to accept remote connections from VNC
What can go wrong and how to fix it
Some of the MKS errors (for instance, vmware unable to connect to the mks internal error) you might see are as follows:
-
- Error connecting: Host address lookup for server <SERVER> failed: The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for.
-
- Error connecting: cannot connect to host <host>: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because the connected host has failed to respond.
-
- Error connecting: You need to execute access in order to connect with the VMware console. Access denied for config file.
-
- Unable to connect to MKS: Failed to connect to server IP:903.
1. Firewalls
Depending on the version of ESXi / vCenter Server installed, TCP ports 902, 903, 443 and 9443 need to be reachable when using the web based and standalone remote consoles. With vSphere 6.5, I managed to replicate a common problem where a personal firewall, or one sitting between the client computer and ESXi networks, is blocking one or more ports especially 902. To do this, I enabled the Windows firewall and created an outbound rule blocking 902 as shown.
Managing Microsoft Windows firewall rules
When the firewall rule is enabled, the following is what you get when trying to remote console to a virtual machine. The error message might differ slightly depending at which point the connection is dropped.
Remote console connection errors due to a firewall blocking ports 902 and 9443
Changing the firewall rule to Allow from Block fixes the “unable to connect to the mks” issue. Often, the lost ability to remote console occurs right after someone installs or rolls out security software incorporating a personal firewall. From my experience, other primary suspects include updates to group policies governing the Windows firewall and unannounced changes to ACLs on switches / routers. If you’re not the one administering the latter, talk to your colleagues to try and narrow down the source of the problem.
You can use netstat to verify that connections on port 902 are being established when you remote console to a VM. If you don’t see any entries, the issue is definitely firewall / network related. Another trick you can use is to telnet <ESXi IP> 902 from a command prompt or terminal. If you get a reply, it means that ESXi is listening on the port and ready for connections.
Using netstat to inspect network connections
If you’re not running a personal firewall, SSH to ESXi and temporarily disable the ESXi firewall by running esxcli network firewall set –enabled false. Verify that you can connect. If not, it’s a firewall sitting in between the management station and ESXi that’s dropping the connection.
If the problem persists after having ruled out firewalling as a problem source, move on to the next check.
2. DNS
Connection to remote console can also be impeded if ESXi and vCenter Server hostnames do not resolve correctly. To determine correct DNS resolution, use ping <ESXi hostname> or nslookup to verify that your ESXi and vCenter Server hostnames are resolving to the correct IP addresses and, likewise, to the correct hostnames. If the issues persists, try adding your ESXi hosts and IP addresses to windowssystem32driversetchosts, run ipconfig /flushdns and retry.
192.168.10.10 ESX65-a.lab.local
192.168.10.11 ESX65-b.lab.local
192.168.10.12 ESX65-c.lab.local
3. Free Disk Space
If firewalling and DNS are not the culprit, verify that the partition where /var lives has enough free disk space. To do this, run df -h from an SSH session on the ESXi hosting the VM you’re trying to remote console to. Make sure that the partition where /var is located is not full.
Checking for free disk space on ESXi
Another command you could use is vdh -h.
Making sure /var has free disk space using the vdf -h command
4. Permissions
Verify that the permissions set on the VM’s VMX file are set correctly (755). To check the permissions, run the command:
ls -l *.vmx
-rwxr-xr-x 1 root root 3995 Aug 18 10:00 Windows 7.vmx
We can see that the permissions are correctly set for the VMX file of a VM called Window 7.
-
- rwx = 111 = 7
-
- r-x = 101 = 5
-
- r-x = 101 = 5
If the VMX file permissions are not set to 755, run the following command:
chmod 755 ‘Windows 7.vmx’
Note: On ESXi 6.5, setting the permissions to read only had no effect so the permissions issues might only apply to older versions of ESXi.
5. If nothing else works!
If none of the above worked, try doing the following:
-
- Check that the time on ESXi is set correctly and in sync with the rest of the infrastructure.
-
- vMotion the VM you’re unable to remote console to, to another ESXi host and retry.
-
- Restart the management agents on ESXi as per the following KB.
-
- Reboot the VM.
-
- Reboot ESXi.
Note: Sometimes to fix if vmware remote console is unable to connect to the mks is as trivial as pressing a key while the focus is given to the console window. This was common with older versions of the legacy client and vSphere releases where nothing is displayed in the VM’s console window. Hitting Enter or another key usually brings the console back to life. An alternative fix is to launch the console in its own window by right-clicking on it and selecting Open Console.
Conclusion
Being able to remote console to a virtual machine is, of course, an integral part of any admin’s job. Seeing the dreaded “Unable to connect to the MKS” message and being able to console can be highly frustrating more so when you need to fix something fast. In most cases, the problem lies with a firewall blocking one or more required ports and missing or bad DNS entries. For the rest, it’s usually enough to vMotion a VM to another host or restart the management agent on ESXi.
If you enjoyed reading this post, why not have a look at The Complete List of VMware Articles.
You may have seen one of this
kind of MKS errors while trying to open VM console,
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 and
the error is your vSphere installed system simply unable to map this to the
guest OS, hence the open VM console failed.
Most of the time «Unable
to connect to the MKS:” errors are network issues (DNS/firewall, port 902 issue).
Either your system (where the vSphere client is installed) is not able to
resolve host/VM name or port 902 is not open.
You can check the name
resolution easily by using ping command, just open the CMD and try to ping the
esxi host/VM and see if the name resolution is happening.
If system is unable to
resolve the name, check your network setup/firewall config. This error is
caused by your vSphere client not able to communicate with the ESXi host
directly.
After verifying DNS, open a command prompt on the vSphere
Client machine and run these commands:
ipconfig /flushdns
ipconfig
/registerdns
If name resolution is not
happening, as a workaround of dns issue you may edit
the C:WindowsSystem32driversetchosts file and add esxi host’s dns
entry there.
If it’s not DNS then:
Before doing anything else
first vMotion the affected VM to any other and see if the issue
still persist.
Verify that the ESXi/ESX host
and the workstation running the vSphere Client are correctly synced to an NTP
service. This is required to satisfy SSL handshaking between the vSphere
Client or and the ESXi/ESX host.
A restart of the esxi host management agents would also fix any of the below error.
In case you are using Esxi 6.0.x
and getting following error “Unable to open MKS: Internal Error” while opening
VM console for any VM then as listed in kb# 2116542,
This
issue is caused by the SSL certificates are updated by the ESXi host when
connecting to the new vCenter Server. These certificates are used by the
console and may not be updated with the virtual machine running.
This is a known issue affecting ESXi
6.0.
To resolve this issue, use one of these
options:
- Power off and Power on the virtual
machine.
- Migrate the virtual machine
to another ESXi host using vMotion.
- Suspend and then
Resume the virtual machine.
Note: The virtual machine must be powered off for the changes to take effect.
A warm reboot will not resolve the issue.
In earlier versions of Esxi you may also try this for above error,
Select affected Esxi Host =>
Configuration > Advanced Setting
Now Go to Config =>
Security => host
Uncheck the
Config.Defaults.security.host.ruissl
In case you are using HP
ProLiant server and getting open VM console errors like,
Unable to contact the MKS: Could not connect to pipe\.pipevmware-authdpipe
or
Unable to connect to the MKS: connection terminated by server.
or
or
It could be related to hp-ams related bug, if above didn’t work then
check if a latest version of hp-ams is available and update the same if
available using below command.
esxcli software vib install
-d /datastore/directory/hp-ams-esxi5.5-bundle-10.0.1-2.zip
Or as a workaround for the time being you may stop the hp-ams process,
/etc/init.d/hp-ams.sh stop
or Uninstall the hp-ams by using the below command,
esxcli software vib remove -n hp-ams
Note: for any of the above open VM console error, not necessarily all VM
running on the host would be affected by this issue.
If anyone came across any of the MKS error not listed here please let me know in comment area.
Reference: kb# 749640.
That’s it… 
reseauexpert
asked on 5/19/2011
can not connect from Win 7/ 64bit SP1 , VM client console only , other PC no problem ,
Thanks
VMware
Hi,
Are you running the vSphere client from behind a firewall? Is this the only VM it is happening too?
Cheers,
it is diectly connected on the same subnet , norton 360 ver 5 insatlled on the win 7 64bit , i disable it and still have the problem ,
I deactived the ssl connection like this article
http://communities.vmware.com/thread/303631
still not working
Thanks
Hi,
Are you connecting to vCenter or a single ESX host. Can you try connecting using the IP address of ESX?
Cheers,
Yes I tried ip address , host name , I can connect to V center configure evrything , only the console of the virtual machine , cannot open with the meassage unable to connect to the mks:internal error
I connect from many machines with NO problem , XP sp3 , Win 7 32bit (notron 360 installed) , virtual win7 64bit
But not from my main machine win 7 64bit (norton 360 ver 5 installed ) same subnet
any hint ?
Thanks
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/19/2011
Have you got the latest VMware Tools installed, and also check there are no communication issues between client and host or vcenter, and vcenter and the host.
yes latest Vsphere client 4.10 build 345043 with esxi 4.1.0 build 348481
all Pc can ping the ESXI using ip or host name and the virtual machine
Thanks
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/19/2011
Have you tried restarting your PC?
Can you telnet to your ESXi host on port 902?
Cheers,
yes
220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC , VMXARGS supported
thanks
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/19/2011
have you restarted network managements on the host ESXi 4.1 server?
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/19/2011
have you tried connecting to the ESX host with it’s IP address, and not hostname.
or make sure you have a host name and fqdn in the hosts files on your PC.
Make sure firewall is off.
Yes many times,
I reinstalled ESX entreprise , I had the same problem, then I reinstalled ESXI
and I still have the same the problem ,
I removed and reinstalled the Vsphere client and I still have the same the problem
I think the problem is from my machine and not from the ESXI , because other Pc on my network can connect even thru a VPN
Thanks
this is very easy to resolve, this is what you need to do:
1) power down VM
2) right click and remove from inventory — not delete from disk obviously
3) navigate to the datastore where the VM folder resides, right click the VM’s the virtual machine configuration file (machinename.vmx) and select add to inventory
You will find that ESX has re-registered the VM and you will then regain access to the remote console
I removed VM from inventory , and did exactly what you suggested , still not working
Thanks
OK, lets try something more advanced:
1) power down VM
2) log into ESXi from the local console and enable local tech support — if the datacenter is remote to you then enable remote tech support in the ESXi secuity profile via the vSPhere client
3) log into ESXi as root
4) Kill all processes associated with the VM. there are different ways to do this, you can follow the instructions in either of these articles:
this link shows 3 ways, in your case the it isn’t the VM that is stuck, but rather a process associated with the remote console. try all of the methods.
http://itknowledgeexchange.techtarget.com/virtualization-pro/killing-a-frozen-vm-on-a-vsphere-esx-host/
Since you have esxi 4.1 this link might be better:
http://www.virtuallyghetto.com/2010/08/how-to-kill-stuck-vm-on-esxi-41-using.html
The above can be run from the vsphere CLI that you can download and install on your windows PC, it can be run from the VMware management assistance applicane, or from the local command prompt on the ESXi host as well.
If this doesn’t work a restart of ESXi server will unlock the process that is hosed and preventing you from getting a session up.
Keep in mind I am only recommending the above becuas you hvae stated you are 100% certain there is no firewall or network issue between your PC and ESX server. the console, although you may be logged into vcenter, is actually launched from the ESX server and not vCenter.
Another method that can be attempted is to remove the VM from inventory, build a new virtual machine with the same name, but when building select custom and use the existing virtual disks of the virtual machine. this will allow you to create a whole new VM from the existing disks. If this doesn’t resolve the issue, or the above methods, then there is most likely a network issue between your PC and ESX that you are over looking
more details ,
I will try later the above solution , but just to let you know that , I insatlled a Virtual XP on my windows 7 ultimate 64-bit , and I can access the console form this virtual machine but not from my Win 7
Thanks for the advice , I will try to go over during the day ,
Very interesting.. it would appear that you are having trouble with your client on the windows 7 PC then.. have you tried to uninstall the client and then reinstall it? Also, shut down your windows 7 firewall.
I did that already I uninstall, used an older version but then it prompt me to upgrade to the sameversion that I originaly instaled Vsphere client 4.10 build 345043
Yes, norton 360 version 5 firewall disabled
Thanks
Make sure you are using the most up to date client, you should not be asked to upgrade your client if it is the newest version. Upgrading a client may not resolve the issue as the client may contain legacy code that is incompatible with windows 7.
After you uninstall, reboot, make sure files on the drive are gone, same for registry, then connect to http://esxserver IP and run your download.
I did it again I uninstall Vm client and reboot the machine reinstall it from the the ESXI 4.1 machine , and still get the same problem
Thanks
Can you launch the remote console of other VMs on the same host?
I have only one ESXi server
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/24/2011
VMwareGuy means is this the only VM on that host that is affected?
some one suggest to change this config
a.Log in to the ESX host’s service console as root.
b.Open /etc/vmware/config using a text editor.
c.Add this line to the file:
vmauthd.server.alwaysProxy = «TRUE»
d.Run this command to restart xinetd:
service xinetd restart
what do you think and how to do it ?
No I have multiple VM on one ESXI server and all vm host can not access their console
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/24/2011
so, you cannot access any console on any vm on this server?
From my WIn 7 64 bit I cannot access any console but from an win XP virtual on the same win7 64bit I can access any console
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/24/2011
Can you telnet to the server by IP address and fully qualified domain name
telnet <ip address> 902
and
telnet <fqdn> 902
it should display
220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtoco
l:SOAP, MKSDisplayProtocol:VNC , VMXARGS supported
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/24/2011
Yes, okay I understand.
try the telnet on both XP and WIndows 7.
this is the result from telnet on port 902
220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC , VMXARGS supported
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/24/2011
both with and IP address and fqdn?
and this is the same IP address and fqdn you use in the client?
with the IP both machine was Ok
220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC , VMXARGS supported
with fqdn
XP—> C:Documents and SettingsAdministrator>telnet vm1 902
Connecting To vm1…Could not open connection to the host, on port 902: Connect
failed
win7—>220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC , VMXARGS supported
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/24/2011
okay, something quick to try, when connected to the ESXi server.
Selection the Server, Configuratio Tab, Advanced Settings, Config, Security, Host, and then remove the tick from Config.Defaults.security.host.ruissl.
See here
I try that alredy I disable SSL and still did not work
result telenet 902
220 VMware Authentication Daemon Version 1.0, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC , VMXARGS supported
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/24/2011
oh, yes, just seen that at very start!
Just to let you know, you are not alone with the VMware Client, I’ve never found a fix for our Vista 64 bit Workstations, they don’t connect at all! (had to create virtual machines on the workstations, and install inside, and then we found Thinapp VMware Client and that works!). Sometimes it can be odd.
have we seen you logs from the viclient?
Yes , in the event nothing concerning my problem
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/24/2011
there is a viclient log in the users profile directory
This is a section from the log stating the error : Unable to connect to the MKS: Internal error.
[viclient:SoapTran:W: 9] 2011-05-24 08:07:50.758 Invoke 114 Finish WaitForUpdates on PropertyCollector:ha-property-collector [vm1] — Serial:0.000, Server:000.002
[viclient:QuickInf:M: 6] 2011-05-24 08:07:50.801 Begin inventory tree update: changed nodes: 1, removed nodes 0
[viclient:QuickInf:M: 6] 2011-05-24 08:07:50.802 End inventory tree update
——> [ :QuickInf:M: 6] 2011-05-24 08:07:51.003 EmbeddedVMRC::onMessage value : Unable to connect to the MKS: Internal error.
[ :QuickInf:M: 6] 2011-05-24 08:07:51.005 EmbeddedVMRC::OnConnectionStateChange value : True
[ :QuickInf:M: 6] 2011-05-24 08:07:51.005 EmbeddedVMRC::OnConnectionStateChange value : False
[viclient:SoapTran:M: 6] 2011-05-24 08:07:51.007 Invoke 115 Start PostEvent on EventManager:ha-eventmgr [vm1]. [operationID:8779516B-00000073][Caller: VpxClient.Common.Util.Events+PostEvent.LogConsoleConnection]
[viclient:SrvMsg :M: 6] 2011-05-24 08:07:51.014 RMI Request Vmomi.Event.EventManager.PostEvent — 115
<eventToPost type=»Vmomi.Event.VmRemoteConsoleConnectedEvent»>
Here is what we know:
1) you can’t access any remote consoles for VMs running on a host via your windows client
2) you can access the remote consoles from this host from a windows XP client
Based on this, I would tend to believe your host is fine, consoles are being launched. if you reboot the host and it is still happening then you know for sure it is a client issue.
Have you tried a different windows 7 client from another workstation? Here is why I ask, I think this is a client issue.
I have had other client related problems that were fixed by deleting temp files that get created and stored by your vi client:
Delete all files in these two locations:
C:Usersyour usernameAppDataRoamingVMware
and C:Usersyour usernameAppDataLocalVMware*
this will give your client a refresh and may resolve the issue
I renamed these 2 folders and still not working
I deployed on my machine a virtual win7 64bit wich connect successfuly, so the problem is definitly from my machine , some software incompatibility
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a
7-Day free trial
and enjoy unlimited access to the platform.
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
5/27/2011
it would certainly interfere with the network stack on your pc, but i think we confirmed you could telnet to the vnc interface on 902, which worked. Glad you had the time to start uninstalling applications, and have fixed it.
Nice — what a pain the ass though huh? As a best practice, keep your work machines separate from personal use to avoid these scenarios. Thsi is the very reason enterprise IT locks down user PCs.
Glad things are back to normal.
I kept trying until I foud the solution
Are you serious? and you did this all on your own without any assistance right? and give yourself all the credit.. now I’ve seen it all.
Dear VMwareGuy
No , I didn,t do it only on my own I got a lot of support from you and hanccocka , I am new in Expert exchange , I was asked to close the tiket and accept the solution I did as was instructed and the point was awarded to me, I an sorry about you loose those point because I don,t care about the point , and if you can tell me how I can award the point between you and hanccocka let me know I will transfer those 500 point
I would like to thank you again for your time and effort
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
6/4/2011
Thanks for your kind words.
thanks — not sure how to go about it to be honest.. Perhaps a moderator would be able to help you split up some points.
I had this same exact issue…. nice find!
i found the reason, on windows 7, if u run with user not Administrator, You’ll have a error. You must run VSClient as Administrator, You’ll not receive error
Good luck
I had a similar issue which turned out to be caused by Veeam FastSCP file transfers. Issue would go away when Veeam FastSCP was not backing up or transferring files.