OpenVZ Pushing for Linux Kernel Inclusion

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."

Comments

OpenVZ?

[Anonymous Coward]

The link is a buzzword-fest and it doesn't seem to have a wikipedia article. Anyone know what OpenVZ is?

Why is this needed?

[Anonymous Coward]

You can compile anything you want into the kernel.

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.

Re:Why is this needed?

[m50d]

The kernel maintainers have as policy that they won't give you a stable source interface, if you want your driver to work well you should get it into the kernel (See Documentation/stable_api_nonsense.txt). That's fair enough, but a policy like that gives them a responsibility to accept things into the kernel.

Anyone worried?

[paulius_g]

Now, I've seen SW-Soft at work numerous reasons and I don't quite agree with their principles of development. Just check out their forums, they have an awesome community of people asking features in their higer end products and they never want to implement those. Instead, they're creating some kinds of "solution" to allow "lower TCO" and "easier management", at an extra cost of course. I've used their software, and it's quite buggy.

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.

Re:Anyone worried?

[Bogtha]

I still don't feel right about having a company control over a piece of software embedded into a kernel.

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.

I have a chilly feeling about what they might do next and about what they're actually gaining by enabling this.

Some pretty decent reasons for this off the top of my head are:

1. They have less maintenance work to do (no updates every time a new kernel comes out).
2. Less hassle for their users.
3. More testers/bugfixers.
4. They gain positive publicity.

Why the FUD?

Hardware support?

[Visaris]

Both Intel and AMD are releasing CPUs which support OS partitioning in hardware this year (2006). Does the OpenVZ project support or have plans to support these hardware features?

Re:Xen

[sakielnorn]

Or am i missing something and are OpenVZ and Xen very different products? (doesn't sound like it) Upside of Xen seems to be the ability to run *bsd and other OS's in guest domains too, no mention of this in OpenVZ

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?

[molo]

How does this benefit over current inclusion of User Space Linux? Does it allow other operating systems a la VMware? Is it platform-agnostic? Any info?

-molo

This would be a REALLY REALLY bad choice.

[namulator]

I myself work on software which uses a VServer modification to the kernel. Although I do see advantages to setting this up so that it's included into the kernel. I see many more problems that this create then the good it would bring through.

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.

It's not that simple: everyone is following the $

[mattbee]

Xen has caused major shifts in business direction for commercial virtualisation companies: VMWare suddenly released their VMWare player in part as an effort to make their "virtual machine file format" the standard one. Look they even want to support virtualisation standards now! SWSoft kicked off OpenVZ for similar motivation: because Xen is a competing solution and (they gamble) that it is going to be better to give away a corresponding part of their "crown jewels" to get more of a market share.

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, presumably as a coda to other products. SWSoft 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 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 :) ).