A forthcoming update to the Linux 2.6 kernel will incorporate the Xen open source virtualization technology, said the man who maintains the Linux kernel.
Linux 2.6 Kernel to Include Xen; Infiniband, NFS 4
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I think it’s really encouraging to see such a rapid developmental pace with the 2.6 Kernel series. There’ve been a large number of exciting features already implemented and the decision to include Xen is just another one of them. My only real concern is whether or not they’re going to introduce too much too fast and cause instability. I think though that once the developers get to a point where they’re happy with the feature set of this kernel series that they can then direct their focus and resources to stabilizing the kernel and squashing those nasty little annoying bugs.
You know, I don’t agree with that. Now, I’m a *nix user (BSD mainly) and I do not believe that the 2.6 series, which is labelled STABLE should be introducing such new features like this so quickly. I mean, yes this is a very neat feature to incorporate into the kernel, but if it is labelled stable, then that’s not something that should be happneing. This is one of the few problems I have with Linux, and I’m sure I’m not alone on that.
FYI, This is not a troll, I’m a supporter of Linux, I’m just pointing out some things.
Where were you for the last couple months of discussion about the new development model? It was a (hard fought) consensus that new features needed to go into 2.(k) model instead of gathering dust in 2.(k+1) for a year. Browse by kerneltrap.org more often to keep up on this debates and semantics.
Is widespread use of XEN by IBM’s competitors going to weaken the introduction of the leading edge features of the IBM eSeries OpenPower line? (e tu Brute, OSDL?)
The OpenPower system (the 720 and 710) glossies mention LPAR, Dynamic LPAR, and Micro-Partitioning as features. With the 2.6.11 kernel, will any x86 box vendor be able to offer similar, if minimal, functionality? (Minus the virtual I/O.)
I’d wonder about SUN’s stuff too, if they weren’t doing the sick whale on the beach thing.
How long before Apple upgrades to a CPU with hypervisor instructions in the ISA?
Hypervisor seems like a more elegant solution than the kludges employed by software only solutions. (VMware?)
Fun stuff.
>It was a (hard fought) consensus that new features needed to go into 2.(k) model instead of gathering dust in 2.(k+1) for a year.
And this stupid consensus is the reason, why a lot of people don’t consider Linux 2.6 stable.
IBM is contributing to Xen; I don’t think Xen and Power virtualization has to be an either/or situation.
This is somewhat tangential, but OpenPower is shipping and supported now. RHEL and SLES don’t currently include Xen.
Many hypervisors (including Xen) are software-only, so I don’t think that’s a useful criteria for comparison.
It seems a stretch to say that 2.6 isn’t stable because it keeps gaining features. I’ve been using it since .0, and through to .10 not one release has broken anything that worked before.
You don’t have to use the new things, the kernel is still basically the same deal throughout the series.
It doesn’t imply being bugfree or reliable. Linux in the 2.6 series isn’t stable anymore, but big deal, it is reliable and bugs are being fixed as always.
If a dynamic development model is not someones cup of tea, there are always other avenues with more traditional development models.
And this stupid consensus is the reason, why a lot of people don’t consider Linux 2.6 stable.
So? There’s always 2.4, or even (gasp!) 2.2, if they want “stable”, whatever that might mean. I don’t understand why you’re upset?! 🙂
-fooks
> You know, I don’t agree with that. Now, I’m a *nix user (BSD mainly) and I do not believe that the 2.6 series, which is labelled STABLE should be introducing such new features like this so quickly. I mean, yes this is a very neat feature to incorporate into the kernel, but if it is labelled stable, then that’s not something that should be happneing. This is one of the few problems I have with Linux, and I’m sure I’m not alone on that.
You didn’t think that through before posting.
You may not have noticed, but the kernel is modular. Don’t trust a particular subsystem to be stable yet? Don’t compile that support into the kernel you’re running, and you’re set.
Ever 2.6 version introduced seems to be more stable. This is probably because I’m a laptop user and each version introduces some nice, needed, features however. Even so I use Linux on the desktop and would call each upgrade an improvement since the newer features are appreciated over whatever bugs that may be introduced (I sure haven’t noticed any bugs). YMMV.
I don’t see a problem with the new development model. If you don’t like all this “major instability” stick with your distro’s kernel and leave it alone. For instance, I found the vanilla 2.6.8.1 kernel (compiled on SUSE 9.1) very unstable (although I may have messed up compiling). However, on Ubuntu Warty which I now use, the kernel is currently 2.6.8.1 with security fixes and bug fixes backported from later versions, without the new features, and it is very stable.
So, stick with the distro kernels and don’t always compile the latest kernel if you don’t think it is stable. Or, toss Slackware or Debian Testing on your computer and use kernel 2.4.
What a good news (not only for Xen, but for the new way they want to release source code 🙂 ) !
I pretty much support everything Linus and Andrew have done, and i’m only wondering this:
I’ve been on the Xen mailing list for a long time now and I haven’t seen a whole lot of movement on the X86_64 for AMD, before you all flame that part, there is a diff. group working on the x86_64EMT that is why i said “AMD”. Maybe i missed an e-mail or that is something that would hold them from dropping this in the kernel.
Fedora, It’s been in Rawhide for sometime now:
# yum list | grep xen
kernel-xen0.i686 2.6.10-1.1125_FC4 development
kernel-xen0-devel.i686 2.6.10-1.1125_FC4 development
kernel-xenU.i686 2.6.10-1.1125_FC4 development
kernel-xenU-devel.i686 2.6.10-1.1125_FC4 development
xen.i386 2-20050201.1 development
xen-debuginfo.i386 2-20050201.1 development
# yum info xen
Name : xen
Arch : i386
Version: 2
Release: 20050201.1
Size : 1.1 M
Repo : development
Summary: Xen is a virtual machine monitor
Description:
This package contains the Xen hypervisor and Xen tools, needed to
run virtual machines on x86 systems, together with the kernel-xen*
packages. Information on how to use Xen can be found at the Xen
project pages.
Virtualisation can be used to run multiple versions or multiple
Linux distributions on one system, or to test untrusted applications
in a sandboxed environment. Note that the Xen technology is still
in development, and this RPM has received extremely little testing.
Don’t be surprised if this RPM eats your data, drinks your coffee
or makes fun of you in front of your friends.
RHEL 4 will be out the door some time mid-Feb so it wont have it, but maybe and update or 3 away and they might support it or RHEL 5.
Suse/novell Ent 9, dunno. I don’t pay to much attention to them, but I’m sure they would drop it into a update or so down the road.
“You know, I don’t agree with that. Now, I’m a *nix user (BSD mainly) and I do not believe that the 2.6 series, which is labelled STABLE should be introducing such new features like this so quickly. I mean, yes this is a very neat feature to incorporate into the kernel, but if it is labelled stable, then that’s not something that should be happneing. This is one of the few problems I have with Linux, and I’m sure I’m not alone on that.”
This is just how development works in Linux. 2.7 hasn’t been started yet, so if a feature can’t wait a couple of years for the next development cycle, it is added to the current release. You don’t have to use the experimental features in the Linux kernel, as a matter of fact there is a kernel configuration option that will disable all experimental code, so you can use that if you choose to.
I understand the stability issue, but after a recent foray into the FreeBSD world I have to say that it may be stable, but even the “experimental” code in the Linux kernel is more reliable than some of FreeBSD’s “stable” code. IP over firewire in FreeBSD 5.3 (the fwip driver) is completely unstable, and is unusable when connecting to a Mac OS X machine. It is usable for a little while when connected to a Linux machine, but the link still drops out every once in a while. I also tried the much touted GBDE disk encryption driver…. it does not work at all under 5.3. My machine would crash instantly when trying to write a lot of data to a GBDE partition. DM-Crypt, a feature that was introduced to Linux *after* the 2.6.0 release, works perfectly for me.