@Danp Yes later I did try and it restore the vm along side the original with the "_" a underscore appended to the end of the name of the vm. Original - Windows Server 2022. Restored - Windows Server 2022_

@poddingue Borrow away - "smoke alarm" is a better name for it than anything we had, so we might borrow it right back. Since you mentioned reading the matrix - here is the classification you would be reading, straight from the file: grep access: dadl/xen-orchestra.dadl | sort | uniq -c 49 access: admin 21 access: dangerous 122 access: read 75 access: write 122 of the 267 tools are plain read - that is the entire surface a review-capped agent gets. The other 145 exist in the same file, but for that agent they might as well not. The whole security taxonomy is greppable plaintext - which is rather the point of a declarative format. And if anything in the matrix looks wrong or missing, this thread is exactly the right place - real-world corrections are how it improves.

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

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