For most users, you probably have a large collection of vSphere license keys that have been provisioned over the years and keeping track of the product SKU, entitled features and capacity can be a challenge, especially if you are just looking at the raw 25 character license string.
While the Broadcom Support Portal (BSP) is recommended for all license management operations(view, split, merge, etc), did you know you could also use vCenter Server to help decode a particular license key?
As of VMware Cloud Foundation 5.1.0, you can now use the new vSAN Express Storage Architecture (ESA) when deploying a VCF Workload Domain where as in earlier releases, only the vSAN Original Storage Architecture (OSA) was supported, which is typically what I deploy for testing purposes.
While working on some enhancements to my VCF Automated Lab Deployment Script, I needed to go through a VCF Workload Domain deployment using vSAN ESA but I kept running into the following error within SDDC Manager: Perform vSAN ESA Auto Disk Claim
Based on the error message, I had assumed there was an issue with claiming the SSD on the Nested ESXi VM for vSAN ESA but when I logged into the VCF Workload Domain vCenter Server, I was able to claim the devices without any issues. Looking at the SDDC Manager logs /var/log/vmware/vcf/domainmanager/domainmanager.log also did not yield anything useful:
2024-05-27T12:43:44.545+0000 ERROR [vcf_dm,66548000bff276b81889b17ab22d34ed,2f33] [c.v.v.c.f.p.a.i.ClaimDisksForVsanEsaClusterAction,dm-exec-14] Host host-16 does not contribute to the vSAN ESA storage. 2024-05-27T12:43:44.598+0000 ERROR [vcf_dm,66548000bff276b81889b17ab22d34ed,2f33] [c.v.v.c.f.p.a.i.ClaimDisksForVsanEsaClusterAction,dm-exec-14] Host host-19 does not contribute to the vSAN ESA storage. 2024-05-27T12:43:44.650+0000 ERROR [vcf_dm,66548000bff276b81889b17ab22d34ed,2f33] [c.v.v.c.f.p.a.i.ClaimDisksForVsanEsaClusterAction,dm-exec-14] Host host-20 does not contribute to the vSAN ESA storage. 2024-05-27T12:43:44.701+0000 ERROR [vcf_dm,66548000bff276b81889b17ab22d34ed,2f33] [c.v.v.c.f.p.a.i.ClaimDisksForVsanEsaClusterAction,dm-exec-14] Host host-21 does not contribute to the vSAN ESA storage. 2024-05-27T12:43:44.702+0000 DEBUG [vcf_dm,66548000bff276b81889b17ab22d34ed,2f33] [c.v.e.s.c.c.v.vsphere.VsphereClient,dm-exec-14] Destroying 2 open views 2024-05-27T12:43:44.722+0000 ERROR [vcf_dm,66548000bff276b81889b17ab22d34ed,2f33] [c.v.v.c.f.p.a.i.ClaimDisksForVsanEsaClusterAction,dm-exec-14] Failed to verify storage pool disks for cluster wld-w01-cl01 2024-05-27T12:43:44.723+0000 ERROR [vcf_dm,66548000bff276b81889b17ab22d34ed,2f33] [c.v.v.c.f.p.a.i.ClaimDisksForVsanEsaClusterAction,dm-exec-14] com.vmware.evo.sddc.orchestrator.exceptions.OrchTaskException: Found host(s) in clust er wld-w01-cl01 without contributing to storage pool. 2024-05-27T12:43:44.723+0000 ERROR [vcf_dm,66548000bff276b81889b17ab22d34ed,2f33] [c.v.e.s.o.model.error.ErrorFactory,dm-exec-14] [A337BL] VSPHERE_AUTO_DISK_CLAIM_FAILED Failed to enable auto claim on cluster wld-w01-cl01 com.vmware.evo.sddc.orchestrator.exceptions.OrchTaskException: Failed to enable auto claim on cluster wld-w01-cl01 at com.vmware.vcf.common.fsm.plugins.action.impl.ClaimDisksForVsanEsaClusterAction.postValidate(ClaimDisksForVsanEsaClusterAction.java:119) at com.vmware.vcf.common.fsm.plugins.action.impl.ClaimDisksForVsanEsaClusterAction.postValidate(ClaimDisksForVsanEsaClusterAction.java:23) at com.vmware.evo.sddc.orchestrator.platform.action.FsmActionState.lambda$static$1(FsmActionState.java:23) at com.vmware.evo.sddc.orchestrator.platform.action.FsmActionState.invoke(FsmActionState.java:62) at com.vmware.evo.sddc.orchestrator.platform.action.FsmActionPlugin.invoke(FsmActionPlugin.java:159) at com.vmware.evo.sddc.orchestrator.platform.action.FsmActionPlugin.invoke(FsmActionPlugin.java:144) at com.vmware.evo.sddc.orchestrator.core.ProcessingTaskSubscriber.invokeMethod(ProcessingTaskSubscriber.java:400) at com.vmware.evo.sddc.orchestrator.core.ProcessingTaskSubscriber.processTask(ProcessingTaskSubscriber.java:561) at com.vmware.evo.sddc.orchestrator.core.ProcessingTaskSubscriber.accept(ProcessingTaskSubscriber.java:124) at jdk.internal.reflect.GeneratedMethodAccessor397.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.google.common.eventbus.Subscriber.invokeSubscriberMethod(Subscriber.java:85) at com.google.common.eventbus.Subscriber.lambda$dispatchEvent$0(Subscriber.java:71) at com.vmware.vcf.common.tracing.TraceRunnable.run(TraceRunnable.java:59) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833) Caused by: com.vmware.evo.sddc.orchestrator.exceptions.OrchTaskException: Found host(s) in cluster wld-w01-cl01 without contributing to storage pool. at com.vmware.vcf.common.fsm.plugins.action.impl.ClaimDisksForVsanEsaClusterAction.postValidate(ClaimDisksForVsanEsaClusterAction.java:113) ... 17 common frames omitted
After a bit of digging, I was wondering if this was related to a similiar issue that is seen during the VCF Bringup of the VCF Management Domain using vSAN ESA where a custom vSAN HCL JSON was required?
I always love hearing about new and interesting hardware vendors from our VMware community, which is exactly how I came to learn about Protectli back in 2021 from fellow vExpert Trevor Smith. It was in 2021 where Trevor had shared with the vExpert Community that Protectli was developing a 10GbE hardware kit, which was really interesting since there was not many options for small form factor systems at that time that included 10GbE connectivity.
After following up with Protectcli in 2021, they confirmed a 10GbE kit was in the works but it was still in early design and development, so there was nothing to evaluate at the time. Fast forward to April 2024, I received a follow-up email asking if I would be interested in kicking the tires on their first 10GbE kits with their new Protectli Vault Pro 6600 series.
So here is your first look at the ESXi running on the new Protectli 10G Vault Pro!