poddingue

From the log you attached, the failure is on session.login_with_password, and XO tries ::1:443 and then 127.0.0.1:443.
So it is XO trying to reach a host, not your remote, and whatever address it holds for that host is resolving to loopback.
You rebuilt one of the three nodes and you moved XO into Docker, so my guess is the host came back into the pool with a hostname instead of an IP, and that name does not resolve inside the container the way it did for the script install.
It would fit the rest too: migration goes host to host over the management address, copying does not, which is why one works and the other doesn't.

Could you paste the output of xe host-list params=uuid,name-label,address? I am guessing here, and @Team-XAPI-Network will know much better than me whether resetting that address is the right move.

I don't think "Protect from accidental shutdown" is what you are hitting here.
If any VM on that host has a host-bound device attached (PCI passthrough, vGPU, or an SR-IOV VIF), XAPI refuses to suspend it with VM_HAS_PCI_ATTACHED, and Smart Reboot stops there. xe host-get-vms-which-prevent-evacuation uuid=<host-uuid> should name them.
For the Rolling Pool Update half, XO 6.7.0 (released 30 July) added a shutdownPinnedVms option that shuts those VMs down and starts them again afterwards instead of aborting the run, so upgrading might get you past it.
I could easily be wrong about which of the two you are actually hitting, though, so I would start with that command and see what comes back.

Hi RN0, and thanks for photographing the panic on your first post here, because that is what made it findable.
The last line reads acpi_device_hid, which looks like the same crash someone else hit on an MS-A2 last year: https://xcp-ng.org/forum/topic/10972/xcp-ng-8-3-lts-install-on-minisforum-ms-a2-7945hx .

What got them past the installer was a BIOS change rather than a boot flag: disabling Global C-State Control under Advanced > AMD CBS > CPU Common Options worked for one of them, and another got through by turning off PSS Support instead.
That might be why nomodeset and safe mode made no difference for you, since neither touches ACPI.
There is a kernel fix for it now too, and once installed and updated they put the BIOS setting back to Auto and it kept working. So I do not think this is an HCL or driver problem, though I am not deep enough in ACPI to promise that, and someone who knows the kernel side better will correct me if I have misread your screenshot.

The PoD crash half is known: https://xcp-ng.org/forum/topic/10179/rockylinux-vm-s-random-reboots hit the same p2m_pod_demand_populate line, and the answer there was closing the gap between static-max and dynamic-max, with the background at https://xenproject.org/blog/ballooning-rebooting-and-the-feature-youve-never-heard-of/ .
The guest tools angle I have not seen reported before, and the 13-second repro makes it hard to wave off. What gives me pause is https://xcp-ng.org/forum/topic/11955/memory-ballooning-dmc-broken-since-xcp-ng-8.3-january-2026-patches, where the Vates Rust guest agent stopped re-arming ballooning after live migration and the Citrix utilities were the ones behaving.
Different guest OS and probably a different mechanism, so it may well be unrelated, but it makes me wary of reading your result as "Citrix tools do not reclaim" rather than the narrower "on Windows under PoD pressure".
I could not find an existing issue for either of your XO asks, so both look worth filing at vatesfr/xen-orchestra, and they stand on their own regardless of where the tools question lands.

Whether the XO 6 creation form already treats the memory side differently, I do not know, and I would rather say that than guess.

I checked this on an 8.3 host here, and your sshd_config.d observation is exactly right: the shipped /etc/ssh/sshd_config has no Include line at all, so anything you drop in that directory is never read.
The directory exists and is empty, which is what makes it look like it should work. It is not an OpenSSH version limit either, since the package is openssh-server-9.8p1-1.2.4.xcpng8.3 and 9.8 supports Include fine.
On @tjkreidl's route, two things check out on my side: the packaged unit really is ExecStart=/usr/sbin/sshd -D $OPTIONS, so his blank ExecStart= plus a replacement line is the correct shape, and RH-Firewall-1-INPUT does exist as a chain, so his iptables step targets the right place.
I have not actually moved a port with it, so treat that as "the pieces line up" rather than "I tested it end to end", and keep a second session open when you try.
Might be worth a mention to @Team-OS-Platform-Release, since whether there is a supported way to pin a port is a packaging question more than a config one.

@tjkreidl's systemd override is the angle I would try first too, since it moves the port out of the file the package keeps rewriting and into a drop-in that an update should leave alone.

His firewall step is worth reading carefully rather than skimming, because on XCP-ng the iptables rule is the part that locks you out if you miss it, and he says himself he has not run this.

On your sshd_config.d question, I would check whether the shipped sshd_config actually contains an Include /etc/ssh/sshd_config.d/*.conf line, because if it does not then those files are simply never read and that would explain the silence rather completely.
One thing that is written down is that since 8.3 the accepted ciphers and algorithms are baked in at OpenSSH build time, and anything you override yourself is yours to maintain across updates: https://docs.xcp-ng.org/releases/release-8-3#openssh-security-ciphers-and-user-configuration.
Might be worth a mention to @Team-OS-Platform-Release, since whether a supported way to pin a port exists is really a packaging question rather than a config one.

I have not done this on a live host, so please keep a second session open while you test.

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.

That is a useful pair of findings, thanks for going back and testing both.
So the appliance was never the blocker, it just needs the Windows console next to it to add the NFS repository and connect XCP-ng, which fits what @AtaxyaNetwork saw too.
The part I would not have guessed is that upgrading an existing console pulls the plug-in in by itself, while running the standalone plugin installer against a fresh 13.1 offers to uninstall it instead, so anyone coming from 12.x probably wants to look at the console component list rather than hunt for a separate download.

Your screenshot showing Veeam Plug-In for Xen UI Extension 13.1.0.295 sitting next to the Nutanix, oVirt and Proxmox extensions is a good confirmation it is a proper component now and not a side channel.

I have not run 13.1 myself so I am going entirely on your screenshots here. If you get as far as a first successful backup run, it would be great to hear how that went.

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?