@john.c Hey guys, my understanding (based on Googling...and NOT working with your software) is that you've historically used only the NBD/NBDSSL data path as a way to copy data from VMware. Is this correct? I refer to Xen Orchestra.
Over the weekend, I've finished testing the compatibility with Broadcom VCF 9.1.1 (actually, vCenter/ESXi 9.1.1) and have confirmed identical behaviour with the B library and openVDDK (the B one even crashes on AlmaLinux 9 without an additional package).
So all VMware vSphere versions from 6.7 to 9.1 are covered (this would allow you to support VMware customers moving away from 6.7 - and unfortunately there are still people using it).
With OpenVDDK you get HotAdd as well, besides NBD/NBDSSL (your current custom solution) - if you later decide to implement the VDDK HotAdd transport (proxy/worker VM inside the source vCenter, mounting local snapshot disk with datastore-speed reads which are significantly faster than the NBD/NBDSSL transport method - this is a general fact when it comes to VDDK).
Also pay attention to not "choke" the VM Kernel adapter with too many parallel NBD streams (NFC port 902), it has its own limits.
Some performance notes:
Due to VMware's Terms and Conditions (inside VDDK bundles, and I have them all fresh from August 2026, v 7.xxx, 8.xxx. 9.xxx) - users are forbidden to "publish" benchmarking data, so I did not put a lot of that onto my website. But here is some real-world feedback from a few USA/EU companies that were testing it - and the speed gains are significant (I knew this due to my own testing, but it's always good to have 3rd party confirm it) - these below are from different companies and different tooling (Migratkit; Forklift into KubeVirt) - and I have more results, but don't want to share too much due to the evil eyes of B...
[image: image.jpeg]
This is from another company:
[image: image.jpeg]
These are just to scratch your imagination. And it behaves more properly than the B one - no silent failback to NBD on multi-disk VM migrations or short network hiccups, no crashing in certain cases, and much more helpful error/exit messages (identical exit/error codes, but I aimed to give a more informative message so users can more easily troubleshoot their software)
I'm already trying to put this under the umbrella of an open-source foundation (not ASF), but it will take time due to internal processes and, of course, legal reviews, etc.
Happy to share more if anyone is interested, but that would probably be better over a call, etc.
