Lecture 1

Migrating to KVM Virtualization

Upon completion of this unit, you should be able to: Describe the benefits of KVM virtualization Prepare a Xen guest system for migration to KVM Prepare a KVM virtualization host system Transition from Xen to KVM virtualization Identify other tools used for migration

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / unit-0154102 1

Introducing KVM

1-1

KVM versus Xen virtualization

Simpler implementation than Xen Adopted by upstream kernel developers Virtual machines are scheduled like normal processes Requires hardware support The future of Red Hat virtualization The Xen hypervisor is a customized kernel

Implemented with kernel modules

For more information about KVM, check out the KVM project web site at the following URL: http://www.linux-kvm.org

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / page-0156958 2

Xen to KVM Migration Overview

1-2

Things to consider when migrating:

Kernel version Storage configuration Network configuration Console configuration Xen guest preparation Virtualization host preparation Transition from Xen to KVM

Steps to take to migrate from Xen to KVM:

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / page-0157033 3

Prepare the Xen Guest System

1-3

Network configuration
Xen MAC address - 00:16:36:??:??:?? KVM MAC address - 54:52:00:??:??:?? Adjust or comment HWADDR setting Xen xvc0 will change to standard ttyS0 Provide a login prompt: co entry in /etc/inittab Permit root login: /etc/securetty

Console configuration

The first three octets of the MAC address varies between KVM and Xen virtualized network devices. When the guest's network device connects to the private virtual network, its MAC address isn't a major consideration. The HWADDR line in /etc/sysconfig/network-scripts/ifcfg-eth0 should either be commented or changed to match the new MAC address. Virtual network interfaces that are connected directly to the hardware NIC may require more attention when they are configured. Upstream switches could filter packets coming from an unrecognized MAC address, so in this case the virtual machine could be configured to use the original MAC address. The virtual machine's network configuration would be unchanged in this case, but its hardware profile will need to use the original MAC address for the NIC. When using KVM, the system console is implemented as the standard COM1 port. This means that all references to xvc0 should be changed to ttyS0. In Red Hat Enterprise Linux 5.4 systems this requires changes to /etc/inittab and /etc/securetty. Sometimes there are references to the console in / boot/grub/grub.conf that need to be changed as well.

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / page-0157099 4

Prepare the Xen Guest System (cont.)

1-4

Storage configuration
All references to Xen's /dev/xvda will change to...
/dev/vda with virtio drivers /dev/hda without virtio drivers

/boot/grub/device.map /etc/fstab (not an issue if the guest uses LVM and volume labels) Configure the standard kernel as the default Modify /etc/modprobe.conf to reference virtio drivers Install the standard (non-Xen) kernel Ensure the virtio drivers are available at boot (mkinitrd)

Kernel configuration

Power off the Xen virtual guest

Two files affected by disk device name changes are /etc/fstab and /boot/grub/device.map. The /etc/fstab file only requires changes when disk device names are explicitly referenced. When all file systems are referenced by file system label or are contained in LVM logical volumes, /etc/fstab doesn't require modification since the partitions aren't referenced by the disk device name. Note: Errors in /etc/fstab will prevent a system from booting. This is why it is important to confirm the integrity of this file. The best way to begin guest system kernel configuration is to modify /etc/sysconfig/kernel so it defaults to the standard kernel: DEFAULTKERNEL=kernel This will cause updates to the system to prefer the standard kernel over the paravirtualized Xen kernel, kernel-xen. In time the Xen kernel can be removed, but it is convenient to keep it around if you have issues initially booting the system with KVM. /etc/modprobe.conf should be modified to refer to the virtio drivers: alias scsi_hostadapter virtio_blk alias eth0 virtio_net After you use yum to install the standard kernel, you will need to use mkinitrd to build a new ramdisk image with the appropriate drivers. Run the following command in the guest: # mkinitrd -v -f --with=virtio_pci --builtin=xenblk path-to-initrd kernel-version The --builtin option is required when running under Xen to prevent mkinitrd from trying to build that driver into the ramdisk image.

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / page-0157240 5

Prepare the Virtualization Host

1-5

Kernel configuration
Make the standard kernel the default Reboot using the standard kernel

Resolve any SELinux issues for storage/disk images Network configuration

Private virtual network, or Direct interface access requires a bridge

