After version 4.1, VMware renamed ESX to ESXi. ESXi replaces Service Console (a rudimentary operating system) with a more closely integrated OS. ESX/ESXi is the primary component in the VMware Infrastructuresoftware suite.[3]

ESX runs on bare metal (without running an operating system)[6] unlike other VMware products.[7] It includes its own kernel: A Linux kernel is started first,[8] and is then used to load a variety of specialized virtualization components, including ESX, which is otherwise known as the vmkernel component.[citation needed] The Linux kernel is the primary virtual machine; it is invoked by the service console. At normal run-time, the vmkernel is running on the bare computer, and the Linux-based service console runs as the first virtual machine. VMWare dropped development of ESX at version 4.1, and now uses ESXi, which does not include a Linux kernel.[citation needed]

The vmkernel is a microkernel[9] with three interfaces: hardware, guest systems, and the service console (Console OS).

The vmkernel handles CPU and memory directly, using scan-before-execution (SBE) to handle special or privileged CPU instructions[10][11] and the SRAT (system resource allocation table) to track allocated memory.[12]

Access to other hardware (such as network or storage devices) takes place using modules. At least some of the modules derive from modules used in the Linux kernel. To access these modules, an additional module called vmklinux implements the Linux module interface. According to the README file, "This module contains the Linux emulation layer used by the vmkernel."[13]

These drivers mostly equate to those described in VMware's hardware compatibility list.[14] All these modules fall under the GPL. Programmers have adapted them to run with the vmkernel: VMware Inc has changed the module-loading and some other minor things.[13]

In ESX (and not ESXi), the Service Console is a vestigial general purpose operating system most significantly used as bootstrap for the VMware kernel, vmkernel, and secondarily used as a management interface. Both of these Console Operating System functions are being deprecated from version 5.0, as VMware migrates exclusively to the ESXi model, current version being ESXi.[15] The Service Console, for all intents and purposes, is the operating system used to interact with VMware ESX and the virtual machines that run on the server.

ESX uses a Linux kernel to load additional code: often referred to by VMware, Inc. as the "vmkernel". The dependencies between the "vmkernel" and the Linux part of the ESX server have changed drastically over different major versions of the software. The VMware FAQ[16] states: "ESX Server also incorporates a service console based on a Linux 2.4 kernel that is used to boot the ESX Server virtualization layer". The Linux kernel runs before any other software on an ESX host.[8] On ESX versions 1 and 2, no VMkernel processes run on the system during the boot process.[17] After the Linux kernel has loaded, the S90vmware script loads the vmkernel.[17] VMware Inc states that vmkernel does not derive from Linux, but acknowledges that it has adapted certain device-drivers from Linux device drivers. The Linux kernel continues running, under the control of the vmkernel, providing functions including the proc file system used by the ESX and an environment to run support applications.[17] ESX version 3 loads the VMkernel from the Linux initrd, thus much earlier in the boot-sequence than in previous ESX versions.

In traditional systems, a given operating system runs a single kernel. The VMware FAQ mentions that ESX has both a Linux 2.4 kernel and vmkernel – hence confusion over whether ESX has a Linux base. An ESX system starts a Linux kernel first, but it loads vmkernel (also described by VMware as a kernel), which according to VMware 'wraps around' the linux kernel, and which (according to VMware Inc) does not derive from Linux.

As a further detail which differentiates the ESX from other VMware virtualization products: ESX supports the VMware proprietary cluster file system VMFS. VMFS enables multiple hosts to access the same SANLUNs simultaneously, while file-level locking provides simple protection to file-system integrity.

In the event of a hardware error, the vmkernel can 'catch' a Machine Check Exception.[18] This results in an error message displayed on a purple diagnostic screen. This is colloquially known as a purple diagnostic screen, or purple screen of death (PSOD, cf. Blue Screen of Death (BSOD)).

Upon displaying a purple diagnostic screen, the vmkernel writes debug information to the core dump partition. This information, together with the error codes displayed on the purple diagnostic screen can be used by VMware support to determine the cause of the problem.

Live migration (vMotion) in ESX allows a virtual machine to move between two different hosts. Live storage migration (Storage vMotion) enables live migration of virtual disks on the fly.[19] During vMotion Live Migration (vLM) of a running virtual machine (VM) the content of the (RAM) memory of the VM is sent from the running VM to the new VM (the instance on another host that will become the running VM after the vLM). The content of memory is by its nature changing all the time. ESX uses a system where the content is sent to the other VM and then it will check what data is changed and send that, each time smaller blocks. At the last moment it will very briefly 'freeze' the existing VM, transfer the last changes in the RAM content and then start the new VM. The intended effect of this process is to minimize the time during which the VM is suspended; in a best case this will be the time of the final transfer plus the time required to start the new VM.[20][21]

VMware ESX Server 3.5 Update 5 Build 207095 (20 December 2009) This was the last version to support 32-bit systems [22]

VMware vSphere 4.0 (20 May 2009)

VMware ESX 4.0 Build 164009 (21 May 2009)

VMware ESX 4.0 Update 1 Build 208167 (19 November 2009)

VMware ESX 4.0 Update 2 Build 261974 (10 June 2010)

VMware ESX 4.0 Update 3 Build 398348 (5 May 2011)

