#Blogtober 1 – Don’t Pester With My Vester

Don’t you hate it, when someone comes into your organization and tells you the environment is not consistent, or the environment is not configure correctly? That’s a small hit to the gut. This recently happened to me. An outside consulting group came in and reported some inconsistencies with our VMware environment. The report showed some hosts with NTP turned off, some hosts with SSH service turned on, and some VMs with old snapshots. Our environment has exploded and it’s been hard to keep up with the explosion. We needed a way to configure the environment the way we wanted it to be configured.

This reminded me of a session Chris Wahl did back at VMworld 2016. Chris talked about an Open Source project that he started called, Vester (here). The administrator can tell Vester how the environment should look. The admin can configure HA, DRS, VMhost services, even get down to the VM level and remove attached ISOs. This might sound like host profiles, but “why use the system to monitor itself.” This resonated with me, partly because we weren’t having much luck with host profiles. You should have a component outside the environment looking for changes, not the system monitoring itself.

This gave me the perfect opportunity to dive into Vester. Since Chris’s release, he’s since moved on and Brian Blake has taken over. Brian has released a very good youtube video, a walk through blog, and even gave a quick overview on the vBrownBag stage at VMworld 2017 (here).

Getting Started

One of the nicest things about Vester, is that it’s all PowerShell base. My comfort level has increased with PowerShell over the last year, so that’s why I found Vester so attractive. There are other options, including vSphereDSC, but I wanted something I didn’t have to invest a lot of time researching something new.

The easiest way to get started with Vester is to use the PowerShell Gallery plugin and run Install-Module -Name Vester. Wait for the necessary bits to download and open your favorite PowerShell editor. Once the necessary components have been downloaded (Pester and PowerCLI), create a .ps1 file and copy the following components into that .ps1.

# Your vCenter server
$vCenter = 'your.vcenter.com'

Install-Module Vester
Import-Module Vester
# Module requirements "Pester" & "VMware.VimAutomation.Core" automatically load into the session

# Do you care about Distributed Switches?
# PowerCLI doesn't do implicit module loading yet, so manually import any other needed modules
Import-Module VMware.VimAutomation.Vds

Connect-VIServer $vCenter

# Help is available:
Get-Help about_Vester
Get-Help New-VesterConfig
Get-Help Invoke-Vester

Generate JSON File

Before creating the first JSON file, be sure to have a cluster, host, or virtual machine in the end desired state. For example, I made sure one of our VM hosts had NTP turned on, pointed to the correct NTP server, and turned off SSH.

Once you have the .ps1 with the code copied to it, you are ready to generate your first JSON file. Run the NewVester-Config cmdlet, follow the prompts, and point it to a VMhost in a Cluster in an end desired state and it will create a new config.JSON file located under \Config folder. The generated JSON file is what Vester relies on to configure and set your Cluster/Hosts/vCenter/Networking/VMs consistently across the board. It’s essentially the map of settings on how you want the environment configured.

Testing Vester

Now that we have the map (JSON) created, we need to test it against the environment. This is where we see how close things are set to our desired end state. The command to run is Invoke-Vester. This command will use the default location of the config.json file and compare the rest of the objects in the environment against it. No changes to the environment occur at this time, we’re only comparing, so you get a sense of what will change with the next command.



This is where things get fun! We are going to change the environment to the state you’ve configured in the config.json file. The command is simple but powerful, Invoke-Vester -Remediate. If you’re nervous, I was the first time running, you can follow the command up with –Whatif. Once you’ve issued the command with the –Whatif and you like what you see, remove the –Whatif switch and watch your environment be set the way you want it to be configured. After running Vester and knowing my environment is configured consistently across the board, it really gave me the sense of this Infrastructure as Code ideology I’ve been reading about. I can use a flat file (json file) that any engineer or manager can read and know exactly how the environment is configured.

Wait, There’s More

Not all environments are created equal. We have a few clusters in our environment, like Test vs Prod, that needed to be set differently between each other. Vester tackles this issue as well. Using invoke-Vester -Config .\name.json will allow you to run specific config files so each cluster/environment can have its own desired end state.

Invoke-Vester -Config TestCluster.json
Invoke-Vester -Config ProdCluster.json

You can generate a new config file using the code below, but since the JSON file can be opened up in any text editor, I chose to copy and edit the copied version to the states that matched the environment. It’s up to you, but nice Vester gives us options.

New-VesterConfig -Output "C:\newConfig"

The project covers a lot of your basic configurations, but I have found a couple of things that I would like to have added, like check round robin SATP rules. The best part of Open Source, YOU can make this happen. Brian has given a great part 3 series to the blog about how anyone can contribute. I have yet to adventure down this path, but figure the more I rely on Vester, the more I should contribute. So, keep your eyes peeled for my git request.


This was one of the first Open Source infrastructure projects I’ve used. I was nervous and used extreme caution before running in my production environment. After I got over the fear and saw Vester run without causing issues, I wanted to automate and code more things. To know my clusters, hosts, and VMs were configured exactly how I wanted them. No more outside people telling me the environment is inconsistent. I’m understanding this Infrastructure as Code movement and I’ve seen the power first hand.

Leave a Reply

Your email address will not be published. Required fields are marked *