One of the important DevOps adagios in my book is “Treat your servers as cattle, not as pets”. Meaning that you roll out your stations when you need them, use them and throw them away after you used them. This series of posts will document one such way of deploying such ‘cattle’ stations. The method is named cloud-init.
In this first part, we will introduce cloud-init and how you can use it from your PowerShell/PowerCLI scripts. Since the Ubuntu distribution is very popular, on-premises and in the cloud, this introduction will focus on that distro to demonstrate the concept. In the following parts, we will tackle Photon, containers and how to run your scripts on these stations.
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.
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.