1.1 vSphere 8.x Architecture and Components Overview

1.1 vSphere 8.x Architecture and Components Overview

VMware vSphere 8.0 represents the foundational virtualization platform for enterprise hybrid cloud environments. At the center of vSphere is VMware ESXi 8.0, an enterprise-class Type-1 bare-metal hypervisor that abstracts physical compute, memory, storage, and networking resources into logical pools shared across virtual workloads. Mastering vSphere 8 architecture requires understanding the internal mechanics of the hypervisor, physical hardware boundaries, management agent communication paths, and the file structures comprising virtual machines.

The Type-1 Bare-Metal Hypervisor & VMkernel Subsystem

Unlike Type-2 hosted hypervisors (such as VMware Workstation or Oracle VirtualBox) that execute as an application on top of a general-purpose operating system like Linux or Windows, ESXi installs and executes directly on physical bare-metal hardware. There is no underlying third-party operating system. ESXi boots directly from system firmware (UEFI or legacy BIOS) and initializes its custom POSIX-like operating system kernel known as the VMkernel.

+-------------------------------------------------------------+
|               Virtual Machines (VMX Processes)              |
|      [ Guest OS ]          [ Guest OS ]      [ Guest OS ]   |
|      [ Virtual HW ]        [ Virtual HW ]    [ Virtual HW ] |
+-------------------------------------------------------------+
|                         User World                          |
|          hostd               vpxa             Shell/SSH     |
+-------------------------------------------------------------+
|                          VMkernel                           |
|  CPU Scheduler | Memory Management | Virtual Device Drivers |
+-------------------------------------------------------------+
|                      Physical Hardware                      |
|           x86-64 CPUs | RAM | NVMe/SAS Storage | NICs       |
+-------------------------------------------------------------+

VMkernel Architectural Roles

The VMkernel exercises complete, direct control over the server's physical resources and provides three primary management subsystems:

