VMware ESXi and vSphere Cluster Management

What Is VMware ESXi? Type 1 Hypervisor Architecture and Core Concepts

Learn what VMware ESXi is, how its Type 1 hypervisor and VMkernel work, how it virtualizes resources, and how it differs from hosted hypervisors.

VMware ESXi is VMware’s bare-metal, or Type 1, hypervisor. It is installed directly on supported physical server hardware instead of running inside a conventional operating system. ESXi allows multiple independent virtual machines (VMs) to share one physical server while keeping their operating systems and applications logically isolated.

ESXi is the foundational hypervisor layer in a VMware vSphere environment. An ESXi host runs VMs; optional components such as vCenter Server provide centralized management for multiple hosts.

What Is a Hypervisor?

A hypervisor is a software or firmware-layer technology that creates, runs, isolates, and manages virtual machines. It controls how VMs use physical CPU, memory, storage, and networking resources.

A physical host, often shortened to host, is the physical server on which a hypervisor is installed. A virtual machine is an isolated, software-defined computer. It has virtual CPU, memory, storage, network interfaces, and other virtual hardware. The operating system installed inside it is the guest operating system. Applications run inside the guest operating system as they would on a physical computer.

For example, one physical server could host a Linux web-server VM, a Windows application-server VM, and a database VM. Each VM can have its own operating system, applications, users, and configuration.

Type 1 and Type 2 Hypervisors

A Type 1 hypervisor runs directly on physical hardware. It is also called a bare-metal hypervisor. ESXi is designed for servers and datacenter environments.

A Type 2 hypervisor runs as an application inside a conventional host operating system such as Windows, Linux, or macOS. VMware Workstation and Oracle VirtualBox are common Type 2 examples. A Type 2 hypervisor is useful for desktop testing, software development, training, and laboratories.

Characteristic | Type 1 / Bare-Metal | Type 2 / Hosted | Example

Where it runs | Directly on physical server hardware | Inside a general-purpose host operating system | ESXi versus Workstation

Host operating system dependency | Does not require a general-purpose operating system beneath the hypervisor | Depends on the host operating system, its drivers, and its updates | VirtualBox uses Windows, Linux, or macOS resources

Typical environment | Production servers and datacenters | Desktops, developer machines, labs, and test systems | ESXi in a rack server; VirtualBox on a laptop

Hardware interaction | The hypervisor manages hardware through its own virtualization layer and supported drivers | The host operating system mediates access to hardware | Different performance and device-support paths

Operational use | Centralized server operations, workload consolidation, and VM infrastructure | Convenient local VM creation and experimentation | vSphere hosts versus desktop testing

The distinction is about the software stack, not simply whether a VM is used. A Type 1 design generally removes the extra general-purpose operating-system layer and is optimized for server operations. Performance still depends on hardware, configuration, workload, drivers, storage, and network design.

ESXi Architecture and the VMkernel

The VMkernel is the core ESXi kernel. It receives resource requests from running VMs and coordinates access to physical hardware. It provides hardware abstraction: a VM uses standardized virtual devices while ESXi maps those devices to supported physical resources.

Layer | Main Components | Responsibility

Guest layer | Applications and guest operating system | Runs workloads and issues requests to virtual devices

Virtual hardware layer | vCPUs, virtual memory, virtual disks, and virtual NICs | Presents a consistent computer-like hardware interface to the VM

ESXi VMkernel layer | CPU scheduler, memory manager, storage and network virtualization | Isolates VMs and brokers their access to host resources

Physical hardware layer | CPUs, RAM, storage devices, controllers, and network adapters | Supplies the underlying compute, memory, storage, and network capacity

The basic request path is:

  1. An application in a guest operating system requests a resource.
  2. The guest OS uses the VM’s virtual hardware.
  3. ESXi’s VMkernel interprets and schedules the request.
  4. The VMkernel accesses an appropriate physical resource.
  5. The result is returned to the VM through its virtual device.

VMs do not normally control the underlying host hardware directly. This abstraction helps different guest operating systems run on the same server and allows ESXi to enforce isolation and resource policies.

How ESXi Virtualizes Resources

Physical Resource | ESXi Virtualization Concept | VM-Facing Example

CPU | ESXi schedules virtual processors on physical processor execution resources | A VM is assigned one or more vCPUs

Memory | ESXi maps and manages VM memory against host RAM | A VM is configured with a defined amount of virtual memory

Storage | ESXi exposes datastores and virtual disks backed by storage resources | A VM sees a virtual disk rather than a physical disk controller

