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.
Nested ESXi is also used extensively for our own internal development and functional testing and when deploying vSAN ESA, we also run into the same HCL warning as our users. Another way to workaround this is to "mock" up the hardware such that the vSAN ESA HCL will successfully pass the vSAN Health Check and this is accomplished by creating a stress.json file that is placed within a Nested ESXi host.
Initially, I was not a fan of this option as you needed to create this file on every single Nested ESXi host and because it does not persists, you also would need to re-create this upon each reboot which added to the complexity and while you can certainly create a startup script, you had to remember each time you added a new host.
After thinking about both workarounds, I did find merit in the stress.json option, it certainly required less "tweaking" from the product and messing with configuration files is typically not my preference, if I can help it. Given some of the scenarios users were hitting as they were playing with newer bits, I came up with an easy solution which was to create a custom ESXi VIB/Offline Bundle that users could simply install stress.json into correct path for their Nested ESXi VM, solving both the persistency, scale and ease of use problem.
Hop over to my Nested vSAN ESA Mock Hardware Repo to download either the ESXi VIB or ESXi Offline Bundle and after the installation (you do need to change the software acceptance to CommunitySupported), you then just restart the vSAN Management Service by running:
/etc/init.d/vsanmgmtd restart
or you can simply integrate this into a new ESXi Image Profile/ISO using vSphere Lifecycle Manager so the VIB is always part of your ESXi installation. Once ESXi host contains the stress.json, there are NO other changes required on either vCenter Server or VCF, so that is certainly a huge plus with not having to touch any other settings.
Note: I was thinking about incorporating this into my Nested ESXi Virtual Appliance, but because it requires changing the default software acceptance level to CommunitySupported, I decided not to make that global change and leave it for now and users can simply install the VIB/Offline Bundle as a separate task for those requiring the use of vSAN ESA.
Nice idea William, will give it a try!