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

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

@florent yeah that is what i did deploy xo-ce while waiting for a response. I still have 3 more vms to migrate. I so i will continue this route for the migration. Thank you for the confirmation.

@dinhngtu Thanks. I did verify that it does not have the revoked version on any of the hosts. I've also verified that this is only occurring with Windows 2025. I can V2V Windows 2022 or any Linux distribution that we've tried, without secure boot issues. Also, a fresh installation of Windows 2025 doesn't have the issue. I've opened support ticket number 7747017 for this issue. Hopefully someone can get it figured out. Thanks. Allen B.

@Biz365 Warm migrations from ESXi are ESXi license dependent on what you have/had with ESXi. Otherwise you can replicate the VM using the migration tool and then manually shutdown the VM on ESXi and then power it on XCP-ng.

If XO from sources, double check you are fully up to date in the first place. You maybe used an outdated V2V code that wasn't asking for the template, causing the issue you experience now.

@PaulDCL [image: 1757633451167-9eb17eb5-9a99-4743-9df5-51edcc2b1847-image.png] This benchmark was taken inside the Windows Server VM on that iSCSI device. The iSCSI host is a QNAP NAS with Toshiba 18 TB drives configured in RAID-6. I think this is a decent speed for non-flash storage. Both devices are on a 10Gbit network. If you need more specific details, I'll be happy to help.

I had this tab still open which lets me realize that despite we packaged vmfs6-tools and updated the documentation at https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/#local-migration-same-host, we didn't inform you here. Now it's done

@AtaxyaNetwork I appreciate the sentiment. I think this one is all on me as pointed out by @Danp .. My VDI's would not register without this step. I'm unsure as to why because the error logs were completely blank within XO. Your post in conjunction with the docs were extremely helpful though!

Great! Thanks for the feedback

@Greg_E thanks for the clarification.

@olivierlambert Excellent news!!! I will keep my eyes on that, and provide a tests! Thank you!

Yes, even if there no code, there's a lot of pushing on our end to make it happen on their side

Before the end of this month.

On DOM0 (host xcp-ng) traffic is filtered by iptables. So iptables -L will show which ports are open. Everything else will be rejected by default. For testing, you can stop iptables. If that helps, add rules. Keep in mind that XCP-NG is based on CentOS. So you can easily find an answer on Google for any question.

Fix committed upstream.

@DustinB it's there on mine as well. Going to test it in a couple of weeks. Lots on the docket! Thanks again, everyone.

@afk said in What is the status/roadmap of V2V (Migrating from VMware to XCPng/XO) ?: Great news ! Thanks @olivierlambert and @florent and let me know if you need some information on the vmware side. yes we are prototyping with vddk , it should open some interesting possibilities. stay tuned, hopefully by the end of the summer (I am saying it again : for a prototype) as a shameless plug, we are looking for users with VSAN to ensure we don't break thing for it

I probably would have just bought a cheap mini PC and used Virtual Box for this, which is something I did do in the past for an old XP machine when the hardware started to fail. Grabbed a disk to vhd of it before the final failure and loaded it into Vbox. Might be able to do this in nested virtualization in XCP-ng.

@iLix The sizing of the VM in XCP-NG was bigger compared to the source