It really is where virtualization got started.įor today’s VMware history lesson, we are going to start with ESX.ĮSX is what VMware’s bare metal hypervisor we all know and love was originally called. ESX was what VMware’s bare metal hypervisor was originally called. While the functionality of today’s ESXi hosts is very similar (though much more advanced) to ESX, there are some important architectural difference. The main difference was the ESX service console. In fact, my first ever blog post was dedicated to the ESX service console. 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. The service console allowed you to login to ESX and issue esxcfg commands at a command line to configure your host. 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 ESX management agents also lived here in the service console. 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. Wondering what is ESXi? It is the next generation of VMware’s ESX hypervisor. 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. Remember, ESXi came out with vSphere 4 in 2009, which was the boom of virtualization. Everyone was virtualizing everything in site, and running their mission critical workloads on ESX. Performance and Stability for VMware ESXi Here are a couple of reasons that VMware may have seen it fit to make this change. 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. 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. 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.ī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. Simplification of Virtualization Managementīy integrating these management functions into the VMkernel, the ESXi architecture became much simpler than ESX. 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. 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. It is from 2011, and wonderfully explains this huge shift in ESX vs ESXi architecture. Not only did this simplify management, but added to the stability and security of ESXi as a whole. We’ve talked a lot about the VMkernel, which is the brains of ESXi. I want to give you a simple overview so you can really begin to understand its capabilities. Like I said, the VMkernel is the brains of the operation. It handles things like resource scheduling, and resource management. The networking and storage stacks are also in the VMkernel, and the ESXi’s hosts device drivers are also handled by the VMkernel. What are VMkernel Ports?īack in the ESX days, we connected to our hosts with a special service console port. This was configured during the installation process of ESX, so we could connect to our hosts to continue to configure them and manage them. Starting with ESXi, we configured a VMkernel port for management.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |