I recently got a comment on a post I had done a while back on VMware tools and Time Sync. While the one-liners there may be useful, they don’t particularly explain how they got to the end results. With that in mind, today I hope to explain some of the logic used when you need to find particular properties of an object. To that end we’ll use the example proposed on the post:
Can you tell me how can I find out the poweroff Vm and also when it is poweroff and by whom with powershell script.
I know how to get the poweroff vm, but not able to get the other details.
If possible can you put your comments on this.
Power Off tasks for a VM. Well, where do we normally find those in the vSphere client?
Turns out it’s listed under Tasks & Events for that VM:
This gives us an idea about the information we’re looking for, as well as provides us a place to start looking. Let’s dip into the PowerCLI:
[vSphere PowerCLI] C:\> $vm = Get-VM | where { $_.Name -eq "Wiki" }
What this does is set the variable $vm to the object that represents our VM. What is an object? For our use an object is anything in your Virtual Infrastructure, and the properties and methods that belong to it. Take a turtle for example (yes… turtle, hang with me). That turtle will have some properties: breed, gender, length, weight, etc. For a VM these properties are quite numerous:
[vSphere PowerCLI] C:\> $vm | fl *
PowerState : PoweredOff
Description :
Guest : VMware.VimAutomation.Client20.VMGuestImpl
NumCpu : 1
MemoryMB : 256
CDDrives : {CD/DVD Drive 1}
FloppyDrives : {Floppy drive 1}
HardDisks : {Hard disk 1}
NetworkAdapters : {Network adapter 1}
Host : 192.168.15.253
HostId : HostSystem-host-26
HARestartPriority :
HAIsolationResponse :
DrsAutomationLevel :
CustomFields : {}
Id : VirtualMachine-vm-47
Name : wiki
What we did there was take our $vm object, and expand out a list (using short hand for Format-List) of all properties (using * ). Quite a few properties, no? None are exactly what we need, however, so lets dig a bit deeper. As the information we’re looking for is an Event, we need to pipe, or pass our $vm object to the Get-VIEvent cmdlet:
[vSphere PowerCLI] C:\> $vm | Get-VIEvent | select -First 1 | fl *
info : VimApi.TaskInfo
key : 2177
chainId : 2177
createdTime : 10/12/2009 10:09:35 AM
userName : NERV\cody.bunch
datacenter : VimApi.DatacenterEventArgument
computeResource : VimApi.ComputeResourceEventArgument
host : VimApi.HostEventArgument
vm : VimApi.VmEventArgument
fullFormattedMessage : Task: Power Off virtual machine
dynamicType :
dynamicProperty :
Ok, this particular bit of output is doctored. Why? The list of events for a give VM is huge, and this provides us with the information we’re looking for 🙂
Looking at the output we see that there are several properties of interest here, the time the VM was powered down, the user who initiated the task, and of course the message notification. Let’s put these all together to answer the original question:
[vSphere PowerCLI] C:\> $vm | Get-VIEvent | where { $_.fullFormattedMessage -like "Task: Power off*" } | select createdTime, userName, fullFormattedMessage
createdTime userName fullFormattedMessage
———– ——– ——————–
10/12/2009 10:09:35 AM NERV\cody.bunch Task: Power Off virtua…
Hope this was helpful. If you’ve any questions or comments, drop a line in the comments section.
I should add the user to my PowerWF tutorial that monitors when a VM was powered on or off (http://blog.powerwf.com/post/221107418/tutorial…)
Would be interesting to see. 🙂
I should add the user to my PowerWF tutorial that monitors when a VM was powered on or off (http://blog.powerwf.com/post/221107418/tutorial…)
Would be interesting to see. 🙂
this is exactly what i have been looking for! Is there is a ready script for this?
As a one-liner it should give you some flexibility, but I suppose it could
be rolled into it's own script.
-C
I was trying to use this to find out who powered ON my VM. For some reason, it’s not showing the users all the time.
Do all the events have users? At times there will be HA or other events which may not register with a user. Also, if the hypervisors are being managed directly and the VM is powered on in that fashion, vCenter may not catch it.
Interesting. Have you confirmed against the vCenter to see if all of these actions had a user attached?