ESXi Build Number without vCenter

原文：ESXi Build Number without vCenter — theDXT (Daniel Keer)

Knowing your ESXi Build Number can be very useful. It’s really easy to do with vCenter.Without vCenter it’s not as straight forward. Here are a few ways to get your build number when you don’t have vCenter.

Console

If you have access to the console of the ESXi host via IPMI or iLO or iDRAC or physical access, you can get your ESXi build number right from there, you don’t even need to login.

You can also get your ESXi build number right from the Help menu in the Web UI.

• Login to the Web UI of your ESXi host
• Click on Help > About

You will now get a screen that show you your ESXi build number.

It should look something like this

In this example we know that my ESXi build number is 19482537.

SSH

• Enable SSH on your ESXi Host by right clicking on the host and selecting Services > Enable Secure Shell

• Login to your ESXi host with SSH
• Enter the following command vmware -v

You will get an output that looks something like this

VMware ESXi 7.0.3 build-19482537

In this example we know that my ESXi build number is 19482537.

ESXi Config Backup File

You can also get your ESXi build number from an ESXi config backup file, which can be helpful if you want to know which ESXi build number was installed when a backup was taken.

To do this we will need something that can open a tgz archive. I like to use 7-Zip.

• Open your ESXi config backup file

In your ESXi config backup file there will be another tgz archive with the same name

• Open the second tgz archive in your ESXi config backup file
• Go into the folder named .
• Open the file named Manifest.txt

The contents of Manifest.txt should look something like this

RELEASELEVEL=VMware ESXi 7.0 Update 3BUILDNUMBER=21313628UUID=30393157-3496-5155-4595-31374D36514AKERNELOPTS=autoPartition=FALSEUSEROPTS=

In this example we know that my ESXi build number is 21313628.

