Quick-Take: It’s Time to Upgrade from ESX to ESXi

January 15, 2010

That’s right, I said upgrade from ESX to ESXi – not ESX 3.x to vSphere, but ESX (any version) to vSphere’s ESXi! Ever since VMware PartnerExchange 2009 (April), SOLORI has been advising clients and prospects to focus on ESXi and move away from ESX-based hosts – you know, the one with the “Linux” service console. Personally, I’m glad VMware has strengthened their message about the virtues of ESXi and the direction of their flagship product.

ESXi has a superior architecture and we encourage customers to deploy ESXi as part of any new vSphere deployment. Our future posts will compare ESX 4 and ESXi 4 in detail on topics like hardware compatibility list, performance, and management to demonstrate that ESXi is either on par with or superior than ESX. But for now, here are some key points you should know about ESXi vs. ESX:

  1. The functionality and performance of VMware ESX and ESXi are the same; the difference between the two hypervisors resides in their packaging architecture and operational management. VMware ESXi is the latest hypervisor architecture from VMware. It has an ultra thin footprint with no reliance on a general-purpose OS, setting a new bar for security and reliability (learn more).
  2. In the future, ESXi’s superior architecture will be the exclusive focus of VMware’s development efforts.
  3. New and existing customers are highly encouraged to deploy ESXi. Many Fortune 100 companies have already standardized on the ESXi platform.

VMware Blog, June, 2009

Not unfamiliar with the VI3 version of ESXi, its ease of installation, configuration and management and smaller footprint, I was one of about 10 participants in an “ESXi BoF Breakout Session” with Charu Chaubal of VMware. While discussing vSphere’s ESXi with Charu, I never heard the words “ESXi is a superior architecture,” but I did get a clear message that ESXi was the way of the future. From that point on, it seemed as though any efforts concentrated on (net new) ESX deployments was going to be “time wasted.”

However, it was clear by the whispered tone about ESXi’s virtues that the timing was not right for the real message to be spoken aloud. Remember, this was the launch of vSphere and “ESXi” was strongly associated with “ESXi Free” – not a clear marketing message when license sales and adoption curves are on the line. Perhaps that’s why the “talking points” at PEX2009 always suggested that ESX was the “flagship” hypervisor and ESXi was “targeted for embedded and OEM” deployments.

In practical terms, migration from ESX 3.x to vSphere/ESXi didn’t make a lot of sense for many large or institutional customers at the time due to the lack of third-party driver parity between ESX and ESXi in vSphere. However, for net new installations where thrid-party drivers and service console agents were not a concern, the message about ESXi’s superiority was getting lost. Thomas Paine once said “what we obtain too cheap, we esteem too lightly” and I’d attribute the slow uptake on ESXi to the perception that it was somehow inferior to ESX – a misconception owed to it being offered in a “free” version.

Price is what you pay; value is what you get.

– Warren Buffet

By Warren Buffet’s standards, ESXi is a tremendous value. For the novice entering bare-metal virtualization for the first time, the relative ease with which ESXi installs to a USB flash drive allows for a trial experience that is both quick and reassuring. I’d argue that ESXi’s tiny memory footprint and generous hardware support make it the easiest platform for testing bare-metal virtualization. As I’ve blogged about, ESXi takes about 14 minutes to install to USB flash – from initial CD-ROM boot to configuration console.

Anyone experienced with ESX will have encountered service and performance affecting IRQ sharing issues with the service console. The hours discovering, tracking and mitigating these kinds of issues after a BIOS update or hardware refresh can never be reclaimed. The fact is these problems simply do not exist for ESXi – something many ESXers will appreciate.

I’ve attended a great deal of WebEx sessions on VMware products over the last year and I’m still hearing hushed tones and uncertainty about the role of ESXi versus ESX. To be clear, ESXi is being talked about as “enterprise ready,” but much of the focus is still on ESX. These overtones were still present in an “vSphere: Install, Configure and Manage” course I recently attended to qualify for VCP410. While our instructors were very knowledgeable and experienced, there seemed to be much less confidence when discussing ESXi versus ESX. In fact, the lab guide clearly states:

If you are new to VMware vSphere and you do not have any special needs for more advanced features, use ESXi.

– Page 599, Module 13, Installing VMware ESX and ESXi

The manual – and VMware’s choice of message here – seems to indicate that ESX has “more advanced features” than ESXi. While the “advanced features” VMware is talking about are service console related, it leaves many regarding ESXi as the inferior product in sharp contrast to today’s message. If the statement “ESXi’s superior architecture will be the exclusive focus of VMware’s development efforts” isn’t writing on the wall for the rest of you, here’s a list of VMware’s new talking points on ESXi:

  • Improved Reliability and Security
  • Fewer Patches
  • Less Disk Space
  • Streamlined Deployment and Configuration
  • Reduced Management Overhead
  • Next Generation Hypervisor
  • Superior Architecture
  • Drastically Reduced Hypervisor Footprint
  • Smaller Code Base, Smaller Attach Surface
  • Certified on over 1,000 Server Systems – including USB keys
  • New, Operating System Independent

