@john.c said: nd need to be cleared, before re-attempting the update. Checking the logs will help Just for completeness... it kept doing this after all the typical diagnosis steps. So never found a solution Definitely wasn't cache or disc space related. In the end I built the XOA from source on the same VM and that worked fine. Although subsequent to that I've moved XOA to the containerised version thus saving an extra VM!.

@irtaza9 i would look a the usual suspect, /var/log/SMlog /var/log/xensource.log see https://docs.xcp-ng.org/troubleshooting/

So I ended up going with the Windows B&R as i could net setup the windows mount server when setting up the repo for the backups. It would setup the linux one but not the windows one. This was with using the veeam console from a windows client. So i ended up with the Windows one. Now after a few backups i am see this warning / error.... 8/5/2026 5:34:50 PM Warning : Failed to use CBT: [Task e75c4247-2ee1-7b51-088c-b970ace60f3d (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated] First i thought it was because i maped the new job to older backups from Beta v1. So i purged all old backups and started fresh. The full backups were successful. Now on first delta 4 out of 7 vms have that warrning. This a Veeam issue or xcp-ng?

What kind of storage are you using? Is it a 4K block native storage? You should be able to see if you can create a virtual disk easily with xe vdi-create name-label=test virtual-size=1G sr-uuid=356475ac-…

Hi, I found your original request. I will make sure someone from the Sales team responds ASAP. Regards, Dan

If i recall from my migration I belive thats all there is to it. I know the docs mention about doing a test migration but mine just migrated and it just worked as you stated after making the needed adjustments. Let other chime in but i think you are good to go. And you could delete the snapshot from the vm.

Very cool, thanks for the feedback @maximsachs !

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.

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

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.

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

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

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

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

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.