Whether you are configuring vSAN Express Storage Architecture (ESA) directly from vCenter Server or from VMware Cloud Foundation (VCF), the underlying ESXi hardware is automatically validated against the vSAN ESA Hardware Compatibility List (HCL) to ensure that you are using supported vSAN hardware.
In the case of vCenter Server, you can simply ignore the HCL warnings and accept the risks and proceed with the configuration but when using VCF, the operation is blocked to ensure customers have a good experience when selecting vSAN ESA when deploying a VCF Management or Workload Domain.
With that said, there is workaround where you can create your own custom vSAN ESA HCL JSON based on the hardware that you have and then upload that to either Cloud Builder for setting up a new VCF Management Domain or to SDDC Manager for deploying a new VCF Workload Domain, which I have blogged about HERE and HERE.
The use of Nested ESXi is a very popular way to deploy VCF, especially if you are new to solution and allows you to easily experiment and learn. More recently, I have noticed an uptick in the interests for deploying VCF with vSAN ESA and while you can certainly generate a custom vSAN ESA HCL as mentioned earlier, the process still requires some effort and in some situations the vSAN ESA HCL could get overwritten leading some frustration in debugging.
After helping some folks debug their VCF environments recently, I was thinking about a better experience and leveraging another technique that may not be very well known externally ...
UPDATE (02/03/25) - This solution can also be used for a physical ESXi deployment for use with vSAN ESA and VCF.