V2V - Stops at 99%

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

draft 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