similar to: [RFC nbdkit PATCH] server: Allow --run with --vsock

While we are unlikely to change our decision that -e should not control our response to NBD_OPT_LIST (because we intend to add a new callback .extents_list for that), it turns out that it is a lot easier to write: nbdkit -U - -e foo info --run 'nbdsh -u "$uri" -c "print(h.pread(3, 0))"' than it is to write the equivalent: nbdkit -U - info --run 'nbdsh -u

This parameter provided a name for the "default export" -- ie. the one and only export returned to the client by NBD_OPT_LIST. But nbdkit traditionally didn't care what export name the client requested. Since 1.16 plugins have been able to serve different content per export name (and return errors for unknown exports), but the -e option didn't reflect that and only created

On Tue, Jun 25, 2019 at 09:35:11PM -0500, Eric Blake wrote: > The existing --run '$nbd' outputs an older form that differs between > libguestfs and qemu, and which is not always a valid URI. For > historical compatibility, we probably can't change that; but we can > instead add a new '$uri' that outputs a valid URI. Note that the > libguestfs '$nbd' TCP

On platforms which support it (only Linux currently) nbdkit can act as a vsock server. Guests running on the host see a raw NBD socket which it can connect to by opening an AF_VSOCK connection. (Although only libnbd supports this). The current limitations are: * nbdkit can only act as a host (cid == VMADDR_CID_HOST == 2). * There is no access control. Any guest which has vsock enabled can

The existing --run '$nbd' outputs an older form that differs between libguestfs and qemu, and which is not always a valid URI. For historical compatibility, we probably can't change that; but we can instead add a new '$uri' that outputs a valid URI. Note that the libguestfs '$nbd' TCP form is already a valid URI, but that libguestfs still needs to be taught about the

The existing --run '$nbd' outputs an older form that differs between libguestfs and qemu, and which is not always a valid URI. For historical compatibility, we probably can't change that; but we can instead add a new '$uri' that outputs a valid URI. Note that the libguestfs '$nbd' TCP form is already a valid URI (at least, as long as the user isn't exploiting

On 7/21/20 10:10 AM, Richard W.M. Jones wrote: > This parameter provided a name for the "default export" -- ie. the one > and only export returned to the client by NBD_OPT_LIST. But nbdkit > traditionally didn't care what export name the client requested. > Since 1.16 plugins have been able to serve different content per > export name (and return errors for unknown

On Tue, Jul 21, 2020 at 07:51:29PM -0500, Eric Blake wrote: > On 7/21/20 12:46 PM, Eric Blake wrote: > > >>(2) The --run option no longer sets $exportname (to -e) nor puts the > >>     export name into the $uri.  However this was always the wrong > >>     thing to do since export names are per connection, not per server. > >>     Existing --run scripts

On 7/21/20 12:46 PM, Eric Blake wrote: >> (2) The --run option no longer sets $exportname (to -e) nor puts the >>      export name into the $uri.  However this was always the wrong >>      thing to do since export names are per connection, not per server. >>      Existing --run scripts will see $exportname expand to "" which is >>      most likely what they

As shown in the previous patch, plugins may choose to use stdin or stdout during .config. But from .get_ready onwards, well-written plugins shouldn't be needing any further use of stdin/out. We already swapped stdin/out to /dev/null while daemonizing, but did not do do during -f or --run, which leads to some surprising inconsistency when trying to debug a plugin that works in the foreground

As shown in the previous patch, plugins may choose to use stdin or stdout during .config. But from .get_ready onwards, well-written plugins shouldn't be needing any further use of stdin/out. We already swapped stdin/out to /dev/null while daemonizing, but did not do do during -f or --run, which leads to some surprising inconsistency when trying to debug a plugin that works in the foreground

On 10/18/19 10:38 AM, Richard W.M. Jones wrote: > On platforms which support it (only Linux currently) nbdkit can act as > a vsock server. Guests running on the host see a raw NBD socket which > it can connect to by opening an AF_VSOCK connection. (Although only > libnbd supports this). > > The current limitations are: > > * nbdkit can only act as a host (cid ==

Socket activation (aka systemd socket activation) is a simple protocol that lets you pass in an opened, listening socket to a server. Supporting socket activation allows you to use a modern superserver to serve infrequent NBD requests without needing nbdkit to be running the whole time. Although the protocol was invented by systemd, it has been implemented in a few other places, and the protocol

Since v1: - new patch to add uri_quote() - rebase on top of other recent patches needed while auditing shell_quote() - use uri_quote() instead of shell_quote() for producing $uri Eric Blake (2): common/utils: Add uri_quote and tests captive: Support $uri in --run docs/nbdkit-captive.pod | 8 ++- common/utils/utils.h | 1 + common/utils/test-quotes.c | 108

Typing nbdsh --con (the minimum to get an unambiguous prefix for --connect, different from --command) is annoying compared to having a short option. Since it takes a URI as an argument, using -u/--uri is a nicer mnemonic. We still accept --connect for back-compat, and document it in the man page, but omit it from --help as the new spelling is nicer all around. --- Here's what things evolved

Typing nbdsh --con (the minimum to get an unambiguous prefix for --connect, different from --command) is annoying compared to having a short option. Since it takes a URI as an argument, using -u seems like a reasonable mnemonic. --- sh/nbdsh.pod | 6 ++++-- python/nbdsh.py | 2 +- sh/test-context.sh | 8 ++++---- sh/test-pattern.sh | 2 +- 4 files changed, 10 insertions(+), 8

On 7/22/20 4:02 AM, Richard W.M. Jones wrote: >> The more I think about it, the more I disagree with disabling this. >> Or, put another way, I think that the _only_ time -e makes sense is >> _when_ you are using --run. Consider: >> >> nbdkit -U - -e foo info --run 'nbdsh -u $uri -c "print(h.pread(3, 0))"' >> nbdkit -U - -e bar info --run

On Wed, Sep 11, 2019 at 08:48:28AM -0500, Eric Blake wrote: > On 9/11/19 5:40 AM, Richard W.M. Jones wrote: > > Very much a work in progress as there are still many tests using > > qemu-io which are candidates for conversion. > > > > You'll notice at the end of test-full.sh that the new test has some > > duplicated code which looks as if it ought to be

On Tue, Jun 25, 2019 at 02:58:34PM +0200, Martin Kletzander wrote: > Here are few things I found out when using libnbd that might be perfectly fine > or maybe just an oversight, but I wanted to point them out. It's nothing major. > > When running a program with `nbdkit -U - --run ...`, the $nbd parameter gets > expanded to nbd:unix:/path/to/socket. When this string is passed

On Sat, Feb 22, 2020 at 05:11:01AM -0600, Eric Blake wrote: > On 2/22/20 4:37 AM, Richard W.M. Jones wrote: > >Another thing I've been thinking about for some time is splitting > >.config_complete into .config_complete + .get_ready (new name TBD). > >At the moment .config_complete is both the place where we finish > >processing config, and also the last chance we get