Monday 8 February 2010

ESX v ESXi

Many of you will be aware that in terms of enterprise-level virtualization software from VMware, we currently have the set of products titled "vSphere 4", the foundation building block of which is ESX 4 and ESXi 4.

ESX dates back to 2001 when it was first launched as a 1.0 product, before it became part of VMware Infrastructure 3 (VI3) and now vSphere 4. ESXi didn't arrive until 2007, as a 3.5 version, and was initially only available as "ESX Embedded" inside servers made by the likes of HP and Dell. It didn't take long for VMware to also offer this new embedded hypervisor as an installable product, and at the same time it was renamed to become ESXi.

So these days, customers have the option of installing and using either ESX or ESXi, or even a combination of the two, and as such a question I'm asked all the time by customers is "Which one should we use?" Before you read on, if you're wondering what the actual differences between them are, click here.

My answer back in 2007 was always that ESX was generally the better choice as ESXi was more difficult to manage and troubleshoot, it's integration with 3rd-party products was poor, but looking back that's because ESX was familiar to me and the wider market, and ESXi was new and different and 3rd-party vendors had yet to release products that could interface with ESXi.

Since then, there have been huge numbers of blog articles and whitepapers on ESXi management and troubleshooting, and the major 3rd-party vendors now have similar or identical support for both ESX and ESXi, as such when I am asked the same question today my response is quite different.

To me, the key factor these days is whether I depend on the Service Console in ESX, or whether I have a script or 3rd-party product that does. If I was deploying vSphere today, in most cases I'd use ESXi over ESX, in spite of ESXi still not being quite the same beast to handle as ESX.

So why has my answer changed? It's not just because of the positive and negative points raised above, it's more due to the rich set of programming interfaces and APIs that are common to both ESX and ESXi (particularly the vSphere CLI and vSphere PowerCLI), and the fact that VMware will be retiring ESX by the time we get to vSphere 5. Organizations that have established VI3/vSphere 4 as the basis for their virtualization layer will have to get used to life without the Service Console, so if you can get by without it today in terms of scripting/troubleshooting and 3rd-party product support then you are helping yourself in the longer term.

Oh, and just in case you were wondering why I created this post today, I just became aware of a new set of pages that appeared on VMware's website recently: ESX to ESXi Upgrade Center. Interesting reading....

2 comments:

  1. You just happened to post this the same day I was looking into the key differences between the ESX and ESXi (and reading some of the same links mentioned here). I'm presently supporting an ESX 3.5 infrastructure, but the ESXi model of a very thin hypervisor seems to be the direction VMware is headed. Thanks for posting!

    ReplyDelete
  2. Agreed with the API comment - in the domain that I spend the most time in it's the vStorage API set that VMware has done a good job of working across versions and across ESXi and ESX.

    I posted an overview from a backup perspective of both ESX and ESXi in 3.5 and 4 at http://www.unitrends.com/weblog/index.php/2010/02/20/backup-vmwares-roadmap-and-esx-versus-esxi/

    ReplyDelete