If you have not had a chance, I would definitely recommend you check out the recently launched “VMware ESX to ESXi Upgrade Center.” We launched this upgrade center to help customers and partners get comfortable with ESXi because we’ve stated on numerous occasions that in the future, ESXi will be the exclusive focus of VMware development efforts.
Why have we made this decision to move towards the ESXi architecture? Simply put, we wanted to improve hypervisor management in regards to security, deployment and configuration, and ongoing administration. You can read more about all the benefits at the Upgrade Center or ESXi product page, but as a quick snapshot, take a look at this graph of how ESXi reduces the number of patches compared to traditional ESX (over the same timeframe).
It just goes to show you what removing the dependency on a general purpose OS in the virtualization layer can do for you. Goodbye patches for general purpose operating system code that wasn’t required for core virtualization functionality. (Although the console OS in traditional ESX serves a vastly different purpose than the Parent Partition in Hyper-V or Domain 0 in Xen, but that’s a whole separate discussion.)
As expected, not everyone agrees with our approach of reducing the role of a general purpose operating system in the virtualization layer. Just take a look at a Microsoft marketing brochure that proudly highlights how their virtualization layer is part of general purpose Windows. But it is very interesting how, once you talk to knowledgeable people outside of the Hyper-V marketing team, you find resoundingly consistent agreement that a smaller code base is the way to go for protecting your mission-critical virtualization layer.
- From a leading virtualization security analyst’s blog (Feb 2010):
“The lesson from all of this is that thinner is better from a security perspective and I’d argue that the x86 virtualization platforms that we are installing (ESX, Xen, Hyper-V and so on) are the most important x86 platforms in our data centers. That means patching this layer is paramount. With Hyper-V’s parent partition that means closely keeping an eye on Microsoft’s vulnerability announcements to see if it is affected.” (emphasis added)
- From an article quoting another leading virtualization analyst (Nov 2009):
“Problem two is a bigger, architectural problem that he was told about by R2 beta users. As he explains it, in a Hyper-V environment, every physical host has a copy of Windows that is used as the parent OS. It manages the I/O drivers and is home to any management agents that are installed. ‘If I want to use PowerShell, I’m also using the parent OS for that,’ he declares, ‘so what you end up with is one big, fat, single point of failure.’” (emphasis added)
- Finally, let’s look at what a Director in the Microsoft Azure team said was a key design principle for Azure:
“[Design Principle #2] Small footprint: any features not applicable to our specific cloud scenarios are removed. This guarantees that we do not have to worry about updating or fixing unnecessary code, meaning less churning or required reboots for the host.” (emphasis added)
Pretty good independent confirmation of our approach with ESXi.
So give ESXi a try if you’ve never done so. If you already own vSphere licenses, you have the option of deploying any of those licenses as either ESXi or as traditional ESX. If you don’t have vSphere, download ESXi for free.