2.2 ESXi Deployment, DCUI & Initial Host Configuration

2.2 ESXi Deployment, DCUI & Initial Host Configuration

Deploying and configuring the VMware ESXi hypervisor represents the foundational step in establishing an enterprise private cloud with VMware vSphere Foundation (VVF). A standardized, security-hardened installation ensures cluster stability, simplifies vCenter Server registration, and prevents common network and identity failures.

---

ESXi Installation Methods & Deployment Architecture

VMware ESXi can be deployed onto physical server hardware using three primary installation methodologies depending on datacenter scale and automation requirements:

1. Interactive Installation

Interactive installation is commonly employed for small-scale deployments, pilot environments, or single-host provisioning:

• Media Delivery: The ESXi installer ISO image is booted via a bootable USB flash drive, physical DVD-ROM, or out-of-band server management virtual media (HPE iLO, Dell iDRAC, Cisco IMC, Lenovo XClarity).
• Workflow: The installer boots an in-memory runtime environment, detects hardware; administrators must independently check it against the Broadcom Compatibility Guide, prompts the administrator to accept the End User License Agreement (EULA), select a target local or SAN storage drive, choose a default keyboard layout, and specify the root administrative password (meeting the configured password quality policy).

2. Scripted Installation (Kickstart)

Scripted installation provides automated, unattended ESXi provisioning across dozens or hundreds of identical servers:

