That should be it, tks @poddingue

@pierrebrunet This week I only got 500 errors affecting 5 VMs. These 5 VMs were retried at VM-level and one fo these failed again (it failed to backup since I only have set 1 retry). I'm now looking into connection and bandwitdh to B2. I'm only reaching 200 Mbps to B2 with my current ISP so I'll tune concurrency so I reach those 200 Mbps with fewer VMs in parallel, making each single VM transfer faster. Concurrency was set to 8, I'll try with 3 VMs in parallel this weekend. Tks, Pedro

Hi, Any detailed error log could maybe pinpoint the problem

@anthoineb, We checked both SMlog and xensource.log for the two latest incidents on hypervisor 172.30.50.181. There was no VM or storage pause/unpause operation before either stall. The only matching pause/unpause pairs were part of our later forced VM.hard_reboot: 2026-08-19, VM 172.30.52.185: stall confirmed around 20:24; pause at 20:36:37 and unpause at 20:38:12. 2026-08-20, VM 172.30.52.182: stall confirmed around 20:24; pause at 20:30:07 and unpause at 20:31:26. The first related VDI operations in SMlog were also the vdi_deactivate actions initiated by those reboots. Therefore, we do not see a pause/unpause immediately before or at the onset of either lock.

Anyone who is using Commvault to back up VMs please tell me what you are using for credintials since you have to connect directly to a pool? I am looking for a way to backup VMs using Commvault and us AD accounts or OIDC.

Intel needs some special handling to support physical displays with PCI Passthrough; I don't know much of the details, but on "recent" machines, some bits are missing according to : https://lore.kernel.org/all/20260802050824.10554-1-brchuckz@aol.com/

@pierrebrunet I built on the fix_undici_timeout branch and manually ran the metadata backup job 10 times and did NOT get an error. I will stay on this build through the weekend, let the scheduled metadata backups run, and report back on Monday.