Wednesday, November 27, 2013

VMware ESXi Design

The ESXi hypervisor shares many common elements with its older big brother ESX classic, but the main differentiator is that the Linux-based Service Console was stripped out. ESXi retains VMkernel and VMM components similar to ESX but has additional features built into the VMkernel; a new, much smaller management console; and other user-mode processes to replace the old Service Console OS functionality.

ESXi was redesigned this way to allow VMware users to scale out through a hypervisor
that is more akin to a hardware appliance. The vision was a base OS that is capable of autoconfiguring, receiving its settings remotely, and running from memory without disks. But it’s also an OS that’s flexible enough to be installed on hard disks along with a locally saved state and user-defined settings for smaller, ready-to-use installations that don’t require additional infrastructure.

Removing the Service Console obviously had an impact. A number of services and agents
that were normally installed had to be rethought. The familiar command-line interface with its
access to management, troubleshooting, and confi guration tools is replaced in ESXi. And the
Linux-styled third-party agents for backups, hardware monitoring, and the like must be provisioned in different ways.

VMware ESXi vs ESX (difference)

The removal of the Service Console fundamentally changed what was possible with VMware’s hypervisor. ESXi has a smaller and less demanding footprint, which means the hypervisor consumes fewer host resources to perform essentially the same functions. ESXi also uses significantly less disk space, whether local disk or boot-from-SAN space. The Service Console of ESX hosts effectively ran as a single vCPU guest, which meant all of its processes ran serially. With ESXi, those functions were moved to the VMkernel, meaning there is greater scope for those processes to run in parallel using much more sophisticated scheduling.

One unequivocal advantage of ESXi’s reduced code base is the greater level of security it brings. An ESX install came in at around 2 GB of installed fi les, whereas ESXi currently is near 125 MB. It’s easy to see that so much less code means less to keep secure with a smaller attack vector. The Service Console provided additional software that had to be secured, which ESXi avoids.

With fewer patches to apply, ESXi reduces the frequency of host-server reboots and lessens the administrative burden of regular patching. Any large enterprise with a sizable collection of ESX hosts will be only too familiar with the seemingly never-ending cycle of host patching. ESXi patches come as a single relatively small file, as opposed to ESX patches, which could be very large. Patching is also easier to manage if hosts are spread across several remote sites, particularly where slow WAN links cause issues with vCenter Update Manager’s (VUM’s) ability to push out these large packages. Another advantage with ESXi’s patches is that they come as a single firmware-like image that updates everything. Compare this to ESX patches, which came in multiple updates, potentially with dependencies on previous patches, and required multiple reboots.

An ESXi host is also more reliable than an ESX classic host. It effectively has less code to go wrong and fewer processes running over and above the VMs. The ability of the Service Console to run third-party agents was a double-edged sword, because although it allowed you to add extra functionality, some of the available agents caused stability issues on hosts. The inability of ESXi hosts to run unmanaged code means this is no longer a concern. Additionally, the dualimage nature of ESXi means there is always a standby bootable copy of the OS to roll back to, should you have any problems with an update.

ESXi brings with it the possibility of running hosts in a practically Stateless mode, meaning host servers are more comparable to hardware appliances. The deployment techniques available for ESXi are similar to those for ESX, but the install is considerably easier. You’re prompted for very little information, and the install time is incredibly short. You don’t need to understand the nuances of a POSIX fi lesystem and how best to carve up ESX’s partitions. Even rebooting an ESXi server takes considerably less time than rebooting an equivalent ESX classic host.

The simplifi cation of host management, with no need to understand a Service Console when confi guring and troubleshooting, means a lower entry bar for staff to install and maintain new vSphere environments. The simple Direct Console User Interface (DCUI) screen is more comparable to a BIOS setup screen and far less intimidating to staff unfamiliar with Linux. If a problem exists in a remote offi ce and there are no remote access cards or a keyboard, video and mouse (KVM) switch, then it’s more feasible that an onsite employee might be able to assist in restarting a management daemon.

ESXi has so many advantages that it’s clearly the better option for VMware and the company’s customers moving forward. Despite the many ESX classic installations that still exist awaiting migration to ESXi, clearly the smart option—the only option—is to deploy ESXi. Thanks to vSphere’s inherent abstraction, migrating VM workloads is relatively trivial and pain-free.

VMware vSphere Hypervisor

The term VMware vSphere hypervisor is actually a marketing term to specifi cally refer to the standalone version of ESXi that can be downloaded for free from the VMware website. It’s a restricted version of the hypervisor that can’t be managed by a vCenter instance. Remote connections via APIs are read-only, which limits third-party software such as backup and cloning tools, and there is a hard limit of 32 GB of physical memory for the host. It’s offered as a direct response to other free hypervisors on the market and is a useful springboard for many administrators just discovering virtualization.