WilliamLam.com

PowerCLI script to help correlate vCenter, ESXi & vSAN build/versions w/o manual VMware KB lookup

by // 10 Comments

I can still remember when I was a VI Admin and how annoying it was to try to correlate the build numbers for my ESX(i) hosts and vCenter Servers that I have deployed with the versions listed on VMware's website. This especially gets challenging when there are multiple patch releases (a, b, c or 01, 02, 03) in between major releases (5.5, 6.0, 6.0u1, 6.0u2, 6.5, etc.). Historically, most customers including myself would retrieve the respective build numbers and then manually comparing them to either the release notes and/or download website which was very tedious.

Although VMware has exposed the version number within our vSphere products since day 1 which can also be retrieved programmatically using the vSphere API (here), it unfortunately does not provide more details than simply the major/minor version (e.g. 5,5, 6.0, 6.5, etc) of the software. Recently, VMware had released a series of VMware KBs which provides a mapping between the build numbers for vCenter Server, ESXi and vSAN to their respective versions which can be found in the links below:

These are definitely a great set of resources that I know many customers including myself have been using since its release. Having said that, the process today is still pretty manual since you need to manually retrieve the build numbers for either a VC, ESXi or vSAN Host (can be automated using vSphere APIs) and then comparing that to the KBs to get the correct versions. How cool would it be if you could *easily* just point to YOUR environment and retrieve the version information for either a vCenter Server (Windows or VCSA), ESXi host(s) or vSAN host(s) without needing to manually perform this lookup each time? Well, I have just done that! I have taken all three KBs and converted that information into a simple PowerCLI script called VCESXivSANBuildVersion.ps1 leveraging our vSphere API and it provides three functions:

  • Get-VCVersion - Retrieves the vCenter Server version given a VC connection
  • Get-ESXiVersion - Retrieves the ESXi version for all hosts given a vSphere Cluster
  • Get-VSANVersion - Retrieves the vSAN version for all hosts given a vSAN Cluster

Here is an example output using the first two functions:


For the vCenter Server version output, you will notice that I am also including the OS platform of your vCenter Server, so you can distinguish between a Windows vCenter Server and a vCenter Server Appliance (VCSA) which can be useful to see if you have been #migrate2vcsa ;). For the ESXi version output, you will notice the "OriginalInstallDate" value, this is actually new API property that was introduced in vSphere 6.5 and it provides you with the original installation date of your ESXi host (more details can be found here) which is pretty neat.

Here is an example output using last function:


If you wanted to take this a step further, you could even take this output and dynamically update the vSphere UI using either Custom Attributes or vSphere Tags so you know what version the software is at any given moment. Its easy enough to set this up as a scheduled task that could run periodically so you always have the latest information provided in the vSphere UIs.

Although this is a significant improvement over the existing manual methods, I think most of you will agree that it would be ideal if this information was natively available within the product which means BOTH UI and APIs. I think we all appreciate versioning of software is not always easy and it can change from release to release for a variety of reasons, most of which may not be technical. If the vSphere platform could dynamically pull this information in either real time and/or through an offline mechanism and provide this association by default, it would greatly improve the experience when needing to troubleshoot or perform maintenance of the vSphere platform. If this is something you would like to see, please leave a comment below providing your feedback. I know I have already pinged our PMs about this and I am sure they would love to hear form you as well!

Additional Information:

Note1: Update levels can be found using the vSphere API, take a look at this article here for more details.

Note2: As of ESXi 6.5 Update 1, the Update levels are also included by default in the Embedded Host Client as shown in the screenshot below:

Note3: As of vSAN 6.2, the vSAN Management API already includes vSAN version information that can be queried. Take a look at this script here which exercises this new API. For example above, I decided to not use this new API since customers may be running older releases of vSAN which is not covered by the vSAN Mgmt API.

Note4: VMware has also published simliar build to version mapping for other VMware products which can find the complete list here.

Functional USB-C Ethernet Adapter for ESXi 5.5, 6.0 & 6.5

by // 23 Comments

While attending an offsite this week, there were some discussions amongst my colleagues about their new Apple Mac Pro and its USB-C only ports. The discussion was completely unrelated to work, however that did get me thinking about the USB-C peripheral market and specifically their ethernet adapters. While searching online, I came across several new USB-C to gigabit ethernet adapters that were now available and one in particular that was very interesting, was the Plugable USB-C to 10/100/1000 Gigabit Ethernet LAN Network Adapter. What caught my eye about this specific network adapter was that it uses the exact same ASIX AX88179 driver as my USB 3.0 to Ethernet Adapter ESXi VIBs were built off of! There was a good chance this might just work.


As you can probably guess, I was pretty excited and quickly ordered one of the Plugable USB-C Ethernet Adapters. The next challenge was getting access to a system that has a USB-C port. After asking around, I finally got my hands on a Dell XPS 13 which has a USB-C port that I could use for a few days. Funny enough, the Dell laptop only has USB 3.0 and USB-C ports, so the first challenge was to disable Secure Boot since I had built a custom ESXi 6.5 image that included my USB 3.0 Ethernet Adapter VIB. Below are the ESXi VIBs or offline bundles that will be required for this solution.

UPDATE (02/12/19) - A new VMware Native Driver for USB-based NICs has just been released, please use this driver going forward.

Please see this blog post for more detailed instructions on installing the VIB as well as accessing the vusbX pNIC.

Disclaimer: This is not officially supported by VMware. Use at your own risk.

Once I got ESXi up and running, I was disappointed to see that the USB-C device was not being detected. I had tried a few more things but nothing worked and I decided to sleep on it. The next morning, I realize maybe there was some additional settings that needed to be tweaked in the BIOS. With a bit of trial/error, I found out that you needed to enable the "Thunderbolt Boot Support" which apparently is disabled by default, at least on this Dell system. Below is a screenshot of the BIOS USB/Thunderbolt Settings and this was the only change required from the system defaults.


Once I rebooted, I immediately saw the link up on the USB-C device while ESXi was starting up 😀

[Read more...]

How to Netboot install ESXi onto Apple Mac Hardware?

by // 13 Comments

The ability to perform an ESXi Scripted Installation over the network has been a basic capability for non-Apple hardware customers since the initial release of classic ESX. However, for customers who run ESXi on Apple Mac Hardware (first introduced in vSphere 5.0), being able to remotely boot and install ESXi over the network has not been possible and customers could only dream of this capability which many of us have probably taken for granted.

Unlike traditional scripted network installations which commonly uses Preboot eXecution Environment (PXE), Apple Mac Hardware actually uses its own developed Boot Service Discover Protocol (BSDP) which ESXi and other OSses do not support. In addition, there are very few DHCP servers that even support BSDP (at least this may have been true 4 years ago when I had initially inquired about this topic). It was expected that if you were going to Netboot (equivalent of PXE/Kickstart in the Apple world) a server that you would be running a Mac OS X system. Even if you had set this up, a Netboot installation was wildly different from a traditional PXE installation and it would be pretty difficult to near impossible to get it working with an ESXi image. With no real viable solution over the years, it was believed that a Netboot installation of ESXi onto Mac Hardware just may not be possible.

tl;dr - If you are interested in the background to the eventual solution, continue reading. If not and you just want the goods, jump down a bit further. Though, I do think it is pretty interesting and worth getting the full context 🙂

[Read more...]