Events – Part 4 : Who started that VM ?

In a comment on my Events – Part 3 : Auditing VM device changes post, Ian asked if it was possible to report who started a VM.

To take away the suspense, yes that can be done by using the information from two of my earlier post.


Since I considered it a bit too long to give the solution in a comment, this post.


First you will have to find which event(s) to use for a power on of a guest. For that use the CSV file of all events that I blogged about in Events, Dear Boy, Events – Part 2.

It’s obvious that you will need the VmPoweredOnEvent.

The first script in Events: a great source of information – Part 1 shows how to get at the user information in the event object via the userName property.

The scripts

First the script with only PowerCLI cmdlets.
Turns out we can do this with a one-liner !


Line 1: The Where-Object (alias ‘where’) cmdlet only passes the events we’re interested in

The second version of the script uses the event collector methods as described in Events: a great source of information – Part 1 (second script in that post).


Line 9-13: VIM 4.0 has a limitation in the number of events.
Line 26-31: this way of building an object is new to PowerShell v2
Line 37: you can have a maximum of 32 event collectors in your session. So clean up !


Both scripts produce a CSV file that gives all the information we’re after. See the first screenshot in this post.
The difference is in the execution time, the 2nd script ran nearly 35 times faster than the first script in my test environment. Quite important if you have to go back far in time or if you are auditing a big environment !

You can use any of the above scripts as skeletons to hunt for other audit information. Just plug in the event(s) you’re after 😉

A personal reflection, it would be useful that in a future PowerCLI build, the Get-VIEvent cmdlet would have a ‘filter‘ parameter. That would get rid of the Where-Object cmdlet through which we now have to pipe all the events.



    Hi, Thank you.
    Is there a way that we can monitor VM information in depth? We are reaching our hardware limit and I need to free up some VMs. I know that some people are not using their VM anymore, how can I tell when the last time a VM was interactively logged into so I can produce the report if they really need an Idle VM?



      The start/stop of a VM does only tell you when the VM was running or not.
      To actually see if someone logged on you would have to interpolate the Guest OS.

      You could look at performance metrics like CPU, memory and disk IO, but that is not an absolute indication if someone is actually working in the Guest OS.
      It could be that for example scheduled tasks are causing these fluctuations in those metrics.

      The only true method is to iterpolate the Guest OS I’m afraid.


    Hi LucD

    Is there a way for me to access the configSpec property for a CloneVM_Task. I think its the VirtualMachineCloneSpec that I’m looking for, but I only see it being used as a parameter when calling the CloneVM_Task.

    I’m unsure whether I can access task parameters via the TaskManager/eventManager.
    My aim is to identify the configuration for CPU & memory for the target machine.



      @Luveshen, see my reply in Events – Part 3 : Auditing VM device changes


    Thanks much, Luc!


    Hi Luc,
    Is it possible to monitor manual migration event and have username (who), starttime, state, vm name, from, to displayed? I saw a script from you, which tracks DRS. Thanks again!


      That shouldn’t be too difficult.
      If you replace the code inside the switch statement (lines 25-32) by the following code, you should get a report on the vMotions.

      $report += New-Object PSObject -Property @{
      VMname = $event.Vm.Name
      CreatedTime = $event.CreatedTimE
      From = $event.SourceHost.Name
      To = $event.Host.Name
      User = $event.UserName
      State = $event.FullFormattedMessage

      I suspect that you can test on the presence of the User property to determine if it was a manual vMotion or one triggered by the system (DRS).

    Cody Bunch

    Good stuff! I did a similar post a bit back: Love the performance improvements tho… 35x is HUGE!


      That is indeed a great post you did Cody.
      Wouldn’t have done this one, if it wasn’t for the performance difference between the two methods.

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.