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

@probain I assume that you are running XO from sources. What is your current commit? Have you tried updating to the latest source?

@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

@poddingue Thank you!!!