I bought a refurbished HP EliteDesk 800 G6 Mini — i5-10500T, 6C/12T, 32 GB, $359 — to get one bare-metal ESXi host into a lab that was otherwise entirely nested. Budget for the install: an hour.
The ESXi installer's disk-selection screen showed exactly one device: the SanDisk USB stick I had booted from. The 512 GB NVMe that shipped inside the machine was not there. Total elapsed time from that screen to a working install was about 21 hours and 45 minutes, and the resolution was not a fix. It was a different drive.
The first theory was the obvious one, and it was wrong
The drive had Windows on it and showed up in the F9 UEFI boot menu, so the natural read was that the existing OS and partitions were in the way. Wipe the disk, and the installer will claim it.
That is backwards on its face — the installer will happily erase Windows itself if it can see the disk — but I chased it anyway, including an HP BIOS Secure Erase that completed in about five seconds because it is a cryptographic erase, not an overwrite. What actually settled it was one command in the installer shell:
esxcfg-scsidevs -aOne storage adapter: vmhba31 on vmkusb. The USB stick. ESXi could not see the storage controller at all, so the contents of the disk were irrelevant — there was nothing to wipe from. I could have zeroed that drive at 4pm and the installer would still have shown me nothing but the SanDisk. (Note for the installer environment: esxcli returns connection refused there because hostd is not running. Use localcli.)
An hour of checkbox roulette
Before I collected any hardware-level evidence I made three round trips into the BIOS on theories, flipping "Configure Storage Controller for RAID" on and off without once verifying its effect. The checkbox is a claim about ground truth. The controller's PCI device ID is ground truth.
vmkchdev -lIn RST mode the SATA controller at 0000:00:17.0 enumerated as 8086:06d6 with no vmhba name appended — present on the bus, claimed by no driver. The real tell was what was missing: no PCIe root ports anywhere in the list, and no NVMe device at all. The device list simply stopped at the chipset. In Intel RST mode the NVMe is pulled off its own PCIe root port and remapped behind the RST controller, which ESXi has no driver for.
That produced a falsifiable prediction. Uncheck both "Configure Storage Controller for RAID" and the Intel Optane equivalent, F10 save, and three things should change: 00:17.0 goes 06d6 to 06d2 and gains vmhba0, a PCIe root port appears at 00:1b.0, and the NVMe appears at 0000:01:00.0 as 1c5c:1339 claimed as vmhba1. All three hit.
Side effect, immediate and permanent: the preinstalled Windows bluescreened INACCESSIBLE_BOOT_DEVICE, because it had been installed expecting RST. That is the moment the machine stopped being returnable, and it happened before I had any idea what was actually wrong.
ESXi 8: controller present, status Offline
With the controller visible, the first attempt ran on an ESXi 8 ISO I already had — 8.0 U3 by the boot media, though I never printed the exact build. localcli nvme device list showed vmhba1 Offline. No namespace, no disk. vdq -q returned exactly one entry — mpx.vmhba32:C0:T0:L0, Size(MB) 58674 — the USB stick again.
Broadcom KB 416736 matched precisely: in ESXi 8.0 and earlier, Namespace Attribute Notices (AEC) is disabled by default, so the host never picks up the namespace. The KB's listed symptoms include the device being undetected after a rescan, the controller status showing offline, and the issue persisting even after formatting the device. I ran the documented workaround in full:
localcli nvme device namespace format -A vmhba1 -f 0 -n 1 -m 0 -p 0 -l 0 -s 0
localcli nvme device feature aec set -A vmhba1 -v 1
localcli storage core adapter rescan --allThe format returned "Format successfully, but failed to update namespace attributes". The AEC set returned "Feature set successfully!". After the rescan the controller was still Offline and vdq -q was byte-for-byte unchanged.
The KB's stated permanent resolution is to move to ESXi 9.x, where AEC is on by default. On ESXi 9.1.0 build-25370933 the controller came up Online. I did not isolate whether that was the AEC default specifically or just a newer NVMe stack, so treat the causal link as KB-consistent rather than proven. Either way it fixed the controller half and produced no disk.
The empty output that meant nothing
When I wrote the problem up properly, two lines of my own evidence read: localcli nvme namespace list returns no namespaces, localcli nvme controller list returns nothing. I had concluded the drive presented neither. Both commands were the wrong syntax. The subcommands live under device and want the adapter flag.
localcli nvme device namespace list -A vmhba1Namespace ID 1, Status Active. No Device Name. And the line above it: Unknown path vmhba1:C0:T0:L0.
That single output reframed the entire problem — not "the drive presents nothing" but "the drive presents a namespace ESXi refuses to name." An empty result from a bad invocation is indistinguishable from an empty result from a real absence, and I had spent hours treating one as the other.
The theory that cost the most
Pulling the namespace details showed Total NVM Capacity: 0x0 and Unallocated NVM Capacity: 0x0, with the namespace listed Active but with zero-looking geometry. I read those as literal truth and concluded that the Secure Erase plus the half-failed format had left the drive with a zero-capacity namespace. In other words, that my own troubleshooting had bricked it — on a machine I could no longer return, because I had already destroyed the Windows install.
I had flagged the caveat myself at the time: those fields are optional in the NVMe spec and plenty of client drives report zero because they do not implement them. Then I talked past my own caveat, because a drive I had broken was a more satisfying story than a spec-optional field.
An Ubuntu live USB, booted purely as a control test, settled it in one command. sudo nvme list showed /dev/nvme0n1 at 512.11 GB of 512.11 GB, namespace 0x1, 512 B format, firmware 11004101. Fully healthy, full capacity, nothing damaged. When a hypervisor and a general-purpose kernel disagree about a device, boot the kernel.
The actual root cause
sudo nvme id-ns /dev/nvme0n1 | grep -i -e nguid -e eui64Zeros. The Namespace Globally Unique Identifier and the IEEE Extended Unique Identifier are both all-zero on this drive. ESXi derives its storage device identity — the vml. identifier — from NGUID/EUI64. With no unique identifier to build from, it will not create the device, which is exactly what Unknown path vmhba1:C0:T0:L0 is telling you. Linux is indifferent; it just calls the thing /dev/nvme0n1 and moves on.
Broadcom KB 323065 documents the milder case, where EUI64 is blank but NGUID is populated:
Currently there is no resolution to the issue.
With both fields zero there is no fallback at all — no boot flag, no driver parameter, no BIOS setting. The BC511 is an OEM part that ships inside prebuilt machines, was never sold at retail, and was never validated against ESXi. It is not defective. It is simply unusable by ESXi on 8.x or 9.1, and remains perfectly good for Linux, Proxmox, or Windows.
The fix was free and took ten minutes
I was pricing $150–230 same-day NVMe drives three days before a flight, seriously considering a no-name "SIX X4000" listing, when the answer turned out to be sitting in another box. The 16 GB lab NUC had a Lexar NM620 256 GB in it — a retail drive with proper identifiers. The EliteDesk has an empty second M.2 2280 slot, silkscreened J40 SSD2. The ESXi 9.1 installer saw the Lexar on the first boot. Cost: $0. Downsides: the NUC is now driveless, and I am running a 256 GB host.
The purchasing lesson is narrower than "buy good drives." No-name and OEM drives are specifically the category that skips populating NGUID and EUI64, because nothing in their intended lifetime ever reads those fields. Paying for a brand with a track record buys known-good identifier metadata, not speed.
And then I fumbled the install anyway
systemMediaSize=small has to be typed at the installer's very first loader screen — Shift+O, append it to the boot line — and it cannot be changed afterward. I had it written down before the install and missed it during the install. Post-install df: VMFSOS (OSDATA) at 119.8 GB, datastore1 at 110.2 GB VMFS-6. On a 256 GB drive the system partitions are larger than the usable datastore.
Reinstalling while the host was still empty would have taken about ten minutes and reclaimed roughly 65 GB. I left it because it was late and the deadline was close. That call is already biting: the box's job is to host vCenter, and 110 GB of datastore is not much room for a VCSA.
What I never tested
- The community NVMe driver VIB. Floated several times, never installed. Once KB 323065 said there was no resolution I stopped rather than trying it, so I cannot tell you whether it helps.
- The BC511 in the second M.2 slot. It was a free test of slot-dependent enumeration and I never ran it — the Lexar went into that slot instead. So "the BC511 fails in both slots" is not something I have established.
- Whether the BC511 supports NVMe Namespace Management at all, which would open the door to deleting and recreating the namespace to force a real NGUID — I never captured the controller's OACS value to find out.
The drive is labeled ESXi-incompatible now, which is the honest end state: a healthy 512 GB part that one hypervisor will not touch because of a metadata field its firmware never bothered to write. The open question I would actually like answered is whether namespace management can mint an identifier the drive never had — and that is a test I can run on the BC511 any afternoon, since it has nothing left on it to lose.