Skip to content

ESXi Architecture Overview

This section documents the architecture and design decisions related to provisioning and managing VMware ESXi using Digital Rebar Provision.

ESXi Provisioning Differences

ESXi provisioning in DRP differs fundamentally from Linux provisioning. Standard Linux distributions expose a network installer (Anaconda, d-i, Subiquity) that can be fully automated via kickstart or preseed files served by DRP's template system. ESXi does not use a standard network installer in the same way: it uses a scripted install mechanism driven by a ks.cfg (kickstart) file, but the ESXi installer itself is a VMware-supplied ISO that must be repackaged or served in a specific format for PXE-based installation.

DRP handles this through a dedicated ESXi BootEnv that:

  1. Serves the ESXi installer kernel and modules over TFTP/HTTP using the format VMware's bootloader expects.
  2. Renders a machine-specific ks.cfg from DRP's template system, embedding the root password, network configuration, datastore layout, and post-install script.
  3. Directs the ESXi installer to fetch the ks.cfg from DRP's static file server at boot time.

Because the ESXi kickstart format is VMware-specific, the templates for ESXi BootEnvs are separate from Linux kickstart templates, and the available configuration options reflect ESXi's installer capabilities rather than Linux's.

Agent Installation and Join-up

ESXi does not support a native Linux-style init system, so the DRP machine agent cannot be installed as a standard systemd service. Instead, agent installation follows the Case 3 join-up pattern: after the ESXi installer finishes and the hypervisor boots for the first time, the ESXi kickstart post-install section downloads the DRP agent (a Python-based runner in ESXi environments), writes the DRP endpoint configuration, and starts the agent as a long-running process via the local script invocation.

Once the agent is running, it connects to DRP and drives the machine through any post-install configuration tasks — for example, configuring vSwitch settings, joining a vCenter, setting VLAN tagging on uplinks, or enabling SSH for management. These tasks execute as DRP workflow steps in the same task-chain model used for Linux machines, with results recorded as job logs and parameter updates on the Machine object.

Post-Install Configuration Patterns

Post-install ESXi configuration in DRP uses the same workflow model as any other OS. A typical ESXi application workflow includes:

  • Network configuration — VLAN, vSwitch, MTU, and NIC teaming settings applied via esxcli commands embedded in DRP task templates.
  • Storage configuration — datastore creation, NFS mount, or iSCSI initiator setup.
  • vCenter registration — joining the ESXi host to a vCenter inventory using credentials injected from DRP parameters (kept in secure/encrypted profile params).
  • Hardening and compliance — applying CIS or STIG baseline settings via task templates that run esxcli or vim-cmd commands.

All of these tasks are parameterized, allowing the same task templates to be applied differently based on the machine's role, location, or hardware profile — following the same Universal Workflow classification and FlexiFlow extension model used for other operating systems.

Available Topics

  • ESXi Node Ready Details the system state and prerequisites for a node to be considered ready for ESXi deployment.

  • Vibless Install Discussion Explains the rationale and technical approach behind removing the dependency on VIBs for ESXi provisioning.

More documents will be added here as the ESXi architecture evolves.