Confirm virtualisation and choose the right driver
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
- 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. - Confirm the module is loaded and usable:
lsmod | grep kvm,ls /dev/kvm. - Run the full readiness check:
virt-host-validate. Read each line and note which are pass, warn and fail. - Create a small VM with emulated disk and network explicitly, deliberately choosing the slow path:
virt-install ... --disk bus=sata --network model=e1000. - Inside the guest, measure disk throughput with a simple
dd ... oflag=directand note it. - Recreate or reconfigure the VM with
--disk bus=virtioand--network model=virtio. Measure again and compare. - Confirm which devices the guest is using with
lspciinside 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.