This Workshop was conducted at Pragati Maidan in Linux Asia 2008

Workshop on Virtualization , High Availability and storage Virtualization (14th Feb 2008)

What is Virtualization?

Virtualization essentially lets one computer do the job of multiple computers, by sharing the resources of a single computer across multiple environments. Virtual servers and virtual desktops lets you host multiple operating systems and multiple applications locally and in remote locations, freeing you from physical and geographical limitations. In addition to energy savings and lower capital expenses due to more efficient use of your hardware resources, you get high availability of resources, better desktop management, increased security, and improved disaster recovery processes when you build a virtual infrastructure.

Today’s powerful x86 computer hardware was originally designed to run only a single operating system and a single application, but virtualization breaks that bond, making it possible to run multiple operating systems and multiple applications on the same computer at the same time, increasing the utilization and flexibility of hardware.

Why Virtualization

Needs for virtualization?

This aims to describe why some people want virtualization, and why some other people absolutely need virtualization.

Consolidation

The most common use for virtualization is consolidation: combining multiple workloads on one physical computer. This allows people to run a lot of virtual machines on fewer physical computers.

But computers are cheap...

Well, computers may be cheap, but if you have enough of them the cost sure adds up.

A typical (full) data center

Lets take a look at a typical data center today. The data center is full, there is literally no more space to add extra computers and the power and air conditioning are near their limits too. However, since dual core CPUs and 1GB RAM sticks are so cheap, the vast majority of the servers only get used to 10-20% of their capacity.

In short, the data center is full, but the servers are empty.

If the IT department wants to run more server workloads, will they:

Build a new data center, or
use the capacity inside the existing servers?

As long as there is free space available inside a data center, adding a few computers is the easy way to go. However, once the data center is full, IT management will have a hard time convincing the higher-ups that an entire new data center should be built.

To make matters worse, there might not even be enough electricity available nearby. It's not like you can just plug a 5MW data center into the power grid, and you do not want to have to train an entire new staff in another state!

Virtualization can offer a relatively easy way out. When the datacenter fills up, you can start actually filling up the servers.

Hardware isolation

Hardware is getting faster every month. However, moving a workload to a new server requires installing an OS on the new server and then configuring it to run the application. After that, you copy over the application data and hope everything still works.

Virtual machines do not have this issue, since they do not interact with real hardware. You install the host OS onto your new server, then copy over the virtual machine in its entirety. No need to reconfigure the OS that runs your applications, since that is inside a virtual machine.

Legacy operating systems

The problem gets a lot worse when dealing with an older operating system. Yes, the one that runs that critical database. With a bit of bad luck, that older OS will not boot on quad core CPUs. Doh! Look around in any data center, and you'll find a critical application that's tied down to old hardware because it's running on a legacy operating system.

Wouldn't it be nice if you could magically run that old operating system on new hardware?

With full virtualization (vmware binary rewriting, or Xen or KVM with Intel VT or AMD-V capable CPUs) you can. It works because the virtualization layer emulates simple hardware, so your octo-core CPU will look like an older 8-CPU system, only with faster CPUs. Multi-core, ACPI device discovery and interrupt routing, support for 10GigE or SATA are no longer a problem.

Yes, virtualization can have significant overhead. However, because the virtualization software emulates simple hardware, it may help you run legacy OSes on way faster hardware than anything that OS could boot on natively. It may help with the power bill, too...

Testing

Whether you are a student doing software development, or the CIO of a major bank, you will have a shortage of test hardware.

Virtualization allows you to create low priority virtual machines for testing. Test out that new Fedora Rawhide or Debian Unstable on a virtual machine, before it breaks your desktop. Give your developers a bunch of virtual test machines each, instead of having them wait for each other to finish using the test systems.

Maintenance

With virtual machine migration - like vmware vmotion, or xen live migration - you can move a virtual machine from one system to another while it is running. Believe it or not, this is useful for more things than impressing your friends...

There are a number of situations in which you will want to migrate virtual machines to other physical machines:

Hardware failure. Say that a CPU fan breaks down, the CPU throttles itself and runs at a glacial speed. You move the virtual machines onto healthy systems and fix the hardware, without application downtime.
Load balancing. The virtual web server of one of your customers just got slashdotted. Move some of the other virtual machines away, so there is enough capacity to handle the load.
Flexible maintenance window. You would like to upgrade those CPUs during the daytime, but you cannot shut down the applications used by everybody else in the office. With live migration you can move the virtual machines off each physical system before you perform your surgery.

Power Savings

Consider a stack of machines providing some kind off web service. They're not busy all day. At peak hours, say 9am to 5pm, they might be working at capacity, but at off hours (eg 10pm to 6am), they may be working at only 10% of their capacity. IT staff could dramatically reduce power bills by migrating virtual machines around the server room so that at off-peak hours, 90% of all machines can be shut down. A 5MW machine room running at 0.5MW for even just one third of the day is a significant savings.

Security and performance isolation

Running different applications in their own virtual machines means that if one of your applications starts misbehaving, for example eating up all memory, the other applications on the same system will not get swapped out. This one misbehaving application will run slowly (but it would anyway), but the other applications will continue running like nothing happened.

A similar thing is true when one application gets compromised. Just that virtual machine (or part of it) will be under control of the attacker. As long as the virtual machines are well isolated from each other, which is typically the case in all virtualization technologies where each virtual machine runs its own kernel, the other virtual machines will be safe.

Container technologies, like Linux VServer, Virtuozzo/OpenVZ and Solaris Zones, typically have a lower degree of isolation, in exchange for lower overhead and more flexible resource use.= Technology Overview = An overview of the different technologies in Linux virtualization.

Paravirtualization

The original x86 architecture is not virtualizable, because some instructions behave differently depending on whether or not the CPU is running in privileged mode. Because a guest virtual machine does not run in privileged mode (for obvious security reasons), pure software full virtualization software like vmware or qemu deals with these instructions by replacing them with other instructions on the fly.

