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.
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!
An automation scripts that prompts you is a letdown, to say the least.
A typical example of such an event is the question you get when you try to unmount a CD or DVD drive from a VM. Some Linux guest OS will place a lock on the CD or DVD, and vSphere will ask you if you want to bypass this lock. And your script just hangs there, waiting for you to reply 🙁
Another interesting question in the PowerCLI Community today. David wanted to know if it was possible to track which VMs had been failed over to another ESXi host by HA.
With the Get-VIEventPlus function from my Get the vMotion/svMotion history post it is easy to get that informatiom from the Tasks and Events that are kept in the vCenter database.
The end of the year is near again. Time to plan for the new, but also a time to look back on what was there in the past year.
Your vSphere environment is no different. It is time to produce some of those dreaded year reports that will show you how your environment has been doing. And one of the aspects a lot of people are very keen about, is the number 9 game 😉
What was the uptime of the VMs you had running ?
The question popped up on several occasions in the PowerCLI Community as well. So I guess I was not the only one that was looking for a way to calculate the uptime of Virtual Machines.
Bug alert ?: it seems that the PerformanceManager handles vMotions in a strange way. After a vMotion the sys.uptime.latest is reset to 0 (zero). That is understandable, since the VM is now running on a different ESXi host. But it seems that the aggregated metric do not add up all the sys.uptime.latest metrics from different ESXi hosts. So when you use DRS or do vMotions yourself, the produced report will have some serious flaws !
But getting the individual vDisk statistics is a bit more tricky compared to getting the datastore statistics, as I showed in that post. The “disk” metrics hold the information, but the Instance that points to the MoRef value of a VM makes it a bit more tricky to retrieve.
Be forewarned, the “disk” metrics hold usage data for all the vDisks that a specific VM has on a specific datastore. You will not be able to get individual vDisk statistics, unless the vDisks are stored on different datastores !
On the positive side, the “disk” metrics will allow you to see how your vDisks increase in size over time. For your Thick vDisks that increase will be by expanding them, and for your Thin vDisks it will also show the natural growth.
Since I’m interested in all things statistics in vSphere I decided to tackle the question. Finding the metrics to use for this kind of report is not too difficult. Under the PerformanceManager Network section we find the metrics net.received.average and net.transmitted.average. And, provided your Statistics Level is set to 3 for the timeframe you want to report on, the metrics capture statistics on the device level.
Great, exactly what we need! A quick check in the Performance tab in the vSphere Client showed an additional problem to solve. The instance didn’t mention Network Adapter 1 but a number.