I had a question the other day asking whether the encrypted password which can be specified within an ESXi Kickstart file (denoted by the --isencrypted flag) can use a different hashing algorithm other than MD5? The answer is absolutely yes. In fact, MD5 as a default hashing algorithm has NOT been used for a number of releases, probably dating back to classic ESX (you know, the version that had the Service Console).
For all recent releases of ESXi including 5.5 to 6.7, the default hashing algorithm has been SHA512 for quite some time now. Below are two ways in which you can check which default hashing algorithm is currently being used:
Option 1 - SSH to ESXi host and take a look at /etc/pam.d/passwd
Option 2 - SSH to ESXi host and take a look at /etc/shadow and look at the field prior to the salt.
The idea of "Instant Cloning" a Nested ESXi VM (running ESXi in a VM) is not a new concept. In fact, I had shared a solution back in 2015 using the private VMFork APIs. However, what has changed is the ease of consumption, primarily due to the re-architecture of Instant Clone in vSphere 6.7 (more details here and here) which resulted in a public and simplified API. Some of you might ask, why not simply clone a Nested ESXi VM or create a Link Clone? What benefit would I get by using Instant Clone?
The answer is not only speed, but the fact that the instantiated VM is fully operational and ready to start executing where as a traditional full clone or linked clone requires a full OS boot up that can take up to several minutes to deploy and configure. This may not sound like much for a small number of Nested ESXi VMs, but as you increase the number of instances, Instant Clone really shines while still maintaining speed and the instant availability of the VM. As you can imagine, this definitely opens up for some interesting use cases whether it be for personal home lab or educational purposes like VMware HOL. In addition, we also have customers who deploy Nested ESXi not only at high scale but also with a high churn rate for development purposes, think CI/CD type of a workload who can also benefit from Instant Clone.
So how fast are we talking about? Lets say you wanted to test out the latest version of VSAN in vSphere 6.7, you would normally deploy 3 Nested ESXi VMs, power them up and wait for them to be ready on the network. With Instant Clone, you can deploy three fully functional Nested ESXi VMs in just 30seconds! As the VMs are instantly available for consumption, you can start the VSAN enablement workflow immediately and even parts of that can be baked into the Instant Clone workflow. With the ease of provisioning Nested ESXi VMs, you can simply maintain a catalog of ESXi templates which are in "frozen" states and then leverage Instant Clone to deploy just-in-time Nested ESXi environments and discard them once you are done. Pretty slick if you ask me! and something I plan on using going forward.
Disclaimer: Nested ESXi is still not officially supported by VMware. Please use at your own risk.
While catching up on my news feed early this morning, I came across a really slick browser plugin developed by Jens L. that enables a "Dark" theme for the vSphere HTML5 Client (h5client). If you use either Chrome or Firefox, simply visit Bery's Github site here to get a link to the plugin.
Once the plugin has been enabled, simply login to your vSphere H5 Client, this works using vSphere 6.5 or latest 6.7 and you should see the UI automatically render using the Dark theme without any modifications to your vCenter Server. I know the Clarity team is working on an out-of-the-box Dark Theme for the H5 Client, but until then, this is an excellent workaround. I definitely appreciate this as someone who does work either super late at night or super early in the morning and although I use things like Flux to reduce the brightness of the screen, having a proper dark theme also helps. Thanks for the awesome project Bery!
Here is a screenshot of my vSphere 6.5 environment, which I was able to make use of new theme morning 🙂
For those that have customized their vSphere Client Login UI using the instructions here and here, it looks like the process can not be applied to the vSphere 6.7 release. From what I can tell, it looks like we have now consolidated the various WAR files into a single file /usr/lib/vmware-sso/vmware-sts/webapps/ROOT.war. The original contents of the websso directory, which pertains to the UI customization, is now located here. This was a fairly minor change, but something to be aware of and for details on how to persist your configuration changes, please see the instructions below.
Disclaimer: This is not officially supported by VMware. If you decide to enable this, please use at your own risk and ensure you backup all original files in case you need revert back to the original configuration.
As part of looking into this, I also had some fun incorporating a cool little animated login page directly into the vSphere UI which I had shared on Twitter yesterday. Stay tuned for more details on #vYetti 🙂