An Open Request for Feedback – vSphere Configuration Management with Vester

Chris Wahl · Posted on

Back at VMworld 2016 US, I co-presented a session entitled  “Enforcing a vSphere Cluster Design with PowerCLI Automation – INF8036” with VMware’s Chief Technologist, Duncan Epping. The centerpiece of this deck was built around an open source project named Vester. Created in March of 2015, this was my attempt to write PowerShell code to test and enforce configuration values for a VMware environment. In fact, the name was born from a combination of the words vSphere and Pester … because naming things is the hardest part of any open source project. It was originally just called the Lab Config Project because that was my primary use case at the time: to keep my lab consistent across tinkering attempts.

Vester is about to turn two years old. I’m so incredibly proud of all the effort that many, many people around the world have put into the project. At the time of this writing there have been 235 code commits across 8 public contributors with 57 individual tests available. That number is constantly growing. At this point, most of my original code isn’t even there anymore, which is fine with me! I’ve learned a ton of new things watching other people spend their time and energy working on the project.

A special kudos to Brian Bunke for taking on the role of being a project administrator and poking me when I forget to review pull requests. 🙂

Calling All Testers!

If you’d like to get your hands on Vester and give it a whirl, we’ve got an open solicitation for feedback with the 1.0.0 release! This contains instructions on what sort of testing and feedback we’re looking to receive. This includes a fancy new version that has been ported over to the PowerShell Gallery. Can’t make it any easier! 🙂

If you’re new to Vester, you might be wondering – what exactly does it do? Simply put, Vester is designed to read a set of configuration values for cluster, host, network, management, and virtual machine objects. It then examines a vSphere environment to see if the objects have the same value as described in the configuration file. Vester will report if any differences exist and optionally remediate them. The actual testing process is achieved by using another project named Pester. This is primarily a unit testing framework written for PowerShell. You can literally feed two values into a Pester test, have them compared, and take actions based on the results.This eliminates the need to write something from scratch.

Some advantages to this approach:

  • Vester runs without requiring any installation beyond grabbing a module and storing it on any workstation of your choice.
  • No knowledge of third party tools required; get started immediately with hardly any effort.
  • No special vSphere license level (such as Enterprise Plus to gain Host Profiles) is needed – any licensed version that grants API access will work.

If you’d like, the best place to begin is reading the official documentation. I’ve begun the process of migrating those over to Read the Docs because I’m rather taken by RST files these days. In a nutshell you just need to download the files from the GitHub project and drop the included Vester folder into your preferred module directory. For most folks, this is going to be the %USERPROFILE%\Documents\WindowsPowerShell\Modules folder. Once there, we have some new goodies available!

We also have a fun group of people on the VMware {code} Slack! Sign up for an account and then join the #Vester channel. Make sure to say hello to our Deadly Viper Assassination Squad taco bot. She’s quite sassy.

Some of The New Hotness

Back when I presented Vester at VMworld, it was still a bit rough around the edges and the configuration file had to be written by hand. More recently you can use the New-VesterConfig function to automatically inspect and build a new configuration file. It will bring up a wizard that allows you to select a reference data center, cluster, host, virtual machine, and so forth. The results are stored in a JSON file.

Once the configuration file is created, you can edit it further with any changes you may require. I have a few different configuration files – one for each vSphere environment that I manage. If you don’t want to run tests on a particular value, set it to $null.

From there, all that’s required is using the Invoke-Vester function to start testing. There are a number of parameters available for picking a specific configuration file, limiting the tests that are run, passing through results to another object, or saving output data to an XML file.

I’ve run a sample configuration on my vSphere 6.5 environment below and revealed that the SSH Service is not running on host esx15.rubrik.demo. The configuration file says it should be.

Running the command a second time with the -Remediate parameter enabled allows Vester to fix the drift.

Fairly simple, right?

Thoughts

I’ve definitely learned a lot about working on an open source project and building a module in PowerShell by working on Vester. The number of smart folks who have stepped up to contribute their skills to the code has been very educational and humbling. I hope that you’ll give the project a try by checking out our call for feedback and let it compare your desired configuration to the actual current state. And if you discover that a test is missing that is important to you, get involved! Everyone is very friendly and willing to help usher along new ideas.