similar to: [PATCH libnbd 1/2] nbd_connect_tcp: Try to return errno from underlying connect(2) call.

Now that we have implemented systemd socket activation, we can use this to run qemu-nbd in tests. The first patch leaves some dead code around (the -DSERVE_OVER_TCP=1 path). It's possible we might want to use this to test against a putative future NBD server that only supports TCP, but on the other hand maybe we should just remove it. Tests & valgrind still pass for me. Rich.

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 adds new APIs for running a local NBD server and connecting to it using systemd socket activation (instead of stdin/stdout). This includes interop tests against nbdkit and qemu-nbd which I believe are the only NBD servers supporting socket activation. (If we find others then we can add more interop tests in future.) The upstream spec for systemd socket activation is here:

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

The test interop-qemu-nbd-tls-certs frequently fails on slow (32 bit) machines in Fedora Koji. (Is crypto slow on these already overloaded machines?) As we cannot wait for a signal when qemu-nbd is ready start serving, we have to use a sleep. The current sleep is 5 seconds, which is not long enough. Making the sleep longer would work but is inconsiderate for people using faster machines.

If the user calls nbd_kill_subprocess, we shouldn't kill the process again when we close the handle (since the process has likely gone and we might be killing a different process). --- lib/handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/handle.c b/lib/handle.c index 2af25fe..5ad818e 100644 --- a/lib/handle.c +++ b/lib/handle.c @@ -315,6 +315,8 @@

I was a little surprised to find that LIBNBD_TLS_ALLOW worked out of the box, so I had to examine the logs whereupon I saw the magic message ... libnbd: debug: nbd1: nbd_connect_command: server refused TLS (policy), continuing with unencrypted connection I don't believe this path has ever been tested before. It's possible the tests could be improved if they actually checked for this

RFC because this is an API break, but we haven't declared stable API yet. If we like it, I'm working on using libnbd to implement the nbdkit-nbd plugin; knowing whether it is API version 0.1 or 0.2 will be useful. I also dabbled with allowing optional parameters in python, although my OCaml is weak enough that there may be cleaner ways to approach that. Eric Blake (4): api: Add flags

A prior patch highlighted the following leak: when any construction step fails in the parent after fork(), the child process is leaked. We could plug the leak by inserting a new error handling section for killing the child process and reaping it with waitpid(). However, it would raise some new questions (what signal to send, ensure the child not ignore that signal, hope that whatever process

Most of the states were calling SET_NEXT_STATE(%.DEAD) then using return -1 on error, to reflect the fact that they had also called set_error() and wanted the caller to notice the failure. Unfortunately, the state machine engine refuses to run the entry code of the next state when the current state returned -1, which meant the DEAD state entry code never runs. A concrete example of the problems

For commands with long names and/or short descriptors, you can end up going over 72 characters in the first line of the man page (causing podwrapper to complain). Wrap these lines. --- generator/generator | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/generator/generator b/generator/generator index 7d3f656..ad1cb6b 100755 --- a/generator/generator +++ b/generator/generator

One API change, some small documentation changes.

This is slightly redundant with just trying nbd_set_tls(nbd, 2) then checking for failure; however, this function does not set errors and looks more similar to nbd_supports_uri. --- This is borderline enough that I figured I'd post it to check if we want it. generator/generator | 45 ++++++++++++++++++++++++++++++++++++++------- interop/interop.c | 4 ++++ lib/handle.c | 12

nbd_connect_unix|tcp had a tricky failure case. This is a consequence of allowing callers to mix synchronous and asynchronous calls, with multi-conn thrown into the mix. I think the new behaviour proposed here is better. We could do with a better way of classifying the state of connections, such as are they connectING. Rich.

--- p2v/ssh.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/p2v/ssh.c b/p2v/ssh.c index 1e9b05c..ff906df 100644 --- a/p2v/ssh.c +++ b/p2v/ssh.c @@ -505,7 +505,16 @@ open_data_connection (struct config *config, int *local_port, int *remote_port) }, ovector, ovecsize)) { case 100: /* Ephemeral port. */ port_str =

v1: https://www.redhat.com/archives/libguestfs/2019-June/msg00014.html I pushed a few bits which are uncontroversial. The main changes since v1 are: An extra patch removes the want_to_send / check for nbd_aio_is_ready in examples/threaded-reads-and-writes.c. This logic was wrong since commit 6af72b87 as was pointed out by Eric in his review. Comments and structure of

If not using multi-conn then obviously the synchronous connection calls ‘nbd_connect_unix’, ‘nbd_connect_tcp’ and ‘nbd_connect_command’ should only return when the (one) connection object is connected. In the multi-conn case it's not very clear what these synchronous calls should do. Previously I had it so that they would return as soon as at least one connection was connected. However this

Fix and/or document issues raised in this thread: https://www.redhat.com/archives/libguestfs/2017-February/msg00010.html Rich.

If not using multi-conn then obviously the synchronous connection calls ‘nbd_connect_unix’, ‘nbd_connect_tcp’ and ‘nbd_connect_command’ should only return when the (one) connection object is connected. In the multi-conn case it's not very clear what these synchronous calls should do. Previously I had it so that they would return as soon as at least one connection was connected. However this

I would really appreciate help ! I did not have any reply to my two posts and I don't know what to do. I can't build 3.0.21a and I have to migrate 54 Solaris 2.5.1 servers from 2.2.8a to 3.0.x. I'm afraid we could not move to newer solaris versions before 12 or 18 months. Under is the problem description. Thank you for your help. Pierre --------- SOLARIS 7 --------- On Solaris 7