search for: vixdisklib_connectex

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

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

...(1) VDDK hangs for a really long time when using the nbdkit --run option. It specifically hangs for exactly 120 seconds doing: nbdkit: debug: VixDiskLib: Resolve host. 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. It would be fair to deduct 2 minutes from all timings below. (2) VDDK cannot use VixDiskLib_QueryAllocatedBlocks if the disk is opened for writes. It fails with this uninformative error: nbdkit: vddk[1]: error: [NFC ERROR] NfcFssrvrP...

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. > > > >It would be fair to deduct 2 minutes from all timings below. > > > > Is the PID changed because you want to exec from the parent (where > the init is done), but all the other calls are done in the...

...dup ("dummy-vddk: error message"); +} + +void +VixDiskLib_FreeErrorText (char *text) +{ + free (text); +} + +void +VixDiskLib_FreeConnectParams (VixDiskLibConnectParams *params) +{ + /* never called since we don't define optional AllocateConnectParams */ + abort (); +} + +VixError +VixDiskLib_ConnectEx (const VixDiskLibConnectParams *params, + char read_only, + const char *snapshot_ref, + const char *transport_modes, + VixDiskLibConnection *connection) +{ + return VIX_OK; +} + +VixError +VixDiskLib_Open (const Vi...

..., 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. >> > >> >It would be fair to deduct 2 minutes from all timings below. >> > >> >> Is the PID changed because you want to exec from the parent (where >> the init is done), but all the...

...e when using the nbdkit --run > option. > >It specifically hangs for exactly 120 seconds doing: > > nbdkit: debug: VixDiskLib: Resolve host. > >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. > >It would be fair to deduct 2 minutes from all timings below. > Is the PID changed because you want to exec from the parent (where the init is done), but all the other calls are done in the child? Is that the case so that n...

...2>$env(out)" + expect "ssword:" + send "abc\r" + wait +EOF +cat $out + +grep "password=abc$" $out diff --git a/tests/dummy-vddk.c b/tests/dummy-vddk.c index 13be492d..a2377944 100644 --- a/tests/dummy-vddk.c +++ b/tests/dummy-vddk.c @@ -91,6 +91,12 @@ VixDiskLib_ConnectEx (const VixDiskLibConnectParams *params, const char *transport_modes, VixDiskLibConnection *connection) { + /* Used when regression testing password= parameter. */ + if (getenv ("DUMMY_VDDK_PRINT_PASSWORD") && + params->credT...

Probably needs a bit of cleanup, but seems like it is generally the right direction. One thing I've noticed is that the expect test randomly (but rarely) hangs :-( I guess something is racey but I don't know what at the moment. Rich.