HomeLab Updated Nov 4, 2026

William Lam’s ESXi Advanced and Kernel Settings: 21 Lab Recommendations with Explorer Links

27 min read
William Lam ESXi advanced settings: 21 lab recommendations with esxcli commands and explorer links

Short answer: this is a William Lam ESXi advanced settings cheat sheet: 21 lab-tested tweaks from his blog, most of them a single esxcli system settings advanced set or esxcli system settings kernel set line, from the 2026 VCF 9.1 workarounds (entropySources, LRO and TSO offload on Intel X710, nested vSAN on physical vSAN) back to the classics (FakeSCSIReservations, FollowHardwareMac, CMMDS.goto11). Each entry has the exact command as William gives it, the version it was written for, what has changed since, and a link to the ESXi Advanced and Kernel Settings Explorer for the default, the range and the history of the setting. Everything here is for labs and consumer hardware. None of it is supported by Broadcom, and William says so in every post.

I verified every command against the post it comes from on williamlam.com (formerly virtuallyghetto.com) on 3 November 2026. Where a command only appears in a reader comment, I say so. The explorer data itself comes from William’s esxi-advanced-and-kernel-settings repository, so the circle closes nicely: his defaults, his tweaks. Two conventions to keep in mind: the vSphere API and UI use the dotted key (Net.TcpipDefLROEnabled), esxcli the slash form (/Net/TcpipDefLROEnabled), and kernel settings (esxcli system settings kernel set) always need a reboot.

Table of Contents

William Lam ESXi advanced settings at a glance

SettingWilliam’s valueForExplorer
entropySources (kernel)2AMD Ryzen Zen 4/5, VCF 9.xopen
ignoreMsrFaults (kernel)TRUEIntel 13th gen hybrid CPUsopen
cpuUniformityHardCheckPanic (kernel)FALSEIntel 12th gen and neweropen
Net.TcpipDefLROEnabled0Intel X710, vSAN ESAopen
Net.UseHwTSO0Intel X710, vSAN ESAopen
MemoryTiering (kernel) + Mem.TierNvmePctTRUE, 25 to 400NVMe tiering, 8.0 U3 to 9.0open · open
SVGAScaling (kernel)2Small DCUI screensopen
Power.CpuPolicyHigh PerformanceAny hostopen
USB.quirksUQ_NET_IGNORE / UQ_MSC_NO_UNCLAIMUSB NIC and USB storage passthroughopen
ignoreHwSMBIOSInfo (kernel)TRUEFake vendor strings, VCF installeropen
UserVars.SuppressShellWarning, UserVars.SuppressCoredumpWarning1Kickstart, stateless hostsopen · open
VSAN.FakeSCSIReservations1Nested ESXi on vSANopen (hidden)
VSAN.GuestUnmap1Nested vSAN on physical vSAN OSAopen (hidden)
VSAN.Vsan2ZdomCompZstd0vSAN ESA on weak CPUs, VCF 9.1open (hidden, 9.1)
LSOM.VSANDeviceMonitoring, LSOM.lsomSlowDeviceUnmount, VSAN.SwapThickProvisionDisabled0, 0, 1Nested vSAN hostsopen · open · open (hidden)
Net.FollowHardwareMac1Cloning nested ESXi (legacy)open
CMMDS.goto111vSAN clusters over 16 nodes (legacy)open (hidden, to 6.5)
VSAN.AllowUsbDisks, Disk.AllowUsbClaimedAsSSD1USB disks in vSAN, ESXi-Arm witnessopen (hidden) · open
VisorFS.VisorFSPristineTardisk0 then 1esxcli MemoryError on 8.xopen (hidden)
Migrate.VMotionStreamDisable0Nested FT (legacy)to 7.0 U1
iovDisableIR (kernel)true2012 Mac mini (legacy)open

Settings marked hidden never appear in the esxcli system settings advanced list output that William’s repository, and therefore the explorer, is built from; list -o and set -o accept them by name. The explorer now carries them from William’s posts with a dashed hidden badge, an “Only: hidden” filter and a panel note that says which values are verified and which are not. The links open the setting on ESX 9.0.1; switch the release in the strip to see older defaults.

Physical hosts and consumer hardware

entropySources: slow entropy on AMD Ryzen Zen 4 and Zen 5

