Slashdot Mirror
Red Hat Wants Xen In Linux Kernel
DIY News writes "Red Hat is aggressively pushing to get Xen virtualization technology included in the Linux kernel as quickly as possible. This move comes as Microsoft is pushing its own virtualization products and recently relaxed some of its licensing requirements around Windows Server 2003 to facilitate more pervasive adoption and use of those technologies."
Well, Xen is free, and Intel/AMD hardware solutions are comming soon, which will allow Xen to run Windows unmodified. So, once everyone is upgraded to the new CPU's, virtualization will become a basic standard feature for everyone. MS can compete by giving their solution away for free, but either way, it doesn't get better than free for the consumer.
From a link in TFA:
"Xen is a virtualization technology available for the Linux kernel that lets you enclose and test new upgrades as if running them in the existing environment but without the worries of disturbing the original system"
"I'm going to f***ing bury that guy, I have done it before, and I will do it again. I'm going to f***ing kill Google"
"While Xen appears as a neat package, why choose Xen instead of vservers?
The hardware cost of running multiple copies of the same OS with vservers is smaller than Xen - there is one and only one copy of glibc in memory, one and only scheduler, and so on."
But part of the purpose of a virtual machine is that you can run a different operating system in each partition, including different schedulers and libc versions.
That gives the impression that Vmare is a great product, I'd debate that. I find it a PITA alot of the time. XEN isn't the only kid on the block, Qemu works really well too.
With Xen, a kernel panic effects only that kernel, the other kernels keep on running. Under vservers, it takes down the machine.
Under Xen you can reduce the parent kernel down to obare minimum, reducing the chance of errors.
eg: you want to run an experimental iptable module on one of the virtual servers, no problem, if it crashes, all the other servers keep on trucking.
Essentially Xen provides a better sandbox from a stability/security perspective.
Remember that anything RedHat pushes into the Linux Kernel will automatically become available for ALL OTHER LINUX DISTROS. So please forgive my ignorance, but where is the "badness" in that aim? AFAIK, nothing that RedHat has developed has been proprietary in any way. They do have a track record of buying things from other companies and releasing them as OSS stuff. Again please let me know of the badness in that aim.
IMHO, virtualisation is going to become very important to all sofware developers over the next few years. If it is easy to fire up a Debian system on top of a SUSE and have Mandriva & RedHat running as well then you can test your app on all these platforms at the same time. Hurrah!
I'd rather be riding my '63 Triumph T120.
I'm pretty sure they do that, most distros tweak the kernel to suit them somewhat.
I know that SUSE 9.3+ has built-in support for Xen, and since there are different kernel packages especially for Xen support, I assume that Suse has accomplished what Red Hat is working towards. Although, I could be completely wrong since I didn't RTFA.
Xen is 100% different. Also, Xen supports over 100 VMs per machine.
Also, Xen does things to make that 1 copy of glibc a reality. Arguably, that 1 scheduler is one of the primary reasons you would prefer Xen.
RTFA
"Part of the Red Hat emerging technology team's efforts will be to drive the Xen virtualization technologies as part of the Linux kernel rather than as part of a sidebar project, as is currently the case, Stevens said."
JOhn
Campaign for Liberty
These guys(Xen) have all these companies donating money to them, but have been beaten to kernel inclusion by UML. UML is basically a two man project, developed by Jeff Dike and Paolo Giarrusso (aka Blaisorblade). Xen may be multi platform and all, but thus far UML is easier to handle and does not require the host to run a patched kernel (you could use a patched kernel, but the newest development Skas0 does not need it).
This space is intentionally staring blankly at you
You must have never used vmware before for it's best use.
vmware in linux is the absolute #1 tool useful for reverse engineering. I can pipe the rs232 and usb as well as ethernet ports fo the hosted OS to files or through sniffers on my linux machine and figure out quite quickly how a device is talking to it's hardware or server on the net. Capturing an entire session into a input and an output file makes is trivial to reverse engineer something.
this can not be done with zen or the utter crap that msft is making.
Since you've received few answers to you actual question, getting xen into the kernel means the xen patches required to run the linux kernel in a xen hypervisor (both as a guest and a host) will be a part of the mainstream kernel and be able to be built trivially. RedHat ships 3 different kernels now with FC4. One is a normal kernel available in both smp and non-smp configurations. Then we have the XenU kernel, which is a kernel designed to boot in a guest xen session. The Xen0 kernel is the kernel that you'd actually boot on top of xen and use as your main OS.
Once the Xen0 kernel is running on top of xen, you have basically a normal linux kernel running that does all the hardware support. Then you load up Xen guest machines running the Xen0 kernel and these run their in their own virtual machines complete with their own disk images and linux distro. So xen doesn't really have anything to do with running elf binaries on the other machine. If you ran FreeBSD in the guest, it would run those binaries inside of that OS and that libc. When Xen 3.0 comes out, if you have the new intel or amd chips that support on-chip virtualization, then Windows XP can even run as a guest underneath the linux kernel-Xen0 host.
I still remeber reading that the whole x86 architecture didn't meet the requirements for virtualization, meaning that this recent trend is probably the result of VMware figuring out some "tricks to make it work", and then everyone else jumping on the bandwagon.
In any case, if you really want to learn about the fundamental concepts behind virtualization, I strongly recommend reading the following paper: Formal Requirements for Virtualizable Third Generation Architectures
Yes, it was published in 1974, but most of the concepts are still very applicable and make a lot of sense. (though the architecture examples are obviously dated)
This is a very good paper which lays out all the ground rules. Sure, it may sound a bit academic in terminology and explanation, but it is still quite readable.
Don't let that comment fool you though. Xen is much, much more. What if you organization had 4 distinct sites they wanted to host on one server? Start up 4 virtual machines, and back up their running state from time to time. If one goes down, just restart it from your clean backup IN SECONDS. Better yet, do it automatically. At the same time, Xen enforces separation from the host OS that the virtual machines are running on, so you don't have to worry about it being compromised (well, not in any way anyone has been able to demonstrate or even postulate yet).
While Xen appears as a neat package, why choose Xen instead of vservers?
Perhaps because vservers lack some of the neat features of Xen, such as on-the-fly instance migration and full iptables support?
Furthermore, vservers is, for the foreseeable future, a Linux-only project. So far, NetBSD and Solaris have been ported to Xen, and basic support for FreeBSD as a guest host is available. Once Intel VT and AMD Pacifica are available, Xen will also support Windows XP SP2.
Given just these benefits (and Xen has many more), it's no surprise that Xen appeals to more people and applications.
I'm Trappped at Berkeley.
http://www.novell.com/products/linuxprofessional/c omparative.html
This sig kills fascists.
Solaris "zones" technically aren't really virtualization, per se. Rather, they are virtual-machine-"like" process containers. Inside of a zone, it behaves very much like a virtual machine, but it really isn't.
This concept likely provides many advantages for system resource management on a server, where you only care about a single operating system. It does not, however, let you run different OSs at the same time.
Multiple OSes at once? [..] I never got the whole concept of virtual servers
Its mainly an enterprise play.
If you're an old-timer UNIX admin, you may have difficulty understanding the point of server virtualization (i.e. multiple OS instances). In UNIXland, it has been normal and customary for several completely unrelated applications to run under the same OS instance, together servicing thousands of users. That never worked well in Windowsland. That being said, it didn't stop manufacturers from making staggering improvements in performace and capabilities of Intel servers. Companies grew to expect single Intel boxes to perform at the levels of large UNIX servers. The only way to achieve that in recent years has been to use industrial strength virtualization technology (basically, ESX). The boxes are beefier than ever, and ESX isn't cheap, but it works wonders.
For $50k, you can run 50 VMware guests on one very beefy box (not counting SAN), but you'd want a second for failover. For $75k, you can run about 100 guests on 14 blades in 7U (again, not counting SAN) and have the guests automatically migrate to the blades most able to run their workload at that moment in time. Ask a blade to come down for maintenance, and all the guests scatter to other blades before the blade powers off. Replaced a dead blade with a blank? Your systems management policies detect the new blank and automatically install ESX on it so guests can migrate back and evenly spread out the load.
Sounds crazy, I know, but that's a taste of what we're doing in the enteprise space these days.
Intelligent Life on Earth
Imagine if you would the ability to use Xen for unlimited operating systems, no licensing cost of the base OS, thinking about it, I would prefer to be in Microsoft's shoes as opposed to VMWare's. Only difference is that Xen when compared to VMWare is a very immature platform and no IT manager is going to take Xen over VMWare just yet (Unless cost is a BIG factor).
I've been using xen here in what I call "production development." Its serving several development servers. One of them is running a crappy spam assassing frontend thats pretty resource intensive. I was quite satisfied when my colleuge asked me when I was going to move said test server from real hardware to Xen a week after I did the migration.
Anyway, while vmware is definatly prettier, I think xen performs better. Of course being xen can't run windows I can't see how one of the machines catching a virus affects the performance of all the machines. But if your comfortable with the command line, and have a decent grasp of lvm and piping tar over ssh, you should have no problem using xen.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
The Xen0 kernel is the kernel that you'd actually boot on top of xen and use as your main OS.
Nitpicking the "main OS" wording: it's the host OS. I would think in a production server environment you'd keep this OS minimal and not do much in the Xen0 domain so you don't risk crashing or compromising the host environment. On the other hand, if it's a game box it would make sense to have the 3d video drivers in domain 0, and if it's a workstation it may or may not make sense to have the host OS run apps and have the user domains for testing purposes.
Once the Xen0 kernel is running on top of xen, you have basically a normal linux kernel running that does all the hardware support. Then you load up Xen guest machines running the Xen0 kernel and these run their in their own virtual machines complete with their own disk images and linux distro. (my bolding)
Typo: The guests are XenU (user) kernels which typically have no real device drivers and are therefore much smaller. Very well put, though. Note that you can use any block device as a disk image: a file, an LVM volume or even an actual hdd.
They won't even know that this originated in the *nix world.
It didn't. This is mainframe technology. It just didn't work very well on x86 and hence the Windows using world was unaware of it. There is quite a bit of stuff that doesn't exist in the Windows world yet.
I can throw myself at the ground, and miss.
The full x86 architecture is not suitable for virtualization, because there are a few instructions which fail silently when run from user level.
VMware uses various techniques to get around this, including full simulation and binary re-writing.
Xen uses another approach, where they port to an instruction set that is basically x86 without the problematic instructions. This approach requires that the guest OS's be modfied.
This will all change with the new virtualization instructions being added by both AMD and Intel. Once that is in place, Xen will be able to run unmodified guest OS's (such as Windows, for instance). There will be a speed hit though, so modified guests will be prefered if speed is an issue.
There are a few problems with Xen. First, it's i386 only.
Not true. Today, Xen supports i386, x86_64, and ia64. Xen is currently being ported to PowerPC also.
Second (and this is the biggest problem IMO) - Xen is venture-backed, and seems to be extremely eager to show their investors a return.
XenSource is a company backed by VC. Xen is developed by a much larger community though. There are a ton of press-releases that XenSource puts out that have the typical marketting junk that most Open Source folks despise but whatever, XenSource != Xen. Most of there people aren't even actively working on Xen anyway (they have a product for Xen management),
If XenSource does not turn out to be a great business, then will Xen still be developed and maintained?
Absolutely.
Also, there is another project that I plug every chance I get - Linux Vserver. Unlike Xen, this is a purely volunteer effort, and is very innovative and attemtps to solve a difficult issue. Unlike Xen, these guys actually do not want to be in the mainline for now, becuase they think it will slow down development.
Yup. That's why VServer is not in the kernel--they don't want to be in the kernel. VServer is a cool project, and I would love to see it end up in the kernel. Xen is also a cool project and it would be great to see it in the kernel. The kernel guys *will not* accept crap. Large portions of the Xen Linux port are currently being rewritten to live up to kernel standards. I have a ton of faith in the kernel folks overseeing the process.