Slashdot Mirror
Linux 3.0 Will Have Full Xen Support
GPLHost-Thomas writes "The very last components that were needed to run Xen as a dom0 have finally reached kernel.org. The Xen block backend was one major feature missing from 2.6.39 dom0 support, and it's now included. Posts on the Xen blog, at Oracle and at Citrix celebrate this achievement."
Actually you have been able to run newer kernel on EC2 for a long time! Xen domU (guest VM) support has been in upstream Linux kernel since version 2.6.24. Now upcoming Linux kernel 3.0 adds Xen dom0 support, which is the *host* support, ie. Linux kernel 3.0 can run on Xen hypervisor (xen.gz) as the "management console", providing various backends (virtual networks, virtual disks) allowing you to launch Xen VMs.
Xen Dom0 support has been supported in released versions of NetBSD and Solaris for something like 4 years, while the VMWare lobby on the LKML was requiring the entire paravirtualisation subsystem to be rewritten before they'd accept patches, and Red Hat decided to push KVM as a Xen replacement, in spite of them having very different capabilities.
I am TheRaven on Soylent News
Xen has features that KVM doesn't have (by design). For example Xen "stubdomains" and "driver domains", full memory address space separation between domains, etc.. and of course it's good to have multiple opensource virtualization platforms, competition is a good thing!
Xen is a secure baremetal hypervisor (xen.gz), around 2 MB in size, and it's the first thing that boots on your computer from GRUB. After Xen hypervisor has started it boots the "management console" VM, called "Xen dom0", which is most often Linux, but it could also be BSD or Solaris. Upstream Linux kernel v3.0 can run as Xen dom0 without additional patches. Xen dom0 has some special privileges, like direct access to hardware, so you can run device drivers in dom0 (=use native Linux kernel device drivers for disk/net etc), and dom0 then provides virtual networks and virtual disks for other VMs through Xen hypervisor. Xen also has the concept of "driver domains", where you can dedicate a piece of hardware to some VM (with Xen PCI passthru), and run the driver for the hardware in the VM, instead of dom0, adding further separation and security to the system. Xen "Driver domain" VMs can provide virtual network and virtual disk backends for other VMs. KVM on the other hand is a loadable module for Linux kernel, which turns Linux kernel into a hypervisor. The difference is that in KVM all the processes (sshd, apache, etc) running on the host Linux and the VMs share the same memory address space. So KVM has less separation between the host and the VMs, by design. VMs in KVM are processes on the host Linux, not "true" separated VMs.
What is Xen? Xen is a virtualization project that is run by four of the top five major cloud providers (including Amazon, Rackspace, &c); a commercial version written by Citrix run by thousands of sites worldwide, including large companies like Tesco, SAP, &c. It's also the approved way of running Oracle databases in a virtual machine.
What does that have to do with Linux? The Xen project is focused on virtualization. But Xen still needs to run on systems with all manner of devices. There are several ways they could have handled this. One is to try to put drivers for all of the devices in Xen. This would require a huge amount of work, mostly copying new device drivers and device fixes from Linux and porting them over to Xen. It would be a colossal waste of time: they would be duplicating effort of what Linux already does well, instead of doing what they want to do -- work on virtualization.
So what they do instead is run Xen as the hypervisor, but leverage the device drivers in Linux. They do this by creating a special VM, called "domain 0" or "dom0", which is booted first after Xen boots, that has drivers to control all of the devices. This domain is a version of Linux that is designed to be able to work with Xen to control and drive devices, while allowing Xen to control memory, CPU, and interrupts (the key hardware required to do virtualization).
Xen has been out for years. Why is this just being announced? The Xen project started out of a University research project. As is typical, they were trying to answer the question "what is possible?", and as a result, felt free to completely rip out and rewrite large sections of Linux code. This code was not upstream-able -- changes were made that were (rightly) not acceptable to the Kernel community.
Since that time, the Xen community has maintained branches of Linux with these intrusive, non-upstreamable patches, and used these branches as domain 0. At the same time, they have worked to try to get support for Linux-as-domain-0 into the mainline tree. This has been a long process, and something that has been a sore point for users of Xen for some time.
But as of Linux 3.0, all of the functionality required to use the mainline kernel tree as a basic dom0 with Xen is in. This means that if you install Xen, you'll be able to use the same kernel you booted with natively as the dom0 for Xen. It means that distributions won't have to maintain two separate kernels, one for booting bare metal, and one for booting on Xen. And it means not having to maintain the xen-linux fork, which has been a lot of painful work for the Xen community.
TCP: Why the Internet is full of SYN.
Not sure which Xen book you read, but the grandparent makes a lot of errors and I'd be surprised if a book was that inaccurate. Mine is slightly out of date, but at least was accurate at the time of printing (technical review was done by the original Xen developer).
Let's start at the end. KVM VMs and userspace Linux applications do not share the same address space. This isn't even true if you remove KVM - userspace processes have isolated address spaces. KVM requires the CPU have virtualisation extensions, which means (among other things) nested page tables. This means that there is hardware-enforced separation between the pages. The guest OS sees page tables that map from virtual to pseudophysical address space, but thinks that they map from virtual to physical. The host (Linux) sets the mapping from these pseudophysical pages to real memory pages and the CPU enforces this mapping. Xen uses exactly the same mechanism in HVM mode (it uses some other tricks in paravirtual mode).
The driver domains are correct, but it's worth noting that Xen will use VT-d or equivalent to protect against malicious use. Linux can't give a userspace program direct access to the disk controller, because if it did then a rogue DMA command could compromise the kernel. Xen will use the IOMMU to ensure that each peripheral may only issue DMAs to memory owned by the driver domain. The Solaris VM that you have accessing your block device and exporting virtual disks from ZVOLs, for example, can trample its own address space with rogue DMAs, but it can't touch any memory in other VMs.
This means that Xen (in theory) has a smaller attack profile than KVM. Xen is basically a microkernel, and it enforces low privilege on the services (OS instances) that provide drivers and the management console. With KVM, the entire kernel runs in privileged mode. It's fairly common these days for the management console domain to have either no network access, or highly-restricted access, and be separated from the driver domains. If there is a flaw in the network stack in Linux and an attacker compromises it, then with KVM they now have access to all of your VMs. With Xen, they control that driver domain, and they can inject packets into the other VMs, but they are no more able to compromise them than they would be if they controlled the router one hop away.
KVM recently gained support or live migration (this has been stable in Xen for a long time - they were doing demos of live-migrating a Quake 2 server with clients connected since the early 2000s), but it doesn't have any of the high-availability stuff that Xen 4 includes. This allows you to do things like run two instances of the same VM on different machines and transparently fail-over when one dies.
I am TheRaven on Soylent News