William’s most useful 2026 tweak. On a Minisforum MS-A2 with a Ryzen 9 7945HX, host CPU utilization climbed over time until it overran the host, and vmkernel.log filled with “Out of entropy” messages. VMkernel engineering measured RDSEED on Zen 4 at roughly 50 times slower than on Zen 3, and Zen 5 behaves the same. The fix from engineering is to move the ESX entropy source to RDRAND, which is value 2 of the entropySources bitmask. Source: Quick Tip: High CPU Utilization on ESX due to Slow Entropy from AMD Zen 4 CPUs (29 April 2026).

esxcli system settings kernel set -s entropySources -v 2
# reboot the host

In September 2026 he followed up for VCF 9.1.1: the remaining CPU load came from RDSEED calls out of guest workloads, so the second half of the fix masks the RDSEED CPUID bit for every VM on the host by appending a line to /etc/vmware/config. Source: VCF 9.1.1 – Reducing CPU Utilization on AMD Ryzen Zen4/Zen5 by Masking the RDSEED Instruction (7 September 2026).

echo 'cpuid.7.ebx = "-------------0------------------"' >> /etc/vmware/config
# reboot the host

Explorer: entropySources is a kernel setting since ESXi 8.0, default 0 (ESX picks the sources itself). The bitmask is 1 interrupts, 2 RDRAND, 4 RDSEED, 8 entropyd. Caveats: AMD Ryzen consumer CPUs only, it does not apply to Intel. In the VCF 9.1 workarounds William sets the nested ESX 9.1 VMs on such a host to -v 1 (interrupts) instead of 2. A BIOS update that AMD shipped for an RDSEED CVE does not help here, engineering still recommends the two lines above.

ignoreMsrFaults: PSOD “GP Exception 13” on Intel 13th gen

Raptor Lake CPUs with both P-cores and E-cores enabled can PSOD ESXi with “GP Exception 13 in world” the moment a VM powers on. ESXi does not support Intel’s hybrid architecture and William says there are no plans to. His option 1 is to disable the E-cores in the BIOS. Option 2, for boards that cannot, is to disable the uniformity check at install time (next section) and then tell the VMkernel to ignore the MSR faults. Source: ESXi PSOD due to GP Exception 13 in world with Intel 13th Generation CPU (22 April 2023, ESXi 8.0 U1).

esxcli system settings kernel set -s ignoreMsrFaults -v TRUE
# reboot the host; on a USB boot you can add ignoreMsrFaults=True to the kernel boot line instead

Explorer: ignoreMsrFaults, kernel setting since ESXi 6.5d, default FALSE, still present in ESX 9.0.1. Caveats: William does not run option 2 himself. He has seen enough quirks with both core types active and treats the BIOS route as the real fix. Readers on 8.0 U3 reported PSODs even with E-cores off until they also disabled SpeedStep, SpeedShift and C-states.

cpuUniformityHardCheckPanic: install on Intel 12th gen and newer

Same hybrid-CPU family, different stage. The installer PSODs with “Fatal CPU mismatch on feature” on Alder Lake and later because the P-cores and E-cores do not report the same feature set. William’s workaround from the Intel NUC 12 Pro post is a kernel boot option: press SHIFT+O at the installer boot screen and append cpuUniformityHardCheckPanic=FALSE to the existing kernel line, keeping what is already there. Source: ESXi on Intel NUC 12 Pro (Wall Street Canyon) (15 September 2022). His kickstart post makes it permanent on the installed system by editing the bootbank boot.cfg in %post. Source: Automated ESXi Installation with a USB Network Adapter using Kickstart (1 February 2023).

# installer: SHIFT+O, append to the kernel line
cpuUniformityHardCheckPanic=FALSE

# kickstart %post, only for Intel 12th gen or later hybrid CPUs
sed -i 's/autoPartition.*/autoPartition=FALSE cpuUniformityHardCheckPanic=FALSE/g' /vmfs/volumes/BOOTBANK1/boot.cfg

Explorer: cpuUniformityHardCheckPanic is a kernel setting since ESXi 7.0 U2, default TRUE. The explorer panel gives you the esxcli system settings kernel set form, which a reader of the NUC post used to persist it after install. Caveats: without the E-cores disabled in the BIOS, ESXi turns hyperthreading off. William’s preferred fix is still the BIOS.

Net.TcpipDefLROEnabled: hardware LRO on Intel X710 breaks vSAN ESA