This instruction rewriting can be quite expensive. If the guest operating system kernel would simply never call the unvirtualizable instructions, that overhead could be avoided. While we're changing the guest operating system anyway, why not stop pretending we are emulating real hardware, and give it lower overhead virtual devices instead?

In a nutshell, this is paravirtualization. In order to run more efficiently, the guest operating system's kernel is changed out for a kernel that behaves well in a virtualized environment.

Xen, lguest and User Mode Linux do paravirtualization on x86. IBM POWER also does something along the same lines, with the hypervisor taking care of pagetable updates.

Hardware assisted virtualization

Intel VT and AMD-V capable CPUs can run all instructions in an unprivileged virtual machine, and have them behave well. However, when running an unmodified operating system, many operations simply trap to the hypervisor and still need to be emulated. However, it allows for a much cleaner implementation of full virtualization.

Xen and KVM do hardware assisted full virtualization.

Coopvirt

Coopvirt (cooperative virtualization) is an interesting hybrid between paravirtualization and hardware assisted full virtualization. The idea is to use the hardware capabilities of Intel VT and AMD-V to do some of the virtualization that is done in software by paravirtualization, while still having a well-behaved guest that can run very efficiently in a virtualized environment.

As of late 2006, coopvirt on x86 is still in a research and prototyping phase. However IBM mainframes have been using something along the lines of coopvirt for decades.

Containers

Containers, also known as operating-system level virtualization, do not run virtual machines at all, but simply segregate multiple user space environments from each other, while everything runs under one kernel. Container systems tend to have low overhead and high density, but also lower isolation between the different containers. Container systems do not allow you to run multiple different kernels, but different Linux distributions in the different containers are fine. While possibly limiting for testing or development, containers can simplify production usage since the shared kernel reduces the amount of software and security maintenance.

Solaris Zones, Linux-VServer and OpenVZ/Virtuozzo are examples of containering systems. OpenVZ has relatively complete resource isolation between the different containers, the other two have a bit less control. FreeBSD Jails can be seen as a precursor to containers.

Binary rewriting / JIT

Qemu and VMware both emulate a full computer without relying on trap & emulate. They achieve this by scanning the instructions that the guest is about to run, making sure there are no privileged instructions on the page and replacing those instructions with alternatives if necessary. Because there may be a debugger running inside the guest, unchanged code pages need to be marked read-only and changed code pages need to be duplicated. Qemu has the ability to emulate different architecures, eg. running an x86 virtual PC on powerpc hardware, while VMware is x86 only. VMware has some paravirtualized device drivers available for eg. video, to reduce the performance impact of full virtualization. = Technology Comparison = This table compares the features and performance of the various virtualization technologies available for Linux. Hopefully this table also explains why many Linux distributions today ship Xen, even though UML,lguest and KVM are upstream.

	FULL VIRT	PARAVIRT	CONTAINERS (OS VIRT)	LICENSE	ARCHITECTURES	PERFORMANCE	SMP GUESTS	CPU / MEMORY HOTPLUG	STANDALONE HOST	NOTES
Xen	File:Checkmark.png	File:Checkmark.png		GPL	i686, x86-64, IA64, PPC	paravirt very fast, full virt medium	File:Checkmark.png	File:Checkmark.png	File:Checkmark.png	full virt needs VT / AMD-V
KVM	File:Checkmark.png	File:Checkmark.png		GPL	i686, x86-64, IA64, PPC	paravirt very fast, full virt medium	File:Checkmark.png	File:Checkmark.png		full and para virt need VT / AMD-V, upstream
lguest		File:Checkmark.png		GPL	i686	slow/medium				upstream
rhype		File:Checkmark.png		GPL	i686, x86-64, PPC	fast	(?)		File:Checkmark.png	research project
MoL	File:Checkmark.png			GPL	PPC	fast				32 bit only
UML		File:Checkmark.png		GPL	i686, x86-64, PPC	slow				upstream
L4Linux		File:Checkmark.png		GPL	i686, ARM	medium			File:Checkmark.png
qemu	File:Checkmark.png			GPL	i686, x86-64, IA64, PPC, ARM, MIPS, SPARC	slow/medium, fast with kQEMU
OpenVZ			File:Checkmark.png	GPL	i686, x86-64, IA64, PPC, SPARC	native	File:Checkmark.png	File:Checkmark.png		live migration
Linux-VServer			File:Checkmark.png	GPL	i686, x86-64, IA64, PPC	native	File:Checkmark.png	File:Checkmark.png		poor performance isolation
VMware	File:Checkmark.png			proprietary	i686, x86-64	medium	File:Checkmark.png
LPAR	File:Checkmark.png			proprietary	s390	native	File:Checkmark.png		File:Checkmark.png
z/VM	File:Checkmark.png	File:Checkmark.png		proprietary	s390	very fast	File:Checkmark.png		File:Checkmark.png	typically runs under LPAR
PHYP		File:Checkmark.png		proprietary	PPC	fast	File:Checkmark.png	File:Checkmark.png	File:Checkmark.png	used on all modern IBM System p
lv1		File:Checkmark.png		proprietary	PPC	fast	File:Checkmark.png		File:Checkmark.png	used on Sony PS3
BEAT		File:Checkmark.png		proprietary	PPC	fast	(?)		File:Checkmark.png	used on Toshiba CellEB

Notes:

