Diagnosing and fixing Virtual Machine Remote Console MKS problems
Virtual Machine Remote Console (VMRC) issues, also known as MKS Errors, seem to be more and more common these days. The causes and solutions to most of these problems are the same for the large-scale user of vSphere Enterprise Plus as they are for the home-lab user on a trial license. It usually boils down to one fulcrum: The client (vSphere Client for Windows or the Web Client) does not “see” your vSphere Cluster the same way that vCenter “sees” all of the ESXi Hosts. Try to answer the following questions, and then we’ll get started with diagnosis.
Q: Does your client have Layer 2 connectivity to your ESXi Hosts? Another way of saying this is: If your ESXi Hosts and vCenter are on 172.20.0.0/16, is the system where the client app is installed also on 172.20.0.0/16?
Q: Can you ping your vCenter and all your ESXi Hosts by IP address from the client system?
Q: Can you ping your vCenter and all your ESXi Hosts by hostname from the client?
Problems connecting to the Remote Console of VMware vSphere Virtual Machines can usually be divided into one of three problem areas:
Problem One: Layer 3 (Firewall/Gateway) issues
The VMRC connection exists between the EXSi Host of the VM and the Client, even in environments which are managed by a vCenter Server. This means that if the client is on a different network (Layer 3) from the ESXi Hosts, the client must be able to resolve and connect to all ESXi hosts!
It is a misnomer and wives-tale that firewalls/routers which exist between vSphere client networks and vSphere Management networks need only route ports 443 & 902 between the client and the vCenter. Those sort of Layer 3 relationships need route to ports 443 & 902 between the client and all of the ESXi Hosts!
You can diagnose issues simply with a ping. If you can ping all of your ESXi Hosts and by IP, it is likely not a problem with Layer 3 connectivity. If you can not ping vSphere, it may just be ICMP that is blocked, go ahead and use telnet or a port-scanner.
A more conclusive, diagnosis would be to use telnet or a port-scanner to check for connectivity on ports 443 & 902 from your client to all of your ESXi hosts. If you were able to connect to 443 & 902 on everything, you could rule Layer 3 problems out conclusively.
Run: telnet <ESXi IP address> 902
This is the message you should see:
If you run: telnet <ESXI IP address> 443 you should see:
Resolution:
Fix Layer 3 connectivity issues between the client system and all of vSphere (ESXi and vCenter)
Workaround:
One potential workaround to Layer 3 issues with the VMRC would to build a Windows/Linux Desktop VM inside the vSphere Management Network and simply RDP to that! Instead of potentially compromising the security of the vSphere Management Network by opening up all of those ports, just allow 3260 (RDP), connect to that and initiate your Virtual Machine Remote Console there.
Problem Two: DNS Name resolution issues
If the PC running the vSphere Client (or Web Client) is not able to resolve the hostname of the ESXi Host of the VM, then the VMRC can not connect.
In this case, a ping by hostname to all of the ESXi hosts will determine that name resolution for one or all of these entities is not working for the client or does not exist.
This image represents a correctly configured system where the VMRC should be able to connect:
It may be a simple matter that the client PC served by a different DNS server than the vSphere Management Network, or the client PC may have no DNS resolution at all
Fix:
Make sure that the vSphere Management Network DNS is resolvable from the client PC.
NOTE: on corporate AD domains, using the workaround of creating a hosts file may be more desirable than changing the DNS of the client PC as the hosts file has no impact on authentication issues!
Workaround:
Create a hosts file on the client PC which contains the A-records for the vCenter and all of the ESXi Hosts. Be sure to run the editor as administrator. I highly recommend Notepad ++
Problem Three: vSphere 6 issues
I have noticed that, beginning with vSphere 6, when an ESXi Host is added to vCenter, and that host contains running Virtual Machines (like vCenter itself), the VMRC of those VMs will fail with a generic MKS error until the VMs are fully powered-off or vMotion-ed to another ESXi Host.
The diagnosis for this would be MKS issues that exist when there are no port issues and DNS resolution is working perfectly! In other words, if it’s not Problem One or Problem Two, then it’s probably problem Three!
Resolution:
None that I know of – please feel free to provide one!
Workaround:
As this symptom only occurs to running VMs that were on an ESXi Host at the time it was added to a vCenter, it is relatively uncommon and will only happen once in a given environment. Simply vMotion the VMs or power them off and back on once!
