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

Hey Guys.

Got a general question about the V2V conversion.
We have two different clients that we are working on VMware to XCP migrations. Both clients have a half dozen VMs, and in both cases all the VMs migrated fine except for the file servers, which are around 1.5TB each.

Again, completely separate clients.

When running the import, everything appears to be running fine, but the import hangs at 99% and never gets past that.

I'm curious what is the import doing at 99%?
Thinking back to the VMware Converter days, the data move was actually finished at 97% and the last couple percent was configuration stuff. So if a conversation was to fail at 97% you could actually attach the VMDK to a VM and it would still be usable.

I'm curious if the same holds true with XCP if the import would be finished moving data at 99% and something else might be causing them to hang where we could create a new VM and attach the vhd.

(We do have a support ticket open on this issue)

Thanks

@florent

I have read through the guide you have provided but I'm struggling with it.

The guide does not appear to be a full sync and then a delta sync.
The guide appears to be for a per-migration test, which you then delete the test sync and re-run a migration.

This is the step that seems to suggest this:
"Remove the test copy
Once you’ve finished your checks and taken notes, delete the test VM. This will free up resources and prevent any confusion before the final migration."

Hey guys,

We are ramping up our VMware to Vates migrations.

One item that has come up is we would like to be able to use the Warm Migration method mentioned here: https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/

The feedback I have got from our guys is that once you start the warm migration you really lose control. What I mean by this is on the final snapshot, shutdown of the VMware side. This happens when the initial copy is completed.

Without having some form of control, the options cannot be leveraged properly as the shutdown could happen mid-day when the server is being utilized.

Is there possibly via CLI any way to control the final step?
It would be really nice if the final step did not happen automatically, and once the initial sync is completed we had a button or such to trigger final sync and shutdown. That way we could arrange for it to happen after hours.

Just an idea if there is no way from CLI.

Thanks