Appendix D - Perl SDK for VMware vSphere
There are some things that Puppet’s Cloud Provisioner can’t do - one of these is editing the specifications of the machine it’s building (i.e. CPU count, RAM etc.). The Cloud Provisioner approach expects templates to be created with the necessary specifications, but this would require maintenance of multiple ‘standard build’ templates, which is not terribly practical.
Instead, we would like to be able to change various settings automatically from within our provisioning scripts. For this, we’ll need to use the vSphere API.
Note: This document assumes the reader is familiar with using CPAN to install Perl modules.
Installing the Perl SDK
We install this on the Puppet Console server, as it’s the Cloud Provisioner control node. Here are the installation instructions.
Download
The SDK can be downloaded here.
Since we’re using vCenter version 5.1.0, we’ve chosen the 5.1 version of the SDK. The filename is VMware-vSphere-Perl-SDK-5.1.0-780721.x86_64.tar.gz
Prerequisites
Some packages are required before the SDK will even consider installing:
We also need to set this environment variable to allow Perl’s https client to not worry about verifying certificates:
Without this, we’ll get the following error when trying to connect to vCenter:
It’s useful to set this variable in our .bashrc file.
Install
We move the tarball to the /tmp directory and unpack it.
We also had to set the http_proxy and ftp_proxy environment variables, even though the installation instructions say this is an optional step:
The installer used CPAN to download any pre-requisite Perl modules, but it couldn’t get all of them:
It couldn’t install these due to some missing RPM packages:
It’s not clear whether the vSphere SDK installer was successful, so we’ll try running it again…
After accepting the licence agreement, we see this:
So it looks successful, but there’s a warning about some out-of-date Perl modules. These are the versions that ship with CentOS, so we may as well upgrade these with the CPAN versions to avoid any subtle problems later. To test, we use one of the SDK’s utility scripts:
Credential Store
To store passwords so we don’t have to keep supplying them on the command line, we can use a credential store. This is how to add an entry to the store:
This adds an entry to the file /root/.vmware/credstore/vicredentials.xml.
The SDK scripts automatically look for credentials in this file, so once the credentials have been added, we can run the same comands as before without the password option:
Note that this doesn’t work with the –url option, only the –server option.
A Problem…
In hindsight, updating LWP might not have been the best idea. It seemed to mess up the SOAP communications between the client and server. When testing with the above script, it took a very long time to connect, then a very long time to eventually tell us there was a “SOAP request error - possibly a protocol issue”.
The answer lay in downgrading Net::HTTP and libwww-perl, as described in this helpful blog post.
In summary, this is the fix:
Once that’s done, the connect script (which used to take about 3m 50s to run) completes in about 4 seconds. So we can now get started by reading the SDK documentation.
Summary
The Perl SDK is enormously useful - if you have time to figure out how it works. Unlike most Perl modules, the VMware modules come with very little documentation. The official documentation is terse and only marginally helpful.
I eventually cobbled together a script to do what I wanted - namely, set the number of vCPUs and amount of system memory allocated to a VM
- after trawling through the example scripts and utility modules. This ‘vmspec’ script (now available on GitHub) enables us to set the desired spec of the VM at provisioning time, and plugs neatly into the ‘hatch’ auto- provisioning script.
It’s easy when you know how!