VCSA – The default choice. Always.

I’ve been a big proponent of the VMware vCenter Appliance for a long time, I even did a talk called VCS to VCSA Converter or How a Fling Can Be Good for You! on migrating to the VCSA at the Nordic VMUG last year.

The VCSA has gone through a few iterations and versions by now, coinciding with the vSphere releases.


vCenter Server Appliance 5.0 August 2011
vCenter Server Appliance 5.1September 2012
vCenter Server Appliance 5.5 September 2013
vCenter Server Appliance 6.0 March 2015
vCenter Server Appliance 6.5 TBA

Since v6.0 scaling has been on par with it’s Windows based counterpart, supporting the same number of  hosts and VMs.

When it comes to features, VCSA 6.5 surpasses the Windows version. New tools like the Migration Tool, vCenter High Availability, Backup / Restore and the new Management Interface are all exclusively available on the VCSA.

In my opinion, the most noteworthy of these are vCenter High Availability and the Backup / Restore options.

vCenter High Availability adresses one of the main concerns with vCenter in general since the discontinuation of vCenter Server Heartbeat in June 2014. This new HA setup enables you to have a passive VCSA ready if your active one should fail, with the added protection of a witness that keeps track of it all. This is a native feature of the VCSA, and not available in it’s Windows counterpart (or little brother as it is now…)

The Backup / Restore feature is very nice as well. One of the (few) arguments I’ve heard surrounding running the VCSA vs the Windows vCenter is surrounding backup. Thankfully the myth regarding image level backups of it was debunked in v6, but the new backup / restore functionality takes that a step further. Native backup is now available in the VCSA, either via the management interface or via a public API. The backup files (HTTP(s), FTP(s), and SCP transfer protocols are supported) make up the entire VCSA configuration, and you can restore those directly from the VCSA 6.5 ISO image in case of an emergency. This means that you can image level backups of the VCSA as usual, and script the backup file generation as added protection.

Also worth noting is that in v6.5, VMware Update Manager has been included in the VCSA, and runs natively on the appliance. The last argument for keeping your Windows vCenter has just disappeared.

With the upcoming vSphere 6.5 release it’s clear that the VCSA should be the default deployment model for a new vCenter. There is really no question about it anymore. #migrate2vcsa you should.

#vDM30in30 progress:


vCenter Server Appliance Backups

For some time now I’ve been advocating the usage of VCSA instead of the traditional Microsoft Windows based vCenter. It has feature parity with the Windows version now, it’s easier to deploy, gets right-sized out of the box and eliminates the need for an external Microsoft SQL server.

One of the questions I often face when talking about the appliance, is how do we handle backups?  Most customers are comfortable with backup up Windows servers and Microsoft SQL, but quite a few have reservations when it comes to the integrated vPostgres database that the VCSA employs. One common misconception is that a VCSA backup is only crash-consistent. Thankfully vPostgres takes care of this on it’s own, by using what it calls Continuous Archiving and Point-in-Time Recovery (PITR).

I essence, vPostgres writes everything to a log file, in case of a system crash. Since this is done continuously, every transaction that should hit the DB is recorded and can be replayed if required. From the Postgres documentation:

“We do not need a perfectly consistent file system backup as the starting point. Any internal inconsistency in the backup will be corrected by log replay (this is not significantly different from what happens during crash recovery). So we do not need a file system snapshot capability, just tar or a similar archiving tool.”

With regards to the VCSA, this means that your image level backups  will be consistent, and there isn’t really a need to dump and export the vPostgres DB and then archive that. Yet another reason to switch to the appliance today!

Myth busted!

Importing vCloud Air SSL Certificate on the vCenter Server Appliance 5.x

I’m playing around a bit with vCloud Air and Virtual Private Cloud OnDemand, and in order to set up the vCloud Hybrid Service plugin in the vSphere Web Client you need to import the vCloud Air SSL certificate into vCenter. If the certificate isn’t present in the vCSA keystore when you try to authenticate with vCloud Air, you get a “Server Certificate not Verified” error, and you will be unsuccessful in configuring the plugin.

The Using the vCloud Hybrid Service vSphere Client Plug-in document outlines how this can be accomplished, but it’s based on downloading the SSL certificate via a browser and then importing it into the vCenter Keystore. Since I mostly run the vCenter Server Appliance, I didn’t want to bother with downloading it from one of my desktops, and copying the files over to the vCSA for import.

I mean, there has to be a better way to do that, via the command line, right? Indeed there is, this little one-liner downloads and formats the certificate from to /tmp on the vCSA, and then proceeds to import it into the keystore.


[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
echo -n | openssl s_client -connect | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > /tmp/vchs.cer && /usr/java/jre-vmware/bin/keytool -alias vchs -v -keystore /usr/lib/vmware-vsphere-client/server/configuration/keystore -storepass changeit -import -file /tmp/vchs.cer

All you have to to is press ‘y’ to confirm the import:
[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”1″]
Trust this certificate? [no]: y
Certificate was added to keystore
[Storing /usr/lib/vmware-vsphere-client/server/configuration/keystore]
vcenter:/tmp #

And there it is, you can now add your vCloud Air credentials via the vSphere Web Client, without having to copy any files from your browser/desktop to the vCSA.