VMware ESXi 8 Production Best Practices: A Hardcore Guide from Security Hardening to Performance Tuning

Foreword

Mid this year, our team took over a legacy project from a client. Walking in, we found an ESXi 7 host that hadn’t been patched in six months, SSH enabled by default, and a root password set to “P@ssw0rd” — probably typed in during installation. The cherry on top? Every single VM was using the E1000 virtual NIC. Performance was abysmal.

This isn’t a joke. It’s the reality for countless SMBs.

Scrolling through Reddit discussions on ESXi 8, I noticed a pattern: people aren’t complaining about missing features. They’re complaining that the documentation is scattered and official recommendations are too idealized. For example, VMware says “VMXNET3 default of no more than 8 queues provides the best performance.” Try running that on a 40G NIC and watch your throughput tank.

So here’s the deal — I’m not going to rehash the official docs. I’m going to tell you about the pitfalls we’ve hit in production, the stuff we broke, and the battle-tested best practices we eventually settled on.

The Core Problem: Why ESXi 8 Needs Its Own Set of Best Practices

vSphere 8 introduced a ton of new stuff: a major DVS architecture overhaul, DPU support, vSAN ESA (Express Storage Architecture), and the love-it-or-hate-it vSphere Lifecycle Manager.

But here’s the thing — new doesn’t mean good.

I’ve seen teams blindly enable new features only to watch their monitoring dashboards turn red. Case in point: vSphere 8’s “Fast Boot” feature. In theory, it reduces host reboot time. In practice, on hardware that isn’t fully HCL-compatible, it caused vSAN cluster split-brain scenarios.

Don’t be a guinea pig. Let new features marinate in your test environment for at least two weeks before pushing them to production.

Security Hardening: Don’t Let ESXi Be the Backdoor to Your Network

Let me tell you a real story. In March this year, a well-known cloud provider got hit by ransomware. The entry point? An ESXi host with SSH left open. The entire virtualization layer went down. Reddit was on fire about it for three days.

Here’s my prioritized list for ESXi 8 security hardening:

1. Kill SSH and Shell Immediately

# Disable SSH and ESXi Shell via esxcli
esxcli system ssh server set --enabled=false
esxcli network shell set --enabled=false

Don’t give me the “but I need it for debugging” excuse. Turn it on, do your work, turn it off. Anything over 15 minutes of SSH uptime in production is a security incident waiting to happen.

2. Enable Lockdown Mode

ESXi 8 supports two lockdown modes: normal and strict. I recommend strict lockdown mode — it disables root access even through DCUI. All operations must go through vCenter.

# Enable strict lockdown mode
esxcli system settings lockdown set --mode=lockdown_strict

Warning: Before enabling this, make sure your vCenter connection is solid. Otherwise, you’ll lock yourself out. Don’t ask me how I know.

3. Don’t Join ESXi Hosts to the Domain

VMware’s official docs say “Avoid joining ESXi hosts to the domain,” and they’re right. ESXi’s domain authentication implementation has legacy issues — when Kerberos tickets expire and you haven’t configured a fallback authentication method, the host becomes a brick.

Our approach: All authentication goes through vCenter SSO. ESXi local accounts are strictly for emergency use. Root passwords are stored in a password manager and rotated every 90 days.

4. Configure Certificates

ESXi 8 ships with self-signed certificates. Fine for internal networks, but if you’re integrating with external monitoring or automation tools, you need CA-signed certs.

# Generate CSR
openssl req -new -nodes -out esxi.csr -keyout esxi.key -config openssl.cfg

# Import certificate
esxcli system security certificate set --cert=/path/to/cert.pem --key=/path/to/key.pem

Security Configuration Quick Reference

Networking: Stop Letting E1000 Ruin Your VMs

I ran a test: same VM, switched from E1000 to VMXNET3, network throughput went from 1.2Gbps to 9.8Gbps. That’s an eight-fold improvement.

ESXi 8’s network virtualization architecture has significant improvements. The default VMXNET3 driver already supports multi-queue RSS. VMware recommends “no more than 8 queues,” but on our 40G Mellanox NICs, 16 queues actually performed better.

Rule of thumb:

• 10G and below: 4-8 queues
• 25G-40G: 8-16 queues
• 100G: 16-32 queues (requires NUMA affinity tuning)

# Check NIC queue usage
esxcli network nic list
esxcli network nic queueusage get -n vmnic0

# Adjust VM NIC queues (in .vmx file)
ethernet0.virtualDev = "vmxnet3"
ethernet0.coalescingScheme = "disabled"
ethernet0.queues = "16"

The LACP Trap

Someone on Reddit asked: “Each physical NIC has 2 ports, each connected to a switch using trunk ports allowing all VLANs, without LACP. Is that okay?”

The answer is: Technically yes, but don’t do it.

ESXi 8’s distributed switch supports LACP, but the configuration is tedious. I recommend route based on physical NIC load with two uplinks in Active/Standby mode. Simple, stable, hard to break.

If you absolutely must use LACP, remember three things:

1. You need vSphere Distributed Switch (standard switches don’t support LACP)
2. LACP rate mode must be consistent (active/active or passive/passive)
3. Don’t mix different switch vendors (Cisco and Mellanox have subtle LACP implementation differences)

Storage Configuration: vSAN vs. Traditional Storage Gotchas

