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

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

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.

Hello, The initial issue, non encrypred to encrypted mirroring is now working. The second issue was about general errors when sending backups to S3. I've tried and was able to increase AWS_MAX_ATTEMPTS to 10 but I'm still having errors and VMs that fail the first backup and have to be retried. So these do not seem to be transient errors that can be fixed by increasing AWS_MAX_ATTEMPTS. Thank you, Pedro

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/

Thanks for actually booting one, that's the bit I skipped. -84s versus -10s without console=ttyS0 matches the Ubuntu ratio, and it's the first EL10 number anyone has measured rather than read from the source. That settles the question I left open. A real-world measurement is vastly better than a source-code read, right? Thanks for the backport request, too. Since CentOS Stream sits upstream of RHEL and Rocky, if the backport lands there, it should be the earliest signal that the rest of the family will follow.

Thanks for the feedback.

Veeam scheduled a remote call with me and pulled more log files. Of coarse when we ran the backup job twice in a row both times al vms were successful. Veeam needs to baby sit our backups :). The call was cut short do to internet going down. I have uploaded the logs and waiting to hear back.