@tsukraw I think the bottleneck is indeed the tapdisk and smapiv1. We have full 10Gb WDM between nominal and DR site, and get the same transfer speeds as you on CR. [image: 1779779566351-c860aa15-c649-4608-91f9-0cec88645218-image.jpeg]

Update: We just expanded the SR to 2GB. And I'm still getting the same error. Write permissions were verified by creating a vdi on the SR. And that was successfull with no problem.

Hi, This is harmless, you can ignore it

Still, something to fix

@laszlobortel since we are generating the stream sequentially, we though that there wasn't any real world gain. Also, if my understanding is correct using one thread means we will have only one process( + xo + nbdkit-vddk) processes , and we were trying to limit the risk of zombie process locking the disks , which was far too common with the previous code we'll do a quick test to ensure it does not beak anything and propose either a better default of a configuration option note that this will be a concurrency per disk, so VM with a lot of disk will put more pressure on the source

When speaking to our Veeam sources, we were told end of July is the target date for 13.1. That is what we are hoping for as Veeam is an important one for us.