Historically, a lot of my lab based vCloud Director (vCD) work has revolved around use of the vCD appliance that runs on SUSE Linux. Although I have installed it a handful of times on RHEL 5.X or 6.X (Red Hat Enterprise Linux), the underlying VM has traditionally been provided from someone else’s template (since RHEL is not a free product).
With vCloud Director 5.1 being available, I figured it would be a good time to roll out a new copy of vCloud Director on a full underlying RHEL 6.2 installation using my developer account in the home lab. After all, I might as well get more comfortable with RHEL.
During this process, I hit upon two “newbie” mistakes that, although frustrating at the time for me, may be something that you also will, are, or have encountered.
After completely walking through the vCD 5.1 installation steps, using a combination of Brian Smith’s excellent writeup and the vCloud Director 5.1 Installation and Upgrade Guide, I figured I was ready to start actually configuring the vCD settings for my secondary vCenter server. Annoyingly enough, I found that only port 22 for SSH was open on my newly minted server, and was unable to even scan 80 or 443.
I found it strange that I couldn’t hit the web ports
I verified that vCD services were operational, checked the logs, looked at listening ports, and generally scrounged around the server to try and figure out why the web interface was not responding.
On a whim, I thought perhaps I needed to regenerate the certificates (figuring I did it incorrectly or forgot to properly chmod the access to “just about everyone”).
However, the certificates.ks file looked just fine. So, I decided to re-install the vCD application and try again – perhaps I just goofed the install somewhere along the way. This, however, did not solve my problem.
This is where I knew it was time to take a step back and stop focusing on the hard answers. Sometimes it’s that simple, little thing that can cause a big problem and appear to require a big solution.
Port Problems Are Usually Firewall Problems
Although Brian does call out that you should disable the firewall in his directions (and the required ports and disabling SELinux are documented in the partner SETs for vCloud 1.5), I started further down in the instructions list and skipped over this part. Sure enough, by using the “setup” command as root, I was able to verify that the firewall was enabled.
Disabling the firewall quickly solved the port problem, and I was able to hit the web service on 443. I’m kind of curious why the vCD application doesn’t just open the ports it will need to operate on its own (I originally assumed it would). Is that just a Windows world approach?
A Cranky Database
Unfortunately, by re-installing the application, I had inadvertently crippled the application, too. The web page for configuring vCD eventually timed out with an error. Checking the services (which is my default “sanity check”), I noticed this error:
service vmware-vcd status vmware-vcd-watchdog is running vmware-vcd-cell is dead, but pidfile exist
I didn’t realize it at the time, but installing the application a second time using the “old” database would not work – even when I used the same name and IP. The response file generated from the configuration had changed, and “each vCD installation has a unique encryption key that various settings and some data in the DB is encrypted with” (source).
In order to redo the configuration piece for the cell, I remade the database and then changed the password on the “vcloud” database user. I then ran the configuration wizard again, which noticed that the database access was lost and requested that I enter new settings to map to the database. I figured it was easier than fooling around with the response file (since the data was worthless to me, anyway). The configuration command is located here:
Now that the firewall and database were satisfied, I went to configure vCD and was met with one last little poke in the eye.
Apparently Chrome is still not supported
5,440 total views, 2 views today