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 🙂
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.
A new DSC resource in the vSphereDSC module, the VmwDatacenter resource. This is a rather smallish resource, ideal for a Monday 🙂
A Datacenter can only be created in a limited number of locations in a vSphere tree. You can create them in the RootFolder, or in a Yellow folder, but you can not “nest” Datacenters. The new vSphereDSC module release contains some sample Configurations for creating and removing Datacenters.
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.
My attempts to marry DSC and vSphere have been going on for nearly a year* now. I showed some of my attempts and intermediate results at VMworld 2015, in two sessions at the PowerShell + DevOps Global Summit and recently during a session at the 24th VMUGBE+. But now I’m finally going public with the vSphereDSC module.
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
In an older post, named Folder by Path, I provided a function to retrieve a Folder object by it’s path.
With the recent publication of my Get-InventoryPlus function, I can now get the path to all vSphere objects. So the obvious next step was to create a function, that would be able to use that information and retrieve any vSphere object by it’s path.
The function was first demonstrated during the 24th VMUGBe in Mechelen.
Often I have to get a complete list of all the objects in a vSphere environment. From the PowerCLI cmdlets, the Get-Inventory cmdlets looks like the obvious candidate to tackle such a request. But the cmdlet seems to have some shortcomings. It definitely does not return all vSphere objects.
Hence I set out to write this Get-InventoryPlus function.
The function was demonstrated for the first time during the 24th VMUGBe in Mechelen.
PowerCLI is great tool, and the Team behind it surprises us on a regular basis with a new Release. With the v6.x generation we witnessed the introduction of Modules. And the Team keeps adding further integration with other VMware products.
With the PowerCLI installation comes a shortcut to a PowerShell sessions, loaded with all the PowerCLI goodness. And this is ideal to make your first steps in the wonderful world of PowerShell and PowerCLI.
But soon you’ll start using more advanced features of PowerShell. You’ll be scheduling jobs, running parallel workflows, start using PowerCLI in Desired State Configuration (DSC). At that moment, the simple PowerCLI session doesn’t cut it anymore, and even the Init scripts that are installed together with PowerCLI, will not give you the exact environment as you want it. Hence my Universal PowerCLI Loader!
I have been using a “Universal PowerCLI loader” function since quite some time now. I thought it was time to prettify it a bit, and share it with the community.
While Archimedes once said “Give me a place to stand and with a lever I will move the whole world”, my personal preferred statement nowadays is “Give me an API, and I will automate it!”. And the LogInsight module I’m announcing is another step on that path.
So I was very pleased when the Release Notes of the latest Log Insight version announced the availability of a Query API. On the blog of Steve Flanders there are several posts that go further into this new feature. Definitely worth a read to get a better understanding of what is available, and what is not (yet).
My LogInsight PowerShell module makes use of these new API, and it will allow you to automate your interaction with Log Insight from within your PowerShell scripts.