Troubleshooting DB Connections in VMware Appliances

There's a new batch of virtual appliances from VMware and increasingly they need some kind of DB backend to function. This usually means cranking up the web-front end of the appliance, and in the configuration page typing in the name of the SQL server, username, password and name of database.

It can take sometime for these configuration pages to do there thang. And sometimes they come back with horribly cryptic error messages that aren't particularly illuminating. So here's a tip for me. Find a Windows machine that has the SQL Native Driver installed, and try configuring a standard system DSN to the same DB, using the same credentials. The ODBC does a relatively good job send back the reason why you can't connect - once you can connecting using the ODBC administrator, then there should be no reason why the same method shouldn't work on the appliance...

Scripted Install of vCLI & PowerCLI

As you probably have gathered I've been busy working out how to install all the bits that make up vSphere, and install them automagically without human interaction. It's all about getting away from doing any of my day to day stuff manually - and instead document them fastest, quickest, most automated ways of getting stuff done. They are working me so hard here at Corp.com, and want everything by next week - there's no time to shilly-shally about I can tell you.

So to install vCLI automatically I used:

192.168.3.254\software\VMware\vs5\VMware-vSphere-CLI-5.0.0-373086.exe /s /v/qn

And to install PowerCLI automatically I used the same command-line switches.

192.168.3.254\software\VMware\vs5\VMware-PowerCLI-5.0.0-374833.exe /s /v/qn

After the install of PowerCLI I opened both the 32-bit and 64-bit icons that were left on my desktop – and set the execution policy for both with

set-executionpolicy remotesigned

I've come across situations where if it hadn’t been set for both –  cmdlet that was called in a PowerShell script, the script would fail because of an unset execution policy.

Scripted Installation of VUM Client

Like the scripted install of vSphere Client, the install of the VUM client is relatively prosaic affair and can be done with this "one-liner"

E:\updateManager\VMware-UMClient.exe /q /s /w /L1033 /v" /qr /L*v \"%TEMP%\vim-umc-msi.log\""

Scripted Installation of VMware Update Manager

WARNING:

Since the GA of vSphere5 the script below has stopped working. When ever it executes it fails to install to the SQL database, and instead tries to install SQL Express instead. Whilst documentation has been released on how to do an unattend vCenter5 install - no such document appears forthcoming on VMware Update Manager at the moment.

The scripted install of VUM is very much the same as vCenter, except the way you specify the database type you want to use is different - you use parameter VCI_DB_SERVER_TYPE to indicate you want to use an existing external database for the installation, rather than the embedded SQL Express method.

Also it it supports the ability to specify which location you want the patches and updates to be downloaded to with the VMUM_DATA_DIR parameter. I've always installed VUM to the same Windows Instance as vCenter, and given the vCenter a seperate D: drive to hold the downloads.

E:\updateManager\VMware-UpdateManager.exe /L1033 /v" /qr WARNING_LEVEL=0 VMUM_SERVER_SELECT=vcnyc.corp.com VMUM_DATA_DIR=\"D:\" VC_SERVER_IP=vcnyc.corp.com VC_SERVER_ADMIN_USER=\"corp\administrator\" VC_SERVER_ADMIN_PASSWORD=\"Password1\" VCI_DB_SERVER_TYPE=Custom DB_DSN=\"VMware VUM\" DB_USERNAME=\"vumdbuser-nyc\" DB_PASSWORD=\"Password1\"

Scripted Installation of the vSphere Client

The scripted installation of the vSphere Client is somewhat less arduous than the vCenter installation, given that it has less requirements:

e:\vSphere-Client\VMware-viclient.exe /q /s /w /L1033 /v" /qr"

Scripted Installation of vCenter

It took me a while to get scripted installations of vCenter5 working. Basically, I had to rip off an old script from the vCenter4 PDF to get it working.

UPDATE: Since the GA is now a PDF on scripted installs of vCenter - located here:

http://www.vmware.com/files/pdf/techpaper/vsp_50_vcserver_cmdline_install.pdf

VMware don't officially support scripted installations of vCenter or VUM. Although they do publish a PDF on how to do it. How queer. I think the policy is... Don't ring us about scripted vCenter/VUM installs, but if you manage to get a successful outcome - we will support that build.

It looks like this:

E:\vCenter-Server\VMware-vcserver.exe /q /s /w /L1033 /v" /qr WARNING_LEVEL=0 USERNAME=\"Luke Maverick\" COMPANYNAME=\"For and On Behalf of Corp, Inc\" LICENSEKEY=\"XXXXX-XXXXX-XXXXX-XXXXX-XXXXX\" DB_SERVER_TYPE=Custom DB_DSN=\"VMware vCenter\" DB_USERNAME=\"corp\vcdbuser-nyc\" DB_PASSWORD=\"Password1\" VPX_USES_SYSTEM_ACCOUNT=0 VPX_ACCOUNT=\"CORP\vcdbuser-nyc\" VPX_PASSWORD=\"Password1\" VPX_PASSWORD_VERIFY=\"Password1\" VCS_GROUP_TYPE=Single VCS_HTTPS_PORT=443 VCS_HTTP_PORT=80 VCS_HEARTBEAT_PORT=902 TC_HTTP_PORT=8080 TC_HTTPS_PORT=8443 VCS_ADAM_LDAP_PORT=389 VCS_ADAM_SSL_PORT=902

This is designed to do a script install where there is Windows Authentication occurring between vCenter & the MS SQL system. For it to work a couple of things need to be done.

1. add the installer user (in my case vcdbuser-nyc) to local administrators group
2. ensure the SQL Native Drivers are installed and that System DSN has been created
3. add the installer user (vcdbuser-nyc) to local policy to allow "Logon as a service" rights.

UPDATE:
I've noticed that if "Named Pipes" is not enabled on SQL this fails. That's a new one on me because in all previous releases (vCenter4, vCenter5 Beta/RC) it wasn't needed. To enable named pipes you need to crank up the "SQL Server Configuration Manager", expand the "SQL Server Network Configuration" node and enable it there. You need to restart the SQL service in order for the change to take affect.