In a previous post, called Events, Dear Boy, Events – Part 2, I mentioned that some tools/add-ons use a special event type called ExtendedEvent. Two classic examples are the Converter and the Update Manager. If you want to compile a report for any these tools it’s important to understand what is available in the extended events they produce.
If you want to know if there are any other tools/add-ons in your vSphere environment that produce extended events, then you can use the first script from the Events, Dear Boy, Events – Part 2 post to get a complete list of all available extended events.
In this post I’ll show how to use the Converter extended events.
Converter import report
If we look at the ExtendedEvent object we notice that it adds three extra properties to the basic event object, called GeneralEvent.
The eventTypeId property corresponds with the text in the Description column of the CSV file produced by the first script in the Events, Dear Boy, Events – Part 2 post.
That makes it an ideal property to filter out the results we want.
The following script for example will extract all the events that are produced by the Converter.
|
1 2 3 |
Get-VIEvent -Start (Get-Date).adddays(-1) | ` where {$_.EventTypeId -like "com.vmware.converter*"} | ` select createdTime, eventTypeId | Sort-Object -Property createdTime |
When you run this script you’ll see something like this
The events marked in yellow represent all the events the Converter generated for one import of a virtual machine. And when we verify from the vSphere Client, these events corresponds with events associated with the Import task.
Now unfortunately none of these events seem to tell us anything about the imported machine, no MoRef, no Name 🙁
But with a bit of fiddling around we can still get this information for our Converter Import report. For that we use the VmBeingCreatedEvent object.
If we investigate the events a bit further we see that the Converter Import task produces an event called CreateTargetVm. At that point the Converter asks the vCenter to create a new guest into which it will later import the guest. This creation of a new guest produces some events of it’s own. We will capture the start of that task by filtering the VmBeingCreatedEvent.
The script
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$secondsDifference = 30 $events = Get-VIEvent -Start (Get-Date).AddDays(-1) | ` where {$_.EventTypeId -eq "com.vmware.converter.CreateTargetVm" -or $_.GetType().Name -eq "VmBeingCreatedEvent"} $events | where {$_.EventTypeId -eq "com.vmware.converter.CreateTargetVm"} | %{ $cvtEvent = $_ New-Object PSObject -Property @{ Date = $_.CreatedTime User = $_.UserName Host = $_.Host.Name VM = ($events | where {$_.GetType().Name -eq "VmBeingCreatedEvent" ` -and $cvtEvent.Host.Name -eq $_.Host.Name ` -and $cvtEvent.UserName -eq $_.UserName ` -and [math]::Abs($cvtEvent.CreatedTime.Subtract($_.CreatedTime).TotalSeconds) -lt $secondsDifference}).Vm.Name } } | Export-Csv "C:\Converter-Imports.csv" -NoTypeInformation -UseCulture |
Annotations
Line 1: This is the time difference that is acceptable between the com.vmware.converter.CreateTargetVm event and the VmBeingCreatedEvent events. If your environment is heavily loaded it’s possible that you have to increase this number.
Line 2: The script looks at all the events one day back.
Line 3: We filter out only the 2 event types we’re going to use for the report.
Line 4: We loop through all the Converter events
Line 10-13: To make sure we catch the correct VmBeingCreatedEvent event we perform three tests; the host should be the same, the username should be the same and the time difference between the two events shouldn’t be more than $secondsDifference seconds. Note that the script calls the Abs function, because I noticed that the time difference sometimes produces a negative value.
Sample output
The script produces a CSV file that looks like this.
As you can see, we now have the name of the VM in the Converter Import report.