We have 2 vSphere 5.5 environments. Each site uses a different Host Management network. I have a VM console anomaly that exists from a couple source servers to one of the sites.
A couple other notes:
Anyone experiencing anything similar?
I believe the port in ESXi 5.x for MKS is 902 VMware KB: TCP and UDP Ports required to access VMware vCenter Server, VMware ESXi and ESX hosts, an...
Right typo 902. I get expected results when telneting to 902 from clients to ESXi 5.5 Hosts.
I would still double check on the firewall rules. Make sure they are allowed on both directions
We have the same issue with vSphere Client 5.5 and free ESXi 5.5 Update 1. Before we performed the update from Version 5.0 everything worked fine. It is definitly no firewall issue: We disabled the firewalls on the server as on the client.
are these HP servers? Saw another thread with the same symptoms vSphere 5.5 VM console access errors / MKS connection terminated by server & MKS malformed repso...
No, these are not HP servers. Moreover the referred thread decribes a scenario that differs in an essential point. They try to use vCenter in order to manage several physical ESXi hosts (in a cloud) from one central point and cannot connect to a console through vCenter, but they can connect to the console if they log in to the ESXi host directly. In a scenario like that I am willing to believe that those symptomes might be caused by networking problems. And they do no not claim that the console has ever worked before.
Back to our problem: Our setup is really simple and plain. We have ONE single, physical host that runs ESXi hypervisor 5.5 (free version) and several VMs. We use the vSphere Client 5.5 to manage the ESXi host and the VMs from one client on the SAME network. We DIRECTLY connect to the ESXi host through the vSphere client. We DO NOT use vCenter, vCloud or a multiple network spanning, decentralized setup with fancy firewalls or routing in between. Every part of the network including the physical wiring is under our control. In summary, we have the stupiest setup one can think of.
And most important: Everything was working fine until the day before yesterday with ESXi 5.0. After the upgrade to ESXi 5.5 the console stopped working immediately. Hence, I would take this as a strong clue that is must be somehow related to the upgrade.
I've had this happen a couple of times, even after rebuilding my nested lab where it was working (So firewall had not changed).
The issue is more than likely to do DNS. Double check they hosts and vCenter are registered in the DNS server.
Make sure your client computer has the same primary DNS as what your vCenter and hosts are using.
Run the following on your client machine.
Under administrative CMD
Open up web Browser again and log into the webclient and test.
If you proceed to continue to have the issue.
Log on to your DNS server and run (Presuming Server 2008)
Under administrative CMD
Hope this helps.
Our DNS should be OK but, I'll try that to see it it helps. Thanks.
In my case they are not HP servers, The thread issue you linked to I had read about and VMware has acknowledged an internittent VM console issue with ESXi 5.5. Apprently this intermittent issue was addressed and resolved in Update 1. My issue exhibits a bit diffrently but, I did update my Lab environment to Update 1 over the weekend and it didn't correct the problem.
I don't want to confuse my original scenerio with HEKnet's. The key points with mine are:
I checked DNS. Everything is OK, "nslookup" (Windows) and "dig" (Liunx) report no errors to a DNS query. (BTW: We use bind as DNS server.) If one connects with vSphere client by IP, the issue stays the same. So it is no DNS problem.
First bullitin point given by vmproteau in message #8 holds for us, too. We cannot say anything about point two and three, because all our clients show the same symptoms. But that might be, because we only have a small setup.
I found the solution. Although VMware claims that their products support IPv6 vSphere client and/or ESXi hypervisor does not or at least not completely. The console only supports IPv4. If you use the DNS name to connect with vSphere and both IPv6 and IPv4 DNS entries are available, IPv6 is normally preferred. (If IPv6 is avalaible, Windows queries for the AAAA record first, and uses A records as a fall back.) Because vSphere clients supports IPv6 everything seems to work at the first glance. But it prevents the console from working. Even if you directly enter the IPv6 address into the vSphere login box, the console tries to use IPv4. First, it does a DNS reverse lookup in order to convert the IPv6 address into an DNS name and then it uses the DNS name to convert it back into an IPv4 address. What the hell?!
IPv6 was standardized in 1998, today is is 2014. There are 16 years in between. Anyway, has anyone at VMware ever heard about network layer and layer separation? If the network stack supports IPv6 and obviously it does, because the rest of vSphere works perfectly fine, the application layer should not worry about lower levels. It would consider this a severe bug. At least I would expect some kind of message from vSphere like "virtual host console support requires IPv4".