Networking | ESXi uses virtual switches and physical uplinks to connect VM traffic | A VM uses a virtual network interface card, or vNIC

CPU Virtualization

A vCPU is a virtual processor assigned to a VM. ESXi schedules vCPUs on the host’s physical CPU resources. The number of vCPUs assigned should reflect the workload; assigning more vCPUs than necessary can increase scheduling overhead and reduce available capacity.

A logical CPU is a processor execution context recognized by the host, including contexts provided by simultaneous multithreading where applicable. Logical CPUs are not the same as guaranteed performance units. Workload demand, CPU frequency, scheduling, and contention also matter.

Memory Virtualization

ESXi allocates host RAM to VMs and maintains the mappings needed for guest memory access. Each VM sees its configured virtual memory, while ESXi manages how that memory is backed by physical RAM and how competing VMs are handled.

Storage Virtualization

A datastore is a storage container made available to ESXi for VM files, virtual disks, configuration files, and related data. A VM typically sees a virtual disk file or device. The datastore may ultimately use local disks, shared storage, or another supported storage system.

Networking Virtualization

A virtual NIC is the network adapter presented to a VM. A virtual switch is a software-based switching construct that connects VMs to one another and to physical network adapters, also called uplinks. VLANs, port groups, and physical switch settings determine how traffic is connected and separated.

Sharing and Isolation

ESXi allows VMs to share a host’s resources while maintaining logical separation between them. Sharing does not create unlimited capacity. If too many VMs compete for CPU, memory, storage throughput, or network bandwidth, contention can cause slow performance. Capacity planning and monitoring are therefore essential.

Installing ESXi and Choosing Boot Media

ESXi can be installed on supported local disks and other supported boot devices. Exact support for USB or SD boot media, installation behavior, and lifecycle practices can vary by ESXi release and server vendor guidance. Always verify the target release and platform before selecting boot media.

ESXi has a relatively small dedicated installation footprint compared with a full general-purpose server operating system. That does not mean every release has the same storage requirement. Use the current release documentation and vendor instructions rather than relying on an old fixed footprint number.

Hardware and Guest Operating-System Compatibility

The ESXi host requires compatible 64-bit server hardware and virtualization-capable CPUs. Compatibility includes more than the processor: the server model, storage controller, network adapter, firmware, drivers, and intended ESXi release must all be considered.

Before installation, verify the complete configuration against the current VMware Compatibility Guide and the server vendor’s supported configuration. An installer may fail to detect a storage controller or network adapter when the device, driver, firmware, or ESXi release is unsupported.

Host CPU architecture requirements are separate from guest OS support. A supported ESXi version may run supported 32-bit and 64-bit guest operating systems, subject to the compatibility policies for that ESXi and guest OS version. Check guest OS compatibility before creating a production VM.

Capacity and Scaling Limits

Capacity planning considers logical CPUs, assigned vCPUs, host memory, storage capacity and performance, network bandwidth, and the number of VMs per host. A host’s safe workload depends on the demand of those VMs, not only on a VM-count limit.

Maximum values are release-specific and hardware-dependent. Processor, memory, virtual-device, and VM-per-host limits can change between ESXi and vSphere versions. Consult the configuration maximums documentation for the exact version and hardware platform being deployed. Do not treat figures from an older release as universal current limits.

A practical review before adding VMs includes host CPU utilization, memory pressure, datastore free space and latency, network throughput, failure capacity, and supported configuration maximums.

ESXi Management Interfaces

Direct Console User Interface

The Direct Console User Interface (DCUI) is the local console used for basic ESXi configuration and recovery. It is especially useful when browser-based management is not yet available or network settings need to be repaired.

For initial setup, use the DCUI to:

  1. Configure the management network.
  2. Assign a static IP address or use DHCP as appropriate.
  3. Set a VLAN ID when the network design requires one.
  4. Configure the default gateway and DNS servers.
  5. Set the hostname.
  6. Configure time settings and NTP as appropriate.
  7. Set or confirm administrative credentials.
  8. Test management-network connectivity.

After networking is functional, an administrator can use browser-based host management or add the host to vCenter Server.

ESXi Shell and SSH

Command-line access through the ESXi Shell or SSH can be enabled temporarily for administration or troubleshooting. Restrict access, use strong authentication and auditing practices, and disable unnecessary services after the task is complete. The local console and supported management interfaces should be the primary introduction to ESXi administration.

ESXi, vCenter Server, and vSphere

Component | Primary Role | Scope

