Get-VMotion for vSphere 6.5

by brianbunke on October 25, 2017 under blog

5 minute read

After following the #migrate2vcsa path, trading a 6.0 Windows vCenter server for the 6.5 vCenter Server Appliance, I (eventually) noticed my trusty Get-VMotion command was missing a lot of vMotion events.

tl;dr - I’ve updated Get-VMotion to version 1.1!

Now returns a new event type for 6.5’s encrypted vMotions
- com.vmware.vc.vm.VmHotMigratingWithEncryptionEvent
Fixed a filtering bug I encountered after the 6.0 > 6.5 upgrade
Start/End times are now converted to your local time zone (instead of UTC)
SrcDC & DstDC properties added, for those of you getting fancy with your vMotions

Get-VMotion is available on the PowerShell Gallery, the VMware {code} Sample Exchange, and GitHub.

# Grabbing the script is easy with PowerShellGet (the PS Gallery module):
Save-Script Get-VMotion -Path $env:USERPROFILE\Desktop

See also my original blog post: Get-VMotion

…and lots of details

If you just want the script, that’s cool, you can stop here. No judging. :) I found some interesting things while troubleshooting this update, though, that I think are worth documenting. Hopefully, if you end up reading this, you have some knowledge that can help straighten me out!

Again, all of the below findings relate to my experience transitioning a vCenter server from Windows 6.0 to VCSA 6.5.

1) All results filtered out

At first, Get-VMotion wasn’t returning anything for me.

Get-VMotion builds an EventFilterSpec to query the SOAP API for recent events in your vCenter. When I dove into debugging the command, I found that removing this line began returning results:

# I had to remove this for 6.5
$EventFilter.Category = 'Info'

I wanted to filter by category, because that reduces the result set that needs to be parsed. It doesn’t work anymore…but why?

After a Google search for vmware eventfilterspec brought only very outdated results, I tried the new docs.vmware.com site, but found that the EventFilterSpec page there only had versions 5.1, 5.5, and 6.0. (This is the link for 6.0…which is virtually guaranteed to break, because a more shareable URL is not available.)

I eventually conceded the following:

I’m not sure what changed in 6.5 to apparently break this
I’m not sure what other strings I could supply into category to test other filtering
It works with no category filter, so I guess it’s staying that way

2) Not all vMotions are returned

I thought I was good to go for about a day, until I realized that I definitely wasn’t seeing every vMotion that had occurred. Roughly half of all vMotions were not being returned.

Another deep dive into PowerShell debugging later, I found that removing my filter on event type did expose those missing vMotion events. With some additional trial and error, I noticed a new event type on the missing vMotions: “com.vmware.vc.vm.VmHotMigratingWithEncryptionEvent”.

Now, my EventFilterSpec needed to be updated with the new type:

$EventFilter.EventTypeID = @(
    'com.vmware.vc.vm.VmHotMigratingWithEncryptionEvent',
    'DrsVmMigratedEvent',
    'VmBeingHotMigratedEvent',
    'VmBeingMigratedEvent',
    'VmMigratedEvent'
)

This worked, but it begged the question: What other event types am I missing? Which, unfortunately, led me to the end of the Internet.

I still have no idea if there are other relevant event types. Since my environment wasn’t generating anything else, I rolled with just adding the single entry and calling it good.

3) The new type doesn’t return all properties

With all vMotion events finally being returned, I found that some were not populating the destination properties (host, datastore, datacenter). This boiled down to the new event type moving them beneath an Arguments property.

# Return the destination host from a vMotion event
# EventType: DrsVmMigratedEvent|VmBeingHotMigratedEvent|VmBeingMigratedEvent|VmMigratedEvent
$Event.DestHost.Name
# EventType: com.vmware.vc.vm.VmHotMigratingWithEncryptionEvent
($Event.Arguments | Where {$_.Key -eq 'destHost'}).Value

NOTE: While Arguments looks like a normal hashtable, it is instead a disappointing PowerCLI custom object that makes you really work for it.

4) Localizing the times

This has nothing to do with VMware, but I learned something new in PowerShell during this process.

VMware’s SOAP API inputs/outputs times in UTC, which is fine. However, I didn’t know it was so easy to convert universal time back to your local timezone…but [DateTime] .NET objects have a method for that.