From owner-freebsd-hackers@FreeBSD.ORG Mon May 14 21:05:27 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 35D1E16A407 for ; Mon, 14 May 2007 21:05:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outK.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5F713C44B for ; Mon, 14 May 2007 21:05:27 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.32) with ESMTP; Mon, 14 May 2007 14:05:26 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 76CB7125A25; Mon, 14 May 2007 14:05:26 -0700 (PDT) Message-ID: <4648CF15.8050304@elischer.org> Date: Mon, 14 May 2007 14:05:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Andre Oppermann References: <45F1C355.8030504@digitaldaemon.com> <20070511075857.GL23313@hoeg.nl> <4644773E.60909@freebsd.org> <20070514141416.GR23313@hoeg.nl> <20070514155727.Y2939@maildrop.int.zabbadoz.net> <4648993A.4060709@elischer.org> <4648CAFD.4020009@freebsd.org> In-Reply-To: <4648CAFD.4020009@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , Ed Schouten , FreeBSD Hackers 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: Mon, 14 May 2007 21:05:27 -0000 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. > >> 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. Actually I am not sure I completely agree. Consider: It is nearly all implemented by macros, which nearly all result in the same or similar code as before when turned off. No-one is suggesting that we turn it on for 7.0. but Having it in earlier will result in more beating on it.. I however do admit that others may not be as daring as I am on this :-) One thing that could be born in mind however is that the various parts of this that have been virtualised could be used by other virtualisation possibilies.. For example it is possible that the places that vimage needs to touch with its macros are the same places that your implementation might be looking at changing.. It is also possible that the jail code could do the same. Possibly having different sets of the same macros could implement a sliding scale of virtualisation, from plain old 'chroot' though to full vimage. I might add that What Marco has now is very functional and that people should kick its tires (tyres) a bit.. the p4 branch is: //projects/vimage/... for those who want to look at it. >