@poddingue The other option would be to be able to offer a different default /etc/ssh/sshd_config option but that's embedded in the Linux OS. One other possibility would be to create a startup job that runs out of /etc/rc.local and has a script that makes the changes after-the-fact. Just a thought...

So i just attempted a restore not sure if this is a Xen thing or Veeam thing. Xen Orchestra will leave the orginal VM alone and just create a new one. This states it will remove the original vm. [image: 1785617284852-screenshot_20260801_164708.png]

That is clearer than I expected, thank you. The part that lands for me is that the cap sits on the agent rather than on the token, so a delete is not refused after the fact, it simply never appears in the catalogue the model can see. I had assumed most of the work would live in a policy engine, and it sounds like the bulk of it is classifying the 267 tools once and shipping that classification with the description itself. Treating a refused call as a signal rather than a near miss is the bit I want to borrow if/when we talk about this, because it turns the log from an audit trail into something closer to a smoke alarm. I am not deep enough in MCP to have a useful opinion on where this model breaks, so I will read the endpoint matrix properly before asking anything else. Passing it on internally as promised.

Merci pour les précisions, elles écartent ma piste. Si vous reproduisez en BIOS comme en UEFI, le ticket #151 ne colle pas, d'autant qu'il parle de l'installeur Windows et pas d'Anaconda : je l'avais résumé un peu vite. La différence intéressante est peut-être RHEL 9 contre RHEL 10, puisque @AtaxyaNetwork a un build qui fonctionne en 10 avec cd_files et sans DHCP, et son test en 9 ce week-end devrait trancher. Sur cd_label = "OEMDRV", je n'ai trouvé ni issue ni PR dans le dépôt du plugin, donc ça n'existe visiblement pas encore : si ça vous va, ça ferait une demande propre à ouvrir sur https://github.com/vatesfr/packer-plugin-xenserver, en reprenant l'argument air-gapped que vous détaillez plus haut, qui est plus convaincant que ce que j'écrirais moi. Je ne connais pas assez le plugin pour dire si c'est simple à ajouter, donc je préfère ne rien promettre. Merci en tout cas de documenter tout précisément, ça servira sans doute bien au-delà de votre POC.

Trying to pull the last few posts together, because there is a pattern I keep staring at. Every failed run in @JB's screenshots lasts exactly 5 minutes while the successful ones finish in seconds, and @abudef's history going back to 23 June shows the same 5-minute wall. That reads to me like a fixed timeout firing rather than a merely slow transfer, though I could be wrong about which one. @christopher-petzel's syslog looks like a different animal, since assert(!this.paused) in undici's Parser.finish is xo-server crashing outright at job start while 13 other instances backed up fine the same minute. The only knob I can find written down is httpInactivityTimeout at https://docs.xen-orchestra.com/xo5/backup_troubleshooting#error-http-connection-has-timed-out, but that one sits on the XAPI GET path, and I do not know whether it touches pool metadata jobs at all. @florent, does the 5-minute signature change anything on your side?

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.

@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

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