search for: vddk_error

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

...if (unbuffered) - flags |= VIXDISKLIB_FLAG_OPEN_UNBUFFERED; - - DEBUG_CALL ("VixDiskLib_Open", - "connection, %s, %d, &handle", filename, flags); - err = VixDiskLib_Open (h->connection, filename, flags, &h->handle); - if (err != VIX_OK) { - VDDK_ERROR (err, "VixDiskLib_Open: %s", filename); - goto err2; - } - - nbdkit_debug ("transport mode: %s", - VixDiskLib_GetTransportMode (h->handle)); + h->flags |= VIXDISKLIB_FLAG_OPEN_UNBUFFERED; return h; - err2: - DEBUG_CALL ("VixDiskLib_Disco...

...|= VIXDISKLIB_FLAG_OPEN_UNBUFFERED; > - > - DEBUG_CALL ("VixDiskLib_Open", > - "connection, %s, %d, &handle", filename, flags); > - err = VixDiskLib_Open (h->connection, filename, flags, &h->handle); > - if (err != VIX_OK) { > - VDDK_ERROR (err, "VixDiskLib_Open: %s", filename); > - goto err2; > - } > - > - nbdkit_debug ("transport mode: %s", > - VixDiskLib_GetTransportMode (h->handle)); > + h->flags |= VIXDISKLIB_FLAG_OPEN_UNBUFFERED; > > return h; > >...

...LAG_OPEN_SINGLE_LINK; + + DEBUG_CALL ("VixDiskLib_Open", + "connection, %s, %d, &handle_single_link", filename, flags); + err = VixDiskLib_Open (h->connection, filename, flags, &h->handle_single_link); + if (err != VIX_OK) { + VDDK_ERROR (err, "VixDiskLib_Open: %s", filename); + goto err2; + } + + nbdkit_debug ("transport mode for single_link: %s", + VixDiskLib_GetTransportMode (h->handle_single_link)); + } + return h; err2: @@ -559,6 +573,10 @@ vddk_close (void *ha...

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

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

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

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

...IZE); + err = VixDiskLib_QueryAllocatedBlocks (h->handle, + start_sector, nr_sectors, + VIXDISKLIB_MIN_CHUNK_SIZE, + &block_list); + if (err != VIX_OK) { + VDDK_ERROR (err, "VixDiskLib_QueryAllocatedBlocks"); + return -1; + } + + for (i = 0; i < block_list->numBlocks; ++i) { + uint64_t offset, length; + + offset = block_list->blocks[i].offset * VIXDISKLIB_SECTOR_SIZE; + length = block_list->blocks[i].length * VIXDI...

...ction, /* log function */ &error_function, /* warn function */ &error_function, /* panic function */ - libdir ? : VDDK_LIBDIR, config); + libdir, config); if (err != VIX_OK) { VDDK_ERROR (err, "VixDiskLib_InitEx"); exit (EXIT_FAILURE); diff --git a/tests/test-vddk-real.sh b/tests/test-vddk-real.sh index 9f29dfba..d0ef6cbe 100755 --- a/tests/test-vddk-real.sh +++ b/tests/test-vddk-real.sh @@ -55,22 +55,16 @@ qemu-img create -f vmdk test-vddk-real.vmdk 100M # not tran...

...return -1; + } + } + } + /* For remote connections, check all the parameters have been * passed. Note that VDDK will segfault if parameters that it * expects are NULL (and there's no real way to tell what parameters @@ -347,7 +479,7 @@ vddk_config_complete (void) VDDK_ERROR (err, "VixDiskLib_InitEx"); exit (EXIT_FAILURE); } - init_called = 1; + init_called = true; return 0; } -- 2.24.1

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

I'm not sure exactly which version we're up to, but let's say it's version 4. I'm a lot happier with this version: - all filters have been reviewed and changed where I think that's necessary - can_extents is properly defined and implemented now - NBD protocol is followed - I believe it addresses all previous review points where possible The "only" thing

I want to post this but mainly for discussion and early review. It's not safe for these patches to all go upstream yet (because not all filters have been checked/adjusted), but if any patches were to go upstream then probably 1 & 2 only are safe. File, VDDK, memory and data plugins all work, although I have only done minimal testing on them. The current tests, such as they are, all

This has already been pushed upstream. I am simply posting these here so we have a reference in the mailing list in case we find bugs later (as I'm sure we will - it's a complex patch series). Great thanks to Eric Blake for tireless review on this one. It also seems to have identified a few minor bugs in qemu along the way. Rich.