From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Fri 27 Feb 2004 - 16:50:17 GMT
On Fri, Feb 27, 2004 at 03:37:23AM -0500, Matt Ayres wrote:
> On Fri, 2004-02-27 at 03:34, Thomas Gelf wrote:
> > Am Fre, den 27.02.2004 schrieb Alex Lyashkov um 09:11:
> > > ? ???, 27.02.2004, ? 10:03, Thomas Gelf ?????:
> > > > is it possible to realize this?
> > > > how much work would it be?
> > > >
> > > > the first part (tun/tap interface == virtual eth0 inside the vserver,
> > > > bridge them to real eth0, allow CAP_NET_ADMIN for the visible interfaces
> > > > only) should be no problem, what about per-context routing/firewalling?
ad TUN/TAP, that is a solution, but you do not want that,
because it would slow down the network implementation
very much (similar to the slowdown UML imposes) and it
isn't required at all ...
latest 2.6 patches of linux-vserver allow private namespaces
and the next step might be to extend this to the network
interface (which could give you the eth0 you want)
> > > >
> > > VServer not have it.
> > that's the reason why I posted this - something like that should be
> > developed. my questions are:
> > - is it realizable?
> > - if not: why not?
> > - how much work would it be?
> FreeVPS (VServer branch) has this, so it is definitely possible. I
> believe it took Alex quite a bit of work, but we could learn from his
> implementation and perhaps improve upon it.
the thing is, currently available FreeVPS patches are
not portable and except for Alexey and Say nobody knows
what they exactly do ...
So 'adapting' FreeVPS network stuff, would be similar
to rewriting it from scratch, unless Alexey or Say break
out and document or explain the network stuff in small
personally I don't think that the FreeVPS network approach
is the best, because it is very intrusive, and in most
cases not required ...
this doesn't mean that I would not accept tested patches
against linux-vserver kernels which add virtualized
> > probably stable vs shouldn't be modified that way, but what about kernel
> > 2.6? a usable networking support is in my opinion an essential
> > requirement for a vserver project - and at the moment the network
> > inside a vserver "works", but there is still no real networking support.
you won't be able to get 'real networking support', because
that would be a security issue in any case ...
just think about manipulating arp/icmp and other stuff ...
but a good start would be to draft up a document (maybe
on the wiki) which describes what abilities and limitations
such a network support for vserver would have ...
> I 100% agree, that's why it's on my wishlist :)
> Matt Ayres <matta_at_tektonic.net>
> Vserver mailing list
Vserver mailing list