Filed both XO related issues: Memory visibility at VM creation: https://github.com/vatesfr/xen-orchestra/issues/10225 domain_crash invisible in XO: https://github.com/vatesfr/xen-orchestra/issues/10226 Linking to this thread as promised earlier, thanks all. Hope this helps someone out.

Just got a failure today but with a different pool. "message": "backup task failed with undefined error", "name": "Error", "stack": "Error: backup task failed with undefined error\n at forwardResult (file:///usr/local/lib/node_modules/xo-server/src/_handleBackupLog.mjs:37:25)\n at handleBackupLog (file:///usr/local/lib/node_modules/xo-server/src/_handleBackupLog.mjs:68:12)\n at onTaskUpdate (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/metadata-backups.mjs:117:13)\n at onTaskUpdate (file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/mixins/Tasks.mjs:205:23)\n at onLogFct (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/combineEvents.js:61:5)\n at metadataBackup._executor (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/metadata-backups.mjs:122:11)\n at Jobs.runJob (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/jobs/index.mjs:297:7)\n at file:///usr/local/lib/node_modules/xo-server/src/api/schedule.mjs:84:9\n at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:204:22)\n at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:188:20)\n at Xo.runSequence (file:///usr/local/lib/node_modules/xo-server/src/api/schedule.mjs:73:3)\n at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:204:22)\n at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:188:20)\n at Api.#callApiMethod (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/api.mjs:475:18)" } } [image: 1785806777819-screenshot_20260803_212536.png]

@poddingue, that is true, my first post here. I'll try to play with these BIOS settings again. and keep you posted. Cheers

Hi! No, but check XO logs/output to see what's going on

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

This might have worked, at that time i've allready created new VMs from the information inside the Backup xml file. It worked out allright but building VMs this way, is quite tidious. Maybe there could be a way to find the correct installer and patches, to get a new host in a state to restore a pool backup, would be good.

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.