That's the flag then, not XAPI refusing. Which is the easier of the two to get out of. Nothing showed up in Advanced because XO only lights that toggle when all seven of its stop operations are blocked: clean_reboot, clean_shutdown, hard_reboot, hard_shutdown, pause, suspend and shutdown. Yours has four of them, so the toggle already reads as off and there's nothing to switch off. Turning it on and then straight back off does clear them, though. I tried that on a test VM here, on XO 5.205.2. The first click set all seven, the second removed all seven, and suspend was back in allowed-operations. Your destroy entry is the separate "Protect from accidental deletion" toggle just above it, and that one will show as on. Turning the shutdown one on and off leaves it alone, so keep it if you want it. If you'd rather not touch the others, this removes just the one key: xe vm-param-remove uuid=<vm-uuid> param-name=blocked-operations param-key=suspend I ran that one too, on 8.3, and suspend came back in allowed-operations straight away with the VM still running. What I can't tell you is what set that particular combination on your VM in the first place. Does it ring a bell?

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.

@msupport We're testing Veeam now. From what I read, I thought CBT was supposed to be disabled in XCP as Veeam uses it's own CBT engine, is that not correct? Also, is it normal for the SR to show a bunch of veeamsnap files for all the VDI's it backed up? I was under the impression Veeam was supposed to remove those when the backup was complete, but perhaps one of them needs to stay for tracking?

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/

For anyone who finds this in the future, I ran into a similar issue today when passing through a LSI Card, Coincidentally on Address 05:00.0, also coincidentally on a Supermicro Board (mine is X10DRH-CT, OPs was a X8DA8) I was originally writing a comment here to see if a solution had ever been found, but while taking/marking up screenshots of my Motherboards System Block Diagram, I discovered my problem... Human Error of course. Long story short, I added a PCI to 2xM.2 card, and in my BIOS, I bifurcated the wrong CPU/PCI Port. Instead of Bifurcating the M.2 Card, I accidentally Bifurcated the LSI Card, which caused the Unknown Header Error AND since there was an unknown header, the VM Would throw the "Device or Resource is busy" error when trying to start. Correcting the Bifurcation fixed the issue in my case. Not sure if that was the issue in OPs case, but this might help someone else who stumbles across this

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.

@MajorP93 Ok. Thanks!

Any update on this? It is a drawback. It is also in the wrong format under snapshots. XO 5 has the format: July 17, 2026 or 2026-07-17 depending on the screen.

Question for @Team-XO-Backend

It's more like "partially"/loosely based on Alma (10, not 9). And yes, the kernel will be far more recent, same for Xen and so on.

@neal https://github.com/vatesfr/xen-orchestra/issues/10260

@dinhngtu When creating GPOs if you have an non-policy setting for all users in the settings area for the agent config. The policy based registry settings can go into “Software\Policies”, for the appropriate HKEY and keys. In which case the policy based registry entries supersede the non-policy ones, when considering also the HKLM vs HKU and HKCU cascade. Also a disabling of user configuration of the managed setting(s) along with display of a message like “At least some of these settings are managed by the organisation”.

@poddingue Fistst of all I appreciate your answer and your position. The thing is that, even though the proxy code itself is opensource, the functionality of the plugin is basicaly behind a paywall. We are not talking about support. Actual functioning of the plugin after compiling from sources depends on license availability and there is no option to select no support or something along the lines "I built it myself from sources". Without patching the code even though the proxy is otherwise functional the backups won't work because of missing license. Hopefully the powers that can will provide an acceptable albeit community supported way to use the proxy cleanly, without touching license checks. Best regards!