V2V - Stops at 99%

dnordmann

Is there anything in the logs he provided that stand out?

florent

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

Can 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

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed fix(nbd-client): nbddisk must emit full size block #9233

dnordmann

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

florent

@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

dnordmann

@florent

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!

florent

@dnordmann said in V2V - Stops at 99%:

@florent

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

dnordmann

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

florent

@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

tsukraw

@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

olivierlambert

Thanks for your feedback @tsukraw !

nikade

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.950

The nbdkit debug-log can be found here:
https://mirror2.iextreme.org/temp/stderr

Edit: some additional info

Xen Orchestra, commit 1640a
Master, commit 1640a

Vanny

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.

florent

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

olivierlambert

FYI, Vanny is a representative from Vinchin

nikade

Got most of them working, except 2 of the bigger ones.

florent

@nikade we'll got them ( on monday )
could you remind me the exact size of the disks ? to check for an alignment issue