“Get VM HostSystem and ResourcePool” Orchestrator Workflow

The Problem

Jason recently blogged a VMware Orchestrator workflow we developed, which automates applying Windows updates to template VMs.

While fine-tuning the project, we decided to resolve one of the persistent annoyances of the workflow: it required extra fields that most administrators would probably find unnecessarily nitpicky.  Relevant:

Actual screenshot of too many options:

What’s the issue?  The first step of the workflow is to reconfigure the VM Template to a standard Virtual Machine.  Orchestrator has a built-in workflow to perform this action, but it requires three parameters – VM, host, and resource pool:


Is it really necessary to pass these options on to the administrator?  Nope, not at all…

The Solution

We simply want the standard VM to spin up on the host (or cluster) where the VM Template is currently living.

I created a new workflow that accepts a Virtual Machine and returns its current host and resource pool.

The scriptable task “Get Info” has the following input and outputs configured:

Note – the VC::VirtualMachine can be a VM Template or standard VM.  Either type works.

Using Orchestrator’s object library and Javascript, getting the current host is trivial, just one line of code:

It’s that easy.

Getting the resource pool is a little more complex.  We can’t (to my knowledge) directly query the root resource pool from a VC:HostSystem object, nor from a VM.

However, we can get the VC:ComputeResource for the host, and then query the root resource pool from the compute resource.  Exactly what we need.

Here’s log output from a real run:

This approach also works for ESXi hosts outside a cluster.  In that case, the script will identify the host’s “parent compute resource”as the host itself, since in that scenario the top-level compute container is the standalone host.

Here’s the complete script:

I then went back to the Update Template workflow and popped in my new workflow, “Get VM HostSystem and ResourcePool”:

Orchestrator has a handy feature to convert workflow input parameters into attributes, so I migrated the “Host” and “Resource Pool” inputs over to attributes, and used visual binding to associate the output of the new workflow with the corresponding attributes.  The host and pool attributes are then consumed by the existing “Mark as VM” workflow.

Here’s our simplified input screen.

Note that if this workflow is launched from the vSphere Web Client context menu for a VM, the VM field is prepopulated.  In that case, the administrator need only specify the guest OS username and password and can move on their merry way.







Audit for VMware Tools Version matching VMware KB 2115997

This one-liner will find online VMs running VMware Tools versions that match the KB below.

I am using the -AllLinked flag to audit multiple vCenter’s inventory in a single go.  You might adjust the array to specify your own versions to find.

Another option would be to remove the filter from the pipeline and export the results of the select statement to CSV using Export-CSV.  Then you could use Pivot Tables in Excel to report on number of VMs with specific versions, and so on.


Configure host networking based on ESXi server name

Quick and dirty script to set host networking (DNS name, DNS servers, domain name) for hosts based on the server name.  Assumes server name is in format “host1.lab.local” for example.


Audit Windows network adapter speed and capability

Quick & dirty script to audit network adapters Windows OS network adapter active speed vs. adapter capability, using a combination of WMI calls.

Although the script is handy, it also illustrates the use of parallel foreach execution in workflows, a Powershell 3.0 feature.

Test Host Networking (for many hosts and port groups / VLANs)

Testing all the things… the automated way!

When standing up new servers, clusters or networking, I like to be extremely confident in the consistency factor across hosts and network uplinks before bringing production workload online.

One common test we find requested that is the good old “assign a test VM to a particular IP network and port group, and run a ping test.”  However, this type of approach is tedious when performed manually.

To automate this, I wrote a short PowerCLI script to run these types of tests.  I also included several other networking tests on the recommendation of Matthew Mabis, a VMware consultant, based on his experience dealing with common networking issues in many environments.

The script also builds on the idea and some previous work Jason did towards automating this process.  One of the key refinements is the use of Invoke-VMScript to make networking changes to the test VM, a method which will succeed even if guest OS networking is down due to a particular failed test.

The script takes as input a CSV file listing port groups and valid IP information to be used for testing the specified port group.  Note this was designed for distributed virtual switch environments only, so if you are using standard switches, this won’t work for you.

Input and Specific Tests Performed (Host, Uplink, Port Group)

Here’s an example of the input CSV:

The script performs two main tests.  Both tests involve setting a static IP address on the test VM guest OS that is valid for the port group or VLAN being tested.

  • Test A: Check port group configuration – if I place the VM on the DVS port group, can I ping the test IP?
  • Test B: Check VLAN config for each uplink on each host – if I assign the VM to a specific VLAN ID, and direct traffic through a specific uplink, can I ping the test IP?

When the script runs, a cluster is specified for testing.  The script will perform test B on each host in the cluster.  Test A is really geared towards checking the port group configuration, so to save time during test A the test runs from the host the test virtual machine is currently assigned.

Regarding test B, here’s a visual diagram of what we are trying to test.  Basically we grab the VLAN tag from each port group listed in the source file, assign them one at a time to the port group, testing each uplink individually:

The reason we do this is to check if a specific physical or virtual uplink was misconfigured, does not carry all the VLANs intended, and so on.

Sample Output

When the script is complete, it generates output as follows.

Using the Script

You can use the Get-Help cmdlet for reference against the script:


Example of Running the Script

Finally, here is a sample of executing the script.  Just a few parameters are necessary:

You can see several things going on here, a ping test that just completed successfully, reassignment of uplinks for the test port group, and a vMotion action to migrate the test VM to the next host in the test.


A couple of notes:

  • To test each uplink without risking impacting existing port groups, I opted to create a new port group and just copy the VLAN tag from each port group specified in the input CSV file to the test port group in turn.
  • Before the test runs, we query the test VM for its currently assigned port group.  When the test is over, we reassign it back to the original port group.  This frees the test port group of VMs allowing us to delete it and return the environment to its original state.
  • As usual, use at your own risk!  There are some opportunities for error checking and early termination that need to be added before this is a polished tool.

Updated 9/27/15

  • Fixed handling of port groups with no VLAN tag assigned


Updated 3/3/16

  • Pointed to github repository

Download this and any of my other scripts at my GitHub repository (link up top).  You’ll want to grab test-host-networking* (2 files) from here https://github.com/jeffgreenca/powershell-scripts/tree/master/networking