Paravirtualization is fundamentally faster than full virtualization, with the exception of the userspace implementation in UML.
Containers (OS-level virtualization) is yet faster than paravirtualization, achieving the native speed.
Performance can vary wildly depending on workload. This page assumes system call intensive applications, since "fair weather" performance numbers are not very useful.
Memory and CPU hotplug is mostly useful because it allows one to run more virtual machines on a system simultaneously, adjusting the amount of memory allocated to each guest depending on load.
Full virtualization performance in KVM and Xen is largely limited by the overhead of trap & emulate. Emulating multiple instructions at once at the time of a trap should bring it up to speed with VMware.
OpenVZ (Virtuozzo) and Linux-VServer are not virtualization technologies per se. They carve up a single system in "super chroot" jails. All the containers run on top of the same kernel.
OpenVZ (Virtuozzo) can change memory and CPU quota during runtime, there is no real hotplug since there are no guest kernels.
Qemu can emulate different guest architectures, eg. running an x86 virtual machine on a PPC guest. Qemu also has the distinction of being the only full virtualization technology that can run without root privileges.
Parts of Qemu are used in the full virtualization implementations of Xen and KVM.
The standalone host column indicates whether or not the hypervisor (or host OS, in the case of VM) is booted before Linux.

Workshop overview

Open VZ
Para-virtualization on XEN
Full-Virtualization on XEN
High availability on VM ( virtual machine)
Xen live migration
Automated failover and recovery of virtualized guests

Open VZ

What is OpenVZ?

OpenVZ is an open source container-based virtualization solution built on Linux. It is Operating system-level virtualization which enables multiple isolated execution environments within a single operating system kernel. It has the

best possible (i. e. close to native) performance and density, and features

dynamic resource management. On the other hand, this technology does not

allow to run different kernels from different OSs at the same time.

Virtual Server which are created by OpenVZ are isolated, secure containers (otherwise known as VEs or VPSs) on a single physical server enabling better server utilization and ensuring that applications do not conflict. Each container performs and executes exactly like a stand-alone server; containers can be rebooted independently and have root access, users, IP addresses, memory, processes, files, applications, system libraries and configuration files.

Top 5 Reasons to Adopt OpenVZ Software

Server Consolidation and Infrastructure Optimization: Virtualization makes it possible to achieve significantly higher resource utilization by pooling common infrastructure resources and breaking the legacy “one application to one server” model.
Physical Infrastructure Cost Reduction: With virtualization, you can reduce the number of servers and related IT hardware in the data center. This leads to reductions in real estate, power and cooling requirements, resulting in significantly lower IT costs.
Improved Operational Flexibility & Responsiveness: Virtualization offers a new way of managing IT infrastructure and can help IT administrators spend less time on repetitive tasks such as provisioning, configuration, monitoring and maintenance.
Increased Application Availability & Improved Business Continuity: Eliminate planned downtime and recover quickly from unplanned outages with the ability to securely backup and migrate entire virtual environments with no interruption in service.
Improved Desktop Manageability & Security: Deploy, manage and monitor secure desktop environments that end users can access locally or remotely, with or without a network connection, on almost any standard desktop, laptop or tablet PC.

Workshop Scenario:

Demonstration of OpenVZ based Virtulization on Fedoar Core 7 (base OS )with Guest OS Centos 4, Centos 5 and Fedora Core 6. Here we first install a openvz kernel and configure the OS to suit new kernel. Further we will follow the installation of utilities and populate the our server with guest OS and management of them.

Installation Procedure

Packages Required:

i. Openvirtulization Kernel

ovzkernel-2.6.18-53.1.4.el5.028stab053.4.i686.rpm

ii. OpenVZ Utilities.

vzctl-3.0.22-1.i386.rpm

vzctl-lib-3.0.22-1.i386.rpm

vzquota-3.0.11-1.i386.rpm

iii. Template Utilities

fedora-package-config-smart-7-8.1.i386.rpm

smart-0.50-47.fc7.i386.rpm

vzpkg-2.7.0-18.noarch.rpm

vzrpm43-python-4.3.3-7_nonptl.6.i386.rpm

vzrpm44-4.4.1-22.5.i386.rpm

vzrpm44-python-4.4.1-22.5.i386.rpm

vzyum-2.4.0-11.noarch.rpm

Required above packages can be downloaded form the site of OpenVZ, as mentioned below:

http://openvz.org/download

Installation of OpenVZ Kernel

Kernel is the heart of OpenVZ. This is modified Linux kernel with virtualization layer added.

cd /downloads

rpm -Uvh ovzkernel-2.6.18-53.1.4.el5.028stab053.4.i686.rpm

Configuring Boot Loader

Making our openvz kernel as default at the time of booting. Here in our case 2.6.18-53.1.4.el5.028stab053.4 is openVZ kernel and 2.6.21-1.3194.fc7 is base linux kernel. By setting /etc/grub.conf we are choosing VZ kernel to boot at next reboot.

Configuring “sysctl.conf” file
There is a number of kernel parameters that should be set for OpenVZ to work correctly. These parameters are stored in /etc/sysctl.conf file. Thus we have to edit the parameter of file.

Append the following /etc/sysctl.conf

net.ipv4.ip_forward = 0

net.ipv4.conf.default.proxy_arp = 0

net.ipv4.conf.default.send_redirects = 1

net.ipv4.conf.all.send_redirects = 0

Conntracks Setting

In the stable OpenVZ kernels (those that are 2.6.8-based) netfilter connection tracking for VE0 is disabled by default. If you have a stateful firewall enabled on the host node (it is there by default) you should either disable it, or enable connection tracking for VE0.To enable conntracks for VE0, add the following line to /etc/modprobe.conf file:

options ip_conntrack ip_conntrack_enable_ve0=1

Rebooting the system with OpenVZ Kernel

Now rebooting the our server with openzvz kernel. We execute below command to reboot the systyem.

reboot

Installing OpenVZ Utilities & Template Utilities

Set of user-level tools needed to run OpenVZ. Consists of vzctl - an utility to control VPSs and vzquota - VPS disk quota configuration too

Here we will be installing openvz utilities.

vzctl - A utility to control OpenVZ VPSs (create, destroy, start, stop, set parameters etc.)

vzquota - A utility to manage quotas for VPSs. Mostly used indirectly (by vzctl).

cd /downloads/

rpm -Uvh vzquota-3.0.11-1.i386.rpm

