The next question on your mind is probably “How can I contribute?“. Well, with the correct tools and some VMware PowerCLI knowledge, it turns out that this is not too difficult. What follows is my first attempt at contributing to the Desired State Configuration Resources for VMware.
Before you need to reboot a VM, or do some destructive maintenance on there, it is a good practice to at least tell the user(s) of that VM what is going to happen. But how do you address the users of a VM? They can be connected to a console (local) or via a RDP session (remote). And how do you get their reply back?
Exactly such a question appeared in the VMTN PowerCLI Community recently. And after some digging, it seems that is possible through a PowerShell script that uses the Remote Desktop Services API, provided through the wtsapi32.dll. Note that the VMs we are looking at, all are running a Windows guest OS.
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.
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!
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.
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 🙂
We all know, and love, PowerCLI‘s New-Datastore and Set-Datastore cmdlets to create and manipulate VMFS datastores. But when we look at the functionality available through the Web Client, there is one interesting feature for manipulating VMFS datastores that is missing from the PowerCLI cmdlets. The Increase button, which allows us to Expand or Extend an existing VMFS datastore*.
Recently there were a couple of threads on this subject in the VMTN PowerCLI Community, so I decided to streamline my quick-and-dirty scripts into something more presentable, and create a PowerShell module to bundle the functions. I present the VMFSIncrease module!
The VMFSIncrease module will also be my first contribution to the PowerCLI Community Repository! More on that further on in this post.
* The expand and extend functions for a VMFS datastore depend on the availability of free space on the VMFS datastore extents and/or the availability of free LUNs
The “Principles of Operation” in the title is in fact just an expensive expression for “How do I use this stuff ?”. In this post I will try to show you how you can use the vSphereDSC module, as a user, and as a contributing developer. On the side, it also shows you how you can use these vSphereDSC resources.
The vSphereDSC module contains a set of DSC resources to can be used to configure a vSphere environment. These DSC resources can be used against any vSphere Server, beit a vCenter or an ESXi node. On the condition of course that the selected resource is supported on the vSphere Server.
For “users” of the vSphereDSC resources, the post will show how to automate keeping the module up to date and how to manage the life cycle of the Configuration files that are build on the vSphereDSC resources.
For those of you that want to contribute to the development of the vSphereDSC module and it’s resources, this post will also show how you can automate the testing phase. In a first instance through a number of PowerShell scripts, in a later phase through the use of a build server.
In this post I’ll introduce the first DSC resource from the vSphereDSC module, the VmwFolder resource. Since this is the first post in the series, I will also expand a bit on how the vSphereDSC module is set up and which conventions I’m using.
A vSphere Folder is a resource which can exist rather independently in an existing vSphere environment. You can easily create some test Folders to get the hang and feel of the vSphereDSC module and play with DSC Configurations based on this vSphereDSC resource.
Since WMF 5 has been made available in preview, and still is in RTM at the moment I’m writing this, there have been constant changes to the way I was writing the DSC resources for vSphere. Since the February 2016 WMF 5 release, I now have a (somewhat) stable, working class-based solution. At least, that is what my initial tests seem to indicate.
This intro for my vSphereDSC series, will lay out the playing field. I’ll explain the concept I’m using, show some of the issues I encountered and explain the layout of the vSphereDSC Resource module.
* “Wisely and slow; they stumble that run fast”, Romeo and Juliet, Act II, Scene III