For those of you that are observing a difference in the reported transfer size between XO5 and XO6, can you please let us know if the affected backup jobs are performing health checks?

@samuelolavo Hello, Could the fact that this is a local LVM SR on a non-master host be relevant to how make_chain_rw is being handled? Yes, it's indeed what's happening. The check for the SRMaster (for a shared SR it's the master but for a local it's supposed to be done on the host directly) is failing and always saying False. I'll fix this. Thank you for the help

From LINBIT's description, drbd_peerdevice_outofsync_bytes is what one node's bitmap says is still out of sync with one particular peer, while the UpToDate in linstor r l is the state of each node's own disk, so as far as I understand the two aren't measuring the same thing (the resource states are described at https://docs.xcp-ng.org/xostor#drbdlinstor-resource-state). Your table has the 119 GiB on .10 and .14, the two Unused copies, so I'd be curious which peer those series point at; the labels on the metric should say. If I'm reading drbd-utils right, drbdsetup status xcp-volume-6a8544e8-f17f-49c8-b725-54c5e3213ae1 --verbose --statistics on xen01 also prints an out-of-sync figure per peer, but I haven't got an XOSTOR cluster to try it on, so treat that as a (not so educated) guess. Whether a non-zero number between two secondaries means anything is beyond me; @Team-Storage will know.

@carloum70 Are all your hosts properly time sychronized to NTP or chronyc? Check each host for offsets. They need to be really close in time with each other. And what HA heartbeat client setup are you using? As long as you have a quorum, HA should continue to work fine. WHen you get down to two hosts and one cannot communicate with the other is when things get critical (unless running HA-Lizard on a two-host pool).

@JamesG, Yea i ended up having to go with a bare metal ubuntu install + docker containers for everything and have been off to the races, I would still like a hypervisor but unfortunately had to move on. The software stack on these intel's gpus is still maturing but i'm running some pretty impressive models on them and for the money it has been a good investment, hopefully these will gain some popularity and get better support all around. GPU hosting definitely deserves some attention from xcpng. I would buy some licenses for some production use cases but things like this and nested virtualization (completely unrelated but also something i ran into this past week) needs attention.

Just recieved another update from veeam... Regarding the general earlier errors: Warning : Failed to use CBT: [Task e75c4247-2ee1-7b51-088c-b970ace60f3d (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated] Our QA team did hear back from Vates support, who says its tied to a recent bug they've found with blktap calls: https://github.com/xapi-project/blktap/pull/444 Our QA engineer hasn't heard back yet on ETA when it will be pushed out in a general release yet though