According to the latest statistics, VMware holds more than 75% of the global server virtualization market, which makes the company the undisputed leader in the field, with its competitors lagging far behind. VMware hypervisor provides you with a way to virtualize even the most resource-intensive applications while still staying within your budget. If you are just getting started with VMware software, you may have come across the seemingly unending ESX vs. ESXi discussion. These are two types of VMware hypervisor architecture, designed for “bare-metal” installation, which is directly on top of the physical server (without running an operating system). The aim of our article is to explain the difference between them.
If you are talking about a vSphere host, you may see or hear people refer to them as ESXi, or sometimes ESX. No, someone didn’t just drop the i, there was a previous version of the vSphere Hypervisor called ESX. You may also hear ESX referred to as ESX classic or ESX full form. Today I want to take a look at ESX vs ESXi and see what the difference is between them. More importantly, I want to look at some of the reasons VMware changed the vSphere hypervisor architecture beginning in 2009.
What Does ESXi Stand for and How Did It All Begin?
If you are already somewhat familiar with the VMware product line, you may have heard that ESXi, unlike ESX, is available free of cost. This has led to the common misconception that ESX servers provide a more efficient and feature-rich solution, compared to ESXi servers. This notion, however, is not entirely accurate.
ESX is the predecessor of ESXi. The last VMware release to include both ESX and ESXi hypervisor architectures is vSphere 4.1 (“vSphere”). Upon its release in August 2010, ESXi became the replacement for ESX. VMware announced the transition away from ESX, its classic hypervisor architecture, to ESXi, a more lightweight solution.
The primary difference between ESX and ESXi is that ESX is based on a Linux-based console OS, while ESXi offers a menu for server configuration and operates independently from any general-purpose OS. For your reference, the name ESX is an abbreviation of Elastic Sky X, while the newly-added letter “i” in ESXi stands for “integrated.” As an aside, you may be interested to know that at the early development stage in 2004, ESXi was internally known as “VMvisor” (“VMware Hypervisor”), and became “ESXi” only three years later. Since version 5, released in July 2011, only ESXi has continued.
ESX vs. ESXi: Key Differences
Overall, the functionality of ESX and ESXi hypervisors is effectively the same. The key difference lies in architecture and operations management. If only to shorten the VMware version comparison to a few words, ESXi architecture is superior in terms of security, reliability, and management. Additionally, as mentioned above, ESXi is not dependent on an operating system. VMware strongly recommends their users currently running the classic ESX architecture to migrate to ESXi. According to VMware documentation, this migration is required for users to upgrade beyond the 4.1 version and maximize the benefits from their hypervisor.
Console OS in ESX
As previously noted, ESX architecture relies on a Linux-based Console Operating System (COS). This is the key difference between ESX and ESXi, as the latter operates without the COS. In ESX, the function of the console OS is to boot the server and then load the vSphere hypervisor into the memory. After that, however, there is no further need for the COS as these are its only functions. Apart from the fact that the role of the console OS is quite limited, it poses certain challenges to both VMware and their users. COS is rather demanding in terms of the time and effort required to keep it secure and maintained. Some of its limitations are as follows:
- Most security issues associated with ESX-based environment are caused by vulnerabilities in the COS;
- Enabling third-party agents or tools may pose security risks and should thus be strictly monitored;
- If enabled to run in the COS, third-party agents or tools compete with the hypervisor for the system’s resources.
In ESXi, initially introduced in the 3.5 VMware release, the hypervisor no longer relies on an external OS. It is loaded from the boot device directly into memory. The fact that the COS has been eliminated is beneficial in many ways:
- The decreased number of components allows you to develop a secure and tightly locked-down architecture;
- The size of the boot image is reduced;
- The deployment model becomes more flexible and agile, which is beneficial for infrastructures with a large amount of ESXi hosts.
This way, the key point in the ESX vs. ESXi discussion is that the introduction of ESXi architecture resolved some of the challenges associated with ESX, thus enhancing security, performance, and reliability of the platform.Data Protection with NAKIVO Backup & Replication
ESX vs. ESXi: Basic Features of the Latter
For today, ESXi remains a “bare-metal” hypervisor that sets up a virtualization layer between the hardware and the machine’s OS. One of the key advantages of ESXi is that it creates a balance between the ever-growing demand for the resource capacity and affordability. By enabling effective partitioning of the available hardware, ESXi provides a smarter way for the hardware use. Simply put, ESXi lets you consolidate multiple servers onto fewer physical machines. This allows you to reduce both the IT administration effort and resource requirements, especially in terms of space and power consumption, thus helping you save on total costs in return.
Here are some of the key features of ESXi at a glance:
ESXi may be regarded as a smaller-footprint version of ESX. For quick reference, “footprint” refers to the amount of memory the software (or hypervisor, in this context) occupies. In the case of ESXi 6.7, this is only about 130 MB, while the size of an ESXi 6.7 ISO Image is 325 MB. For comparison, the footprint of ESXi 6 is about 155 MB.
Flexible configuration models
VMware provides its users with a tool to figure out the recommended configuration limits for a particular product. To properly deploy, configure, and operate either physical or virtual equipment, it is advisable that you do not go beyond the limits that the product supports. With that, VMware creates the means for accommodating applications of basically any size. In ESXi 6.7, each of your VMs can have up to 256 virtual CPUs, 6 TB of RAM, 2 GB of video memory, etc. The size of the virtual disk is 62 TB.
The reason it was so easy to develop and install agents on the service console was because the service console was basically a linux VM sitting on your ESX host with access to the VMkernel.
This means the service console had to be patched just like any other Linux OS, and was susceptible to anything a Linux server was.
See a problem with that and running mission critical workloads? Absolutely.
VMware ecosystem supports a wide range of third-party hardware, products, guest operating systems, and services. As an example, you can use third-party management applications in conjunction with your ESXi host, thus making infrastructure management a far less complex endeavor. One VMware tool, Global Support Services (GSS), allows you to find out whether or not a given tech problem is related to the third-party hardware or software.
Since the 6.5 release, the vSphere Client is available in an HTML5 version, which greatly improves the user experience. With that release, there is also the vSphere Command-Line Interface (vSphere CLI), allowing you to initiate basic administration commands from any machine that has access to the given network and system. For development purposes, you can use the REST-based APIs, thus optimizing application provisioning, conditional access controls, self-service catalog, etc.
Coming back to VMware ESX vs. ESXi comparison, the two hypervisors are quite similar in terms of functionality and performance, at least when comparing the 4.1 release versions, though they are entirely different when it comes to architecture and operational management. Since ESXi does not rely on a general-purpose OS, unlike ESX, this provides you with the opportunity to resolve a number of security and reliability issues. VMware encourages migration to ESXi architecture; according to their documentation, migration can be performed with no VM downtime, although the process does require careful preparation.
To help you protect your VMware-based infrastructure, NAKIVO Backup & Replication offers a rich set of advanced features that allow for automatization, near-instant recovery, and resource saving. Below are outlined some of our product’s basic features that can be especially helpful in a VMware environment:
VMware Backup – Back up live VMs and application data, and keep the backup archive for as long as you need. With NAKIVO Backup & Replication, backups have the following characteristics:
- Image-based – the entire VM is captured, including its disks and configuration files;
- Incremental – after the initial full backup is complete, only the changed blocks of data are copied;
- Application-aware – application data in MS Exchange, Active Directory, SQL, etc. is copied in a transactionally-consistent state.
VMware Replication – Create identical copies, aka replicas, of your VMs. Until needed, they remain in a powered-off state and don’t consume resources.
If a disaster strikes and renders your VM unavailable, you can fail over to this VM’s replica and have it running in basically no time.
Policy-Based Data Protection – Free up your time by automating the basic VM protection jobs. Create rules based on a VM’s name, size, tag, configuration, etc. to have the machine added to a specific job scope automatically. With policy rules in place, you no longer need to chase newly-added or changed VMs yourself.
NAKIVO Backup & Replication was created with the understanding of how important it is to achieve the lowest possible RPO and RTO. With backups and replicas of your workloads in place, you can near-instantly resume operations after a disaster, with little to no downtime or data loss.