Ok with the veeam Appliance you can use a windows vm or pc with the veeam console and you can connect the applaince to add nfs share for backup repo and connect to XCP-NG. So two working cofigs... Windows VM with B&R Veeam Appliance + Windows Client for console access When i upgraded the current veeam client to the latest client it also installed the xcp-ng plugin. [image: 1785509253968-screenshot-2026-07-31-103408.png]

@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

@jeremie1977 j'ai un packer qui fonctionne avec RHEL 10 (c'est ce que j'avais sous la main), uefi, sans dhcp, et un cd file qui sert le ks Le code est ici: https://github.com/disruptivemindseu/xcpng-template-builder/tree/rhel-airgapped/packer/distros/rhel/10/uefi-airgapped Je vais essayer avec une RHEL 9 ce week-end, il y a peut-etre une subtilité entre les deux versions

[image: 1785509780280-backup-metadados4.jpg]

@acebmxer Thank you for your quick feedback.

Great, thanks for the feedback!

A remote is not the same thing as a SR. For a remote, it's simple: disconnect it (click on "Enabled" so it's disabled then), do whatever you need on the NFS server, re-enable.

@acebmxer all good and thank you again for sharing your discovery on the forums

@yannsionneau , may this link helps if you not anyway know it https://medium.com/@timemaster5/getting-amd-phoenix-igpu-passthrough-working-on-xen-xcp-ng-8856593f9c0d I will give it a try this weekend

Hello @anthoineb, We captured another occurrence on the same VM, os-ott-data-3-2 (172.30.52.193), on the same hypervisor and QCOW2 VDI as the incident reported on 2026-07-25. This occurrence is useful because xen_blkfront.max_ring_page_order=3 was definitely active: xenstore showed ring-page-order=3 with eight ring references; the guest queue depth was 256; 255 write requests remained in flight; all 256 blk-mq scheduler tags were busy; wbt_lat_usec=0; I/O PSI full was approximately 98%; completed xvdb counters did not advance between samples. The backend state was nevertheless the same as in the previous capture: tapdisk was sleeping in scheduler_wait_for_events(); tap-ctl reported reqs_outstanding=0; tap request counters were 0/0; req_prod=0 and rsp_prod=0; no tap, image, VBD, map or xenbus errors were reported. One detail may be relevant: GDB still printed n_reqs=32 and n_reqs_free=32, although the frontend had negotiated an order-3 ring and the guest exposed 256 tags. Is this expected because n_reqs represents a separate fixed tapdisk request pool, or could it indicate that tapdisk is not observing the complete multi-page ring? The controller captured GDB and the guest/hypervisor state before reboot. After the ten-minute diagnostic window, the same signature was confirmed three more times and the VM was rebooted. It rejoined the cluster successfully. I have attached: the complete GDB/tap-ctl capture; the guest blk-mq, diskstats, PSI, D-state stack and kernel-journal snapshot; the corresponding tapdisk/xenstore, daemon.log and SMlog excerpt; a README and SHA-256 checksums. The important new result appears to be that increasing max_ring_page_order from 0 to 3 did not prevent the stall; the same mismatch recurred with 255/256 frontend requests/tags occupied while the backend ring and tapdisk remained empty. 20260730-005220-gdb-172.30.52.193.txt 20260730-pre-reboot-guest-172.30.52.193.txt 20260730-pre-reboot-hypervisor-172.30.50.191.txt README.txt SHA256SUMS.txt

Good news that it sorted itself out. Both changes went in at once and the next run came back clean on the ADDS VMs too, so I don't think there's anything left to pin down here, and I'd rather say that than invent an explanation after the fact. Your question about the snapshot modes was the useful thing to come out of this thread. I went looking, they genuinely aren't documented anywhere, and that's written up on our side now If the fall back to a full ever comes back on the ADDS VMs specifically, that would deserve its own thread with the SMlog output @tjkreidl asked for, since nobody got to look at that part.

