This topic has been on my mind for quite some time, but it was until recently, when attending a presentation, that the picture became much clearer.
In this post, I would like to share some of my thoughts.
To install and configure vSphere environments, we can use various methods, from manual, all kind of scripting, to fully automated deployments.
vSphere also comes with tools, like Host Profiles which can be helpful. After installation and initial configuration is done, we are not finished. We also want to enforce a consistent configuration, but how?
Again, Host Profiles can be useful to maintain the state of ESXi hosts, but there are some objections. Host Profiles are difficult to setup and maintain (how nice would it be, if you could export / import a Host Profile in a more user friendly .JSON format?). But more important, hosts are only a part of the environment. How about configuration of Clusters, DatastoreClusters, Virtual switches and Virtual machine properties?
If you are familiar with PowerShell, you may have heard about Pester. Pester is a test framework for PowerShell. Suppose you have written a new function; to ensure that the function is working as designed, you create some test cases. If the outcome of all test cases matches the expectations, you may assume that the function is working correctly. This becomes even more important when changes are applied to the function. Now you may see the need for a way to a more structured way of testing your functions. Pester can also handle more advanced test scenarios; e.g. you can test a function which uses Active Directory cmdlets like Get-ADUser, without a real Active Directory present. BTW, Pester comes as part of Windows 10, can easily be installed in other versions and PowerShell Core.
If I have aroused your curiosity, there are many excellent blog posts about Pester. To get you started, I recommend this five-part series on Microsoft Technet.
After attending a presentation/workshop about Pester, I began to see some overlap between my “Configuration drift issue” and this test framework.
A Google search on “Pester” and “VMware” brought me to “Vester”.
In June 2016, Chris Wahl wrote a post on using Pester to remediate configuration drift in a vSphere environment. In March 2015, an open source project named Vester was started and two years later presented with an open request for feedback.
Vester is also based on Pester and comes as a PowerShell Module, that lets you create a baseline of an environment. After that, it can validate the configuration of the environment and if necessary correct deviations.
Brian Bunke, Vester’s PM, wrote a three-part-series covering many aspects of Vester, ranging from introduction to advanced usage. Brian’s posts provide enough information to get you started with Vester.
After setting up Vester, it’s a good idea to carefully read Brian Bunke’s posts and also have a look at the help files that come with Vester:
PS> Get-Help Invoke-Vester -examples
After running the first New-VesterConfig, have a look at the Config.json file that has been created. If you are planning to use Vester in a complex environment with multiple clusters with different configurations, you must decide how to handle this. New-VesterConfig and Invoke-Vester both have useful parameters to handle these situations.
You can adjust the scope by editing the Config.json file(s), and use PowerShell wildcards for the string values. A few examples.
Suppose you have some VDI clusters, names starting with “VDICluster” and server clusters, names starting with “Cluster”, this line will only select the VDI clusters:
and the other clusters will be in scope with this line:
To name some advantages of Vester. The configuration files are excellent human readable, and if the name of one of the tests isn’t clear enough, you can change the name in the test file (next).
Vester is very flexible, not only in defining scopes but especially when it comes to tests. Vester comes with a number of test, but you can also create your own test files. In his third post, Brian describes how to create a new test, step by step. Also the tests that come with Vester provide a wealth of inspiration how to create new tests.
As an example, the cluster section comes with a few tests regarding HA and DRS settings, but you can create additional tests. Just explore the Get-Cluster and Set-Cluster Cmdlets to see what is possible.
You can also take it a step further and not only check for configuration settings but also think about “business rules”. Think about Clusters with Host groups and VM groups.
However, there are still some items on my list that need further investigation. The first one is reporting. While running the Invoke-Vester Cmdlet, lots of information scrolls over the screen, you can send the output to a file with the parameter -XMLOutputFile, which will create a .XML file or create a new PowerShell object with the parameter -PassThru. But can we also get an exceptions report?
If we want to run Invoke-Vester at regular intervals, how can we integrate Vester with existing monitoring tools and/or automatically perform remediation?
At this time, I see great value in using Vester, mainly because of it’s flexibility. A big thank you, to all who contributed to Vester. My first task will be to create more Vester tests and try these out.
As always, I thank you for reading and welcome your comments.