In contrast, the ESX platform is being re-imaged. Here are some new talking points about ESX:

  • The Older Architecture
  • Relies on Linux OS for Resource Management
  • 20x Larger on-disk Footprint
  • More Complex to Configure
  • Console OS Administration for Configuration and Diagnostics
  • Prone to Arbitrary Code Execution (Console OS)

For many of us familiar with both ESXi and ESX, nothing here is really new. The only real change is the message: build your eco-system around ESXi…

SOLORI’s Take: It’s clear to me that VMware took inventory of its customers and chose to lead with ESX when vSphere was released. I suspect this was a practical decision due to the overwhelming numbers of ESX hosts already installed. However, the change in marketing and positioning we’re witnessing signals that we’re moving toward a time when ESX will be openly considered a dead-end variant.

When will ESX be phased-out? That’s up to market forces and VMware, but the cloud loves efficiency and ESXi is certainly more resource efficient and compartmentalized than its brother ESX. Furthermore, VMware has to maintain two development and support chains with ESX and ESXi and Darwin likes ESXi. If I had to bet, I wouldn’t put my money on seeing an ESX version of the next major release. In any case, when ESX is gone VMware can stop having to make excuses for the “linux console” and the implications that VMware is somehow “based on Linux.”


  1. […] the article here: Quick-Take: It's Time to Upgrade from ESX to ESXi … Posted in: Virtualization ADD […]


  2. correction/syntax & readability: “and lead with ESX” is now “and chose to lead with ESX” in SOLORI’s Take


  3. Hey! good read….

    from talking to our VMware technical account manager it is clear that ESXi is the strategic future for their virtualisation portfolio.

    There are 3rd party considerations for such a move, integration with enterprise management agents such as HP SIM, BMC Patrol or Enterprise wide directory authentication such as PAMS, Centrify Direct Control or Quest Authentication Services (Vintela).

    As for putting money on the next version of VMware being ESX or ESXi – without the support of third party management tools, critical production virtualised production platforms will not be able to move from ESX. Until this is addressed (and not by some unsupported hack) I cannot see how ESX can be dropped.



    • Stu:

      Thanks. Good specific points on what I lumped into “third-party drivers and console agents,” and an important detail for VMware’s partners to address prior to ESXi’s succession. Indeed, there are many useful third-party tools yet to make the transition.

      To VMware’s credit, I think the vAPI approach (in vSphere) made it much easier for third-parties to hook into (as opposed to hack into) the foundation products as the preferred approach, and we’re already seeing API-based releases of previously legacy products doing just that. I would speculate that a vSphere 4.5-ish product may “penalize” non-API products (i.e. work, but sub-optimally) prior to a complete denial of compatibility in the next full release.

      Pressure from VMware will not be enough, though, and customers need to ply their vendors for sustainable adoption. Now is a good time to start aligning third-party tools with ESXi-based implementations and, if necessary, begin looking for ESXi-compliant alternatives to fill your VMware Eco-System.



      • My sense has been that VMware did not completely think through the ESXi strategy, especially for customers with many hosts or hosts spread across a country or continent.

        First example, we are deploying ESXi 4 hosts to our remote offices. In all cases we are using internal HDD for storage as shared storage is not justified. My biggest problem with this solution was that we had no way of seeing the health of the RAID controller, only the HDDs. We were lucky that we picked Dell and that Dell has release an OpenManage agent specifically for ESXi 4. Now we can see and configure the RAID controller. I haven’t yet testing the alerting for the RAID controller, but I am hopefull. If we were still using IBM xSeries then we would be plain out of luck.

        Second example, there is no means of updating system firmware (BIOS, etc) using ESXi. This is something we could do with ESX and the IHV’s HMA (hardware management agent) such as Dell OpenManage or IBM Director. This means that we need to go to the OOBM interface such as iDRAC and install the updates one at a time.


  4. One of the biggest issue for ESXi deployment in large environments, is that you can’t kickstart deploy ESXi yet. Once that changes, things will move faster for the migration to an hypervisor without a console service.


  5. “In any case, when ESX is gone VMware can stop having to make excuses for the “linux console” and the implications that VMware is somehow “based on Linux.””

    ESXi is still based on linux…BusyBox linux to be exact.


    • Derek:

      To say “ESXi is based on Linux” is kind of like saying “Ubuntu is based on GDM” – especially since the key to your argument is “BusyBox linux.” BusyBox is neither a linux kernel nor a distribution!

      BusyBox’s is an execution environment – its use does not indicate a Linux kernel any more than the use of GDM depicts an underlying Ubuntu system. VMware’s customized derivative of BusyBox is used in ESXi to replace the basic functionality served by the RedHat VM (service console) in ESX (classic) but without the additional surface area to secure.

      William Lam has a great post on compiling BusyBox for your ESXi host (unsupported):



Comments are closed.

%d bloggers like this: