Mainly VMware things
While using the vCenter Upgrade process to 6.7 Update 1b I ran into an issue where the space calculation results were incorrect in the upgrade interface. The GUI stated it would need 2.78GB but the actually capacity needed on the source appliance was much greater.
There are many times when we will want to schedule VM clones within our environment. Doing this for one or two VMs is easy enough through the various clients but if you are needing to do this on dozens of VMs then this can become highly tedious. I found some examples on the internet but nothing that was effective on specifying resource pool and exact time when scheduling out the work. This script allows you to specify those items and fulfills my requirements.
PowerCLI has been a mainstay for automating all things VMware for a very long time. PowerCLI can be an extremely powerful tool but highly frustrating if you don’t understand it. As I have progressed through my career I have gone from someone who was confused and frustrated to someone who completely loves PowerCLI. I hope this document can take some who are in the first group and move them into the second group. As you get into PowerCLI you will find the information I have included here just scratches the surface, for more information please reference VMware’s Cmdlets reference guide.
To ensure compliance and reduce vulnerability vectors we need to frequently update our ESXi hypervisors. If you setup your configuration with SDDC then that process is simple. However, as soon as vCloud Director (VCD) is utilized the environment it causes some additional steps to be taken. In order to ‘properly’ patch a hypervisor within VCD V8 or older you should disable the host and then redistribute VMs. If ignored then this can cause problems, while on newer versions of VCD this is handled rather gracefully, on older versions of VCD that is not the case. In order to ensure that proper patching process is done I opted to write a script that did all of the proper steps with the hypervisor in all services.
We had a few hypervisors in our configuration that were incorrectly configured with a VMKernel port (VMK) on a distributed virtual switch (DVS). These particular hypervisors had specific requirements to keep those VMK ports assigned to a traditional vSwitch. VMware has an amazingly slick process to move VMKs from a vSwitch into a DVS but unfortunately no way of moving it back to a standard vSwitch. If these management interfaces are either your sole means of access or your primary access then the hypervisor will become disconnected off the network.
To resolve this problem I created a simple shell script that can be copied onto the hypervisor and executed. A few variables will have to be changed within the script to match your environment. I have successfully run this script on dozens of hypervisors in my configuration with zero issues.