ESXi | Runs VMs and virtualizes the resources of one physical host | Host-level compute, memory, storage, and networking

vCenter Server | Centralizes management of hosts, VMs, inventory, policies, and advanced capabilities | Multiple ESXi hosts and their virtual infrastructure

vSphere | VMware’s virtualization platform and associated management capabilities built around ESXi and related components | The broader virtual datacenter platform

ESXi can run VMs independently. vCenter Server is a separate centralized management platform that makes it easier to manage multiple ESXi hosts and enables related vSphere capabilities. An ESXi host and vCenter Server therefore have different roles.

Older VMware documentation referred to both ESX and ESXi architectures. Later vSphere releases standardized on the ESXi architecture, so current deployments generally use ESXi as the host hypervisor.

Practical Examples

Server Consolidation

A physical server with sufficient CPU, RAM, storage, and network capacity can run separate Linux web, Windows application, and database VMs. ESXi schedules shared physical resources while retaining VM-level isolation. This can replace several lightly utilized physical servers, provided performance, availability, licensing, and backup requirements are addressed.

Type 1 Versus Type 2 in Practice

An administrator may use VirtualBox on a laptop to test an operating system, while an organization uses ESXi on supported rack-mounted servers for production workloads. The laptop scenario values convenience and local experimentation; the server scenario values direct hardware deployment and datacenter operations.

Resource Abstraction

A VM may see a virtual network adapter and a virtual disk. ESXi maps the vNIC to virtual-switch and physical-NIC resources and maps the virtual disk to storage available through a datastore. The guest does not need to know the exact physical device behind each virtual device.

Benefits and Planning Considerations

Benefits

  • Consolidation: Multiple workloads can share one physical server.
  • Isolation: VMs separate operating systems and applications from one another.
  • Efficient hardware use: Shared capacity can reduce idle physical-server resources.
  • Faster provisioning: New VMs can often be created from templates or defined configurations.
  • Centralized operations: vCenter can provide common inventory and management for multiple hosts.

Limitations and Planning Issues

  • Hardware must be supported by the selected ESXi release.
  • Licensing and product availability must be evaluated for the intended features and environment.
  • Storage capacity, performance, redundancy, and network design affect VM behavior.
  • A host failure can affect many VMs, so availability and recovery plans are important.
  • VMs still require backups; snapshots are not a substitute for a backup system.
  • Oversubscription can create CPU, memory, storage, or network contention.

Troubleshooting Common ESXi Problems

Unsupported Hardware or Missing Devices

Symptom: The installer reports unsupported hardware or cannot detect a storage or network device.

Likely causes: The server model, storage controller, NIC, driver, firmware combination, or target ESXi release is unsupported.

Resolution: Check the compatibility matrix and server-vendor documentation, apply approved firmware or driver updates, and use a supported ESXi image or hardware configuration.

Host Cannot Be Reached

Likely causes: Incorrect management IP, subnet mask, gateway, VLAN, DNS setting, or physical network connection.

Resolution: Use the DCUI to verify management networking, check the switch VLAN and uplink configuration, and test connectivity and name resolution.

VM Performance Degrades After Adding VMs

Likely causes: CPU, memory, storage, or network contention; excessive resource allocation; or insufficient datastore performance or capacity.

Resolution: Review host and VM performance metrics, right-size VM resources, investigate storage and network bottlenecks, and confirm that the design remains within supported limits.

Guest OS Will Not Install or Run Correctly

Likely causes: The guest OS version is unsupported for the installed ESXi release, or the VM’s virtual hardware settings do not meet guest requirements.

Resolution: Check guest OS compatibility documentation, use supported virtual hardware settings and installation media, and select a supported ESXi release if necessary.

Key Takeaways

  • ESXi is VMware’s Type 1 hypervisor, installed directly on supported physical server hardware.
  • The VMkernel is the core layer that schedules, isolates, and brokers VM access to CPU, memory, storage, and networking.
  • Each VM uses virtual hardware and can run its own guest operating system and applications.
  • Type 1 hypervisors such as ESXi are server-oriented; Type 2 products such as Workstation and VirtualBox run inside a host operating system.
  • vCenter Server centrally manages multiple ESXi hosts, while vSphere describes the broader platform and capabilities.
  • Compatibility, capacity, storage, networking, backups, host failure, licensing, and contention must be addressed before production deployment.

For the next steps, study ESXi installation and configuration, vCenter Server fundamentals, datastores, virtual switches, VM resource allocation, monitoring, backup and recovery, high availability, and host hardening.