Hypervisors and virtual machines

Why this matters

Almost every Linux server you touch is a virtual machine. Understanding the layer beneath it explains a great deal that otherwise looks like magic — why a disk can be grown while the machine runs, why a VM's clock drifts, why one guest is slow when the host looks idle, and why the wrong driver halves your disk throughput.

The single most valuable fact here is VirtIO: using paravirtualised drivers instead of emulated ones is often a several-fold performance difference, and it is a checkbox.

The lesson

KVM and QEMU

KVM — the Kernel-based Virtual Machine — is a kernel module that turns Linux itself into a hypervisor. It uses the CPU's hardware virtualisation extensions (Intel VT-x, AMD-V) so guest instructions run directly on the processor at native speed.

QEMU is the emulator that provides everything around the CPU: virtual disks, network cards, USB controllers, graphics. QEMU can emulate a whole machine on its own — slowly — but paired with KVM it hands CPU execution to the hardware and emulates only the devices.

So the pairing is: KVM runs the CPU, QEMU provides the hardware. They are not competitors, and "KVM/QEMU" is one stack.

lscpu | grep -E 'vmx|svm'          # is hardware virtualisation supported?
lsmod | grep kvm                   # is the module loaded?
ls /dev/kvm                        # exists = usable
virt-host-validate                 # a full readiness check

vmx (Intel) or svm (AMD) missing from lscpu usually means it is disabled in firmware rather than absent. That is the first thing to check when a VM will not start or runs impossibly slowly — without it QEMU falls back to full emulation, which is roughly an order of magnitude slower.

Hypervisors are conventionally split into type 1, running on bare metal (ESXi, Xen, Hyper-V), and type 2, running on a host OS (VirtualBox, VMware Workstation). KVM sits awkwardly across the line — it is a module inside a general-purpose kernel, but that kernel is the hypervisor, so it behaves as type 1.

VirtIO and paravirtualised drivers

An emulated device pretends to be real hardware — an Intel e1000 network card, an IDE controller. The guest's ordinary driver works unmodified, which is convenient and slow: every register access traps to the hypervisor.

Paravirtualised drivers drop the pretence. The guest knows it is virtual and talks to the hypervisor through a purpose-built interface. VirtIO is that interface on Linux.

Emulated:      guest driver → fake hardware → hypervisor → real hardware
Paravirtual:   guest VirtIO driver → hypervisor → real hardware

VirtIO devices you will select:

• virtio-blk / virtio-scsi — disks
• virtio-net — network
• virtio-balloon — dynamic memory
• virtio-rng — entropy from the host

The performance difference is large — commonly several times on disk and network throughput — and it costs nothing but choosing the right device type when you create the VM. Linux guests have VirtIO drivers built into the kernel; Windows guests need them installed, which is why a Windows VM often has to be built with an emulated disk and switched over afterwards.

A VM that is inexplicably slow at I/O, with an idle host, is very often still on emulated devices.

Disk images

qemu-img create -f qcow2 disk.qcow2 50G
qemu-img info disk.qcow2
qemu-img convert -f raw -O qcow2 disk.img disk.qcow2    # convert format
qemu-img resize disk.qcow2 +20G                          # grow
qemu-img resize disk.qcow2 --shrink 30G                  # shrink — dangerous
qemu-img snapshot -l disk.qcow2                          # internal snapshots
qemu-img check disk.qcow2

Two formats matter. raw is a plain byte-for-byte image: fastest, simplest, and it allocates the full size immediately. qcow2 — QEMU copy-on-write — supports thin provisioning, internal snapshots, compression and encryption, at a small performance cost. qcow2 for flexibility, raw for maximum speed.

Resizing is two steps and only the first is qemu-img. Growing the image gives the guest a bigger disk; the guest's partition table and filesystem still end where they did. Inside the guest you then run growpart, pvresize and lvextend -r as in the storage lessons.

