VMware Cloud Foundation (VCF) 9.0.1 is the first maintenance release for VCF 9.0, delivering a number of important fixes but also several exciting enhancements for lab deployments or running proof-of-concepts (PoC).
VCF 9.0 had already introduced a number of built-in capabilities and some neat “tricks” that makes it easier than ever to deploy a minimal VCF footprint, which you can read more about here.
However, there were still a couple of minor annoyances around vSAN ESA HCL or Host Commissioning pre-checks that could be improved to provide a better customer experience when deploying VCF for non-production usage. With feedback to VCF Engineering, I am pleased to share that these issues have now been addressed as part of VCF 9.0.1 release!
vSAN ESA HCL Check
Similar to the enhancement that was introduced with the release of VCF 5.2.2, which was actually driven by the development of VCF 9.0.1, we now have a simplified method for bypassing the vSAN ESA HCL check for lab and proof of concept purposes. Users no longer need to craft custom vSAN ESA JSON files or messing around with installing VIBs on their ESXi hosts.
Day 0 - VCF Installer
During the initial VCF Fleet deployment using the VCF Installer, if you do NOT have compatible vSAN ESA hardware, you will see the following error as shown in the screenshot above.
To workaround this, login to the VCF Installer and append the following:
- vsan.esa.sddc.managed.disk.claim=true to /etc/vmware/vcf/domainmanager/application-prod.properties
For changes to go into effect, restart the SDDC Domain Manager services.
echo "vsan.esa.sddc.managed.disk.claim=true" >> /etc/vmware/vcf/domainmanager/application-prod.properties systemctl restart domainmanager
Day N - SDDC Manager
Once you have a VCF Fleet deployed, you may want to commission additional ESXi hosts for expanding your existing VCF Management Domain and/or deploy a new VCF Workload Domain using VCF Operations. If you do NOT have compatible vSAN ESA hardware, you will see the following error as shown in the screenshot above when you attempt to commission a new host.
To workaround this, login to SDDC Manager and append the following:
- vsan.esa.sddc.managed.disk.claim=true to /etc/vmware/vcf/domainmanager/application-prod.properties
- vsan.esa.sddc.managed.disk.claim=true to /etc/vmware/vcf/operationsmanager/application-prod.properties
For changes to go into effect, restart the SDDC Manager services.
echo "vsan.esa.sddc.managed.disk.claim=true" >> /etc/vmware/vcf/domainmanager/application-prod.properties echo "vsan.esa.sddc.managed.disk.claim=true" >> /etc/vmware/vcf/operationsmanager/application-prod.properties echo 'y' | /opt/vmware/vcf/operationsmanager/scripts/cli/sddcmanager_restart_services.sh
10GbE NIC Check
Day 0 - VCF Installer
An existing workaround already exists in VCF 9.0 to disable the 10GbE NIC pre-check during the initial VCF Fleet deployment using the VCF Installer.
Day N - SDDC Manager
While it is possible to disable the 10GbE NIC pre-check during the initial VCF Fleet deployment through the VCF Installer, one limitation that has existed since VCF 5.x is that the 10GbE pre-check is not disabled during host commissioning and you will see the following error as shown in screenshot above.
To workaround this, login to SDDC Manager and append
- enable.speed.of.physical.nics.validation=false to /etc/vmware/vcf/operationsmanager/application.properties
For changes to go into effect, restart the SDDC Manager Operations Manager services.
echo "enable.speed.of.physical.nics.validation=false" >> /etc/vmware/vcf/operationsmanager/application.properties systemctl restart operationsmanager
Awesome news - the bits have already hit the lab 😉 Thanks William
How about making it easier to bypass image checks also? or not having to completely rebuild after a failed attempt!
Which image checks are you referring to, could you provide an example?
I synced the binaries in SDDC yesterday after I saw 9.0.1 was released.
When trying to create a SDDC cluster, it wants you to attach an image but it filtered on images for ESXi 9.0.0.0.24813472 (dont think this one exists). Seemed like it should have filtered on ESXi 9.0.0.0100.24813472 instead.
It would be nice if that step lets you create an image based on those hosts or skip the step entirely.
I understand that VCF requires NICs with speeds of 10 Gbps or higher. However, for VVF (not vSAN), is it supported to use 1 Gbps NICs? Our current management LAN utilizes 1 Gbps NICs, and we would prefer to avoid upgrading to 10 Gbps NICs during the VVF 9.0 upgrade if feasible.
William... Can you shed any additional light on specific necessity or purpose of the feature.vcf.vgl-43370.vsan.esa.sddc.managed.disk.claim=true property? I've been able to bypass the ESA HCL failure for bringup, commission, and expand on 9.0.1.0 with the other property alone, as noted in KB 408300. https://knowledge.broadcom.com/external/article/408300
Hi Jason,
The KB is correct, the additional flag was something we needed during pre-release of 9.0.1, but its set automatically within the code but I wasn't 100% sure during my early testing, so I included it. I've updated the blog post to only reference the single required param. Apperciate the feedback
i am using Kingstons DC600M this works? it works on vsphere 8 with a simple warning.
Deploying 9.0.2 from scratch today on a new set of 3x MS-A2 units. These workarounds are very helpful. One odd thing however is that the VCF Installer (VCF-SDDC-Manager-Appliance-9.0.2.0.25151285.ova) only asks for admin and root passwords in the OVA deployment wizard. As far as I can tell, it doesn't create a vcf user (or if it does, I have not idea what the creds might be). As a result, you can't SSH into the installer as neither admin or root will work. I had to login as root on the console and type in all the commands.
For VCF Installer, the non-root user is "vcf" and when you provide the password, it is applicable to that user as well as the application login which admin@local (which VCF Installer UI pre-populates). Hope that helps
Ah, got it. I confirmed the admin@local password works with user vcf for SSH login. Thank you!