Hi,
for several weeks, since 23 June 2026 (see below), I have been experiencing the same issue. XO (from source; daily updated) is running as a VM on the host (updated on the day or day + 1 the patches were released) being backed up.

result	
name	"BodyTimeoutError"
code	"UND_ERR_BODY_TIMEOUT"
message	"Body Timeout Error"
stack	"BodyTimeoutError: Body Timeout Error\n    at FastTimer.onParserTimeout [as _onTimeout] (/opt/xo/xo-builds/xen-orchestra-202607312004/node_modules/undici/lib/dispatcher/client-h1.js:688:28)\n    at Timeout.onTick [as _onTimeout] (/opt/xo/xo-builds/xen-orchestra-202607312004/node_modules/undici/lib/util/timers.js:162:13)\n    at listOnTimeout (node:internal/timers:605:17)\n    at processTimers (node:internal/timers:541:7)"

Configuration	2026-07-31 20:22	2026-07-31 20:22	a few seconds		
Configuration	2026-07-31 20:16	2026-07-31 20:21	5 minutes		
Configuration	2026-07-31 20:09	2026-07-31 20:14	5 minutes		
Configuration	2026-07-31 19:50	2026-07-31 19:55	5 minutes		
Configuration	2026-07-30 20:53	2026-07-30 20:53	a few seconds		
Configuration	2026-07-30 19:50	2026-07-30 19:50	a few seconds		
Configuration	2026-07-29 19:50	2026-07-29 19:50	a few seconds		
Configuration	2026-07-28 20:05	2026-07-28 20:05	a few seconds		
Configuration	2026-07-28 19:50	2026-07-28 19:55	5 minutes		
Configuration	2026-07-27 19:50	2026-07-27 19:50	a few seconds		
Configuration	2026-07-26 20:49	2026-07-26 20:49	a few seconds		
Configuration	2026-07-26 19:50	2026-07-26 19:55	5 minutes		
Configuration	2026-07-25 19:50	2026-07-25 19:50	a few seconds		
Configuration	2026-07-24 19:50	2026-07-24 19:50	a few seconds		
Configuration	2026-07-23 20:48	2026-07-23 20:48	a few seconds		
Configuration	2026-07-23 19:50	2026-07-23 19:55	5 minutes		
Configuration	2026-07-22 19:50	2026-07-22 19:50	a few seconds		
Configuration	2026-07-21 19:50	2026-07-21 19:50	a few seconds		
Configuration	2026-07-20 19:50	2026-07-20 19:50	a few seconds		
Configuration	2026-07-19 19:50	2026-07-19 19:50	a few seconds		
Configuration	2026-07-19 07:47	2026-07-19 07:47	a few seconds		
Configuration	2026-07-18 19:50	2026-07-18 19:50	a few seconds		
Configuration	2026-07-17 19:50	2026-07-17 19:50	a few seconds		
Configuration	2026-07-16 19:50	2026-07-16 19:50	a few seconds		
Configuration	2026-07-15 19:50	2026-07-15 19:50	a few seconds		
Configuration	2026-07-14 19:50	2026-07-14 19:55	6 minutes		
Configuration	2026-07-13 23:03	2026-07-13 23:03	a few seconds		
Configuration	2026-07-13 19:50	2026-07-13 19:55	5 minutes		
Configuration	2026-07-12 19:50	2026-07-12 19:50	a few seconds		
Configuration	2026-07-11 19:50	2026-07-11 19:50	a few seconds		
Configuration	2026-07-10 19:50	2026-07-10 19:50	a few seconds		
Configuration	2026-07-09 19:50	2026-07-09 19:55	5 minutes		
Configuration	2026-07-08 19:50	2026-07-08 19:50	a few seconds		
Configuration	2026-07-07 19:50	2026-07-07 19:55	5 minutes		
Configuration	2026-07-06 19:50	2026-07-06 19:50	a few seconds		
Configuration	2026-07-06 13:34	2026-07-06 13:34	a few seconds		
Configuration	2026-07-05 19:50	2026-07-05 19:55	6 minutes		
Configuration	2026-07-04 19:50	2026-07-04 19:50	a few seconds		
Configuration	2026-07-03 19:50	2026-07-03 19:50	a few seconds		
Configuration	2026-07-02 19:50	2026-07-02 19:50	a few seconds		
Configuration	2026-07-01 19:50	2026-07-01 19:50	a few seconds		
Configuration	2026-07-01 06:28	2026-07-01 06:28	a few seconds		
Configuration	2026-07-01 00:52	2026-07-01 00:57	5 minutes		
Configuration	2026-06-30 19:50	2026-06-30 19:55	5 minutes		
Configuration	2026-06-29 20:23	2026-06-29 20:23	a few seconds		
Configuration	2026-06-29 19:50	2026-06-29 19:55	5 minutes		
Configuration	2026-06-28 19:50	2026-06-28 19:50	a few seconds		
Configuration	2026-06-27 19:50	2026-06-27 19:50	a few seconds		
Configuration	2026-06-26 19:50	2026-06-26 19:50	a few seconds		
Configuration	2026-06-25 19:50	2026-06-25 19:50	a few seconds		
Configuration	2026-06-24 19:50	2026-06-24 19:50	a few seconds		
Configuration	2026-06-24 07:03	2026-06-24 07:03	a few seconds		
Configuration	2026-06-23 19:50	2026-06-23 19:55	5 minutes			

