Managing KVM Deployments with Virt-Manager
KVM is the kernel-based virtual machine, a mainline kernel feature since versuib 2.6.20 for running virtualized guest systems on top of a host system. In less technical terms, this means you can run other operating systems as just another window on your desktop. But, before you can get to the desktop, you need to become familiar with creating and managing virtual machines using the Virtual Machine Manager suite of tools.
Each virtual machine instance, referred to as a VM, has its own virtualized hardware. This includes a chunk of memory and one or more of the available CPUs, network and graphics hardware, virtual disks and a mouse. The Virtual Machine Manager tools, often referred to collectively by the name of the primary GUI application virt-manager, make it possible to bring up the virtual hardware quickly with the virtual CD-ROM device “connected to” an ISO file in order to install an operating system. At work, we run a variety of Linux distributions and a couple Windows versions. Each operating system instance is installed with a base configuration that is common to all copies of that instance. This is known as a base image. From these, we make copies, known as clones, in which specific applications are installed. This result of cloning and custom application configuration is what the cloud computing world refers to as virtual appliances.
KVM is one of a number of options for running virtual machines. Xen, VirtualBox and VMware are alternatives with different requirements for setup and use. KVM was chosen for use at my office, because of the simplicity of setup on Fedora systems (the standard Linux development platform at work) and because of the ease of creating and using virtual machines across the internal network. The process discussed here is applicable specifically to using KVM-based virtual machines.
Since KVM is part of the kernel, most modern Linux distributions offer KVM kernels. However, the user-level tools that utilize KVM, such as virt-manager and libvirt, are what most users will be interested in. Check your distribution for availability of ready-to-install packages or grab the source packages from the URLs provided at the end of this article.
In virtualization parlance, the host system is the real hardware and its operating system that will be the platform on which you will run guest systems. Each guest system is the KVM-based virtual hardware and the OS installed on it. Before you can use a KVM-enabled kernel on your host system, you need to make sure your hardware supports virtualization. To check whether the processor supports virtualization, search for the following CPU flags:
egrep "vmx|svm" /proc/cpuinfo
Intel processors with VM support will have the vmx flag in the output of this command. AMD processors that support virtual machines use the svm flag. This command will print one line for each CPU core with VM support.
The next step is to configure the host operating system. The first thing to do is install the user-space tools associated with virt-manager:
sudo yum install kvm qemu libvirt \
libvirt-python python-virtinst \
bridge-utils virt-manager
This may install additional packages, but these are the ones critical to using KVM and virt-manager. These package names are specific to Fedora. Check your distribution for proper package names.
After installing the required software, a bridge network device needs to be added to the host system. Using a bridge device allows the VM to function like any other system on your network, using its own IP address. On the host system, the bridge will be assigned an IP address and the default “eth” device will be attached to that. Using a bridged network is a little easier if you disable NetworkManager:
# chkconfig NetworkManager off # chkconfig network on # service NetworkManager stop # service network start
NetworkManager is ideal for mobile platforms, but as of Fedora 12, it's not suitable for use with shared networks, such as those used with a host and guest virtualized systems. Although you can run KVM on mobile systems, this article assumes the use of a desktop or server that is unlikely to need to change network configurations often.
Note that the above commands must be run as root. On Fedora, configuration scripts for each network device are located under /etc/sysconfig/network-scripts. Assuming there is at least one network card in your system, there will be a configuration file named ifcfg-eth0 in that directory. Open it and add the following line:
BRIDGE=br0
Then, comment out the following lines by prefixing each line with the # symbol:
#BOOTPROTO=none #DNS1=... #GATEWAY=... #IPADDR=... #NETMASK=...
To add the bridge device, create a file called ifcfg-br0 in that directory, and add the following lines to it:
DEVICE=br0 TYPE=Bridge BOOTPROTO=static DNS1=... GATEWAY=... IPADDR=... NETMASK=... ONBOOT=yes
The lines with ... can, in most cases, be the lines that you commented out of ifcfg-eth0. Note that the TYPE entry is case-sensitive.
Be sure to assign proper values for DNS, GATEWAY, IPADDR and NETMASK. This example assumes a static IP address, but if the device will use DHCP, change BOOTPROTO and leave these entries out:
DEVICE=br0 TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes
Note that the host also should have a large amount of disk space for the VM image files. The size of these can vary, but in this article, we'll create 12GB files to support complete Linux distributions on 8GB with 4GB for local user directories. Smaller installation partitions could be used for the operating system, and user directories can be NFS-mounted if desired. Also, it is possible to place the VM image files on NFS-mounted directories, although this can have serious performance impacts when running the virtual machine.
At this point, the host network can be restarted with the new networking configuration:
# service network start
The host now is ready for use with virtual machines.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Weechat, Irssi's Little Brother
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Reply to comment | Linux Journal
20 min 27 sec ago - Didn't read
30 min 47 sec ago - Reply to comment | Linux Journal
35 min 47 sec ago - Poul-Henning Kamp: welcome to
2 hours 45 min ago - This has already been done
2 hours 46 min ago - Reply to comment | Linux Journal
3 hours 32 min ago - Welcome to 1998
4 hours 20 min ago - notifier shortcomings
4 hours 44 min ago - heroku?
6 hours 21 min ago - Android User
6 hours 22 min ago




Comments
Configuring the host for DHCP address assignment
I'm confused by the paragraph describing configuration of the host for DHCP network access. The lines listed are to be left "out"? Out of which file - ifcfg-br0 or ifcfg-eth0? My first guess would be that ifcfg-eth0 should contain the same contents as for a statically addressed host, and that the lines listed should appear in ifcfg-br0. Please clarify.
Thanks.