On Wed, Aug 05, 2020 at 02:39:44PM +0300, Nir Soffer wrote: > Can we use something like the file plugin? thread pool of workers, > each keeping open vddk handle, and serving requests in parallel from > the same nbd socket?
Yes, but this isn't implemented in the plugins, it's implemented in the server. The server always uses a thread pool, but plugins can opt for more or less concurrency by adjusting the thread model: http://libguestfs.org/nbdkit-plugin.3.html#Threads The file plugin uses PARALLEL: $ nbdkit file --dump-plugin | grep thread max_thread_model=parallel thread_model=parallel The VDDK plugin currently uses SERIALIZE_ALL_REQUESTS: $ nbdkit vddk --dump-plugin | grep thread max_thread_model=serialize_all_requests thread_model=serialize_all_requests The proposal is to use SERIALIZE_REQUESTS, with an extra mutex added by the plugin around VixDiskLib_Open and _Close calls. PARALLEL is not possible. > This is kind of ugly but simple, and it works great for the file > plugin - we get better > performance than qemu-nbd. > > But since we get low throughput even when we have 10 concurrent > handles for 10 different disks, I'm sure this will help, and the > issue may be deeper in vmware. Maybe they intentionally throttle the > clients? The whole server side seems very heavyweight, judging by how long it takes to answer single requests. It might just be poor implementation rather than throttling though. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
