You are on page 1of 25

SEMINAR REPORT

On

Red Hat Virtualization


Submitted By-

Name Roll No.

: :

ANKUR VERMA 0902710018 VI A

Semester : Section :

Signature :

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

AJAY KUMAR GARG ENGINEERING COLLEGE GHAZIABAD

1|Page

bstract

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|Page

cknowledgment

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|Page

ontents

Abstract Acknowledgement Chapter1: Introduction 1. Red Hat Virtualization System Architecture i. Full Virtualization ii. Para Virtualization 2. The Hypervisor 3. Intels Virtualization Architecture i. x86 mode :Privilage Levels a. Current Privilage Level b. Descriptor privilege level (DPL) c. Requested privilege level (RPL) ii. Dom0 Chapter2: Operating System Specifications and Hardware Support 1. System Requirements i. Xen para-virtualization requirements ii. Xen full virtualization requirements iii. KVM requirements iv. Storage Support

2. Available Operating Systems (KVM) i. Linux ii. Solaris iii. Unix iv. Windows Chapter3: Configurations 1. Physical Address Extension 2. Logical Volume Manager 3. KVM Packages installation i. libvirt ii. qemu-kvm iii. python-virtinst iv. virt-manager v. virt-viewer

4|Page

4. Virtual Machine Installation on KVM i. Installation Process through GUI ii. Installation Process Through CLI Chapter4: Comparison of various Hypervisors 1. Based on Processing Speed 2. Overall Performance Conclusion Reference

5|Page

mages

Image 1)Protection Rings 2)Logical Volume lv0 3)Physical Volume Pv0, Pv1, Pv2 4)Installation through GUI Open Virtual Machine 17 Manager Adding a Connection 17 Adding a new VM 18 Selecting Storage Location and size Selecting Virtual Network Selecting Memory and CPU Allocation Finalizing the VM Creation Created Vm 5)Installation through CLI Launching virt-install Configuration Window 18 18 19 19 20

Page No 9 13 15

20 21

6)I/O Performance Comparison

22

7)Performance Summary

22

6|Page

Chapter1

ntroduction

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 guests 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|Page

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

Intels Virtualization Architecture x86 mode :Privilage Levels


The processors 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|Page

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|Page

Chapter2

pecifications

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 o

an Intel processor with the Intel VT extensions, or an AMD processor with the AMD-V extensions.

KVM requirements The KVM hypervisor requires:


o o

an Intel processor with the Intel VT and the Intel 64 extensions, or an AMD processor with the AMD-V and the AMD64 extensions.

Storage support The supported guest storage methods are:


o o o o

Files on local storage Physical disk partitions Locally connected physical LUNs 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: Linux Listed distributions include Debian (Etch, Lenny, and Squeeze), Fedora (releases 512), 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. UNIX FreeBSD 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

onfigurations

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 abstracting away differences between Xen, KVM, and other virtualization technologies. qemu-kvm Contains KVM components associated with QEMU utilities. python-virtinst Contains commands such as virt-install (to create and manage virtual guests), virt-convert (to convert VMs into different formats), virt-image (to create VMs from image descriptors), and virt-clone (to create clone VMs from existing disk images). virt-manager Contains 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

omparison

Comparison of Various Hypervisors: 1) Based on processing speed:

2) On Scale of 5(best)

22 | P a g e

The enthusiast From the enthusiasts standpoint, KVM would seem like the best choice, most configuration options. Enthusiasts will find plenty of new combinations of settings to experiment with. KVMs 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 whos not techsavvy. 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 Players 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 followers 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

onclusion

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 its always good to have things free!! An inevitable human nature which will definitely define entirely new boundaries for the open source virtualization. Thus its not a hyperbole if we say that future is Virtually Free.

24 | P a g e

eferences

Websites: http://docs.RedHat.com/docs/enUS/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-kvmvirtualization-comparativereview/http://www.linuxforu.com/2011/09/vmware-playervirtualbox-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

You might also like