similar to: [PATCH nbdkit 0/5] vddk: Fix password parameter.

In v7: everything should work now! The re-exec code is slightly simplified, with Rich's suggestion to pass the original LD_LIBRARY_PATH rather than just the prefix being added, and I've now finished wiring up the initial dlopen() check into code that correctly computes the right prefix dir to add to LD_LIBRARY_PATH. Eric Blake (1): vddk: Add re-exec with altered environment Richard

Pure refactoring. Just decouples the complicated reexec code from the rest. --- plugins/vddk/Makefile.am | 2 + plugins/vddk/vddk.h | 42 +++++++++ plugins/vddk/reexec.c | 196 +++++++++++++++++++++++++++++++++++++++ plugins/vddk/vddk.c | 151 ++---------------------------- 4 files changed, 246 insertions(+), 145 deletions(-) diff --git a/plugins/vddk/Makefile.am

Use an extensible buffer (a vector<char>) when reading /proc/self/cmdline. Tidy up some error messages. --- plugins/vddk/reexec.c | 57 ++++++++++++++++++++++++++----------------- 1 file changed, 35 insertions(+), 22 deletions(-) diff --git a/plugins/vddk/reexec.c b/plugins/vddk/reexec.c index 5a5e9844..9641ee8c 100644 --- a/plugins/vddk/reexec.c +++ b/plugins/vddk/reexec.c @@ -48,6

On 6/2/20 7:27 AM, Richard W.M. Jones wrote: > Use an extensible buffer (a vector<char>) when reading > /proc/self/cmdline. > > Tidy up some error messages. > --- > plugins/vddk/reexec.c | 57 ++++++++++++++++++++++++++----------------- > 1 file changed, 35 insertions(+), 22 deletions(-) > > @@ -80,42 +95,40 @@ perform_reexec (const char *env, const char

--- plugins/vddk/vddk.c | 41 +++++++++++++++++++++++++---------------- TODO | 1 - 2 files changed, 25 insertions(+), 17 deletions(-) diff --git a/plugins/vddk/vddk.c b/plugins/vddk/vddk.c index 87c0d146..d1a3015f 100644 --- a/plugins/vddk/vddk.c +++ b/plugins/vddk/vddk.c @@ -51,6 +51,7 @@ #include "isaligned.h" #include "minmax.h" #include

In the next patch, we want to get rid of the requirement for the user to supply LD_LIBRARY_PATH pointing to vddk libs, if we can derive it ourselves from libdir. However, VDDK itself requires LD_LIBRARY_PATH to be set (because it tries to load libraries that in turn depend on a bare library name, which no manner of dlopen() hacking can work around, and implementing la_objsearch() is no better for

I believe this roughly implements Nir's proposal here: https://www.redhat.com/archives/libguestfs/2020-August/msg00028.html Unfortunately it doesn't work for me. It actually slows things down quite a lot, for reasons I don't understand. Note the adjustment of the pool-max parameter and how it affects the total time. The results are quite reproducible. $ ./nbdkit -r -U - vddk

We had a query yesterday about the VDDK plugin and making it actually obey the weird "Multithreading Considerations" rules in the VDDK documentation (https://vdc-download.vmware.com/vmwb-repository/dcr-public/8f96698a-0e7b-4d67-bb6c-d18a1d101540/ef536a47-27cd-481a-90ef-76b38e75353c/vsphere-vddk-671-programming-guide.pdf) This patch is my attempt to implement this. The idea is that the

See this thread: https://www.redhat.com/archives/libguestfs/2020-June/thread.html#00012 This commit also adds a regression test of vddk password=- and password=-FD. --- tests/Makefile.am | 4 ++ plugins/vddk/vddk.h | 1 + plugins/vddk/reexec.c | 43 ++++++++++++- plugins/vddk/vddk.c | 2 +-

This is my second attempt at this. The first version (also not working) was here: https://www.redhat.com/archives/libguestfs/2019-October/msg00062.html In part 1/2 I introduce a new .ready_to_serve plugin method which is called after forking and just before accepting any client connection. The idea would be that plugins could start background threads here. However this doesn't work well in

From: "Richard W.M. Jones" <rjones@redhat.com> Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’

--- common/include/isaligned.h | 11 +++++------ plugins/file/file.c | 4 ++-- plugins/vddk/vddk.c | 8 ++++---- 3 files changed, 11 insertions(+), 12 deletions(-) diff --git a/common/include/isaligned.h b/common/include/isaligned.h index e693820..81ce8a7 100644 --- a/common/include/isaligned.h +++ b/common/include/isaligned.h @@ -36,16 +36,15 @@ #include <assert.h>

This has been broken since we added the reexec code (commit 155af3107292c351d54ed42c732f4a67bb9aa910) because it tried to read the password twice (before and after the reexec) failing the second time because stdin had already been reopened on /dev/null. Virt-v2v used this feature, but I will change virt-v2v instead. --- plugins/vddk/nbdkit-vddk-plugin.pod | 7 +------ plugins/vddk/vddk.c

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"

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: nbdkit: debug: VixDiskLib: Could not load default plugins from

In can_extents we test whether the VDDK function VixDiskLib_QueryAllocatedBlocks works before declaring that extents are supported. This VDDK function can fail in several ways but most notable if the server doesn't support querying extents. In this case VDDK raises an error message through the error_function callback, which we turn into a call to nbdkit_error. In most cases this will cause

On Tue, Jun 02, 2020 at 09:22:49AM -0500, Eric Blake wrote: > On 6/2/20 7:27 AM, Richard W.M. Jones wrote: > >Use an extensible buffer (a vector<char>) when reading > >/proc/self/cmdline. > > > >Tidy up some error messages. > >--- > > plugins/vddk/reexec.c | 57 ++++++++++++++++++++++++++----------------- > > 1 file changed, 35 insertions(+), 22

On 6/2/20 9:33 AM, Richard W.M. Jones wrote: > On Tue, Jun 02, 2020 at 09:22:49AM -0500, Eric Blake wrote: >> On 6/2/20 7:27 AM, Richard W.M. Jones wrote: >>> Use an extensible buffer (a vector<char>) when reading >>> /proc/self/cmdline. >>> >>> Tidy up some error messages. >>> --- >>> plugins/vddk/reexec.c | 57

I couldn't get this to work in the end. This is the latest non-working version. This email documents what doesn't work for the permanent record. The central problem is that VDDK InitEx() appears to dlopen() various of its own plugins. Although I wasn't able to capture exactly what dlopen() command it is running, the plugins cannot be loaded because they rely on the recompiled

Not sure what version we're up to, but this reimplements extents using the new simpler structure described in this thread: https://www.redhat.com/archives/libguestfs/2019-March/msg00077.html I also fixed most of the things that Eric pointed out in the previous review, although I need to go back over his replies and check I've got everything. This needs a bit more testing. However the