2.1 ESXi Host & vCenter Architecture and Deployment

2.1 ESXi Host & vCenter Architecture and Deployment

Exam Focus: In VMware Cloud Foundation (VCF) 9.0, hypervisor architecture, secure host onboarding, centralized vCenter administration, and cluster lifecycle management form the bedrock of private cloud compute infrastructure. For the VCP-VCF (2V0-17.25) exam, candidates must master the internal architecture of ESXi 9.0, physical hardware prerequisites for VCF commissioning, modern system storage partitioning and boot media requirements, host security lockdown modes, vCenter Server Appliance (VCSA) deployment sizing and microservices, and the declarative desired-state lifecycle model enforced by vSphere Lifecycle Manager (vLCM).

---

ESXi 9.0 Bare-Metal Hypervisor Architecture

The VMware ESXi hypervisor represents an enterprise Type-1 bare-metal hypervisor architecture engineered for high performance, hardware isolation, and minimal attack surface. Operating without an underlying general-purpose operating system, the ESXi core engine is the VMkernel (vmkernel). The VMkernel schedules CPU execution, orchestrates physical and virtual memory allocation, handles hardware interrupts, and mediates network and storage I/O through modular device drivers (VMkernel device drivers).

Key architectural layers of ESXi 9.0 include:

• VMkernel Core: Directly controls physical hardware resources (CPU, NUMA nodes, RAM, PCIe buses). It implements a non-preemptive, prioritized scheduling engine optimized for symmetric multiprocessing (SMP) virtual machines.
• Userworld Processes: Sandboxed user-space processes running on top of the VMkernel. These include management daemons such as hostd (ESXi host management daemon), vpxa (vCenter Server management agent), syslogd (system logging daemon), and ntpd / ptpd (time synchronization daemons).
• vSphere Distributed Services Engine (DSE): Modern ESXi architectures support offloading core infrastructure workloads—including NSX virtual networking, Geneve encapsulation/decapsulation, and Distributed Firewall (DFW) packet filtering—to Data Processing Units (DPUs, also known as SmartNICs). By offloading these services to on-NIC ARM processors, ESXi frees up host x86 CPU cores for application execution while delivering wire-speed security and network throughput.
• Direct Driver Model: ESXi communicates with physical Network Interface Cards (NICs) and Host Bus Adapters (HBAs) using native VMkernel drivers. Legacy Linux-based driver wrappers (vmnix) are entirely absent, ensuring a lean footprint (under 300 MB for core hypervisor files) and heightened security.

---

VCF Physical Host Prerequisites & Commissioning Standards

Before an ESXi host can be commissioned into a VMware Cloud Foundation workload domain via SDDC Manager, the physical host must satisfy stringent hardware prerequisites:

• Certified Hardware & ReadyNode Specification: Physical hosts must comply with the VMware Compatibility Guide (VCG) and ideally align with vSAN ReadyNode profiles (guaranteeing validated CPU, memory, storage controller, and NVMe/SSD drive configurations).
• Management Domain Minimum Host Footprint: A VCF Management Domain cluster requires a strict minimum of four physical ESXi hosts to guarantee high availability and accommodate vSAN FTT=1 (RAID-1 mirroring or RAID-5 erasure coding) alongside maintenance tolerance.
• Network Interface Redundancy: Each host must be equipped with at least two high-speed physical network interfaces (dual 10 GbE, 25 GbE, or 100 GbE NICs) assigned to a vSphere Distributed Switch (vDS) to carry management, vSAN, vMotion, and Geneve overlay traffic with hardware redundancy.
• Out-of-Band Management: Dedicated out-of-band management interfaces (such as Dell iDRAC, HPE iLO, or standard IPMI) must be configured with static IP addresses and accessible to SDDC Manager for automated power cycling, commissioning, and firmware lifecycle operations.
• Time Synchronization & Name Resolution: Strict network time protocol (NTP) synchronization across all hosts, vCenter instances, and SDDC Manager is mandatory; time drift exceeding 5 minutes causes severe authentication failures in VMware Identity Services (STS tokens). Furthermore, bidirectional forward and reverse DNS resolution (A and PTR records) must be established prior to commissioning.

---

Modern ESXi System Storage Partitions & Boot Media

Modern ESXi architectures dynamically consolidate system storage into four primary functional partitions:

