Starting with ESXi, we configured a VMkernel port for management. This was configured during the installation process of ESX, so we could connect to our hosts to continue to configure them and manage them. What are VMkernel Ports?īack in the ESX days, we connected to our hosts with a special service console port.
#ESXI VERSIONS DRIVERS#
The networking and storage stacks are also in the VMkernel, and the ESXi’s hosts device drivers are also handled by the VMkernel. It handles things like resource scheduling, and resource management. Like I said, the VMkernel is the brains of the operation. I want to give you a simple overview so you can really begin to understand its capabilities. We’ve talked a lot about the VMkernel, which is the brains of ESXi. Not only did this simplify management, but added to the stability and security of ESXi as a whole. It is from 2011, and wonderfully explains this huge shift in ESX vs ESXi architecture. This allowed hardware data to be easily seen in vCenter server, and common hardware management platforms to access it via vCenter.įor a great overview of the CIM, be sure to check out this blog on VMware’s site. As anyone who has ever architected anything can tell you, the simpler the better.įor example, instead of installing a 3rd party agent for hardware monitoring, VMware introduced the Common Information Model or CIM. Simplification of Virtualization Managementīy integrating these management functions into the VMkernel, the ESXi architecture became much simpler than ESX. See a problem with that and running mission critical workloads? Absolutely.īy getting rid of this “management VM”, VMware was able to greatly reduce the attack surface of their hypervisor, which was becoming increasingly important as adoption grew so rapidly. This means the service console had to be patched just like any other Linux OS, and was susceptible to anything a Linux server was.
#ESXI VERSIONS INSTALL#
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.
Remember those third party agents we talked about? Well in this case, a bad agent could bring you ESX host to a screeching halt, which was not a good thing. While the service console could only use up to 800 MB of RAM (which could be significant believe it or not in some of the hosts of the 2009 era), it still could wreak havoc with performance and stability. Performance and Stability for VMware ESXi Here are a couple of reasons that VMware may have seen it fit to make this change. Everyone was virtualizing everything in site, and running their mission critical workloads on ESX. Remember, ESXi came out with vSphere 4 in 2009, which was the boom of virtualization. When ESXi was created, VMware integrated the service console functionality into the VMkernel, like this: Again, this is a very simple diagram but you can see what the major changes were, the biggest which is eliminating the service console completely from the ESXi architecture.Īs much as I resisted this change at the time, it made sense for a number of reasons. Wondering what is ESXi? It is the next generation of VMware’s ESX hypervisor. The service console talked to the VMkernel, which is basically the brains of your ESX or ESXi host.īefore we talk more about the VMkernel, let’s take a look at what changed with ESXi. The ESX management agents also lived here in the service console.
#ESXI VERSIONS DOWNLOAD#
Here is a very simple depiction of what it looked like:īesides accessing the command line, you could download and instal almost any agent you wanted into the ESX service console, like agents for hardware monitoring, backup, or well, anything you wanted really.
The service console allowed you to login to ESX and issue esxcfg commands at a command line to configure your host. Think of the service console as a small virtual machine that ran next to your guest VMs and provided management access to the ESX host. In fact, my first ever blog post was dedicated to the ESX service console. The main difference was the ESX service console. While the functionality of today’s ESXi hosts is very similar (though much more advanced) to ESX, there are some important architectural difference. ESX was what VMware’s bare metal hypervisor was originally called. It really is where virtualization got started.įor today’s VMware history lesson, we are going to start with ESX.
ESX is what VMware’s bare metal hypervisor we all know and love was originally called. Wondering what is ESX? ESX stands for Elastic Sky X. Simplification of Virtualization Management.Performance and Stability for VMware ESXi.