Month: January 2025

How to Simulate Custom ESXi SMBIOS Hardware Strings (Vendor, Model, Serial) with ignoreHwSMBIOSInfo and vsish (Lab Only)

Override the vendor, model, serial and UUID ESXi reports using ignoreHwSMBIOSInfo and vsish dmiInfo. Works on physical and nested ESXi. Lab only.

Short answer: ESXi reads the hardware vendor, model, serial number and UUID from the firmware’s SMBIOS tables. In a lab you can override them in two steps. First, add ignoreHwSMBIOSInfo=TRUE to kernelopt in /bootbank/boot.cfg and reboot. Then write your own values to /hardware/bios/dmiInfo with vsish and restart hostd. This works on physical and nested ESXi, with BIOS or EFI firmware. It does not persist across reboots and is unsupported, so use it in labs only.

What SMBIOS strings ESXi shows, and why you would fake them

The Hardware panel in the Host Client and vCenter, esxcli hardware platform get, and the vSphere API all report what the firmware exposes through SMBIOS/DMI. Broadcom KB 384493 shows the two ways to read it:

esxcli hardware platform get

vsish -e get /hardware/bios/dmiInfo

In a homelab, whitebox or nested hosts show generic strings such as “VMware, Inc.” or “Default String”. Custom values are handy when you want to:

  • test scripts, reports or automation that branch on vendor or model
  • make nested hosts in a demo look like distinct physical servers, each with its own serial number
  • reproduce customer-side behaviour that depends on hardware identity

If your production hosts show “Default String” or a wrong serial, this is not the fix. KB 384493 says the firmware is supplying incomplete SMBIOS records and the vendor must provide a firmware update.

Step 1: tell ESXi to ignore the hardware SMBIOS

Append the kernel option to the existing kernelopt= line in /bootbank/boot.cfg. Keep what is already there, add a space, then the option. Reboot the host afterwards.

vi /bootbank/boot.cfg
# kernelopt=<existing options> ignoreHwSMBIOSInfo=TRUE
reboot

Broadcom documents two ways to pass boot options: edit the kernelopt line in boot.cfg, or type them after pressing Shift+O at the boot prompt (see About the boot.cfg File). Shift+O applies only to that one boot, so the boot.cfg edit is the practical choice here.

Step 2: set the custom dmiInfo with vsish

The dmiInfo node takes one structure. The field order is product name, vendor, serial number, UUID as a 16-element byte array, BIOS version string, a numeric field, SKU string and family string. The example below uses placeholder values:

vsish -e set /hardware/bios/dmiInfo {\"LAB-R650\", \"vDan Lab\", \"LAB-SN-0001\", [<16 UUID bytes>], \"1.0.0\", 6, \"SKU=LAB650\", \"vDanLab\"}

/etc/init.d/hostd restart

esxcli hardware platform get

The UUID must be written as 16 decimal byte values, and the byte order is easy to get wrong. William Lam’s post (linked below) includes a PowerShell function, Generate-CustomESXiSMBIOS, that takes UUID, model, vendor, serial, SKU and family and prints the full vsish command. Use it rather than converting the UUID by hand. After hostd restarts, the new strings show up in the Host Client, in vCenter and through the vSphere API.

Persistence and Secure Boot

The vsish change lives in memory, so the custom values are lost at every reboot and must be set again. You could re-apply it from /etc/rc.local.d/local.sh, which Broadcom KB 324525 documents for boot-time commands. Two limits apply. Commands must go before the exit 0 line, and the script does not run when UEFI Secure Boot is enabled. On Secure Boot hosts, re-run the command manually or from your lab automation after each boot.

Not the same as SMBIOS.reflectHost

SMBIOS.reflectHost is a VM setting (.vmx) that passes the physical host’s SMBIOS identity into a guest. KB 313985 covers it because it makes VMs report the host’s serial number. It copies real values and cannot invent new ones, so it cannot give each nested ESXi host its own identity. The ignoreHwSMBIOSInfo plus dmiInfo approach works inside ESXi itself, whether ESXi runs on metal or in a VM.

Support statement

Neither ignoreHwSMBIOSInfo nor writing to /hardware/bios/dmiInfo is documented by Broadcom as a supported configuration. Faking hardware identity on a production host can break hardware compatibility checks, vendor add-ons and support workflows. Use it only on lab hosts you can rebuild, such as a minimal VCF 9.0 lab. The esxcli command reference lists the related esxcli hardware namespaces.

Further reading

vRealize Events Missing After Patch or Version Upgrade

vRealize/vROps events stop arriving after a patch or upgrade with an authorization error. How to identify it and fix it by enabling basic authentication.

(Authorization Error on vRealize Host)

After applying a patch or performing a version upgrade of vRealize Operations, some customers notice that events stop appearing in ServiceNow, specifically in the em_event table.

At first glance, the integration looks healthy: the MID Server is up, credentials haven’t changed, and the connection test may even pass. Yet no new events are flowing.

This post explains why this happens, how to recognize it quickly, and how to fix it safely.

Symptoms

After upgrading vRealize Operations, you may observe:

  • No new events in ServiceNow (em_event)
  • Existing integrations appear configured correctly
  • No obvious UI errors in vRealize Operations

However, the vRealize MID Server logs reveal the real problem.

How to Identify the Issue

Worker-Interactive:ConnectorProbe-) [MIDSystem:35]
*** Script: vRealize Payload : Response Body of Resource Properties :
<head><title>Not Authorized</title></head>
<body>
We apologize. You are not authorized for the request
</body>

This message is the key indicator that authentication between ServiceNow and vRealize Operations is failing at the API level.

Root Cause

Starting with vRealize Operations 8.1 and later, Basic Authentication is required for API access used by the MID Server.

basicAuthentication.enabled=false

As a result:

  • The MID Server cannot authenticate
  • API calls return Not Authorized
  • Events silently stop flowing to ServiceNow

Resolution: Enable Basic Authentication (vROps 8.1+)

To restore event flow, Basic Authentication must be enabled on all nodes in the vRealize Operations cluster.

Step-by-step fix

  • Log in to the Primary Node of vRealize Operations
    (SSH or console, user: root)
  • Edit the API configuration file
/usr/lib/vmware-vcops/user/conf/api-conf.properties

Set Basic Authentication to enabled

basicAuthentication.enabled=true

Save and close the file

Restart the REST API service

service api restart

Repeat steps on all other nodes
(Replica, Data, and Remote Collector nodes)

Reference

This behavior and resolution are documented by Broadcom/VMware in the official KB:

How to Apply for the 2025 vExpert Program as a…

How to Apply for the 2025 vExpert Program as a…

Are you a VMTN Community Moderator? If so, you have a unique opportunity to join the prestigious vExpert Program for 2025. This program celebrates individuals who make outstanding contributions to VMware communities—and as a moderator, your role already puts you on the fast track to approval. […]

Broadcom Social Media Advocacy