If you want to know how to take an ESXi Config Backup you can read about it here (https://thedxt.ca/2021/01/esxi-config-backup/)

Build Number to Release Name

With our build number we can translate it over to a release name.

The VMware document called Build numbers and versions of VMware ESXi/ESX (2143832) has everything we need to convert the build number to a release name.

If we use the build number from the SSH example we know that build number 19482537 means that the release name is ESXi 7.0 Update 3d.

If we use the build number from the ESXi config backup file example we know that the release name for build number 21313628 is ESXi 7.0 Update 3k.

Why the Build Number Is the Number That Matters

Vendors, security advisories and the Broadcom support portal all key off the build number rather than the marketing version. Two hosts can both report "ESXi 7.0 Update 3" and still sit on completely different patch levels - one vulnerable, one patched - because the update number alone does not identify a specific build. Whenever you open a support case, check whether a VMSA security advisory applies, or confirm that a host is running a supported build, the build number is the unique identifier you need.

ESXCLI and vim-cmd from the Host

If you can log in to the host - over SSH, or through the DCUI troubleshooting options and the ESXi Shell - the host itself will tell you exactly what it is running. Several commands return the same information in different formats:

vmware -v                    # VMware ESXi 7.0.3 build-19482537
esxcli system version get    # Version, Build, Update, Patch level
vim-cmd hostsvc/hostsummary  # full host summary incl. build and UUID
uname -a                     # kernel build, includes the build number

esxcli system version get is the most complete: it prints the version, the build, the update number and the patch level as separate fields, which makes the output easy to paste into a spreadsheet. vim-cmd hostsvc/hostsummary is valuable because it returns the host UUID alongside the build, and that UUID is the value you cross-reference against a configuration backup or a support bundle when matching records across systems.

Build Number from the Host Client and the API

You do not need the thick client or vCenter to read the build from a browser. Point a browser at the host's management IP and log in to the Host Client; the build number appears on the host's summary and under Help > About, exactly as shown in the Web UI method above. If you are scripting without PowerCLI, the host's own SOAP API exposes the same data - the HostSystem managed object carries config.product.build and config.product.fullName - which is the layer PowerCLI wraps underneath. That makes the API the right entry point when you are building your own inventory tooling and do not want to take a dependency on a specific PowerCLI version.

Build Number vs Release Name vs Patch Level

Three labels describe the same host, and confusing them causes real mistakes:

• Version - the marketing release, for example ESXi 7.0 or ESXi 8.0.
• Update - a cumulative update within that release, for example Update 3.
• Build number - the unique numeric identifier of the exact ISO and patch set that was installed.

Beneath those sit the patch level and the individual VIB versions. When an advisory says "fixed in build 21930508", no amount of "we are on Update 3" answers the question; only the build number does. This is the single strongest reason to record builds rather than version labels in your inventory.

Translating a Build Number to a Release Name

Once you have the build number you can name the release. Broadcom Knowledge Base article 2143832, "Build numbers and versions of VMware ESXi/ESX", maps every build to its release name and is kept current for both ESXi 7 and ESXi 8. The lookup also works in reverse: start from the release you intend to standardise on, read off its build number, and compare that against what each host reports. That is why specific numbers such as 19482537 for ESXi 7.0 Update 3d and 21313628 for ESXi 7.0 Update 3k appear in the examples above - each one is a single point in the build table, not a range.

Common ESXi Build Numbers

The table below lists a handful of reference points; always confirm against the live KB before relying on any number for compliance work.

Which Method Should You Use?

Collecting Build Numbers Across Many Hosts

On a single host, reading the build is a one-line command. Across a fleet the goal is a list you can diff against an approved baseline. Where vCenter is available, PowerCLI makes this trivial; where it is not, an SSH loop over the host list does the job just as well:

foreach ($h in (Get-Content hosts.txt)) {
  $v = (Get-EsxCli -VMHost $h -V2).system.version.get().Version
  "$h `t $v"
}
# without vCenter, over SSH:
while read h; do
  printf "%s\t" "$h"
  ssh -o BatchMode=yes root@"$h" "vmware -v"
done < hosts.txt

Export the result to CSV, keep it under version control, and re-run it after every patch window. The diff between two runs is your proof of what changed and when, and it surfaces the host that quietly missed an update - the one that always turns up in an audit.

Troubleshooting: When the Numbers Do Not Match

If the DCUI banner and vmware -v disagree, trust the logged-in command output: the console banner reflects the build the host booted from, while the running system reflects what was actually applied. A build number read from a configuration backup's Manifest.txt describes the host at the moment that backup was taken, not today, so always note the backup date beside it. And if a host reports a build you do not recognise after an upgrade, check whether the update installed a new image but has not been booted into it yet - pending updates only take effect after a reboot, and a host can sit in that state until someone notices.

Reading the Build Number from a Support Bundle

When a host is unreachable over the network, or you are working an escalated support case, a vm-support bundle carries the same information. The bundle's commands/ folder contains the captured output of the version commands, and the bundle manifest records the build the bundle was generated against. This is also the exact format Broadcom support asks for, so knowing that the build number lives in a predictable place inside the bundle saves a round trip when a case is already open.

Why Inventory Drift Happens

Build drift is rarely a deliberate decision; it accumulates. A single host gets emergency-patched during an incident, a new host is commissioned from an older ISO left on a USB stick, an upgrade is rolled back on one node and never reapplied, or a cluster is expanded by a vendor engineer who installs whatever image they have to hand. None of these events shows up in a version-centric report. A build-centric inventory, refreshed after each change window, is the only reliable way to spot drift before it becomes a support or compliance problem - and it is the reason build numbers belong in your CMDB next to serial numbers and firmware levels.

Related Reading on This Site

The build number also appears inside every ESXi configuration backup, so our vCenter ESXi config backup script is the natural companion to this article. If a restore is what led you here, see the ESXi config restore bug write-up for the pitfalls to avoid.

That’s all it takes to figure out your Build Number without vCenter and how to figure out your release name from a build number.