V2V - Stops at 99%

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

nikade

@florent it was 2 windows vm's, both with 100gb but not even 50% filled.

Edit: All Linux VM's worked tho.

florent

@nikade TBF I was expecting from multi TB VM imported through qcow2

nikade

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

florent

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

the logs are in a stderr file in $tmpDir ( they can be quite big )

nikade

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

Danp

@nikade I believe that you can still find the entries in the journalctl output.

nikade

@Danp Yeah? How?
Let me know if you want me to grab some logs for you guys, if it's still interesting.

florent

@nikade can you try a journalctl | grep 'nbdkit logs' ?

new branch with more fixes ( feat_exposes_esxi_export ) the main fix is a >= that should have been a > https://github.com/vatesfr/xen-orchestra/pull/9411/changes#diff-f0de876ee608dac8d272996fbb8fa63ec76473bd260ad5abf1995a805866d1beR130 hopefully I am not paid by the character. Don't forget to do a yarn build at the root of your XO and restart it.

this also expose a way to export a disk from an esxi/vsphere with xo-cli.

First install xo-cli with npm install -g xo-cli and register it https://docs.xen-orchestra.com/architecture#xo-cli-cli

xo-cli.mjs esxi.exportDisk host=ipOfEsxiOrVsphere user=EsxiLogin password='PlzDontEnter!' vm=3 disk='scsi0:0' @=/mnt/ssd/export/out.qcow2 format=qcow2

You can check that the export is valid with qemu-img check /mnt/ssd/export/out.qcow2

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed feat(xo-server): expose an api method to export a disk from vmware #9411

nikade

Thanks @florent - I can see some of the export logs, but not this particular window-vm, unfortunately. Probably because its too far back in time:

Dec 27 21:33:19 xoa xo-server[845]: 2025-12-27T21:33:19.667Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] DEBIAN 11 observium.iextreme.org/DEBIAN 11 observium.iextreme.org.vmdk are in /tmp/xo-serverG5cHF7
Dec 27 21:36:22 xoa xo-server[845]: 2025-12-27T21:36:22.559Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] Windows Server 2022 veeam2.iextreme.org/Windows Server 2022 veeam2.iextreme.org-000005.vmdk are in /tmp/xo-serverqv0XVK
Dec 28 00:32:35 xoa xo-server[845]: 2025-12-28T00:32:35.287Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] DEBIAN 11 observium.iextreme.org/DEBIAN 11 observium.iextreme.org.vmdk are in /tmp/xo-serverfqb8lP
Dec 28 15:28:09 xoa xo-server[845]: 2025-12-28T15:28:09.050Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] DEBIAN 11 observium.iextreme.org/DEBIAN 11 observium.iextreme.org.vmdk are in /tmp/xo-serverxcV6N7
Dec 29 20:13:27 xoa xo-server[845]: 2025-12-29T20:13:27.226Z xo:vmware-explorer:esxi INFO nbdkit logs of [datastore2] DEBIAN 11 observium.iextreme.org/DEBIAN 11 observium.iextreme.org.vmdk are in /tmp/xo-servermnF0TD

The observium VM worked at last, but I had to give it 4 tries before it actually worked.

Edit: Right now all my important VM's have been imported, so I don't think we have to spend anymore time on this, unless you want the logs for the observium import.

florent

@nikade any logs can help fix the issue, but don't make too much effort on getting them back. We will meet the issue again one day if we do not have fixed it
(importing data is fairly honest : any missing bits and the xapi, the file system or both explodes immediatly)

nikade

@florent I'll send you a link in DM, hope it helps with something.
If not, it wasn't too much of an effort, thanks for your time so far