Virtualization In Linux Kernel 2.6.20

mcalwell writes with an article about the Kernel-based Virtual Machine (or KVM for short) in the release candidate Linux 2.6.20 kernel. From the article: "[T]he Linux 2.6.20 kernel will include a full virtualization (not para-virtualization) solution. [KVM] is a GPL software project that has been developed and sponsored by Qumranet. In this article we are offering a brief overview of the KVM for Linux as well as offering up in-house performance numbers as we compare KVM to other virtualization solutions such as QEMU Accelerator and Xen."

Comments

Acronym overload

[phoebe]

Couldn't they just try to use a different acronym, how about KbVM?

Re:Oddness in kernel release cycle

[Builder]

That information is outdated really. The main developers decided that we wouldn't have a development kernel anymore, and would instead just develop in the stable tree. Genius! Now we have all the benefits of an unstable API / ABI combined with the benefits of flaky support... Go team!

Mod... Parent... Up

[Builder]

I feel your pain, deeply! A stable API / ABI is absolutely vital for ISV support and the new development model means that you can only get this if you're prepared to pay a large amount of money for your distribution. I don't want to have to pay $1500 for RHEL, but that's the only way I can run an Oracle dev server on a quad box with 16GB ram. The amusing thing is that RHEL is the ONLY piece of software I have to pay for on that machine - our site license gives us free licenses for dev and DR :)

Anyone other than SLES or RHEL is a second class Linux citizen today. Without vendor support you can forget about trying to run a stable Linux kernel anymore. Bring back the old odd / even split!

Re:Mod... Parent... Up

[gmack]

The patches that each comes up with the backport specific security features will be different, if only slightly. The patches that each comes up with to backport a highly requested feature will be slightly different. Over time these slight differences will add up to become real differences between the distros.

Distros should NEVER backport features. That's the whole point of the new development system. If you want a stable kernel stay with the point release your on and just add the security/stabillity patches. If you want new features use a newer kernel.

That right there was the exact problem with the old even/odd split. The time between the two ended up being so great that people/vendors would start backporting features and destabilizing the "stable series" kernel.

Distros forking the kernel has always been an annoyance so it's nothing new either. I've been playing the "wich distro has the drivers I need" game since 2.0.x and it got to the point where I just never use distro kernels anymore I just compile my own and add that to the installer.

quit your FUD, it's getting old

[r00t]

See unistd.h for the stable API. Combined with the SVR4 ELF specification, that gives you a stable ABI. It's been a damn long time since Linux lost an old system call. Old a.out binaries from a dozen years ago still run fine. BTW, outside the kernel even glibc is doing well; the biggest problem has been the C++ library, mainly because the C++ committee kept adding features.

I think your real complaint is that out-of-tree drivers are unsupported. Tough luck. This will never change. I suggest that you get your drivers into the tree, where other people can review them for bugs (afraid of that? embarrased?) and update them as the rest of the kernel changes.