1. Advanced CPU Scheduling: The VMkernel CPU scheduler handles proportional share allocation, relaxed co-scheduling for Symmetric Multiprocessing (SMP) virtual machines (sibling vCPUs may drift slightly apart instead of running in strict lockstep), and Non-Uniform Memory Access (NUMA) topology awareness. It optimizes thread placement across physical CPU sockets and cores to ensure memory locality and minimize cross-socket interconnect latency.
2. Hierarchical Memory Management: The VMkernel abstracts physical RAM and dynamically orchestrates physical page allocation using four cascading reclamation techniques: Transparent Page Sharing (TPS) (intra-VM deduplication), Memory Ballooning (via the guest vmmemctl driver), Memory Compression (caching swapped pages in a compressed RAM tier), and Hypervisor Swapping (paging unreserved memory out to the VM's .vswp file on storage).
3. Native Virtual Device Driver Architecture: Beginning in vSphere 7.0 and hardened in vSphere 8.0, VMware completely removed the legacy VMKlinux driver compatibility interface. All hardware devices—including storage host bus adapters (HBAs) and network interface cards (NICs)—must interact with the VMkernel through native, 64-bit VMkernel device drivers compiled specifically for VMware Native Driver Architecture.

User World vs. VMkernel World

To preserve hypervisor stability and security, ESXi separates operational execution into two operational domains:

• VMkernel Space (Ring 0): Houses the core scheduler, memory management subsystems, hardware drivers, and network/storage protocol stacks. A crash here results in a purple diagnostic screen (PSOD).
• User World (Ring 3): An isolated runtime environment that executes management daemons and administrative processes outside kernel memory. Key user-world processes include the local management daemon (hostd), the vCenter agent (vpxa), the direct console user interface (DCUI), and administrative shells.

ESXi 8.0 Hardware Requirements & Boot Media Evolution

Enterprise hardware running ESXi 8.0 must be validated against the official VMware Compatibility Guide (often referred to as the Hardware Compatibility List or HCL). Attempting to install ESXi 8.0 on uncertified hardware can lead to unsupported processor traps, missing storage driver failures during installation, or operational instability.

Minimum Compute & Network Hardware Prerequisites

ESXi 8.0 System Storage Layout

Starting with vSphere 7.0, VMware consolidated the ESXi system storage layout. Older releases used many small fixed partitions (bootbank, altbootbank, scratch, locker, and a core dump partition). ESXi 8.0 uses four partitions, and the boot disk must provide at least 32 GB of persistent storage such as an HDD, SSD, or NVMe device:

On smaller media the boot banks shrink (500 MB each on 8-10 GB devices and 1 GB on 10-32 GB devices), but those devices fall below the 32 GB boot-disk requirement for ESXi 8.0. If a high-endurance boot device is larger than 142 GB, the installer also creates a local VMFS datastore in the leftover space. The installer boot option systemMediaSize can cap the system storage size, down to a 32 GB minimum.

ESX-OSData holds two kinds of data. Persistent data is written infrequently: VMware Tools ISOs, configuration, and core dumps. Non-persistent data is written constantly: logs, VMFS global traces, vSAN traces, and real-time databases. That constant write load is why boot-media endurance matters.

Deprecation of USB and SD Card Boot Devices

Historically, administrators deployed ESXi on cheap USB flash drives or dual-SD card modules (IDSDM). In ESXi 8.0, SD cards and USB devices are supported only for the boot-bank partitions. Keeping ESX-OSData on them is deprecated, and new server platforms that boot from SD cards are no longer certified. ESX-OSData takes continuous writes for logs and traces, and low-endurance flash wears out quickly under that load (its Terabytes Written, or TBW, rating is exhausted), which leads to read-only boot devices and host disconnects.

For production vSphere 8 deployments, the recommended boot devices are:

• M.2 NVMe or M.2 SATA Enterprise SSDs
• Dedicated SAS/SATA Enterprise SSDs in a hardware RAID 1 mirror
• SAN Boot via Fibre Channel (FC), FCoE, or hardware/software iSCSI LUNs

Exam Trap: If a legacy server still boots from an SD card or USB device, VMware's best practice is to put ESX-OSData on a separate persistent local device of at least 32 GB that is not shared with other hosts. If no persistent OSDATA location exists, the host keeps that data on non-persistent storage and shows warnings in the vSphere Client.

vCenter Server Agent Architecture: hostd, vpxa, and vpxd

vCenter Server provides centralized management for multiple ESXi hosts, clusters, virtual machines, and software-defined storage/networking resources. When an administrator performs an action in the vSphere Client—such as powering on a virtual machine or creating a distributed port group—that request traverses a specific chain of communication daemons across the network.

+---------------------------------------------------------------------------------+
| Administrator / API Client                                                      |
|                         | HTTPS / Port 443                                      |
|                         v                                                       |
| vCenter Server Appliance (vCSA)                                                 |
|   [ vpxd: vCenter Server Daemon ]                                               |
|                         | HTTPS / Port 443 (Management Traffic)                 |
|                         | UDP / Port 902 (heartbeat every 10 s)                 |
|                         v                                                       |
| ESXi Host (User World)                                                          |
|   [ vpxa: vCenter Agent Daemon ]                                                |
|                         | Local host API calls                                  |
|                         v                                                       |
|   [ hostd: ESXi Host Daemon ]                                                   |
|                         | Direct Kernel Calls                                   |
|                         v                                                       |
| ESXi VMkernel (Core Hypervisor Services)                                        |
+---------------------------------------------------------------------------------+

Management Daemon Roles & Communication Paths

• vCenter Server Daemon (vpxd): The primary service executing inside the vCenter Server Appliance. It maintains the centralized PostgreSQL inventory database, schedules enterprise cluster operations (vSphere HA, vSphere DRS), and communicates with managed ESXi hosts.
• vCenter Agent (vpxa): A daemon installed directly into the ESXi user world when the host is added to vCenter inventory. vpxa acts as the middleman between vCenter and the local host. It receives commands from vpxd over TCP port 443 and sends a UDP heartbeat to vCenter on port 902 every 10 seconds. If vCenter receives no heartbeat for 60 seconds, it marks the host Not Responding. A host that disconnects at 60-second intervals usually has UDP 902 blocked by a firewall.
• ESXi Host Daemon (hostd): The native user-world management daemon on the ESXi host. hostd directly manages local host hardware, registers and powers virtual machines, monitors local tasks, and serves the direct web-based ESXi Host Client UI (https://<esxi-fqdn>/ui). When vpxa receives an instruction from vCenter, it translates the request into local host API calls that hostd carries out.

Management Agent Troubleshooting

When an ESXi host enters a "Not Responding" state in vCenter Server while its virtual machines remain running and pingable, the issue frequently stems from a failure in vpxa, hostd, or underlying network connectivity on port 443.

To restore management connectivity without interrupting running guest workloads, administrators can restart the management daemons:

1. Via the Direct Console User Interface (DCUI): Press F2 -> log in as root -> select Troubleshooting Options -> select Restart Management Agents.
2. Via ESXi Shell or SSH: Execute the command /sbin/services.sh restart, or restart the services individually:

   /etc/init.d/hostd restart
   /etc/init.d/vpxa restart
   

Virtual Machine Internal Architecture and Core Files

A virtual machine (VM) is an isolated software container that executes a guest operating system and applications. To the underlying ESXi hypervisor, every powered-on virtual machine is represented by a dedicated user-world process called the VMX process (vmx). The VMX process manages virtual hardware emulation, interfaces with the VMkernel for CPU and memory scheduling, and coordinates I/O with virtual disk controllers.

Virtual Hardware Version 20 (vHW 20)

vSphere 8.0 introduced Virtual Hardware Version 20. Hardware version 20 is the default compatibility level for new VMs on ESXi 8.0 hosts and carries the platform's current capabilities:

• Maximum Virtual Compute: Up to 768 vCPUs and 24 TB of memory per VM. These maximums first arrived with hardware version 18 in vSphere 7.0 Update 1 (vSphere 7.0 GA stopped at 256 vCPUs); hardware version 20 keeps them.
• Virtual TPM 2.0 (vTPM): Available since hardware version 14 and required by operating systems such as Windows 11. vSphere 8 adds a vTPM provisioning policy that decides whether a clone copies the source VM's vTPM or receives a new one.
• Device Groups: Ability to group multiple PCIe devices—such as NVIDIA vGPUs sharing NVLink interconnects—so they are assigned and scheduled together onto the same physical ESXi host.
• Latency Sensitivity with Hyper-threading: A vSphere 8 option for jitter-sensitive workloads such as telecom and trading systems.

Core Virtual Machine Files

A virtual machine's configuration, state, and virtual storage reside as files within a dedicated directory on a VMFS, NFS, or vSAN datastore:

Exam Trap: Pay close attention to .vswp file sizing. If a VM is allocated 32 GB of vRAM with 0 GB reserved, ESXi creates a 32 GB .vswp file on the datastore at power-on. If the datastore lacks 32 GB of free space, the VM fails to power on with an "insufficient disk space" error. If 32 GB of vRAM is 100% reserved, the swap file size is 0 bytes.

Realistic Failure Scenarios & Troubleshooting

Scenario 1: The Disconnected Host in vCenter

Problem: In the vSphere Client inventory, an ESXi 8.0 host displays a status of "Not Responding". However, network administrators verify that the host's management IP responds to ICMP echo requests (ping), and all virtual machines running on the host continue serving production traffic normally.

Root Cause Analysis:

• Virtual machines run directly under the VMkernel and their respective vmx processes. They do not depend on hostd or vpxa to process tenant network packets or disk I/O.
• The "Not Responding" status indicates that vCenter's vpxd daemon has lost communication with the host's vpxa agent, or vpxa cannot contact hostd.
• Frequent culprits include vpxa thread exhaustion, an unresponsive hostd daemon hung on a non-responsive storage path (All Paths Down / APD condition), or a network firewall blocking UDP port 902 heartbeats.

Resolution Procedure:

1. Establish an SSH connection to the affected ESXi host or open the physical console via DCUI.
2. Verify hostd status: /etc/init.d/hostd status (ESXi does not use systemd) or inspect /var/log/hostd.log.
3. Verify vpxa status: /etc/init.d/vpxa status or inspect /var/log/vpxa.log.
4. Restart the management agents via command line: /sbin/services.sh restart.
5. In the vSphere Client, right-click the disconnected host and select Connection -> Connect.

Scenario 2: Flash Wearout on Legacy Boot Media

Problem: An administrator upgrades a cluster of hosts booting from dual-SD cards to ESXi 8.0. Within weeks, several hosts log I/O errors against their boot devices, and some eventually lose access to them entirely.

Root Cause Analysis:

• ESXi 8.0 consolidates operational logging, core dumps, and scratch memory onto the unified OSDATA partition.
• Low-endurance SD cards and USB drives cannot sustain that continuous write load, so their flash cells wear out. This is exactly why ESXi 8.0 deprecates keeping ESX-OSData on such media.

Resolution Procedure:

1. Retrofit ESXi physical servers with enterprise-class M.2 NVMe or high-TBW SATA SSD boot devices.
2. Reinstall ESXi 8.0 using the dedicated enterprise flash devices.
3. As an interim measure until the hardware is replaced, point the scratch location at persistent storage with the advanced host option ScratchConfig.ConfiguredScratchLocation (use a unique directory per host).