Book Image

Mastering KVM Virtualization - Second Edition

By : Vedran Dakic, Humble Devassy Chirammal, Prasad Mukhedkar, Anil Vettathu
Book Image

Mastering KVM Virtualization - Second Edition

By: Vedran Dakic, Humble Devassy Chirammal, Prasad Mukhedkar, Anil Vettathu

Overview of this book

Kernel-based Virtual Machine (KVM) enables you to virtualize your data center by transforming your Linux operating system into a powerful hypervisor that allows you to manage multiple operating systems with minimal fuss. With this book, you'll gain insights into configuring, troubleshooting, and fixing bugs in KVM virtualization and related software. This second edition of Mastering KVM Virtualization is updated to cover the latest developments in the core KVM components - libvirt and QEMU. Starting with the basics of Linux virtualization, you'll explore VM lifecycle management and migration techniques. You’ll then learn how to use SPICE and VNC protocols while creating VMs and discover best practices for using snapshots. As you progress, you'll integrate third-party tools with Ansible for automation and orchestration. You’ll also learn to scale out and monitor your environments, and will cover oVirt, OpenStack, Eucalyptus, AWS, and ELK stack. Throughout the book, you’ll find out more about tools such as Cloud-Init and Cloudbase-Init. Finally, you'll be taken through the performance tuning and troubleshooting guidelines for KVM-based virtual machines and a hypervisor. By the end of this book, you'll be well-versed with KVM virtualization and the tools and technologies needed to build and manage diverse virtualization environments.
Table of Contents (22 chapters)
Section 1: KVM Virtualization Basics
Section 2: libvirt and ovirt for Virtual Machine Management
Section 3: Automation, Customization, and Orchestration for KVM VMs
Section 4: Scalability, Monitoring, Performance Tuning, and Troubleshooting

Using the hypervisor/virtual machine manager

As its name suggests, the Virtual Machine Manager (VMM) or hypervisor is a piece of software that is responsible for monitoring and controlling virtual machines or guest OSes. The hypervisor/VMM is responsible for ensuring different virtualization management tasks, such as providing virtual hardware, virtual machine life cycle management, migrating virtual machines, allocating resources in real time, defining policies for virtual machine management, and so on. The VMM/hypervisor is also responsible for efficiently controlling physical platform resources, such as memory translation and I/O mapping. One of the main advantages of virtualization software is its capability to run multiple guests operating on the same physical system or hardware. These multiple guest systems can be on the same OS or different ones. For example, there can be multiple Linux guest systems running as guests on the same physical system. The VMM is responsible for allocating the resources requested by these guest OSes. The system hardware, such as the processor, memory, and so on, must be allocated to these guest OSes according to their configuration, and the VMM can take care of this task. Due to this, the VMM is a critical component in a virtualization environment.

In terms of types, we can categorize hypervisors as either type 1 or type 2.

Type 1 and type 2 hypervisors

Hypervisors are mainly categorized as either type 1 or type 2 hypervisors, based on where they reside in the system or, in other terms, whether the underlying OS is present in the system or not. But there is no clear or standard definition of type 1 and type 2 hypervisors. If the VMM/hypervisor runs directly on top of the hardware, its generally considered to be a type 1 hypervisor. If there is an OS present, and if the VMM/hypervisor operates as a separate layer, it will be considered as a type 2 hypervisor. Once again, this concept is open to debate and there is no standard definition for this. A type 1 hypervisor directly interacts with the system hardware; it does not need any host OS. You can directly install it on a bare-metal system and make it ready to host virtual machines. Type 1 hypervisors are also called bare-metal, embedded, or native hypervisors. oVirt-node, VMware ESXi/vSphere, and Red Hat Enterprise Virtualization Hypervisor (RHEV-H) are examples of a type 1 Linux hypervisor. The following diagram provides an illustration of the type 1 hypervisor design concept:

Figure 1.1 – Type 1 hypervisor design

Figure 1.1 – Type 1 hypervisor design

Here are the advantages of type 1 hypervisors:

  • Easy to install and configure
  • Small in size; optimized to give most of the physical resources to the hosted guest (virtual machines)
  • Generates less overhead as it comes with only the applications needed to run virtual machines
  • More secure, because problems in one guest system do not affect the other guest systems running on the hypervisor

However, a type 1 hypervisor doesn't favor customization. Generally, there will be some restrictions when you try to install any third-party applications or drivers on it.

On the other hand, a type 2 hypervisor resides on top of the OS, allowing you to do numerous customizations. Type 2 hypervisors are also known as hosted hypervisors that are dependent on the host OS for their operations. The main advantage of type 2 hypervisors is the wide range of hardware support, because the underlying host OS controls hardware access. The following diagram provides an illustration of the type 2 hypervisor design concept:

Figure 1.2 – Type 2 hypervisor design

Figure 1.2 – Type 2 hypervisor design

When do we use type 1 versus type 2 hypervisors? It primarily depends on whether we already have an OS running on a server where we want to deploy virtual machines. For example, if we're already running a Linux desktop on our workstation, we're probably not going to format our workstation and install a hypervisor – it just wouldn't make any sense. That's a good example of a type 2 hypervisor use case. Well-known type 2 hypervisors include VMware Player, Workstation, Fusion, and Oracle VirtualBox. On the other hand, if we're specifically aiming to create a server that we're going to use to host virtual machines, then that's type 1 hypervisor territory.