@joeymorin try to check the merge backup synchronously to avoid other jobs messing with this one ?

@Andrew What a day... Have two hosts and needed a RAM upg so scheduled these with OVH, one for 4pm and the other for 8pm. Plan was to migrate the VMs off the host being upgraded to maintain uptime. Got an email from OVH stating that due to parts availability the upg will not proceed and then they downed both hosts at 8pm to upg at the same time and that caused havoc today.

@acebmxer thank you for testing and confirming! For those who try this... NOTE WSL 1 has the issue of throwing the error Failed to take /etc/passswd lock: Invalid argument https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2069555/comments/12 Here is a fix sudo sed -i -e '/systemd-sysusers/s/.conf$/.conf || true/' /var/lib/dpkg/info/*.postinst sudo apt --fix-broken install

Did some more testing over the weekend and got some cleaner logs that are fully matched up. We ran the command 'journalctl -u xo-server -f -n 50' and see these to entries: Nov 15 14:26:10 xoa xo-server[552]: 2025-11-15T19:26:10.935Z xo:vmware-explorer:esxi INFO nbdkit logs of [WE-DS] WE-FS1/WE-FS1.vmdk are in /tmp/xo-serverGKTRzl Nov 15 14:26:10 xoa xo-server[552]: 2025-11-15T19:26:10.943Z xo:vmware-explorer:esxi INFO nbdkit logs of [WE-DS] WE-FS1/WE-FS1_1.vmdk are in /tmp/xo-serverCFf19t The log files were fairly large, wouldn't allow me to attach them, so i have provided them in a zip on dropbox if you want to take a look. From what I can pick out in the log files it appears that the transfer from VMware is complete or so it looks that way. After that I ran these two commands against the import tasks: xo-cli rest get tasks/0mi0ogg5f xo-cli rest get tasks/0mi0ogg5g The output for those is also attached. The one thing that stands out is in the "importing vms 17" is that WE-FS1.vmdk shows 'success' and WE-FS1_1.vmdk shows 'pending' Finally, I attached the logs from the host as well. I'm not seeing anything that jumps out at me as being wrong there either. Zip file of logs: https://www.dropbox.com/scl/fi/glxm5tvebf5vjizpnfvmx/Package-of-Logs.zip?rlkey=uyl0kltxhfnfcq0carbrg0lrv&e=1&dl=0

Maybe that's my issue ? Investing this part # journalctl -k | grep -i nvidia [image: 1763219509282-aaed86b6-1384-434e-ac5d-bca510405f33-image.png]

@nikade to be noted, on XO6 this bug does not exist anymore !

@bogikornel said in Cannot migrate a vmdisk: @ashinobi Known issue ... https://xcp-ng.org/forum/topic/11538/failed-to-migrate-vdi-two-local-sr/5?_=1763186433370 Thank you so much for letting me know. I'll follow your post so I can update that if they need more info on what is happening.

@psafont Sorry was swamped with other things. As listed above I get the same error, forced or not, from xcp-ng center, xcp-ng host, or xoa. [image: 1763153778372-1fdda333-0842-4281-ae69-e6c886ec1542-image-resized.png] tls verification has always been off, and in the past we have not had issue with adding new host to pool. I have taken no other actions since my last posting.

Just a quick update. I tried changing the time to see if somehow doing it at midnight was causing the issue. I also tried changing the destination for the health check to restore to in case it was some issue with the HDD. Neither were successful.

@tsukraw we will have to improve the doc First migration : [vm source] => [vm on xcp] Check [vm source] => [vm on xcp] => [copy/clone of vm on xcp] test on [copy/clone of vm on xcp] <-- remove [copy/clone of vm on xcp] Final migration stop [vm source] launch the same migraiton. The data already transfered won't be retransfered applues the fixes you had to do during previous test start [vm on xcp]

@Danp My apologies for not being more specific. I’m encountering an issue with XOA deployment on a home lab environment. Environment Details: Installation source: USB Hardware: 16GB RAM, 1TB NVMe HDD Initial install: Completes successfully Dashboard: Displays expected status Steps Taken: Installed XCP-NG from USB — installation and setup completed without errors. Verified dashboard — all components appeared healthy. Deployed XOA to the existing HDD — process executed as expected. Observed Behavior: After deployment, XOA appears healthy overall, but the final item labeled “NEW” does not appear in the interface. Expected Behavior: The “NEW” item should be visible after deployment. Mark

@Pilow You might be right, this may be simpler to implement than we imagined. We'll keep you informed when we progress on this.

Thanks @Pilow for the test

@olivierlambert can we report documentation issues or can we contribute to docs? I would fix myself if I can.

@rizaemet-0 I've also enabled SAML and the login interface is a little bit odd, not only the remember me button but also the capitalization of SAML which is lowercase. It is a cosmetic issue, but still an issue.

@olivierlambert Yes I previously was. now back on VHD. This was in my home lab, not work enviorment.

@bvitnik Thank you for the great response. I have had great success with Terraform - great work. I'm not touching ocaml myself. And yes, Citrix... they are still above VMware/Broadcom on my list. But SMH. I keep promoting XCP-ng hoping some large companies take advantage of it. It's much more valuable to me than nautobot, for example.

To anyone still having this issue or finding this thread when searching online: "How to clone a VM between hosts in Xen Orchestra" or similar... The key piece of information missing from all these answers is that you must first connect both hosts (XCP-ng) servers to the same Xen Orchestra instance before you can clone (copy (export/import)) a VM from one host to another while using the Xen Orchestra GUI. Note that as mentioned in the first reply that this is only one solution, given both hosts can see each other over the network. You can also manually export and import the VM as an image file to your local PC's storage if needed. To do this, first navigate to "Settings->Servers" and configure/connect the destination host alongside the existing host so you end up with two hosts connected to the same Xen Orchestra. Note that Xen Orchestra can display information and manage multiple hosts if required (does not have to be tied to a single XCP-ng instance). Then navigate back to "Home->VMs" and you should now see all VMs listed for both hosts in the same list. From here you can select the VM to clone and from the copy dialog menu when you select a "SR" you should now be able to select between both host's disks (Local Storage or Pools) to copy the VM onto. Note that this command will spin up two separate tasks: an export and import task simultaneously on each host to complete the copy (sort of streaming it at the same time). Also don't forget to first shutdown the VM first before you copy it so you do not risk losing/corrupting any live data while it is cloning. Hope this helps everyone.

Adding this to our topics to discuss

Since GPU passthrough is involved I'd ping @Team-Hypervisor-Kernel