Happy Birthday! – Give your VM a Birth Certificate

My first post – I planned something more elaborate, technical and earth-shattering, but after seeing the same question come up twice is less than a week on VMTN, decided on something more practical. If you’ve ever been in a situation where you’re looking to see when a virtual machine was deployed, or who deployed it, you’ve got a slight problem – VMWare did not include this handy information in the native properties, you need to find the VI event associated with it’s creation and gather it from there. This can be a problem in a busy environment with event roll-overs or even from a practical stand-point of having to do that search each time you need it. I would say, why not note it from the start?

Below is a script that I wrote that will allow you to gather that information on the day the VM is created. In my environment, I run this script nightly using Windows Task Scheduler. The script runs through a list of vCenter servers creation-related events. It parses those events into a human-friendly text string, and then replaces the newly minted virtual machines notes with information about it’s creation – a VM “birth certificate” per-say. When the script is run, you get a result like this:

That, at least, is the way I chose to implement this information; the same technique could be used to feed custom properties or filling in an inventory or change management database. I recently updated this script with a function created by LucD called Get-VIEventPlus. I originally used the native PowerCLI cmdlet Get-VIEvent, and you still can. Even though, it runs nightly in the background I’ve been optimizing the run-time on a number of scripts and Luc’s function IMHO is slicker and runs faster than the native cmdlet. You can learn more about Get-VIEventPlus here.

Below is the code – scroll down if you want the play-by-play annotations of what’s going on. If you’d like to get the latest version, or contribute, you can join my Github repository at https://github.com/kdmhorn/powercli – it’s in the “adminscripts” folder. Thanks for reading and be sure to stay tuned for more to come!

Updated: 3/21/2017 – Minor bug fixes and line changes, see comments for details


Lines 1 – 44: Not much code to see here, I like to include fairly detailed notes on what the script is for and how it changes over time – you should too. Because I incorporated the Get-VIEventPlus function and it was well noted, looks like I’m in good company there.

Lines 46-147: This is the Get-VIEventPlus function from LucD. You can read more about it here. Simply put, it’s fast, really fast!

Lines 148-160: Here is where the runtime is set up. In Line 149 I identify the number of days between each run of the script, by default I specify 1 day. $AdminName is pretty straight forward, change it to whatever account has the rights to read VIEvents and can change VM properties. In line 151, I’m using a password file to safely store the password. There’s a decent article here on how to do that. Line 150 I load a text file that simply has a list of vcenter servers FQDNs on each line, this is so I can reuse that list over again in other scripts, but also so I don’t need to initiate a change on all my scripts to add or remove vcenters from the list. In Lines 154-158, I set up an array of VM creation type events. Note the remark, that if there’s an event type you don’t particularly care about, let’s say vAPP deploy, or registering a pre-existing VM, you can remark out or remove that line. And finally I set up a constant for readability of  a carriage return and line feed to keep the note nicely formatted.

Lines 161-171: In this section, I convert some of the run-time parameters above into actionable variables. Most notable are creating the credential object that will be used to log into each vCenter, and converting and gathering the dates from which the viEvents will be retrieved.

Lines 172-194: This is where the bulk of the action happens. The script loops through the vCenters, logs on, finds any events related to the creation of a VM. If it doesn’t find any it moves on. If it does find some, then it loops through those events, runs a Get-View for the VM related to it and gets the Name and Config properties. If the VM is still there (I have found create and deletes in the same day, Voila!, it creates a new note and applies it the the VM. Disconnect and move on or we’re done.