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."
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.
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.
The hip way to get your IP. No ads, ever.
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?
I am a viral sig. Please help me spread.
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.