@poddingue Thanks for running the -31 numbers — good to have it confirmed that the ttyS0 removal stays worth ~3-4s even with the clock fixed. Agreed on not rushing -proposed to production; we'll pick up -31 when it promotes and keep the cloud-init tweak permanently.

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

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.

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.

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

Thanks for the feedback.

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/

@poddingue said: What I can't tell you is what set that particular combination on your VM in the first place. Does it ring a bell? I have no Idea. I had it on "Protect from accidental shutdown" but turned that off again, later. Doing this again (on, off) helped, as you said. Thank you so much!

Hi, Any detailed error log could maybe pinpoint the problem

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.

@seanmcg182 's post might be the answer to the original question, two years late. Your lspci -s 0000:05:00.0 -v at post 8 shows (rev ff) and !!! Unknown header type 7f, which is the same pair he had, and in his case it came from bifurcating the wrong PCIe port in the BIOS rather than from anything XCP-ng was doing. He says the unknown header is what then produced the device or resource busy error on VM start, which is the error you opened with. I don't know whether your board exposes bifurcation the way his X10DRH-CT does, so it might not transfer at all. @kuznetcoff777 if that machine is still around, it'd be worth a look either way.

After a good sleep, I resolved half of my issue. I got my LSI Cards messed up, I accidentally hidan internal LSI3108 (Address 01:00.0) instead of the PCI Card LSI3008 (Address 05:00.0)... My Boot Drives run off of the internal card. From the fallback kernel, I was able to Modify /etc/grub-efi.cfg to remove the internal card form the hidden list. I now have a separate issue, but will make another post.

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

Hey that sucks after catching up 23 commits. Looks like something broke in the log module during the update. I’d try a clean reinstall of the dependencies first, or drop back to an older Node version for a bit – Node 24 can be fussy with these packages.

Hi bikemuch, For unregistered XOA the template auto-update is limited. Easiest way is via CLI: download the latest Debian 13 and CentOS Stream 10 ISOs, then use xe vm-import or create new templates from them. You can also check the XOA “Templates” section and force a refresh if available. Works fine for me this way.