kvmadv_pdf

Blueprints The developer's approach to installing and managing KVMs ��� Blueprints The developer's approach to installing and managing KVMs ��� Note Before using this information and the product it supports, read the information in “Notices” on page 17. First Edition (March 2010) © Copyright IBM Corporation 2010. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents The developer's approach to installing and managing KVMs . . . . . . . . . 1 Scope, requirements, and support . . . . . . . 1 KVM overview . . . . . . . . . . . . . 3 Host preparation . . . . . . . . . . . . . 3 Installing a KVM guest . . . . . . . . . . . 3 Creating an XML definition file for your KVM . . 4 An example XML file to install Linux booting from the installation kernel . . . . . . . 4 An example XML file to install an operating system from an ISO image. . . . . . . . 8 Using virsh to create a KVM . . . . . . . . 9 Tips for installing your guest operating system 10 Editing the KVM definition file after operating system installation . . . . . . . . . . . 11 Propagating your KVMs . . . . . . . . . . 12 Managing your KVM . . . . . . . . . . . 12 Optional: Enabling stateless offloads to improve system performance . . . . . . . . . . . 13 Appendix. Related information . . . . 15 Notices . . . . . . . . . . . . . . 17 Trademarks . . . . . . . . . . . . . . 18 © Copyright IBM Corp. 2010 iii iv Blueprints: The developer's approach to installing and managing KVMs The developer's approach to installing and managing KVMs With Kernel-based Virtual Machine (KVM), you can host different guest operating systems. This Blueprint shows you how to use an XML definition file in combination with the virsh tool to install and manage a KVM guest the developer's way. This Blueprint starts by showing you the steps to create a KVM and install an operating system on it. Then it shows you how to manage KVM using the same set of tools. Lastly, it presents you instructions on how to enable stateless offloads to improve system performance. Key tools and technologies discussed in this demonstration include Kernel-based Virtual Machine (KVM), virt-install, virsh, stateless offloads, and XML definition files. Scope, requirements, and support This blueprint applies to System x® running Linux. You can learn more about this blueprint, including the intended audience, the scope and purpose, the hardware and software requirements for the tasks detailed in this blueprint, and the types of support available to you. Systems to which this information applies System x running Linux Intended audience This Blueprint is intended for advanced Linux system administrators and programmers who want to use KVM to create a virtualized environment. Scope and purpose This Blueprint provides information about managing KVMs with XML files and the virsh tool. This is the developer's method for working with KVM. The instructions in this document assume that the KVM guests to be created are using local storage. The process of installing an operating system on a KVM guest is the same as any other installation and is outside the scope of this Blueprint. Test environment The instructions in this Blueprint were tested on a System x HS21 blade system that runs an Intel Xeon chip and is running the stock RHEL 5.4 kernel: # uname -a Linux testmachine.ibm.com 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Hardware requirements Host machines must be running either Intel VT chipsets or AMD-V chipsets that support hardware-assisted virtualization. For a list of supported chipsets, see http://en.wikipedia.org/wiki/X86_virtualization. For more information about hardware requirements, see the "Enabling KVM support on your hardware" section of the Quick Start Guide for installing and running KVM at http://publib.boulder.ibm.com/ infocenter/lnxinfo/v3r0m0/topic/liaai/kvminstall/liaaikvminstallstart.htm. © Copyright IBM Corp. 2010 1 Other considerations This Blueprint assumes that the created KVM guests use local storage, however, live migration is only possible if a guest is running on shared storage on RHEL 5.4. If you would like to preserve the possibility of live migration in the future, you must set up shared storage. Or, if you are running a later release of RHEL, check to see if live migration is possible on local storage. Author names Monza Lui Other contributors Kersten Richter Santwana Samantray Sridhar Samudrala Subrata Modak Heather Crognale IBM® Services Linux offers flexibility, options, and competitive total cost of ownership with a world class enterprise operating system. Community innovation integrates leading-edge technologies and best practices into Linux. IBM is a leader in the Linux community with over 600 developers in the IBM Linux Technology Center working on over 100 open source projects in the community. IBM supports Linux on all IBM servers, storage, and middleware, offering the broadest flexibility to match your business needs. For more information about IBM and Linux, go to ibm.com/linux (https://www.ibm.com/linux) IBM Support Questions and comments regarding this documentation can be posted on the developerWorks® Systems Management Blueprint Community Forum: http://www.ibm.com/developerworks/forums/forum.jspa?forumID=1272 The IBM developerWorks discussion forums let you ask questions, share knowledge, ideas, and opinions about technologies and programming techniques with other developerWorks users. Use the forum content at your own risk. While IBM attempts to provide a timely response to all postings, the use of this developerWorks forum does not guarantee a response to every question that is posted, nor do we validate the answers or the code that are offered. Typographic conventions The following typographic conventions are used in this Blueprint: Bold Identifies commands, subroutines, keywords, files, structures, directories, and other items whose names are predefined by the system. Also identifies graphical objects such as buttons, labels, and icons that the user selects. Italics Identifies parameters whose actual names or values are to be supplied by the user. Monospace Identifies examples of specific data values, examples of text like what you might see displayed, examples of portions of program code like what you might write as a programmer, messages from the system, or information you should actually type. 2 Blueprints: The developer's approach to installing and managing KVMs KVM overview Kernel-based Virtual Machine (KVM) is a hardware-assisted, fully virtualization solution for Linux on x86 and x86_64 hardware that contains virtualization extensions – specifically Intel VT or AMD-V. After you install KVM-related software, you can run multiple guests (virtual machines), with each one running a different operating system image. Each of these virtual machines is assigned private, virtualized hardware. For a list of KVM-supported guest operating systems, see http://www.linux-kvm.org/page/ Guest_Support_Status. For more information about the technology, see http://www.linux-kvm.org. Related concepts: “Scope, requirements, and support” on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the intended audience, the scope and purpose, the hardware and software requirements for the tasks detailed in this blueprint, and the types of support available to you. Host preparation Before completing the instructions in this Blueprint, some preparation must be done to the host system. See the Quick Start Guide for installing and running KVM at http://publib.boulder.ibm.com/infocenter/ lnxinfo/v3r0m0/topic/liaai/kvminstall/liaaikvminstallstart.htm and complete the instructions in the following sections to prepare your host for creating KVMs: v Enabling KVM support on your hardware v Installing and configuring KVM related software v (Optional) Setting up a network bridge in the host Related concepts: “Scope, requirements, and support” on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the intended audience, the scope and purpose, the hardware and software requirements for the tasks detailed in this blueprint, and the types of support available to you. Installing a KVM guest There are at least three methods of creating a guest on a KVM host machine: the virt-manager tool, the virt-install tool, and the virsh tool (in conjunction with XML files). This Blueprint will focus on demonstrating the virsh tool and XML files to manage KVMs. For additional information about the virt-manager tool and the virt-install tool, see the Quick Start Guide for installing and running KVM at http://publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/topic/liaai/ kvminstall/liaaikvminstallstart.htm. This Blueprint includes instructions for creating the XML definition file manually. Alternatively, you can use the virt-manager tool and the virt-install tool to create XML definition files for you, and then manage the KVMs with the XML files and the virsh tool. To install a KVM guest, complete the following steps, which are described in this section of the Blueprint: 1. Create an XML definition file which you will use with the virsh tool to create a KVM and boot to install. 2. Install the operating system on the guest KVM. The developer's approach to installing and managing KVMs 3 3. Change the XML file and redefine the KVM so that the next time the KVM guest boots, it will boot from the installed image instead of the installation. Related concepts: “Scope, requirements, and support” on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the intended audience, the scope and purpose, the hardware and software requirements for the tasks detailed in this blueprint, and the types of support available to you. Creating an XML definition file for your KVM Understanding an XML definition file is beneficial for managing KVMs the developer's way. In this section, the anatomy of XML definition files is discussed. Steps associated with some sections of the file are also explained. You can see how efficient this method is if you need to manage many KVMs or create many KVMs of similar configurations. This Blueprint is not meant to be a comprehensive guide to writing the XML file. Only the most likely scenarios are covered here. Consult the official libvirt site about KVM XML format at http://libvirt.org/formatdomain.html for more details. Related concepts: “Scope, requirements, and support” on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the intended audience, the scope and purpose, the hardware and software requirements for the tasks detailed in this blueprint, and the types of support available to you. An example XML file to install Linux booting from the installation kernel The following example XML file was used to create a KVM and boot up to the Linux RHEL 5.4 installation screen. You should be able to use this file as a template to install any Linux guest. The installation vmlinuz and initrd images that come in the installation media are used as the boot media. This way, you are able to install Linux from installation source that is either remote or local to the system. 1 2 kvm3 3 bdbb89fb-57d1-4d01-b3b7-ff33a9346ae6 4 2048000 5 1024000 6 4 7 8 hvm 9 /tmp/vmlinuz-rhel54 10 /tmp/initrd-rhel54.img 11 12 13 14 15 16 17 18 19 destroy 20 destroy 21 destroy 22 23 /usr/libexec/qemu-kvm 24 25 26 27 28 4 Blueprints: The developer's approach to installing and managing KVMs 29 30 31 32 33 34 35 The following information explains each line of the definition file in detail. Start of the KVM guest definition. 1 Short name of the guest. This short name must consist only of letters and numbers, but no blank spaces. 2 kvm3 Each guest needs a universal unique identifier (uuid). 3 bdbb89fb-57d1-4d01-b3b7-ff33a9346ae6 You must generate one for your guest by running the following command, and then copy and paste the identifier into the XML file: # uuidgen Maximum memory the guest can use, in kilobytes (KB). In this example, 2 GB is the maximum amount of memory the guest is allowed to use without needing to reboot the guest. 4 2048000 Memory allocation when started. This number can be changed to not larger than what is set in the memory element using the virsh setmem command. 5 1024000 Number of virtual processors allocated to the guest. 6 4 The os element specifies how your guest is booted. You can use i686 in the arch attribute to set up an x86 guest. The hvm type indicates that this guest runs an operating system that was designed for bare metal and is therefore a fully virtualized guest. 7 8 hvm 9 /tmp/vmlinuz-rhel54 10 /tmp/initrd-rhel54.img 11 12 The kernel and initrd elements are especially useful if your Linux installation source is remote. You can use these elements to boot from the installation kernel. In RHEL 5, these two files are located in the images/pxeboot directory and are named vmlinuz and initrd.img. In SLES 11, the files are located in the boot//loader directory and are named linux and initrd. Copy them to the local disk and provide their locations to the kernel and initrd elements. In this example, these files were copied from the RHEL 5.4 installation media, placed in the /tmp directory, and renamed to include “-rhel54” in their names. If SELinux is enabled in the host machine, you also need to change the type of security context for the files to virt_image_t to allow libvirtd to access them for booting: # chcon -t virt_image_t /tmp/vmlinuz-rhel54 # chcon -t virt_image_t /tmp/initrd-rhel54.img The developer's approach to installing and managing KVMs 5 After you change the security context, verify that the correct security context is assigned to them as shown in the following example: # ls -Z /tmp|grep virt -r--r--r-- root root root:object_r:virt_image_t initrd-rhel54.img -r--r--r-- root root root:object_r:virt_image_t vmlinuz -rhel54 The boot element specifies hd as the next boot device, which indicates a hard disk drive. You can have repeated lines of boot elements with different values to form a boot order list. Optionally you can also include the boot options in the cmdline element. The following example demonstrates the use of the kickstart file for installation: hvm /tmp/vmlinuz-rhel54 /tmp/initrd-rhel54.img method=http://10.1.1.212/install/rhel5.4/x86_64 ks=http://10.1.1.212/install/autoinst/c20m2n05v3 Processor features to be included. 13 14 15 16 17 Clock time. 18 This set overrides the default actions when a power off, reboot, or crash occurs in the KVM environment. The destroy action is also used for the on_reboot element in this example because once installation is completed, the wanted action is for the guest to stop so that the definition of the guest can be edited to boot from the installed guest operating system rather than from the installation kernel or ISO. Other allowed actions include: restart, preserve, and rename-restart. 19 destroy 20 destroy 21 destroy The definition of the devices element begins. 22 The emulator element should be qemu-kvm for all KVM guests. 23 /usr/libexec/qemu-kvm In this example, the disk element identifies the local /var/lib/libvirt/images/kvm3.img file as the storage of the KVM, and it shows up as an IDE device named hda inside the guest. 24 25 26 27 Because this method is a manual method of creating the KVM, you are expected to create the image file. You can create this file with 10 GB of storage by running the following command: # qemu-img create /var/lib/libvirt/images/kvm3.img 10GB Note: The /var/lib/libvirt/images/ directory is the default directory for KVM images. 6 Blueprints: The developer's approach to installing and managing KVMs More than one set of disks can be defined and exist in the KVM guest, just like any physical machine can have more than one disk. Other common possibilities of a disk element definition are: v Logical volume device: v Disk partition: v CD-ROM device: It is important that each KVM has a unique MAC address, just like its uuid. Otherwise, it might cause traffic disruptions to all machines in the same subnet. In this example, the Linux bridge you set up previously is used and a randomly generated MAC address is assigned. Random MAC addresses can be generated in many ways. For example, to see a python script suggested by RedHat, see the RHEL 5 Virtualization Guide at http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Virtualization- en-US/ch19s22.html. 28 29 30 31 The following example demonstrates the use of the default virtual network instead of the bridge: Defines the input device it simulates. 32 Defines the graphical device being used to interact with the guest. In this example, the vnc protocol is specified. A port value of -1 indicates that a port number is automatically assigned. If you are using other VNC viewers to connect to the host, you can find out the port number used by running the following command: # virsh vncdisplay :0 This example output indicated that port 0 is used. Alternatively, you can specify the port number you would like to use in this field. 33 End of the devices element definition. 34 End of the KVM's definition. The developer's approach to installing and managing KVMs 7 35 Related concepts: “Scope, requirements, and support” on page 1 This blueprint applies to System x running Linux. You can learn more about this blueprint, including the intended audience, the scope and purpose, the hardware and software requirements for the tasks detailed in this blueprint, and the types of support available to you. An example XML file to install an operating system from an ISO image The followi