The main reason to use Photon OS is that it is open-sourced, it has a small footprint and it is optimised for VMware vSphere.Continue reading Cloud-init – Part 3 – Photon OS
A guest post
Over the last couple of weeks, it has been my great pleasure to assist Chip Zoller in writing a VMware PowerCLI script, named Optimize-VMwarePKS. This script helps organise your PKS deployment at three levels: folders, tags and DRS rules, including functionality to run a clean up.
The following post by Chip describes the function in greater detail, and shows how you can use it.
This post also appears on the Sovereign Systems website as Optimize-VMwarePKS: A PowerShell Script for All Your VMware PKS Deployment Needs.
Take it away Chip.Continue reading Optimize-VMwarePKS
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
- Added Folder field for template destination
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.
Update August 21st 2018
- Added ScriptEnvironment
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.
Enjoy reading Part 1, Understanding the VMware REST API interface!
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!
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.
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!