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.
In Deploy Photon 2.0 – Part 1, we showed how to create a Template with the Photon 2.0 guest OS. In Part 2 we will introduce the New-PhotonVM function, which allows to create one or more VMs, based on the template created in Part 1.
The basic concept for the New-PhotonVM function is the same as for the New-PhotonTemplate function. The configuration for the VMs is driven by a JSON file that is passed as an argument to the function.
Photon 2.0 is definitely a guest OS that is useful in a VMware vSphere environment. It is light-weight, easy to manage, security hardened and comes with the Docker daemon. That last feature makes it an ideal environment to explore new applications, isolated from your live platforms. As an example, quite a few of us got to know PowerShell Core with VMware PowerCLI, while running it in a Docker container, well shielded from our other platforms.
There are numerous articles and blog posts that describe how set up a Photon 2.0 VM, but most of these use the ovftool or the vSphere Web Client to install it. Followed by quite of a bit of editing config files, to have your Photon 2.0 VM running the way you prefer it. With the latest version of my Invoke-VMScriptPlus function, you can now automate this entire process, the SDDC way!
Update August 21st 2018
Added “reboot” action
Added optional Environment variables for the customisation scripts
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.
The ability to execute scripts inside the guest OS of your VMs, is definitely one of the more useful cmdlets available in VMware PowerCLI. A year ago I published the first version of my Invoke-VMScriptPlus function to solve some of the issues the Invoke-VMScript cmdlet has in my opinion. That function allowed you to run multi-line scripts in a Linux guest OS on your VMs. It also allowed you to use she-bang lines, to indicate which interpreter your script had to run in (bash, perl, python, nodejs, php…). Another handy feature was that you could use Linux here-documents in your scripts.
With the introduction of PowerShell Core (aka PowerShell v6), the lack of support for any Guest OS of the Windows family became obvious. Prompted by a recent thread in the VMTN PowerCLI Community, I decided it was time to publish a new version of my Invoke-VMScriptPlus function.
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!
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.
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.