Confirm virtualisation and choose the right driver

short · 25 min · Objective 1.7

Task

Establish whether a machine can run KVM at native speed, then observe the difference paravirtualised drivers make. The VirtIO point is the single most valuable fact in the lesson, and it costs nothing but the right device type.

Steps

  1. Confirm the CPU supports hardware virtualisation: lscpu | grep -E 'vmx|svm'. If it prints nothing, check the firmware setting -- absence usually means it is disabled, not missing.
  2. Confirm the module is loaded and usable: lsmod | grep kvm, ls /dev/kvm.
  3. Run the full readiness check: virt-host-validate. Read each line and note which are pass, warn and fail.
  4. Create a small VM with emulated disk and network explicitly, deliberately choosing the slow path: virt-install ... --disk bus=sata --network model=e1000.
  5. Inside the guest, measure disk throughput with a simple dd ... oflag=direct and note it.
  6. Recreate or reconfigure the VM with --disk bus=virtio and --network model=virtio. Measure again and compare.
  7. Confirm which devices the guest is using with lspci inside it -- VirtIO devices identify themselves plainly.

Verify

grep -Eqc 'vmx|svm' /proc/cpuinfo && echo "hardware virtualisation present"
ls /dev/kvm && echo "kvm usable"
virt-host-validate | grep -i qemu | head
# inside the guest, virtio disk vs emulated:
lspci | grep -i virtio

virt-host-validate passing on the QEMU line is the readiness gate. The throughput difference between steps 5 and 6 is the lesson: the same VM, the same host, several times the disk and network performance, for the cost of choosing virtio at creation.

Notes

A VM that is inexplicably slow at I/O while the host is idle is very often still on emulated devices. It is the first thing to check, and lspci inside the guest settles it in one line.