• Kickstart File (ks.cfg): Administrators define a text configuration file specifying target disk selection, keyboard layouts, root password encryption, static network parameters (IP address, subnet mask, gateway, VLAN, DNS), NTP servers and custom %post Python or shell scripts.
• Boot Parameters: During host PXE or media boot, the installer is directed to the script location using bootloader parameters (such as boot.cfg or appending ks=http://config-server/ks.cfg or ks=usb:/ks.cfg).

3. vSphere Auto Deploy

For large-scale, enterprise-grade private cloud environments, vSphere Auto Deploy enables centralized, network-based ESXi host provisioning:

• Architecture: Auto Deploy leverages network PXE booting (DHCP and TFTP) to load an ESXi image directly from vCenter Server into host RAM.
• Image Profiles & Host Profiles: An Image Profile defines the ESXi base build and vendor VIB packages (device drivers, firmware agents), while a Host Profile injects host-specific networking, storage, and security configurations.
• Stateless vs. Stateful Provisioning: Hosts can boot statelessly (retaining no local disk state and streaming the OS on every reboot), utilize stateless caching (caching the boot image on local disk as a safeguard against network or vCenter outages), or execute stateful installations (installing directly to local disks via Auto Deploy).

ESXi System Storage Architecture

Modern ESXi versions utilize a streamlined, consolidated system storage partition layout on the boot disk:

• System Boot (BOOTBANK1 & BOOTBANK2): Two alternating 32-bit FAT boot banks (typically 1 GB each) containing the active ESXi boot image and previous fallback image for seamless upgrade rollbacks.
• OSDATA (Operating System Data): A high-capacity partition formatted with VMFS-L (ranging from 32 GB up to hundreds of gigabytes depending on target drive size). It consolidates system core dumps (dump partitions), host diagnostic logs (/var/log), ESXi system scratch space, and the system locker containing VMware Tools packages and ISO images.

---

Direct Console User Interface (DCUI) Navigation & Network Setup

The Direct Console User Interface (DCUI) is the text-based console interface displayed on physical monitor attachments or out-of-band virtual console sessions (iLO/iDRAC/KVM). The DCUI is designed specifically for initial baseline setup, emergency out-of-band administration, and disaster recovery.

====================================================================
                      VMware ESXi 9.0.0                             
                      Dell PowerEdge R760                           
                      Intel Xeon Gold 6430 @ 2.10GHz                
                      512 GB Memory                                 

  To manage this host go to:                                       
    https://esx-01a.corp.local/ (IPv4)                             
    https://[fe80::250:56ff:fe80:1]/ (IPv6)                        

  <F2> Customize System / View Logs                                
  <F12> Shut Down / Restart                                        
====================================================================

DCUI Access & Keybindings

• <F2> (Customize System / View Logs): Prompts for administrative credentials (root) to unlock host configuration menus.
• <F12> (Shut Down / Restart): Initiates a controlled host power down or hypervisor reboot. If the host is managed by vCenter Server and running active VMs, it prompts for confirmation or requests maintenance mode.
• <Alt+F1> / <Alt+F2>: Toggles between the interactive DCUI console (<Alt+F2>) and the local ESXi Shell terminal (<Alt+F1>) when local shell access is enabled.

Configuring the Management Network

Before an ESXi host can be reached across the corporate network or added to vCenter Server, its primary management interface must be established:

1. Network Adapters (Uplinks): Administrators select the physical network interface cards (e.g., vmnic0, vmnic1) assigned to the default Management Network port group on standard virtual switch vSwitch0. Assigning dual uplinks provides hardware redundancy against switch port or cable failures.
2. VLAN Tagging (Virtual Switch Tagging - VST): If management traffic traverses an 802.1Q trunk port on the physical top-of-rack (ToR) switch, the administrator must configure the management VLAN ID directly in the DCUI. Setting the VLAN ID instructs vSwitch0 to tag outgoing management packets and strip inbound tags.
3. IPv4 & IPv6 Configuration: Assign a static IPv4 address, subnet mask, and default gateway. While DHCP is supported for initial bootstrapping, production enterprise standards dictate static IP configurations to prevent lease expirations from isolating cluster nodes.
4. DNS Configuration: Specify the primary and secondary DNS server IP addresses and the host's fully qualified domain name (FQDN), such as esx-01a.corp.local. Proper reverse DNS (PTR) and forward DNS (A) records must exist prior to adding the host to vCenter Server.

---

Mission-Critical Time Synchronization: Network Time Protocol (NTP)

Precision time synchronization across all physical ESXi hosts, vCenter Server instances, identity providers, and storage arrays is a non-negotiable architectural requirement in VMware vSphere Foundation.

Consequences of Clock Skew

Consistent time supports authentication-token and certificate validation and makes cross-system logs comparable. Large drift can cause authentication or TLS failures. Keep configured time sources reachable and verify synchronization; do not assume every connectivity error is a clock fault or that a universal drift threshold governs every service. NTP does not replace network redundancy or establish vSAN voting quorum.

Configuring NTP

Administrators should configure at least two reliable, stratum-1 or stratum-2 NTP servers:

• VMware Host Client: Navigate to Manage > System > Time & Date, enter NTP server FQDNs/IPs, set the startup policy to Start and stop with host, and start the ntpd service.
• ESXi Shell / CLI:

  esxcli system ntp server add --server=ntp.corp.local
  esxcli system ntp set --enabled=true
  

---

Administrative Access, Shell Hardening & Lockdown Modes

By default, ESXi enforces a hardened security posture. Out-of-the-box, remote command-line services are disabled to minimize the host attack surface.

ESXi Shell and SSH Services

• ESXi Shell: The local text terminal interface (<Alt+F1>). Useful for direct console maintenance when network access is severed.
• SSH (TSM-SSH): Remote command-line access over TCP port 22.
• Hardening Guidelines: Both services should remain Stopped during normal operations. When enabled for troubleshooting, administrators must configure automatic session termination timeouts via advanced settings:
  • UserVars.ESXiShellTimeOut: Number of seconds after which the Shell/SSH service automatically stops.
  • UserVars.ESXiShellInteractiveTimeOut: Number of seconds of inactivity before an open shell session is automatically terminated.

Lockdown Mode Security Tiers

When an ESXi host is registered into vCenter Server, administrators can enforce Lockdown Mode to prevent rogue or un-audited configurations from being applied directly to the host:

Exception Users

Exception Users are specific administrative or service accounts (e.g., third-party backup proxies, hardware monitoring daemons) configured in vCenter Server that retain direct API permissions to the ESXi host regardless of whether Normal or Strict Lockdown Mode is enforced. Exception users should never be assigned to standard human administrators.

---

Host Management Interfaces & Troubleshooting Connectivity

VMware Host Client vs. vCenter Server

While vCenter Server provides centralized multi-host cluster governance, Distributed Resource Scheduler (DRS), High Availability (HA), and distributed virtual switches, the standalone VMware Host Client is an HTML5 interface running directly out of the host's UserWorld via hostd (https://<host-ip>/ui):

• Bootstrap Deployment: Utilized to deploy the initial vCenter Server Appliance (VCSA) virtual machine onto a greenfield ESXi host.
• Disaster Recovery: Utilized to manage a single host when vCenter Server is down, offline, or inaccessible.
• Local Datastore & Storage Configuration: Initializing local SSDs and configuring local VMFS datastores prior to cluster formation.

Diagnose Connectivity Before Restarting Services

For a Not Responding host whose VMs still run, first check management reachability, VLAN and uplink state, DNS, time, certificate status, resource pressure and relevant logs. Continuing guest execution does not prove that a management daemon is hung.

The DCUI management-network test checks configured network and DNS targets. A management-network restart changes connectivity and needs recovery access. It is not a general test of NTP service health.

If evidence identifies a failed management service, follow Broadcom KB 320280. On hosts using vSAN, LACP, NSX or shared graphics, do not run services.sh restart or the blanket DCUI Restart Management Agents action. Restart only the affected service using the documented procedure, such as hostd or vpxa, after considering active operations. Even individual restarts can interrupt management tasks or affect workload performance. Verify service recovery and host state afterward; never promise a risk-free restart.

Review Takeaways

• Validate server and device support before installing ESX.
• Use the DCUI for initial management-network setup and documented recovery tasks.
• Verify DNS and time synchronization separately from basic network reachability.
• Diagnose a Not Responding host before restarting services; blanket restarts are prohibited on vSAN, LACP, NSX and shared-graphics hosts.