I'm having issues with getting access to the web ui on vcloud director. After the install when trying to access the UI it just says "Internet Explorer cannot display the webpage". So I checked netstat -ant | grep LIST and it only shows the proxy IP address listening on 443. Then I restarted vmware-vcd and reviewed the cell.log file.
Cell.log file showed the following: //note there were no errors in the cell.log file
Successfully bound network port: 80 on host address: x.x.x.27
Successfully bound network port: 443 on host address: x.x.x.27
Application Initialization: 9% complete. Subsystem 'com.vmware.vcloud.common.core' started
Successfully connected to database: jdbc:oracle:thin:@x.x.x.20:1521/myoracle.server
Successfully bound network port: 443 on host address: x.x.x.28
Successfully bound network port: 61616 on host address: x.x.x.27
Successfully bound network port: 61613 on host address: x.x.x.27
Application Initialization: 18% complete. Subsystem 'com.vmware.vcloud.common-util' started
Application Initialization: 27% complete. Subsystem 'com.vmware.vcloud.consoleproxy' started
Application Initialization: 36% complete. Subsystem 'com.vmware.vcloud.vlsi-core' started
Successfully verified transfer spooling area: /opt/vmware/cloud-director/data/transfer
Application Initialization: 45% complete. Subsystem 'com.vmware.vcloud.vim-proxy' started
Application Initialization: 54% complete. Subsystem 'com.vmware.vcloud.backend-core' started
Application Initialization: 63% complete. Subsystem 'com.vmware.vcloud.imagetransfer-server' started
Application Initialization: 72% complete. Subsystem 'com.vmware.vcloud.rest-api-handlers' started
Application Initialization: 81% complete. Subsystem 'com.vmware.vcloud.ui.configuration' started
Application Initialization: 90% complete. Subsystem 'com.vmware.vcloud.jax-rs-servlet' started
Application Initialization: 100% complete. Subsystem 'com.vmware.vcloud.ui-vcloud-webapp' started
Application Initialization: Complete. Server is ready in 0:42 (minutes:seconds)
Successfully initialized ConfigurationService session factory
Successfully started scheduler
Successfully started remote JMX connector on port 8999
The .27 address is the HTTP and .28 is the proxy. From netstat it only shows the .28 listening on 443 and nothing for .27. I've also checked to see if anything else was bound to 443 for the .27 address and there is nothing.
Any thoughts/ideas on what else to try would be greatly appreciated
Thanks for the reply here's some answers to your questions.
So this morning I restarted the services and grepped all the logs for the word error and here's what turned up.
/opt/vmware/cloud-director/logs/vcloud-container-info.log:2011-01-06 08:10:00,006 | ERROR | CloudScheduler_QuartzSchedulerThread | ErrorLogger | An error occured while firing trigger 'GLOBAL_com.vmware.vcloud.transfer.server_transferServerJobGroup.GLOBAL_com.vmware.vcloud.transfer.server_cleanTransferSessionsTrigger' |
/opt/vmware/cloud-director/logs/vcloud-container-info.log:2011-01-06 08:10:00,006 | ERROR | CloudScheduler_QuartzSchedulerThread | ErrorLogger | An error occured while releasing trigger 'GLOBAL_com.vmware.vcloud.transfer.server_transferServerJobGroup.GLOBAL_com.vmware.vcloud.transfer.server_cleanTransferSessionsTrigger' |
But I'm not too sure what these errors are referring too.
The failure you came across shouldn't prevent Jetty from running; it means that another service wasn't able to purge the set of expired file transfer sessions (which get created when you upload/download media or vApps).
If there's nothing else in the logs, the only thing else you might check is whether Jetty is in fact running: kill -QUIT $(cat /var/run/vmware-vcd-cell.pid) | grep -c 'pool-jetty'
That should return a number around 25 if it's running. If it's not, you'll probably want to use the vmware-vcd-support script to generate a tarball and file an SR.
Resolved the issue:
It appears the issue was with the SSL certs. My guess is that while it was successful in binding since the SSL certs appeared to have an issue, the binding would actually fail. As a test I created a different set of certificates, shutdown vmware-vcd, and re-ran the configure script. After doing this 443 showed listening on both the proxy and http address.