@Danp The backup jobs are Delta Backups. And other than the Health Checks-theory, I don't really have a theory of why the same job would report 28GB transfered in XO5, but 172GB in XO6. The comment about the side panel, is more an emphasis that it is very difficult to read and extract the relevant information from. Whereas in XO5 that information was presented far easier. Both from a readability standpoint, but also accessibility. Where I have a very hard time with being able to focus on elements in XO6... But that is another topic for another day. I'm eagerly hoping for it to mature more. And it is slowly getting better.

@dthenot Thanks. I checked this on the pool master. Interestingly, there is no make_chain_rw entry in /var/log/SMlog on the pool master itself. On the host where the VM and the storage reside, /var/log/SMlog shows the QCOW2 VDI activation reaching make_chain_rw and then failing with: XENAPI_PLUGIN_FAILURE make_chain_rw CommandException Input/output error One detail that may be relevant: this is a local LVM SR. The SR belongs to the host where the VM is running, and that host is not the pool master. The VG for this SR is therefore not present on the pool master. The existing VHD VDIs on the same local LVM SR continue to activate normally; the failure occurs with the new QCOW2 VDI. I also checked dmesg on the host owning the SR and I do not see any corresponding disk/RAID I/O errors at the time of the failure. For reference, Xen Orchestra is built from source and is currently at commit: faf6745471d7b2a00d774d98428873455e9539dc 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?

@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.

@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).

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

@poddingue Thank you!!!