I have a theory that I'd like you to test on a specific branch. It might be an Undici bug, but I'm far from being sure. You need Node >=22.19 to make it work. Switch to the branch named fix_undici_paused_parser_crash, build it and try again.

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?

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 @stac00 Any progress or additional thoughts on any of this discussion?

@dinhngtu Fantastic - thank you for thinking of and including that!

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.

@TeddyAstie I think there's alot of interest in the Intel platform because of the lack of ridiculous licensing for virtualization features. The problem is that you need a pretty current 6.x kernel to use them and XCP-ng/XenServer is just stuck on a really aging kernel right now. As exposed in this thread, the PCIe pass-through isn't really working properly under XCP-ng. Even if pass-through worked, that's kinda lame because the real purpose would be to chop up the GPU into SR-IOV instances so multiple workloads could have a GPU. The Proxmox community is already rockin' and rollin' with this. I watched a video a couple of days ago where a B70 was chopped up into Qty.4, 8GB GPU's via SR-IOV and passed to clients. No ridiculous mega-$$$$ licensing. It just worked.

I have also opened a support ticket with Veeam. Well trying to... Issue with my account preventing me to and working to fix that issue. Veeam forum did make this statment about CBT and snapshots - There is one known snapshot issue that I'm guessing could possibly have this side-effect (noted in the release notes BTW). We take standard Xen snapshots for CBT but then immediately rename them with our own naming convention. We've noticed that sometimes this rename operation returns success status even if it fails. In this case I can see how this might throw this sort of error but again best to confirm w/support Veeam support ticket - 08188639

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

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-…

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

@Danp Thanks for that command, I had a similar command I found but it didn't display the timestamp fully so I couldn't pinpoint the time of the message, but I had a feeling this was there the issue was. [Fri Aug 7 16:26:44 2026] CIFS VFS: Server 192.168.x.x has not responded in 120 seconds. Reconnecting... Lots of these types of messages since yesterday. And df -h does hang as that's something I was testing yesterday when debugging to see if some disk had got full that I hadn't spotted. There has definitely been a few network disconnects over the past 24 hours as I was testing various things which requires a bit of fiddling with the cables and jumping between networks, and it's quite possible that this happened during the backup window but I can't recall for sure. The Storage Repositories are all reporting as working correctly in XO, XOA, XCP-ng Centre. What's the next steps to fix this? I assume there is a way without deleting the Storage Repository in either XO/XOA/XCP-ng Centre and re-attaching it?

@yllar Hello, We are still validating the ISOs, but we are getting closer to releasing them. We hope to make them available soon.

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

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 !

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

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