SEMINAR REPORTOn

Red Hat Virtualization

Submitted By-

Name : ANKUR VERMA

Roll No. : 0902710018

Semester : VI

Section : A

Signature :

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

AJAY KUMAR GARG ENGINEERING COLLEGE

GHAZIABAD

1 | P a g e

Abstract

Virtualization, in computing, is the creation of a virtual (rather than actual) version of something, such as a hardware platform, operating system, a storage device or network resources.The usual goal of virtualization is to centralize administrative tasks while improving scalability and overall hardware-resource utilization.

Virtual Machine is an instance of an operating system which is running on another operating system using a hypervisor or the respective virtual machine manager (VMM) as a base.

Linux is a Unix-like computer operating system assembled under the model of free and open source software development and distribution. The defining component of Linux is the Linux kernel, an operating system kernel first released October 5, 1991 by Linus Torvalds.

Linux was originally developed as a free operating system for Intel x86-based personal computers.

Red Hat Linux is a parent Linux destro with corporative support known as Red Hat Networks (RHN).The enterprise version is also called as RHEL i.e Red Hat Enterprise Linux.

An open source community funded by Red Hat Inc. is popular with the name as Fedora Project, from which the Red Hat incorporates the most stable and developed attributes.

Red Hat Virtualization is creation and management of virtual machines on Red Hat or Fedora using its two hypervisors: KVM and Xen.

2 | P a g e

Acknowledgment

I, Ankur Verma , show my sincere homage to my seminar guides, Ms. Nishu Bansal, Ms. Shiva Tyagi and Ms. Sangeeta Rani for their innumerable acts of timely advice, encouragement and immense support.

I would also like to express my hearty thanks to my friends Ankit Jauhari and Ayushi Singhal for being with me all the times of the system crashes and other issues, and helped me to remove the glitches and errors, during the development of the demonstrations.

Finally, with all my due respect, the two most important persons who initiated and helped me carry my interest in these two, out of league and revolutionary technologies of Red Hat Linux and Virtualization respectively:

1) Mr. Abhay Verma (IT. VIII Sem)2) Mr. Saurabh Singh (Senior Associate, Headstrong Corporation Ltd)

Ankur Verma

3 | P a g e

Contents

AbstractAcknowledgement

Chapter1: Introduction

1. Red Hat Virtualization System Architecturei. Full Virtualization

ii. Para Virtualization2. The Hypervisor3. Intel’s Virtualization Architecture

i. x86 mode :Privilage Levelsa. Current Privilage Levelb. Descriptor privilege level (DPL)c. Requested privilege level (RPL)

ii. Dom0

Chapter2: Operating System Specifications and Hardware Support

1. System Requirementsi. Xen para-virtualization requirements

ii. Xen full virtualization requirementsiii. KVM requirements iv. Storage Support

2. Available Operating Systems (KVM)i. Linux

ii. Solarisiii. Unixiv. Windows

Chapter3: Configurations

1. Physical Address Extension2. Logical Volume Manager3. KVM Packages installation

i. libvirtii. qemu-kvm

iii. python-virtinstiv. virt-managerv. virt-viewer

4 | P a g e

4. Virtual Machine Installation on KVMi. Installation Process through GUI

ii. Installation Process Through CLI

Chapter4: Comparison of various Hypervisors

1. Based on Processing Speed2. Overall Performance

ConclusionReference

5 | P a g e

Images

6 | P a g e

Image Page No

1)Protection Rings 92)Logical Volume lv0 133)Physical Volume Pv0, Pv1, Pv2 154)Installation through GUI

Open Virtual Machine Manager

17

Adding a Connection 17Adding a new VM 18

Selecting Storage Location and size

18

Selecting Virtual Network 18Selecting Memory and CPU Allocation

19

Finalizing the VM Creation 19Created Vm 20

5)Installation through CLI

Launching virt-install 20

Configuration Window 21

6)I/O Performance Comparison 22

7)Performance Summary 22

Chapter1 Introduction

Red Hat Virtualization System Architecture

A functional Red Hat Virtualization system is multi-layered and is driven by the privileged Red Hat Virtualization component. Red Hat Virtualization can host multiple guest operating systems.

Each guest operating system runs in its own domain, Red Hat Virtualization schedules virtual CPUs within the virtual machines to make the best use of the available physical CPUs. Each guest operating systems handles its’ own applications. These guest operating systems schedule each application accordingly.

We can deploy Red Hat Virtualization in one of two choices: Full virtualization

