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