The standard kernel must be installed and defined as the default kernel for the virtualization host also. Modify /etc/sysconfig/kernel in the same manner as the guest system then use yum to install the kernel package. There are some SELinux issues with KVM using logical volumes as disk storage. To keep things simple for now, set SELinux on the virtualization host to permissive mode with the following command: # setenforce 0 Also modify SELinux to boot in permissive mode persistently on the virtualization host until the policy is fixed to work with KVM. When the virtual guest needs to communicate directly to the local area network, a network bridge must be configured when using KVM. The following files demonstrate how to create a bridge on the first network interface on the virtualization host. After the files are created, restart the network. The contents of /etc/ sysconfig/network-scripts/ifcfg-br0 should include: DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes

# When using DHCP for network info

The contents of /etc/sysconfig/network-scripts/ifcfg-eth0 should include: DEVICE=eth0 HWADDR=MAC-Address-of-Hardware-NIC BRIDGE=br0 ONBOOT=yes Check out the following URL for more information on network bridge configuration on Red Hat Enterprise Linux 5: http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging.

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / page-0157435 6

Transition from Xen to KVM

1-6

Create a new KVM virtual guest with virt-manager

Select guest system name Specify CPU architecture (i686 or x86_64) Provide OS type and version Point to source device or image file for storage Configure network - reuse MAC address? Specify guest memory and CPU

Abort the installation

The system already has a Xen guest system profile, we need to create a profile for the guest as a KVM host. Run virt-manager on the virtualization host when it is running the standard kernel and connect to the QEMU processor emulator. Create a new virtual machine, but abort the installation once all the host characteristics have been specified and the Red Hat installer, anaconda, begins to run. It is during this stage that the original MAC address can be specified if necessary. The KVM guest is almost ready to be started, but some additional modification of the system profile needs to be performed because of the defaults virt-manager uses.

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / page-0157565 7

Transition from Xen to KVM (cont.)

1-7

Modify libvirt XML configuration

Storage references
dev=vda instead of hda bus=virtio instead of ide

Start the guest virtual machine

The virt-manager tool creates the guest system profile so the storage is presented to the guest as an IDE disk drive. The configuration must be adjusted to use the virtio block devices. Use the following command to edit the libvirt configuration: # virsh edit domain-ID

Locate the XML stanza that defines the primary disk drive. It should look something like the following: <disk type='block' device='disk'> <source dev='/dev/vol0/lv.vserver'/> <target dev='hda' bus='ide'/> </disk> Instead the target line should read: <target dev='vda' bus='virtio'/> Once the changes have been saved, start the virtual guest.

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / page-0157647 8

Other Configuration Options

1-8

libvirt alternatives to virt-manager:

Use virsh Modify the XML configuration with scripts qemu-img for disk image conversion and manipulation kpartx to map embedded partitions with file systems Upcoming command-line tool: virt-v2v

Manipulate virtual guest storage with...

This workshop examines how to convert from Xen to KVM using virt-manager with a very manual process. Currently there are other tools, such as virsh, qemu-img, and kpartx that allow virtual machines to be manipulated with scripts. An upcoming tool to watch out for is virt-v2v. It is a general-purpose tool specifically designed to automate and simplify the migration from one virtualization technology to another.

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / page-0157751 9

End of Lecture 1

Questions and Answers Summary

System management tasks KVM Introduction Xen Guest System Preparation Virtualization Host System Preparation Transition from Xen to KVM Migration Tools

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / unit-0154102 10

Lab 1.1: Migrating from Xen to KVM Virtualization

Scenario: Each attendee has a Red Hat Enterprise Linux 5.4 workstation serving as a Xen virtualization host. A Xen paravirtualized guest with a domain ID of vserver serves as a webserver on each of the workstations. A workstation that uses KVM virtualization and a properly functioning KVM guest

Deliverable:

Instructions: 1. You have a Red Hat Enterprise Linux 5.4 x86_64 workstation that is running Xen virtualization. There is a paravirtualized guest host running Red Hat Enterprise Linux 5.4 i686 called vserver. Spend a couple minutes exploring your virtual guest to see what services it offers and what its network configuration is. Source disk device: Target disk device: Virtual console device: IP address: MAC address: Network mask: Active network services: 2. Convert your paravirtualized guest and virtualization host to use KVM virtualization technology instead of Xen. The guest machine should provide its original network services and the data it serves should be left intact. Network clients should not see any difference in network services provided by the guest. Document each step you took to perform the conversion.

Copyright 2010 Red Hat, Inc. All rights reserved

Xen-2-KVM-RHEL5u4-en-Summit2010-20100621 / exercise-0157885 11