Virtualization

I created a KVM guest to test packages without sacrificing another partition. The installer booted, the guest saw a disk, and I congratulated myself until copying files inside it reduced the entire machine to sludge.

My first attempt was to add more guest memory and another virtual processor. The copy became no faster, while the host began swapping. This is a reliable way to make two operating systems unhappy with one setting.

KVM uses the processor’s virtualization extensions to run guest code directly in a special execution mode. That avoids translating every ordinary instruction, but devices are a different matter. The guest still talks to emulated hardware, and each operation may require work in the userspace machine emulator and the host kernel. My slow copy was dominated by the virtual disk path, not by a shortage of arithmetic.

Moving the guest image off the host’s busy system disk helped. Using a simpler virtual disk setup and avoiding unnecessary host caching also made behavior more consistent, though the safest setting depends on what guarantees the storage actually provides. I am not going to trade filesystem integrity for a prettier benchmark. The benchmark will not visit me in hospital.

Preallocating space also avoided some pauses caused by repeatedly extending a sparse image during installation.

Processor support also needs verification rather than assumption. The KVM modules must load, virtualization must be enabled by firmware, and the host kernel needs the appropriate architecture module. Once that path works, compute-heavy tasks can be surprisingly close to native speed. Graphics and storage remain much more obviously virtual.

For my package-testing guest, one virtual processor and enough memory to avoid guest swapping are sufficient. The host must retain enough memory for its own cache and applications. I now measure CPU, host disk activity and swapping separately before changing the virtual machine configuration.

KVM is already useful because it fits into Linux rather than requiring a separate host operating environment. It is not a declaration that every emulated device is free. My practical conclusion is to size the guest modestly and find the actual bottleneck. Adding virtual hardware to cure slow virtual I/O only creates a more lavishly furnished traffic jam.

Linux 2.6.20 was released this week with KVM included, so I tried booting a small guest rather than merely reading patches. The first attempt failed immediately because the processor’s virtualisation support was disabled in the firmware. Progress began with entering setup, which keeps systems programming humble.

KVM uses the processor’s hardware virtualisation extensions and exposes a kernel interface through /dev/kvm. A user-space program supplies the virtual machine’s device model and asks the kernel to run virtual CPUs. This is not a complete machine monitor appearing from one kernel option; kernel and user space divide the work.

The basic checks on this Intel test box were:

grep vmx /proc/cpuinfo
modprobe kvm
modprobe kvm-intel
ls -l /dev/kvm

On an AMD processor I would look for svm and use the corresponding module. Seeing the flag is necessary but not always sufficient, because firmware can still disable the facility.

After loading the modules, I launched a guest image with the available QEMU KVM support and watched the kernel log in another terminal. The guest booted, though virtual disk and network performance are not conclusions I can draw from ten minutes and one ageing drive.

I prefer this architecture because putting CPU execution support behind a kernel interface lets normal Linux scheduling and memory management participate, while device emulation remains in user space where a failure is less likely to take the host with it. The caveat is that the boundary can impose overhead, hardware support varies, and young interfaces may change as use exposes mistakes.

Security deserves restraint too. Hardware isolation is not a promise that a hostile guest can never escape. Device emulation processes parse guest-controlled input, and kernel code now manages another complicated processor mode. I am treating guests as isolated test systems, not as magical bags into which all risk disappears.

The useful result today is narrow: with 2.6.20, suitable hardware, enabled firmware support, kernel modules, and matching user space, a Linux host can run a hardware-assisted guest. Whether KVM becomes the preferred general solution will depend on performance, management tools, and how gracefully it handles less cooperative machines.

For now it boots. In infrastructure experiments, reaching a login prompt is the traditional point at which confidence rises faster than evidence.