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."
... what??
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.
16 cores and 32 GB of RAM
That's, uh, not exactly all that out there, these days.
sic transit gloria mundi
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!
This why Xen PDF might explain it well. Under Xen, guests are running inside the host operating system. In Xen, the hypervisor starts a special Linux kernel (the dom0) that will only take care of drivers for the guests. The design is really different, and has different features. For example, in Xen, you can have your dom0 to run on 2 cores, leaving the rest for the guests (I'm not sure that is possible in KVM), and if you want to avoid any possible CPU starvation, you can even have the guests to not use the cores that the dom0 is using. The CPU scheduler is also very different (and there's not only one available...).
I'm not sure if you are trolling on purpose, or if you don't understand what this news is all about. But I'll bite.
You see, linux runs on almost any kind of hardware: from embedded systems on toasters to phones, desktop computers, laptops, to big servers. Even most supercomputers to date are running Linux. There is a _lot_ of different users that would use Linux in many different ways.
Xen is a technology that virtualizes machines, mainly intended for the data center and cloud computing environments.
This is NOT intended for users in any way. Your mom does NOT have to know that Xen even exists, just like windows users don't need to know what IIS or Apache is in order to browse the web.
Would you also say that windows and OSX is "is way too complicated for people" because you read slashdot news about some geeky kernel details about windows/OSX ?
Surely "no user should need to know, or care about this sort of thing.".
They don't. So do you about Xen. I'm not sure why someone like you is reading and posting on /., because this is usually "news for nerds", as the site indicates. :)
As many slashdotters would say about your reasoning behind your post: "You are doing it wrong." ;)
Actually the design is pretty different. Take a look at these slides: http://www.slideshare.net/xen_com_mgr/why-xen-slides . That should explain the differences. Xen is also multi-OS, ie. you can use also BSD/Solaris in addition to Linux as a Xen host, while KVM is Linux-only as host.
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.
It's partly historical and partly because Xen is structured differently to lots of other virtualisation systems.
"Domain" is to "virtual machine" as "process" is to "program". i.e. it's a running instance of a virtual machine. If you kill a VM and restart it, it's the same VM but a different domain. In practice VM and domain are blurred a bit when people talk, though.
Domain 0 is a bit like the host OS, but for technical reasons it's not exactly.
Just had to reply to this.. Sun forked Xen 3.1 something like 4 years ago, yes. That same fork, Xen version 3.1 is what is still being used today in Solaris and Sun had previously (pre-buyout) said they would not merge to any newer versions of xen.
So while Solaris can claim Xen Dom0 support it is no where near the capabilities of current Xen 4.0 and with no plans to update you're stuck on 3.1 with support only coming from, now, Oracle. Yeah, awesome.
There doesn't have to be a battle -- there's room in the OSS world for two technologies. Xen and KVM are different technologies. For most desktop users, KVM is probably the best option; but on big servers, linux running KVM has to mix scheduling between VMs and processes. Since Xen runs VMs exclusively, it can focus only on algorithms that work well for VMs.
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
'VMWare lobby', WTF? The real problem were things like this and this:
The fact is (and this is a _fact_): Xen is a total mess from a development
standpoint. I talked about this in private with Jeremy. Xen pollutes the
architecture code in ways that NO OTHER subsystem does. And I have never
EVER seen the Xen developers really acknowledge that and try to fix it.
Thomas pointed to patches that add _explicitly_ Xen-related special cases
that aren't even trying to make sense. See the local apic thing.
So quite frankly, I wish some of the Xen people looked themselves in the
mirror, and then asked themselves "would _I_ merge something ugly like
that, if it was filling my subsystem with totally unrelated hacks for some
other crap"?
Seriously.
If it was just the local APIC, fine. But it may be just the local APIC
code this time around, next time it will be something else. It's been TLB,
it's been entry_*.S, it's been all over. Some of them are performance
issues.
I dunno. I just do know that I pointed out the statistics for how
mindlessly incestuous the Xen patches have historically been to Jeremy. He
admitted it. I've not seen _anybody_ say that things will improve.
Xen has been painful. If you give maintainers pain, don't expect them to
love you or respect you.
So I would really suggest that Xen people should look at _why_ they are
giving maintainers so much pain.
Linus
BTW, I have absolutely no doubt that NetBSD and Solaris merged Xen faster than anyone else.