1. System Boot (BOOT) - 100 MB (FAT16): Houses the bootloader, EFI binaries, syslinux configuration, and encryption keys.
2. Bootbank 0 - 4 GB (FAT16): Stores the active ESXi hypervisor system image, base VIBs (vSphere Installation Bundles), core drivers, and system packages.
3. Bootbank 1 - 4 GB (FAT16): Serves as the backup/alternate bootbank. When ESXi is upgraded or patched, the new image installs into Bootbank 1 while Bootbank 0 remains intact. If a failure or incompatibility occurs during boot, administrators can roll back to the prior known-good build by pressing Shift+R during the boot phase.
4. ESX-OSData (OSDATA) - Dynamically Sized (up to hundreds of gigabytes, VMFS-L): The foundational unified partition formatted with VMFS-L (Local Virtual Machine File System). ESX-OSData dynamically manages two distinct data classes:
   • Volatile Data (var-volatile): High-frequency write data including system logs (/var/log), runtime state information, system traces, and live core dumps (/var/core).
   • Non-Volatile Data (var-nonvolatile): Persistent storage for ESXi scratch space, system locker (containing VMware Tools ISO packages and floppy drivers), and VM-level state stores.

Boot Media Requirements & USB/SD Card Deprecation

[!IMPORTANT] Boot Media Deprecation & Host Stability: VMware officially deprecated standalone USB flash drives and SD cards as primary boot media starting in ESXi 7.0 Update 3 and strictly enforces high-endurance media in ESXi 8.0/9.0. The unified ESX-OSData partition generates continuous write I/O for logging and diagnostic dumps. When deployed on low-endurance flash media, the drive enters a read-only state, causing management agent disconnects (hostd lockup), host disconnects from vCenter, and potential Purple Screen of Death (PSOD) kernel crashes. VCF commissioning requires dedicated persistent media of at least 32 GB, with 128 GB or larger recommended.

---

Host Security: Normal vs. Strict Lockdown Mode

Lockdown Mode secures ESXi hosts against unauthorized direct administrative configuration, ensuring that administrative actions flow exclusively through the centralized control and auditing capabilities of vCenter Server.

• Normal Lockdown Mode:
  • The ESXi host can only be managed directly through vCenter Server via vpxa.
  • Direct web access via the VMware Host Client (embedded UI) and SSH connections are blocked for regular administrative accounts.
  • The Direct Console User Interface (DCUI) service remains active. Users listed in the DCUI.Access advanced system configuration (by default, root) can still authenticate at the physical keyboard/monitor console. This permits an administrator to recover host networking or restart management agents if the vCenter Server becomes inaccessible.
• Strict Lockdown Mode:
  • The ESXi host can only be managed through vCenter Server.
  • The DCUI service is stopped and disabled entirely.
  • Even physical access via console/KVM is blocked; attempting to access the DCUI displays a notice that the service is disabled.
  • Recovery Caveat: If an ESXi host in Strict Lockdown Mode permanently loses connection to its managing vCenter Server, it cannot be restored via the console. The connection to vCenter must be restored at the network layer, or the host management agents must be recovered via automated configuration scripts or hypervisor reinstallation.
• Exception Users:
  • Accounts defined in the Exception Users list retain direct host-level access regardless of whether Normal or Strict lockdown is active.
  • Exception users are intended exclusively for service accounts, such as third-party storage multipathing agents, hardware monitoring agents (e.g., Dell OpenManage, HPE Agentless Management Service), or backup appliances that require direct hypervisor API interaction. Exception users should never be assigned to human administrator accounts.

[!WARNING] Strict Lockdown Mode Inaccessibility Trap: If an ESXi host in Strict Lockdown Mode loses network connectivity to its managing vCenter Server, administrators cannot access the Direct Console User Interface (DCUI) to restore networking because the DCUI service is completely stopped. Physical console access is blocked. Connection recovery requires repairing network uplinks at the physical switch level or reinstalling ESXi.

---

vCenter Server Appliance (VCSA) Architecture & Deployment Sizing

The vCenter Server Appliance (VCSA) is a pre-configured, hardened 64-bit Linux virtual appliance running VMware Photon OS. In VMware Cloud Foundation, SDDC Manager automates the deployment and configuration of VCSA instances for the Management Domain and all subsequent Virtual Infrastructure (VI) Workload Domains.

VCSA Compute and Storage Sizing Profiles