On a three-node VCF 9.0 cluster of Minisforum MS-A2 boxes with Intel X710 10 GbE, vSAN ESA could not get past roughly 1 to 2 Gbps. William traced it to the X710’s hardware Large Receive Offload splitting jumbo packets across RX queues, which arrive out of order, cause retransmits and, in his view, trigger vSAN ESA’s adaptive traffic shaping. Disabling LRO removed the ceiling. Source: Maximizing vSAN ESA Performance on Minisforum MS-A2 (31 March 2026).

esxcli system settings advanced set -i 0 -o /Net/TcpipDefLROEnabled
esxcli system settings advanced list -o /Net/TcpipDefLROEnabled
# reboot the host

Explorer: Net.TcpipDefLROEnabled, advanced setting since ESXi 6.0 U3, default 1, range 0 to 1, esxcli can set it. Caveats: the MS-A2 is not on the Broadcom Compatibility Guide and William’s conclusion is that enterprise NICs do not need this. The VCF 9.1 workarounds repeat the setting for X710 hosts. A reader got about 7.6 times the IOPS by also maxing the RX ring buffers (esxcli network nic ring current set -r 4096 -t 4096 -n vmnic0, which William lists in the 9.1 post for the vSAN pNIC error-rate alarm).

Net.UseHwTSO: hardware TSO off on the same NICs

From the same MS-A2 post. The X710 has known LRO and TSO issues, so William disabled hardware TCP Segmentation Offload as well, “to be safe”. He measured no separate gain from this one; it rides along with the LRO change. Source: Maximizing vSAN ESA Performance on Minisforum MS-A2.

esxcli system settings advanced set -o /Net/UseHwTSO -i 0
esxcli system settings advanced list -o /Net/UseHwTSO
# reboot the host

Explorer: Net.UseHwTSO, since ESXi 6.0 U3, default 1. Caveats: software TSO costs CPU. On a NIC without the X710 bug, leave it at 1.

MemoryTiering and Mem.TierNvmePct: NVMe tiering on 8.0 U3 to 9.0

The post that made NVMe memory tiering a homelab topic. On vSphere 8.0 Update 3 (tech preview) William turned a 64 GB Intel NUC with a 1 TB NVMe into a 318 GB host with three commands: enable the kernel feature, dedicate the NVMe device as a tier device and set the tiering percentage relative to DRAM, then reboot. Source: NVMe Tiering in vSphere 8.0 Update 3 is a Homelab game changer! (5 August 2024).

esxcli system settings kernel set -s MemoryTiering -v TRUE
esxcli system tierdevice create -d /vmfs/devices/disks/t10.NVMe____Samsung_SSD_960_EVO_1TB_______________8AC1B17155382500
esxcli system tierdevice list
esxcli system settings advanced set -o /Mem/TierNvmePct -i 400
# reboot the host

Explorer: the kernel setting is listed as memoryTiering (since 8.0 U3, default FALSE). Mem.TierNvmePct is an advanced setting since 8.0 U3 with range 1 to 400; its default moved from 25 to 100 in ESX 9.0.0, which the history table in the explorer shows. Caveats: this is the legacy procedure. William’s own update says the three commands no longer enable tiering on VCF 9.1, where the new esxcli memtier namespace does it in one step without a reboot. The device must be empty and dedicated, the CPU needs vMMR on 8.0 U3 (check grep MemHwCounters /var/log/vmkernel.log, from his follow-up quick tip), and vSAN and tiering are exclusive on a host. His December 2024 recipe for sharing one NVMe between tiering, OSData and VMFS (post) uses the same two settings and, per his 2026 comment, also stops working on 9.1. The full 8.0 U3 to 9.1 picture including Mem.EncryptTierNvme is in my NVMe memory tiering post.

SVGAScaling: readable DCUI on a 1280×400 display

A niche one from the VCF 9.0 mini rack build. The 7-inch rack LCD runs at 1280×400, the DCUI picks its resolution dynamically and the ESX Shell output ends up compressed and unreadable. You cannot set a resolution, but you can scale the SVGA console down. Source: Scaling ESX DCUI & Console for Compressed Screen Resolution (23 October 2025).

esxcli system settings kernel set -s SVGAScaling -v 2
# reboot the host

Explorer: SVGAScaling, kernel setting since ESXi 6.5d, default 1 (“pixel scaling factor for SVGA console”). Caveats: none beyond the reboot. It only changes the console, not the host client.

Power.CpuPolicy: power management policy from the CLI

