From eugen at leitl.org Tue Dec 6 07:12:56 2005 From: eugen at leitl.org (Eugen Leitl) Date: Tue Dec 6 07:12:59 2005 Subject: [Users] VServer vs OpenVZ Message-ID: <20051206121256.GC2249@leitl.org> Before I try OpenVZ I would like to hear comments of people who've ran both VServer and OpenVZ, preferrably on the same hardware, on how both compare. Factors of interest are stability, Debian support, hardware utilization, documentation and community support, security. My planned usage is VServers in a hosting setting. -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://openvz.org/pipermail/users/attachments/20051206/0d2a812f/attachment.bin From kir at openvz.org Tue Dec 6 09:17:18 2005 From: kir at openvz.org (Kir Kolyshkin) Date: Tue Dec 6 09:18:55 2005 Subject: [Users] VServer vs OpenVZ In-Reply-To: <20051206121256.GC2249@leitl.org> References: <20051206121256.GC2249@leitl.org> Message-ID: <43959D6E.7030608@openvz.org> My view of subject is definitely biased towards OpenVZ, but still: there are areas where OpenVZ is definitely more developed than VServer. Let me concentrate on three of these. First is stability. By sticking to old (currently 2.6.8) kernel and backporting all the bug fixes, security fixes and hardware driver updates, we make OpenVZ kernel very stable. We do a lot of kernel testing in house, including stress testing. Second is resource management. There are a lot of resources that can be abused from inside VServer guest or OpenVZ VPS, leading to at least DoS; some of those resources are not under control of traditional UNIX means such as ulimit. In OpenVZ we have User Beancounters (UBC for short), which accounts and limits about 20 of such resources (including IPC objects, various kernel buffers etc). Third is virtualized network stack. AFAIK VServer's ngnet is not yet ready for prime time yet, while OpenVZ's venet is here. Without fully virtualized network stack people are experiencing problems like this one: http://www.paul.sladen.org/vserver/archives/200511/0165.html http://www.paul.sladen.org/vserver/archives/200511/0189.html Regards, Kir, OpenVZ project leader Eugen Leitl wrote: >Before I try OpenVZ I would like to hear comments of people >who've ran both VServer and OpenVZ, preferrably on the same >hardware, on how both compare. > >Factors of interest are stability, Debian support, >hardware utilization, documentation and community support, >security. > >My planned usage is VServers in a hosting setting. > > From kir at openvz.org Wed Dec 7 01:05:13 2005 From: kir at openvz.org (Kir Kolyshkin) Date: Wed Dec 7 01:05:24 2005 Subject: [Users] Re: [Vserver] VServer vs OpenVZ In-Reply-To: <20051206154441.GB13912@MAIL.13thfloor.at> References: <20051206122013.GF2249@leitl.org> <20051206154441.GB13912@MAIL.13thfloor.at> Message-ID: <43967B99.6030600@openvz.org> Let me comment on that as well (ccing our users@ mailing list). Sure I'm biased as well :) Herbert Poetzl wrote: >On Tue, Dec 06, 2005 at 01:20:13PM +0100, Eugen Leitl wrote: > > >>Factors of interest are >>- stability, >> >> > > Z: the announcement reads "first stable OVZ version" > > Although this is indeed the first stable OpenVZ release, OpenVZ is essentially Virtuozzo (without its bells and whistles), and Virtuozzo for Linux is available for more than five years already. > S: we are at version 2.0.1 (> two years stable releases) > > > >>- Debian support, >> >> > > Z: afaik they are redhat oriented (and recently > trying to get gentoo support done) > > Certainly you can compile OpenVZ from sources and use it on any Linux distro. And yes, we are a part of Gentoo for about two months already (with all the recent releases making their way into Gentoo in a very timely fashion). Debian is one of our goals (see roadmap ), although personally I am not a Debian expert, still with some help from the Debian community we will make it. > S: L-VS is in sarge (although with older/broken packages) > but either using recent packages or compiling the tool > yourself works pretty fine on debian > > > >>- hardware utilization, >> >> > > Z: no idea > S: support for 90% of all kernel archs at (almost) native > speed (utilization? I'd say 100% if required) > > OpenVZ is supporting x86 (i386), x86_64 (AMD64, EM64T) and ia64 platforms. "Supporting" here means we have enough hardware for all the three platforms, and do an extensive quality testing (functionality, performance and stress tests) and security audit on all of them. It's a pity but we can not provide the same level of support for other platforms than those three. Speaking of specific hardware, we are supporting the same set of hardware that RHEL4 does, achieving this by backporting newer drivers from mainstream, vendors and RHEL4 kernels. There is an official Virtuozzo/OpenVZ HCL . >>- documentation and >> >> > > Z: no idea > S: the wiki, the L-VS paper(s) and google > > There is an extensive 100-pages user's guide (http://openvz.org/documentation/guides/). Also all utilities has man pages, and there are some short to-the-point howtos on the site and the forum. We are working on more stuff, like QoS (User Beancounters/FairScheduler/Disk Quota) paper. > > >>- community support, >> >> > > Z: irc channel and forum/bug tracker > S: ML, irc channel (I guess we have excellent support) > > There is a bug tracking (Bugzilla) and quite an active support forums, also we have mailing lists and IRC channel (#openvz at freenode). We also provide fee-based support for OpenVZ, done by the same excellent team who supports Virtuozzo. > > >>- security. >> >> > > guess both projects are trying to keep high security > and IMHO the security is at least as high as with the > vanilla kernel release ... > > I can definitely say our security is higher than that of vanilla kernel. We achieve that by two means: (1) sticking to older kernel and backporting all the fixes from mainstream and (2) hiring top-rated security specialists to do OpenVZ security audit. Regards, Kir, OpenVZ project leader.