Daniel Micanek virtual Blog – Like normal Dan, but virtual.
Today’s IT teams are under constant pressure to simplify operations, reduce costs, support new workloads, and do more with less. Yet as applications grow more complex, many organizations are juggling fragmented systems and siloed tools that slow them down. That’s where VMware vSphere Foundation [..]
The NVMe Tiering feature was first previewed with the release of vSphere 8.0 Update 3 and the feature is now officially supported with the release of VMware Cloud Foundation (VCF) 9.0! 🎉 Since the original tech preview, all major limitations and unsupported workload profiles that would prevent [..]
If you have an AMD Ryzen processor and you are planning on use the NVMe Tiering feature with either VMware vSphere Foundation (VVF) or VMware Cloud Foundation (VCF) 9.0, you will need to apply the following workaround for your VMs to properly boot. Note: This workaround is only required on AMD […]
VCF 9.0 Installer says “No vSAN ESA certified disks found”? Fix the 90-day HCL DB check the supported way. Non-HCL disks need an unsupported lab hack.
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.
| 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.
Procedure from Broadcom KB 412606. An Installer with an online depot downloads the file by itself, so this is only needed offline.
https://vvs.broadcom.com/service/vsan/all.json./nfs/vmware/vcf/nfs-mount/ on the VCF Installer appliance, for example with SCP.# 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.jsonAfter 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).
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:
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.
| 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.
By default, the new VMware Cloud Foundation (VCF) 9.0 Installer will validate the ESXi management interface is at a 10GbE network adaptor and it will prevent users from proceeding if the minimum link speed is not detected. This pre-check had also existed in VCF 5.x and users could bypass the […]
In this blog, with the release of VMware Cloud Foundation (VCF) 9.0, we explore three separate technical use-cases for VMware Private AI Foundation with NVIDIA. We show some of the high-level steps to achieve these use cases and give the rationale behind each one. Use Case 1: Models as a […]
For a major new vSphere release, it can be challenging to understand whether your existing hardware will continue to work or if you need to upgrade. During the development of VMware Cloud Foundation (VCF) 9.0, I had put together a survey that would crowdsource from internal users who have […]
When we assign a full GPU or part of a GPU to a VM in the vSphere Client , we use a “vGPU Profile” to achieve that. The set of vGPU profiles is fixed by the host vGPU driver based on the GPU hardware models in the servers in that cluster. Many different vGPU profiles […]
VCF 9.0 lab sizing: vCPU, memory and disk for vCenter, NSX, SDDC Manager, VCF Operations and VCF Automation in the Simple model, checked against Broadcom docs.
Short answer: A single-node (Simple) VCF 9.0 management stack needs about 26 vCPU and 105 GB RAM without VCF Automation. With VCF Automation it’s about 50 vCPU and 201 GB RAM, and more than 2 TB of provisioned storage. Thin provisioning uses only a fraction of that. VCF Automation alone takes 24 vCPU and 96 GB, so at least one host needs 24 or more logical CPUs.
The VCF 9.0 Installer asks for a deployment model for the new appliances. High Availability (Three-node) is the recommended choice for production. Simple deploys NSX Manager, VCF Operations and VCF Automation as single nodes (VCF Installer deployment wizard). SDDC Manager is always a single node. Simple is the model to use for a lab or a proof of concept. It’s also the biggest saving compared to VCF 5.x, which always required three NSX Managers.
| Component | Size | vCPU | RAM | Disk (provisioned) | Source |
|---|---|---|---|---|---|
| vCenter | Small | 4 | 21 GB | 734 GB (default storage) | HW, storage |
| NSX Manager | Medium, 1 node | 6 | 24 GB | 300 GB | KB 403604 |
| SDDC Manager (VCF Installer appliance) | fixed | 4 | 16 GB | 914 GB | TechDocs |
| VCF Operations | Small, 1 node | 4 | 16 GB | see sizing worksheet | KB 397782 |
| VCF Operations collector | Small | 4 | 16 GB | see sizing worksheet | KB 397782 (Unified Cloud Proxy, Small) |
| VCF Operations fleet management | fixed | 4* | 12 GB* | not published | lab measurement* |
| VCF Automation (optional) | Small, 1 node | 24 | 96 GB | 100 GB | VCFA sizing |
* Broadcom TechDocs don’t publish sizing for the fleet management appliance. The figures are what William Lam measured on a deployed lab (see Further reading), so treat them as approximate.
| Scope | vCPU | RAM |
|---|---|---|
| Core stack: vCenter, NSX, SDDC Manager, VCF Operations, collector, fleet management | 26 | 105 GB |
| Core stack + VCF Automation | 50 | 201 GB |
The published disk sizes alone (vCenter, NSX, SDDC Manager, VCF Automation) add up to more than 2 TB. Deploy thin wherever you can. In a freshly deployed lab the space actually used is a few hundred GB.
The host count, the single 10GbE NIC, the NFS versus vSAN choice and the installer overrides that make a small homelab work (single-host domain flag, NIC speed validation bypass, vSAN ESA HCL mock VIB, HTTP offline depot) are covered in Deploying a Minimal VCF 9.0 Lab – Insights from Explore 2025. Those overrides are unsupported and for lab use only. For licensing tiers, see vSphere 9.0 product line comparison.
This page covers VCF 9.0. VCF 9.1 moves several management functions into VCF management services, so check the 9.1 documentation before you size a 9.1 lab.