A 2012 post that William kept updating. Originally the only CLI way to set the host power policy was vsish -e set /power/currentPolicy 1 (1 High Performance, 2 Balanced, 3 Lower Power, 4 Custom), and that does not survive a reboot. In the January 2015 update, engineering confirmed that esxcli can write the hidden advanced setting /Power/CpuPolicy with the policy name as a string. Source: Configuring ESXi Power Management Policy Using the CLI (18 August 2012, updated 2014 and 2015).

esxcli system settings advanced set --option=/Power/CpuPolicy --string-value="High Performance"

Explorer: Power.CpuPolicy shows up in the esxcli list from ESXi 8.0 on (default Balanced, values High Performance, Balanced, Low Power, Custom); before that it was hidden, which is why the post calls the parameters hidden. Caveats: on ESXi 6.7 and later there is a first-class command, esxcli hardware power policy set --short-name static (static, dynamic, low, custom), which a reader added in the comments and which is the one I would use today. Readers reported the advanced-setting form not working on 6.5.

USB.quirks: keep ESXi away from a USB NIC or a USB disk

Two posts, one setting. Since vSphere 7.0 the inbox CDCE driver claims supported USB network adapters, which is great for a VMkernel uplink and a problem when you want to pass the adapter through to a VM. The quirk UQ_NET_IGNORE tells ESXi to leave a given vendor and product ID alone. Find the IDs with esxcli hardware usb passthrough device list. Source: How to enable passthrough for USB Network Adapters claimed by ESXi CDCE Driver? (30 March 2023, ESXi 7.0 and 8.0).

# Realtek RTL8153 example; format 0x<VendorId>:0x<ProductId>:0:0xffff:<FLAG>
esxcli system settings advanced set -o /USB/quirks -s 0x0bda:0x8153:0:0xffff:UQ_NET_IGNORE
# reboot the host

The opposite case is a USB disk you want ESXi itself to keep, for example as a datastore, while the USB arbitrator still passes other devices through to VMs. The flag is UQ_MSC_NO_UNCLAIM. Source: Disable passthrough for specific USB devices for use with ESXi (27 May 2021).

esxcli system settings advanced set -o /USB/quirks -s 0x090c:0x2000:0:0xffff:UQ_MSC_NO_UNCLAIM
# reboot the host

Explorer: USB.quirks, a string setting since ESXi 6.7, empty by default, “additional USB device quirks to be added to the vmkusb native driver default quirks”. Caveats: the 2021 post offers esxcli hardware usb passthrough device disable -d <bus:dev:vendor:product> as option 1 where the build has it; the quirk is the fallback. Readers saw the passthrough state flip back after reboots when the bus number changed, and several comments on the 2023 post report adapters that still would not pass through. Not a guaranteed fix.

ignoreHwSMBIOSInfo: fake the server vendor for the VCF installer

The VCF 9.0 installer refuses hosts from mixed hardware vendors in a vLCM cluster, and nested ESXi reports “VMware, Inc.” as its vendor. William’s older trick patched the VM’s ROM file and only worked with BIOS firmware. The 2025 method is a kernel option that makes ESXi ignore the hardware SMBIOS data, after which a generated vsish command writes any vendor, model, serial and UUID you like. Source: Easier method to simulate custom ESXi SMBIOS hardware strings (6 January 2025).

# append to the kernelopt line of /bootbank/boot.cfg, then reboot
ignoreHwSMBIOSInfo=TRUE

# after the reboot: vsish -e set /hardware/bios/dmiInfo { ... } generated by Generate-CustomESXiSMBIOS, then
/etc/init.d/hostd restart

Explorer: ignoreHwSMBIOSInfo, kernel setting since ESXi 6.7, default FALSE, so esxcli system settings kernel set -s ignoreHwSMBIOSInfo -v TRUE is the equivalent of the boot.cfg edit. Caveats: the vsish part is not persisted; you re-run it after every reboot (a reader puts it in /etc/rc.local.d/local.sh), and it does not work with UEFI Secure Boot. I walked through the whole procedure, PowerShell function included, in How to Simulate Custom ESXi SMBIOS Hardware Strings.

UserVars.SuppressShellWarning and SuppressCoredumpWarning: quiet lab hosts

Not a performance tweak, but the two lines that appear in almost every kickstart and first-boot script William publishes. They hide the yellow “SSH is enabled” and “no coredump target” banners in the vSphere UI. Sources: the extra-config script in Stateless ESXi-Arm with Raspberry Pi (3 November 2020), the %firstboot section of Automated ESXi Installation with a USB Network Adapter using Kickstart (1 February 2023) and the kickstart in How to prevent physical CD-ROM from ejecting after installing or upgrading ESXi? (15 July 2019).

esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1
esxcli system settings advanced set -o /UserVars/SuppressCoredumpWarning -i 1

Explorer: UserVars.SuppressShellWarning and UserVars.SuppressCoredumpWarning, both since ESXi 6.0 U3, default 0, no reboot. Caveats: cosmetic. The shell warning exists for a reason on anything that is not a lab; pair the first one with UserVars.ESXiShellTimeOut (see ESXi Shell Commands You Actually Use).

Nested ESXi and vSAN labs

VSAN.FakeSCSIReservations: nested ESXi on a vSAN datastore

The classic. Installing nested ESXi onto a VMDK that lives on a vSAN datastore failed with “Could not format a vmfs volume” because the VMFS LVM layer wants a SCSI-2 reservation that vSAN does not provide. The workaround, applied on every physical host of the vSAN cluster, makes vSAN pretend. Source: How to run Nested ESXi on top of a VSAN datastore? (7 November 2013, vSphere 5.5). Thirteen years later it is still item 8 of the physical-host list in VCF 9.1 – Comprehensive ESX Configuration Workarounds for Lab Deployments (11 May 2026).

esxcli system settings advanced set -o /VSAN/FakeSCSIReservations -i 1
# no reboot needed; 0 reverts

Explorer: VSAN.FakeSCSIReservations, a hidden vSAN option (default 0, range 0 to 1, older than the explorer’s first release); it never appears in the plain advanced list, which is why William’s per-release tables lack it. Caveats: run it on all hosts of the cluster, not only on the one the nested VM happens to sit on. VMware Cloud on AWS blocks it.

VSAN.GuestUnmap: TRIM and UNMAP from nested vSAN to physical vSAN OSA

Physical vSAN OSA kept growing under nested vSAN OSA and ESA workloads even after the nested clusters freed space, because the TRIM/UNMAP requests from the nested layer were not passed down. Enabling guest UNMAP on the physical OSA hosts fixes the reclamation. Physical vSAN ESA already has it on by default. Source: Enable TRIM/UNMAP from Nested vSAN OSA/ESA to physical vSAN OSA (10 March 2025), repeated in the VCF 9.1 workarounds.

esxcli system settings advanced set -o /VSAN/GuestUnmap -i 1
# PowerCLI for the whole cluster
Get-VMHost | Get-AdvancedSetting -Name VSAN.GuestUnmap | Set-AdvancedSetting -Value 1 -Confirm:$false

Explorer: VSAN.GuestUnmap, hidden, default 0, shown from ESXi 6.7 U1 when vSAN gained UNMAP support. Caveats: no host reboot, but every nested ESXi VM and vSAN workload has to be power cycled before the change takes effect. Only for a physical OSA cluster.

VSAN.Vsan2ZdomCompZstd: back to LZ4 compression on weak CPUs

VCF 9.1 changed the default vSAN ESA compression algorithm from LZ4 to Zstd. Zstd compresses better and costs more CPU, which a mini PC lab does not have to spare. William lists the switch back to LZ4 for both the physical and the nested ESX 9.1 hosts. Source: VCF 9.1 – Comprehensive ESX Configuration Workarounds for Lab Deployments (11 May 2026).

esxcli system settings advanced set -o /VSAN/Vsan2ZdomCompZstd -i 0
# no reboot needed

Explorer: VSAN.Vsan2ZdomCompZstd, hidden and ESX 9.1 only, so it has a page but no release history: the explorer’s release list ends at 9.0.1. Caveats: ESX 9.1 only, and only when CPU is the bottleneck.

LSOM.VSANDeviceMonitoring, LSOM.lsomSlowDeviceUnmount, VSAN.SwapThickProvisionDisabled: nested vSAN hosts

Three settings William applies inside every nested ESX host that runs vSAN. The first two stop vSAN from monitoring and unmounting the virtual disks it considers slow, which a nested lab on consumer SSDs triggers all the time. The third lets the VM swap object be thin instead of thick, so a nested cluster does not reserve memory-sized swap for every VM. His Nested ESXi Virtual Appliance already ships with them; set them by hand on a plain install. Source: “Nested ESX 9.1 Host, vSAN Optimizations” in VCF 9.1 – Comprehensive ESX Configuration Workarounds for Lab Deployments.

