WilliamLam.com

Enabling License Later (evaluation) mode for VMware Cloud Foundation (VCF) 5.1.1

by // 8 Comments

VMware Cloud Foundation (VCF) 5.1.1 was just released this week and it brings a number of new capabilities including the recently announced VMware Private AI Foundation with NVIDIA solution. One feature that I was really happy to see get introduced is called "License Later" better known as evaluation mode, which will now allow users to deploy VCF with Cloud Builder without requiring the component license keys up front, which was the previous user experience.

From a hands on and/testing perspective, this will allow for more users to experience VCF and reduce the barrier to entry for those that want to play with the product. Speaking of hands on, I wanted to try out the new evaluation mode using my VCF Automated Lab Deployment script which I had just assumed you would leave the license fields blank within the deployment JSON file but that did not work. After speaking with VCF Engineering, I found that there is a new deployment parameter that must be appended to the JSON file if you are deploying VCF using the Cloud Builder API.

Once I added the configuration, the VCF deployment kicked off successfully!

Deployment JSON:

For deploying VCF using the Cloud Builder API, you will need to append deployWithoutLicenseKeys with a value of true and the all license fields can be left blank or omitted all together

deployWithoutLicenseKeys: true

Deployment Workbook:

For deploying VCF using the Cloud Builder UI, there is a new entry in the workbook called "License Now" which you can select No and leave all license fields blank.

I have already updated my VCF Automated Lab Deployment script to support the new evaluation mode with VCF 5.1.1 as I have already been asked about the capability from a few customers 🙂

For Workload Domain creation, you can also deploy with the new license later feature by adding the "deployWithoutLicenseKeys" parameter into your JSON specification. For an example, search for this parameter in the JSON example for the VCF Domain Creation API.

Unable to power on vSphere Cluster Services (vCLS) VM in Nested ESXi with no host is compatible with the virtual machine

by // 8 Comments

After deploying a new VMware Cloud Foundation (VCF) Workload Domain using the VCF Holodeck Toolkit, which leverages Nested ESXi, I noticed the vSphere Cluster Services (vCLS) VMs kept failing to power on and threw the following error message:

No host is compatible with the virtual machine


I thought this was quite strange, especially since the vCLS VMs ran fine when the VCF Management Domain was setup.

UPDATE (07/03/2024) - The reason for the vCLS error is actually due to the miss-configuration of the Nested ESXi VM created by VCF Holodeck Toolkit, please see this blog post for an easier fix.

Looking at the vmware.log for the vCLS VM, I quickly found the issue where the VM expects to have the MWAIT CPU instruction exposed:

2024-03-19T16:35:35.736Z In(05)+ vmx - Power on failure messages: Feature 'cpuid.mwait' was 0, but must be 0x1.
2024-03-19T16:35:35.736Z In(05)+ vmx - Module 'FeatureCompatLate' power on failed.
2024-03-19T16:35:35.736Z In(05)+ vmx - Failed to start the virtual machine.

I figure I was probably not the first person to run into this and asked Ben Sier, who works on Holodeck and indeed he ran into this before. It looks like with newer vSphere releases, it expects to configure Per-VM EVC but the vCLS VM may not function properly within a Nested ESXI environment. Luckily, Ben has a workaround that we can quickly use.

[Read more...]

Dynamic ESXi firewall rulset for non-standard syslog ports in vSphere 8.0 Update 2b

by // 5 Comments

For most users who configure syslog for their ESXi hosts (hopefully everyone is doing that for audit, compliance and troubleshooting purposes), they typically stick with the default syslog ports 514 for UDP/TCP or 1514 for TLS.

A huge benefit of using the default syslog ports is that the ESXi firewall is already configured with these rulesets configured for outbound access.


If you require to use a non-standard syslog port for ESXi, the current solution was not ideal. While you can open up a custom port using the ESXi firewall, the issue is persisting that customization, which either requires a custom VIB or messing around with local.sh startup script.

A nice enhancement that is included with the recent release of vSphere 8.0 Update 2b is the support for a dynamic ESXi ruleset when non-standard syslog ports is configured.

As you can see in the example below when I configure my ESXi host to use a syslog server with a custom port 12345, the ESXi will automatically create a dynamic firewall ruleset that will open up that port for outbound connectivity. If you change the port or disable the syslog configuration, then the dynamic ruleset will be updated and/or removed.