vSphere 8’s vSAN ESA is the default for all-flash architectures. But if you’re still running traditional FC SAN or iSCSI, there are some traps to watch out for.

iSCSI Best Practices

# Check current iSCSI configuration
esxcli iscsi adapter list
esxcli iscsi adapter param get -l vmhba64

# Recommended parameter settings
esxcli iscsi adapter param set -l vmhba64 -p LoginTimeout -v 30
esxcli iscsi adapter param set -l vmhba64 -p NoOpInterval -v 5
esxcli iscsi adapter param set -l vmhba64 -p NoOpTimeout -v 10

Key points:

• Each iSCSI target needs at least 2 paths (multi-path I/O)
• Use Fixed Path policy, manually specify the preferred path
• Don’t use Round Robin unless you’ve confirmed the storage array supports ALUA

vSAN ESA Considerations

vSAN ESA mandates all-flash configurations. In our tests, NVMe + Optane had the lowest latency (average 0.3ms), but the cost is eye-watering.

If you’re on a budget, SATA SSD + NVMe cache works, but keep these in mind:

• Cache disk capacity should be at least 10% of capacity disk
• Don’t mix different brands/models of SSDs
• Reserve 20% flash over-provisioning

Performance Tuning: Stuff the Official Docs Don’t Tell You

CPU Scheduling

ESXi 8’s CPU scheduler is smarter than vSphere 7’s, but some scenarios still need manual intervention.

# Check VM CPU scheduling info
esxtop -b -d 2 -a > cpu_report.csv

NUMA affinity: For VMs with 32+ vCPUs, manually bind NUMA nodes.

# Set NUMA affinity in .vmx file
numa.autosize.cookie = "1"
numa.autosize.once = "1"
numa.nodeAffinity = "0,1"

Memory Configuration

ESXi 8 supports memory encryption (vSphere Trust Authority), but enabling it causes a 5-8% performance hit. Unless you’re under PCI-DSS or HIPAA compliance, leave it off.

Keep memory overcommitment under 1.5x. Once you cross 2x, ballooning triggers frequently and performance drops off a cliff.

Quick Performance Check Script

We use this script internally for quick validation:

#!/bin/bash
echo "=== CPU Info ==="
esxcli hardware cpu list | grep "Package"
echo "=== Memory Info ==="
esxcli hardware memory get
echo "=== Network Queues ==="
esxcli network nic queueusage get
echo "=== Storage Latency ==="
esxcli storage nmp path list | grep "Latency"

Daily Operations: Don’t Let ESXi Become a Time Bomb

Log Management

ESXi 8 stores logs locally by default, but space is limited. We’ve seen hosts hang because the log partition filled up.

# Configure remote syslog
esxcli system syslog config set --remote="tcp://192.168.1.100:514"
esxcli system syslog reload

Monitoring and Alerts

vCenter’s built-in alerts aren’t enough. We use Prometheus + vsphere_exporter for finer-grained monitoring:

# prometheus vsphere_exporter config example
collectors:
  - host
  - vm
  - datastore
  - cluster

Key metrics to watch:

• esxi_host_system_uptime_seconds (track reboots)
• esxi_vm_cpu_ready_percentage (anything above 5% is trouble)
• esxi_datastore_free_bytes (keep 20% free)

Backup Strategy

Back up ESXi 8 configuration with PowerCLI:

# Export ESXi configuration
Get-VMHost -Name "esxi-01" | Get-VMHostFirmware -BackupConfiguration -DestinationPath "C:\Backups\"

Frequency: Back up after every configuration change. Keep at least the last 5 versions.

Community Rants and Reflections

Scrolling through Reddit discussions on ESXi 8, three complaints come up repeatedly:

1. vSphere Lifecycle Manager is too slow: A baseline update takes 2 hours — slower than manual patching.
2. HTML5 Web Client is still laggy: Especially noticeable in clusters with 50+ hosts.
3. Broadcom acquisition licensing changes: Lots of people saying “prices went up, support didn’t.”

Honestly, these complaints are valid. But ESXi 8 is noticeably more stable than vSphere 7 — we’ve run it for 8 months without a single PSOD. For that alone, the upgrade is worth it.

FAQ

Q: Can ESXi 8 be installed on older hardware? A: Officially, the CPU needs AVX2 instruction set support. I recommend using the HCL verification tool to check compatibility, or you might end up with no NIC drivers after installation.

Q: Is the performance gap between VMXNET3 and E1000 really that big? A: We measured 8-10x difference. E1000 emulates a gigabit NIC; VMXNET3 is a paravirtualized driver with lower latency and higher throughput.

Q: After enabling vSphere HA, VMs don’t restart as expected? A: Check the HA heartbeat network configuration. ESXi 8 uses the management network for heartbeat by default. I recommend configuring a dedicated isolation network.

Q: Is ESXi 8’s Fast Boot feature safe? A: Safe on HCL-compatible hardware. But I’ve seen vSAN disks not being recognized after reboot on Dell R740s. Test it first.

References and Community Insights

Many of the perspectives in this article come from discussions on Reddit’s r/vmware and r/homelab communities. Special thanks to the engineers who share their war stories late at night. Documentation is static, but production experience is alive.

References & Community Insights

The following authoritative resources were referenced for architectural best practices and specifications:

• Hacker News (Y Combinator)
• Reddit r/sysadmin Community
• Stack Overflow Architecture