esxcli system settings advanced set -o /LSOM/VSANDeviceMonitoring -i 0
esxcli system settings advanced set -o /LSOM/lsomSlowDeviceUnmount -i 0
esxcli system settings advanced set -o /VSAN/SwapThickProvisionDisabled -i 1

Explorer: LSOM.VSANDeviceMonitoring and LSOM.lsomSlowDeviceUnmount are hidden options (default 1). VSAN.SwapThickProvisionDisabled is visible in the list from ESXi 6.5d to 6.7 U2 (default 0 in 6.5, 1 in 6.7) and marked hidden from 7.0 on, where esxcli still accepts it, as the 9.1 post shows. Caveats: nested hosts only. On a physical vSAN host, device monitoring is there to protect your data.

Net.FollowHardwareMac: cloning a nested ESXi VM (legacy)

A cloned nested ESXi VM gets new virtual NIC MAC addresses, but the VMkernel ports inside still carry the MAC of the original, so two hosts answer for the same address. Setting this before the clone makes vmk0 follow the hardware MAC. The same post removes the system UUID from esx.conf and resignatures the local VMFS after the clone. Source: How to properly clone a Nested ESXi VM? (6 December 2013, ESXi 5.x and 6.x).

esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1
sed -i 's#/system/uuid.*##' /etc/vmware/esx.conf
/sbin/auto-backup.sh

Explorer: Net.FollowHardwareMac, since ESXi 6.0 U3, default 0, still in ESX 9.0.1. Caveats: William added a warning in July 2021: from ESXi 7.0 Update 2 on, cloning an ESXi boot volume, nested or physical, is no longer safe and can corrupt data (KB 84280 and KB 84349). Treat the clone workflow as legacy and deploy nested hosts from his OVA or a kickstart instead. The setting itself is harmless and still useful when the virtual NIC of a nested host is replaced. Readers noted it only updates the management vmk, not vMotion or NFS ports.

CMMDS.goto11: vSAN clusters with more than 16 nodes (legacy)

vSAN 5.5 could grow to 32 nodes, but only after an advanced setting that is off by default to save memory (under 150 MB per host). William confirmed with engineering that it has to be set on every host in the cluster, not just the new ones, which the original KB 2073930 left unclear. Source: Required ESXi advanced setting to support 16+ node VSAN Cluster (13 March 2014, updated 2017 for 5.5, 6.0 and 6.5).

esxcli system settings advanced list -o /CMMDS/goto11
esxcli system settings advanced set -o /CMMDS/goto11 -i 1
# reboot every host

Explorer: CMMDS.goto11, hidden, shown for ESXi 6.0 U3 to 6.5 U2. Caveats: legacy. Modern vSAN scales to 64 nodes without it, and the vSAN health check tells you when a large-cluster setting is missing. Included because the name is unforgettable.

VSAN.AllowUsbDisks and Disk.AllowUsbClaimedAsSSD: USB disks in vSAN

Intel NUC and Mac mini labs had two disk slots, so William let vSAN 6.0 claim USB-attached disks for capacity. It takes the USB arbitrator out of the way and sets a hidden vSAN option. Source: Home Labs made easier with VSAN 6.0 + USB Disks (4 March 2015). The same pair, plus Disk.AllowUsbClaimedAsSSD so a USB stick can be tagged as flash, turns a Raspberry Pi 4 on the ESXi-Arm Fling into a two-node vSAN witness. Source: vSAN Witness using Raspberry Pi 4 & ESXi-Arm Fling (8 October 2020).

/etc/init.d/usbarbitrator stop
chkconfig usbarbitrator off
esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1
esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1
vdq -q

Explorer: VSAN.AllowUsbDisks is a hidden option, default 0. Disk.AllowUsbClaimedAsSSD is, since ESXi 6.5d, default 0, “permit claim rules to mark USB disks as SSD”. Caveats: William says in both posts that this is not supported and not for evaluating vSAN performance. The Raspberry Pi witness broke on later ESXi-Arm builds with a ManagedObjectNotFound error. With NVMe everywhere today, this is history, but the Disk.AllowUsbClaimedAsSSD trick still helps when a USB SSD refuses to show as flash.

Housekeeping and legacy tweaks

VisorFS.VisorFSPristineTardisk: esxcli MemoryError on ESXi 8.x

