Hypervisors – everything you have always wanted to learn about them

Hypervisors: VMware ESXi, Xen, OpenVZ, KVM


Hypervisors, supervisors, revisors… So many similar words, so easy to get confused. Let’s take a look at the first two – those sound more interesting than those related to verifying legal compliance.

Virtualization and hypervisor

In fact, virtualization per se is a beautiful misimpression. A hypervisor establishes an illusion for the top levels of that system that there are multiple disparate computers – virtual machines – on the same physical hardware. In other words, a hypervisor creates multiple copies of one physical machine, or clones of its hardware capabilities, and a user sees each clone as a separate device. A guest operating system can be installed on a virtual machine by any user, and this OS doesn’t have to be dependent on a real physical hardware (that is, it doesn’t depend on a host that has a particular processor configuration, random access/ disk memory, etc.). Instead of just one computer, you have many of them. And each of them runs its own software independently from one another! However, if you look behind the curtain, you will see that each of those virtual machines is embodied by merely one file (or a set of files) within the host’s memory. Obviously, if you turn a physical machine off, the illusion will disappear, as the hypervisor will stop working. It is like puppets that stop moving when there is no puppeteer behind the scene.

Note: A hypervisor is a piece of software that manages the resources of a computer and allocates those resources among multiple operating systems, thus enabling their simultaneous launch. A hypervisor isolates the launched OSs from each other in such a way that each of them can use the resources dedicated to it exclusively. Also, a hypervisor enables the collaboration between the OSs of virtual machines if there’s a need. Shared access to particular files and data exchange over a local network can be the communication mechanism between the OSs.


Type 1 hypervisors

XenServer (later renamed by the company-owner as Citrix Hypervisor), VMware ESXi and a number of others refer to Type 1 hypervisors. The easiest way to see the software of such hypervisors is as a specific well-knit operating system that can be installed directly onto the hardware (bare-metal) and has the basic characteristics of an OS:

Type 1 Hypervisors

● provides an abstract set of resources (a so-called ‘view from above’) for applications instead of a chaotic set of hardware;

● manages the set of resources (distributes the CPU time, the memory, the input-output devices among the pieces of software that claim to use the computer’s resources, a so-called ‘view from below’).


Such hypervisors are commonly referred to as a microkernel, an autonomous one, or a ‘Hypervisor Type 1’, and it provides an abstraction (a virtual machine service) to the guest OSs launched on the ‘high level’ under its control. Each guest operating system gets an illusion that it can manage the ‘lower-level’ computing resources – similar to the way an OS would function on a real hardware in the kernel mode (or a supervisor mode).

Note: A supervisor is the core unit, the kernel of an operating system (may consist of multiple parts – a software supervisor, a task manager, an input/output supervisor, etc.). The majority of modern Intel and AMD processors for desktops/servers support the virtualization technology on a hardware level and enable OS operation into the kernel mode (privileged) and a user mode. In the meantime, the application for managing the resources of a computer has limited privileges.


Smaller Code

There is something particular about the software for Type 1 hypervisor – its code is hundredfold smaller than those of the most operating systems functioning nowadays. This results into fewer possible mistakes that can make the system freeze. If an OS on one of the user’s virtual machines fails, it should not affect the operation of other tenant machines on the same hardware.  Security enabled by a hypervisor having full control over the hardware resources of a computer powering the virtualization is one of the key requirements towards a hypervisor. That said, the core task of a hypervisor is to perform machine instructions in a secure way without letting a guest OS to:

  • disable an interruption;
  • modify the mapping tables of the virtual memory onto the physical one for the whole computer;
  • modify the data in the memory cells allocated for other launched processes (except for the cases stipulated by the operation logic and the data exchange logic between them).

Infographics - virtual machine (VM)

The system calls are also intercepted and executed within a hypervisor, although from a guest OS’s prospective it looks as if all instructions were simply executed within its own kernel mode. Ideally, a guest OS ‘has no idea’ that the hardware executes its code in the user mode, and the service instructions of the kernel mode are just being emulated. Even if one of the OSs fails and, as a result of an error, destroys its own memory tables and freezes, all other software will carry on working. In a situation like that, a hypervisor remains the only piece of software launched in the top-privileged mode. This property of a hypervisor is called equivalency – the behavior of a user’s software on a virtual machine is no different from the one running on physical hardware (except for the time properties). However, the time of code execution differs significantly – a hypervisor takes some of the processor’s time for its needs and for interception/analysis of the guest OS’s instructions, as well as for emulating some of those. That’s one of the reasons why hypervisor’s efficiency (executing the majority of the code on a virtual machine without any interference like interpretation, etc.) is so important.


