@florent suggesting this looks like a network issue, I took a look at my XO's server's syslog and found the error when this occurs. 2026-07-31T00:10:00.428083-04:00 mis-26-svr xo-server[1298]: 2026-07-31T04:10:00.427Z xo:xo-server ERROR uncaught exception { 2026-07-31T00:10:00.428186-04:00 mis-26-svr xo-server[1298]: error: AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value: 2026-07-31T00:10:00.428262-04:00 mis-26-svr xo-server[1298]: 2026-07-31T00:10:00.428309-04:00 mis-26-svr xo-server[1298]: assert(!this.paused) 2026-07-31T00:10:00.428341-04:00 mis-26-svr xo-server[1298]: 2026-07-31T00:10:00.428391-04:00 mis-26-svr xo-server[1298]: at Parser.finish (/opt/xo/xo-builds/xen-orchestra-202607200851/node_modules/undici/lib/dispatcher/client-h1.js:302:5) 2026-07-31T00:10:00.428414-04:00 mis-26-svr xo-server[1298]: at TLSSocket.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202607200851/node_modules/undici/lib/dispatcher/client-h1.js:741:32) 2026-07-31T00:10:00.428434-04:00 mis-26-svr xo-server[1298]: at TLSSocket.emit (node:events:521:24) 2026-07-31T00:10:00.428478-04:00 mis-26-svr xo-server[1298]: at TLSSocket.patchedEmit [as emit] (/opt/xo/xo-builds/xen-orchestra-202607200851/@xen-orchestra/log/configure.js:52:17) 2026-07-31T00:10:00.428508-04:00 mis-26-svr xo-server[1298]: at endReadableNT (node:internal/streams/readable:1729:12) 2026-07-31T00:10:00.428525-04:00 mis-26-svr xo-server[1298]: at processTicksAndRejections (node:internal/process/task_queues:90:21) { 2026-07-31T00:10:00.428549-04:00 mis-26-svr xo-server[1298]: generatedMessage: true, 2026-07-31T00:10:00.428567-04:00 mis-26-svr xo-server[1298]: code: 'ERR_ASSERTION', 2026-07-31T00:10:00.428582-04:00 mis-26-svr xo-server[1298]: actual: false, 2026-07-31T00:10:00.428599-04:00 mis-26-svr xo-server[1298]: expected: true, 2026-07-31T00:10:00.428614-04:00 mis-26-svr xo-server[1298]: operator: '==', 2026-07-31T00:10:00.428628-04:00 mis-26-svr xo-server[1298]: diff: 'simple' 2026-07-31T00:10:00.428642-04:00 mis-26-svr xo-server[1298]: } 2026-07-31T00:10:00.428659-04:00 mis-26-svr xo-server[1298]: } So it looks like xo-server is dying, could it be the module undici that the problem here? Keep in mind that 13 other instances of xo-server performed the backup without a problem at the exact same time. Some days this never happens, some days it could be 4 instances of xo-server that die the same way in executing the backup. I think it's also important to note that the instance of xo-server dying happens immediately upon the backup being started at 10 minutes after midnight. I would think that if the problem were the network itself, that there would be some timeout period before causing the xo-server instance to crash. To answer a question asked of @jb , this is a local XCP-ng management network and there are no other backups occurring at 00:10.

My earlier wording was the problem here, not your reading of it. There are two official descriptions and they do not say the same thing. The CLI reference calls start-delay "the delay to wait before a call to start up the VM returns", which is the one I quoted. The XenAPI field description calls it "the delay to wait before proceeding to the next order in the startup sequence". That second one is exactly what you saw: the delay lands on the next VM to start, not on the one you set it on. I quoted the confusing one and then said it explained your behaviour, which it does not really. What I still cannot explain is why a start-delay would stop a VM autostarting altogether. Neither wording predicts that, so I would rather say I do not know than invent a reason. On auto_poweron_delay, I went looking and could not find it anywhere in the XCP-ng or XO docs, so I think your instinct about that search result was right. I have updated the docs PR I had open so it leads with the XenAPI wording and cites both, since the CLI reference phrasing is what sent me wrong in the first place.

@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

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]

@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

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

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.

Great, thanks for the feedback!

@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

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.

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

I think this is fixed in 6.7: when a delta backup falls back to a full, the task now shows the actual reason instead of just contradicting itself the way you and Andrew both saw (PR #10148). Worth checking after you upgrade.

Both things reported here look fixed in 6.7: the retry succeeding but the job still showing as failed (PR #10129), and the EEXIST: file already exists error, which happened when a job got recreated after a crash (PR #10139). Curious if upgrading clears it for you all too.

The progress bar issue you and Florent were chasing looks fixed in 6.7 (PR #10133). Worth upgrading and seeing if it moves now instead of sitting still. Separately, since this thread is specifically about QCOW2 backups: 6.7 also fixes an offset bug that could leave incremental backups mostly empty after the first block when NBD isn't enabled. Worth a look at the release notes if that's your setup too.

Hello, You can find all the demo dashboards at the following address: https://github.com/steeve-san/OpenMetrics_XCP_Grafana Regard,

This issue should be fixed in the latest release (to be out today).

@acebmxer Thank you for your quick feedback.