Julian Elischer wrote:
Bjoern A. Zeeb wrote:
On Mon, 14 May 2007, Ed Schouten wrote:
Hi,
* Andre Oppermann <[EMAIL PROTECTED]> 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.
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.
--
Andre
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
