esxi

New VMware Configuration Maximum Tool

04/13/2018 by William Lam 1 Comment

VMware has just released a new web-based tool that will enable customers to easily view and compare product configuration maximums across different VMware product versions. You can access the easy to remember URL by going to: https://configmax.vmware.com

In this first release of this tool, customers will have the ability to look up configuration maximums for vSphere (includes VSAN) which will initially support vSphere 6.0, vSphere 6.5, vSphere 6.5 Update 1 & the recently released vSphere 6.7 as well as comparing across versions. To view the existing vSphere configuration maximum, simply click on the "Get Started" button.

As you can see from the screenshot below, you now have a single place where you can view the vSphere configuration maximums across different versions. Once you have selected the target version, you can either view all maximums or you can selectively choose the sections you are interested in.

The other really neat feature is the ability to compare the configuration maximums across different vSphere versions. This is really useful for customers to be able to quickly tell what improvements and enhancements have been made, especially as customers plan for vSphere upgrades. To begin, simply click on the "Compare Limits" button at the top. Next, select the target vSphere version and then you can add one or more versions to compare against.

Once you click on the Compare button, a new window will popup providing you the comparison between the target and selected vSphere versions. You can quickly see how the maximums have changed across these vSphere versions. You can even export the results to Excel by click on export option on the upper right hand corner and you be prompted to save a CSV file.

I can tell you, this definitely beats having to manually Google for the correct vSphere configuration maximum document since I can never remember the long URL to the static PDF documents! I am excited to see the improved user experience when consuming our product maximums and I know the team will be working on adding more products and features in the future. Definitely keep an eye on this site and also be sure to update your bookmarks. If you have any feedback or things you would like to see, feel free to leave a comment and I will make sure it reaches the Product and Development teams.

ESXi host with network redundancy using NSX-T and only 2 pNICs?

03/27/2018 by William Lam 7 Comments

In todays data centers, it is not uncommon to find servers with only 2 x 10GbE network interfaces, this is especially true with the rise of Hyper-Converged Infrastructure over the last several years. For customers looking to deploy NSX-T with ESXi, there is an important physical network constraint to be aware of which is quickly mentioned in the NSX-T documentation here.

For example, your hypervisor host has two physical links that are up: vmnic0 and vmnic1. Suppose vmnic0 is used for management and storage networks, while vmnic1 is unused. This would mean that vmnic1 can be used as an NSX-T uplink, but vmnic0 cannot. To do link teaming, you must have two unused physical links available, such as vmnic1 and vmnic2.

As shown in the diagram below, an ESXi host with only two physical NICs can not provide complete network redundancy as each pNIC can only be associated with a single switch (VSS/VDS or the new N-VDS) as pNICs can not be shared across switches.

For customers, this means that you need to allocate a minimum of 4 pNICs to provide redundancy for both overlay traffic and non-overlay VMkernel traffic such as Management, vMotion, VSAN, etc. This is much easier said than done as not all hardware platforms can easily be expanded and even if they can, there still is a huge cost in expanding the physical network footprint (switch port, cabling, etc).

UPDATE (06/12/18) - As of NSX-T 2.2, which was recently released, there is now a UI in NSX-T Manager for managing the migration of VMkernel interfaces to the N-VDS. For automation purposes, you may still find this article useful but now you have option of using the UI.

Thunderbolt to 10GbE Network Adapters for ESXi

03/15/2018 by William Lam 4 Comments

I was recently made aware of this article in which the author, Karim Elatov, had successfully demonstrated the use of a Sonnett Thunderbolt 2 to 10 Gigabit Ethernet Adapter with ESXi running on an Apple Mac Mini. As far as I am aware of, this may be the first public confirmation that such a device would work with ESXi, not to mention having it functional on the Mac Mini. I know in past years, there have been unconfirmed reports on various forums mentioning a Thunderbolt to 10GbE solution that works with ESXi but it was unclear on whether custom drivers were needed or if it would even work with newer versions of ESXi.

