Verifying many VLAN/subnets on a ESXi host

This script is designed to automate the network validation testing that is often required when standing up a new ESXi host, to verify that the host can reach each VLAN/subnet it is supposed to reach.

The script works by reading a CSV file listing network and VLAN ID information, and then creating a temporary port group and VMKernel port on each VLAN ID with the appropriate IP address and subnet mask.  It then pings the specified gateway IP and returns the result in summary format.

It is fairly robust as far as execution goes – if interrupted, it can just be run again.

Running it with $automatedExecution = $true will run through all the tests and report the summary.  The default mode, $automatedExecution = $false, will prompt at each significant action, giving you a pause to troubleshoot if something goes wrong.

Create a CSV file following this format

Then run this script, passing the appropriate parameters (they are self explanatory).

Audit multiple Windows vCenter service user accounts

I wanted to audit multiple Windows vCenter servers to determine if service accounts were configured consistently for the various vCenter services.

This was to support troubleshooting a customer issue described in the below KB

“VMware KB: Logging in to vCenter Server in linked mode using the vSphere Web Client fails with the error: Unable to connect to vCenter Inventory Service on xxxxxxxx

This issue may occur if the Windows account that is used to start the VMware VirtualCenter Server service is different from the account used to start the vCenter Server Inventory service.”

Check VM Tools Update Policy for all VMs

A customer had a requirement to quickly identify if VMs were configured to automatically update tools at restart.

This one-liner will output a report showing all VMs, their current power state, whether the “Check and upgrade VM tools during power cycling” option is enabled.

Remove HP-AMS from HP hosts, via SSH

I had a customer hit with the HP-AMS memory leak, presenting as an inability to complete vMotions.  For information on the issue, see

As stated in the above blog, vMotion still works so long as you target a working host.  Unfortunately in a monolithic environment a memory leak on one server means it is probably only a matter of time before all the hosts will be in a non-functional state.

So, to facilitate stopping the AMS service on all reachable hosts to mitigate occurrence of the issue while we planned maintenance for a permanent solution, I wrote this script to automate the task of stopping the ASM tools and removing them.

My coworker Jason did a good write-up on how we got to the point of wanting to do this, see his blog entry for more.

Since the HP ASM tools need to be stopped using a console based command (/etc/init.d/hp-ams), my PowerCLI script generates a series of commands that will connect via SSH and run the hp-ams STOP command.

Because at this point I’m already logged on to the host, I also issued the esxcli command to remove the AMS VIB.  (This could have been done through other more elegant means such as a Get-EsxCli object.)

It uses the command-line version of PuTTY, plink.exe to connect to each host.

The resulting output is a series of commands like:

This will stop the hp-ams process, query the status for confirmation, and remove the VIB.

Again, this was a stop-gap solution to prevent the memory leak issue from taking down working hosts.

Finally, here’s a quick script (based on a previous post) to check the HP-AMS VIB version:

Query ESXi hosts installation media type and specific driver version

This is a quick one-liner to get hostname and the name of the ESXi image profile used to install ESXi on the host.  It leverages remote access to esxcli via PowerCLI Get-EsxCli and the “-join” operator to build a CSV string for output.

I needed to verify the HBA driver version as well.  You can extend this script by adding another item to the array before -join, just add a comma after the last “.ID” and add another element there.