Displaying 20 results from an estimated 1000 matches similar to: "[nbdkit PATCH] vddk: Drop support for VDDK 5.1.1"
2020 Apr 03
1
[nbdkit PATCH v2] vddk: Drop support for VDDK 5.1.1
That version depends on libexpat.so but does not ship it, and it
appears that VMware no longer supports it. Since VDDK 5.5.5 (the next
oldest version) dropped support for 32-bit platforms, we can slightly
simplify our code by documenting our minimum supported version.
Signed-off-by: Eric Blake <eblake@redhat.com>
---
v2: scrub for more places to clean up, based on Rich's review of v1
2020 Feb 18
1
Re: [nbdkit PATCH v7 2/2] vddk: Drive library loading from libdir parameter.
On Tue, Feb 18, 2020 at 11:05:11AM -0600, Eric Blake wrote:
> static const char *sonames[] = {
> - /* Prefer the newest library in case multiple exist. */
> + /* Prefer the newest library in case multiple exist. Check two
> + * possible directories: the usual VDDK installation puts .so
> + * files in an arch-specific subdirectory of $libdir (although
> + *
2020 Feb 18
2
[nbdkit PATCH v6] vddk: Add re-exec with altered environment
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
2020 Feb 18
0
Re: [nbdkit PATCH v6] vddk: Add re-exec with altered environment
On Mon, Feb 17, 2020 at 09:34:12PM -0600, Eric Blake wrote:
> 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
2020 Feb 18
0
[nbdkit PATCH v7 2/2] vddk: Drive library loading from libdir parameter.
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’
2020 Feb 13
1
[nbdkit PATCH v3] vddk: Drive library loading from libdir parameter.
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’
2020 Feb 18
4
[nbdkit PATCH v7 0/2] vddk: Drive library loading from libdir 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
2020 Feb 13
2
[PATCH nbdkit 1/2] vddk: Delay loading VDDK until config_complete.
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
2020 Feb 17
2
Re: [nbdkit PATCH v5 4/4] vddk: Drive library loading from libdir parameter.
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
2020 Feb 13
4
[PATCH nbdkit v2 2/3] NOT WORKING: vddk: Drive library loading from libdir parameter.
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
2020 Jun 22
1
Re: [PATCH nbdkit 2/2] vddk: Defer library initialization to .after_fork().
On 6/22/20 10:49 AM, Richard W.M. Jones wrote:
> VDDK creates background threads. fork kills these, resulting in the
s/kills/strands/
> library hanging or failing completely in certain configurations.
> ---
> plugins/vddk/vddk.c | 28 ++++++++++++++++++++++------
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
ACK.
Should we also modify our tests/libvixDiskLib.so
2020 Feb 13
1
Re: [PATCH nbdkit 2/2] vddk: Drive library loading from libdir parameter.
On 2/13/20 8:01 AM, Richard W.M. Jones wrote:
> 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
2020 Feb 17
0
[nbdkit PATCH v5 4/4] vddk: Drive library loading from libdir parameter.
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’
2020 Feb 21
1
Re: alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT?
On Fri, Feb 21, 2020 at 05:02:12PM +0100, Florian Weimer wrote:
> * Richard W. M. Jones:
>
> > On Fri, Feb 21, 2020 at 04:00:30PM +0100, Florian Weimer wrote:
> >> * Richard W. M. Jones:
> >>
> >> > On Fri, Feb 21, 2020 at 01:19:34PM +0100, Florian Weimer wrote:
> >> >> I think what confuses me is that keep talking about a single binary,
2020 Feb 17
0
Re: [nbdkit PATCH v5 4/4] vddk: Drive library loading from libdir parameter.
On 2/17/20 12:17 PM, Richard W.M. Jones wrote:
> 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:
>
>
2020 Feb 21
2
Re: alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT?
On Fri, Feb 21, 2020 at 04:00:30PM +0100, Florian Weimer wrote:
> * Richard W. M. Jones:
>
> > On Fri, Feb 21, 2020 at 01:19:34PM +0100, Florian Weimer wrote:
> >> I think what confuses me is that keep talking about a single binary, but
> >> clearly there is this separate vddk DSO, and there is talk of plugins.
> >> So it seems to me that multiple files are
2020 Jun 02
0
[PATCH nbdkit 4/5] tests: Enhance dummy-vddk.
Make it behave more or less like a real VDDK. Of course it ignores
all parameters passed and emulates a blank disk, but that is
sufficient to do some more realistic testing.
---
plugins/vddk/vddk-stubs.h | 8 ---
tests/dummy-vddk.c | 115 ++++++++++++++++++++++++++++++++++----
2 files changed, 103 insertions(+), 20 deletions(-)
diff --git a/plugins/vddk/vddk-stubs.h
2017 Dec 08
0
[PATCH v2 1/2] v2v: vddk: Switch to using ‘-it vddk’ to specify VDDK as input transport.
Previously the presence of the ‘--vddk <libdir>’ option magically
enabled VDDK mode. However we want to introduce other transports for
VMware conversions so this wasn't a very clean choice.
With this commit you must use ‘-it vddk’ to specify that you want VDDK
as a disk transport. The previous ‘--vddk <libdir>’ option has been
renamed to ‘--vddk-libdir <libdir>’ to be
2020 Feb 13
1
[PATCH nbdkit] NOT WORKING vddk: Use dlmopen to isolate VDDK.
---
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])
2019 Oct 10
1
[PATCH NOT WORKING nbdkit] vddk: Restructure plugin to allow greater parallelism.
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