WilliamLam.com

Quick Tip - Automating cpuUniformityHardCheckPanic configuration for ESXi Kickstart with USB

by // Leave a Comment

To prevent ESXi from PSOD'ing when an Intel Hybrid Consumer CPU is detected with non-uniform capabilities, a workaround can be applied to ignore the uniformity miss-match which is needed before the ESXi installer fully boots up and also after the initial reboot.

For those looking to fully automate this process using ESXi Kickstart using USB as an example, there are two places where the kernel boot option must be added:

1) The first is the EFI\boot\boot.cfg file on the ESXi installer media (e.g. USB) where you will append to the kernelopt line as shown in the snippet below:

bootstate=0
title=Loading ESXi installer
timeout=5
prefix=
kernel=/b.b00
kernelopt=ks=usb:/KS.CFG cpuUniformityHardCheckPanic=FALSE
.....

2) The second must be added to the %post section of your ESXi kickstart, which will update the first ESXi bootbank's boot.cfg and ensure the kernel option is passed to ESXi when it reboots after installation:

%post --interpreter=busybox

sed -i '/^kernelopt=/ s/$/ cpuUniformityHardCheckPanic=FALSE/' /vmfs/volumes/BOOTBANK1/boot.cfg

Disable IPv6 in ESXi Kickstart without additional reboot

by // 2 Comments

ESXi supports dual stack networking (IPv4 and IPv6) by default, however users can also configure just IPv4 or IPv6, which requires a system reboot for the changes to go into effect.

Recently, I received a question from a colleague asking if there was a way to disable IPv6 during ESXi Kickstart (aka scripted installation) but NOT require an additional reboot as this setting is typically added in the %post or %firstboot section, which will require an additional reboot due to changing the networking stack default.

The solution was actually quite simple by just leveraging the %pre section, which would ensure that IPv6 is disabled upon the initial reboot after the ESXi installation.

[Read more...]

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...]