Short answer: The VCF 9.0 Installer runs two vSAN ESA checks: the disks must be on the vSAN ESA HCL, and its local vSAN HCL database must be less than 90 days old. The second check has a supported fix: drop a fresh all.json into /nfs/vmware/vcf/nfs-mount/vsan-hcl/ (Broadcom KB 412606). Getting past the first check on non-certified disks takes a community mock VIB. That is unsupported and for labs only.
The two vSAN ESA HCL checks that block the VCF 9.0 Installer
| Check | What fails | Supported fix? |
|---|---|---|
| vSAN HCL database age | The Installer’s bundled all.json is more than 90 days old and cannot be refreshed, typically in an offline depot setup. It surfaces as No vSAN ESA certified disks found on the ESXi Host. | Yes: manual HCL DB update (KB 412606) |
| Disk certification | The NVMe devices are not on the vSAN ESA list in the Broadcom Compatibility Guide | No: use certified devices. In a lab, a mock VIB makes the host report ESA-eligible disks. |
Both failures show the same message, so check the date of the HCL database first. It is the cheap fix, and it is supported. For the other checks VCF 9 runs on hardware (server model, CPU generation, deprecated devices), see How to check VCF 9 hardware compatibility.
Fix 1 (supported): update the vSAN HCL DB on the VCF Installer
Procedure from Broadcom KB 412606. An Installer with an online depot downloads the file by itself, so this is only needed offline.
- On a machine with internet access, download
https://vvs.broadcom.com/service/vsan/all.json. - Copy it to
/nfs/vmware/vcf/nfs-mount/on the VCF Installer appliance, for example with SCP. - SSH in, switch to root, move the file and fix ownership as shown below.
- In the Installer UI, click Re-run Validations.
# mv /nfs/vmware/vcf/nfs-mount/all.json /nfs/vmware/vcf/nfs-mount/vsan-hcl
# chown vcf_lcm:vcf /nfs/vmware/vcf/nfs-mount/vsan-hcl/all.json
After deployment, vCenter has the same kind of check: Skyline Health “vSAN HCL DB up-to-date” warns at 90 days and errors at 180 days. On an air-gapped cluster, upload the same all.json with Update From File (KB 327011).
Fix 2 (lab only, unsupported): non-HCL disks
If the disks are simply not ESA-certified, which is typical for consumer NVMe in homelab boxes, no supported option exists. William Lam publishes a vSAN ESA Hardware Mock VIB for VCF 5.x and 9.0. You install it on each physical ESXi host, restart the vSAN management service and re-run validation. The Installer then accepts the disks.
Be clear about what this means:
- Broadcom does not support it. Do not use it on anything that runs production workloads or anything you might open a support case for.
- It only bypasses the compatibility check. It does not make the hardware any more suitable for ESA.
- SDDC Manager may run HCL checks again later, for example when you commission hosts, so keep the VIB on hosts you add.
Lam’s post also shows an alternative for the 90-day check: edit the timestamp and jsonUpdatedTime fields inside all.json. It is not needed when you can download a current file, and a real update is always the better choice.
Which to use
| Environment | Recommendation |
|---|---|
| Production, certified NVMe, offline depot | Fix 1 only |
| Production, non-certified disks | Replace the disks, or use vSAN OSA or external storage, based on the Broadcom Compatibility Guide |
| Homelab / nested / PoC | Fix 1, plus the mock VIB where needed |
For a complete small-footprint build that uses these steps, see Deploying a minimal VCF 9.0 lab: insights from Explore 2025.
Further reading
- William Lam: vSAN ESA Disk & HCL Workaround for VCF 9.0 (original post)
- Broadcom KB 412606: VCF 9 installer fails the vSAN HCL check because the HCL database is over 90 days old
- Broadcom KB 327011: vSAN HCL DB up-to-date
