V2V - Stops at 99%
-
Wait for vates to reply for more technical information. Take a look at this - https://xcp-ng.org/blog/2025/10/16/qcow2-beta-announcement/
you are at 1.5tb so I think you should be ok with out qcow2 support. I personal had some performance and other issues with it and disable as I didnt need 2tb support yet.
-
@tsukraw hard to answer as is
do you have anything in your xo log ( console / journalctl ) or in the task log ?
If not, the log of xo should say something about " nbdkit logs of ${diskPath} are in /tmp/xo-serverxxxx"
can you check if there is something at the end ?1.5TB is ok in vhd
-
@florent
I'll add some more on this.
I did attach the task log here.
.tasklog.txtNow I did have to restart the toolstack as I wasn't able to cancel the migration task (after it hung). As stated, it hangs at 99% and says "estimated 3 minutes" to complete. I have left this run for over an hour but still says 99%.
I have tried this multiple times but get the same result. Support did mention to try and kick off the import via CLI which was tried in my last attempt. Unfortunately, same result.
I'm new to XCP, but you mention "xo should say something about " nbdkit logs of ${diskPath} are in /tmp/xo-serverxxxx" do you know where exactly I can pull those? Tried looking under /var/log of XOA but not seeing what you mention.
Side note. After restarting the toolstack and going into storage I could see the drives for that server. For testing I did create a new VM and attached those existing disks. The VM did boot up and the data drive was there and accessible. Though skeptical as technically the migration of that drive didn't get to 100%.
-
@dnordmann said in V2V - Stops at 99%:
you mention "xo should say something about " nbdkit logs of ${diskPath} are in /tmp/xo-serverxxxx" do you know where exactly I can pull those? Tried looking under /var/log of XOA but not seeing what you mention.
You can check to XO logs by running the command
journalctl -u xo-server -f -n 50from the CLI of the XOA VM. -
Thank you for pointing me in the right direction for those logs.
I have attached those here.
Disk that seems to hang at 99% is WE-FS1/WE-FS1_1.vmdk. I see in the logs "Error: task has been destroyed before completion" but this would have been me from restarting the toolstack as the task just hangs there. I don't see much info/errors before.Tried a couple of times to migrate this machine so might see a couple of attempts.
11/14 @ 2:05 ish
11/14 @ 7:41 ish
Logs.txt -
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-serverCFf19tThe 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/0mi0ogg5gThe 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 -
Is there anything in the logs he provided that stand out?
-
@dnordmann @tsukraw
thank you for your patience, we found something while working with the xcp storage team, and there is an issue with the last block sizeCan you confirm that the failing VM has at least one disk with a disk with a size not aligned with 2MB ?
Could you test this PR on the failing import ? https://github.com/vatesfr/xen-orchestra/pull/9233
regards
-
@florent
Thanks for the update on this. I have confirmed the 2 clients that we are having issues with the data drives are not divisible by 2MB.How do we go about applying this patch?
-
@dnordmann if I remember well you have opened a ticket on your xoa , can provide us the ticket number and we can patch your xoa ?
if you are using xo from source, you need to change branch and then restart xo-server
-
Ticket#7747444
and I just opened another ticket for the other client that is having the same issue. Ticket#7748053.
Support tunnels should be open for both clients.
Thanks!