Full virtualization provides total abstraction of the underlying physical system and creates a new virtual system in which the guest operating systems can run. No modifications are needed in the guest OS or application (the guest OS or application is not aware of the virtualized environment and runs normally).

Para virtualization

Paravirualization requires user modification of the guest operating systems that run on the virtual machines (these guest operating systems are aware that they are running on a virtual machine) and provide near-native performance. We can deploy both paravirtualization and full virtualization across our virtualization infrastructure.

The Hypervisor

The hypervisor (Red Hat's Virtual Machine Monitor) is a virtualization platform that allows multiple operating systems to run on a single host simultaneously within a full virtualization environment. Virtualization is available for Red Hat Enterprise Linux 4 Server and more. The VMM modifies the guest’s binary image at runtime to get processor control when guest software attempts to perform a privileged operation.

The VMM can then emulate the privileged operation and return control to guest software.

The requirements for virtualization vary depending on the type of hypervisor. The Kernel-based Virtual Machine (KVM) and Xen hypervisors are provided with Red Hat

7 | P a g e

Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization.

Intel’s Virtualization Architecture

x86 mode :Privilage Levels

The processor’s segment-protection mechanism recognizes 4 privilege levels, numbered from 0 to 3. The greater numbers mean lesser privileges.

The fig. shows how these levels of privilege can be interpreted as rings of protection. The centre (reserved for the most privileged code, data, and stacks) is used for the segments containing the critical software, usually the kernel of an operating system. Outer rings are used for less critical software. (Systems that use only 2 of the 4 possible privilege levels should use levels 0 and 3.)The processor uses privilege levels to prevent a program or task operating at a lesser privilege level from accessing a segment with a greater privilege, except under controlled situations. When the processor detects a privilege level violation, it generates a general-protection exception (#GP).To carry out privilege-level checks between code segments and data segments, the processor recognizes the following three types of privilege levels:

8 | P a g e

• Current privilege level (CPL)

The CPL is the privilege level of the currently executing program or task. It is stored in bits 0 and 1 of the CS and SS segment registers. Normally, the CPL is equal to the privilege level of the code segment from which instructions are being fetched. The processor changes the CPL when program control is transferred to a code segment with a different privilege level.

• Descriptor privilege level (DPL)

The DPL is the privilege level of a segment or gate. It is stored in the DPL field of the segment or gate descriptor for the segment or gate. When the currently executing code segment attempts to access a segment or gate, the DPL of the segment or gate is compared to the CPL and RPL of the segment or gate selector (as described later in this section). The DPL is interpreted differently, depending on the type of segment or gate being accessed.

• Requested privilege level (RPL)

The RPL is an override privilege level that is assigned to segment selectors. It is stored in bits 0 and 1 of the segment selector. The processor checks the RPL along with the CPL to determine if access to a segment is allowed. Even if the program or task requesting access to a segment has sufficient privilege to access the segment, access is denied if the RPL is not of sufficient privilege level. That is, if the RPL of a segment selector is numerically greater than the CPL, the RPL overrides the CPL, and vice versa. The RPL can be used to insure that privileged code does not access a segment on behalf of an application program unless the program itself has access privileges for that segment.

Privilege levels are checked when the segment selector of a segment descriptor is loaded into a segment register. The checks used for data access differ from those used for transfers of program control among code segments; therefore, the two kinds of accesses are considered separately in the following sections.

Dom0

In Red Hat Virtualization, the first domain, known as domain0 (dom0), is automatically created when we boot the system.Domain0 is the privileged guest and it possesses management capabilities which can create new domains and manage their virtual devices. Domain0 handles the physical hardware, such as network cards and hard disk controllers. Domain0 also handles administrative tasks such as suspending, resuming, or migrating guest domains to other virtual machines.

9 | P a g e

Chapter2 Specifications

Operating System Specifications and Hardware Support

To deploy para-virtualization across our operating system(s), we need access to the paravirtual guest kernels that are available from a respective Red Hat distro (for example, RHEL 4.0, RHEL 5.0, etc).

Though the full virtualization is also provided in Red Hat Virtualization scheme where we are allowed to run an unmodified guest kernel if we have Intel VT and AMD SVM CPU hardware. We do not have to port our operating system to deploy this architecture on our Intel VT or AMD SVM systems.

Command to check if we have the CPU flags for Intel support:

#grep vmx /proc/cpuinfo

Command to check if we have the CPU flags for AMD support:

#grep svm /proc/cpuinfo

In addition to checking system flags we also need to enable full virtualization within the system BIOS.

System Requirements

When we run a guest virtual operating system, we must keep in mind that each instance might consume the same, or nearly the same, computing resources that the host system consumes. In other words, we must have enough processing power, disk space, and memory (RAM) available for all the guests we are running. Here are some things to check:

10 | P a g e

Xen para-virtualization requirements

Para-virtualized guests require a Red Hat Enterprise Linux 5 installation tree available over the network using the NFS, FTP or HTTP protocols.

Xen full virtualization requirements

Full virtualization with the Xen Hypervisor requires:

o an Intel processor with the Intel VT extensions, or

o an AMD processor with the AMD-V extensions.

KVM requirements

The KVM hypervisor requires:

o an Intel processor with the Intel VT and the Intel 64 extensions, or

o an AMD processor with the AMD-V and the AMD64 extensions.

Storage support

The supported guest storage methods are:

o Files on local storage

o Physical disk partitions

o Locally connected physical LUNs

o LVM partitions

That storage area can come from a large raw file, a disk partition, logical volume, or one of several different storage file formats.

Storage images such as mypuppy or vm1.img have the advantage of being able to only consume space from our hard disk as the guest requires it.

11 | P a g e

Types of Virtual Machines

The available (valid) operating systems for KVM are:

• LinuxListed distributions include Debian (Etch, Lenny, and Squeeze), Fedora(releases 5–12), Red Hat Enterprise Linux (2.1, 3, 4, and 5), SUSE Linux Enerprise Server, and Ubuntu (8.04, 8.10, 9.04, and 9.10). There are also selections for Linux distributions with generic 2.4, 2.6, and 2.6.25 or later (with virtio) that you can choose.

• Solaris Distributions include Sun OpenSolaris, Sun Solaris 10 and Sun Solaris 9.

• UNIXFreeBSD 6, FreeBSD 7, and OpenBSD 4 are listed as supported distributions.

• Windows Microsoft Windows systems listed include Vista, 2000, 2003, 2008, 7, XP(x86), and XP (x86_64).

12 | P a g e

Chapter3 Configurations

Physical Address Extension

PAE is a technology that increases the amount of physical or virtual memory available to user applications. Red Hat Virtualization requires that PAE is active on our systems. Red Hat Virtualization 32 bit architecture with PAE supports up to 16 GB of physical memory. It is recommended that we have at least 256 megabytes of RAM for every guest we have running on the system. Red Hat Virtualization enables x86/64 machines to address upto physical 64 GB. The Red Hat Virtualization kernels will not run on a non-PAE system.

Command to determine if a system supports PAE:

#grep pae /proc/cpuinfo

A sense of PAE can be taken by observing the physical storage extension module

i.e.:

13 | P a g e

Logical Volume Manager

LVM was started being used on various operating systems since many years ago. In Linux, there was an initial implementation of LVM (now known as LVM1), dating back to 1997.When work on kernel 2.5 begun, there were two competing implementations - EVMS (made by IBM) and LVM2.Eventually, LVM2 won the entrance to the 2.6 kernel, and EVMS remained as an out-of-tree project.

Installing an LVM requires following sequence of commands cast strictly in the given sequence:

Create the required partitions.#fdisk /dev/sda

Create the physical volumes #pvcreate /dev/sda{5,6,7}

Watch the pvsize and also the non-usable size of the partition#pvdisplay

Create volume group of the three partitions thus formed#vgcreate vg0 /dev/hda{5,6,7}#vgdisplay

create the logical volume of the volume group thus formed using command:#lvcreate -L +50M /dev/vg0 -n lv0#lvdisplay

We can even extend this logical volume thus formed using the following command depending upon our use:#lvextend -L +25M /dev/vg0/lv0

Display the logical partition which actually exists for use:#ls /dev/vg*

Finally after the partition is created:mount a file system to it using command:mkfs.ext3 -L /lvm_data /dev/vg0/lv0 Mounting it on a directory to use.mount /dev/vg0/ /mnt

14 | P a g e

15 | P a g e

KVM Packages Installation

# yum groupinstall Virtualization

This installed the following packages, along with about two dozen other packages needed to meet dependencies:• libvirt

Contains the libvirt application programming interface (API) for abstractingaway differences between Xen, KVM, and other virtualization technologies.

• qemu-kvm Contains KVM components associated with QEMU utilities.

• python-virtinstContains commands such asvirt-install (to create and manage virtual guests), virt-convert (to convert VMs into different formats),virt-image (to create VMs from image descriptors), andvirt-clone (to create clone VMs from existing disk images).

• virt-managerContains the virt-manager Virtual Machine Manager application. It is used to start, stop, and otherwise manage virtual guest operating systems. It also can display summary information and statistics about your guest VMs.

• virt-viewer Contains the virt-viewer Virtual Machine Viewer graphical client, which is used to connect to virtual machines via a VNC interface.

The dependencies are configured automatically during the installation process.

16 | P a g e

Virtual Machine Installation Using KVM

A) Installation Process through GUI:

1. Open the Virtual Machine Manager window. Select Applications System ToolsVirtual Machine Manager. The Virtual Machine Manager window appears.

2. Add a connection. Select File Add Connection. The Add Connection pop-up appears.

17 | P a g e

3.Add a new Virtual Machine: Select Domainclick New

4. Selecting Storage Location and Size:

5. Selecting Virtual Network in Select Network:

18 | P a g e

6. Selecting Memory and CPU Allocation

7. Finalising the virtual machine creation

19 | P a g e

8. Enjoy Working with your newly created virtual machine

B) Installation Process through CLI:

