@timemaster5 @dustyarmstrong I published a thread with packages to test, if you have a non production host on which you can test it would be awesome: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers Thanks! Regards, Yann

@steff22 Good news! And thanks a lot for the test! Could you share the guest VM dmesg please? as well as the lspci -n -vvv -s SBDF of the GPU? Also, was it working with the stock xcp-ng packages?

@poddingue said: For the XVA, I'm not aware of release notes for the appliance image itself: it updates itself after import, and the notes that exist are per XO version, in the monthly blog post and the changelog, both linked from https://docs.xen-orchestra.com/getting-started/releases#release-cadence-and-channels . The blog doesn't usually mention the base OS image itself, including things like openssh stuff, os version, server software, kernel, etc.

Glad the ticket sorted it, @jacob.becker, and thanks for coming back to say so. I don't know whether a patch for the stable channel is planned before 6.9 moves there. If someone else on stable lands here with the same Body Timeout Error, opening a ticket like you did seems to be the quickest route for now.

Thanks for opening https://github.com/xcp-ng/xcp/issues/851. I checked an 8.3 lab host with every update applied and it's the same there: tzdata-2024a-1.el7, and nothing newer in the updates or testing repositories. zdump -v America/Winnipeg on that host still has Manitoba falling back to CST on November 1st, so a host set to that zone would show local times an hour off from then on (UTC itself isn't affected). I don't know how the team usually handles tzdata on the CentOS 7 based dom0, so a mention to @Team-OS-Platform-Release might help get #851 looked at before the 31st.

@hrvojer I can't tell for sure without detailed troubleshooting, but your crash reminds me of a bug in XenVbd that was fixed in the XCP-ng 9.1.200 tools (Apr 2026). It's unlikely that updating to an old Xen tools version would help in that case.

If a mount uses the hard mount option, it will lock any process touching it, including unmount during shutdown, if the mount source is unavailable. It is a kernel thing and I believe there is no solution for it at present.