From owner-freebsd-virtualization@FreeBSD.ORG Sat Nov 13 21:15:03 2010 Return-Path: Delivered-To: virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44E27106566B for ; Sat, 13 Nov 2010 21:15:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-29.mx.aerioconnect.net [216.240.47.89]) by mx1.freebsd.org (Postfix) with ESMTP id 24D208FC0C for ; Sat, 13 Nov 2010 21:15:02 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oADKxNkZ019411 for ; Sat, 13 Nov 2010 12:59:23 -0800 X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id E1D3B2D6014 for ; Sat, 13 Nov 2010 12:59:22 -0800 (PST) Message-ID: <4CDEFC2D.4090908@freebsd.org> Date: Sat, 13 Nov 2010 12:59:25 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: virtualization@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Subject: limitations on jail style virtualization X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 21:15:03 -0000 We discussed this at MeetBSD last week and it woudl seem that the next big hurdle for virtualization would seem to be a good concept to allow jails to have virtual versions of various virtual devices.. for example pf has been virtualized (when IS that patch going to get committed?) but pfsync and pflog use special devices in /dev. similarly bpf uses /dev entries but the way they are used means they are still useful. so what happend when a device that is accessed from within a jail creates a cloning device? should it just turn up in the devfs for that jail? and should it be visible in other jails that happen to be sharing the same /dev? I have no preconceived ideas abot this. Just possibilities. should the cloning code work alongside a new devfs feature that would make 'per jail' entries? i.e. tun0 would be a different device depending on what jail you were in looking at the /dev? Julian