" can't compute delta" & "can't connect through NBD, fall back to stream export" after 2026-07-28

[probain]

@poddingue

Thanks for looking into it further as well.. If there is a hard cap on the amount of NBD connections, then that is very interesting. Because the closest I've ever been able to find regarding this setting, was the general answer of "Try and see what works for you". So if ther is indeed a hard cap, then I would propose that this is limited inside the GUI itself. e.g. if the cap is 8, then don't let the integer exceed 8.

I'm doing increasing increments of the number of connections now. So far I've done 1,2,10. And 10 does seem to be breaking again, but only on some.

Thanks as well for the link. I'm collecting the logs through xen-bugtool --yestoall now. I do wish that something like this is implemented in GUI someday. And I even made a FR feedback on it. Since I really do want to provide good information for the devs. But collecting manually isn't the most convinient way unfortunately.

Logs should be up shortly

[probain]

5 nbd connections went fine.
8 is not.

[olivierlambert]

Happy to read the logs when you can provide them!

[acebmxer]

Just to confirm you are talking about this setting here in the backup job?

If so is this setting supposed to be set to the number of physical nics that can commicate to the backup remote? Or is this more about how many disks at once can be backup over those connections?

Previously had set to 2 or 4. Upped to 6 and see no difference.

[olivierlambert]

Logs are providing interesting results. Discussing internally about it in the next week to see what could be improved about it.

[probain]

@olivierlambert
Happy to hear that they are providing results to be looked at.
If there is anything else I can provide, please don't hesitate to ask. And I'll do my very best to be helpfull

[IgorGlock]

I am not sure if it is the same issue or not.
I doing daily replication from:
4 VMs nvme-1 SR vhd --> nvme-2 SR qcow2
2 VMs nvme-2 SR qcow2 --> nvme-1 SR vhd

That is homelab for testing only.
Xen Orchestra, commit 6a441

Standalone "Host up-to-date!" with latest august updates.

Replication qcow2 --> vhd works as expected.
Replication of vhd --> qcow2 creates daily new replica VM and reports this:

Log: 2026-08-30T18_42_49.945Z - backup NG.json.txt

[IgorGlock]

My reported issue is gone with build 7a187 from sourcecode.

Day before:

tasks	
0	
id	"0mtj9shwq-k2neggnx0sf"
properties	
id	"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeca"
name	"backup VM"
type	"VM"
name_label	"unifi-server"
progress	0
start	1788303601322
status	"success"
warnings	
0	
message	"can't compute delta OpaqueRef:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeee76 from OpaqueRef:aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeee32, fall back to a full"
tasks

Day after:

1	
id	"0mtktio1u-lrexahnlve"
properties	
id	"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeca"
name	"backup VM"
type	"VM"
name_label	"unifi-server"
progress	0
start	1788397201218
status	"success"
tasks	
0	

[probain]

I've since reduced the number of NBD connections to 4. However, I'm actually still seing this happen. I thought it was resolved. But going back to confirm, proved I assumed wrong.

I have therefore uploaded a new bugtools archive from the host server on the link @poddingue sent me earlier.

I hope they can prove helpfull. If you'd like me to do anything else, then I'll happily help out.

Cheers!

[florent]

@probain the first checkc to do are network one :

is there a default backup network on he pool ? if yes the xo will only look at this network

check if :

• the xo can access network(s) with nbd enabled
• the host have an ip on those networks
• are you on ipv4 or v6 ?
• xo can access the ip of the host on the nbd newtork

[jr-m4]

@florent

I'm seing the same behaviour as well.
To answer the questions you're asking for:

XO from source (7a187)

XO is connected to three separate pools. Backups work most of the times. But I've started seeing the same error. However, it seems intermitent. And somwhat random. Since it will generate an error from one VM, but not on another on the same host with the same SR etc etc.

can't compute delta OpaqueRef: <ref>
from OpaqueRef:<ref>, fall back to a full
can't connect through NBD, fall back to stream export
Backup fell back to a full

• There is an assigned backup-network, and it is the same as the management network. With NBD enabled
• XO can access all of the hosts on the management/backup network
• IPv4

[probain]

@florent

No explicit assigned migration or backup network set.

Backups generate errors somewhat randomly. As one VM won't get the "error" one time. But on the next backup run it will. And the third time it might not. This even happens on VMs that are turned off, and therefore shouldn't have any changed bytes between backups.

• Host is reachable from XO
• Network has NBD enabled
• All VMs use VHD
• IPv4
• Backup type is Delta