Linux VServer Project has done this for years
Linux VServer Project has done this for years
Posted Dec 6, 2005 6:05 UTC (Tue) by kolyshkin (guest, #34342)In reply to: Linux VServer Project has done this for years by micah
Parent article: The first stable OpenVZ release
UBC is an OpenVZ kernel component which implements VPS' resources accounting and limiting. There is a set of different resources (about 20 of them) for each VPS, and you can set their barrier and limit (can think of it as a soft and hard limit), and see their current usage.
The thing is there are some resources (like kernel memory, or open file descriptors) which are not limited in any other way, so any single VPS can abuse such a resource thus rendering the whole system (which can host hundreds of such VPSs) unusable.
So UBC is used to prevent such abuses (by different means - from returning ENOMEM from a syscall to killing the process that abuses resources), this is an important part of isolation. But this is not its only use.
The other UBC use is to provide guarantees for VPSs.
PS OpenVZ VPS == VServer guest
Posted Dec 6, 2005 7:26 UTC (Tue)
by gvy (guest, #11981)
[Link] (7 responses)
From what I've heard, 2.x is quite capable regarding resource management and provisioning, seems like it quite stacks against Solaris 10 containers.
And it's quite actively forward-ported, I see 2.6.12.4-vs2.0 patch on their site right now. It's critical given such a security bug-ridden kernel as 2.6.x presently is, AFAIR there were at least one local kernel since 2.6.8 (maybe I'm still sleepy though).
Maybe it's worth bothering SWsoft's mgmt regarding some kind of "merger" proposal? I somehow can't deny the thought that the whole OpenVZ thing is some kind of move on their part (perhaps motivated by you, goldhead and friends?) feeling that proprietary technology just loses its relevance here, facing VServer, Xen, and OTOH VMware and maybe even to some degree qemu.
Good luck on doing good things, anyways. Privet vsem :)
Posted Dec 6, 2005 8:33 UTC (Tue)
by kolyshkin (guest, #34342)
[Link] (1 responses)
We compared with 2.0. VServer mostly uses ulimit, which can handle some cases (e.g. limit the number of processes), but is quite far from what is needed (and what UBC can do). As I explained above, we do care of security; among the other things, we backport all the relevant security fixes. Say, in 022stab050 release (see changelog) I can count at least couple of security fixed from mainstream (as well a couple of our own ones). Also, Solar Designer is currently performing an extensive security audit for OpenVZ.
Posted Dec 8, 2005 20:30 UTC (Thu)
by gvy (guest, #11981)
[Link]
Posted Dec 6, 2005 15:59 UTC (Tue)
by micah (guest, #20908)
[Link] (4 responses)
From the mailing list on the subject of the differences:
(will use Z for OpenVZ and S for Linux-VServer)
>> Factors of interest are
Z: the announcement reads "first stable OVZ version"
>> - Debian support,
Z: afaik they are redhat oriented (and recently
Z: no idea
>> - documentation and
Z: no idea
>> - community support,
Z: irc channel and forum/bug tracker
>> - security.
guess both projects are trying to keep high security
Posted Dec 6, 2005 19:00 UTC (Tue)
by kolyshkin (guest, #34342)
[Link] (3 responses)
- stability, 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.
- Debian support, 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. - hardware utilization, We are 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 We have an extensive 100-pages user's guide. Also all utilities has man pages, and there are some short to-the-point howtos on the site and the forum. - community 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. 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.
Posted Dec 7, 2005 12:47 UTC (Wed)
by nnnn (guest, #34393)
[Link] (2 responses)
Are you saying that when these "top-notch security people" find new
That would be the only way for your offering to be more secure
Posted Dec 7, 2005 14:37 UTC (Wed)
by kolyshkin (guest, #34342)
[Link]
Second, as I have already tried to explain by my first comment here, our security can indeed be better than that of vanilla kernel. We achieve this by sticking to older (=more stable) kernel and backporting all the relevant fixes from vanilla and RHEL kernels (currently there are about 200 such patches, not counting driver updates).
So, we fix bugs and security holes, but do not introduce any new ones, that _might_ be coming with newer kernels. This is essentially the same model used by Red Hat Enterprise Linux.
Posted Dec 16, 2005 18:02 UTC (Fri)
by dev (guest, #34359)
[Link]
Posted Dec 6, 2005 16:04 UTC (Tue)
by micah (guest, #20908)
[Link] (1 responses)
Posted Dec 7, 2005 10:23 UTC (Wed)
by kolyshkin (guest, #34342)
[Link]
Token bucket is just an algorithm that can be used in rate limiting (such as traffic shaping etc.), it has almost nothing to do with resource management. The closest analogue to OpenVZ's User Beancounters is VServer's ulimit/rlimit. Still resource management is a very complex topic and I believe it is better implemented in OpenVZ.
Hm, Kirill, did you compare OVZ and VS1.x or 2.x?Linux VServer Project is doing just fine now
did you compare OVZ and VS1.x or 2.x?
Linux VServer Project is doing just fine now
> Also, Solar Designer is currently performing an extensive security audit for OpenVZ.Linux VServer Project is doing just fine now
Sounds interesting. (is it going to get 2.6-ow before usual .20?.. :)
Linux-vserver's 2.6.12.4-vs2.0 is the most recent stable release, there are patches available for 2.6.13 and 2.6.14, but they are not "blessed" as stable (although they contain bugfixes, and are very likely *stable*).Linux VServer Project is doing just fine now
>> - stability,
S: we are at version 2.0.1 (> two years stable releases)
trying to get gentoo support done)
S: L-VS is in sarge (although with older/broken packages), etch and sid
but either using recent packages or compiling the tool
yourself works pretty fine on debian
>> - hardware utilization,
S: support for 90% of all kernel archs at (almost) native
speed (utilization? I'd say 100% if required)
S: the wiki, the L-VS paper(s) and google
S: ML, irc channel (I guess we have excellent support)
and IMHO the security is at least as high as with the
vanilla kernel release ...
Let me comment on these claims.
OpenVZ is doing fine as well ;)
Z: the announcement reads "first stable OVZ version"
S: we are at version 2.0.1 (> two years stable releases)
Z: afaik they are redhat oriented (and recently
trying to get gentoo support done)
S: L-VS is in sarge (although with older/broken packages), etch and sid
but either using recent packages or compiling the tool
yourself works pretty fine on debian
Z: no idea
S: support for 90% of all kernel archs at (almost) native
speed (utilization? I'd say 100% if required)
Z: no idea
S: the wiki, the L-VS paper(s) and google
Z: irc channel and forum/bug tracker
S: ML, irc channel (I guess we have excellent support)
guess both projects are trying to keep high security
and IMHO the security is at least as high as with the
vanilla kernel release ...
OpenVZ is doing fine as well ;)
bugs you are keeping the patches private and not send them back
to the upstream maintainers?
than a vanilla kernel or other package. And it would be quite
bad if true.
First of all, we do always send fixes we have upstream, and external people who do security audit for us are also sending their relevant findings upstream.OpenVZ is doing fine as well ;)
No, we are not hiding security fixes and participate in security@kernel.org.OpenVZ is doing fine as well ;)
But as you can see both OpenVZ and vserver add additional layer inside the kernel and to some extent actually introduce a new security model. And this security model should be review/checked/thinked over. For example, when you have a kernel bug which allows 'root' user to crash your node it is usually ok, since root is a priviledges and trusted user. In OpenVZ/vserver model root is untrusted user. See the difference? Just an example...
It sounds like the OpenVZ concept of UBC is basically identical to the token bucket limits that Linux-vserver has with possible more resource limits (at the cost of being more intrusive).Linux VServer Project has done this for years
Linux VServer Project has done this for years