Shrinking must be done from the inside out: shrink the filesystem, then the partition, then the image. Do it the other way and you truncate a filesystem that believes it still owns those blocks. Take a backup first — this is one of the operations that destroys data when done in the wrong order.

qemu-img info reports the image properties: format, virtual size, actual disk usage, backing file and snapshots. The gap between virtual and actual size is thin provisioning at work, and it is also the warning that a host datastore can be over-committed — every guest believing it has 50 GB while the host has 200 GB total is fine until they all fill up.

VM states

virsh list --all
virsh start web01
virsh shutdown web01          # ACPI: asks the guest to shut down cleanly
virsh destroy web01           # pulls the power — does NOT delete anything
virsh reboot web01
virsh suspend web01           # → paused
virsh resume web01
virsh save web01 /var/lib/libvirt/save/web01.save
virsh restore /var/lib/libvirt/save/web01.save

virsh destroy is badly named and worth fixing in your memory now. It is the virtual equivalent of holding the power button: the domain stops immediately, the disk image is untouched, and the VM can be started again. Deleting a VM is virsh undefine. The name has caught out a great many people who expected it to be destructive and a great many more who expected the opposite.

shutdown asks the guest politely and needs the guest to be listening (an ACPI handler or qemu-guest-agent). A guest that ignores it stays running — which is when destroy is the correct escalation.

Resources: CPU, RAM, storage

virsh dominfo web01
virsh setvcpus web01 4 --config          # persistent, next boot
virsh setvcpus web01 4 --live            # now, if hot-plug is supported
virsh setmem web01 4194304 --config      # kilobytes
virsh setmaxmem web01 8388608 --config
virsh domblklist web01                   # attached disks
virsh attach-disk web01 /var/lib/libvirt/images/data.qcow2 vdb --persistent
virsh domiflist web01                    # network interfaces

Three sizing points that matter more than the commands:

Do not over-allocate vCPUs. A VM with more vCPUs than it needs performs worse under contention, because the hypervisor tries to schedule all of them together. Four VMs with 2 vCPUs each usually beat two with 8.

Memory over-commitment is riskier than CPU over-commitment. A CPU-starved guest runs slowly; a memory-starved host starts swapping or invokes the OOM killer, and the failure is abrupt rather than gradual. The balloon driver lets the host reclaim unused guest memory, which softens this but does not remove it.

Thin-provisioned storage over-commits by design. Track actual usage on the host, not the sum of what guests think they have — the failure mode is every guest's disk going read-only at once when the datastore fills.

Nested virtualisation

Running a hypervisor inside a VM — needed for labs, CI runners that build VM images, and running containers-in-VMs on a virtual host.

cat /sys/module/kvm_intel/parameters/nested       # Y or N
echo "options kvm_intel nested=1" > /etc/modprobe.d/kvm.conf
modprobe -r kvm_intel && modprobe kvm_intel
# then expose host CPU features to the guest:
virsh edit web01     # <cpu mode='host-passthrough'/>

The guest must be given host-passthrough (or a model exposing vmx/svm) or the nested hypervisor sees no virtualisation support and refuses to start.

Nested virtualisation is slower at each layer and is officially "supported for development and testing" rather than production by most vendors. It is excellent for exam practice — which, for this course, is exactly the use.

On the exam

• KVM runs the CPU, QEMU provides the devices. KVM needs vmx or svm, and its absence usually means the firmware setting is off.
• VirtIO is the paravirtualised driver interface, and choosing it over emulated devices is a large, free performance win.
• qcow2 supports thin provisioning and snapshots; raw is faster and fully allocated.
• Growing a disk image does not grow the guest's filesystem — growpart, pvresize, lvextend -r inside the guest.
• Shrink from the inside out: filesystem, partition, then image.
• virsh destroy powers off; it does not delete. virsh undefine deletes.
• virsh shutdown needs a cooperating guest.
• Over-allocating vCPUs hurts performance under contention; memory over-commitment fails abruptly rather than gradually.
• Nested virtualisation needs nested=1 and host-passthrough.