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

I checked my hosts and the clocks all seem to be very close in time, certainly within a second of each other. The one difference is that the host that is often the target for the backups is set to UTC and the other two are set to MST. Clearly an oversight on my part, unless it is purely a display issue. When I ssh into dom0 and use date, those two show MST and the other shows UTC. If that has ever changed, it would most likely have been in the upgrade from 8.2 to 8.3, which I performed on Jan 28. All that said, this body timeout issue happens to me every day on random VMs within my backup. Occasionally a backup will complete with none of these errors on any VM but that's uncommon. All of the failed backups are from VMs or configs on the two MST hosts and are stored on the UTC host. (To be clear, they are also stored elsewhere.) I also have an XO instance on one of the MST hosts that performs delta backups and those have never failed. I don't know if that's because they are delta or if it's because they don't touch the UTC host. The recent failed backups started on 6/26 for my VM full backups and on 6/29 for the config backups. Prior to that the config backups had never had a problem and the full backups had been fine back into February. From February 21 to March 12, I had a smattering of backup failures due to body timeout error for the full backups.

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