Date: Sat, 26 Oct 2013 14:51:21 +0100 From: symbolics@gmx.com To: virtualization@freebsd.org Cc: geom@freebsd.org Subject: Re: Three observations on Bhyve Message-ID: <20131026135121.GA2148@lemon> In-Reply-To: <526B072A.2020400@freebsd.org> References: <20131025143341.GC26481@lemon> <526A8E95.7090808@freebsd.org> <20131025221432.GC26814@lemon> <526B072A.2020400@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <keyword> ada1 Where <keyword> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131026135121.GA2148>