@JB @gregbinsd The fix has not been merged with the master branch yet, so you won't have the fix yet. Follow this pull request https://github.com/vatesfr/xen-orchestra/pull/10282 When you see an entry at the end of the activity log which says something like ' merged commit [commit ID] into master' then you'll know the fix has been added to the master branch. It's important to know that they could close this pull request without committing it to the master branch if they want to approach the resolution in a different way (this has already happened once with this issue).

So I ended up going with the Windows B&R as i could net setup the windows mount server when setting up the repo for the backups. It would setup the linux one but not the windows one. This was with using the veeam console from a windows client. So i ended up with the Windows one. Now after a few backups i am see this warning / error.... 8/5/2026 5:34:50 PM Warning : Failed to use CBT: [Task e75c4247-2ee1-7b51-088c-b970ace60f3d (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated] First i thought it was because i maped the new job to older backups from Beta v1. So i purged all old backups and started fresh. The full backups were successful. Now on first delta 4 out of 7 vms have that warrning. This a Veeam issue or xcp-ng?

@dinhngtu Something called "Elpha Secure" ...none of our other antivirus shows it being bad but I wanted to ask around before I unflagged it.

@AtaxyaNetwork Merci pour tes recherches ! Oui "cd_label" serait cool comme ajout au plugin ce qui permet sur les distro type Fedora/Redhat de ne pas avoir de boot_command à gérer

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. Update - Veeam took alot more logs from Veeam and from xcp-ng pool. Their response back - I've got someone else getting similiar results, so I'm providing both of your logs to get some insights. Basically when you see the error, it's because something happened to the bitmap we left behind on the previous run and so next run, we re-read the entire disk. I've not found anything super clear to what's going wrong with the bitmap and why its gone, even from the Xen server logs, so I'm hoping from QA's eyes might see what I might be missing. I will keep you posted if they have any details.

@olivierlambert Happy to hear that they are providing results to be looked at. If there is anything else I can provide, please don't hesitate to ask. And I'll do my very best to be helpfull

Excellent! It's really cool to see how XO Backup and Replication can help you to migrate easily

Hello @anthoineb, We had another occurrence and this time tested the exact GDB method you suggested. It successfully unlocked the ring. The incident affected os-ott-data-3-2 (172.30.52.193) on hypervisor 172.30.50.191. Before the test, the guest state was: 254 requests in flight 255/256 blk-mq tags busy I/O PSI full: approximately 94-97% 3 tasks in D state no completed xvdb I/O progress Tapdisk remained responsive and reported: reqs_outstanding=0 tap/image/VBD/xenbus errors=0 The untouched active td_xenblkif state was: domid=26 devid=832 port=343 ring_n_pages=8 ring_size=256 n_reqs_free=256 in_polling=false req_prod=2243281141 req_cons=2243280886 rsp_prod=2243280886 rsp_prod_pvt=2243280886 Therefore, exactly 255 requests were waiting in the active PV ring. After preserving the baseline, we executed once: call (void)tapdisk_xenblkif_sched_chkrng(blkif) The indices were unchanged immediately inside GDB, but within approximately five seconds: tapdisk reqs_outstanding: 0 -> 256 guest write inflight: 254 -> 0 I/O PSI full: approximately 98% -> 24% and continuing to decrease xvdb completed-I/O counters started advancing The post-test GDB capture showed: in_polling=true req_prod=2243366603 req_cons=2243366603 rsp_prod=2243366600 rsp_prod_pvt=2243366600 n_reqs_free=253 The previously stuck requests had been consumed and normal new I/O was flowing. OpenSearch recovered its transport communication and the node rejoined the cluster without restarting the OpenSearch service and without rebooting the VM. The cluster completed shard recovery and became green at 17:05 MSK. We also checked SMlog, xensource.log, and daemon.log for this incident. There was no VM or storage pause/unpause immediately before or during the stall. This appears to confirm that tapdisk was not performing the scheduled ring check, and explicitly calling tapdisk_xenblkif_sched_chkrng() restored processing. Would it be reasonable to use this call as an automated recovery action when the same exact signature is detected, before falling back to a VM reboot? We have the complete before/after GDB captures and guest/hypervisor diagnostics available if useful.

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

@acebmxer Thank you for your quick feedback.

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

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

@andriy.sultanov @andriy.sultanov said: @pandusen As Teddy said above, you can't passthrough a PCI bridge, so there's no PCI devices xapi shouldn't omit here. I am not trying to pass through the bridge only the end points. The Intel arc's have 2 end points: The GPU and the Sound device. "xe pci-list" only reveals the GPU, not the sound device. (this works for nvidia and AMD) But "going the xen-cmdline way" shouldn't break anything, that's what xe pci-disable-dom0-access does behind the scenes. What issues did you see? Which steps did you follow? the sound device is available in the lspci list and can be passed through using CLI. But doing so, (using CLI for passtrough) undoes everything done using xe or the passthrough gui in XO. and results in this: https://xcp-ng.org/forum/topic/10609/xcp-ng-8.3-pci-passthrough-issue so yes, its does break something.

Thanks for the feedback.

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

@ovicz xapi-26.1.16-1.1.0.pirq.2.xcpng8.3 is now available on xcp-ng-ndinh2, which disables HVM PIRQ for all existing VMs by default on reboot. Please try it out. I've prepared an upstream PR for this feature. If you'd like to be listed as a tester, please respond with your name and email address (or your fake github email if you prefer) and I'll update my commit with your credit.

@olivierlambert busy writing/adapting de RBD SR and running tests. once I got the results and thins finalized I'll post and update with the RBDSR file (based on @benapetr)

Thanks a lot for this feedback, @pedro!