VMTN Blog

Here's a new post from our Developer Center Blog. Welcome, Steve, to the virtualization blogosphere! Check out the Developer Center and Developer Community if you haven't for a while. A lot of solid resources for you. Link: VMware Communities: Developer Center Blog: Announcing client side Java APIs (experimental) and samples for VI SDK.

This is Steve from VMware CoDevelopment Engineering. I would like to share with you the client side Java APIs and some samples I have developed recently.

This API package:

• Enables OO programming with a well defined managed object model
• Reduces the need to use ManagedObjectReference
• Hides the complexity of the PropertyCollector
• Provides necessary utility classes to simplify VI SDK web interfaces
• Keeps it small and simple
• Leverages current VI SDK web services interface while keeping it intact

VMware has released an official guide to writing VC plugins: see VMware Infrastructure (VI) SDK 2.5. Note:Support for VI Client Plug-ins is Experimental, and is subject to change in future releases.

VI Client Plug-ins

With the release of VirtualCenter 2.5, VMware offers third-party developers and partners the ability to extend the VMware Infrastructure Client (VI Client) with their own product-specific menu selections or toolbar icons that provide access to external, Web-based functionality. These extensions, or VI Client Plug-ins, comprise the set of configuration files, URLs, icons, and Web-server-hosted resources that work together to display extended menu items, icons, and other user interface (UI) items in the VI Client and provide access to the external functionality.

Stu @ vinternals likes it. Link: vinternals: First Official VI Client Plug-in Document Released - round of applause for VC architects / devs!.

Outstanding! On the coding side, it looks so straight forward that even a hacker like me should be able to put something together fairly easily... running off the example in the document, you could pretty easily add a context menu item to ESX hosts that fires up the out of band management web interface (ie the iLO page for HP kit) of that particular host.

In related news, Schley Andrew Kutz, who managed to reverse engineer the plugin SDK before this, is writing a book for O'Reilly. He's asking for feedback and/or code samples at VMware Communities. Link: VMware Communities: Announcing "Programming and Managing ....

This book will be the definitive guide for systems administrators and developers eager to make use of the VI and CIM SDKs. The book shows their use with several popular languages, including the VI Perl Toolkit and VI Toolkit (for Windows) as well as C#, Java, and Python. Advanced topics, such as creating client plugins and communicating with VMware through its web service, are also covered.

This text demystifies the VI SDK, transforming the difficult task of searching the VI inventory into a simple one.

Hat tip to Pablo, Scott, David, and Eric for bringing me the news.

Link: VMware Communities: Developer Center Blog: Announcing the latest VMware SDK: The VMware Virtual Disk Development Kit (VDDK).

Pablo: You must be excited about releasing the VMware Virtual Disk Development Kit, can you tell us why our developers should be interested in it?
Hari: Yes. With VMware Virtual Disk Development Kit we are enabling a new eco-system of partners to develop solutions that integrate with VMware virtual disk. The VDDK is an open SDK that developers can use to build cutting edge applications for creating and accessing VMware virtual disk storage.

Pablo: What are some of the use cases for using the VMware Virtual Disk Development Kit?
Hari:  Virtual Disk Development Kit provides easy access to VMware virtual disk storage.

This enables a wide range of use-cases for application vendors including:

• Creation of virtual machine disk files to store backup of physical images
• 
  Read access to virtual disk to enable off-line centralized scanning of virtual machines for anti-virus
• 
  Write access to virtual disk to enable off-line centralized patching of virtual machines Read access to virtual disk to enable off-line software package analysis of virtual machines

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.