rpm -Uvh vzctl-lib-3.0.22-1.i386.rpm

rpm -Uvh zctl-3.0.22-1.i386.rpm

rpm -Uvh –nodeps smart-0.50-47.fc7.i386.rpm

rpm -Uvh fedora-package-config-smart-7-8.1.i386.rpm

rpm -Uvh vzrpm44-4.4.1-22.5.i386.rpm

rpm -Uvh vzrpm44-python-4.4.1-22.5.i386.rpm

rpm -Uvh vzrpm43-python-4.3.3-7_nonptl.6.i386.rpm

rpm -Uvh vzyum-2.4.0-11.noarch.rpm

rpm -Uvh vzpkg-2.7.0-18.noarch.rpm

Getting the OS template metadata and redeposit them into /vz/template/cache/.

Templates: are OS images for installation into OpenVZ VPS. An OS template is basically a set of packages from some Linux distribution used to populate a VPS. With OpenVZ, different distributions can co-exist on the same hardware box, so multiple OS templates are available. Here you can find various OS templates, as well as template utilities.

cd /downloads/ostemplate

ls -1

centos-4-i386-default.tar.gz

centos-5-i386-default.tar.gz

fedora-core-6-i686-default.tar.gz

cp * /vz/template/cache/.

Starting the service of OpenVZ & Creating Virtual Environment (VE)

For starting the service of OpenVZ, we have to execute the following command.

serivce vz start

Here we will be creating three virtual server from the template that we have. They are as Centos-4, Centos-5 & Fedora-6

Syntax:

vzctl create <OS_ID> --ostemplate <template-name>

vzctl create 104 –ostemplate centos-4-i386-default

vzctl create 105 –ostemplate centos-4-i386-default

vzctl create 106 –ostemplate fedora-core-6-i686-default

Assining IP to Virtual Environment (VE)
Syntax:
vzctl set <OS_ID> --ipadd <IP> --save

vzctl set 104 –ipadd 192.168.1.101 –save

vzctl set 105 –ipadd 192.168.1.102 –save

vzctl set 106 –ipadd 192.168.1.103 –save

Starting Each VE Server.

Syntax:

vzctl start <OS_ID>

vzctl start 104

vzctl start 105

vzctl start 106

We have completed the installation .

Para-virtualization with XEN

WorkShop Scenario

Demonstration of ParaVirtualization with Xen Environment using RHEL 5 as Base OS and the Guests OS is RHEL5,CentOS5,Fedora 6

Prerequisites:-

For the Base installation of RHEL 5 the Virtualization and storage packages will be select on installation time and kernel must be boot by Xen kernel.

Here is the steps for Virtulization with XEN on RedHat Enterprise Linux 5:

Step -1

Click on the Application -> System Tools -> Virtual Machine Manager

When you click on the Virtual Machine Manager you will find the following screen. In this you have a Domain name is Domain-0. That is your default DOM when you boot your system with Xen Kernel.(You can check you running kernel by “uname -r”).

[[Image:]]

Step -2

Now for creating a virtual machine click on the new on the virt-Manager tab. After Clicking on the new you should get below screen.

[[Image:]]

Step -3

Click on the forward button then you should have below screen. In this screen you fillup the name of your virtual machine that is you are going to be create.(In shown example it is Tetra1). After give up the of you virtual machine click on the forward button.

[[Image:]]

Step -4

Now after click on the forward button you have following screen. Which asking for the method of virtualization. (Full Virtualization or Para Virtualization).In below screen it is ParaVirtualization.

So for ParaVirtualization click on the ParaVirtualization. Then Click on the Forward Button.

Note: In below screen the only ParaVirtualization tab is showing and FullVirtualization is disable by default because fullyVirtualization is only possible on machine that having VT enable architecture which is Intel-AT and AMD-V .

[[Image:]]

Step -5

Now after Selecting the ParaVirtualization now you will have a screen that is asking for the installation method of the Virtual OS. It is by http location or can be by Kickstart file.In shown example it is by http installation.

For http installation you need to have a http server ready with RHEL5 cd`s Dump .

After that click on the forward button.

[[Image:]]

Step-6

Now after locating you installation path. You will find below screen. In which you have to define your Storage path for your Virtual OS. It can be a separate partition of can be a file on any where.(By default location is /var/lib/xen/images).After giving the location you have to decide the size of your virtual OS.

In below example Virtual OS Location is /var/lib/xen/images/Tetra1.img and the size is near about 10GB.

After selection of the storage area click on the forward button.

[[Image:]]

Step-7

Now after storage area this time you have a network connection screen for Virtual OS. There is two network one is Virtual Network and another is Shared physical device. So in below example it is shared physical device. After selecting the network device click on the forward button.

[[Image:]]

Step-8

Now it time to allocate memory and cpu to Virtual OS. Here in below example there is two options one is Startup Memory and another is Max memory. And another options is Number of CPU`s.

After allocated the memory click on the forward button.

[[Image:]]

Step -9

Now you have the summery of all the details that you have filled up previously. You can check or review here if you want any changes. After reviewing it click on the Finish button.

[[Image:]]

Step -10

After click on the finish button you should have a screen like this. And now the steps of virtulization installation is ok. Now the Virtual OS installation is same as the Normal OS installation .

[[Image:]]

Step-11

Select the Language and click on OK.

[[Image:]]

Step -12

Select the keyboard type and then Pres Ok.

[[Image:]]

Step -13

This below screen select the type of your network connection (IPV4 or IPV6)

[[Image:]]

Step -14

Now the network connection screen come up for your virtual machine. Give the IP, Gateway and Nameserver address to your machine and then click on the ok.

[[Image:]]

After giving the IP Normal installation will start.

When the Installation is completed just login through your new virtual machine. And now go through again Vitrual Machine Manager and you will find there a new domain by name Tetra1 below the Domain0. You can startup or shutdown the Virtual OS by right click on the Virtual OS and select the Run(If VM is already stopped) or Shutdown(If VM is already running)

