search for: vddk_dump_plugin

...Lib_InitEx", @@ -457,10 +476,6 @@ vddk_get_ready (void) return 0; } -#define vddk_config_help \ - "[file=]<FILENAME> (required) The filename (eg. VMDK file) to serve.\n" \ - "Many optional parameters are supported, see nbdkit-vddk-plugin(3)." - static void vddk_dump_plugin (void) { @@ -959,6 +974,7 @@ static struct nbdkit_plugin plugin = { .magic_config_key = "file", .dump_plugin = vddk_dump_plugin, .get_ready = vddk_get_ready, + .after_fork = vddk_after_fork, .open = vddk_open, .close = vddk_c...

...--- > plugins/vddk/vddk.c | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/plugins/vddk/vddk.c b/plugins/vddk/vddk.c > index c24da96f..5926e181 100644 > --- a/plugins/vddk/vddk.c > +++ b/plugins/vddk/vddk.c > @@ -478,11 +478,18 @@ vddk_dump_plugin (void) > #endif > } > > -/* XXX To really do threading correctly in accordance with the VDDK > - * documentation, we must do all open/close calls from a single > - * thread. This is a huge pain. > +/* The rules on threads and VDDK are here: > + * > https://code.vmware....

...d, see nbdkit-vddk-plugin(3)." static void @@ -901,6 +901,7 @@ static struct nbdkit_plugin plugin = { .config = vddk_config, .config_complete = vddk_config_complete, .config_help = vddk_config_help, + .magic_config_key = "file", .dump_plugin = vddk_dump_plugin, .open = vddk_open, .close = vddk_close, diff --git a/tests/test-vddk.sh b/tests/test-vddk.sh index d99ebf88..6933f716 100755 --- a/tests/test-vddk.sh +++ b/tests/test-vddk.sh @@ -48,8 +48,7 @@ grep ^vddk_default_libdir= test-vddk.out # a load that we know will fail,...

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

...020-August/msg00023.html --- plugins/vddk/vddk.c | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/plugins/vddk/vddk.c b/plugins/vddk/vddk.c index 31e58f66..95e030d4 100644 --- a/plugins/vddk/vddk.c +++ b/plugins/vddk/vddk.c @@ -511,17 +511,29 @@ vddk_dump_plugin (void) #endif } -/* XXX To really do threading correctly in accordance with the VDDK - * documentation, we must do all open/close calls from a single - * thread. This is a huge pain. +/* The rules on threads and VDDK are here: + * https://code.vmware.com/docs/11750/virtual-disk-development-kit...

...es/libguestfs/2020-August/msg00023.html --- plugins/vddk/vddk.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/plugins/vddk/vddk.c b/plugins/vddk/vddk.c index c24da96f..5926e181 100644 --- a/plugins/vddk/vddk.c +++ b/plugins/vddk/vddk.c @@ -478,11 +478,18 @@ vddk_dump_plugin (void) #endif } -/* XXX To really do threading correctly in accordance with the VDDK - * documentation, we must do all open/close calls from a single - * thread. This is a huge pain. +/* The rules on threads and VDDK are here: + * https://code.vmware.com/docs/11750/virtual-disk-development-kit...

In theory this patch depends on this series: https://www.redhat.com/archives/libguestfs/2020-August/msg00021.html In practice I believe they're independent of each other, but the above series makes it easier to test. Rich.

...> static void > @@ -901,6 +901,7 @@ static struct nbdkit_plugin plugin = { > .config = vddk_config, > .config_complete = vddk_config_complete, > .config_help = vddk_config_help, > + .magic_config_key = "file", > .dump_plugin = vddk_dump_plugin, > .open = vddk_open, > .close = vddk_close, > diff --git a/tests/test-vddk.sh b/tests/test-vddk.sh > index d99ebf88..6933f716 100755 > --- a/tests/test-vddk.sh > +++ b/tests/test-vddk.sh > @@ -48,8 +48,7 @@ grep ^vddk_default_libdir= test-vddk.ou...

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

...@@ -901,6 +901,7 @@ static struct nbdkit_plugin plugin = { > > .config = vddk_config, > > .config_complete = vddk_config_complete, > > .config_help = vddk_config_help, > > + .magic_config_key = "file", > > .dump_plugin = vddk_dump_plugin, > > .open = vddk_open, > > .close = vddk_close, > > diff --git a/tests/test-vddk.sh b/tests/test-vddk.sh > > index d99ebf88..6933f716 100755 > > --- a/tests/test-vddk.sh > > +++ b/tests/test-vddk.sh > > @@ -48,8 +48,7 @@ grep...

...nsigned ("pool-max", value, &pool_max) == -1) + return -1; + if (pool_max < 1) + pool_max = 1; + } else if (strcmp (key, "reexeced_") == 0) { /* Special name because it is only for internal use. */ reexeced = (char *)value; @@ -482,20 +490,37 @@ vddk_dump_plugin (void) * https://code.vmware.com/docs/11750/virtual-disk-development-kit-programming-guide/GUID-6BE903E8-DC70-46D9-98E4-E34A2002C2AD.html * * Before nbdkit 1.22 we used SERIALIZE_ALL_REQUESTS. Since nbdkit - * 1.22 we changed this to SERIALIZE_REQUESTS and added a mutex around - * calls to V...

If you have a plugin which either creates background threads itself or uses a library that creates background threads, it turns out you cannot create these in .get_ready (or earlier). The reason is that nbdkit forks when either daemonizing itself or using the --run option, and fork cancels all the background threads in the child process (the daemonized or captive nbdkit). The only good solution

...mp;pool_max) == -1) > + return -1; > + if (pool_max < 1) > + pool_max = 1; > + } > else if (strcmp (key, "reexeced_") == 0) { > /* Special name because it is only for internal use. */ > reexeced = (char *)value; > @@ -482,20 +490,37 @@ vddk_dump_plugin (void) > * > https://code.vmware.com/docs/11750/virtual-disk-development-kit-programming-guide/GUID-6BE903E8-DC70-46D9-98E4-E34A2002C2AD.html > * > * Before nbdkit 1.22 we used SERIALIZE_ALL_REQUESTS. Since nbdkit > - * 1.22 we changed this to SERIALIZE_REQUESTS and added a mu...

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

I like this change. I think we were overloading the config_complete method before to do two different things (complete configuration; do any allocation/housekeeping necessary before we can start serving). The only questions in my mind are whether we want this before 1.18, and whether the name ("get_ready") is a good one. Rich.