https://www.techtarget.com/searchitoperations/feature/4-FAQs-to-help-master-KVM-management
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.
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. 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:
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.
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'/>
</disk>
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.
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.
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.
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.
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.
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.
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.
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.
31 Jul 2020