Basic inventory of HyperV virtual machines using PowerShell

Here at Basefarm we operate at a large scale with thousands of servers running for our customers. Quite often a customers asks for a list of machines with various properties for each machine.

Most of the time the customer want this information in an simple format so that they can use it internally. In this blogpost I will show how you can get the information about memory, CPU count etc for a set of Hyper-V machines from Virtual Machine Manager via PowerShell.

First off, start a PowerShell command line and load the PowerShell Snap-In for Virtual Machine Manager.

Add-PSSnapin -Name Microsoft.SystemCenter.VirtualMachineManager

Now we can work with the commands made available to us by the Snap-In, if you want to find all the commands that are available issue:

Get-Command -Module Microsoft.SystemCenter.VirtualMachineManager

So let’s begin by loading information about all our machines from the VMM host into a variable named $VMs

$VMs = Get-VM -VMMServer

What the above command does is to load all of the VMs on the host into the variable $VMs. This means we will only do one call to the server which avoid generating unnecessary load.

Now let’s check how many machines we have:


And now that we know we have machines to query, let’s find out what attributes exists (things we can get into our output)

$VMs | Get-Member -MemberType Property

For example, to find all macines that are powered off:

$VMs | where { $_.Status -eq 'PowerOff' } | select VMHost, name , Memory, CPUCount , Status

The above example adds some complexity to the command, but it is to filter so we only see machines that have the status is ‘PowerOff’.

Now let’s get what we wanted from the beginning, a list of machines for a specific customer. The list should include name of the VM host, VM name, memory, number of CPUs and current status.

$VMs | where { $_.Name -Match 'CUST*' } | select VMHost, name , Memory, CPUCount , Status

This will list all machines who’s name begins with ‘CUST’. So we now have found what we wanted!

But instead of copying & pasting this we want to write the result to a CSV file so we can send that to the customer. Let’s make that easier by getting the output of the above command into a variable named $result

$result = $VMs | where { $_.Name -Match 'LFO*' } | select VMHost, name , Memory, CPUCount , Status

Now our ‘report’ is stored in the $result variable and we can use standard PowerShell to export it to a CSV file:

$result | Export-Csv -NoTypeInformation -Delimiter ';' .\report.csv

Now our report is available in a CSV file on the file ‘report.csv’ (in the current directory)

A very basic way of getting your Hyper-V inventory out!

Cannot add new node to windows hyper-v cluster–SCSI disk validation error

We make extensive use of Hyper-V within Basefarm and I recently encountered a strange problem when doing maintenance on a 5 node windows cluster running the hyper-v role. For reasons I won’t bore you with here (pre-production testing basically), I had been evicting and adding nodes to my host level windows cluster, but when trying to add a node back I encountered errors in the validation tests. This was strange as the node had actually previously been in the cluster and nothing had been changed on it whatsoever, so I already knew that it had previously passed the validation test and been successfully running as a cluster node!

The cluster validation reported an error of this format in the storage tests named

Validate SCSI device Vital Product Data (VPD)


It looks like the above picture when you view the validation report.

The actual errors returned were like this:

Failed to get SCSI page 83h VPD descriptors for cluster disk 1 from node <nodename> status 2

(I’ve removed the node name here obviously but it does say specifically which one in the report):

Fortunately before too long I found that this was due to a bug in hyper-v validation for which a hotfix is available here

Downloading and installing this on all the nodes and potential new nodes resolves the error.

This goes to show the value of pre-production testing as the aim of this cluster is to provide a dynamically expanding virtualisation service for one of our largest customers. If it came to a production situation where I needed to add a node quickly, this is not the type of scenario I would be wanting to troubleshoot live!