From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 13:58:24 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 95E6016A405 for ; Wed, 16 May 2007 13:58:24 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.freebsd.org (Postfix) with ESMTP id 53DFC13C46C for ; Wed, 16 May 2007 13:58:24 +0000 (UTC) (envelope-from chrcoluk@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so178879wxc for ; Wed, 16 May 2007 06:58:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PYdmhcrEaO4SlQm2galC2FZVJSFiG5RLIo3pf/K5yNU5AMT9p5xqhOUnPKd9tgAJFdK1PFPLK2qSM0Z7B4G59juxagSAorNW/oX8cR6c1hfu6Pt2u5cwkIEezgzgaNvNw2tRuUDrgHocBaJWKYUfKJSTygE7rzBJiNm2HxgXkxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ibfVOIlKNWIsRCJEZ6zd3ePp4xoxcfBsPlLw7vdo7yhErFrlW6dGrnv0Mb63D0YPDbJHvq1MjE60I7dEx+BWSgPyZx98Bj5w1uPn1rL03zgftaCIjTLdfABKEQT7LzAVF9HIDJQV1U38z06BfPfnW6BDTZ9XrN9fwd2juc9089I= Received: by 10.90.89.5 with SMTP id m5mr7950288agb.1179322358037; Wed, 16 May 2007 06:32:38 -0700 (PDT) Received: by 10.67.24.16 with HTTP; Wed, 16 May 2007 06:32:37 -0700 (PDT) Message-ID: <3aaaa3a0705160632r4ec0164t8bb8b714fec15426@mail.gmail.com> Date: Wed, 16 May 2007 14:32:37 +0100 From: Chris To: "Marko Zec" In-Reply-To: <200705160604.28402.zec@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45F1C355.8030504@digitaldaemon.com> <4648993A.4060709@elischer.org> <4648CAFD.4020009@freebsd.org> <200705160604.28402.zec@icir.org> Cc: freebsd-hackers@freebsd.org, Ed Schouten , Andre Oppermann , Julian Elischer , "Bjoern A. Zeeb" Subject: Re: Multiple IP Jail's patch for FreeBSD 6.2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2007 13:58:24 -0000 On 16/05/07, Marko Zec 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 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 "freebsd-hackers-unsubscribe@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