similar to: ANNOUNCE: nbdkit 1.18 - high performance NBD server

I'm pleased to announce the release of nbdkit 1.22, a high performance plugin-based Network Block Device (NBD) server. https://en.wikipedia.org/wiki/Network_block_device Key features of nbdkit: * Multithreaded NBD server written in C with good performance. * Minimal dependencies for the basic server. * Liberal license (BSD) allows nbdkit to be linked to proprietary libraries or

NBD — Network Block Device — is a protocol for accessing Block Devices (hard disks and disk-like things) over a Network. nbdkit is a toolkit for creating NBD servers. The key features are: * Multithreaded NBD server written in C with good performance. * Minimal dependencies for the basic server. * Liberal license (BSD) allows nbdkit to be linked to proprietary libraries or included in

[Adding the mailing list address back] On Thu, Nov 21, 2019 at 12:44:38PM +0200, Nir Soffer wrote: > On Thu, Nov 21, 2019 at 12:16 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > > > On Wed, Nov 20, 2019 at 06:00:52PM +0200, Nir Soffer wrote: > > > 5. can_zero fails, not sure why (Maybe Richard knows more about this) > > > > > > nbdkit:

This change adds cainfo and capath options to the curl plugin. They refer directly to CURLOPT_CAINFO and CURLOPT_CAPATH, as documented in libcurl. Signed-off-by: Wiktor Gołgowski <wiktor.golgowski@linux.intel.com> --- plugins/curl/curl.c | 16 ++++++++++++++++ plugins/curl/nbdkit-curl-plugin.pod | 9 +++++++++ 2 files changed, 25 insertions(+) diff --git

On Sun, Dec 09, 2018 at 07:11:28PM +0200, Nir Soffer wrote: > I posted this patch for vdsm, adding NBD APIs: > https://gerrit.ovirt.org/c/96079/ Great stuff. What's the minimum version of oVirt which will have this feature and what's the approximate date when we can assume most users of oVirt will have this? I don't have time now to implement the rest but I filed an RFE bug

On Wed, Aug 5, 2020 at 4:28 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Wed, Aug 05, 2020 at 03:40:43PM +0300, Nir Soffer wrote: > > On Wed, Aug 5, 2020 at 2:58 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > > > > > On Wed, Aug 05, 2020 at 02:39:44PM +0300, Nir Soffer wrote: > > > > Can we use something like the file plugin?

On Wed, Aug 05, 2020 at 03:40:43PM +0300, Nir Soffer wrote: > On Wed, Aug 5, 2020 at 2:58 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > > > On Wed, Aug 05, 2020 at 02:39:44PM +0300, Nir Soffer wrote: > > > Can we use something like the file plugin? thread pool of workers, > > > each keeping open vddk handle, and serving requests in parallel from >

On 2/17/20 12:17 PM, Richard W.M. Jones wrote: > Unfortunately this series doesn't work with the real VDDK library :-( > > I see: > > nbdkit: debug: vddk: config_complete > nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 > > Then a little bit later during VDDK initialization it fails with: > >

On 2/22/20 4:37 AM, Richard W.M. Jones wrote: > Eric: > > Did you want to take this one any further? It might be one that we > save for > 1.18: > > https://www.redhat.com/archives/libguestfs/2020-February/thread.html#00206 At this point, I'm thinking save it for post-1.18 (we've already got enough churn on VDDK with LD_LIBRARY_PATH changes). > > Another

On Wed, Aug 05, 2020 at 02:39:44PM +0300, Nir Soffer wrote: > Can we use something like the file plugin? thread pool of workers, > each keeping open vddk handle, and serving requests in parallel from > the same nbd socket? Yes, but this isn't implemented in the plugins, it's implemented in the server. The server always uses a thread pool, but plugins can opt for more or less

We were previously dlopen-ing it in the load() method. This is very early and in particular means that the only possible way to configure where we find the library is through environment variables and not through config parameters. Also it's not necessary as we don't call any functions from the library (such as VixDiskLib_InitEx) until config_complete. This change is neutral refactoring

On Wed, Aug 5, 2020 at 2:58 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Wed, Aug 05, 2020 at 02:39:44PM +0300, Nir Soffer wrote: > > Can we use something like the file plugin? thread pool of workers, > > each keeping open vddk handle, and serving requests in parallel from > > the same nbd socket? > > Yes, but this isn't implemented in the

On Wed, Aug 5, 2020 at 2:15 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > [NB: Adding PUBLIC mailing list because this is upstream discussion] > > On Mon, Aug 03, 2020 at 06:27:04PM +0100, Richard W.M. Jones wrote: > > On Mon, Aug 03, 2020 at 06:03:23PM +0300, Nir Soffer wrote: > > > On Mon, Aug 3, 2020 at 5:47 PM Richard W.M. Jones <rjones@redhat.com>

I'm pleased to announce the release of nbdkit 1.20, a high performance plugin-based Network Block Device (NBD) server. https://en.wikipedia.org/wiki/Network_block_device Key features of nbdkit: * Multithreaded NBD server written in C with good performance. * Minimal dependencies for the basic server. * Liberal license (BSD) allows nbdkit to be linked to proprietary libraries or

I posted this patch for vdsm, adding NBD APIs: https://gerrit.ovirt.org/c/96079/ The main purpose of these APIs are enabling incremental restore, but they also enable a more efficient rhv-upload via NBD, and importing to thin disks, which is not possible with current solution. The same idea can work for KubeVirt or other targets, minimizing specific target code. Here is how rhv-upload can work

On Mon, Apr 15, 2019 at 04:30:47PM +0200, Martin Kletzander wrote: > On Fri, Apr 12, 2019 at 04:30:02PM +0100, Richard W.M. Jones wrote: > > +-- nbdkit monitoring process > > | > > +-- first child = nbdkit > > | > > +-- second child = ‘--run’ command > > > >so when the second child exits, the monitoring process (which is doing > >nothing

[NB: Adding PUBLIC mailing list because this is upstream discussion] On Mon, Aug 03, 2020 at 06:27:04PM +0100, Richard W.M. Jones wrote: > On Mon, Aug 03, 2020 at 06:03:23PM +0300, Nir Soffer wrote: > > On Mon, Aug 3, 2020 at 5:47 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > All this make sense, but when we upload 10 disks we have 10 connections > > but still we

VDDK plugin + --run was broken because of the following sequence of events: (1) After .config_complete, server redirects stdin/stdout to /dev/null. (2) Server then calls vddk_get_ready which reexecs. (3) We restart the server from the top, but with stdin/stdout redirected to /dev/null. So saved_stdin/saved_stdout save /dev/null. (4) run_command is called which "restores"

On Thu, Nov 21, 2019 at 1:39 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > [Adding the mailing list address back] > > On Thu, Nov 21, 2019 at 12:44:38PM +0200, Nir Soffer wrote: > > On Thu, Nov 21, 2019 at 12:16 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > > > > > On Wed, Nov 20, 2019 at 06:00:52PM +0200, Nir Soffer wrote: > >

On Fri, Aug 7, 2020 at 1:54 AM Nir Soffer <nirsof@gmail.com> wrote: > > This is mainly for testing the new parallel python threading model, but > it also an example how to manage multiple connection from a plugin. > > I tested this with local imageio server, serving qcow2 image on local > SSD. > > Start imageio server from imageio source: > > ./ovirt-imageio