From owner-freebsd-jail@FreeBSD.ORG Thu Apr 25 12:13:58 2013 Return-Path: Delivered-To: freebsd-jail@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 072689B4 for ; Thu, 25 Apr 2013 12:13:58 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4131100 for ; Thu, 25 Apr 2013 12:13:57 +0000 (UTC) Received: from mailout-eu.gmx.com ([10.1.101.211]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LmQuq-1V5E2W1iBm-00a0hX for ; Thu, 25 Apr 2013 14:13:50 +0200 Received: (qmail invoked by alias); 25 Apr 2013 12:13:50 -0000 Received: from unknown (EHLO [192.168.44.80]) [5.135.71.96] by mail.gmx.com (mp-eu011) with SMTP; 25 Apr 2013 14:13:50 +0200 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX1+yQJUCdeSy2Orb0J/JGpPOVmiqq6RLvQa/eASh7X N/VKuG1M+Dg/4B Message-ID: <51791DFD.3040209@gmx.com> Date: Thu, 25 Apr 2013 14:13:49 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: zulu Subject: Re: state of the art ? References: <5177B1A4.6060502@free.fr> <1366868448.5178c1e04043f@gpo.cellcontainer.com> In-Reply-To: <1366868448.5178c1e04043f@gpo.cellcontainer.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Laurent Alebarde , "freebsd-jail@freebsd.org" X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 12:13:58 -0000 On 04/25/2013 07:40 AM, zulu wrote: > VNET is supported and there is a "soft" jail restart option which > prevents the "kern/164763: Memory leak in VNET" issue from appearing. This is a really interesting workaround! Yes, ipfw is vnet-capable since a long time and it works as good as the non-virtualized version. Well... except for dummynet which isn't virtualized yet. My point is, VIMAGE is really stable except for: 1) tearing-down a vnet 2) running non-vnet-ready code (pf, dummynet, lagg, ipf etc) Number one is trigged by destroying a jail. Number two is usually triggered *immediately* after trying to use a non-vnet-ready driver. You can avoid these two and if you avoid them it is perfectly stable... Also, I have to say that i like vimage very much so i might be biased:) Just my 2 cents, Nikos