@msupport said: @acebmxer You need two Disk with 300GB If this is a reply to my initial post. I have already got it installed. Where do you see this 300GB requirement? https://helpcenter.veeam.com/docs/vbr/em/system_requirements.html?ver=13 Disk Selection Logic: When selecting a disk for system and adjacent functions, Veeam Software Appliance automatically chooses an SSD over an HDD, and selects the smaller disk of the two available. The sizing recommendations for Disk 1 below remain valid for the system disk. Disk 1: 240 GB1 minimum. This disk hosts Veeam JeOS, Enterprise Manager Veeam Backup & Replication software, configuration database and instant recovery cache. Recommended sizing depends on the number of protected workloads. Sizing also accounts for configuration database growth as you add more workloads to protect: 480 GB1 SSD for small environments (up to a few hundred workloads). 960 GB1 SSD for medium-sized environments (up to a few thousand workloads). Multi-TB1 SSD for large environments. Larger capacity increases the disk space available to instant recovery cache, allowing for running more machines for longer time. Note: After Veeam Software Appliance deployment, adding new storage devices or resizing existing ones is not supported. Plan your disk capacity carefully before you start the deployment. Disk 2: 240 GB1 minimum. This disk hosts guest file system catalogs and backups, therefore recommended sizing depends on your backup storage needs. Any additional disks found in the system during Veeam Software Appliance deployment will be automatically joined with Disk 2 into the single Logical Volume Manager (LVM) spanned volume. This is only backing a few vms around 10 vms, and actual location is to nfs storage.

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]

@jeremie1977 Ah, oui effectivement je n'ai pas testé avec plusieurs disques ! Et j'ai du typo dans la doc, je vais faire une PR pour modifier Je pense que c'est du a la façon d'insérer les disques et les DVD coté XCP-ng. Je vais investiguer !

@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

Excellent! It's really cool to see how XO Backup and Replication can help you to migrate easily

@acebmxer Thank you for your quick feedback.

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

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.

Great, thanks for the feedback!

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.

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.

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

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.

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.

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

@acebmxer all good and thank you again for sharing your discovery on the forums

Very cool, thanks for the feedback @maximsachs !

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

Hello @anthoineb, We captured another occurrence on the same VM, os-ott-data-3-2 (172.30.52.193), on the same hypervisor and QCOW2 VDI as the incident reported on 2026-07-25. This occurrence is useful because xen_blkfront.max_ring_page_order=3 was definitely active: xenstore showed ring-page-order=3 with eight ring references; the guest queue depth was 256; 255 write requests remained in flight; all 256 blk-mq scheduler tags were busy; wbt_lat_usec=0; I/O PSI full was approximately 98%; completed xvdb counters did not advance between samples. The backend state was nevertheless the same as in the previous capture: tapdisk was sleeping in scheduler_wait_for_events(); tap-ctl reported reqs_outstanding=0; tap request counters were 0/0; req_prod=0 and rsp_prod=0; no tap, image, VBD, map or xenbus errors were reported. One detail may be relevant: GDB still printed n_reqs=32 and n_reqs_free=32, although the frontend had negotiated an order-3 ring and the guest exposed 256 tags. Is this expected because n_reqs represents a separate fixed tapdisk request pool, or could it indicate that tapdisk is not observing the complete multi-page ring? The controller captured GDB and the guest/hypervisor state before reboot. After the ten-minute diagnostic window, the same signature was confirmed three more times and the VM was rebooted. It rejoined the cluster successfully. I have attached: the complete GDB/tap-ctl capture; the guest blk-mq, diskstats, PSI, D-state stack and kernel-journal snapshot; the corresponding tapdisk/xenstore, daemon.log and SMlog excerpt; a README and SHA-256 checksums. The important new result appears to be that increasing max_ring_page_order from 0 to 3 did not prevent the stall; the same mismatch recurred with 255/256 frontend requests/tags occupied while the backend ring and tapdisk remained empty. 20260730-005220-gdb-172.30.52.193.txt 20260730-pre-reboot-guest-172.30.52.193.txt 20260730-pre-reboot-hypervisor-172.30.50.191.txt README.txt SHA256SUMS.txt