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:
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.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Readers' Choice Awards 2013
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The Many Paths to a Solution
- Nativ Disc
- Synopsys' Coverity
- Naztech's Roadstar 5 Car Charger
- Securing the Programmer
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Identity: Our Last Stand