@christopher-petzel Thank you for testing this! I am also interested in this fix since I encounter this issue from time to time. Unfortunately my testing environment / lab is currently unavailable which is why I wasn't able to compile & deploy this branch myself.

@djingo Hi ! Does all your VMs have guest tools ?

@andriy.sultanov @andriy.sultanov said: @pandusen As Teddy said above, you can't passthrough a PCI bridge, so there's no PCI devices xapi shouldn't omit here. I am not trying to pass through the bridge only the end points. The Intel arc's have 2 end points: The GPU and the Sound device. "xe pci-list" only reveals the GPU, not the sound device. (this works for nvidia and AMD) But "going the xen-cmdline way" shouldn't break anything, that's what xe pci-disable-dom0-access does behind the scenes. What issues did you see? Which steps did you follow? the sound device is available in the lspci list and can be passed through using CLI. But doing so, (using CLI for passtrough) undoes everything done using xe or the passthrough gui in XO. and results in this: https://xcp-ng.org/forum/topic/10609/xcp-ng-8.3-pci-passthrough-issue so yes, its does break something.

From the log you attached, the failure is on session.login_with_password, and XO tries ::1:443 and then 127.0.0.1:443. So it is XO trying to reach a host, not your remote, and whatever address it holds for that host is resolving to loopback. You rebuilt one of the three nodes and you moved XO into Docker, so my guess is the host came back into the pool with a hostname instead of an IP, and that name does not resolve inside the container the way it did for the script install. It would fit the rest too: migration goes host to host over the management address, copying does not, which is why one works and the other doesn't. Could you paste the output of xe host-list params=uuid,name-label,address? I am guessing here, and @Team-XAPI-Network will know much better than me whether resetting that address is the right move.

@pierrebrunet Hi! I'm on vacation now, so sorry for the delay. In the meantime I've been analyzing these issues and it seems these are somewhat expected and still happen with minpartsize set to 100M. My next step is to increase the AWS_MAX_ATTEMPTS from the default 3 attempts to 10. This might reduce the number of failed VMs and avoid the need to retry the full VM backup. From AI research, it seems rclone uses 10 attempts instead of the AWS SDK default. Here are some stats of my weekly full backup to B2: "00 Weekly Full Backblaze" ran xxxx → xxxxx — 34.1 hours total, moving ~2.86 TiB across 89 VMs. Final status: failure (more on that below, because it's misleading) -> this is related to XO reporting the backup as a failure even though the follow up retry succeded which is a known issue. Every one of the 7 first-attempt errors shows attempts: 3 in the SDK metadata — the default budget was exhausted in all cases -> 7 of 89 VMs failed on the initial attempt. Error mix: 5× Backblaze InternalError 500, 1× ECONNRESET, 1× EPIPE The 7 failed first attempts burned ~7.1 hours of cumulative transfer time Even though XO does not expose AWS_MAX_ATTEMPTS parameter I might be able to set it using an environment variable. I'll give a try when I'm back at the office. Tks, Pedro

@benapetr Good news, seems like the latest version for SM will implement vdi_revert which should work nicely with Ceph RBD. The only thing now is to have the newer Ceph kernel drivers in XCP-ng since the current driver is very old... (v12 I believe, we're now at v20, soon v22)