This appears when you are attempting to connect the vCO client through a Load Balancer - this is NOT supported. Web services Are supported through a LB, but not the client.
Thanks Burke, but no load balancer, or firewall for that matter. These are all on the same local network segment.
hmm... It looks like you changed the port to 443 in that screenshot - is that the correct port for the vCO Server? Default is :8281 ... If you changed other ports that may be contributing to the issue here... Never seen this issue when there is nothing between the vCO client and server.
Yes, that is the correct port. We modify our configs to use it.
I should point out this is an existing server, and has worked just fine with the 5.5.0 versions.
Just make sure you use a 5.5.1 client
Thanks. I've checked that, and tried using the web client-it reports a slightly different issue-
Anywhere in the logs I should be checking?
You can always check the server.log but not sure if it will give you a clue.
Maybe you need to check your IP / port settings and the http proxy file in the appliance.
Check this :
/opt/vco-proxy/vco-proxy.conf
if you change it restart it with :
/etc/init.d/vco-proxy restart
I'm encountering the exact same issue. Fresh deployment of the new appliance with a restore of the 5.5.0 appliance's configuration file. Using the default network port, no load balancer. Connecting via the Java web-client.
I had this issue as well, I had forgotten to update my client to 5.5.1
Could you provide the exact version of vCO client you are using and vCO server which you are trying to connect (including the build numbers?).
Is this behavior also observed when using java Web Start client (.jnlp)
Could you check if vCO server is accessible (https://10.23.164.147:8281/vco/api/)
Note that unfortunately vCO client need to be exactly the same version as vCO server (including the build number).
We are also seeing this issue with the latest vCO appliance (5.5.1.0 Build 1617225). It happens when using the downloadable client as well as the web-based client (JNLP). We are using all of the default ports with SSO authentication to vCenter and all of the firewall rules look correct. Here's the Java console output I get when using the JNLP client:
2014-04-04 19:21:36.665-0400 INFO [CertTrackerMain] Can not find keystore C:\Program Files (x86)\Java\jre7\lib\security\jssecacerts
2014-04-04 19:21:36.717-0400 INFO [Application] Loading properties at : C:\Users\shane\Downloads\.\vmo.properties ...
2014-04-04 19:21:36.718-0400 INFO [Application] No properties found !
2014-04-04 19:21:36.718-0400 INFO [Application] Loading ...
2014-04-04 19:21:36.856-0400 INFO [Application] Starting...
2014-04-04 19:21:36.858-0400 DEBUG [Preferences] Loading preferences from C:\Users\shane\.vmware\vmware-vmo.cfg ...
2014-04-04 19:21:36.859-0400 INFO [Preferences] Loaded preferences file: C:\Users\shane\.vmware\vmware-vmo.cfg
2014-04-04 19:21:43.329-0400 DEBUG [VSOFactoryClient] Start connection to VMO server : chopin.esx.gatech.edu:8281
2014-04-04 19:21:43.330-0400 DEBUG [VSOFactoryClient] Create Session
2014-04-04 19:21:45.189-0400 DEBUG [TypeConverter] Convertor Re registration of type : Array
2014-04-04 19:21:45.216-0400 DEBUG [VSOFactoryClient] Session created
2014-04-04 19:21:55.447-0400 ERROR [VSOFactoryClient] javax.jms.JMSException: Failed to create session factory
2014-04-04 19:21:55.452-0400 DEBUG [VSOFactoryClient] javax.jms.JMSException: Failed to create session factory
ch.dunes.util.DunesServerException: javax.jms.JMSException: Failed to create session factory
at ch.dunes.model.client.InVMJmsClient.createConnection(InVMJmsClient.java:118)
at ch.dunes.model.client.VCOHornetQJMSClient.connectTopics(VCOHornetQJMSClient.java:79)
at ch.dunes.model.client.VSOFactoryClient.connect(VSOFactoryClient.java:314)
at ch.dunes.model.client.VSOFactoryClient.connect(VSOFactoryClient.java:272)
at ch.dunes.vso.app.VSOClientAuthService.login(VSOClientAuthService.java:45)
at ch.dunes.vso.app.VSOClientAuthService.login(VSOClientAuthService.java:60)
at ch.dunes.vso.app.VSOLoginDialog._doLogin(VSOLoginDialog.java:486)
at ch.dunes.vso.app.VSOLoginDialog.access$400(VSOLoginDialog.java:52)
at ch.dunes.vso.app.VSOLoginDialog$10.run(VSOLoginDialog.java:464)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.jms.JMSException: Failed to create session factory
at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:615)
at org.hornetq.jms.client.HornetQConnectionFactory.createTopicConnection(HornetQConnectionFactory.java:145)
at ch.dunes.model.client.InVMJmsClient.createConnection(InVMJmsClient.java:110)
... 9 more
Caused by: HornetQException[errorCode=2 message=Cannot connect to server(s). Tried with all available servers.]
at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:619)
at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:611)
... 11 more
I figured out my issue... cranked up Wireshark and it turns out that it's using a port that wasn't listed in the vCO documentation (8287/tcp). Check and see if you can access your vCO appliance via 8287/tcp.
I will make sure that the documentation is updated.
Just to confirm that in vCO 5.5.1 ports 8286 and 8287 must be accessible also.
Thank you for the Information.
I had the same issue and with those two ports it is fixed now.
Beside that:
We installed on Dec 2013 a fresh vCenter 5.5 with Orchestrator on a Win2k12R2 Server (german language).
After the update we did today to 5.5.1 i found the Orchestrator Firewallrules twice in our Windows Firewall Settings.