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.

@JamesG Don't bother, I'm in PTO next week; so I may get access to hardware when I'm back.

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

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?

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.

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

When a network share is stalled, the easiest way to get out of it is a host reboot. Or you can try to lazy umount the share and remount it first, but no guarantee.

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

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

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

@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

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?

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