From owner-freebsd-geom@FreeBSD.ORG Sat Oct 26 13:51:24 2013 Return-Path: Delivered-To: geom@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 A7B2721B for ; Sat, 26 Oct 2013 13:51:24 +0000 (UTC) (envelope-from symbolics@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 40B272E82 for ; Sat, 26 Oct 2013 13:51:24 +0000 (UTC) Received: from lemon ([80.7.17.14]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LezI3-1W2qyz2Jxv-00qgpR for ; Sat, 26 Oct 2013 15:51:22 +0200 Received: by lemon (Postfix, from userid 1001) id E11F4EB39F; Sat, 26 Oct 2013 14:51:21 +0100 (BST) Date: Sat, 26 Oct 2013 14:51:21 +0100 From: symbolics@gmx.com To: virtualization@freebsd.org Subject: Re: Three observations on Bhyve Message-ID: <20131026135121.GA2148@lemon> References: <20131025143341.GC26481@lemon> <526A8E95.7090808@freebsd.org> <20131025221432.GC26814@lemon> <526B072A.2020400@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <526B072A.2020400@freebsd.org> X-Provags-ID: V03:K0:ilN+1Unb7OFgypFFvYri4dSqjgAtfecpmqiwgiKycxkq7K8yTwj IzQh6PwhG0Ic8xZktFKeweiNKk444300A+X/ovhgndwK0cBt68nQEu0jAdgTFFUSQiXVFzg 693fZUQ8X7MMra+iPSKwG/nqAHeMJVPBsNEhhtOEEwtsVUnNmwiqYRhf7NDjXy4dQCKNCNe UkiVO2KhQdOPWK4Cfu3fg== Cc: geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 13:51:24 -0000 Context: Bhyve guest cannot use disc devices through VirtIO due to interaction with GEOM tasting on the host. On Fri, Oct 25, 2013 at 05:04:58PM -0700, Peter Grehan wrote: > >> 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. I tried this out today. My ada1 device is connected via a eSATA port so I removed it, set the sysctl and plugged it back in. Of course it didn't help as the sysctl disables tasting globally so the /dev/ada1 node doesn't get created either. > 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. I have been looking at the GEOM code and thinking about what sort of interface I would like. I think I want the ability to tell GEOM not to taste beyond a named provider. # geom disk ada1 Where expands to something like 'notaste'. When this command is invoked a flag is set on the provider that prevents further tasting beyond this point and any existing descendent objects are removed. I have a little code for this and I will see if I can make it work in a reasonable way. I'm CC'ing geom@ because I'd like to know if this approach looks sensible. --sym