V2V - Stops at 99%
-
@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! -
@dnordmann said in V2V - Stops at 99%:
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!I deployed the patch on the new client, if it's ok I will do the second one after
-
@florent
Didn't see your message until now about only applying the fix to only 1 client.I did do a warm migration on client with ticket #7748053. This completed without issue!
I tried a warm migration on client with ticket #7747444 and this failed again. Sounds expected as the patch was not on this one yet.Can you push the patch to client with ticket #7747444. Thanks!
-
@dnordmann the tunnel is closed. By the way the patch will be release tomorrow on latest, by the end of december on stable
thank you all for your patience and your help identifying the root cause of this bug
-
@florent
Thank you very much for your quick help on this one.
The patch resolved the issue for both migrations we were struggling on.It is fantastic to see the teamwork and a resolution developed so quickly.
Really makes us feel confident in knowing we made the right decision with going to XCP-ng for our clients.Thank you
-
Thanks for your feedback @tsukraw !
-
I'm seeing something similar, not sure if its the same issue, but mine stops at 95% and just hangs there:
[12:18 sto-xcp1 ~]# xe task-list
uuid ( RO) : c1056d36-b195-056a-4121-e82d7fc851fb
name-label ( RO): [XO] Importing content into VDI [ESXI]DEBIAN 12 fiona.iextreme.org-flat.vmdk on SR Local storage
name-description ( RO):
status ( RO): pending
progress ( RO): 0.950The nbdkit debug-log can be found here:
https://mirror2.iextreme.org/temp/stderrEdit: some additional info
Xen Orchestra, commit 1640a
Master, commit 1640a -
Did you solve the problem?
If you are looking for another migration solution, you can also try Vinchin Backup & Recovery, which migrates VMware to XCP-ng by restoring VMware VM to XCP-ng host.
-
@Vanny we are still working on the issue which seems to be partly due to the new V2V code, and partly to qcow2 supports.
Note that the v2v tool is a convenient tool, but there are a lot of good tools out there, and some may better fit your needs after testing.
-
FYI, Vanny is a representative from Vinchin
-
Got most of them working, except 2 of the bigger ones.
-
@nikade we'll got them ( on monday )
could you remind me the exact size of the disks ? to check for an alignment issue -
@florent it was 2 windows vm's, both with 100gb but not even 50% filled.
Edit: All Linux VM's worked tho.
-
@nikade TBF I was expecting from multi TB VM imported through qcow2
-
@florent Sorry to dissapoint you
Can you remind me where the vmware-import logs are stored on the XO machine? I can see if I still have them for you, it could be an alignment issue. -
@nikade this is a good news : that will be easier to test and debug.
during an import you should have a
nbdkit logs of ${diskPath} are in ${tmpDir}where diskPath is the datastore/diskname.vmdk and tmpDir is something like /tmp/xo-serverXXXXthe logs are in a stderr file in $tmpDir ( they can be quite big )
-
@florent Oh shoot! So only during the actual vmware import? I guess they're gone now then
Sorry I couldn't be of more help! -
@nikade I believe that you can still find the entries in the journalctl output.
-
@Danp Yeah? How?
Let me know if you want me to grab some logs for you guys, if it's still interesting.
