As most of you might know by now, VMware is moving away from SOAP and going to REST API.
Is this something you should know about? Yes, you should!
In a two-part article on TechGenix, I wrote down my thoughts and observations on REST API. The article goes into what this move towards the REST API might mean for you as a scripter/administrator.
Since an article on coding, without a coding example doesn’t make much sense, I added a module, named rCisTag on the PowerCLI Examples repository.
Enjoy reading Part 1, Understanding the VMware REST API interface!
and Part 2, SOAP vs REST for performing tasks in VMware environments.
REST API are (nearly) everywhere! VMware’s VMTN website is no exception. I already did a post on Automate Your VMTN Search, but that was entirely based on constructing URI and interpreting the returned webpages. For the occasion of the PowerCLI’s 10th Birthday session at VMworld, I wanted to produce some InfoGraphs on the PowerCLI Community. For those InfoGraphs I needed to harvest data from said VMTN Community, and I looked for a better way to do this. That is where the REST API offered by the Jive software, om which the VMTN website is hosted, came in handy.
The functions I ended up with, are also a good example of how easy it is to consume REST API through PowerShell. And they also show how the basic techniques to work with REST API can be reused. Check out my VMTNRest repo.
Continue reading Search VMTN with REST API
Your vSphere environment is a living environment. Inventory objects are created and removed all the time. Together with these inventory objects there are often security permissions that come along. Team X needs Power User access for all VMs in folder Project-X. But the life-cycle management of these permissions is often not as fluent as your VM life cycle management. There is no built in permission cleanup method.
As a result, old permissions might be left behind, and what is worse, redundant permissions might be present. This doesn’t make the task of investigating “Who can do what?” in your vSphere environment any easier.
With the help of the function in this post you can now get rid of all these redundant permissions!
Continue reading vSphere Permission cleanup
The Invoke-VMScript cmdlet is definitely one of the PowerCLI cmdlets that is indispensable when you need to do things inside the Guest OS of your VMs.
When you are interacting with a Windows based Guest OS you can run old-fashioned BAT files or use PowerShell scripts. When the Guest OS is Linux based, you currently only can run Bash scripts.
Most Linux flavours have a feature that is called SheBang, and which allows you to specify in the first line of your bash script, which interpreter shall be used to run the following lines of the script. Unfortunately, the current Invoke-VMScript cmdlet doesn’t allow one to use that feature.
Time to tackle that issue, and expand the possibilities for all VMs that have a Linux-based Guest OS. So I decided to write my Invoke-VMScriptPlus function.
Update October 14th 2017
- Added here-document bash sample
Continue reading Invoke-VMScriptPlus
It is no secret that PowerCLI has lots of amazing options and well-thought trough features. But there is one feature that most of PowerCLI’s users take for granted, and most probably do not even realise that they are using what is called Object By Name or OBN. In this post I’ll show you one way of creating your own OBN, a home made Object By Name, which you can use in your own functions and modules.
OBN allows you to refer to a PowerCLI object by name, instead of passing an actual PowerCLI object. A classic example is “Get-VM -Datastore DS1“, where we are retrieving all VMs that live on a specific datastore. If one looks at the description of the Datastore parameter, it clearly states that a value of type StorageResource is expected, but we are able to provide the datastorename, a string. Under the cover, PowerCLI converts this string to the required PowerCLI object for the parameter.
When we are writing our own functions, it would be very handy to have the same functionality at our disposal. Define a parameter to be of the type of a PowerCLI object, but then be able to pass the name of the object, instead of the object itself.
The solution is here, with the MyOBN attribute. We now have the same functionality available, that was until now only available for PowerCLI cmdlets.
Update September 14th 2017
- Added support for VIServer
- Added support for arrays of objects
- Fixed an issue with the VirtualMachine object
Continue reading Home Made OBN
Yesterday a blog post, named Integration with VMware vSphere using the new Open Sourced Software Development Kits, was published. In my opinion an important milestone on VMware’s Open Source path ! The blog post announced the availability of the first two Open Sourced SDKs made available to the public on GitHub. One for REST and the other for Python.
When we hear REST API, we know it is relatively easy to consume these from a PowerShell script. So power up your labs and follow along on my first steps in my vSphere Audtomation SDK and PowerShell adventure.
Continue reading vSphere Automation SDKs, PowerShell and you – Part 1
Appliances are hot!
Each appliance, delivered as an OVA or OVF, can have one or more properties attached to it. These properties are mostly used to configure the appliance. In PowerCLI we have the Get-OvfConfiguration cmdlet. It returns the user configurable properties from an OVF or OVA file in a hash table.
But what about upgrading an appliance? Most, if not all, of the Ovf Properties are already entered for the older version of the appliance. Can’t we use that information to upgrade the appliance? And avoid having to retype all that information?
And to take away the suspense, of course, that can be done with a bit of PowerShell!
Continue reading Upgrade an Appliance with OvfTools
One of the lesser used PowerCLI cmdlets must be the Get-EsxTop cmdlet.
It’s not that the Get-EsxTop cmdlet is not very useful, on the contrary. In my opinion, the main reason for it’s infrequent use might be the complexity involved to actually use the data it returns. Add to that a somewhat lacking documentation, and the Ugly Duckling of the PowerCLI cmdlets is born.
But just like in the story, this cmdlet has the potential to grow up, and transform into a beautiful swan.
I already did some Get-EsxTop posts in the past, see Hitchhiker’s Guide to Get-EsxTop – Part 1 and Hitchhiker’s Guide to Get-EsxTop – Part 2 – The wrapper. But a recent thread in the VMTN PowerCLI Community made me rethink how the Get-EsxTop cmdlet could be put to better use. The author of the thread wanted to compare the results returned by Get-EsxTop with the data displayed in esxtop. He also compared the calculated Get-EsxTop metrics with those returned by the Get-Stat cmdlet, and there were some serious discrepancies!
Continue reading Get-EsxTop – Another Look
I do love integration, and especially when it is done in a new, innovative way.
My friend Dennis Zimmer, from Opvizor, recently gave me access to a preview of one of their new tools, which they called ChatOps Bot for VMware vSphere. It combines vSphere API calls with Slack API calls. Needless to say I liked the concept. And I can see many interesting possibilities.
Have a look.
Continue reading ChatOps Bot
In my Orphaned files and folders – Spring cleaning post from way back, I provided a script to find orphaned VMDKs. This week there was a post in the VMTN PowerCLI Community that had a request to find all orphaned files. Time for a revisit of my old post!
I took my old script, massaged it a bit and gave it a more contemporary look and feel.
Just for info, the SearchDatastoreSubFolders method is relatively slow. So scanning a couple of datastores for orphaned files might take a bit of time. Be patient 🙂
Continue reading Orphaned Files Revisited