ESX 3i is a great opportunity not only to reduce the local storage footprint requirement, but also provide additional RAM and CPU available to virtual machines. ESX 3i is a small footprint, featuring a hardware integrated hypervisor that provides the VMWare ESX server on a small local footprint at around 32 MB.
While the small footprint is attractive in providing a quick install and minimal build time for adding additional hosts and consistent configuration linearly to the VMWare Infrastructure. The other more attractive, and possibly overlooked piece, is that by removing the customized Red Hat Enterprise Linux (RHEL) operating system that hosts the hypervisor in ESX 3.0.2 and earlier, this can free up between two or three percent of local CPU and RAM resources. Alone those are not much, but consider a large VMWare implementation – saving that much local resources can effectively reduce your number of required VMWare ESX hosts systems by providing that much more resources back to the virtual machines. For example, if you have 100 VMWare ESX hosts, you have effectively added the CPU and RAM power of 2 or 3 VMWare hosts by removing the RHEL layer from the host with certain host configurations.
This is a positive direction for the ESX product. For those of you who are historically Windows administrators, how frequently have you tried to do something in the ESX RHEL that didn’t quite turn out as you expected? My secondary virtualization mentor told me:
“If you don’t know anything about Linux or Unix – that will be great for an ESX administrator. If you do have experience there, don’t make assumptions based on the standard product” when introducing ESX.
For most situations where I have tried to do tasks outside of Virtual Center or the ESX install, some other issue has arisen. This, of course, is excepted when VMWare documentation gives Linux commands to perform tasks, David Davis’ recent blog on enabling SSH and SFTP on ESX is a good example. By removing that layer, the ESX product is more aligned to what it needs to do — providing horsepower to guest operating systems with central management.