VMware migration tool: we need your feedback!
-
We are seeing the "Property description must be an object: undefined error also". VM has been powered off on the VMware host and no snapshots exist. We have updated to the latest release channel. ESX version 6.7. We have opened a support channel if you would like to look around.
vm.importMultipleFromEsxi { "concurrency": 2, "host": "XXXX", "network": "97f6e5a8-ff82-cf56-44ef-fabe3c2217a2", "password": "* obfuscated *", "sr": "40a77962-46f6-e871-9751-0748ae322672", "sslVerify": false, "stopOnError": true, "stopSource": false, "thin": true, "user": "XXXX", "vms": [ "vm-143" ] } { "succeeded": {}, "message": "Property description must be an object: undefined", "name": "TypeError", "stack": "TypeError: Property description must be an object: undefined at Function.defineProperty (<anonymous>) at Task.onProgress (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/combineEvents.js:51:16) at Task.#emit (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:130:21) at Task.#emit (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:124:17) at Function.set (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:47:17) at file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:1388:20 at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:149:22) at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:134:20) at asyncEach.concurrency.concurrency (file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:1372:11)" }
-
@Wolfraider This error was fixed a couple of days ago (https://github.com/vatesfr/xen-orchestra/commit/5c436f3870e39776128369d154bcaa23a126ac59), please upgrade.
-
Has anyone seen this type of error before?
-
@michmoor0725 If the detail is not the same as your previous message (
vm.importMultipleFromEsxi
), please copy/paste it to help us investigate -
@julien-f Here is the details from the log
vm.importMultipleFromEsxi { "concurrency": 2, "host": "192.168.50.20", "network": "17519ece-8817-4e93-4afd-2a00f96927f0", "password": "* obfuscated *", "sr": "ea9202e0-dce9-244e-5983-69fea9aab6b8", "sslVerify": false, "stopOnError": true, "stopSource": false, "thin": false, "user": "admin", "vms": [ "11" ] } { "generatedMessage": true, "code": "ERR_ASSERTION", "operator": "notStrictEqual", "succeeded": {}, "message": "Expected \"actual\" to be strictly unequal to: undefined", "name": "AssertionError", "stack": "AssertionError [ERR_ASSERTION]: Expected \"actual\" to be strictly unequal to: undefined at Task.onProgress (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/combineEvents.js:48:16) at Task.#emit (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:130:21) at Task.#emit (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:124:17) at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:137:17) at MigrateVm.migrationfromEsxi (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/migrate-vm.mjs:175:18) at file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:1374:30 at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:149:22) at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:134:20) at asyncEach.concurrency.concurrency (file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:1372:11)" }
-
@michmoor0725 The same as the previous one then.
Which commit are you on?
-
@julien-f Im new to this so not really sure how to answer that question.
xo-server 5.113.0
xo-web 5.116.1I can PM my support ID if you need to poke around.
-
@michmoor0725 If you are using an official XOA, I think the best would be to wait for the future patch release (very very soon) and re-test after having upgraded
-
-
@michmoor0725 XO 5.82.1 has just been released in the
latest
channel with a few bug fixes, please let me know if that helps. -
@julien-f well well well....lol...
You are correct. There is an update and im able to import from VMware. No error messages so far.
Taking about 40 minutes or so but i dont know if thats good or not. I selected a NFS storage thats running on mechanical disks so i suspect thats the bottleneck.I will keep everyone here up to date if i run into any issues.
Job well done you guys/gals. Job well done -
@julien-f VM has been imported but the problem now is networking.
The VM cannot pick up an IP regardless of what network i place it in. The eth0 interface is down. I bring it up no IP. VM is set for DHCP.
I know the vlans work as thats how ive been building test VMs which are configured with a dhcp scope.For example, ive built a DMZ Host from XO. No issue.
Ive imported a VM from ESXi and placed it in the DMZ vlan. No IPI took a pcap from the firewall and sure enough I dont see any DHCP Discover packets at all.
-
disregard. I rebooted the VM a few times but the solution was to force a dhcp renew
$sudo dhclient -
Good news then
-
@olivierlambert Very very good news. Great job on the import tool.
-
I have a legacy host running VMWare 5.1.0, when attempting to execute
xo-cli --register --allowUnauthorized <host> <user>
I receive the following error
✖ Error: write EPROTO C057D8B5357F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1987: at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16) { code: 'EPROTO', errno: -71, syscall: 'write' }
Would VMWare 5.1.0 be too old to transfer via Import from ?
-
Hi,
I'm not sure to understand why are you using XO CLI in the first place? Have you tried from the UI directly?
-
When I try the import from the UI directly I receive the following in the logs:
write EPROTO C0A77278D27F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1987:
I am using Xen Orchestra from sources (commit 6fe79)
xo-server 5.116.3
xo-web 5.119.1 -
Sounds like very old SSL libs that are not supported anymore?
-
This was my initial thought, I tried to drop the MinProtocol to TLSv1.0 in openssl.cnf and recomplile from source. But the error persisted,
Worst case I can look at manually exporting and importing the VMs.