Full-Virtualization with XEN

In case full virtualization , the virtualization software emulates a full virtual machine including all hardware resources. The operating system running in the virtual machine(guest OS) communicates with these resources as if they were physical hardware. VMware Workstation is also a popular full virtualization software.

We have Already discussed about the Paravirtualization in previous demonstration. In Full Virtualization It just seems like the other normal operating system with same performance but , If we use the virtual driver pack ( provided by SUSE / Novell )with the fully virtual operating system , performance is enhanced .

Workshop Scenario

Demostration of Full- virtualization on Xen using SLES 10 ( Suse Linux Enterprise Server ) SP1 as Base OS and Windows 2003 and SLES 10 Desktop as guest OS .

Installation procedure

Ist step is to install SLES 10 SP1 with on XEN kernel and virtualization packages. This will be the Base OS . On an Xen activated base machine run yast2 and select “create virtual machine “.

[[Image:]]

To run fully virtualized guests, host CPU support is needed. This is typically referred to as Intel VT, or AMD-V. Xen uses a generic 'HVM' layer to support both CPU vendors. To check for Intel VT support look for the 'vmx' flag, or for AMD-V support check for 'svm' flag:

At this stage , check for VT (Virtualization Technology ) support on the hardware by .

# grep vmx /proc/cpuinfo (For Intel Processor)

It should generate the output like this:

Flags: fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm

# grep svm /proc/cpuinfo (For AMD Processor)

Flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy

This confirms the VT support and we can proceed with yast2 now .

[[Image:]]

Next screen

Select the Operating system which you want to Install. We have selected windows 2003. please get your [[Image:]]windows 2003 CD pack ready .

Define the configuration here for guest O.S.

[[Image:]]

Select the the target path where the image goes after installation. It can be anything.

[[Image:]]

Select the installation source It can be nfs, http , ftp or cdrom.

After All this you can proceed for the installation.

[[Image:]]

This will install windows 2003 on the created virtual machine.

The windows VM will be shown running at virt-manager as shown .

[[Image:]]

Similarly other Os such as RHEL , SLED , CentOS , Fedora , windows XP etc. can be installed .

High Availability on VM

Workshop Scenario:

Demonstration of service failover between two virtual machine running RHEL5. We will demonstrate failure of machine and httpd service.

Here we will be using system-config-cluster, which is a gui tool to configure a cluster between two nodes. As we type system-config-cluster in the gui terminal, a window for cluster configuration will pop. If we are configuring the cluster for first time, window shown as in below figure will pop up, which will ask whether we want to configure new cluster or want to continue with old if we had before.

[[Image:]]

Clicking Create New Configuration causes the New Configuration dialog box to be dis-played

The New Configuration dia-log box provides a text box for cluster name and the following checkboxes: Custom Configure Multicast and Use a Quorum disk. In most circumstances you only need to configure the cluster name.

[[Image:]]

When you have completed entering the cluster name and other parameters in the New Configuration dialog box, click OK.

Clicking OK starts the Cluster Configuration Tool, displaying a graphical representation of the configuration

[[Image:]]

Adding the Cluster Node

To add a member to a new cluster, follow these steps:

Click Cluster Node.
At the bottom of the right frame (labeled Properties), click the Add a Cluster Node button. Clicking that button causes a Node Properties dialog box to be displayed. The Node Properties dialog box presents text boxes for Cluster Node Name and Quorum Votes
Enter the Cluster Node Name as mail.sunny64.com and let Quorum votes be a default value.
Simillary we be adding second Cluster Node Name as mail.sunny53.com.

[[Image:]]

Adding a Failover Domain

A failover domain is a named subset of cluster nodes that are eligible to run a cluster service in the event of a node failure.

To add a failover domain, follow these steps:

At the left frame of the the Cluster Configuration Tool, click Failover Domains.
At the bottom of the right frame (labeled Properties), click the Create a Failover Domain button. Clicking the Create a Failover Domain button causes the Add Failover Domain dialog box to be displayed.
At the Add Failover Domain dialog box, specify a failover domain name at the Name for new Failover Domain text box (here in our case httpd) and click OK. Clicking OK causes the Failover Domain configuration dialog box to be displayed

[[Image:]]

Click the Available Cluster Nodes drop-down box and select the members for this failover domain.
To restrict failover to members in this failover domain, click (check) the Restrict Failover.
To This Domains Members checkbox.
To prioritize the order in which the members in the failover domain, we click on checkboxes Priortized and use up and down arrow keys to set the priority.

[[Image:]]

Adding Cluster Resources

On the Resources property of the Cluster Configuration Tool, click the Create a Resource button. Clicking the Create a Resource button causes the Resource Configuration dialog box to be displayed.
At the Resource Configuration dialog box, under Select a Resource Type, click the drop-down box. At the drop-down box, select a resource to configure.
We will be adding to Resources, one a script that starts apache service and sencond ip which will be our service ip / floating ip.
Name can be give any ( as in our case webserver) and the file path should be init script of httpd i.e /etc/init.d/httpd

[[Image:]]

For addition of second resource, i.e adding our service ip, we have to choose IP Address from drop down menu and need to add IP in the boxes as show below.

[[Image:]]

Adding a Cluster Service to the Cluster

To add a cluster service to the cluster, follow these steps:

At the left frame, click Services.
At the bottom of the right frame (labeled Properties), click the Create a Service button. Clicking Create a Service causes the Add a Service dialog box to be displayed.
At the Add a Service dialog box, type the name of the service in the Name text box (as in our case apache) and click OK. Clicking OK causes the Service Management dialog box to be displayed.

[[Image:]]

