Virtualization: Part 4 — KVM

KVM (Kernel-based Virtual Machine) — a virtualization subsystem built into the Linux kernel since version 2.6.20. It uses CPU hardware virtualization support (Intel VT-x, AMD-V) and turns the Linux kernel into a hypervisor. Each virtual machine runs like a normal Linux process, so the usual mechanisms apply: the scheduler, memory management, cgroups.

KVM consists of the kvm.ko module and a CPU-specific module — kvm-intel.ko or kvm-amd.ko. KVM itself is only responsible for executing VM code on the processor. Virtual disks, network cards, the video adapter and other devices are emulated by QEMU, which runs in user space. Therefore in practice people speak of the KVM + QEMU stack, and VMs are launched via libvirt — a management layer with the virsh utility. Proxmox VE, OpenStack, most cloud providers and Russian virtualization platforms are built on this stack.

Checking support

The CPU must support hardware virtualization, and it must be enabled in BIOS/UEFI:

grep -Ec '(vmx|svm)' /proc/cpuinfo   # greater than zero — support available
ls -l /dev/kvm                       # the device appears after the module is loaded

On Ubuntu and Debian there is the kvm-ok utility from the cpu-checker package: it reports whether KVM acceleration can be used and hints if virtualization is disabled in BIOS.

Installation on Ubuntu or Debian

sudo apt update
sudo apt install qemu-kvm libvirt-daemon-system virtinst
sudo adduser $USER libvirt     # then log out and log in again
virsh list --all

libvirt-daemon-system installs the libvirt service, virtinst — the virt-install utility for creating VMs. For GUI management there is virt-manager (desktop application) and the web console Cockpit with the cockpit-machines module, which allows creating, running and configuring VMs from a browser.

First virtual machine

Example of installing a VM from an ISO image. The command is constructed following the virt-install documentation:

virt-install --connect qemu:///system \
  --name web01 \
  --memory 4096 --vcpus 2 \
  --disk size=40 \
  --osinfo ubuntu24.04 \
  --cdrom /var/lib/libvirt/images/ubuntu-24.04-live-server-amd64.iso \
  --network bridge=br0

• --osinfo sets the guest OS type, and libvirt picks default settings for it; the list of known values is shown by virt-install --osinfo list;
• --disk size=40 creates a new 40 GB disk in the default storage pool;
• --network bridge=br0 connects the VM to the host bridge; without this parameter the VM ends up in libvirt’s default network.

Everyday management:

virsh list --all            # all VMs and their state
virsh start web01           # start
virsh shutdown web01        # properly shut down via the guest OS
virsh autostart web01       # start together with the host
virsh edit web01            # change configuration (XML)

Networking: NAT or bridge

• Default network (NAT). libvirt creates the virbr0 bridge and the 192.168.122.0/24 subnet. VMs reach the internet via the host address, but cannot be connected to directly from the external network. Suitable for a workstation and testing.
• Bridge. The host’s physical interface is included in a Linux bridge, for example br0, and VMs end up on the same network as the host with their own addresses. libvirt does not manage the bridge: it is configured by the system tools — on Ubuntu via Netplan. How to describe a bridge, VLAN and bonding in Netplan is in the article “Netplan: advanced network configuration”.

When configuring a bridge on a remote server, keep your provider’s console at hand: a mistake in the network configuration will cut off SSH access.

Disks: qcow2 or raw

• qcow2 — QEMU’s primary format: the file grows as data is written, supports snapshots and compression. Convenient when snapshots and space savings are needed.
• raw — a plain image without metadata. Simpler and slightly faster for I/O, easy to move to other systems, but does not provide snapshots at the format level.

For production VMs raw on LVM or ZFS is often used: snapshots are then taken by the storage rather than by the disk format.

What’s missing in KVM

KVM and libvirt are “building blocks”, not a complete platform. Out of the box there is no:

• web interface for cluster management;
• high availability with automatic VM restart on another host;
• centralized backup.

All this is provided by platforms built on top of KVM: Proxmox VE, OpenStack, the Russian zVirt and SpaceVM. “Pure” KVM with libvirt makes sense for one or two hosts, developer testbeds and cases where the infrastructure is already described in Ansible or Terraform.

Common mistakes

• Virtualization disabled in BIOS. VM runs without KVM acceleration and is many times slower; check /dev/kvm and the output of kvm-ok.
• Running as root instead of using the libvirt group and giving access to qemu:///system to all users on the server.
• Windows without virtio drivers. The installer doesn’t see the disk on the virtio controller; the virtio-win driver image is attached as a second drive during installation.
• Snapshots instead of backups. A qcow2 snapshot lives in the same file as the VM disk.
• Insufficient host memory. The sum of VM memory exceeds physical memory — the kernel begins killing VM processes when memory is low.