From owner-freebsd-virtualization@FreeBSD.ORG Sat Oct 26 00:05:09 2013 Return-Path: Delivered-To: virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4488EE48 for ; Sat, 26 Oct 2013 00:05:09 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 08A252B5B for ; Sat, 26 Oct 2013 00:05:08 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id 4D94411FD3; Sat, 26 Oct 2013 10:05:01 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BPK86871 (AUTH peterg@ptree32.com.au); Sat, 26 Oct 2013 10:05:00 +1000 Message-ID: <526B072A.2020400@freebsd.org> Date: Fri, 25 Oct 2013 17:04:58 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: symbolics@gmx.com, virtualization@freebsd.org Subject: Re: Three observations on Bhyve References: <20131025143341.GC26481@lemon> <526A8E95.7090808@freebsd.org> <20131025221432.GC26814@lemon> In-Reply-To: <20131025221432.GC26814@lemon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 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, 26 Oct 2013 00:05:09 -0000 >> That's bhyve colliding with GEOM. There was a thread a while back >> about being able to exempt certain block devices from being tasted for >> iSCSI LUN usage - bhyve will probably need something similar. > > Is this different from the kern.geom.notaste sysctl des@ added recently? Yes. I've not tried that, but guessing it could be used as a workaround for something like a zvol-backed image where the zvol is created after the sysctl is set. However, what is really needed is something like a blacklist that can prevent specified devices from being seen by GEOM at all, since the internal structure is only relevant to the guest VM. later, Peter.