The kitchen-vcenter Driver

While many companies already rely on some Cloud for all of their IT systems, bigger enterprise customers often have own data centers which consist of thousands of virtual machines. Under these circumstances, it is often not desirable to only test Chef cookbooks on AWS or Azure, but doing this in the real environment is a better idea. The kitchen-vcenter driver allows you to harness the power of your own IT systems.

Background

In some projects we are working with air-gapped systems or migrate entire datacenters to configuration management using Chef. As anybody who had to work in such an environment can confirm, this poses unique challenges. Sometimes you have to rely on internal artifact servers like JFrog Artifactory and cannot simply install any tool from the Internet. In other situations, you are forced to use internal proxy servers for connectivity or have very special Windows OEM images which differ greatly from stuff you can find in the Cloud.

While searching for something more resemblant of on premises testing, I came across the kitchen-vcenter driver on Github which was pretty old and bulky at that time. Luckily, two customers agreed to sponsor a complete rewrite and still continue to support development of new features. Of these two, Siemens Gamesa is also proud to be openly named as a sponsor of this project and other Chef-related contributions. Big thanks to them for making all these enhancements possible.

Over the next few posts, I will detail the features and unique possibilities that the new driver offers for those situations.

Installation & Configuration

Installation of the driver is pretty simple now:

gem install kitchen-vcenter

If you tried to use the driver before September 2019, you might have had problems especially on Windows due to some obscure dependencies which were present before (specifically the ethon gem). Due to the work of J.R. Garcia from VMware, this problem was recently fixed in the underlying vsphere-automation-sdk-ruby Gem in versions 0.4.0 and up. Thanks!

As soon as you installed the gem, you can start adding the necessary options to your .kitchen.yml file:

driver:
  name: vcenter

  vcenter_disable_ssl_verify: true
  vcenter_host: vcsa.lab.local
  vcenter_username: "<%= ENV['vcenter_user'] %>"
  vcenter_password: "<%= ENV['vcenter_password'] %>"

  datacenter: "Datacenter"
  
platforms:
 - name: win2016
   driver:
     template: 'win2016-template'

At this point, I will assume either you or your organization VMware admin have created a technical user for all your Test Kitchen needs. I tried to include a reference of needed permissions in the project’s README.md file - if anything is missing, please create an issue and I will try to improve on this.

The main points in the configuration are of course the credentials to your vCenter server. You should never put real users and passwords into this file, because they might end up in GIT. Using environment variables has proven valuable for this, sometimes we even have most of the configuration values handled in that way.

In most environments, the VMware SSL certificates seem to be self-signed or the internal CA certificates are not distributed properly. That is why the SSL verification is often skipped. Managing a VMware related PKI is a bit complicated, as I heard.

Location

You will need to supply the name of your vCenter datacenter that the VMs should be created in. Datacenters are a foundational organizational unit in vCenter which specify the exact location of virtual machines.

If you have more specific needs, you can be more specific:

• cluster can specify a designated development cluster of ESX hosts
• targethost can be used to reference a specific ESX server to deploy to
• folder specifies a VM folder to group your kitchen machines

While a resource_pool is also often used to group VMs, this is generally not a good idea and is a legacy setting of the driver:

In VMware, resource pools are used to create a hierarchy to distribute CPU or Memory across virtual machines. If your vCenter had only to 2 VMs on the “top level” and next to it a resource pool with 10 VMs in it, those 10 VMs will only get 1/3rd of the allocated resources. Please use folder to organize your kitchen instances due to this reason.

Using Templates

As there is no automatic lookup of matching templates (compared to the kitchen-ec2 driver), we have to point Test Kitchen to the base of our VM. Currently, you can only use normal VM templates and not the newer Content library - sorry!

While the parameter is called template, it will also accept a VM. For some types of clones this is even necessary, the details will be in another post.

Please remember to include the VMware tools or open-vm-tools in your templates. These are important to allow vCenter to get info about the IP of the machine and is a hard requirement for using the kitchen-vcenter driver.

Clone Types

If you are trying this out and wonder about the time it takes to get a new VM: for now, we are copying the disk of the template before starting the VM (a Full Clone). In later posts, we will look at other clone types which are much faster.