If you want to restrict the members on which this cluster service is able to run, choose a failover domain from the Failover Domain drop-down box. ( here we choose httpd, that we had created before.
Autostart This Service checkbox — This is checked by default.

[[Image:]]

After the above steps, we will save the cluster configuration. Then in other terminal, we will be starting the service of cman and rgmanager and replicate the cluster configuration file by clicking on send to cluster.

Then our final step is to restart the both server.

Now , shutdown one of VM via virt-manager and observe the failover of IP and service on the other node .

XEN live migration

This workshop explains how to set up a demo that shows a live migration of a SuSE Linux 10.0 XEN virtual machine to other physical machine in no time .

XEN Migration with iscsi

Network configuration

The demo was set up in a private network 192.168.0.0/24. Available addresses in the range were 192.168.0.20 through 192.168.0.25, so 192.168.0.21 was used for node1 (first laptop), 192.168.0.22 for node2 (the second laptop) , and 192.168.0.23 for the virtual machine, /var/lib/xen/image/myimage. After doing the whole setup, you should be able to disconnect the laptops from the network and interconnect them with a single utp cable, which gives you a complete portable demo.

Here for this infrastructure we use two xen enabled host machine, one virtual machine, iscsi for storage.

Sequence 1: Configuring Xend (Both Xen Hosts)

The image directory is in /var/lib/xen/image/myimage on node1:192.168.0.21(xen Host).
The config file is in /etc/xen/vm/myimage.
When you launch the command

node1:# xm create -c /etc/xen/vm/myimage

After this you have two configure iscsi basically it is used here for storage such as SAN.Here Iam using iscsi target on the same machine where the guest os will create.

Configring iscsi terget on node 1

The iscsitarget configuration file is called /etc/ietd.conf. Open and edit it like below.

Node1:#vi /etc/ietd.conf

IncomingUser

OutgoingUser

Target iqn.2006-01.com.virt-1.linux.com.

IncomingUser

OutgoingUser

Lun 0 Path=/var/lib/xen/images/myimage,Type=fileio

node2:#rciscsitarget start

Starting iSCSI target service : done

Configuring the initiator on node1 and node 2

configure iscsi-client with yast on both nodes with terget address of node1 which is iscsi target.

node1:/ # xm create -c /etc/xen/vm/myimage

check It should work.

Final touch.
Make a backup of your xend-config.sxp file:

cp -pr /etc/xen/xend-config.sxp /etc/xen/xend-config.sxp.default

Edit /etc/xen/xend-config.sxp and make the following changes:

#(xend-unix-server yes)

(xend-relocation-server yes)

(xend-relocation-port 8002)

(xend-relocation-address )

(xend-relocation-hosts-allow )

#(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')

Restart Xend:

service xend restart

node1:/ # netstat -natup | grep 800

tcp0 0 127.0.0.1:8000 0.0.0.0:*

LISTEN10291/python

tcp0 0 0.0.0.0:8002 0.0.0.0:*

LISTEN10291/python

At last we have done migration of live images as:

node1:~ # xm list

Name ID Mem(MiB) VCPUs State Time(s)

Domain-0 0 490 1 r----- 168.5

myimage 3 256 1 ------ 12.6

node1:~ # xm migrate --live myimage node2

node1:~ # xm list

Name ID Mem(MiB) VCPUs State Time(s)

Domain-0 0 490 1 r----- 175.8

node1:~ # ssh -l root node2 "xm list"

Password:

Name ID Mem(MiB) VCPUs State Time(s)

Domain-0 0 489 1 r----- 288.6

myimage 1 256 1 ------ 0.4

Here, we demonstrate live migration og image from node 1 to node 2.

XEN Migration with NFS Server

Introduction: Before we begin

In this lab, we will need two Xen hosts, a Xen guest, and a shared storage. The two Xen hosts will be connected via a UTP cable. One of the Xen hosts will be exporting a shared storage via NFS. Both of the Xen hosts will be configured sothat we can perform a live migration. The Xen guest will reside on the shared storage. In the Xen guest, we will beinstalling a streaming server.

Sequence 1: Configuring Xend (Both Xen hosts)

In this sequence, we will configure Xend to start up as a HTTP server as well as a relocation server. By default, Xend does not start a HTTP server. It does start a Unix domain socket management server for xm to communicate with Xend.

But in order to support cross-machine live migration, this support has to be enabled.

Make a backup of your xend-config.sxp file:

cp -pr /etc/xen/xend-config.sxp /etc/xen/xend-config.sxp.default

Edit /etc/xen/xend-config.sxp and make the following changes:

#(xend-unix-server yes)

(xend-relocation-server yes)

(xend-relocation-port 8002)

(xend-relocation-address )

(xend-relocation-hosts-allow )

#(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')

Restart Xend:

service xend restart

Sequence 2: Exporting a shared storage via NFS (Host1)

In this sequence, we will configure NFS and export a shared storage via NFS.

Edit /etc/exports and add in the following line:

/var/lib/xen/images *(rw,sync,no_root_squash)

Save /etc/exports and restart the NFS server. Make sure that the NFS server starts by default:

service nfs start

chkconfig nfs on

After starting the NFS server on host1, we can then mount it on host2:mount host1:/var/lib/xen /var/lib/xen

Proceed to start Xen guest on host1 :

xm create -c sles10 //sles10 is name of virtual m/c.//

Sequence 4: Performing live migration

Perform the live migration from host1 to host2 by running the following command:

xm migrate --live sles10 host2 //sles10 is the configuration file in /etc/xen/vm/sles//

By this we can migrate guest os from one machine to other.

Automated failover and recovery of virtualized guest

In this workshop we show how Red Hat Enterprise Linux 5.1’s Advanced Platform can be configured to automatically provide High Availability for Virtual Machine Guests. Using the Conga management interface, the reader is walked through the process of setting up a shared filesystem guest repository, enabling the failover settings, and demonstrating zero downtime failback.

In this sceniero You’ve automated system administration processes and have reduced costs on sysadmin staff. You’ve reduced hardware costs by replacing large numbers of small servers with a smaller number of blade servers. And finally, you’ve begun to replace physical servers with virtual machines.

Let’s examine what it looks like to provide the failover protection to a virtual machine environment using Red Hat Enterprise Linux 5.0 Advanced Platform. In the diagram below, we have two Enterprise Linux guests on each of three machines. On the left, we see that a server physically fails. Ordinarily, guest instances A & B would stay down until an administrator is able to take action. But since we have Advanced Platform configured to manage these instances, the physical machine failure is automatically detected, and guests A & B are automatically restarted on the two other servers.

[[Image:]]

Once the administrator is able to repair the problem with the machine on the left, we can then ask for those two guests to be moved, live, back to the now functioning system. This is an example of zero downtime failback. So not only did the virtual guests quickly and automatically get restarted, but there was no disruption to the application when re-balancing the configuration.

Detail :

Let’s look at how this magic is constructed and then see the system in action. The key, fundamental change in the machine setup is to treat the three physical machines as shared resources. In this discussion, we’ll be using the new web-based management tool, Conga, to set up the cluster, shared storage, and failover configuration. We’ll also be using iSCSI SAN devices, which are a great alternative to Fibre Channel since they use standard Ethernet adapters, switches, and connections. Here’s the big picture:

[[Image:]]

This solution makes use of GFS2, Advanced Platform’s cluster filesystem, to provide block level, high performance operation across a set of machines. The /guest_roots GFS2 filesystem is where the configuration and guest boot images are stored. This enables us to start a guest on any of the machines as well as perform live migration.

rhel1.tetra.com, rhel2.tetra.com, and rhel3.tetra.com are the physical machines hosting three virtual instances: vert1, vert2, and vert3.

Here are the five steps we’ll follow in creating and validating our example:

1.Form a cluster of the three physical machines.2.Create the shared area for maintaining the virtual guests.3.Move the virtual guests to a shared area, visible to all the nodes.4.Have the cluster control the guests.

STEP-1 Form a cluster

[[Image:]]

Using Conga’s web-based management interface to form the cluster is easy. Make sure that your machines are on the same subnet, and then log in to Conga and navigate to the “Create a new cluster” page. Enter the machine names and root password, make sure “Enable shared storage” is selected, and click Submit. ConAutomated failover and recovery of virtualized guest

In this workshop we show how Red Hat Enterprise Linux 5.1’s Advanced Platform can be configured to automatically provide High Availability for Virtual Machine Guests. Using the Conga management interface, the reader is walked through the process of setting up a shared filesystem guest repository, enabling the failover settings, and demonstrating zero downtime failback.

In this sceniero You’ve automated system administration processes and have reduced costs on sysadmin staff. You’ve reduced hardware costs by replacing large numbers of small servers with a smaller number of blade servers. And finally, you’ve begun to replace physical servers with virtual machines.

Let’s examine what it looks like to provide the failover protection to a virtual machine environment using Red Hat Enterprise Linux 5.0 Advanced Platform. In the diagram below, we have two Enterprise Linux guests on each of three machines. On the left, we see that a server physically fails. Ordinarily, guest instances A & B would stay down until an administrator is able to take action. But since we have Advanced Platform configured to manage these instances, the physical machine failure is automatically detected, and guests A & B are automatically restarted on the two other servers.

[[Image:]]

Once the administrator is able to repair the problem with the machine on the left, we can then ask for those two guests to be moved, live, back to the now functioning system. This is an example of zero downtime failback. So not only did the virtual guests quickly and automatically get restarted, but there was no disruption to the application when re-balancing the configuration.

Detail :

Let’s look at how this magic is constructed and then see the system in action. The key, fundamental change in the machine setup is to treat the three physical machines as shared resources. In this discussion, we’ll be using the new web-based management tool, Conga, to set up the cluster, shared storage, and failover configuration. We’ll also be using iSCSI SAN devices, which are a great alternative to Fibre Channel since they use standard Ethernet adapters, switches, and connections. Here’s the big picture:

[[Image:]]

This solution makes use of GFS2, Advanced Platform’s cluster filesystem, to provide block level, high performance operation across a set of machines. The /guest_roots GFS2 filesystem is where the configuration and guest boot images are stored. This enables us to start a guest on any of the machines as well as perform live migration.

rhel1.tetra.com, rhel2.tetra.com, and rhel3.tetra.com are the physical machines hosting three virtual instances: vert1, vert2, and vert3.

Here are the five steps we’ll follow in creating and validating our example:

1.Form a cluster of the three physical machines.2.Create the shared area for maintaining the virtual guests.3.Move the virtual guests to a shared area, visible to all the nodes.4.Have the cluster control the guests.

ga will deal with installing packages and establishing the cluster. And don’t worry, the root password is encrypted over the network.

The submit step will restart the machines and within a few minutes, the cluster will be established. Next we will create the shared filesystem which holds the guest configurations and boot image files.

Step 2:Create the shared area for maintaining virtual guests

Conga makes it easy to create a shared filesystem across the machine set using the Cluster Logical Volume Manager (CLVM). CLVM provides volume management across a set of machines and enables concatenation, striping, mirroring, and expansion of storage underneath a filesystem. Start from the Storage tab and then select one of the machines; in our case et-virt05. Note that when initially viewing the storage page for a server, Conga will probe for a current, accurate view of disk and volume configurations. This will take a few seconds.[[Image:]]

A volume group is the logical storage area from which we draw space for the creation of our filesystem. Use of a volume group instead of a raw partition allows us to later extend the volume and the filesystem in case we need more space.

Once we’ve created the volume group, CLVM will provide a common name across the machine set which persists between reboots. For this case we have created a 100 GB volume group and will use a portion of that for the shared area. Specifically, we’ll create a volume group using two LUNs (storage partitions) from the array: /dev/sdd2 and /dev/sdg2. We’ll use the default extent size of 4 MB and name the volume group guest_vg. And since this is shared storage, we set the clustered state to “true.”

Note: It’s always a best practice to keep your servers time synchronized to a common source, like an ntp server. This is even more important for clusters and machines migrating g[[Image:]]uests.

[[Image:]]

Now click “New Logical Volume” to build the filesystem specification. There is a one-to-one correlation of logical volumes to filesystems. In one step we’ll create a new logical volume with a filesystem on top. Initially, the plan is to create three guests. Select GFS2 as the file system choice. Considering that each guest needs 6GB for the root volume and that we will need more guests later, we’ll carve out 60GB from the volume group. The filesystem is called guest_roots and we can use the same name for the logical volume name, filesystem name, and mount point. Let Conga create the fstab entry and also set the mount to occur at boot.

GFS2 uses a journal for filesystem crash recovery. Conga already knows that there are three machines involved, so it defaults to three journals, one for each server machine. Easy journal addition is one of the new features of GFS2, so it’s easy to add more journals later when expanding the cluster.

Now click “Create”.

[[Image:]]

You can see that we’ve got our filesystem. Note that we can later remove the filesystem from this page. Next, go and create a mount point with the same name (/guest_roots) and add an /etc/fstab entry on each machine.

[[Image:]]

Step 3: Move the virtual guests to the shared area

At this point the guests can now be created and placed in the shared area. This article is not focused on the creation of virtual machine guests, but let’s review the settings needed for our configurations. Virt-manager is the easiest way to create new guests. In particular, specify that the disk image resides on the shared area, /guest_roots in our example. Also, you need to note that your system is in a networked environment, which will create the network bridge to your guest.

Once a guest has been constructed, its configuration file will be created in /etc/xen. In this case, it is /etc/xen/guest1. We need this file to also reside in the shared area. So, copy it over to /guests_root, right next to the disk image. Note that if you use virt-manager to modify the configuration, the /etc/xen configuration file needs to be re-copied to the shared area.

Step 4: Have the cluster control the guests

We are now ready to place the control of the guests under cluster management. This includes starting a guest OS, restarting it if it crashes, and failover to another node in the event of machine failure. There are a few parts to this setup; disabling Xen, starting the guest, turning on live migration, and enabling the control of guests by the cluster management.

First disable the Xen script which starts the guest at boot time for the physical machine. On each of the servers issue the commands:

[root@et-virt06 ~]# chkconfig xendomains off

[root@et-virt06 ~]# service xendomains stop

This will immediately stop the service and prevent it from starting at the next boot time. Note that this will also stop currently running guests on the machine.

Next, enable live migration of a guest from one machine to another. This capability is off by default. On each of the machines, edit /etc/xen/xend-config.sxp. Uncomment the two relocation lines and set xend-relocation-server to “yes.”

(xend-relocation-server yes)

(xend-relocation-port 8002)

Now place the management of the virtual guest under the cluster. The cluster manager deals with services– whether they are a web service, database, or, as in this case, a virtual machine service. Since we are now in a cluster, we will specify how and where the guest OS is to be started. The first task is to configure a failover domain.

The failover domain simply states which machines can run the guest as well as which we prefer to have the guest run on. We will pick one machine out of the three to bias the running of the guest. We also will allow the guest to run on any other machine. You can get fancier with this configuration, but let’s keep it simple here. Look at the following failover domain.

We construct three in total; one for each physical machine. When later adding more guests, associate them to one of these three failover domains.

We don’t need fine-grained prioritization; only one machine is preferred and all others are treated equally. So we don’t check “Prioritized” or set the Priority fields.. Again, since we allow the guest to run on any machine, we don’t check “Restrict failover to the domain’s members.” This specification simply sets a bias to one machine. So we end up with three failover domain configurations: “bias-et-virt05”, “bias-et-virt06”, and “bias-et-virt07”.

[[Image:]]

Next construct the virtual service entries. Enter the name of the guest (guest1), the shared area (/guest_roots), that we want the service to automatically start, the failover domain (bias-etvirt05), and the recovery policy (restart the service if it fails).

[[Image:]]

That’s it. Once you click “Update Virtual Machine Service,” the guest is under cluster management. If it’s not currently running, it will immediately be started. Notice that names are green, indicating that they are running and that the status lists which physical machine they are running on. They are shown running on the “bias” machine. Guest1 is on et-virt05 etc. Here’s what the service list now looks like:

[[Image:]]

Step 5: Try an example failover and recovery

Now it’s time to validate our setup and see the system respond to various failure scenarios. First, let’s simply simulate a guest crash. This is easily performed by issuing the command “xm destroy” on one of the machines. Log in to one of the physical machines and try it. Here we used xm destroy to kill the guest.

[root@et-virt06 ~]# xm list

Name......................................ID.Mem(MiB).VCPUs.State...Time(s)

Domain-0...................................0.....1505.....8.r-----...6972.4guest2.....................................5......499.....1.-b----.....21.0

[root@et-virt06 ~]# xm destroy guest2

[root@et-virt06 ~]# xm list

Name......................................ID.Mem(MiB).VCPUs.State...Time(s)

Domain-0...................................0.....1505.....8.r-----...6975.7

[root@et-virt06 ~]# xm list

Name......................................ID.Mem(MiB).VCPUs.State...Time(s)

Domain-0...................................0.....1505.....8.r-----...6988.7

guest2.....................................6......499.....1.-b----.....17.7

Note that about 10 seconds2 after destroying the guest, it restarts. The cluster manager has detected the failure and restarted the guest for you.

[[Image:]]

Let’s now simulate a physical machine failure. For this we’ll simply reboot one of the machines in the cluster. First note the report that Conga provides about the state and location of the guests. Also note that guest1 is running on et-virt05.

Now by simply logging into et-virt05 and issuing a reboot, we can watch the recovery kick in. With the absence of et-virt05, guest1 is restarted to run on et-virt07.

After we wait for et-virt05 to reboot, we can now use the same screen and choose the migrate task for guest1 to move it back to et-virt05. Remember, this failback happens while the guest is active with no further disruption in service.