vCO Appliance and SSL Certificates

The vCO team has a great post on issuing an SSL certificate for the Windows version of vCO here: http://www.vcoteam.info/learn-vco/work-with-vco-over-ssl.html. I’ve recently been doing some work with the vCO virtual appliance and wanted to issue an SSL certificate for the appliance. The steps are nearly the same as Windows with some different paths. Here are the steps:

Verify the keystore has an existing entry.

/opt/vmo/jre/bin/keytool -list -keystore /opt/vmo/jre/lib/security/jssecacerts -storepass "dunesdunes"

You should see the default SSL certificate for dunes. We do not want this certificate so we’ll start by deleting it from the keystore:

/opt/vmo/jre/bin/keytool -delete -alias dunes -keystore /opt/vmo/jre/lib/security/jssecacerts -storepass "dunesdunes"

We now create a new key using our server name. I deal with certificates a lot, so I like to specify the full distinguished name from the command instead of typing the values at each prompt to cut down on the chance of errors (I just copy/paste the one line of text). Also, unlike the vcoteam post, I am going to specify a 2048 keysize (the default is 1024).

/opt/vmo/jre/bin/keytool -genkey -keyalg RSA -keysize 2048 -alias dunes -keystore /opt/vmo/jre/lib/security/jssecacerts -storepass "dunesdunes" -validity 3650 -dname "CN=vco-server.bwuch.local,OU=My Department,O=My Company,L=City,ST=State,C=XX,emailAddress=vmware-admin@bwuch.local"

Once we have the key with correct server name, we’ll create a certificate request we can send to a CA:

/opt/vmo/jre/bin/keytool -certreq -alias dunes -keypass "dunesdunes" -keystore /opt/vmo/jre/lib/security/jssecacerts -storepass "dunesdunes" -file /tmp/vcoCertRequest.csr

We’ll take the csr and submit it to our CA. We’ll want to obtain the DER encoded certificate and chain, then use a program like WinSCP to copy the file (named vcoCertificateChain.crt in this example) to the /tmp path. We can then import the new certificate into the keystore:

/opt/vmo/jre/bin/keytool -importcert -alias dunes -keypass "dunesdunes" -file /tmp/vcoCertificateChain.crt -keystore /opt/vmo/jre/lib/security/jssecacerts -storepass "dunesdunes"

As a practice, I like to make a backup of the certificate for safe keeping. If I ever need to rebuild the appliance, I’ll be able to import my existing certificate without the need to issue a new version. You can do the same with the following command:

/opt/vmo/jre/bin/keytool -exportcert -alias dunes -keystore /opt/vmo/jre/lib/security/jssecacerts -storepass "dunesdunes" -file /tmp/vcoExportCert

You’ll want to copy the vcoExportCert file to a very secure location for safe keeping. You can either restart the vCO Server Service and the Configuration Server Service for the change to take effect — or do what I did and just reboot the virtual appliance.

Posted in Virtualization | Leave a comment

VMware Tools and VMware vCenter Server Appliance

As part of my series on installing VMware Tools on virtual appliances, I wanted to post an article on the VMware vCenter Server Appliance. The instructions for this topic are identical to the VMware Tools and vCO Appliance post.

There is one caveat, that actually applies to all the recent posts on this topic. When using zypper to install GCC, you’ll need internet connectivity and a correctly configured IP stack in your virtual appliance. This means you need an IP address, gateway and DNS name resolution. If you are using a static IP address or need to manually specify one of these values, you can do it with the vami_config_net command that ships with the virtual appliance. From the console or an ssh session simply execute the following command:

/opt/vmware/share/vami/vami_config_net

This wizard will help configure network settings which will be required for zypper to work correctly.

Posted in Virtualization | Leave a comment

VMware Tools and vCO Appliance

In a recent post I wrote about my obsessive compulsive desire to update all my VMware Tools. In many cases virtual appliances come with a ‘3rd-party/independent’ version of VMware Tools which are not ‘Current’ according to the vSphere Client. If you want to replace the VMware Tools version on a vCO Appliance, you can follow these steps:

Add a CD-ROM device to the virtual machine.

Remove the existing version of VMware Tools…I’m sure there is a more refined way of doing this, but as I couldn’t find an option to remove all of the dependancies, I just removed each package by name:

rpm -e vmware-tools-esx-nox vmware-tools-plugins-guestInfo vmware-tools-plugins-autoUpgrade vmware-tools-plugins-vix
rpm -e vmware-tools-plugins-timeSync vmware-tools-esx-kmods-default vmware-tools-plugins-powerOps vmware-tools-vmxnet-kmp-default
rpm -e vmware-tools-vmxnet-common vmware-tools-plugins-deployPkg vmware-tools-plugins-vmbackup vmware-tools-vsock-kmp-default vmware-tools-vmci-kmp-default
rpm -e vmware-tools-vmci-common vmware-tools-vmmemctl-kmp-default vmware-tools-vmmemctl-common vmware-tools-vsock-common vmware-tools-plugins-hgfsServer
rpm -e vmware-tools-services vmware-tools-core vmware-tools-libraries-nox vmware-tools-guestlib
rpm -e vmware-tools-foundation

