One of the announcements during VMworld 2010 in San Francisco that perhaps got a bit obscured by the other “big” announcements, was the release of Onyx 2.0. For those of you that hadn’t heard of Project Onyx before, this nifty little tool captures all SOAP traffic that is passed between your vSphere client or PowerCLI session and the vCenter or ESX(i) server to which you are connected.
And that’s not all, the Onyx program will translate the captured SOAP traffic into PowerShell code. This allows you to see which vSphere APIs are used and how parameter objects for these methods are constructed.
One of the new features that came with vSphere 4.1 was the ability to use Active Directory Authentication on ESX(i) servers for permissions, console access and ssh access.This is a great feature that you will probably want to activate on all your ESX(i) servers.
Unfortunately this new feature is not available in PowerCLI 4.1. That means you can’t set this up in your configuration scripts through a PowerCLI cmdlet. In most such cases you can fall back on one of the SDK APIs to bypass this lack of a cmdlet. But unfortunately the new “managers”, of which HostActiveDirectoryAuthentication is one, are not available in the VMware.Vim assembly either.
Rob raised this in a recent PowerCLI Community thread. Yasen, one of the PowerCLI Dev Team members, provided a bypass. To make this bypass a bit more accessible, I decided to roll it up in a PowerShell function.
Read more…
The New-Datastore cmdlet allows you to easily create VMFS datastores on a free LUN or local disk. But what if you want to create a VMFS datastore on that free partition you have left on a LUN or on a local disk ? These free GBs could come in handy and it’s a shame letting them go to waste. Unfortunately, the New-Datastore cmdlet doesn’t have an option (yet) to handle “free space” partitions.
Exactly such a question was raised by Alasdair in his thread new-datastore on ESX4i Installable local disk in the PowerCLI Community recently.
Read more…
Another idea triggered by a post in the PowerCLI Community. Lars wanted to know where his VMs had been running in the past.
Since vSphere doesn’t maintain any historical data with the guests themselves, we have to fall back on the Tasks and Events to create such a report. The basic algorithm to query the tasks, and their related events, is already published in Events – Part 3 : Auditing VM device changes. But to get a historical record of the servers where your guests have been hosted requires a bit more logic in the script.
I received an interesting comment on my Events – Part 7 : Working with extended events – Update Manager post from Suresh. He wanted to know if it was possible to create a similar report with the vCenter Update Manager PowerCLI cmdlets as you can get with the esxupdate query command.
Read more…
As I already mentioned in my previous post, Events – Part 6 : Working with extended events – Converter, another
add-on that produces extended events, is the Update Manager.
With the recent introduction of the vCenter Update Manager PowerCLI snapin, it is now fairly easy to automate all aspects of patch and update management in your vSphere environment. And with the help of the extended events produced by Update Manager, you can easily produce reports. This post shows one way of doing this.
Read more…
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.
Read more…
Michael asked if it was possible to produce a report that showed the NX/XD flag setting for all the guests.
Piece of cake I thought, but it turned out to be a bit more complex than that. If you don’t set the NX/XD flag (expose or hide) explicitly on the guest, the hyper-visor will use a default that is defined per OS you can have on the guest.
In the end I think I came up with a script that seems to handle all the different possibilities I encountered.
Read more…
Today Steve Jin published a post called How to Enable ESX Server Logs for Troubleshooting. A very useful tip when you are looking for those hard-to-find “features” in your script.
Steve’s tip reminded me that I have a similar small function in my toolchest to do something similar for the vCenter log.
The function allows you to switch the vCenter log between “warning” and “verbose” on the fly. No need to go into the vCenter client to change the logging option anymore while debugging.
Read more…
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.
Read more…