abudef said:

I was thinking more of updating the entire set of the agent and drivers, similar to how XenServer VM Tools for Windows have it implemented. Using a scheduled job, they regularly check whether an update is available, and if so, they carry out the update of both the agent and the drivers themselves.

Hi, how’s it looking regarding a possible automatic update?

@stormi said:

This is not exposed in Xen Orchestra yet.

When will it likely be available in the GUI?

Thank you, @pilow @bastien-nollet , for the explanation. It would certainly be worthwhile to expand the documentation to make it clear how these settings relate to each other and how to use them correctly, perhaps with some practical examples.

Hello,
I have two questions about backups:

• What is the relationship between the “Backup retention” values within the schedule and the values in the “Long-term retention of backups” settings?

• Is it better to use the “Full backup interval” parameter, or to configure a schedule with the “Force full backup” option? For example, one schedule running once daily Mon–Sat, and another schedule running once daily on Sun with the “Force full backup” option?

versus

I have gone through the documentation at https://docs.xen-orchestra.com/backup, but it is still not entirely clear to me. Thank you.

@AlexanderK said:

@abudef this causes some vms not to boot

You mean that when you enable Nested virtualization in the VM settings under the Advanced tab, the VM then fails to boot?

@MajorP93 Overall it works, Windows VMs run more or less reliably, but I wasn’t able to resolve the nested host crashing when starting Debian. That’s why I put the free version of ESXi underneath the nested XCP-ng hosts, and that works reliably.

@MajorP93 Sure I did

You can enable it in the VM configuration simply by clicking a button in Xen Orchestra:

or use this command:
xe vm-param-set platform:nested_virt=true uuid=<VM UUID> mistake here, see below

Nested virtualization doesn’t work very well in Xen. For example, when I set up a small test playground, I had XCP-ng 8.3 as the primary host and another XCP-ng running on it as a nested host. When I then booted Debian 12 on the nested host, it caused the entire nested host to crash and reboot. On the other hand, Windows VMs on the nested host run quite well.

Later, when I was preparing a test lab, I installed ESXi 8.0U3e on a Dell server and then deployed four virtualized XCP-ng 8.3 hosts on top of it. A number of Linux and Windows VMs run on them without any issues.

@gduperrey Of course, the order matters. Now everything seems to be clear.

In my case, I gave the command to shut down all hosts, and the master "made it" first. The other hosts then got "stuck" at this point for a very long time:

EDIT: Apparently waiting for umount:

@gduperrey Restart happens normally, without any noticeable delay, but shutdown takes a long time. Which logs should I specifically check?

(It's not a real issue, but I just needed to move servers in the lab and had to shut them down, so I noticed it.)

Hi, it seems that shutting down the host is taking an extremely long time now. I tried it in two different environments; the shutdown process starts but gets stuck on the splash screen for several minutes before finally completing. There were no active virtual machines on the hosts being shut down.

Does anyone have the possibility to test this in a lab? Thanks!

Hi,
I’m afraid I’ve encountered the same problem:

• Xen Orchestra, commit 0b52a
  

• v6
  

I was thinking more of updating the entire set of the agent and drivers, similar to how XenServer VM Tools for Windows have it implemented. Using a scheduled job, they regularly check whether an update is available, and if so, they carry out the update of both the agent and the drivers themselves.

Can we look forward to automatic updates arriving in the future as well?

@dinhngtu I would prefer some standardized OS information for Windows systems, similar to this info:

Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber, OsArchitecture
      
OsName                                            OsVersion  OsBuildNumber OsArchitecture
------                                            ---------  ------------- --------------
Microsoft Windows Server 2025 Standard Evaluation 10.0.26100 26100         64-bit

@dinhngtu said in XCP-ng Windows PV tools announcements:

@abudef Got it, the agent was not changed since the last version so the build number was not bumped. I'll keep that in mind for the next release.

Hi, the agent still identifies as version 9.0.9065-44. It would be great if it identified with the same version as the drivers, so it would be clear at first glance which version it's running.