OpenVZ Pushing for Linux Kernel Inclusion 160
RomanianClimber writes to tell us News.com is reporting that SWSoft is trying to get OpenVZ into the Linux kernel. OpenVZ is an operating system level server virtualization solution, built on Linux. From the article: "In
this, it has a major ally: Red Hat, the top seller of the open-source operating system, which plans to add the software to its free Fedora version of Linux for enthusiasts. The companies' move to make OpenVZ partitioning standard in Linux is timely, said Pund-IT analyst Charles King."
OpenVZ? (Score:0, Insightful)
Why is this needed? (Score:5, Insightful)
If this becomes part of the official kernel, then it becomes the kernel maintainer's problem.
If Red Hat comiles it into their distro's kernel, it is Red Hat's problem to maintain.
So if I were the kernel maintainer, I would need a very compelling reason to take on the extra work.
Anyone worried? (Score:5, Insightful)
Now, Virtuozzo is one of their most awesome products, but I still don't feel right about having a company control over a piece of software embedded into a kernel. I have a chilly feeling about what they might do next and about what they're actually gaining by enabling this.
Just my two cents, I'm sure I'll get many replies of people disagreeing.
Hardware support? (Score:5, Insightful)
Re:Xen (Score:5, Insightful)
Essentially, Xen creates a new kernel for each virtual machine instance (or dom-u), while OpenVZ appears to use the same kernel instance for each virtual server. The latter approach seems to have benefits for performance and scalability, but if you discover a kernel bug in an OpenVZ server, all other instances are immediately susceptible, whereas with Xen, only the dom-u you are in is exploited (though if all instances are running the same kernel, you're up the creek). You'd generally need to be able to exploit the dom0 in order to affect all dom-u's.
Obviously, you're right about Xen supporting multiple OSes per instantiation versus OpenVZ.
User Space Linux? (Score:2, Insightful)
-molo
Re:Anyone worried? (Score:5, Insightful)
If Linus merges it into his tree, then how are they the ones that control it? If Redhat merge it into their tree, then how are they the ones that control it?
The whole point of Free Software is that the user is the one in control, not whoever happens to hold the copyright.
You do realise that other companies have lots of code in the kernel already, don't you? This is by no means the first company to push to have their code included in the kernel. SGI contributed XFS. IBM contributed JFS. Namesys contributed ReiserFS and are currently pushing to have Reiser4 included.
Some pretty decent reasons for this off the top of my head are:
Why the FUD?
This would be a REALLY REALLY bad choice. (Score:2, Insightful)
Two really big problems I see are these two.
1) There is many other virtual server projects which do the same thing as OpenVZ. If one is included into the kernel, and the others conflict with eachtother over that, that's really going to complicate the linux world.
2) Multiple projects use vserver software currently in project, or they are developing on one of the many different virtual server project. This would cause problems for every one of those peoples project. Companies could loose lots of money because of a foolish decision like this.
The choice should be up to the user, and they should not be restricted to any one server virtualization project. This would get rid of competition over virtual server projects. If they are going to include this virtual server software, they should include all of the current virtual server projects and make them options. Most of them are probably incompatible with eachother, so the code has to make sure those conflicts do not happen.
Maybe an alternative should be to have a patchset made by the OpenVZ which could be given to linux for each kernel release, and multiple trees could be made. A regular kernel, then alternative virtual server kernels.
To allow this to happen would be something like Xorg saying they will only support Intel video cards from now on. Anyone with anything which doesn't have the intel chipset on their video card which is supported is screwed. Or for the linux kernel to only support AMD processors, it just wouldn't make sence. The foolish decision of OpenVZ to request this above all the other server virtualization projects is an extremely greedy and foolish choice I think.
I hope linus says no, or comes and checks the slashdot comments to read this and then tells them no. I may even have to fire him off an email about this.
While I can understand OpenVZ's side of things, overall this would be an extremely bad decision. I hope this never comes to be, for it will be a very sad day.
As for OpenVZ, Quit with the greed, keep your project as a seperate kernel addon to give a more competitive market.
Re:Why is this needed? (Score:5, Insightful)
It's not that simple: everyone is following the $ (Score:3, Insightful)
Getting your virtualiser into the kernel (or a vendor tree) isn't about control, it's about being in technical pole position to sell copies of their commercial products. Xen might be free, and might have started this all off, but they too have a commercial arm, XenSource, trying to sell Xen Optimizer [xensource.com], presumably as a coda to other products. SWSoft [swsoft.com] have Plesk, HSPComplete, PEM and others. And VMWare has ESX/GSX server. All of their selling would be made easier, and their marketing departments made very happy, if the king of open source projects, Linux, includes parts of their core technology.
While I'm not sure what the critiera are for acceptance into the kernel, I don't think it's going to happen for SWSoft. From an engineering standpoint, their technology is not much different from Linux vserver [linux-vserver.org] which has been around a while to do much the same job and I imagine its invasive kernel changes to keep everything partitioned are just as (un)appealing to kernel maintainers. On the other hand the Xen kernel changes implement a new "architecture", albeit a virtual one, and (last I looked) were only around 150K in size. So I would have thought that the Xen guys have more of a shot at this one because the bulk of their software is maintained outside of the Linux kernel, and seems like the better solution from an engineering standpoint.
But with CPU virtualisation extensions becoming all the rage this year, I think it'll be a while before the best solution shakes itself out engineering-wise: there is still too much vendor "buy-in" for any of these solutions to seem like a good bet for the mainline kernel.
Also NB from the article that SWSoft have made lots of money from selling a modified Linux kernel, and yes for years before OpenVZ they would give out the sources to Virtuozzo licensees. It's not clear to me whether Virtuozzo uses a forked OpenVZ codebase and they are continuing to develop virtuozzo's kernel bits in secret (which would seem like madness on top of running openvz, but that's commerce for you