@Pilow - so...I powered down the VM and re-attempted the RPU. It seems snapshots is a deterrent for being able to perform a RPU, because I see VMs migrating now so the RPU can run. For specificity - yes, my XCP Hosts are identical (CPU, RAM, etc); there were no affinities set (see screenshot) [image: 1763483116773-cf9b9ae2-5363-4b66-b367-1b0474e54538-image-resized.png] , etc. Thank you for the assist! I think @olivierlambert or his tech writers need to update the RPU requirements area of the docs. Snapshots cannot be present or RPU will fail. Weird why that is

Hi, I just responded to your ticket with the steps to update XOA to match your new license. Regards, Dan

-= Update =- Tried to expose the Unraid server container to the host network, everything seemed perfect and pings work both ways, while nfs still giving me the same error only for mounting remotes (both from QNAP and the same host Unraid server. I decided to install another fresh XCP-ng host server just to eliminate my first host configuration, but I got the same result, remotes would not mount. The last idea was to remove the XOA container VM running on the Unraid server and download the prebuilt XOA VM image directly from the XCP-ng host. This gave me a timeout error when trying to mount off QNAP with permissions set to both the new XOA IP and the XCP-ng host IP. remote.test { "id": "7903a500-ee84-43dc-bd3e-b6c7abe8381b" } { "shortMessage": "Command failed with exit code 32: mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b", "command": "mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b", "escapedCommand": "mount -o hard -t nfs "192.168.45.20:/LAB-NFS" "/run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b"", "exitCode": 32, "stdout": "", "stderr": "mount.nfs: Connection timed out", "failed": true, "timedOut": false, "isCanceled": false, "killed": false, "message": "Command failed with exit code 32: mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b mount.nfs: Connection timed out", "name": "Error", "stack": "Error: Command failed with exit code 32: mount -o hard -t nfs 192.168.45.20:/LAB-NFS /run/xo-server/mounts/7903a500-ee84-43dc-bd3e-b6c7abe8381b mount.nfs: Connection timed out at makeError (/opt/xo/xo-builds/xen-orchestra-202511150402/node_modules/execa/lib/error.js:60:11) at handlePromise (/opt/xo/xo-builds/xen-orchestra-202511150402/node_modules/execa/index.js:118:26) at NfsHandler._sync (/opt/xo/xo-builds/xen-orchestra-202511150402/@xen-orchestra/fs/src/_mount.js:68:7)" } BUT If I configured a completely unsecured public NFS share on the Unraid server, I then managed to get it mounted successfully. (using the XOA vm running on the XCP-ng host. When I changed the share to Private with granting permissions to the IP of the host and the XOA VM IPs, I get permissions denied yet again. At this point, I'm at a loss, there must be a way to grant access to an IP and make it work with remote. Clearly, I know how to grant permissions as the NFS SR and the Unraid mount of the secured NFS from QNAP are working with no issues. Must be something stupid I'm missing.

https://forums.veeam.com/kvm-rhv-olvm-pve-schc-f62/xcp-ng-not-showing-as-virtualization-source-after-restore-t101040.html Et voilà suffit de demander

@WorkAccount1000 Prior to myself finding that option in the config file use to run this command that worked as well.. cd /opt/xo/xo-web sudo yarn run turbo run build --filter @xen-orchestra/web

@Bill.Oliver license-wise should be the same. now I think virtualisation gurus here could try to explain you what are the challenges with numa and dual sockets i have notions, but couldnt explain quite the optimisation in xen

@bvitnik indeed, RTFM i'm a newb on cloud-init, and should follow more this good advice !

@wezke said in Ansible Role - Install XO from source - Now available: @probain Thank you for sharing your ansible role, ill have a look at it It's far, far from perfect. So there might be a few rough edges that I solved manually. But I welcome feedback.

I will leave the @Team-Storage to answer that

On the bottom of each documentation page, there's an "Edit this page" link you can use to contribute

@florent Sorry for the late reply, yes, we had previously tried that setting and found that it did not provide any speed increase in our case. One thing to note is that we do have our backup jobs configured to merge backups synchronously, we're starting to test some of our jobs with that setting disabled. We had originally turned it on because we experienced a lot of backup failures due to locking errors. We've since added additional proxies as we've found that the amount of data that a single proxy can backup in a nightly window was the primary bottleneck in our environment. Since adding the additional proxies we've started disabling the synchronous backup merge for several of our jobs and so far it has been working pretty well and our backup times have been running faster (obviously since the final merge was the vast majority of the time that we observed in our backup steps).

Starting from Other install media with BIOS (not uefi) is the only combo that is working with Terraform