This topic has been popular amongst our customers who virtualize Apple MacOS on vSphere. In fact, several years back I had written an article on Thunderbolt Storage for ESXi, which includes a number of solutions that our customers have implemented to provide remote storage for their vSphere infrastructure running on either an Apple XServe, Mac Pro or Mac Mini. Questions around a functional Thunderbolt to 10GbE has definitely been asked about, but I had never heard from any customer who have had a successful story to share, at least until now.

From Karim's post, it looks like he was able to get this working using ESXi 6.0 but it was unclear if there was anything he needed to do to get the device recognized. I reached out to Karim and he was able to confirm that the Thunderbolt device was recognized by ESXi without any additional driver installation. In fact, if you look at this console output on his blog, you will see that it simply uses the inbox Intel ixgbe driver. I had also asked if Karim tried this with the latest version of ESXi, which is currently at 6.5 Update 1. Karim was kind enough to perform one additional test for me which was to confirm the device would still work with the latest ESXi release, which you can see for yourself in the screenshot below.

Identifying ESXi boot method & boot device

01/09/2018 by William Lam 6 Comments

There was an interesting discussion on our internal Socialcast platform last week on figuring out how an ESXi host is booted up whether it is from local device like a disk or USB device, Auto Deploy or even boot from SAN along with its respective boot device? Although I had answered the question, I was not confident that we actually had a reliable and programmatic method for identifying all the different ESXi boot methods, which of course piqued my interest.

With a bit of trial and error in the lab, I believe I have found a method in which we can identify the ESXi boot type (Local, Stateless, Stateless Caching, Stateful or Boot from SAN) along with some additional details pertaining to the boot device. To demonstrate this, I have created the following PowerCLI script ESXiBootDevice.ps1 which contains a function called Get-ESXiBootDevice.

The function can be called without any parameters, in which it will query all ESXi hosts for a given vCenter Server and/or standalone ESXi host. You can also specify a specific ESXi host by simply passing in the -VMHostname option.

Here is an example output for one of my lab environments which shows several ESXi hosts and their different boot methods from local disk to Auto Deploy which can include stateless, stateless caching and stateful deployments. Depending on the BootType, the boot device shown in the Device column will either be the MAC Address of the NIC used to network boot the ESXi host or the identifier of a disk device. I have also included some additional details such as vendor/model along with the media type (SAS, SSD or USB) which is available as part of ESXCLI.

This script also supports ESXi environments that boot from SAN (FC, FCoE or iSCSI) and you can easily identify that with the word "remote" for the BootType. I would like to give a huge thanks to David Stamen who helped me out with the boot from SAN testing.

ATTO’s ESXi Thunderbolt Driver is now officially on VMware HCL

08/22/2017 by William Lam 1 Comment

Last week I had received some great news from our friends over at ATTO Technology that their ESXi Thunderbolt to Fibre Channel Driver has passed the VMware Certification process and is now officially listed on VMware's HCL. I had known the team was planning to certify their driver but was not aware of their timelines and whether it would actually get accepted given the fact that this was for a Thunderbolt-based device, which is the first of its kind for the VMware HCL.

Funny enough, it was roughly around this time last year that ATTO released a Beta of their ESXi Thunderbolt to Fibre Channel Driver which I had shared with my readers here. I was not surprised by the demand given the fact that no official solutions exists for customers who would like to take advantage of their existing SAN-based storage infrastructure when virtualizing Apple macOS (iOS development, etc) on vSphere. ATTO has certified two of their ThunderLink devices, customers have the option of using either the TLFC2082 which provides 20Gb/s Thunderbolt 2 (2-port) to 8Gb/s FC (2-Port) Device or the TLFC2182 which provides 20Gb/s Thunderbolt 2 (2-port) to 16Gb/s FC (2-Port) Device which is supported from ESXi 5.5u3 all the way up to latest 6.5u1 release.

Click here for the direct link to VMware HCL.

Huge congrats to the ATTO team for getting this on the VMware HCL and partnering up with VMware to provide a solution for our customers who virtualize Apple macOS using vSphere!

Lastly, if you are going to be at VMworld and you are interested in learning more about this solution, be sure to drop by the ATTO booth.

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

08/02/2017 by William Lam 9 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.