Additionally, the physical hardware resources are typically distributed among multiple virtual machines, and each of them only gets a bit of the CPU time on demand. However, this is normally enough to facilitate full operation of most processes (some of which are not constantly and equally loaded). Some of them might be idle waiting for:

  • a user’s activity – keyboard or mouse input;
  • completion of slow-performing peripheral equipment work – a printer, etc.

To make the most of this time, the system re-allocates it for other active processes in a multi-tasking environment.

Type 2 and hybrid hypervisors

Option 2 is to install and run a hypervisor as one of the processes launched on an already operating OS (mostly Linux). In that case, a hypervisor (commonly referred to as a host one as it works on the same level with a host operating system) has far more limited capabilities. VirtualBox, VMware Workstation and KVM (that was initially closely integrated with the core Linux host system, having open source code, a kvm.ko loadable kernel module, QEMU user mode components and a processor-specific module) are classified as Type 2 hypervisors.


Type 2 Hypervisors

There are also hybrid hypervisors combining the attributes of Type 1 and Type 2 (a combination of a ‘thin’ hypervisor and a service OS managed by it). This type of hypervisor manages the processor and the memory directly, and guest OSs get access to the input-output devices via a service OS. One of the most widely-known hybrid hypervisors is Microsoft Hyper-V (both as a separate product and as a role in Windows Server R2 2012, Windows Server 2012, Windows Server R2 2008, Windows Server 2008, some versions of Windows 8, Windows 8.1, Windows 10).


Another popular solution is paravirtualization – a specially prepared guest OS is installed, with its code being modified to work effectively with a Type 2 hypervisor. Obviously, there can’t be any modifications to proprietary closed code systems (such as Windows). However, making changes to most of the Linux versions does not require any authorization.


Many VDS (virtual dedicated servers) providers also tend to use container-based virtualization solutions running on an advanced Linux core. OpenVZ, which powers the Virtuozzo platform, is one of the most popular ones among them. In that case (when a Linux core is used on the host), only Linux OSs can be used as the guest OSs. High performance and optimal utilization of the physical server resources thanks to the high packing density of VMs are the main advantages of the OpenVZ solution. Jailhouse by Siemens is another interesting solution: this hypervisor works as a bare-metal one but is launched on an operating Linux system and facilitates its distribution into isolated ‘cells’ – system partitions responsible for running user’s applications.


In any case, the main goal of any type of hypervisor is to emulate the hardware resources of a computer, to execute machine instructions in a safe manner, and to prevent executing guest OSs’ instructions in a supervisor mode on a real host machine (without intercepting or analyzing them, just emulating their execution). Regardless of the technology details, a hypervisor separates the physical hardware resources and a virtual machine (it is no longer connected to any particular hardware). You can stop a virtual machine and make a snapshot of the processor registers state, the memory pages and the data storage. You can also launch the machine on another set of physical hardware (migrate or clone it), including an option to do so without stopping it or with minimal idle time. A virtual machine enables you to try brand new stuff, verify new pieces of software and operating systems without any risks. In case a VM fails, you won’t have to reinstall everything you have on your computer – you can simply launch a new virtual machine while saving the rest of the software and your data. Besides, a seasoned admin can design traps on a virtual machine that would serve as fake target servers for hackers, track where exactly an attack is coming from and block it. It’s like an aircraft scattering heat traps when taking off and landing in risk areas.


Hypervisors and virtualization systems for Dedicated Servers and Cloud IaaS: VMware ESXi, Xen, OpenVZ, Virtuozzo, KVM, Jailhouse


When choosing the best virtualization technology for each particular use case, you should ask an expert who can take into account the physical hardware available, the software fees, the availability of technical support and a number of other factors. For example, when you plan to use VMware ESXi (or some other hypervisors), you will have to pay a license fee along with a fee for using up-to-date physical hardware for a virtualization system installation. When getting ready for using hypervisors:

  • carefully review the information available on the virtualization software provider’s website;
  • make a preliminary check as to whether the existing physical hardware complies with the minimum technical requirements of a hypervisor;
  • review other properties of the software you choose (to make sure the reality meets your expectations).



Author: Stanislav Komukhayev

Share this: