I got an interesting question from one of my co-authors of the PowerCLI Reference book. He was looking for a method to find the port used by a VM when connected to a portgroup on a dvSwitch.
Finding the answer to that question is not too difficult, once you know which property holds the value. But while writing and testing the script, I thought that this question would be a good opportunity to show several ways and methods that you have at your disposal in PowerCLI and PowerShell, to come to a solution.
Here it goes.
The VMTN Communities have always been a useful source of inspiration for writing scripts. This week, for example, there was an intriguing question raised in the Onyx Community. The user wanted to know if it was possible to monitor changes in the vSphere environment in real time.
As far as I know there is no API in the vSphere SDK to do real time monitoring. But the EventHistoryCollector can deliver something that I prefer to call nearly real time monitoring. The following script is a very basic function, written primarily to show that this principle of nearly real time monitoring works. The function displays some selected properties of each event it sees.
Triggered by a recent post, see get-virtualportgroup, in the PowerCLI Community, I had a closer look at the Get-VirtualPortgroup cmdlet.
This cmdlet returns a VMware.VimAutomation.Types.Host.VirtualPortGroup object, which contains a very useful property called Ports. In that property it lists all the guests that are connected to a port on the portgroup. That would be the solution to find unused portgroups, I thought. But while the vSphere Client also shows powered off guests that are connected, the Port property returned by the Get-VirtualPortgroup cmdlet doesn’t.
So the question at hand required a bit more scripting than I originally thought.
Steve Jin, author of the VMware VI and vSphere SDK: Managing the VMware Infrastructure and vSphere book, recently started his DoubleCloud blog. In a short time span he produced several high quality posts which should be a must-read for every SDK user.
In his latest post, Top 10 Best Practices Using VMware VI and vSphere SDK (part 1), Steve gives invaluable advice for working with the SDK.
Since most of the SDK samples are (still) in Java, and since I know there are quite a few SDK users coming from the PowerCLI world, I decided to write up on some of Steve’s best practices for PowerCLI users.
And I hope Steve doesn’t mind
Update: I thought it would make it easier for the reader to group all the SDK best practices and tips & tricks together. So I created a dedicated page, see SDK.
Yesterday, Cody published on his Professional VMware blog an excellent article, called vSphere Host Died Abandon Ship! – vSphere vCenter Alarms & Actions.
The article shows a very elegant solution how to move your guests to “safer havens”, the moment one of the hosts in the cluster starts experiencing hardware problems.
The elegance of Cody’s solution is that he uses maintenance mode to force vMotion on all the powered-on guests on the host that experiences HW problems.
When I publish scripts that use SDK properties or methods, one of the questions that comes back regularly is “Where do you find what to use ?“.
Let me assure you, there are no tricks, optical illusions or black magic involved. I’m simply using the numerous resources that are made available in the VMware Developer community.
Diving into the SDK is like making a big trip, you have to start prepared !
When you try to migrate a guest, that is using one or more RDM disks, you might see this message.
The reason this is most probably because the LUN IDs are different on the source and the destination ESX server.
One solution is:
- stop the guest
- write down the Physical LUN ID
- remove the RDM disk(s)
- vMotion the guest
- add the RDM disk(s) to the guest based on the Physical LUN ID
- start the guest
But why do this the hard (manual) way when we have PowerCLI ?
During my Dutch VMUG event 2009 presentation there was a technical problem with some of the demo videos I prepared. Luckily an audience member came to the rescue by downloading the excellent VLC Video Player via his cell phone. Thanks again for the assistance
To make up for this technical mishap, the demo videos with a short explanation.