ESX and ESXi are two architectures of the same VMware hypervisor, and only ESXi still exists. Both ran the same VMkernel. ESX added a Linux Service Console for management; ESXi removed it, dropping the installation from gigabytes to about 150 MB.
- The VMkernel is VMware code. Neither ran VMs on Linux
- ESX carried a Linux Service Console; ESXi has none
- ESXi is about 150 MB against gigabytes for ESX
- ESX last shipped in vSphere 4.1, in 2010
- ESXi runs VMs, vCenter runs hosts, vSphere is the suite name
On this page
The differenceThe architecture difference: what the Service Console was
The confusion in ESX vs ESXi comes from a reasonable assumption that turns out to be wrong: that VMware ESX ran its VMs on Linux. It did not.
In both architectures the hypervisor is the VMkernel, VMware's own code, running directly on the hardware. It schedules CPU, manages memory and drives the storage and network for every VM. Nothing about that changed between ESX and ESXi, which is why the performance of the two was broadly the same.
What ESX added was a separate Linux based Service Console running as a privileged virtual machine beside the VMkernel. It existed for management: agents ran in it, administrators logged into it, scripts and backup tools were installed into it, and a set of esxcfg- commands lived there.
That console was convenient and it was also the problem, and the four differences below are all consequences of it.
It was large. Gigabytes of a general purpose Linux distribution, on a box whose only job was to run VMs. Every byte of it competed for the same memory and storage the VMs needed.
It was a patching burden of its own. Every package in that distribution had its own vulnerabilities and its own updates, unrelated to the hypervisor.
It was a security problem. A full operating system with services and accounts, sitting on the most valuable host in the room, and holding the keys to every VM on it.
It let people install things. Agents accumulated inside it, and a host that should have been an appliance became a server somebody had configured.
VMware removed it entirely in ESXi. Management moved to remote APIs, a small direct console for basic configuration, and a restricted shell that is off by default. The result is a hypervisor of roughly 150 megabytes that boots from a small device, leaves its memory and storage to the VMs, and holds almost nothing worth attacking.
| ESX | ESXi | |
|---|---|---|
| The hypervisor itself | VMkernel | VMkernel, the same |
| Linux Service Console | Yes | None |
| Approximate footprint | Gigabytes | About 150 MB |
| Local agents installable | Yes | No, by design |
| Managed by | Console, scripts, client | Remote APIs and clients |
| Security surface | A full Linux install | Very small |
| Still shipping | No, ended 2010 | Yes |
The three namesThe names people are actually confusing
Anyone searching ESX vs ESXi in the current decade almost always has a different question underneath it, because three VMware names get used interchangeably and they are not interchangeable.
ESXi is the hypervisor. It is the VMware software installed on a physical server. One installation, one host. It runs VMs whether or not anything else exists.
vCenter Server is the management application. It is itself a VM, and it manages many ESXi hosts together. Everything people associate with VMware beyond raw virtualization lives here: moving a running VM between hosts, restarting VMs elsewhere when a host fails, balancing load for performance, central permissions and templates.
vSphere is the product suite. It is the VMware name for the whole thing, ESXi and vCenter and the features licensed with them. There is no file called vSphere that you install.
The useful way to hold it: ESXi runs the machines, vCenter runs the ESXi hosts, vSphere is what the bundle is called on the invoice.
A single ESXi host without vCenter is a perfectly functional hypervisor, managed through its own web interface. What it cannot do is anything that involves more than one host at once, including moving a VM without stopping it, and that is the line most small deployments eventually cross.
Managing itWhat ESXi looks like to manage
Removing the Service Console did not remove administration, it moved it. Four routes exist and each has a proper use.
| Route | Covers | On by default | When it is the only option |
|---|---|---|---|
| Host client | One host | Yes | vCenter is down or absent |
| vCenter | Every host together | Separate product | Anything across hosts |
| PowerCLI | Whatever you script | Install it | Bulk work and reporting |
| ESXi shell and SSH | One host, deeply | No | Troubleshooting the host itself |
| Direct console | One host, minimally | Yes | Before the host is on the network |
The host client. A web interface served by the ESXi host itself. Create a VM, attach storage, configure networking on that host. Enough for one server, and the only option when vCenter is the thing that is broken.
vCenter. The web interface most administrators actually work in, covering every host together. This is where the features people buy VMware for are configured, and where the differences between a single host and a cluster become obvious.
PowerCLI. The VMware PowerShell module, and the answer for anything repetitive. Reporting across a hundred VMs is a script rather than an afternoon.
The ESXi shell and SSH. Off by default, enabled deliberately, and used for troubleshooting rather than routine work. Leaving SSH permanently on is a recognized finding in any security review, and the host will tell you so on its summary page.
The direct console on the physical screen exists too, for the handful of things you do before the host is on the network: address, hostname, password, restarting the management agents.
MigrationIf you still have an ESX host
They exist. A machine running something that drives a physical process, a system whose vendor disappeared, a host somebody stopped thinking about in 2011. The path off it is well worn and the ordering matters.
Take a backup first, and prove you can restore it. Whatever backup product is attached to a host this old is also fifteen years old. Restore one VM somewhere else before touching anything, because the migration is the moment you will find out.
Do not upgrade in place across that gap. There is no supported upgrade from an ESX host to a current VMware release. Build a new ESXi host and move the VMs onto it.
Move the virtual machines, not the host. A VM is files. Copy them to storage the new host can read, register them, and let VMware tools update inside the guest afterward. For a handful of VMs this is an evening rather than a project.
Expect the guest operating systems to be the real problem. A host from 2010 is running guests from 2010, and those have their own end of life. Moving them to a modern hypervisor makes them supported by VMware and no more supported by their own vendors.
Check what the VMs are actually for before assuming they must move. A meaningful share of very old hosts are running one application that nobody has used in years, and the data recovery plan for those is an archive rather than a migration.
PitfallsWhere people go wrong
Looking for ESX to download. It has not shipped since 2010. Anything currently supported is ESXi, and a system still running ESX is fifteen years past its last patch.
Assuming ESXi runs on Linux. It does not, and neither did ESX. The VMkernel is VMware's own code. The Linux console in ESX sat beside it rather than under it.
Trying to install agents on the host. ESXi has no place for them by design. Backup and monitoring products interact with VMware through APIs, and a vendor asking to install software onto the hypervisor is describing an ESX era product.
Confusing ESXi with vSphere. ESXi is the hypervisor you install. vSphere is the name of the suite. The distinction matters when reading licensing.
Expecting one host to do what vCenter does. Live migration, automatic restart of VMs after a host failure and performance load balancing are vCenter features. A standalone host has none of them, whatever the hardware cost.
Leaving SSH enabled permanently. It is off by default for a reason, and the host raises a warning about it. Enable it for the task and turn it off after.
Treating the hypervisor as a general purpose server. It is an appliance. The whole point of the ESXi architecture is that there is nothing on it to manage or secure except the hypervisor itself.
ComparisonThree names, two pieces of software, and one word on a price list
| Criterion | ESXi | vCenter | vSphere |
|---|---|---|---|
| What it is | A hypervisor | A management application | A product suite name |
| Installed on | Physical hardware | A virtual machine | Nothing, it is a name |
| Runs virtual machines | Yes | No | Not applicable |
| Manages many hosts | No | Yes | Not applicable |
| Needed to run one server | Yes | No | Not applicable |
| Provides live migration | No | Yes | Not applicable |
| Something you download | Yes | Yes | No |
Reading the last row settles most of the confusion on its own. Two of these are software and the third is a word on a price list.
FAQFrequently asked questions
What is the difference between ESX and ESXi?
Both run the same VMkernel hypervisor. ESX added a Linux based Service Console for management; ESXi removed it and moved management to remote tools, which made the installation roughly 150 MB instead of gigabytes.
Is ESX still available?
No. The last release including it was vSphere 4.1 in 2010, and vSphere 5.0 shipped with ESXi only. Anything supported today is ESXi.
Does ESXi run on Linux?
No, and neither did ESX. The hypervisor is VMware's own VMkernel running directly on the hardware. ESX had a Linux console beside it, not underneath it.
What was the Service Console for?
Management: logging in, running commands, and installing agents. Removing it cut the footprint, the patching burden and the attack surface at the same time.
Why is ESXi more secure than VMware ESX was?
Because there is far less of it. No general purpose operating system, no package manager, no local accounts to speak of and nowhere to install software, so the security surface is a fraction of the size.
What is the difference between ESXi and vSphere?
ESXi is the hypervisor you install on a server. vSphere is the name of the suite that includes ESXi, vCenter and the licensed features. There is nothing called vSphere to install.
Do I need vCenter to use ESXi?
No. A single host runs perfectly well on its own through its web interface. You need vCenter for anything involving several hosts together, including live migration and automatic restart after a failure.
How do I manage ESXi without a Service Console?
Through the host web client, vCenter, PowerCLI for anything scripted, and the shell for troubleshooting. The direct console on the physical screen handles initial setup.
Should SSH be enabled on an ESXi host?
Not permanently. It is off by default, the host warns when it is left on, and it should be enabled for a specific task and disabled afterward.
Can I install a backup agent on ESXi?
No, and you should not need to. Backup products read VM data through the VMware APIs rather than by installing software on the hypervisor, which is the change ESXi made deliberate.
What replaced the esxcfg commands?
esxcli on the host, and PowerCLI for anything done from elsewhere. The old commands persisted for a while as wrappers and are long gone from current versions.
Is ESXi a type 1 hypervisor?
Yes. It installs on bare metal with no host operating system underneath it, which is the definition.
How does this compare with Hyper-V?
Both are type 1 hypervisors and the comparison is a live one. ESX against ESXi is a historical question; ESXi against Hyper-V is the decision people actually make.
Keep readingRelated concepts
Read next · Hypervisors Hyper-V vs VMware This is the comparison people actually have to decide, now that ESX against ESXi is settled history. Open this next11 min- Containers · 11 min Containers vs VMs The other way to run several workloads on one machine, and it answers a different question than a hypervisor does.
- Hypervisors · 10 min Type 1 vs Type 2 Hypervisor ESXi installs on bare metal with nothing underneath it, which is what the type 1 label means.