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

Hello @mike.potapov , ok that's interesting, it seems that the lack of communication is in the other way, from guest to tapdisk. To try unlock the ring on tapdisk side you can either: send a SIGUSR2 to force the polling of tapdisk: kill -s SIGUSR2 <TAPDISK_PID> . Problem is the polling will start only if the cpu load is low enough. or with gdb, call (void)tapdisk_xenblkif_sched_chkrng(blkif). Same command the polling is doing above but without the cpu load check. Can you confirm one of the method check the ring and unlock it? SMlog is doing a pause/unpause at the moment of the lock or just before? I will investigate on how a event channel could be lost in tapdisk because I trust the kernel to send it and the hypervisor to deliver it.

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.

I went and checked a couple of the factual bits here rather than take them on trust, and the xscontainer one holds up: xscontainer-10.0.4-1.xcpng8.3.noarch.rpm is still sitting in the 8.3 base repo, and back in topic 6845 Olivier said it was meant to be removed at some point, which evidently hasn't happened. The wiki page is the bit I couldn't reproduce. There's no Docker or container page in the current docs that I can find, and nothing matching in the docs repo either, so I might be looking in the wrong place. On the proposal, I'm not the right person to say whether a containers collector fits the agent's scope. Two things I can tell you. xen-guest-agent lives on GitLab rather than GitHub, so the design conversation would need to happen there. And there's no Feeder entry for any of this yet, which surprised me given how far back the requests go; worth putting one up so the votes have somewhere to land. That's my read on where it should go rather than on whether it's a good idea, and someone closer to the agent will correct me if I've sent you the wrong way.

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.