VMTN Blog

When I tell you to stay glued to your computer, I mean it. Carter Shanklin announces the beta release of the PowerShell-based VI Toolkit (for Windows). Link: We Are Beta.

I won't speculate on whether PowerShell fanatics are more or less likely to be sitting in front of their computers on a Friday night like I am, but regardless of when you read this post, if you use VMware ESX or VMware VirtualCenter, you should download our VI Toolkit (for Windows) Beta and give it a try.

Some of the cool things you might want to try for yourself:

• Snapshot all of your virtual machines at once with a script like:   

  Get-VM | % { New-Snapshot -VM $_ -Name ($_.name + "-current") }

• Automate long-running tasks like cloning using a script like:   

  foreach ($i in 1..30) { Get-Template "My Template" |      New-VM -Name "Clone $i" }

• Disconnect connected CD-ROM drives (to enable VMware VMotion, for example) using a script like:   

  Get-VM | Get-CDDrive |                                              ? { $_.ConnectionState.Connected -eq "true" } |      Set-CDDrive -Connected:$false -Confirm:$false

Well, once Carter spilled the beans, everybody is now waiting with bated breath for VMware to release the beta of our new curiously-named VI Toolkit (for Windows). The toolkit is powered by Windows PowerShell, a shell/scripting technology that Microsoft appears to have gotten very right indeed. The VI SDK, while extremely powerful, is not for the faint of heart. This toolkit takes that power and wraps it up in a very simple syntax which creates a compelling tool for VI admins.

I'm a Perl guy from way back, and I have to say seeing PowerShell scripts, er, cmdlets do all sorts of tricks with my VMs without breaking a sweat makes me grin like a maniac. This is going to be a real boon to VI admins.

Here's an example from the VMworld hands-on lab manual Automating VMware with PowerShell Lab Manual. How can you not like this? You don't even need a manual to understand what it does.

get-vm | get-snapshot | where { `
  $_.Created -lt (get-date).addmonths(-1) `
}

Here's a round-up of the blog reactions so far.

Dave Marshall played with it at VMworld. Link: VMware administrators find value in Microsoft PowerShell

I in fact also attended the lab during the show and found it quite interesting and compelling. For me, this was the first time I had actually used the PowerShell cmdlets to operate and manage a VMware environment. I spoke with VMware's Product Manager of API & SDK, Carter Shanklin at length. Like the people being exposed to PowerShell for the first time, Shanklin seemed very energetic about the possibilities that this scripting feature brings to VMware environments.

Eric Sloof has been working with the toolkit for a while and posting his progress. Link: VMware PowerShell - NTPRO.NL. Here are some of his posts:

• The VI3 Windows Toolkit and .net integration
• Create multiple VM’s using PowerShell
• PowerShell Snapshot Remover
• Pipe VMware PowerShell into PowerGadgets

Hal is looking for good nuts to crack with our new nutcracker. Link: Call for Script Ideas: VMware PowerShell Toolkit.

Calling all ESX admins!  I am looking for novel ideas for scripts to write for the upcoming VMware Toolkit for Windows PowerShell.  Yes–I am offering to do the writing.  I am doing research for a project (details of which to be announced in the coming weeks), and I could use some really great ideas of missing functionality or fixes to problems you have seen while working with VMware Virtual Infrastructure 3.  Pointers to something cool you have seen done with the VMware Perl Toolkit are good too.  It’ll be amusing to see how much simpler those will be in PowerShell. 

Hal and Andrew Kutz are also having a great discussion about relative complexity and our Perl vs PowerShell toolkits here: TechProsaic - VMware Perl Toolkit versus PowerShell VI Toolkit. I don't think either one really is saying my scripting language is better than yours, but more that the VMware team has done a great job of providing the right level of interface for what admins need to do. Jeffrey Snover actually puts it best on the Windows PowerShell team blog. Link: Windows PowerShell : The Semantic Gap.

Someone could read this blog and walk away thinking, "PowerShell is great and Perl is crap" - you'd be both right and wrong.  PowerShell is great but Perl is not crap.  (Hats off to superstar Larry Wall and Perl, very few people and technologies that have had the level of (positive :-) ) impact these 2 have had on the industry.  The world is a better place because that guy was born!)   The difference between the 2 examples is the semantic gap.  The PowerShell example has a very small gap between what you think and what you type. The Perl example has a very large gap.

At the end of the day, the semantic gap is "owned" by the people that provide the instrumentation.   VMWare could have just as easily provided a PowerShell Script that took just as many lines as the Perl example or they could have provide a Perl library or script which provides the semantics of the Get-VM cmdlet.

The good folks at SAPIEN Technologies have a new VI Toolkit (for Windows) book coming out. Link: Coming Soon: Managing VMWare with Windows PowerShell

We’ve a new book in the works: Managing VMWare with Windows PowerShell: TFM. Read about it at http://www.sapienpress.com/vmware.asp, where you can also read about the author and (once we have them available) download preview chapters. We’ll be looking for community reviewers before long, so if you’re an ESX Server user, stay tuned to this blog for your chance to participate and earn some cash!

Dave Stein wins the award for the best title so far: Oh No They Didn't!  VMware Getting all Uppity with Mac Daddy PowerShell

I have no doubt you or your RSS reader should stay glued to the VI PowerShell and Developer Center blogs -- the VI Toolkit (for Windows) beta is coming your way soon.

Link: Leveraging the VI3 SDK with .NET, part one - Understanding the VI3 SDK.

The preferred mechanism for programmatically interacting with VI3 is the SDK, not the commands available in the ESX COS [system console -jt] (such as the suite of commands prefixed with "esxcfg" found in /usr/sbin). The SDK is very powerful, and its power can be harnessed with another equally powerful tool, .NET. In this article, I will describe the beginning steps you must take as you start down the path toward leveraging the VI3 SDK with .NET using C#.

Part Two: "In this article, I demonstrated how to query the VI3 SDK for information, such as the available hosts." (Free Registration Required -- make sure you go back to your profile and confirm your spam subscriptions are set as desired.)

Part Three: Exploring the SDK

vish project: "The Virtual Interface Shell (vish) project is a command-line interface for managing VMware's Virtual Infrastructure 3 (VI3). Written in C#, this interactive shell can be used in Windows or Linux or OS X with Mono."

[via VMblog]

Richard Garsthagen has been burning the midnight oil to hook the VI3 SDK to Visual Basic using web services:

Well I am finding out more and more that the VirtualCenter client is by far not using all the actual functionality of the VI3 product. One of the things the SDK does expose is for every physical server what kind of CPU it has and what features are available. You can even compare if one physical server might have different cpus. So, yes I could write a very easy application in Perl (using the perl toolkit) that shows you all the servers and their cpu features, high light the differences and asking you if you want to set a specific cpu feature mask for a group of selected virtual machines. All automated. Writing that application should take me about one hour. But then all you people need to be able to run that application, meaning you need to have perl installed, add some extra needed modules to perl, download the VI perl toolkit, compile the toolkit and run my small perl app.  ...

til now!!!!!!!!!!!!!!!!!!!!!!!!!

Yippie, I can not express how happy I am. For 3 nights in a row I have been limiting my sleeping time on trying this challange. But I have done it. I have a working VB application running, where I actually understand the source code and wrote every single line of it myself, I have no slow delay problems (as many other people have using the WSDL file). WOW! Why did no one do this before??

Update: If you're a Perl monger, Richard has also written about the VI3 Perl Toolkit as well.