On 16/05/07, Marko Zec <[EMAIL PROTECTED]> 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 <[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.
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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