Listing image profiles from the online depot with esxcli on ESXi 8.x can end in “MemoryError” or “Got no data from process”, because the esxcli software plugin has a fixed 300 MB memory limit and the depot metadata outgrew it. William’s unsupported workaround edits the limit in the esxcli-software binary, and because the file lives on a pristine tardisk, the advanced setting has to be flipped off and on around the edit. Source: Quick Tip – Using ESXCLI to upgrade ESXi 8.x throws MemoryError or Got no data from process (4 March 2024, tested on 8.0 U2).

esxcli system settings advanced set -o /VisorFS/VisorFSPristineTardisk -i 0
cp /usr/lib/vmware/esxcli-software /usr/lib/vmware/esxcli-software.bak
sed -i 's/mem=300/mem=500/g' /usr/lib/vmware/esxcli-software.bak
mv /usr/lib/vmware/esxcli-software.bak /usr/lib/vmware/esxcli-software -f
esxcli system settings advanced set -o /VisorFS/VisorFSPristineTardisk -i 1

Explorer: VisorFS.VisorFSPristineTardisk, hidden, default 1, shown from ESXi 8.0. Caveats: the supported answers are vCenter or an offline bundle ZIP. The edit does not survive a reboot according to readers, the mv -f leaves no untouched backup, and a Dell image needed 700 MB. On ESX 9 use esxcli software component with an offline depot, see ESXi Shell Commands You Actually Use.

Migrate.VMotionStreamDisable: nested Fault Tolerance (legacy)

From the vSphere 5 beta days: enabling FT on a VM inside a nested ESXi host needed vMotion streams turned off on the nested host, plus three replay.* lines in the protected VM’s VMX. William shows both the esxcli and the esxcfg-advcfg form. Source: How to Enable Nested vFT (virtual Fault Tolerance) in vSphere 5 (31 July 2011).

esxcli system settings advanced set -o /Migrate/VMotionStreamDisable -i 0
esxcfg-advcfg -s 0 /Migrate/VMotionStreamDisable

Explorer: Migrate.VMotionStreamDisable exists in the list from ESXi 6.0 U3 to 7.0 U1 (default 0, “pretend to not support streams”) and is gone from 7.0 U2 on, which the Compare view shows. Caveats: legacy on both counts. FT has been based on checkpointing since vSphere 6.0, so the replay lines mean nothing today, and 0 has been the default all along. Keep it for the archaeology.

iovDisableIR: PSOD on the 2012 Mac mini (legacy)

ESXi 5.0 and 5.1 PSODed on the 2012 Mac mini 6,2 until interrupt remapping in the IOMMU was disabled. William’s recipe: add iovDisableIR=true with SHIFT+O at every boot until the host is up, then make it stick. Source: Running ESXi 5.0 & 5.1 on 2012 Mac Mini 6,2 (4 December 2012).

esxcli system settings kernel set -s iovDisableIR -v true
# reboot the host

Explorer: iovDisableIR tells the story better than the post: default TRUE in ESXi 6.0 U3, FALSE from 6.5d on, still present in ESX 9.0.1. Caveats: the setting is the standard answer in several Broadcom KBs for interrupt-remapping PSODs on specific chipsets, so it is not dead, but the Mac mini use case is. Interrupt remapping off also means no VT-d passthrough on that host.

Not advanced settings, but from the same posts

Several of William’s lab fixes live next to the advanced settings but are configured elsewhere. They belong on the same checklist:

  • Host-wide VM config in /etc/vmware/config (AMD Ryzen, VCF 9.x): monitor_control.disable_apichv ="TRUE" so VMs boot with NVMe tiering enabled (NVMe Tiering with AMD Ryzen CPU workaround for VCF 9.0, 19 June 2025), and cpuid.brandstring = "AMD EPYC Ryzen 9 7945HX" so NSX Edge and VNA pass their DPDK check (VCF 9.1 workarounds).
  • VM setting sched.mem.enableNestedTiering = true: lets a nested ESX 9.1 VM benefit from the physical host’s NVMe tiering. On VCF 9.0 nested ESXi would not even power on with tiering enabled (NVMe Tiering with Nested Virtualization in VCF 9.0, 20 June 2025); 9.1 fixed that.
  • Module parameter for USB NIC only hosts: esxcli system module parameters set -p "usbBusFullScanOnBootEnabled=1" -m vmkusb_nic_fling makes the vusb0 uplink binding survive reboots since ESXi 7.0 U2 (ESXi 7.0 Update 2 enhancement for USB NIC only installations, 16 March 2021).
  • Installer boot option allowLegacyCPU=true and the kickstart flags --ignoreprereqwarnings --ignoreprereqerrors for deprecated CPUs on ESXi 8.0 (Quick Tip – Automating ESXi 8.0 install using allowLegacyCPU=true, 17 October 2022). 8.0 U2 and later need XSAVE regardless.
  • NIC ring buffers: esxcli network nic ring current set -r 4096 -t 4096 -n vmnic0 against the vSAN “high pNIC error rate” alarm on nested 9.1 hosts (VCF 9.1 workarounds).
  • execInstalledOnly: the one not to touch. Readers keep posting esxcli system settings advanced set -o /User/execInstalledOnly -i 0 under William’s iperf and rsync posts to run unsigned binaries (the explorer lists it as the hidden User.execInstalledOnly). His own 2022 update to Quick Tip – iPerf now available on ESXi says you do not have to lower that setting on 7.0 U3 and later, because /usr/lib/vmware/vsan/bin/iperf3 runs as is. ESX 9.0 flipped the default of VMkernel.Boot.execInstalledOnly to True, which the explorer marks as a changed default. Leave it.

