There was an issue that was identified by some folks internally as well as myself around the new HTML5 VM Console for the VCSA 5.5 (vCenter Server Appliance). The issue is that after a reboot of the VCSA, the new HTML5 VM Console no longer functions. When you launch the console from the vSphere Web Client, you will get the following error "could not connect to x.x.x.x:7331"

After troubleshooting the issue with some of the engineers, it turns out there is an environmental variable that is not being properly set. There is a simple workaround to restore HTML5 VM Console functionality, take a look at the steps below:

Step 1 - Open up /usr/lib/vmware-vsphere-client/server/wrapper/conf/wrapper.conf (for Windows it is under C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\bin\service\conf\wrapper.conf) and add set.default.VMWARE_JAVA_HOME=/usr/java/jre-vmware under the environmental section and save the file.

Step 2 - Restart the vSphere Web Client by running the following command:

/etc/init.d/vsphere-client restart

Once the vSphere Web Client is available, you will now be able to access the HTML5 VM Console when launching from a Mac OS X system or an automatic generated URL. This issue has already been reported internally and we will also get a VMware KB article published with the workaround.

Here is the official VMware KB 2060604

30 thoughts on “HTML5 VM Console does not work after rebooting the VCSA or Windows vCenter Server 5.5

  1. Thanks William

    Have been banging my head against this issue, thought it may have been port forwarding as my vCenter is behind a firewall!

    All working now though


  2. Im also experiencing the same problem on Windows based vcenter 5.5, i located the wrapper.conf file as stated above but what path do i put in the variable ? Doesnt seem right to use /usr/java/jre-vmware on windows.

  3. William,

    Can you confirm the correct path to put in the Windows vCenter Server. Is it: /usr/java/jre-vmware or C:\Program Files\Common Files\VMware vCenter Server – Java Components\bin or other?? It’s not working for me.

    • You’ll need to use the “Windows” path to JRE πŸ™‚

      “C:\Program Files\Common Files\VMware\VMware vCenter Server – Java Components\bin”

    • Thanks William. Just an FYI, this doesn’t fix the issue with Windows based vCenter 5.5. It seems only to work with the Linux and or Virtual Appliance instance of vCenter.

  4. Hi William, thanks for sharing. Still getting same error πŸ™
    My scenario is: WAN — ESXI — VMFIREWALL — VCENTER
    The vcenter is natted on public ip different from the esxi but is behind, any advice?

  5. I have the same problem with a Windows vCenter Server, and could get the fix get to work.
    I tried set.default.JAVA_HOME which is not set by default (but commented out) and also set.default.VMWARE_JAVA_HOME to set to “C:\Program Files\Common Files\VMware\VMware vCenter Server – Java Components\bin”. I also tried to play with “/” and “\”, but didn’t had success.
    Anyone found a solution for a Windows vCenter Server? The virgo logfile still shows an error regarding loading the context of console.war, but without any details. Does anyone know how to increase the loglevel there, maybe then I can see some usefull information.

  6. Spali,

    I have the same issue with Windows vCenter Server. I’m yet to find any fix. I’ve read all the articles on how to fix it on the VCSA appliance but nothing seems to work on the Windows version. I also tried different “/” and “\” since Windows and Unix use it differently.

    • Make sure you set the proper VMWARE_JAVA_HOME path, I don’t have a Windows box w/VC so I can’t tell you where that is but a simple search should help you find it.

      Also regarding the slashes, you should not be switching between them. It’s very simple “/” is for *NIX and “\” is for Windows. You just need to ensure you provide the correct path.

      • Hi William

        The idea for switching the slashes is because somewhere below in the wrapper.conf VMWare itself used it in Unix style πŸ™‚

        And the path is correct, i tried it several times and also copied it from below where a sub directory of the java home is referenced. But sill no luck πŸ™

        The path (same as you have written some comments above) itself exists and is the right one in my opinion. That’s the reason I’m not sure if its the same problem as with the VCSA. But i didn’t found a way to increase the log level to see a meaningful error message.
        Its always a single line in windows and only marked as error. The message behind does look really like an error and there is no more to find the reason. So it’s possible that Windows Servers have a completely different reason with the same symptom for this problem.

        I never have seen the console working on a windows server. Even after a fresh install of the whole server.

        • Ah interesting, yea sorry I don’t use Windows much :X

          I would recommend filing an SR on the issue you’re having, someone from GSS should be able to help.

          FYI – This issue has been resolved in latest vSphere 5.5u1

          • Then it’s definitely not the same issue, because I used 5.5u1 for the fresh installation.

            thanks anyway, if I’m lucky and will find a solution I will post it here.

  7. If you’re still having a problem on the Windows side with 5.5u1 OR after addressing the fix above… vCenter doesn’t automatically open port TCP/7331, so if you have the Windows Firewall active, you should be good after you exempt that port.

    Not very good at Windows myself… πŸ™‚

    • Hi Jon

      thanks for the input, but the problem is it don’t even try to listen on the port.. the service which should listen on the port does not even start at all.
      Still no new from my side to this issue πŸ™

  8. Guys, I was having the same troubles as everyone else then I tired disabling the firewall on both Private and Public zones then it worked!

  9. Seems Jon had the right idea from an earlier comment that I missed. Allow TCP 7331 through the firewall and this will take care of it.

  10. from outside the WAN is functioning properly reverse resolution, eg host: with ip:

    ping -a
    must respond

    with this and open ports firewall 7331, 9443, 443 works ok

Thanks for the comment!

This site uses Akismet to reduce spam. Learn how your comment data is processed.