One of the recent features of the vSphere Cluster Services (vCLS) is the ability configure the vSphere Datastores that vCLS is allowed to use to provision the required service VMs, which can be on a vSphere Cluster under Configure->vSphere Cluster Services->Datastores as shown in the screenshot below.
In addition to the vSphere UI, you can also programmatically update this configuration using the vSphere API and with tools like PowerCLI as one of the interfaces to the API.
I was recently chatting with a fellow colleague who asked an interesting question about the memory overhead between running vSAN Original Storage Architecture (OSA) versus the new vSAN Express Storage Architecture (ESA) from a VMware Homelab perspective. I honestly did not know the answer as I am only using vSAN OSA for my personal homelab. I was curious myself, especially its implicationn on small form factor (SFF) systems which typically max at out 64GB of memory.
Today, vSAN ESA is only officially supported when using vSAN ESA Ready Nodes which are all listed in the vSAN ESA HCL and the minimum amount of memory is 512GB. For the best possible experience and supported configurations, customers should only use approved vSAN ESA hardware and the use of any other systems will not yield the same benefits nor outcomes. As an aside, a fantastic resource for all things vSAN ESA can be found on the vSAN ESA TechZone page, which I highly recommend bookmarking as there is a lot of in-depth technical resources and collateral.
Disclaimer: This is not officially supported by VMware and is purely for educational purposes, use at your own risk.
In vSphere 7.0 Update 2, an enhancement was made to the Virtual Machine's UEFI firmware called VirtualEFI that would enable ESXi to run in a VM (Nested ESXi) and perform an HTTP Boot given the ESXi bootloader URL without requiring any traditional PXE infrastructure.
This was especially useful for anyone testing or developing ESXi automation for use with ESXi Kickstart, where you can quickly prototype your automation without additional infrastructure dependencies and once the automation has been vetted, you can then leverage that exact same automation in your physical ESXi provisioning infrastructure.
The original solution had only supported HTTP and I recently came to learn that we can now also support HTTPS in vSphere 8!