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
Anonymous says
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
Phil
Anonymous says
GREAT!!! Many thanks for this help.
mtech87 says
Thanks!!! I was wondering why it was breaking for the Mac.
Ahmed Ali says
I'm seeing same issue on Windows based vCenter 5.5, could not find the variable, any idea?
William Lam says
I've updated the article to include the Windows path, it should be C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\bin\service\conf\wrapper.conf
Ahmed Ali says
Works great, thanks William!
Peter Magnusson says
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.
William Lam says
See if this exists on your system C:\Program Files\Common Files\VMware\VMware vCenter Server - Java Components\bin
Emilio Barco says
William, i donΒ΄t find the file wrapper.conf in a Windows based vcenter 5.5, any idea?
elecoloco says
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.
William Lam says
You'll need to use the "Windows" path to JRE π
"C:\Program Files\Common Files\VMware\VMware vCenter Server - Java Components\bin"
elecoloco says
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.
Federico says
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?
William Lam says
Can you try the setup where it's not NAT'ed and see if that helps. Could potentially be an issue relating to the NAT'ing.
spali says
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.
Efren Palacios says
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.
William Lam says
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.
spali says
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.
William Lam says
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
spali says
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.
Jon Ducommun says
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... π
spali says
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 π
William Lam says
I would recommend that if you're still having issues that you file an SR with VMware Support, they should be able to help get to bottom of this
Jon Ducommun says
Agreed with you William. I thought on it yesterday and couldn't think of anything else.
NIc Olinsky says
http://www.netgainit.com/blog/vmware-vcenter-5-5-web-client-console-fix/
jwaste says
this worked for me!!
x3nse says
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!
x3nse says
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.
Emilio says
from outside the WAN is functioning properly reverse resolution, eg host: vcenter.domain.com with ip: 80.78.76.65
ping -a 80.78.76.65
must respond
vcenter.domain.com
with this and open ports firewall 7331, 9443, 443 works ok