Update: LucD has created a detailed cheatsheet with the changes. You can find it on the VMware Communities document library.
The VMware Toolkit (for Windows) was officially released last night. I’m very excited by this for several reasons. For one, I no longer have to “backport” my public code samples to make them compatible with the then-current beta. Two, when I find bugs I can actually converse about them on the VITK forum, rather than having to privately report them in email to a guy who is already busy enough that he doesn’t need me adding to his workload. And three, this stuff is just cool, I’m glad that everyone can play with it now!
I wanted to write a quick post to highlight some of the more obvious changes between the public beta and the 1.0 build 103777.
- This change was mentioned by Carter on the VI PowerShell blog: the cmdlet used to connect to your virtual infrastructure servers has been renamed from Get-VIServer to Connect-VIServer.
- This one is really neat—the sessions are now kept alive just as you see with the graphical VI Client. This means no more running a script only to have it die because your session had timed out.
- The Get-View cmdlet is used when you have an instance of one of the .NET automation objects (type names begin with VMware.VimAutomation.Client20), and you want to use that to retrieve the managed object reference. Prior to release, this cmdlet could only pull up a managed object (the server-side stuff) by the ID property of an automation object. They have since enhanced it so that all you have to do is pass an automation object to Get-View on the pipeline and it just figures it out. Gotta love the pipeline! Here’s a before and after:
Before:
$vmview = Get-VM | foreach-object { Get-View $_.ID }
After:
$vmview = Get-VM | Get-View
If you have any questions, be sure to hang out in the VITK forum or in #PowerShell or #VMware on irc.freenode.net. Lots of nice smart people are ready to answer your calls!
I saw the thread you started on VMware Communities about get-view… Holy crap they listened! The fact that they fixed get-view to work in the pipeline just made it infinitely more useful. Especially since, until vmware finishes building up there cmdlet base, Get-View is our only window into some of VI more hidden configuration items.
Does the change in Connect-VIServer mean that a powershell session will maintain the same persistent state as VIC? If so what about scripts? I know that get-VIServer was scoped because it stored all the connection information in $defaultVIServer (not at work going off mem). Therefor, before, when connecting in a function that connection was not available to you once you left that function.
If I’m reading everything correctly looks like it’s time to start treating VI like AD or SQL Connect-> do stuff -> Disconnect.
They did make changes to cvi (the alias I made for it) so that it now keeps your connection alive just like VIC.
To my knowledge, their plans did not work out 100% with regards to $defaultVIServer. One thing I don’t like is that after you use disconnect-viserver, the $defaultVIServer variable still contains a value. They should have nulled it. If you use a function (named disconnect-viserver) to fix this up, then you can use the presence or absence of that variable to determine if there is a connection. Sorta. You can have multiple connections active at once, so that gets confusing.
I was never able to enforce scope on the variable, I don’t know if that was a bug or by design. It _always_ seemed to be privately scoped, even if you $global’d it.