apops - Fotolia

Get started Bring yourself up to speed with our introductory content.

4 FAQs to help master KVM management

When it comes to managing KVM, admins should do their homework and research common questions to better understand the technology and ensure peak performance.

KVM is a popular and well-known hypervisor for Linux distributions that is not only free to use, but also offers admins remote access to software and VMs, network flexibility and scalability. IT administrators who research which environments are compatible with KVM, explore common KVM best practices, know how to expand KVM storage and understand common KVM issues can better master their KVM management.

Despite the fact that the KVM hypervisor is generally well understood, some admins might come across instances where KVM performance is lacking. This lackluster performance could be the result of incompatible workloads, inadequate disk space or even an inactive VM. Here are four FAQs to help admins master their KVM management and ensure peak performance.

Which environments work well with KVM?

The nature of admins' workloads greatly influences whether KVM is compatible with their systems. For example, production environments, demanding enterprises, mixed workload systems and private clouds can benefit from a KVM module in different ways. Many admins rely on the Red Hat Enterprise Linux or SUSE Linux Enterprise Server distribution of KVM.

These distributions of the KVM module often rely on Intel VT-x and AMD-V x86 to allocate memory to VMs. Admins who primarily use Linux can take advantage of memory ballooning to better allocate memory resources to several VMs within a system. In addition, the KVM module can provide offline or live migrations, enabling KVM guests' VMs to move and run on a different host system, such as migrating between AMD and Intel systems.

Overall, KVM is compatible and supports a variety of guest OSes, such as Windows, Red Hat variations, Ubuntu and Debian variations, BSD variations, Solaris and OpenSolaris variations, and additional Linux OSes, including Android, Gentoo Linux and Mandriva Linux.

Though KVM is easy for admins to manage at low densities, those who plan to manage KVM at scale must be deliberate with the installation and configuration process.

What are some common KVM management best practices?

Though KVM is easy for admins to manage at low densities, those who plan to manage KVM at scale must be deliberate with the installation and configuration process. Otherwise, admins risk unchecked growth that has the ability to damage the quality of their KVM deployment.

For example, the graphical user or command-line interfaces are acceptable tools to manage a small number of KVMs. However, a large-scale deployment of KVM means admins must manage hundreds or even thousands of machines. In this case, admins must plan accordingly and take advantage of best practices, including:

  • Managing KVM installations. When managing KVM installations, admins must install VirtIO drivers to build KVM images. Most Linux distributions support KVM and have VirtIO drivers built into the kernel. However, admins running Windows must install the VirtIO driver beforehand.
  • Choosing the best management platform. After a KVM installation, admins must consider how they will monitor and cultivate KVM for the long term. Vendors such as Red Hat offer extensive GUI management services. Admins must take care when choosing and deploying a specific platform that fits their use cases.
  • Experimenting with KVM best practices. To help determine which best practices work best for admins' KVM deployments, it's best to experiment with other methods of KVM management. For example, admins installing Windows on a KVM host will notice that the system defaults to an integrated drive electronics disk. Though this isn't optimal, it works. However, some admins might find this particular configuration doesn't work for their needs. Admins should design their base images incrementally and carefully document their KVM deployment and adjust their tactics as needed.

Though there are several variations of KVM management best practices, it's important for admins to pick and choose wisely to ensure they utilize the capabilities of KVM as efficiently as possible.

How can admins expand and customize KVM storage?

Expanding and customizing KVM storage is essential to maintaining KVM's flexibility and performance. To do so, admins can use virsh commands to manage KVM VMs and add storage to an existing VM.

First, admins must create a disk file and determine whether it's going to be a sparse file or a file with a fixed size. Spare files offer additional space but aren't ideal, because new data blocks require allocation of resources on the underling physical device. Admins can create a pre-allocated disk file that contains 10 GB with the following command:

dd if=/dev/zero of=/var/lib/libvirt/images/vm1-disk2.img bs=1G count=10.

Next, admins must use XML code to connect to KVM to ensure it recognizes the storage device admins created. Admins can put the specification in a separate file to make configuration updates easier. The file should look similar to what is shown below:

<disk type='file' device='disk'>
     <driver name='qemu' type='raw' cache='none'/>
     <source file='/var/lib/libvirt/images/vm1-disk2.img'/
     <target dev='vdc'/>

Admins should then identify the disk type as file-based storage to use as the storage back end, followed by presenting the file as a disk within the VM. Next, admins must identify the driver as the QEMU disk driver using a raw file type.

At this point, admins can attach the disk to the device using the virsh attach-device command and config vm1 vm1-dik2.xml to expand the volume of KVM. However, admins must keep in mind that the virsh attach-device command sometimes requires admins to use an XML configuration file to help define the new disk's properties.

Are there ways to troubleshoot common KVM issues?

When KVM management doesn't go as planned, it's important admins know how to troubleshoot common issues. For example, admins can use hypervisor logs and VM logs to effectively root out issues within a KVM module. Here are six steps admins can use to effectively remediate issues with KVM.

1. Isolate the issue

The first step to remediating any issue associated with KVM is to isolate the problem. Admins should determine whether this issue affects all of their KVM machines. If this is the case, it's possible that admins can locate the issue within the KVM service, rather than the VMs themselves. Admins can check the KVM service by initiating root and using the systemctl status libvirtd command. This will show admins its uptime and whether the KVM service is active. If there is an error, admins can restart the KVM service using the systemctl start libvirtd command.

2. Check the status of VMs

If the KVM service is running, admins should then check the status of their VMs with virsh. Using the list command, admins can determine if any issues between the VM and the outside host are present. If there are issues, admins can use the virsh command console with the VM name. But admins should keep in mind that they must configure a virtual serial console in their OS to use the virsh command console.

3. Ensure there is adequate disk space

Without adequate disk space, CPU performance can severely deteriorate and, therefore, affect KVM's inherent capabilities. To check the amount of disk space available, admins can use the virsh cpu-stats centos7 command to extract CPU performance data. This will reveal VMs' utilization values and can help admins determine whether they should add additional virtual CPUs.

4. Check memory

Similar to disk space, it's essential that admins' systems have enough memory for KVM to function. The determining factor in knowing whether admins have enough memory is the swap value. If admins' swap value is anything other than zero, it indicates that their system is swapping out memory to physical disks and slowing down performance. Admins can use the virsh shutdown <machine name> command to shut down a VM. Additional commands include start, suspend, resume and reboot -- all of which can replace "shutdown" within the virsh shutdown <machine name> command to execute a new action.

5. Check the VM network

Though VM networking isn't usually a KVM issue, a VM network often uses Network Address Translation by default. In some production environments, this configuration isn't ideal and can cause issues that negatively affect KVM. If this is the case for some admins, they can find the VM network configuration on the libvirt site. However, admins must be cautious when modifying the VM network configuration and understand how those changes will affect their system.

6. Consider using a GUI vs. virsh

Admins who prefer to use GUIs over virsh command line can use the Virtual Machine Manager (VMM) to view the KVM console, create machines, perform basic administration and gather performance measurements. Admins can use VMM on any Linux distribution that has a GUI installed.

Dig Deeper on Open source virtualization

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.