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
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.
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.
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
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.