Multiple IP Jail's patch for FreeBSD 6.2

[Chris]

On 16/05/07, Marko Zec <zec at icir.org> wrote:
> On Monday 14 May 2007 22:47:57 Andre Oppermann wrote:
> > Julian Elischer wrote:
> > > Bjoern A. Zeeb wrote:
> > >> On Mon, 14 May 2007, Ed Schouten wrote:
> > >>
> > >> Hi,
> > >>
> > >>> * Andre Oppermann <andre at freebsd.org> wrote:
> > >>>>  I'm working on a "light" variant of multi-IPv[46] per jail.  It
> > >>>> doesn't
> > >>>>  create an entirely new network instance per jail and probably
> > >>>> is more suitable for low- to mid-end (virtual) hosting.  In
> > >>>> those cases you normally want the host administrator to
> > >>>> excercise full control over IP address and firewall
> > >>>> configuration of the individual jails.  For high-end stuff where
> > >>>> you offer jail based virtual machines or network and routing
> > >>>> simulations Marco's work is more appropriate.
> > >>>
> > >>> Is there a way for us to colaborate on this? I'd really love to
> > >>> work on this sort of stuff and I think it's really interesting to
> > >>> dig in that sort of code.
> > >>>
> > >>> I already wrote an initial patch which changes the system call
> > >>> and sysctl format of the jail structures which allow you to
> > >>> specify lists of addresses for IPv4 and IPv6.
> > >
> > > talk with Marko Zec about "immunes".
> > >
> > > http://www.tel.fer.hr/zec/vimage/
> > > and http://www.tel.fer.hr/imunes/
> > >
> > > It has a complete virtualized stack for each jail.
> > > ipfw, routing table, divert sockets, sysctls, statistics, netgraph
> > > etc.
> >
> > Like I said there is a place for both approaches and they are
> > complementary.  A couple of hosting ISPs I know do not want to
> > give a full virtualized stack to their customers.  They want to
> > retain full control over the network configuration inside and
> > outside of the jail.  In those (mass-hosting) cases it is done
> > that way to ease support (less stuff users can fumble) and to
> > properly position those products against full virtual machines
> > and dedicated servers.  Something like this: jail < vimage <
> > virtual machine < dedicated server.
>
> You're right we shouldn't look at virtualized stack as a replacement for
> jails.  Every approach has its niche and use.
>
> > > He as a set of patches against 7-current that now implements nearly
> > > all the parts you need. It Will be discussed at the devsummit on
> > > Wed/Thurs and we'll be discussing whether it is suitable for
> > > general inclusion or to be kept as patches. Note, it can be
> > > compiled out, which leaves a pretty much binarily compatible OS, so
> > > I personally would like to see it included.
> >
> > I don't think it is mature enough for inclusion into the upcoming
> > 7.0R.  Not enough integration time.  Food for FreeBSD 8.0.
>
> Even not knowing how far exactly 7.0 is from being frozen and entering
> the release process, I'd agree with your point - the stack
> virtualization prototype for -CURRENT is still far from being ready for
> prime time.  The fact that the patchsets I maintained for 4.11 were
> quite stable is of little significance now, given that the -CURRENT
> prototype is a from-scratch implementation of the same idea but using
> slightly different tricks, and of course the FreeBSD code base has
> evolved tremendeously over the years.  What the prototype does
> demonstrate at this point however, is that the changes can be made to
> optionaly compile, that they should work fine on a multithreaded / SMP
> kernel, and that all this can be accomplished with relatively less
> churn to the existing code compared to what was done in 4.11 days.
> Knowing that I had a machine running a virtualized -CURRENT kernel
> under different kinds of workloads for over a month without a glitch
> might be considered encouranging but nothing spectacular...
>
> OTOH, even if we miss the window for sneaking this into 7.0-R, it would
> be a huge pitty not to at least reserve a few additional fields in
> various kernel structures needed to support stack virtualization.  That
> way it would be possible to maintain a virtualized 7.0-R kernel in a
> separate code branch, which could be used as a snap-in replacement for
> the stock kernel even after API / ABI freeze comes into effect.  This
> would allow us to give people an opportunity to conveniently test and
> play with the new framework on an otherwise production-grade OS, while
> continuing work towards (hopefully) merging of the chages into 8.0 at
> some point.
>
> Cheers,
>
> Marko
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>

Would like to see this in 7.0 considering many of us have been waiting
for such a feature since 4.x days.  There is patches that make this
work with 5.x and 6.x so I have always been puzzled why it hasnt been
commited to the base, clearly enough time to make 7.0 a dream for
desktop users but I see many server side things been pushed aside.
Please make this happen as waiting for 8.0 seems forever.

Chris