similar to: [PATCH libnbd] nbdfuse: New tool to present a network block device in a FUSE filesystem.

On 10/12/19 9:21 AM, Richard W.M. Jones wrote: > This program allows you to turn a network block device source into a > FUSE filesystem containing a virtual file: > > $ nbdkit memory 128M > $ mkdir mp > $ nbdfuse mp/ramdisk nbd://localhost & > $ ls -l mp > total 0 > -rw-rw-rw-. 1 rjones rjones 134217728 Oct 12 15:09 ramdisk > $ dd

This adds a new API for connecting to AF_VSOCK protocol (https://wiki.qemu.org/Features/VirtioVsock). For example: nbd_connect_vsock (nbd, 2, 10809); There is no test of this feature because it only works between guest and host. You cannot start a server and client on the host and talk between them, which is what we'd need to write a sane test. --- configure.ac | 2 ++

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

This patch is a straightforward refactoring of libnbd?s nbdcopy program, and not very interesting. However I have plans for nbdcopy (see full todo below). I would like to use this utility for virt-v2v as a replacement for ?qemu-img convert?. qemu-img has caused us a series of problems: - change in zeroing behaviour caused a big performance regression - qemu-img reads extents up-front which

I'm pleased to announce the releases of libnbd 1.2 and nbdkit 1.16. These are a high performance Network Block Device (NBD) client library and server. Key features of libnbd: * Synchronous API for ease of use. * Asynchronous API for writing non-blocking, multithreaded clients. You can mix both APIs freely. * High performance. * Minimal dependencies for the basic library. *

This is a series of patches to libnbd and nbdkit adding AF_VSOCK support. On the host side it allows you to start an nbdkit instance which listens on a virtio-vsock socket: $ ./nbdkit -fv --vsock memory 1G ... nbdkit: debug: bound to vsock 2:10809 On the guest side you can then use libnbd to connect to the server: $ ./run nbdsh -c 'h.connect_vsock(2, 10809)' -c

This is a proposal for an NBD to/from file copying tool (not actually written). Obviously this would duplicate functionality which is already available in qemu-img convert. The reasons for writing this tool would be: - to produce a tool which is very focused on the specific needs of virt-v2v and similar migration scenarios - to have a small tool with minimal dependencies - fix some of

Go 1.17 or newer is required to use unsafe.Slice(), which in turn allows us to write a simpler conversion from a C array to a Go object during callbacks. To check if this makes sense, look at https://repology.org/project/go/versions compared to our list in ci/manifest.yml, at the time I made this commit: Alpine 3.15: 1.17.10 AlmaLinux 8: 1.19.10 CentOS Stream 8: 1.20.4 Debian 10: 1.11.6 Debian

On 4/14/23 10:11, Richard W.M. Jones wrote: > On Fri, Apr 14, 2023 at 09:59:53AM +0200, Laszlo Ersek wrote: >> Two of the enum constants that denote command line options are >> inconsistently named with the rest: all identifiers should be >> <purpose>_OPTION, but LONG_OPTIONS and SHORT_OPTIONS (which are supposed >> to list the long and short options) don't

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2172516 v1: https://listman.redhat.com/archives/libguestfs/2023-April/031258.html Please refer to the Notes section in each patch for the v2 updates. BR, Laszlo Laszlo Ersek (3): copy: rename DESTINATION_IS_ZERO_OPTION to TARGET_IS_ZERO_OPTION copy: fix layout of "long_options" table copy: rewrap error message about

On Fri, Apr 14, 2023 at 09:59:53AM +0200, Laszlo Ersek wrote: > Two of the enum constants that denote command line options are > inconsistently named with the rest: all identifiers should be > <purpose>_OPTION, but LONG_OPTIONS and SHORT_OPTIONS (which are supposed > to list the long and short options) don't conform. Rename them. > > Bugzilla:

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2172516 I figured I'd work on the libnbd line wrapping in shorter waves than how long the nbdkit patch series was. Laszlo Laszlo Ersek (4): copy: rename (LONG|SHORT)_OPTIONS to (LONG|SHORT)_OPTIONS_OPTION copy: rename <purpose>_OPTION to OPT_<purpose> copy: fix layout of "long_options" table copy: rewrap

This is a rough-and-ready implementation of nbdinfo --map option, to display the allocation and other metadata of NBD exports. I only tested it lightly against nbdkit. It needs at least some tests. Command like these should work: nbdinfo --map nbd://localhost nbdinfo --map=qemu:dirty-bitmap nbd://localhost Rich.

[I'm quite convinced I wrote this down in an email before, but I cannot find it. Maybe we only talked about it on IRC? Anyway, my apologies if this is a repeat ...] We're planning to add libnbd to RHEL & CentOS 8.x, likely in RHEL AV 8.2 and CentOS 8.2 or 8.3. It would be nice to get some of the new features added upstream since 1.0 was released, such as: - fast zeroing -

On 10/18/19 10:39 AM, Richard W.M. Jones wrote: > This adds a new API for connecting to AF_VSOCK protocol > (https://wiki.qemu.org/Features/VirtioVsock). > > For example: > > nbd_connect_vsock (nbd, 2, 10809); > > There is no test of this feature because it only works between guest > and host. You cannot start a server and client on the host and talk > between

--- info/Makefile.am | 4 + info/info-map-base-allocation-json.sh | 52 ++++++++++ info/info-map-base-allocation.sh | 49 ++++++++++ info/nbdinfo.c | 134 ++++++++++++++++++++++++-- info/nbdinfo.pod | 39 +++++++- 5 files changed, 271 insertions(+), 7 deletions(-) diff --git a/info/Makefile.am b/info/Makefile.am index

This version doesn't crash or cause hung processes or stuck mountpoints, so that's an improvement. Rich.

When we added support for .extents, we had nbdkit unconditionally support structured replies if the client requests them, and the plugin's .can_extents has no impact on what the server advertises. However, while the plugin API doesn't care whether the client requested SR, there are still integration situations where not advertising SR can be useful (such as comparison on what a client does

This changes the proposed API slightly. Previously 'mount-local' generating a 'mounted' event when the filesystem was ready, and from the 'mounted' event you had to effectively do a fork. Now, 'mount-local' just initializes the mountpoint and you have to call 'mount-local-run' to enter the FUSE main loop. Between these calls you can do a fork or whatever

Fixes bugs with JSON output in the previous patch, and adds some tests. Rich.