When deploying or upgrading VCSA, administrators select an appliance deployment profile based on the planned inventory scale of ESXi hosts and virtual machines:

In addition to compute sizing, storage tiers (Default, Large, and X-Large) can be selected independently. Storage tiers determine the capacity allocated for SEAT data: Stats (performance metrics), Events, Alarms, and Tasks. Selecting a larger storage tier enables longer historical retention periods for performance metrics without risking disk space exhaustion on /storage/seat.

---

Core vCenter Server Services and Daemons

The VCSA architecture relies on the VMware Service Lifecycle Manager (vmon) to supervise and maintain internal microservices and daemons:

• vpxd (vCenter Server Daemon): The central heart of vCenter Server. It coordinates the global virtual machine inventory, manages tasks and alarms, maintains state synchronization with ESXi host agents (vpxa), and dispatches API commands.
• vSphere Client (vsphere-ui): The modern, HTML5-based graphical administrative interface. It communicates with vpxd via reverse-proxy API calls and manages user interaction.
• vmware-vpostgres: The embedded relational PostgreSQL database storing the entire vCenter object hierarchy, inventory relationships, historical tasks, events, and performance statistics.
• vmdir (VMware Directory Service) & VMware STS: Foundational identity components providing Single Sign-On (SSO), domain federation, and SAML token generation for authentication between vCenter, SDDC Manager, NSX, and external identity providers.
• vmware-updatemgr: The backend service supporting vSphere Lifecycle Manager (vLCM), executing cluster baseline compliance checks, image catalog synchronizations, and host upgrade remediations.
• content-library: Centralized catalog service for synchronizing VM templates, ISO images, and OVF/OVA packages across multiple vCenter instances in a Cloud Foundation environment.

Administrators monitor and manage these services from the appliance bash shell using service-control commands (such as service-control --status and service-control --stop/start <service-name>) or the vmon-cli utility.

---

vSphere Lifecycle Manager (vLCM) vs. Legacy Baselines

Managing hypervisor software versions and hardware firmware at enterprise scale is governed by vSphere Lifecycle Manager (vLCM). VCF 9.0 standardizes entirely on declarative, cluster-level desired state images, superseding the legacy baseline model previously provided by vSphere Update Manager (VUM).

The Declarative vLCM Cluster Image Architecture

A vLCM cluster image applies a uniform, version-locked software specification to all ESXi hosts within a vSphere cluster. A complete vLCM image consists of four modular components:

1. ESXi Base Image: The core hypervisor release published by VMware/Broadcom (e.g., ESXi 8.0 Update 3 or ESXi 9.0 GA).
2. Vendor Add-on: A bundled package certified by server hardware OEMs (e.g., Dell, HPE, Lenovo, Cisco) containing manufacturer-specific device drivers, management CIM providers, and diagnostic utilities tailored to the server hardware family.
3. Additional Components: Individual VIBs or component bulletins added by the administrator, such as NSX transport node components, third-party storage multipathing software (e.g., Dell PowerPath), or backup agents.
4. Hardware Support Package (HSP): An integrated hardware management definition linking vLCM to vendor-specific Hardware Support Managers (HSMs, such as Dell OpenManage Integration for VMware vCenter - OMIVV, or HPE OneView). The HSP enables vLCM to orchestrate server firmware updates (BIOS, iDRAC/iLO, RAID controller, and NIC firmware) concurrently with hypervisor software upgrades during a single host maintenance cycle.

Operational Advantages Over Legacy Baselines

Legacy VUM baselines operated imperatively: administrators attached multiple separate patch baselines, extension baselines, and upgrade baselines to individual hosts or clusters. This frequently resulted in configuration drift, where hosts in the same cluster ran divergent patch combinations.

In contrast, vLCM operates on a declarative model:

• Zero Configuration Drift: Any host joining the cluster is validated against the cluster image; if deviations exist, vLCM marks the host as non-compliant and remediates it to match the exact image specification.
• Hardware Compatibility Checking: vLCM integrates with the VMware Compatibility Guide (VCG) and vSAN Hardware Compatibility List (HCL), automatically checking physical NIC, storage controller, and drive firmware against the target ESXi version before remediation begins.
• Integrated SDDC Manager Orchestration: In VCF, SDDC Manager leverages vLCM cluster images as the foundational mechanism for rolling cluster lifecycle updates across all Management and VI Workload Domains.