similar to: nbdkit, VDDK, extents, readahead, etc

On Fri, Apr 12, 2019 at 03:52:58PM +0200, Martin Kletzander wrote: > On Thu, Apr 11, 2019 at 06:55:55PM +0100, Richard W.M. Jones wrote: > >This seems to be a bug in VDDK, possibly connected with the fact that > >we fork after initializing VDDK but before doing the > >VixDiskLib_ConnectEx. I suspect it's something to do with the PID > >changing. > > >

On Thu, Apr 11, 2019 at 06:55:55PM +0100, Richard W.M. Jones wrote: >As I've spent really too long today investigating this, I want to >document this in a public email, even though there's nothing really >that interesting here. One thing you find from search for VDD 6.7 / >VixDiskLib_QueryAllocatedBlocks issues with Google is that we must be >one of the very few users out

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

On Fri, Apr 12, 2019 at 04:30:02PM +0100, Richard W.M. Jones wrote: >On Fri, Apr 12, 2019 at 03:52:58PM +0200, Martin Kletzander wrote: >> On Thu, Apr 11, 2019 at 06:55:55PM +0100, Richard W.M. Jones wrote: >> >This seems to be a bug in VDDK, possibly connected with the fact that >> >we fork after initializing VDDK but before doing the >> >VixDiskLib_ConnectEx.

--- configure.ac | 5 +++++ plugins/vddk/vddk.c | 4 ++++ 2 files changed, 9 insertions(+) diff --git a/configure.ac b/configure.ac index d71f06e4..57626a76 100644 --- a/configure.ac +++ b/configure.ac @@ -321,6 +321,11 @@ AC_SEARCH_LIBS([dlsym], [dl dld], [ ]) LIBS="$old_LIBS" +old_LIBS="$LIBS" +LIBS="$LIBS -ldl" +AC_CHECK_FUNCS([dlmopen])

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

Differences from v4: Patch 1 is simplified: I realized that since we already use -rdynamic for nbdkit (after all, we WANT our dlopen()d plugins to be able to call our nbdkit_* exports), it is only a matter of adding dlopen to the set of symbols that we export. With that done, there is no separate shared library needed; our dlopen shim is now part of nbdkit proper, and we don't have to tweak

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 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

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

Couple of fixes to return correct data and one nice-to-have clean-up which is not needed. I just find it nicer to read. Martin Kletzander (3): vddk: Use a separate handle for single-link=true vddk: Do not report hole extents to be zero with single-link=true vddk: Eliminate one needless goto plugins/vddk/vddk.c | 48 +++++++++++++++++++++++++++++++++------------ 1 file changed, 36

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

From: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- plugins/vddk/nbdkit-vddk-plugin.pod | 7 ++++++- plugins/vddk/vddk-structs.h | 1 + plugins/vddk/vddk.c | 10 ++++++++++ 3 files changed, 17 insertions(+), 1 deletion(-) diff --git a/plugins/vddk/nbdkit-vddk-plugin.pod

I have an update on the networking issue: - After the deep dive into the logs of the firewall by customer's security team, it turns out that even though there were some disconnections, the time-stamps do not match. This means that we got the disconnected by something else (ESXi or conversion host perhaps) - As we mentioned in the chat briefly, there could be general keep-alive issues on both

I'm a lot happier with this version: no mucking with dlmopen(). It does add a bit more coupling between nbdkit proper and the vddk plugin (namely, nbdkit now exports a new function that the vddk plugin relies on), but patch 2 adds testsuite coverage of the new function so we shouldn't regress. Patch 1 and 2 are new, patch 3 is unchanged from when Rich posted it in v2, and patch 4 is

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

Being able to programmatically force nbdkit to be less parallel can be useful during testing. I was less sure about patch 3, but if you like it, I'm inclined to instead squash it into patch 1. This patch is written to apply after my NBD_CMD_CACHE work (since I touched the nocache filter); but can be rearranged if we think this series should go in first while that one undergoes any adjustments

Hi Eric: Here's the problem: We have a VMware VDDK file or snapshot. The virtual size of the snapshot is generally much larger than what's allocated. Copying the snapshot using: nbdkit vddk file=foo.vmdk --run 'qemu-img convert $nbd out' is therefore much slower than it could be. (In the real world version of this we're actually copying the source over the network, but

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

Nir, BTW what are you using for performance testing? As far as I can tell it's not possible to make qemu-img convert use multi-conn when connecting to the source (which is going to be a problem if we want to use this stuff in virt-v2v). Instead I've hacked up a copy of this program from libnbd: https://github.com/libguestfs/libnbd/blob/master/examples/threaded-reads-and-writes.c so