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.