VMware ESX 4.0 Update 4 Build 504850 (17 November 2011)

VMware ESX 4.1 Build 260247 (13 July 2010)

VMware ESX 4.1 Update 1 Build 348481 (10 February 2011)

VMware ESX 4.1 Update 2 Build 502767 (27 October 2011)

VMware ESX 4.1 Update 3 Build 800380 (30 August 2012)

ESX and ESXi before version 5.0 do not support Windows 8/Windows 2012. These Microsoft operating systems can only run on ESXi 5.x or later.[23]

18 July 2010 vSphere 4.1 and its subsequent update and patch releases are the last releases to include both ESX and ESXi hypervisor architectures. Future major releases of VMware vSphere will include only the VMware ESXi architecture. For this reason, VMware recommends that deployments of vSphere 4.x utilize the ESXi hypervisor architecture.

VMware ESXi is a smaller footprint version of ESX that does not include the ESX Service Console. It is available without the need to purchase a vCenter license as a free download from VMware with some features disabled.[25][26][27]

VMware ESXi was originally a compact version of VMware ESX that allowed for a smaller 32 MB disk footprint on the Host. With a simple configuration console for mostly network configuration and remote based VMware Infrastructure Client Interface, this allows for more resources to be dedicated to the Guest environments.

There are two variations of ESXi, VMware ESXi Installable and VMware ESXi Embedded Edition. The same installation media will install to either one or the other of these installation modes depending on the size of the target media.[28] It has the ability to upgrade to VMware Infrastructure 3[29] or VMware vSphere 4.0 ESXi.

Originally named VMware ESX Server ESXi edition, through several revisions the product finally became VMware ESXi 3. New editions then followed: ESXi 3.5, ESXi 4 and now ESXi 5.

To virtualize Windows 8 or Windows Server 2012 as guest operating systems, the ESXi version must be 5.0 update 1 or later.

Fault Tolerance (almost instant stateful fail-over of a VM in the event of a physical host failure)[31]

Converter, enables users to create VMware ESX Server- or Workstation-compatible virtual machines from either physical machines or from virtual machines made by other virtualization products. Converter replaces the VMware "P2V Assistant" and "Importer" products — P2V Assistant allowed users to convert physical machines into virtual machines; and Importer allowed the import of virtual machines from other products into VMware Workstation.

vSphere Client (formerly VMware Infrastructure Client), enables monitoring and management of a single instance of ESX or ESXi server. After ESX 4.1, vSphere Client was no longer available from the ESX/ESXi server, but must be downloaded from the VMware web site.

Network-connectivity between ESX hosts and the VM's running on it relies on virtual NIC's (inside the VM) and virtual switches. The latter exists in two versions: the 'standard' vSwitch allowing several VM's on a single ESX host to share a physical NIC and the 'distributed vSwitch' where the vSwitches on different ESX hosts together form one logical switch. Cisco offers in their Cisco Nexus product-line the Nexus 1000v, an advanced version of the standard distributed vSwitch. A Nexus 1000v consists of two parts: a supervisor module (VSM) and on each ESX host a virtual ethernet module (VEM). The VSM runs as a virtual appliance within the ESX cluster or on dedicated hardware (Nexus 1010 series) and the VEM runs as module on each host and replaces a standard dvS (distributed virtual switch) from VMware. Configuration of the switch is done on the VSM using the standard NX-OSCLI. It offers capabilities to create standard port-profiles which can then be assigned to virtual machines using vCenter.

There are several differences between the standard dvS and the N1000v, one is that the Cisco switch generally has full support for network technologies such as LACP link aggregation or that the VMware switch supports new features such as routing based on physical NIC load. However the main difference lies in the architecture: Nexus 1000v is working in the same way as a physical Ethernet switch does while dvS is relying on information from ESX. This has consequences for example in scalability where the limit for a N1000v is 2048 virtual ports against 60000 for a dvS. The Nexus1000v is developed in co-operation between Cisco and VMware and uses the API of the dvS[32]

Because VMware ESX is a leader in the server-virtualisation market,[33] software and hardware vendors offer a range of tools to integrate their products or services with ESX. Examples are the products from Veeam Software with backup and management applications[34] and a plugin to monitor and manage ESX using HP OpenView,[35]Quest Software with a range of management and backup-applications and most major backup-solution providers have plugins or modules for ESX. Using Microsoft Operations Manager (SCOM) 2007/2012 with a Bridgeways ESX management pack gives you a realtime ESX datacenter health view.

Also hardware-vendors such as HP and Dell include tools to support the use of ESX(i) on their hardware platforms. An example is the ESX module for Dell's OpenManage management platform.[36]
VMware have added a Web Client[37] since v5 but it will work on vCenter only and does not contain all features.[38] vEMan[39] is a Linux application which is trying to fill that gap. These are just a few examples: there are numerous 3rd party products to manage, monitor or backup ESX infrastructures and the VMs running on them[40]

In terms of performance, virtualization imposes a cost in the additional work the CPU has to perform to virtualize the underlying hardware. Instructions that perform this extra work, and other activities that require virtualization, tend to lie in operating system calls. In an unmodified operating system, OS calls introduce the greatest portion of virtualization "overhead".[citation needed]