I first wrote about the tiny palm size iKOOLCORE R1 back in Spring of this year, I was pretty impressed at how capable the R1 was, especially given the tiny footprint that is slightly taller than a Lego minifigure!
It has not even been a full year since the release of the R1 and the second generation of the R-Series is now available, not surprisingly dubbed the R2.
While official support for running ESXi on Apple Hardware (Mac Pro and Mac Mini) has concluded with ESXi 7.x, it certainly has not discourage users from experimenting with newer ESXi releases. In fact, ESXi 8.x still runs like a champ on most x86 Apple Hardware platforms including the vintage Apple Mac Mini 7,1 (2014) and to the most recent Apple Mac Mini 8,1 (2018)!
For those with an Apple Mac Mini 8,1 (2018), the onboard Apple NVMe storage device can not be used out of the box with ESXi, without the use of the Community NVMe Driver for ESXi Fling. Surprisingly, the Community NVMe Driver for ESXI Fling is still functional even with the latest ESXi 8.x release, even though it was only created and supported during ESXi 7.x timeframe.
From the recent reports from the VMware Community, the Apple NVMe device can be detected up until ESXi 8.0 Update 1c (Build 22088125) but after upgrading to ESXi 8.0 Update 2 (22380479), it was no longer showing up.
One of the exciting new features in the latest VMware Cloud Foundation (VCF) 5.1 release is the support for the vSphere 8.0 Update 2 and the new vSAN Express Storage Architecture (ESA), which can be enabled for both the VCF Management and Workload Domain.
As many of you already know, one of the easiest way to explore and play with new VCF releases is by leveraging Nested ESXi, which dramatically reduces the amount of time for setting up the infrastructure before you can start deploying VCF. This is how I initially played with VCF 5.0 and I had assumed the same would also work for the latest VCF 5.1 release.
Shortly after kicking off the VCF Bringup process, I noticed it failed immediately with an error about validating the virtual disks on my Nested ESXi VM against the vSAN HCL!? 😧
I thought this was really strange, especially in a non-VCF deployment, enabling vSAN ESA using vCenter Server only gives you a warning about your hardware not being on the vSAN HCL but does not stop you from continuing with the deployment. For testing and homelab purposes, this is completely acceptable and the fact that vCenter Server allows this operation but VCF blocks it, was an interesting UX decision.
If hardware validation against the vSAN HCL is required for VCF 5.1 when enabling vSAN ESA, then this would severely impact who can play with the latest VCF release, at least if you wanted to try out vSAN ESA.
UPDATE (05/28/24) - If you are using Nested ESXi and wish to enable vSAN ESA for a VCF Workload Domain, please take a look at this blog post HERE for more details.