@poddingue Olá! The failure has a fixed duration of 5 minutes.

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.

More options: to Prevent overwriting the file: Method 1: Probably the best option. Use a Configuration Directory. Modern OpenSSH versions (8.2+) support an include directive. This is the cleanest approach. Create a drop-in file: Put your custom settings in a separate file, such as /etc/ssh/sshd_config.d/custom.conf. The rule: Package updates will not touch files inside this directory. Verification: Ensure the line Include /etc/ssh/sshd_config.d/*.conf is active at the top of your main /etc/ssh/sshd_config file. Method 2: Lock the File (Alternative) You can force the filesystem to make the file immutable so nothing can change it. Lock the file: Run sudo chattr +i /etc/ssh/sshd_config Unlock for edits: Run sudo chattr -i /etc/ssh/sshd_config when you need to make intentional changes. Method 3: Tell Apt to Ignore Updates. If you are on a Debian-based system, you can force the package manager to always keep your local version. Add this line to /etc/apt/apt.conf.d/local: UCF_FORCE_CONFFOLD=true

Drivers are actually in @Team-Hypervisor-Kernel scope nowadays

After trying a few more restores the other vms did not get this name change. Not sure why it happened to the one vm, but the other retained their original names and tags.

Du coup j'ai testé avec RHEL 9, ça fonctionne aussi. Faut bien prendre l'iso "dvd", pas "boot" en revanche ! (je me suis fait avoir en téléchargeant l'image)