for future reference here is the xl dmesg at this point xldmesg.txt

Indeed, it should be detected/reported correctly to avoid losing time finding the problem. Let me ping @julienXOVates

@florent Sorry, missed your previous post. I will return to master and test it (over the weekend). Thank you!

@pkgw Planning an RPU as a whole is a nice idea in theory, but it's inherently designed to co-exist with normal pool management operations (you should still be able to migrate VMs between hosts B and C during it, or start new ones), we are not "pre-booking" memory and other resources for groups of VMs, otherwise it can quickly make the rest of the pool hard to manage while some VM migrations could still be far away. Regarding the narrower case - I'll note this down and see if we can improve things, thank you!

Hardware update: Got a couple M9148 (4 port Matrox DP) and Wavlink WL-UG7500DH (4 port DP/HDMI) in to test. Configured a Win11 Pro VM with the Matrox driver. It broke the VM so severely that I had to re-pave. So, I pulled the card, swapped for a Wavlink and created another Win11 Pro VM - to which I assigned the Wavlink card and loaded their drivers. It works flawlessly. Both HDMI displays I had connected were instantly recognized in Device Manager and available. I then shut it down, created another VM with Mint 22.3 and assigned resources exactly per the Windows machine. Installed the Wavlink Ubuntu driver and DisplayLink. Rebooted. Still only see the XOA virtual (Console) screen regardless if I have the VM's VGA option turned on or not. The evdi driver is running as is the DisplayLink service. Looking at Xorg.0.log, I see EDID returns for the two HDMI monitors connected to the Wavlink card along with that from the virtual screen - but no screens other than the virtual one show in Display. Interesting bit: The GT730 card behaves EXACTLY the same way. Works great under Win11, driver initializes correctly in Mint but no display other than virtual. Going to post something on the DisplayLink support forum but find it odd that two different cards behave the same way in two different OSes.

@itservices Hello, I'm taking this issue from Pierre. Did you perform a full restart of the XCP-ng host since the issue occured ? Or just restarted the toolstask ?

The 2026-05-28 build still being good narrows the window a lot more than "sometime since November". What I keep coming back to is the shape of the failure: 14 out of 15, then 5 out of 6, so it is always exactly one that falls over and never the whole run. I don't know whether that points at a per-VM timeout or at something the last task in a run does differently, and someone on the XO team will read that better than me. @pierrebrunet still needs /var/log/xensource.log from the pool master covering one failed run's window, so even a slice from a job where only one VM failed should be enough.

Thirty to forty seconds of clock drift after a power outage, and then the backup goes through once you fix the time. That could be coincidence, but it might not be. I don't know enough about how the XAPI client handles time skew to say whether it would surface as a BodyTimeoutError rather than an auth or TLS failure, so I could easily be wrong here. If it fails again, could you look at what the host clock is doing before you correct it? @pierrebrunet from the XO team is already on this one, and a second data point either way would tell him whether it's worth pulling on. Thanks for putting the logs on the pastebin, much easier to read that way.