@poddingue I found it in a google search. Supposedly xe vm-param-set other-config:auto_poweron_delay=<Delay_In_Seconds> uuid=<VM_UUID> I have no idea whether this is AI hallucinating or whether this was relevant to older releases or what. But when you wrote it explained the behaviour what did you mean? I don't understand. The setting doesn't delay the start of the VM I am setting it on? Because from what I could see it seemed like it delayed the start of the next VM instead.

Actually, isn't XAPI 24.19.2 what is shipped with the original XCP-ng 8.3 release? If so, then you could just do this -- Reinstall XCP-ng on the new host Restore the pool metadata Patch the host

Thanks for coming back with the actual cause instead of leaving it hanging. To me, a permissions reset on /etc/rc.d/rc.local would explain it completely, and it fails in the worst way, since nothing complains at boot and the VMs just never start. It also looks worth documenting, because our own troubleshooting page tells people to append a clocksource workaround to /etc/rc.local without mentioning the executable bit either, so anyone following that could end up with a workaround that quietly does nothing. I haven't tested whether the 8.2 to 8.3 upgrade resets that bit every time or just happened to in your case, so that half stays your finding, not mine. I'm curious what you turn up on the colon versus equals behaviour.

All hosts are restarted with 9.2.18 loaded now. Will see what happens next. [15:56 ovbh-pprod-xen05 ~]# drbdadm --version DRBDADM_BUILDTAG=GIT-hash:\ 71c8bcff6ea77a022b272a7eba649a774251bac4\ build\ by\ @buildsystem\,\ 2025-11-03\ 10:21:36 DRBDADM_API_VERSION=2 DRBD_KERNEL_VERSION_CODE=0x090212 DRBD_KERNEL_VERSION=9.2.18 DRBDADM_VERSION_CODE=0x092100 DRBDADM_VERSION=9.33.0

@olivierlambert I have a full Realtek 8125/8126/8127 update to replace the existing r8125 driver, as required to support newer chips. The new 8125 driver drops the 8126 support but you just install the 8126 if needed (requires newer 8125 driver to avoid module conflicts).

@poddingue Thanks - great question, and the answer is simpler than you might expect. Every tool in the catalog is classified right in its description: read, write, admin, dangerous. That classification ships with the DADL itself - nobody has to sort 267 endpoints by hand before letting an agent near them. From there it is a ladder: Each agent (or user) gets a maximum access level. Our reviewing agent is capped at "read" - so a VDI delete is not blocked with a warning, it is simply not on the table. And this holds even though the gateway itself holds an admin token towards XO: the agent's reach ends at the classification, not at the token. The model cannot talk its way past a label. Exceptions are a one-line override: "read-only, but snapshot_vm is allowed" - or the other direction, "writes allowed, but nothing classified dangerous". For the fine-grained cases - "read-only, except never touch this one VM" for example - there are policies that can filter on parameters, not just functions. Underneath it all, one rule: fail-closed. If any check cannot complete, the call does not run. The detail we find most underrated: refused attempts are logged as first-class events. A reviewing agent that suddenly asks for a delete is not a near-miss - it is a signal, because it usually means the model read something it should not have trusted. Which is your Insights piece's "boundaries drawn in advance", applied literally. Happy to go deeper on any of this - the boundary question is exactly what the gateway exists for.

@oliv77 said: Hi, XOA version: xo-server 5.193.1 xo-web-premium 5.191.0 We've noticed on our production XOA server that when we put an XCPNG host in a pool into maintenance mode, we reboot it and then it reconnects to its pool but is no longer in maintenance mode. Is it possible to configure the XCPNG hosts so that they automatically return to maintenance mode after a reboot? Regards, Oliv77 Hi @oliv77, XO 6.7 - latest - adds this option in REST API and next month we should have the available action (Disable host and evacuate VM) in XO6 !