Multiple IP Jail's patch for FreeBSD 6.2

Thu May 17 15:51:19 UTC 2007

On 16/05/07, Marko Zec <zec at icir.org> wrote:
> On Wednesday 16 May 2007 09:32:37 Chris wrote:
> > 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.
>
> I'm not aware of any stack virtualization patches floating around for
> 5.x or 6.x, at least not of anything that I wrote -> I was basically
> frozen in the 4.11 age until say 9-10 months ago...
>
> Marko
>
>
> > Chris
> > _______________________________________________
> > 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"
>
>
>
Yeah probably something else, I also think the reason why they werent
commited because they possibly broke other stuff, but the multi ip was
working.  Thanks again for working on this.

Chris