How to check these on your host

Read a single advanced setting with its default, min and max, list everything that differs from the defaults, and read a kernel setting (kernel settings show the configured and the runtime value, so you can see whether the reboot has happened):

esxcli system settings advanced list -o /Net/TcpipDefLROEnabled
esxcli system settings advanced list --delta
esxcli system settings kernel list -o entropySources
esxcli system settings kernel list | grep -E 'entropySources|ignoreMsrFaults|cpuUniformityHardCheckPanic|memoryTiering'

The same from PowerCLI, for a whole cluster:

Get-Cluster lab | Get-VMHost | Get-AdvancedSetting -Name Net.TcpipDefLROEnabled,Net.UseHwTSO,VSAN.FakeSCSIReservations | Select Entity,Name,Value
$esxcli = Get-EsxCli -VMHost esx01 -V2
$esxcli.system.settings.kernel.list.Invoke() | Where-Object { $_.Name -in 'entropySources','ignoreMsrFaults' }

Hidden settings like VSAN.FakeSCSIReservations do not show up in advanced list or --delta, but Get-AdvancedSetting -Name and esxcli system settings advanced list -o /VSAN/FakeSCSIReservations return them by name, and the explorer now lists them with a hidden badge. For the visible ones it gives you the shipped default of every release from 6.0 U3 to 9.0.1, so you know what “back to default” means on your build, and the Compare view shows which of these settings a release added, removed or re-defaulted. If your host runs anything that is not a lab, the right value of every setting in this post is the default.

Frequently asked questions

Are William Lam’s ESXi advanced settings supported by Broadcom?

No. Every setting in this post comes from a lab or homelab post, and William says so in each of them. On a production host the right value is the default; use these on hosts you can rebuild.

Which of these ESXi settings still apply to ESX 9 and VCF 9.1?

entropySources on AMD Ryzen, the LRO and TSO offload switches on Intel X710, VSAN.FakeSCSIReservations and VSAN.GuestUnmap for nested vSAN, VSAN.Vsan2ZdomCompZstd, USB.quirks, ignoreHwSMBIOSInfo and SVGAScaling. NVMe tiering moved to esxcli memtier in 9.1; CMMDS.goto11, Migrate.VMotionStreamDisable, the Mac mini iovDisableIR and the FollowHardwareMac clone workflow are legacy.

Why does esxcli system settings advanced list not show FakeSCSIReservations or GuestUnmap?

They are hidden options. The plain list omits them, so they are also missing from William Lam’s per-release tables; list -o /VSAN/FakeSCSIReservations and set -o accept them by name, and the vDan explorer marks them with a hidden badge.

Do ESXi kernel settings need a reboot?

Yes. Everything set with esxcli system settings kernel set, such as entropySources, ignoreMsrFaults or SVGAScaling, takes effect after a reboot. Most advanced settings apply at once; the post says when one needs a reboot, for example the LRO and TSO switches.

Sources

Daniel Micanek

Senior Service Architect, SAP/TDL Platform Services Team at Vivicta | vExpert ⭐⭐⭐⭐⭐⭐⭐ | Broadcom Knight: vSphere Kubernetes Service, VCF Networking (NSX), VCF Automation | Broadcom Software Knight: vSphere | Cisco Champion. Notes from running about 1,000 ESXi hosts on Cisco UCS, VCF 9 and SAP HANA on vSphere.