From owner-freebsd-virtualization@freebsd.org Mon Dec 30 23:48:17 2019 Return-Path: Delivered-To: freebsd-virtualization@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 532711ED35C; Mon, 30 Dec 2019 23:48:17 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47mvJD2NGZz4cr3; Mon, 30 Dec 2019 23:48:11 +0000 (UTC) (envelope-from paul@redbarn.org) Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id DB82EB0591; Mon, 30 Dec 2019 23:48:09 +0000 (UTC) From: Paul Vixie To: virtualization@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: Adding a different type of blockstore to Bhyve Date: Mon, 30 Dec 2019 23:48:09 +0000 Message-ID: <42643725.2GhSzOL8V3@linux-9daj> Organization: none In-Reply-To: <6e5508d0-4a41-8442-3807-8b9e22bba933@digiware.nl> References: <6e5508d0-4a41-8442-3807-8b9e22bba933@digiware.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 47mvJD2NGZz4cr3 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of paul@redbarn.org designates 24.104.150.213 as permitted sender) smtp.mailfrom=paul@redbarn.org X-Spamd-Result: default: False [-1.29 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:24.104.150.0/24]; NEURAL_HAM_LONG(-0.99)[-0.990,0]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[redbarn.org]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[213.150.104.24.list.dnswl.org : 127.0.10.0]; IP_SCORE(-0.01)[country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; CTE_CASE(0.50)[]; ASN(0.00)[asn:33651, ipnet:24.104.150.0/24, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.29 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: Mon, 30 Dec 2019 23:48:17 -0000 On Monday, 30 December 2019 18:06:11 UTC Willem Jan Withagen wrote: > Something like: > bhyve -s 1,virtio-blk,rbd:poolname/imagename[@snapshotname] \ > [:option1=value1[:option2=value2...]] this is approximately how i'd hope to do object-store level ZFS integration, so as to avoid the zvol abstraction. i know you're working on Ceph not ZFS but the concepts and facilities are similar enough to warrant cooperative thinking. > So the questions are: > 1) Is the abstraction of block_backends.{ch} the way to go? > 1.1) And would the extra indirection there be acceptable? > (For network devices it seems no problem) > > 2) Does anybody already have such a framework for blockdevs? > (Otherwise I'll try to morph the net_backends.{ch} > > 3) Other suggestions I need to consider? i think you're hitting an architectural limit, and that the bhyve design team should be thinking about a third way, one which would also solve my own loopback and mmap requirements as i've described variously. what you want to do should not only be possible, it should be clean and performant. -- Paul