Subject: Re: [vserver] vserver git server and misc. thoughts
From: "Daniel Hokka Zakrisson" <daniel@hozac.com>
Date: Tue, 12 Aug 2008 19:35:51 +0200 (CEST)

Martin Fick wrote:
> --- On Tue, 8/12/08, Ed W <lists@wildgooses.com> wrote:
>
>> So does anyone have enough interest and capacity to try and
>> take some small bits of the vserver project and push it upstream?
>> Are there any reasonably uncontroversial bits to get some momentum?
>
>
> Vservers are cool, they provided lots of very nice features and are light weight to
> boot.  However, I personally only use the simplest features of veservers.  I want
and
> use simple (primarily namespace) isolation and do not (yet) use any of the more advanced
> features such as cpu/memory limits...  I suspect that I am not the only one in this
> boat.  I like the simplicity of most of the management features but do not care as
much
> about underlying implementations.  I want a new vserver, I simply give it a name and
an
> IP, done.  Great tools, thanks!
>
> I suspect that much of what it takes to support my mode of operation is already well
> available in the mainline kernel:
> http://delivery.acm.org/10.1145/1410000/1400109/p104-bhattiprolu.pdf?key1=1400109&key2=3909558121&coll=GUIDE&dl=GUIDE&CFID=40226051&CFTOKEN=79653329
> If that is indeed true, then would perhaps a separate approach not be porting vserver
> utilities to these new kernel features?  How far would this approach go, and would
it be
> enough for most of the basic namespace isolation.  While this may conflict with the
goal
> of getting advanced vserver functionality into mainline, it may be what many people
are
> actually looking for?  Could basic vserver support be implemented currently by simply
> patching the utilities to use new system calls?  If not, what about identifying the
> important features to merge to mainline with this objective in mind?

We're adopting the new namespaces/cgroups as soon as they're somewhat vetted for
functionality. Currently, the biggest things missing from a vanilla kernel when compared
to a Linux-VServer kernel are:
- chroot barrier. Guests can escape to the host without much difficulty at all.
- devpts virtualization/isolation. Guest A can access guest B's terminals.
- network isolation. Network virtualization is in mainline, but that's more overhead
maintenance- and CPU-wise, and it currently requires you to disable sysfs.

Those are just some major, rather basic, things off the top of my head.

-- 
Daniel Hokka Zakrisson