Date: Mon, 30 Dec 2019 23:48:09 +0000 From: Paul Vixie <paul@redbarn.org> To: virtualization@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: Adding a different type of blockstore to Bhyve Message-ID: <42643725.2GhSzOL8V3@linux-9daj> In-Reply-To: <6e5508d0-4a41-8442-3807-8b9e22bba933@digiware.nl> References: <6e5508d0-4a41-8442-3807-8b9e22bba933@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42643725.2GhSzOL8V3>