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

Welcome to the forum, and thanks for writing this up instead of just fixing it on your own box. You already found the thread I was going to point you at. You're ahead of me there. What happened in it after the part you read: Olivier bisected the problem down to Linux 6.12.5, and Teddy linked an upstream fix that landed in tip (f24df84cbe05), with no ETA for when distros pick it up. The tsc_mode=2 plus nomigrate workaround came out of that, and it carries the live migration cost you already spotted. One thing I'd like to know, and I don't think anyone has tried it on your side. Does the leftover couple of seconds per vCPU go away if you set tsc_mode=2 on one of those VMs? If it does, that would tie your case to the same regression rather than to a second thing. I'm not deep enough in the timer code to tell you whether the ttyS0 amplification and the TSC regression are the same mechanism or two things stacking. Probably worth a mention to @Team-Hypervisor-Kernel so someone who is can have a look.

@dsauce To test your theory out on my issue i just tried to disable CBT on XOA side and one vm gave me this error... vdi.set { "id": "11286a97-b773-4ec4-a0b7-464ab87254ca", "cbt": false } { "code": "UUID_INVALID", "params": [ "VDI", "a52fe4ab-edc2-4975-a118-f6db84435379" ], "call": { "duration": 1, "method": "VDI.get_by_uuid", "params": [ "* session id *", "a52fe4ab-edc2-4975-a118-f6db84435379" ] }, "message": "UUID_INVALID(VDI, a52fe4ab-edc2-4975-a118-f6db84435379)", "name": "XapiError", "stack": "XapiError: UUID_INVALID(VDI, a52fe4ab-edc2-4975-a118-f6db84435379) at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12) at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:64:5) at processImmediate (node:internal/timers:452:9) at process.callbackTrampoline (node:internal/async_hooks:130:17)" } Another vm.. vdi.set { "id": "966fe072-4865-48a2-867a-0eb59b23dcc7", "cbt": false } { "code": "UUID_INVALID", "params": [ "VDI", "d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5" ], "call": { "duration": 1, "method": "VDI.get_by_uuid", "params": [ "* session id *", "d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5" ] }, "message": "UUID_INVALID(VDI, d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5)", "name": "XapiError", "stack": "XapiError: UUID_INVALID(VDI, d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5) at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12) at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:64:5) at processImmediate (node:internal/timers:452:9) at process.callbackTrampoline (node:internal/async_hooks:130:17)" } Update - after backup completed with warnings i looked back and CBT was re-enabled in XOA. Did not help with my Veeam issues.

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.

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

Possibly related observation from an Intel pool (Xeon Gold, XCP-ng 8.3): Ubuntu 26.04 cloud image (kernel 7.0, UEFI) shows a similar-looking freeze at "installing Xen timer for CPU N". In my case console=ttyS0 from the cloud image's default cmdline amplified it ~7x — removing it dropped the sched_clock correction from 143s to 16s on 8 vCPUs, and unlike tsc_mode=2 it keeps live migration. Not sure it's the same root cause, but might be worth checking cmdline for those hitting this with cloud images.

@poddingue Thank you for the analysis. I'd give you a rep if I could

If the list is only complete after you've been through the Storage view first, that smells like the VM view not loading the whole SR collection, so the dialog only knows about the SR the disk already sits on. I could easily be wrong about the mechanism though. 6.7.0 went out on 30 July, so it would help to know whether it still does this there, and whether anyone else on 6.6.2 sees the same thing. Might be worth a mention to @Team-XO-Frontend, since they'd know straight away whether that dropdown is meant to come from a shared collection or get fetched per view. The nearest thing I found in the tracker is https://github.com/vatesfr/xen-orchestra/issues/7392, but that one is ISO SRs turning up in the wrong list rather than SRs going missing, so probably not the same thing.

Hello @mike.potapov , on n_reqs=32 and n_reqs_free=32, I think you're watching td_blktap_t structure. This structure is only used if the pvdriver are not install in the VM, so it's normal this ring is not used. You should watch struct td_xenblkif that is the ring use normally and that must contains 256 requests on max_order=3. The tapdisk will wakeup periodically, you could put a breakpoint on tapdisk_xenio_ctx_ring_event to confirm that the ring is check periodically. You can investigate td_xenblkif here. Ultimatly, you can try to send a notification from the tapdisk under gdb to the linux kernel with call (int)xenevtchn_notify(blkif->ctx->xce_handle, blkif->port); to see if it unlock something on the guest side. It it's the case it will confirm a notification was lost. If not you will get a message about spurious interrupt in the dmesg of the guest kernel.

Your xe host-list output kills my guess. All three addresses are real LAN IPs with nothing on loopback, so the loopback is probably coming from the XO side rather than from XAPI. I did test one thing: given a name that resolves to both families, Node reports connect ECONNREFUSED ::1:443 and connect ECONNREFUSED 127.0.0.1:443 together, which is what your log shows, while the literal 127.0.0.1 only ever names one address. That suggests something is handing XO a name rather than an IP, and localhost is the obvious candidate, so it's worth checking what you have registered for that pool under Settings then Servers, which is where the address comes from in the first place: https://docs.xen-orchestra.com/xo5/manage_infrastructure#add-a-host . The migration failure I'd keep separate for now, and could you paste the exact error XO gives when one fails? I don't know whether the two are the same problem and I'd rather have the text than keep making wild guesses.

@yllar said: @yannsionneau Hi, any news on the new iso? Hello @yllar In case you missed it, the ISO was released a few days ago: https://xcp-ng.org/blog/2026/08/14/xcp-ng-8-3-lts-refreshed-installation-isos/