I can honestly say that I capitalized on a once in a lifetime opportunity. For what ever reason Dev day was small this year. There where only around 300 of us on the Developer track, and while the superstars of Virtualization were all looping through PTAP sessions I was attending small 15 to 1 labs with the likes of Steve Jin, Scott Herold, Carter Shanklin, LucD, and Cody Bunch… You could say I learned a thing or two!
I started Monday with DS-13 it was suppose to be an Introduction to the vSphere Webservices SDK . Unfortunately system errors prevented Steve from giving his full presentation! My first lab I spent 45m trying to log into my virtual desktop. It wasn’t a total lost though as I had Access to one of the authoritative sources on the VI API! Shortly after Steve’s session I got a little side tracked, and picked my schedule back up with DS-16.
DS-16 Extending PowerCLI to Enterprise Applications with Virtualization EcoShell (VESI) presented by Scott Herold. This session proved to be my favorite from Monday, and ran an hour long (in a good way)! Good news, Scott and his team have done some fantastic work. He is attempting to develop on demand. Meaning as a demand for a feature/need starts to bubble up from the community either from the VESI forums or the usual places. Scott fills that gap with a custom script extending the PowerCLI, or by modifying the user interface itself, extending VESI to better match the needs of the virtual administrator. An example of the latter was on display where the VESI team has added the ability to transform any data set into rich charts. An important distinction with VESI is it is meant to enable the Virtualization Administrator NOT the VI Admin! VESI will have full support for any Hypervisor/mgmt framework that the community has demand for. It will also encompass any peripheral components of the virtual world. Providing easy to use and context relevant access to any pain point whether it be storage, Network, AD… What ever the community needs!
The cynic out there will ask okay what does Vizioncore get out of this? the answer, A single pane of glass that encompasses the entire virtualization ecosystem. Oh yeah, and that pane of glass, it will one day serve as the front end for all of Vizioncores products! The question was asked about pricing, and Scott insists that “VESI is and always will remain free”. They need this framework for there own internal roadmap. It’s extension to the community as a whole in my opinion will garnish them nothing but good will, and a built in user base. Your probably asking yourself where’s the bad?
Politics… anyone from the PowerShell community will immediately recognize the VESI interface. It’s our old friend PowerGUI, I asked Scott why something new, why not just build on top of PowerGUI. His answer was speed, the PowerGUI team has a product roadmap, and there users need different things then Scotts. He used the upcoming charts feature as an example. It could take PowerGUI 18 months to get charts on there roadmap. PowerGUI is already hard at work putting out other fires. By Scott forking PowerGUI he created a divisions but that division purchased an independent product roadmap. It’s this roadmap that is enabling him to move with the Virtualization Community. The sad part to me I don’t believe the division was truly necessary. Why Scotts team couldn’t just develop those same features, injecting them into PowerGUI as needed, and thereby enhancing both products at once… that can only be political. We all know how software works. There is no technical reason preventing this. Alas while I think a best of both worlds super PowerGUI would have been better for everyone. I for one am glad to have VESI in our tool belt. If your new to PowerShell or the PowerCLI check it out as Carter put it “VESI is the onramp to PowerCLI and PowerShell Scripting”… Couldn’t agree more!
Finally I ended Monday with a session on VIX. while there is some really cool stuff coming in VIX there has been no change for the PowerShell community. The latest version of VIX shipped just last week, and sadly 1.7 still offers no .Net/vi sdk interfaces. The .COM interface is critically crippled if you want to use it with vSphere, and overall your still forced to provide a username/Password to the guest OS. Alas it’s not nearly as bad as I made it out to be! 😉
The 1.7 release added full support for vSphere 4.0, and the VIX team is currently evaluating SSIP/Certification based authentication for the guest. As for how it will ultimately be extended into powershell it looks like either a .net class, or by extending the vi api. Either way will be a win for powershell as we can easily extend either into first-class cmdlets! The use case for VIX is a bit nitch, but when you need it nothing else will do!
An interesting tidbit if you’re super security cautious you can disable VIX by adding
to either the VM or the host. Be aware that this WILL break upgrading of VMware tools, and Guest customization as they both use vix as the underlying technology!
So that’s Developer day at VMworld all in all I had a blast, and met the superstars of the VI API/vSphere automation community. The Food was 10x better then what they’re serving here at VMworld, and I get a free license of vSphere! All for $249 USD, if you’re interested in more advanced automation at the vi api level I highly recommend developer day.
VMware this was a win, win… let’s try and keep it for the future.