I'm not a big fan of proprietary software, and this is an official blog of OpenVZ, not Virtuozzo — so I haven't had any plans to tell you anything about the latter. But there is one subject I really want to share with you: why Virtuozzo is good for OpenVZ.
To begin with, Virtuozzo is a commercial product based on OpenVZ software. It adds some more value: features, GUIs, tools (and there is also Virtuozzo for Windblows). The first version of Virtuozzo was released about 6 years ago, so it is not something new. Virtuozzo costs money, and is used by big corporations for mission-critical applications. Virtuozzo customers expect it to be very stable, fast, bug-free, well documented, etc. And to sell the product successfully, those expectations must be met.
But how can all this be achieved? A lot of approaches are used: from having a top-notch development team to dedicating lots of resources to testing the software. Indeed, the Virtuozzo QA team is quite large (as well as their server farm), and there are quite a few talented people (and high-end servers) working there. Those people are doing all the bad things with the kernel, trying hard to bring it down to its knees. The majority of the tests are automated, and more and more cases are added to the extensive test suite. The general idea is to find each and every bug — and fix it before the software ships to the customer.
So, good for them, but how does that affect OpenVZ? Quite simple: OpenVZ is the core of Virtuozzo, and thus it is tested and exercised in the same manner. Not too many open source projects can boast of having such great testing and as a result such high quality.
I have to admit it: this is exactly where proprietary software helps open source software. Without Virtuozzo, OpenVZ quality would definitely be lower. A dedicated quality assurance team is always needed because it's just not appealing for developers to find a new bugs in their code — they'd rather write some more.
PS Certainly the scope of "why Virtuozzo is good for OpenVZ" is much broader than just quality: for example, OpenVZ is also feature-rich because of the same reasons.
To begin with, Virtuozzo is a commercial product based on OpenVZ software. It adds some more value: features, GUIs, tools (and there is also Virtuozzo for Windblows). The first version of Virtuozzo was released about 6 years ago, so it is not something new. Virtuozzo costs money, and is used by big corporations for mission-critical applications. Virtuozzo customers expect it to be very stable, fast, bug-free, well documented, etc. And to sell the product successfully, those expectations must be met.
But how can all this be achieved? A lot of approaches are used: from having a top-notch development team to dedicating lots of resources to testing the software. Indeed, the Virtuozzo QA team is quite large (as well as their server farm), and there are quite a few talented people (and high-end servers) working there. Those people are doing all the bad things with the kernel, trying hard to bring it down to its knees. The majority of the tests are automated, and more and more cases are added to the extensive test suite. The general idea is to find each and every bug — and fix it before the software ships to the customer.
So, good for them, but how does that affect OpenVZ? Quite simple: OpenVZ is the core of Virtuozzo, and thus it is tested and exercised in the same manner. Not too many open source projects can boast of having such great testing and as a result such high quality.
I have to admit it: this is exactly where proprietary software helps open source software. Without Virtuozzo, OpenVZ quality would definitely be lower. A dedicated quality assurance team is always needed because it's just not appealing for developers to find a new bugs in their code — they'd rather write some more.
PS Certainly the scope of "why Virtuozzo is good for OpenVZ" is much broader than just quality: for example, OpenVZ is also feature-rich because of the same reasons.


Comments
I don't think you necessarily need a commercial Q&A for a successful project, but it doesn't hurt... and is especially helpful if many of your users are like me.
Rick Blundell
Yes, this is exactly one of ways of how OpenVZ benefits from Virtuozzo. If the bug is found, it is fixed in both Virtuozzo and OpenVZ (since there is only one kernel team for both Virtuozzo and OpenVZ).
Naturally! As I said they are the same people — Virtuozzo kernel developers are OpenVZ kernel developers.