About this list Date view Thread view Subject view Author view Attachment view

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Mon 22 Sep 2003 - 20:59:22 BST

On Mon, Sep 22, 2003 at 02:53:23PM -0400, Rik van Riel wrote:
> Hi,
> I'm wondering how much of the 2.4 vserver infrastructure
> is really needed to achieve the same functionality in 2.6.

guess we need some central syscall switch, as proposed
by yourself, and a nice (working) concept for context
creation, manipulation and destruction ...

> I suspect that we need to look at reimplementing some of
> the vserver functionality with other components of the
> kernel, so the vserver patch becomes smaller and could
> even be merged into the main line kernel.

would be nice, although I doubt that it could/will be
merged soon ...

> Ideally vserver would be standard functionality and not
> a separate fork.

agreed, but that is a long way ...

> For the various components of vserver, I could envision
> using these technologies:
> - unbreakable chroot
> --> filesystem namespaces, CLONE_NS, recursive bind mount
> (already in 2.4 and 2.6 kernels, needs userspace helper)

did that some time ago, seemed to work reasonably well,
(see http://www.13thfloor.at/VServer/Virtual/)

> - separated out /proc namespaces
> --> cannot be done yet, needs vserver implementation
> reuse same implementation for selinux ?

maybe separating out some lists will do a major part
of the /proc virtualization, /proc/mount can be done
with the namespace virtualization, resources should be
done by the CKRM, processes will be done by vserver ...

> - firewalling, probably IP address binding
> --> netfilter & selinux framework

I would prefer a virtual network device like that Alex?
does, so you can create it from outside, and configure
it from inside ... where iptables & co do the security
on both sides ...

> - cpu & memory resource use of vservers
> --> CKRM, see http://ckrm.sourceforge.net/

we'll see ...
I currently doubt that class and context fit well

> - network resource use of vservers
> --> reuse normal traffic control infrastructure,
> maybe selinux infrastructure
> - per-vserver disk quota
> --> maybe the selinux people are interested in this too ?
> make this something generic, beyond just vserver

guess this will not make it into selinux, because the
per context tagging of files/dirs is a requirement, but
nobody would do that without good reason.
same goes for the per context disk limits ...

> This leaves one, maybe two, components of vserver that need a
> special vserver specific implementation. The rest can be done
> using already existing or generic-but-still-in-development
> infrastructure.
> Having vserver as small as possible should not only make it
> easier to maintain, but also to get it merged upstream.
> What do you think?

good idea ... 8-)


> Rik
> --
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 22 Sep 2003 - 21:42:02 BST by hypermail 2.1.3