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.
In a recent post on the vSphere PowerCLI Blog, called New Nested Properties for Navigating to Parent Objects in PowerCLI 4.1, some new features were introduced.
In PowerCLI 4.1 some objects now have, besides the ParentId property, the actual parent object itself. This will take quite some complexity out of several scripts. This is definitely a good improvement.
The 2nd novelty in that post were nested properties. Some SDK object properties are now mapped directly in the PowerCLI object. For example the VMHost object now holds the StorageInfo and NetworkInfo properties besides some others. And what is even better, there is hardly any performance impact since the values will only be loaded the first time you access the properties (similar to the ExtensionData property).
Read more…
As we announced in our post “We’re writing a book!“, Alan and myself started writing a PowerCLI book.
At about the same time Alan got the once-in-a-lifetime oppurtunity to join EMC as a vSpecialist.
Now you don’t become a vSpecialist for free! Alan has been spending a fair amount of time in training, coming up to speed with VCE (VMware/Cisco/EMC) and traveling all over the globe. The little time he was at home, went of course in the first place to his loved ones.
As a consequence, our chapter-writing schedule failed misserably.
So we decided to get some extra help for the book in order to keep our deadline.
And now, for the proverbial “silver lining”, have a look who agreed to help us out:
| Glenn Sizemore |
Jonathan Medd |
Arnim van Lieshout |
|
Winner of the
Scripting Games 2010
vExpert
|
PowerShell MVP
|
vExpert
|
|
|
 |
 |
In other words, the book will now be written by “4 vExperts and a MVP” !
Can’t wait to read it 
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…
In the new PowerCLI 4.1 build 264274 there are two new cmdlets, called New-VIProperty and Remove-VIProperty, that deserve your special attention.
The New-VIProperty cmdlet allows you to add a new properties to any PowerCLI object (InventoryItem, HostSystem, VirtualMachine…). And it’s up to you to define what the value of this new property will !
The Remove-VIProperty cmdlet allows you to remove such a new property.
These new cmdlets, combined with the new Extension property, will change several of the well established ways that you use in your PowerCLI scripts. And besides adding a lot of flexibility, the extension property will make your scripts considerably faster (if used wisely).
Read more…
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…
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…
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…
There was another interesting question on the PowerCLI community. Mike was wondering if it would be possible to change the VMware Tools scripts with a PowerCLI script. As far as I can see there are two options available with the VMware Tools scripts.
- You can run the default scripts that are installed on the guests when you install VMware Tools
- You can use Custom scripts and you have to specify the path of these scripts to VMware Tools
To use the 2nd option you will need, as William already pointed out, the VIX APIs.
But if you can live with the first option, and reuse the default scripts, the current PowerCLI build has all you need.
Read more…
Some of you might be interested to know, Alan and Luc are writing a PowerCLI book.
We don’t have many more details at the moment but wanted to let you know, as we are both very excited (and nervous by the amount of work) about this project.
As you know we both live and breathe PowerCLI. And we want to share our knowledge to help others achieve the level of PowerCLI automation we both know is possible.
One thing you can expect from this book is a practical approach with examples galore. We aim to cover most of the common configuration/troubleshooting and reporting areas with easy to understand examples and explanations.
Read more…