Have you ever tried to automate a specific vSphere operation but were sure which vSphere API to use or if known, how to actually use it? This is something I frequently see and get asked about quite often!
Did you know about this hidden little gem that has been available since vSphere 6.7, built right into the vSphere UI that can help with these questions!?
It is called vSphere Code Capture or what I typically refer to as your ChatGPT for vSphere Automation, but without the hallucinations 😀
Up until vSphere 8.0, there were two primary sets of vSphere APIs:
Note: Technically, there are other vCenter Server API endpoints including vSAN, Storage Policy Based Management (SPBM), etc. but for the purposes of this article, we are focusing on the core vCenter Server functionality.
The vSphere Web Services API was available starting with the Virtual Infrastructure (VI) 2.x release back in 2007. To date, the vSphere Web Services API supports the latest vSphere 8.x release and still also has full backwards compatibility going all the way back to Virtual Center 2.x!
As you can imagine, the vSphere Web Services API covers an extremely large amount of functionality over the past 16 years since its introduction and it continues to be widely used by almost all customers either directly or indirectly through the various vSphere SDKs including PowerCLI, pyvmomi (vSphere SDK for Python), govmomi (vSphere SDK for Go), Terraform Provider for vSphere to just name a few. In addition, we also have many 2nd party solutions from VMware and thousands of 3rd party offerings from our broader ecosystem of partners that provide integrations with the vSphere platform, all consuming the vSphere Web Services API!
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.