On BA Chapter 7 (Xen and the Beauty of ...)

After reading the chapter on Xen and realizing that I have to comment on it in the context of an Architecture class as opposed to the typical OS class where things like performance are the most analyzed concerns, I could not help comparing a few Xen architectural decisions with similar architectures, among which the most notable being KVM. KVM (for Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V).

Xen is open source, decision which most definitely benefited Xen because of the huge amount of software that it has been able to harness, from the Linux kernel to QEMU emulator. KVM architects made a similar decision by leveraging on the Linux kernel and QEMU, however they do not modify the kernel code base and provide a patched version of the kernel as Xen does. They integrate the hypervisor directly into the kernel as a loadable kernel module, thus leaving the kernel structures untouched; the integration is done via the well defined interface for kernel loadable modules. The separation of concerns and simplicity of KVM come from its clear design: a device driver for managing the virtualization hardware and a user space QEMU based component for emulating PC hardware. It is exactly the separation of concerns that prevented Xen from finding its way into the mainline Linux kernel. The kernel component of KVM is included in mainline Linux, as of 2.6.20.

Another Xen design decision was to provide VM management via Xen domain0. In contrast, a KVM virtual machine is simply a Linux process. All of the standard tools apply: one can destroy, pause, and resume a virtual machine with the kill command and even Ctrl-C, or use top to view VM resource usage. This level of reusability confers KVM great flexibility in managing VMs. Also, adhering to the Linux standard interface, already well understood by many users, helps KVM users learn VM management easily.

Last but not least, by adding virtualization capabilities to a standard Linux kernel, KVM can benefit all the fine tuning work that has gone and is going into the kernel. While Xen had to deal with frontend and backend driver model, with driver domains, KVM simply had all this support in the Linux kernel itself. Adding support for a new driver in the Linux kernel would automatically mean having that driver available to the KVM supervisor.

Regarding paravirtualization, strongly promoted by Xen as _the_ technique to improve the performance of the guest operating system, it has also got support in KVM. However, as a design decision it is very hard to be judged. With its main drawback, guest modification, and with the user preference to run unmodified guests, it is hard to foresee the future of paravirtualization. The only certain fact is that the success of paravirtualization will always begin where the concrete capabilities of the hardware assisted virtualization will end. And hardware will always evolve.