Tips for writing Vester test files, part 2


This post is the second part in a series about writing effective Vester test files. The previous part can be found here.

When there is no easy Get and Set

An example, we want to create a test to check the Cluster DPM settings. The Get-Cluster cmdlet can show many properties, however the options of the corresponding Set-Cluster cmdlet are limited. You can see for yourself running the following command:

PS> help Set-Cluster -Parameter *

Commands like Get-Cluster, Get-VMHost, Get-Datacenter are practical, easy to use but have some limitations, like not showing all info and are not blazing fast.

Time to meet the Get-View cmdlet, a bit less user-friendly, but much quicker and very useful. The equivalent for the Get-Cluster cmdlet is:

PS> Get-View -ViewType ClusterComputeResource</span>

To select a specific Cluster, use the -Filter parameter, like:

PS> Get-View -ViewType ClusterComputeResource -Filter  @{"NAME"="Cluster01"}

Another way is:

PS> Get-Cluster -Name Cluster01 | Get-View

Time to create the first DPM test. To test if DPM is enabled, execute the following commands:

PS> $Cluster = Get-Cluster -Name Cluster01 | Get-View

And run this:

PS> $Cluster

You can see all properties, note there is “Configuration” and “ConfigurationEx”. Run both:

PS> $Cluster.Configuration
PS> $Cluster.ConfigurationEx

And note the difference, $Cluster.ConfigurationEx has a “DpmConfigInfo” section. The following line will show the current DPM configuration for Cluster “Cluster01”

PS> $Cluster.ConfigurationEx.DpmConfigInfo.Enabled

Enabled DefaultDpmBehavior HostPowerActionRate Option
------- ------------------ ------------------- ------
   True          automated                   4    

We can now write the first part for the DPM enabled test.

$Title = 'DRS Power Management enabled'
$Description = 'Enable Power Management DPM'
$Desired = $cfg.cluster.drsDpmEnable
$Type = 'bool'

# The command(s) to pull the actual value for comparison
# $Object will scope to the folder this test is in (Cluster, Host, etc.)
[ScriptBlock]$Actual = {
    ($Object | Get-View).Configurationex.DpmConfigInfo.Enabled

# The command(s) to match the environment to the config
# Use $Object to help filter, and $Desired to set the correct value
[ScriptBlock]$Fix = {

Read the rest of this entry »

Tips for writing Vester test files, part 1


Over the last couple of weeks, I took a look at the Desired State Configuration Resources for VMware (later more on that…).

But above all, I spent quite some time exploring Vester. Vester can be really useful, and it is relatively easy to create additional test files and get more configuration settings under Vester control. While working on new test files, I gathered some lessons learned that can be useful for others.

Naming Test file and the components

Choose a descriptive name for a new test file. Although test files are organized in folders, when the number of test files is increasing descriptive names can be helpful.
What makes a good name? Refer to something that is known and unique.
E.g. For vCenter Clusters, most settings are related to DRS or HA settings, the output of the following command can be helpful:

> Get-Cluster -Name Cluster01 | select *
VsanEnabled               : False
VsanDiskClaimMode         : Manual
HATotalSlots              : 
HAUsedSlots               : 
HAAvailableSlots          : 
HASlotCpuMHz              : 
HASlotMemoryMb            : 
HASlotMemoryGB            : 
HASlotNumVCpus            : 
ParentId                  : Folder-group-h23
ParentFolder              : host
HAEnabled                 : True
HAAdmissionControlEnabled : True
HAFailoverLevel           : 1
HARestartPriority         : Low
HAIsolationResponse       : PowerOff

E.g. Creating a test file for the HA Failover Level, name the test file: “HA-FailoverLevel.Vester.ps1”.
While working on a test file the following variables also play an important role.
The variable $Title is shown during each run of Invoke-Vester and can be used to provide more information then the title of the test file.

Fig. 1

Read the rest of this entry »

About Configuration Drift, Pester and Vester


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?

Read the rest of this entry »

Running unmap on a large number of datastores


With the VMFS-6 filesystem came the option to automatically unmap datastores. In short, the unmap command is used to reclaim unused storage blocks on a VMFS datastore when thin provisioning is used.

When Datastores are still on VMFS-5, reclaiming disk space is a manual process. VMware KB “Using the esxcli storage vmfs unmap command to reclaim VMFS deleted blocks on thin-provisioned LUNs (2057513)” details how to use the unmap command.

The action is performed on an ESXi hosts, the basic command looks like this:

# esxcli storage vmfs unmap -l <Volume label>

Where Volume label is the human readable name of a Datastore like: “VMFS01”.

Depending on the size of the datastore(s), running unmap will take quite some time. If you have few datastores, you run this command a couple of times and voila. If cluster(s) have dozens of datastores, the following workaround can help you.

Read the rest of this entry »

Getting started with the vCSA 6.x – Part 3


In part 1 and part 2 of this series about the vCSA, we have covered topics like; the shells, filesystem, services, health, logging, database and some extra tools. Recently I realised there a few more topics worth mentioning.

Appliance MUI

In pre 6.0 releases of the vCSA, there was a vCenter Server Appliance Management Interface, better known as the VAMI. This management interface is written in HTML5 and is now called the e Appliance Management User Interface (Appliance MUI).

You will find the new management interface in vCSA 6.0 and 6.5, however there are some differences.

You can login to this interface, using: https://<vCSA fqdn or IP>:5480. Us a local account such as the “root” account.

Fig. 1 – Summary vCSA 6.0.

Read the rest of this entry »

Getting started with the vCSA 6.x – Part 2


In the previous post we started to unravel the vCSA and discussed topics like the Appliance shell, the file system and the services. In this post we will continue with the vCSA Health.


Knowing the health of your system is important. Like the Windows vCenter Server, the vCSA is also able to report its health. Most common is using the vSphere Web Client and from the main menu, choose: System Configuration and watch the “Service Health” pane. Detailed information can be found by clicking on the various Services.

Figure 1

However, from the Appliance shell, the following API command will also inform you”


If everything is OK, it will report; Health: green

In the Bash shell, you can browse to the folder: /etc/vmware-sca/health/.
On a vCSA 6.0, you will find two files with health status information:


On a vCSA 6.5, you will only find the first file.

Read the rest of this entry »

Getting started with the vCSA 6.x – Part 1


The vCenter Server Appliance is the new vCenter Server. In the old days, we had a brand new Windows Server on which the vCenter Server was installed. The necessary database server was quite often an external MS SQL database and sometimes an internal database. In the those days, tweaking the Windows Server and the installed components was more or less a common practice, due to the familiarity with Windows.

But now the vCenter Server Appliance (vCSA) is the new and preferred standard. The vCSA comes as a virtual appliance and is ready to run within minutes compared to the old vCenter Server. Although a (virtual) appliance still means; (virtual) hardware, an operating system, middleware and applications, VMware likes to treat the vCSA as a “black box”. Like most appliances, the operating system is a Linux flavor and you can log in. After a successful log in, you will encounter the first discouragement; you are not welcomed by a Bash shell but with the default “Appliance Shell”. For more information read my post on the vCSA shells.
In this post, a brief introduction on the following topics; Appliance shell, File system and the Services.

Read the rest of this entry »