We also need to install the C compiler like before. Unlike the vMA appliance, the vCO Appliance does not have a zypper repository listed. We can add one pretty easy:

zypper ar http://download.opensuse.org/distribution/11.4/repo/oss/ 114

We can then install GCC with zypper:

zypper in gcc

If you haven’t used zypper already, you may need to select ‘t’ to temporarily trust the distribution key. You’ll then want to select Option 1 to resolve a conflict by removing the existing version of GCC and installing the new version.

From this point, we can install VMware Tools in normal Linux fashion. Select Guest > Install VMware Tools and then follow these steps:

mkdir /tmp/cdrom
mount /dev/cdrom /tmp/cdrom
cp /tmp/cdrom/VMwareTools-9.0.1-913578.tar.gz /tmp
cd /tmp
tar zxvf VMwareTools-9.0.1-913578.tar.gz
./vmware-install.pl

The installer is going to ask a bunch of questions — selecting the defaults should work just fine. We are now running the current version of VMware Tools for this host.

Posted in Virtualization | 2 Comments

VMware Tools and vSphere Management Assistant (vMA)

I recently deployed the vSphere Management Assistant (vMA) virtual appliance to an ESXi 5.1 host. While it worked fine, the VMware Tools Version Status displayed ‘3rd-party/independent’ instead of Current. While this is normal, I was on a kick to get all my VMware Tools Current. If you share the same obsessive compulsive traits, here are some instructions for you:

Start by removing the existing Open VMware Tools:

rpm -e vmware-open-vm-tools-common vmware-open-vm-tools-kmod

We also need to install the C Compiler before we can install the standard VMware Tools. We can do that with zypper in SUSE Linux.

zypper in gcc

If you haven’t used zypper already, you may need to select ‘t’ to temporarily trust the distribution key. You’ll then want to select Option 1 to resolve a conflict by removing the existing version of GCC and installing the new version.

From this point, we can install VMware Tools in normal Linux fashion. Select Guest > Install VMware Tools and then follow these steps:

mkdir /tmp/cdrom
mount /dev/cdrom /tmp/cdrom
cp /tmp/cdrom/VMwareTools-9.0.1-913578.tar.gz /tmp
cd /tmp
tar zxvf VMwareTools-9.0.1-913578.tar.gz
./vmware-install.pl

The installer is going to ask a bunch of questions — selecting the defaults should work just fine. We are now running the current version of VMware Tools for this host.

Posted in Virtualization | Leave a comment

vCenter Plugins, SSL certificates, ExtensionManager and Powershell – what more could you want for Christmas?

I was recently working in a lab environment trying to register the vCenter Operations 5.6 virtual appliance into a vCenter Virtual Appliance environment. As a standard practice I like to issue CA signed certificates to everything — even in a lab environment — so I’ll know what to expect in production.

Even after replacing the SSL certificate (here are some instructions on that process: http://www.bussink.ch/?p=458) you’ll still get an SSL warning because the plugin is registered by IP address instead of DNS name. There is another great article here: http://www.vstable.com/2012/04/02/vcenter-operations-5-x-vcenter-plugin-uses-ip-instead-of-dns-hostname/ that includes a two step process to resolve the warnings.

Step 1 is easy and very straight forward…you use vi or some other text editor to update a file on the UI virtual appliance. The second step is a little more challenging because I’m working with the vCenter Virtual Appliance and the embedded database, making the required database changes a bit tougher. Since the article described where to find this value in the Managed Object Browser, I figured I could find and update it from PowerCLI.

[cc lang=”Powershell”]
$exMgr = Get-View ExtensionManager
$vcops = $exMgr.ExtensionList | ?{$_.key -eq ‘com.vmware.vcops’}
$vcops.Server[0].Url = “https://vcops-ui/vcops-vsphere/viClientConfig.xml”
$exMgr.UpdateExtension($vcops)
[/cc]

This code is fairly straightforward.
Line 1: Use Get-View to connect to the ExtensionManager where vSphere plugins are registered.
Line 2: Find the vCOps plugin and make a copy of all the properties to a variable called $vcops.
Line 3: Update only the Server URL to use a name instead of an IP address
Line 4: Use the ExtensionManager connection from line 1 to write the updated $vcops extension back to vCenter

A refresh of the MOB shows that this updated value is immediately available — even without a restart of the vCenter Service.

Posted in Scripting, Virtualization | 4 Comments