VMware migration tool: we need your feedback!
-
the test with @dumarjo showed that there is still a bug during the import. I am still investigating it and will keep you informed, hopefully today or tomorrow
-
@olivierlambert Ok i see now. xcp-ng.org vs xcp-ng.com. Community vs Pro.
I will keep the existing community POC in place. How do i pivot to Pro? Do i reach out to your amazing team for the iso along with support contract?
-
It's off topic but you have both Xen Orchestra and XCP-ng pro support (because they are done by 2 different teams). We can provide bundles with both so you are entirely covered in your infrastructure, not just when you have a problem, but even discussing before about migrating, best practices and having our feedback/advice directly to build the best of the entire stack Feel free to contact us if you want to know more
-
@olivierlambert Yep i am escalating to sales here.
I think I started off things incorrectly. It was my assumption that XO being the hypervisor is the product that's free and the XOA is the licensed product. -
No worries, it's not trivial if you don't know anything about our stack, that's why we are working on creating a more unified identity through the Vates stack/Vates virtualization, with everything included (like vSphere includes ESXi+vCenter, Vates Virtualization will include XCP-ng+XO)
-
@michmoor0725 patch is deployed
tell us if it solves the importsource VM should be stopped. Snapshots are only supported till esxi 6.3 for now
-
@florent Thanks for your attention to this. I get a new error now.
vm.importMultipleFromEsxi { "concurrency": 2, "host": "192.168.50.20", "network": "17519ece-8817-4e93-4afd-2a00f96927f0", "password": "* obfuscated *", "sr": "0b002e97-e812-8626-f4e0-2c6267c62296", "sslVerify": false, "stopOnError": true, "stopSource": true, "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)" }
-
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.
-
-
@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