To ESXi and beyond

Like I also blogged about in a previous blog posting, the Service Console of ESX is being discontinued and that leaves us with ESXi as the only option for the future.  vMA will take the Service Console’s role for command line stuff and you only need one of these for managing many servers.

First I’d like to give a shortened history lesson so we can better understand where we are today and where we’re heading. I didn’t include every new feature here, but only those I regard as the most important ones regarding the evolution from tightly bound systems to stateless ones.

VMware have provided technologies that for each iteration has had a greater level of statelessness than the previous version.  Version 1.x of ESX could run one VM per physical cpu. When ESX 2.0 was released in 2003 you could no longer count the cpus to get the number of VMs anymore as this limit was removed. Instead of binding each VM to a cpu it would load balance all of the running VMs across all available cpus, and it could now also run multiple VMs per cpu. After the introduction of Virtual Center in 2004, data center admins no longer needed to know which physical server a VM is running on. Virtual Center gave you the ability to administer all your ESX hosts from a single interface and with VMotion you could move your VMs from physical host A to B without any service interruption.

ESX 3 was released in 2006 and brought in new important features such as a  Distributed Resource Scheduler (DRS) and Distributed Availability Services (VMware HA). These new features would ensure that the performance of your environment was optimal at any time and that all of your VMs was running, even if a host died or if a VM or two would start eating up a lot of resources.

ESX 3.5 was released late in 2007 and came with the ability to migrate VMs between different cpu models (EVC), the ability to change datastore for your VMs while running and a software update utility for hosts and guest VMs. ESXi (or 3i as it was called back then) was also released at the same time and could do everything that a full blown ESX host could do, except for the missing Service Console.

In 2008 we had the release of Site Recovery Manager (SRM). Having a recovery site (a datacenter at a remote location that will host all your services in case of a disaster) is something that has existed in the physical world for quite some time, but there has not been a unified solution that would work equally for all kinds of services.  Virtualization is a game changer here as it uncouples the servers from their physical hardware and with SRM you could also bring up a copy of your main datacenter at the disaster site within minutes by the click of a single button.

With vSphere 4.0 they also introduced host profiles and distributed switches for making it easier to deploy the same configuration across multiple ESX hosts. SRM was also updated to support two active data centers.

VMware demoed booting of ESXi from the network back at VMworld 2009, and it is surely something that will be coming as an official feature from VMware in the future. By doing this you get the same advantages that you get with your VMs today as you’re unbinding the systems from their hw. It also lowers your deployment time (of a new host) as you don’t have to install anything. We also have a similar technology from VMware already with VMware View where all users boot from the same disk image (linked clones). The users may also already be using stateless thin clients to access these desktops.

A couple of years ago I showed some end users from the company I worked for around in the data center and they were wondering what server “their” system was running on. My answer was that I didn’t know. All I knew was that their system was running on one of the ESX servers, but it could change server without anyone knowing it and without anyone noticing it. I also told them that there were around 80 virtual servers running on these 4 physical boxes and that it would have taken two full racks of pizza box servers if we had not been running it like that. 

As we all know ESX is an acronym for Elastic Sky X. I don’t know if they were having cloud computing in mind when they invented that name, but it surely seems to be a name that fits the future. Now that traditional ESX is going away we’re left with ESXi which gives us Elastic Sky XI. XI in roman numerals equals 11, something I take as a hint to that 2011 is the year ESXi can help use move VMs into the sky. 

So I guess when I show around end users again in the data center in a year or two, my answer would be “your system may be running on these boxes here, or on one of the similar ones  in our secondary data center, but if it is running some heavy transactions it may also have been temporarily migrated to a more powerful system out somewhere on the internet”.