Kvm on Roberto Selbach

Idle Host, Busy Guest

Wed, 25 Jun 2008 20:45:00 +0000

My laptop stayed warm with an apparently idle KVM guest running. The guest reported nearly no processor use, and the host showed only small bursts, so I first blamed inaccurate temperature sensors. Sensors are convenient suspects because they cannot write rebuttals.

I stopped services in the guest one by one. A periodic timer user was waking it frequently, but even a minimal guest produced more activity than expected. Virtual timer interrupts, emulated devices and host-side handling all require exits from guest execution. An idle guest is therefore not necessarily an idle host.

Tickless operation helps when the guest kernel can avoid unnecessary periodic ticks and when KVM presents timers accurately enough for longer idle periods. It cannot eliminate device emulation or a program requesting frequent wakeups. The host must also be tickless while idle; saving ticks in one layer and generating them in the other is elaborate bookkeeping, not power management.

After using a tickless guest kernel and disabling a polling monitor, host wakeups dropped and the machine cooled. Timekeeping remained the thing to watch: aggressive experiments are worthless if the guest clock drifts or timers fire late.

My conclusion is to shut down unused guests on battery and to measure host wakeups, not merely guest CPU percentage. For a guest that must remain available, remove polling and use appropriate virtual devices where supported. Virtualization can make a machine appear to be doing nothing in two operating systems simultaneously while the processor is, with admirable professionalism, doing work for both.

KVM Needs the Right Bottleneck

Wed, 14 Nov 2007 20:25:00 +0000

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.

KVM After 2.6.20

Thu, 08 Feb 2007 21:27:00 +0000

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.