Posted by The Problem
Sometimes an ESXi installation fails before you ever get useful logs.
Instead of a clean error message, the installer simply crashes or reboots. If you are unlucky, you are left staring at a brief Purple Screen of Death (PSOD).
That was exactly the situation I recently ran into while installing ESXi on an HPE Gen10 server. The installer repeatedly crashed during boot, without leaving any visible diagnostics.
The only realistic way to understand what is happening in those early boot stages is to capture serial logs from the ESXi installer.
VMware actually documents how to enable serial logging during installation, but there is one practical problem. You still need a way to capture the serial output.
And that is where things get interesting.
The First Question: Can iLO Read COM1?
The most obvious thought was to simply capture the data via the HPE iLO interface.
Gen10 servers expose a Virtual Serial Port (VSP) through iLO. At first glance it looks like a perfect solution. If ESXi logs to COM1, then iLO should be able to read it.
Unfortunately it is not that simple.
The iLO Virtual Serial Port is not directly connected to the physical COM1 port on the server. Instead, it is a logical serial interface that the operating system can use for remote console access.
So there are two completely separate concepts.
• Physical COM1 port on the server motherboard
• iLO Virtual Serial Port (VSP)
The iLO can only display data that is explicitly written to the VSP, not the electrical pins of the physical serial port.
Fortunately, ESXi can still send its installer logs to the virtual serial port if it is configured correctly.
Enabling Serial Logging During ESXi Installation
VMware provides a boot parameter that allows the installer to write logs to a serial port.
When the ESXi installer starts loading, press Shift + O to edit the boot options and append the following parameters.
runweasel debugLogToSerial=1 logPort=com1
This instructs the installer to send debugging output to COM1.
In most HPE Gen10 configurations, the iLO Virtual Serial Port maps to COM1, which means the logs can be captured remotely.
Preparing iLO to Capture the Logs
Before booting the installer, the iLO console needs to start listening for serial output.
- Open an SSH session to the iLO interface
- Log in with your iLO credentials
- Start the virtual serial console:
vsp
Once the command is executed, the iLO will start displaying any serial output it receives.
If everything is configured correctly, the ESXi installer logs will immediately start streaming into the SSH session.
At this point it is highly recommended to enable session logging in your SSH client, so you capture everything into a file.
If the installer crashes, you now have the entire boot log available for analysis.
Capturing the Crash
With serial logging enabled, the ESXi installer logs started appearing in the VSP session.
This provided something that was previously impossible to capture: the exact point where the VMkernel initialization stopped.
Looking at the logs showed that the crash happened during hardware initialization and CPU power management.
Specifically around the scheduler and power state handling:
CpuSched: Will use MWAIT to enter C1
This is a strong indicator that the problem is related to power management settings in the BIOS.
The Root Cause
On HPE Gen10 servers the default power profile is often set to an energy efficient mode.
While this works fine for many workloads, it can cause issues during early ESXi initialization because of the way CPU power states and scheduling interact.
Changing the BIOS power profile resolved the installer crash.
The fix was simple.
In the system BIOS:
System Configuration
→ BIOS/Platform Configuration
→ Power Management
→ Power Profile
→ Maximum Performance
After switching to Maximum Performance, the ESXi installer booted normally.
Another Interesting Warning
While analyzing the logs, another message appeared earlier in the boot process.
WARNING: Sched: Sub-NUMA clustering may be enabled and is incompatible with the Intel RDT features on ESXi
This warning refers to Sub-NUMA Clustering (SNC), a CPU configuration that splits a socket into multiple NUMA domains.
Although SNC can improve performance for certain specialized workloads, it is often not recommended for general virtualization environments.
In ESXi environments it can interfere with features such as Intel Resource Director Technology (RDT) and complicate CPU scheduling.
In most cases it is best to disable SNC unless there is a very specific workload that benefits from it.
Why Serial Logging Matters
When ESXi fails very early in the boot process, normal logging mechanisms are not yet available.
That means:
• No installer logs
• No vmkernel logs
• No persistent diagnostics
Serial logging provides visibility into those earliest stages of the boot process where the VMkernel initializes hardware, CPU topology, NUMA, and drivers.
Without it, troubleshooting early installer crashes can become guesswork.
Final Thoughts
This troubleshooting session was a good reminder of two things.
First, serial logging is incredibly valuable when diagnosing ESXi installation issues.
Second, the iLO Virtual Serial Port is a powerful but often overlooked tool that allows you to capture those logs remotely without additional hardware.
In this case it made it possible to quickly identify that the installer crash was related to BIOS power management settings, something that would have been difficult to diagnose otherwise.
If you ever run into ESXi installation crashes on HPE servers, enabling serial logging through the iLO VSP is definitely worth trying.