Cloud 101: Flavors of hypervisors

Virtualization, as we know in information technology (IT), is not a new technology. Its history goes back to the early 1960s when IBM invented virtualization to run multiple software contexts on the IBM mainframe. In the 1960s no one knew that this technology would be of immense importance to IT after 50 years.

Virtualization has created a revolution in the IT landscape. Simply put, virtualization is a process of abstraction of computing resources (CPU, memory, storage, network and so on) from users and applications. Although virtualization is not a requirement for cloud computing, cloud computing offerings without virtualization are not very common. In this blog post, we’ll see how virtualization is achieved by means of a hypervisor or virtual machine manager (VMM).

I would recommend that those who are new to hypervisor technology read an interesting blog entitled “What is a hypervisor?” by David Beaumont. A hypervisor or VMM is a virtualization software that allows multiple operating systems (OS) to share the resources of the same physical server. This physical server is known as the host server. We denote the operating systems as the guest operating systems. Virtual machines (VM) are software-based abstractions of the hardware. As VMs are decoupled to the underlying hardware, it becomes very easy to move VMs from one physical server to another. Cloud computing relies heavily on this feature because of the distributed nature of computing environments and operations.

Hypervisors can be categorized into two main types. The first one is called a native, bare metal or type 1 hypervisor. The second type is called a type 2 or hosted hypervisor.

types of hypervisorsFigure 1: Types of hypervisors (Image source: Infrastructure as a Service)

As we can see in figure 1, a bare metal hypervisor runs directly on the physical server. It has control over the server’s resources and can allocate resources to guest operating systems or VMs as required. VMs run on top the bare metal hypervisor. Finally, the applications run on the VMs like any other operating systems. Normally applications are not aware of the virtualization. The underlying hardware is abstracted from the applications running on VMs. Examples of bare metal hypervisors are IBM z/VM, Microsoft Hyper-V, VMWare ESXi and Citrix XenServer. It is important to remember that there are two layers of software stack in a bare metal hypervisor.

On the contrary, a hosted hypervisor has three layers of software stack. As indicated in figure 1, a host operating system runs directly on the physical server. It is known as level 1. A hypervisor sits in level 2 on top of the host operating system. As we can see in figure 1, both the hypervisor and traditional non-virtualized applications run on a host operating system as level 2 software. Finally, the VMs run on top of the hypervisor at level 3. VMs contain guest operating systems and applications running on the guest OS. Like a type 1 hypervisor, applications running on guest operating systems in type 2 hypervisors are also not aware of virtualization. Some examples of type 2 hypervisors are VMware Server, Oracle VM VirtualBox and Microsoft Virtual PC.

nested hypervisorsFigure 2: Nested virtualization and hypervisors (Image source: Nested virtualization for the next-generation cloud)

We can see another variant of virtualization known as nested virtualization in figure 2. In this arrangement one hypervisor sits on top of a host hypervisor. This will provide a greater flexibility in the cloud, as VMs are totally decoupled from the host hypervisor.

I hope that this blog post has provided you with an overview of hypervisors. In my future blogs on hypervisors, I will present how hypervisors control data traffic between VMs. Leave a comment below or connect with me on Twitter @shamimshossain.

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Archive Stories

ITIL and cloud series: Service design for cloud implementation

Your business is changing and you verified cloud computing as a possible solution. You have defined your strategy, formed a vision and a roadmap to realize it, and decided on the service and deployment models to start with. Now you need to focus on the design of your cloud implementation and you need consultants and architects, helping you with the base of good practices and proven architectures.

Introduction to the RESTful API of IBM SmartCloud Enterprise

The IBM SmartCloud Enterprise RESTful API follows the RESTful principle. It is based on HTTP request using the GET, POST, PUT, and DELETE methods to take actions on the IBM SmartCloud Enterprise platform. RESTful APIs are web-services and thus are often used in a SOA environment, nevertheless some scripting techniques, using for example cURL, are well adapted to use a RESTful API.

IBM SoftLayer: Data center as a service (DCaaS)

IBM SoftLayer has been recommended by various stakeholders as an infrastructure as a service (IaaS) provider. It can certainly be viewed as such. It provides a lot of automation tools out of the box, as well as the ability for customers to bring their own automation tools to integrate with the SoftLayer application programming interface […]