#virt-install --prompt

20 | P a g e

The Result of commands opens up the boot configuration window :

21 | P a g e

Chapter4 Comparison

Comparison of Various Hypervisors:

1)Based on processing speed:

2)On Scale of 5(best)

22 | P a g e

The enthusiast

From the enthusiast’s standpoint, KVM would seem like the best choice, most configuration options. Enthusiasts will find plenty of new combinations of settings to experiment with.

KVM’s lack of end-user features and complexity of use also give it the flavour of being a tool for the elite, which the enthusiast is likely to find appealing.

 

Next in line is VirtualBox, which offers fewer options, but still enough to keep a geek interested. Simply reading the manual and following the forums will suffice.

 

VMware Player is last in line for this category of users, since it offers very limited customisability.

 

The architect

For architects, the requirement determines the choice of component. For server virtualisation with an emphasis on performance and scale, KVM is the clear choice.

 

For end users,

VMware Player is the best choice, since it can run a VM authored on Workstation in a manner that makes it extremely easy to use, particularly for a user who’s not tech-savvy.

However, for prototyping and getting off the ground quickly, VirtualBox’ superior feature set makes it the tool of choice.

 

The executive

VirtualBox is the product with the likelihood of meeting the most requirements at the least cost.

If budget was not a constraint, VMware Player’s paid version, VMWare Workstation, could give VirtualBox a run for its money on features. VirtualBox provides many more features in the free version than VMWare. The exception to this is if the VM is being authored elsewhere, and VMWare Player is being used only for access. In that scenario, VMWare Player is much easier to use than either of the other two.

KVM is not really a solution for the executive at all.

 

The follower

From the follower’s viewpoint, the ideal and often only supportable option is to use VMWare Player to run existing VMs (created by Workstation). Next in line is VirtualBox. As with the executive, KVM is not an option for the follower.

23 | P a g e

Conclusion

Virtualization is an everlasting technology and with the advancement in other scenarios like increasing computational needs and resources; its scope is undoubtedly expected to become exponentially more widespread.With various types of virtualizations like Hardware, Desktop, Memory, Software, Data and Network etc. , its application and economic nature will definitely bring the boon spread in every aspect of life and the future is not far where the open source software will definitely lead the world.

And finally it’s always good to have things ‘free’!! An inevitable human nature which will definitely define entirely new boundaries for the open source virtualization.

Thus it’s not a hyperbole if we say that future is ‘Virtually Free’.

24 | P a g e

References

Websites:

• http://docs.RedHat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/ html/Virtualization/

• http://en.wikipedia.org/wiki/Xen

• http://xen.org/

• http:// www.server-world.info/en/note?os=Ubuntu_10.04&p=kvm

• http://libvirt.org/virshcmdref.html

• http://www.linuxforu.com/2011/09/vmware-player-virtualbox-kvm- virtualization-comparative-review/http://www.linuxforu.com/2011/09/vmware-player-virtualbox-kvm-virtualization-comparative-review/

Documents and Books:

• Xen and the Art of Virtualization

Paper by:

Paul Barham, University of Cambridge Computer Laboratory

• Fedora Bible: 2010 Edition

By: Wiley Publication

• Virtualization Guide: Red Hat Virtualization

Copyright © 2007 Red Hat, Inc.

25 | P a g e