Mastering KVM Virtualization: Key Concepts, Overcommit Strategies, and Essential Tools

KVM Virtualization Learning Summary

1. Virtualization is divided into full virtualization and para‑virtualization, both requiring CPU support.

2. Full virtualization does not require any configuration; it makes the user feel like they are using a real server.

3. Para‑virtualization requires user configuration and is somewhat cumbersome.

4. KVM is merely a Linux kernel module; additional tools are needed to manage and create complete KVM virtual machines.

5. Compared with Xen, KVM is much simpler: it does not require recompiling the kernel or modifying the current kernel, as it consists of dynamically loadable .ko modules, resulting in a smaller code base and lower error probability, while often delivering better performance than Xen.

6. The directory /etc/libvirt/qemu stores virtual machine configuration files.

7. To back up KVM, copy the XML configuration files and the image files located in /etc/libvirt/qemu.

8. To restore KVM, enter virsh and execute define with the path to the XML file, ensuring the image file exists.

9. KVM allows over‑commit of physical resources, meaning the allocated CPU and memory can exceed the actual physical resources.

10. CPU over‑commit lets one or more guests use a total number of vCPUs greater than the physical CPUs; QEMU creates additional threads scheduled by the Linux kernel on the physical CPUs.

11. The recommended practice is to over‑commit CPUs across multiple guests, e.g., on a host with 4 logical CPUs run more than 4 guests (8 or 16), each assigned one vCPU. When host load is low, Linux scheduling remains efficient and performance loss is minimal.

12. The least recommended practice is to assign a single guest more vCPUs than the host has physical CPUs, which can cause noticeable performance degradation, though moderate over‑commit may be acceptable if the host is not fully loaded.

13. Overall, KVM permits CPU over‑commit, but it is not recommended in production environments, especially under heavy load; thorough performance and stability testing is required before deployment.

14. Memory in KVM also supports over‑commit, allowing the total assigned memory to exceed the physical memory.

15. Three common methods to achieve memory over‑commit are:

Swapping: using swap space to compensate for insufficient memory.

Ballooning: using the virio_balloon driver to coordinate between the hypervisor and guests.

Page sharing (KSM – Kernel Samepage Merging): merging identical memory pages across guests.

16. The modprobe command loads the KVM kernel module; installing KVM via RPM automatically loads the module at boot. However, the kernel module alone is insufficient; user‑space tools are required to create and manage VMs.

17. QEMU is a powerful virtualization tool that can emulate different CPU architectures, such as running a PowerPC CPU on an x86 host.

18. QEMU‑KVM combines QEMU's x86 portion with modifications to provide user‑space tools that control the KVM kernel module.

19. Management tools like libvirt, virsh, and virt‑manager simplify VM control. Red Hat provides additional utilities (e.g., libguestfs) because QEMU alone is less efficient.

20. In the KVM model, each VM is a standard Linux process managed by the scheduler, running in a dedicated guest mode with its own kernel and user mode.

21. The kernel module exports the device /dev/kvm, enabling the guest mode and isolating each VM's address space from the host and other VMs.