VMware migration tool: we need your feedback!
-
@olivierlambert
Quick update. Import via XOA finished overnight with no error.I can keep both XOA and source running in parallel for now if you need me to do any more testing
-
Great news then! The tool will stay free in XOA Free anyway, but as soon as we can, we'll see if we can reproduce the issue on
master
on our side. If not, maybe you need to wipe/re-clone/rebuild the XO source folder in case. Double check your node version too. -
I'm getting the same error from sources and from a fresh XOA fully updated on Latest channel even started a trial of premium. Any ideas?
-
@Flying9167 without providing more info on the error nor the VMware version you use, or if your VM is running or not, it's hard to help
-
I'm running ESXi 6.7 update 3, trying to transfer a Windows 2019 Server, running or halted I get the same error, I have tried several other vms with the same result. Tried different storage and network options too, all same result.
Import Property description must be an object: undefined
Running XOA on latest with trial enabled fully up to date, two hosts in pool fully up to date.
vm.importMultipleFromEsxi { "concurrency": 2, "host": "192.168.150.39", "network": "d41468b9-53d8-63af-b474-d3062625ce10", "password": "* obfuscated *", "sr": "1477ad1f-0d29-ec1f-fa8e-7b8d3bb04ae4", "sslVerify": false, "stopOnError": true, "stopSource": false, "thin": false, "user": "root", "vms": [ "21", "20" ] } { "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)" }
Even selecting just 1 vm at a time produces the same error
-
Are you sure the halted VM doesn't have any snapshot?
-
New user to XCP-NG.
Testing the migration from ESXi and i am getting the following message in log.
Property description must be an object: undefinedESXi client is version 8.0.0
I am able to connect from XCP-NG and see my VMs but cant import any of them. Is there another workaround than using XOA?
edit: I have tried suspending and shutdown my VM on ESXi and still get the same error.
vm.importMultipleFromEsxi { "concurrency": 2, "host": "192.168.50.20", "network": "61289739-1df5-c88d-770c-78287d9d72a5", "password": "* obfuscated *", "sr": "0b002e97-e812-8626-f4e0-2c6267c62296", "sslVerify": false, "stopOnError": true, "stopSource": false, "thin": false, "user": "admin", "vms": [ "1" ] } { "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)" }
-
You need to be sure the VM is halted and doesn't have any snapshot
-
@olivierlambert to be clear as i mentioned in my post, the VMs are shut down.
-
Are you using XOA on
latest
channel? My question holds regarding the presence of a snapshot for this VM -
@olivierlambert just about to edit my comment
There are no snapshots. I shutdown the VM at the time. -
@florent will take a look tomorrow (it's V-day here)
-
@olivierlambert Understood. I also have a support ticket open as well to track.
Has this been tested on ESXi 8.0.0 ?
-
I'm not sure, but without any delta mode (no snap and VM halted) the format (full) should work. Maybe there's something else in 8.0
-
@olivierlambert the plot thickens. Iβm still in POC mode so no production impact. With so many VMs I would like to transfer and test the migration tool would be helpful.
Anyways, Iβll wait for your testing. Enjoy the holiday -
yep I had no snapshots my side either and same error
-
@olivierlambert hello! I donβt have the patch pushed to my XOA. Do I need to do anything to get the fix? I have the support tunnel open
-
Well, you have to wait a bit for @florent to put the patch on your XOA, and since you are on the community forum and not with pro support, you have to be a bit patient until we can do that on our free time Stay tuned and keep the tunnel opened At worst, we'll have a patch release in XOA this week (Friday maybe).
@Flying9167 this is now fixed on
master
branch. -
@olivierlambert woohooo! Thank you team - have just tested on XOA built from sources and its working!
If I give my XOA more CPU and/or RAM will it speed up the import? Is it bound to the resources of XOA? I'm getting 7.5MiB and have got 20MiB before but no more. My hardware (both sides) does support reads and writes at over 500MiB across my 10Gb link.
-
It's XO from the sources, XOA is Xen Orchestra virtual Appliance (the turnkey thing you deploy as a VM directly)
Regarding the speed, it depends but since we have to read from Vmware API, then convert it on the fly, then read twice to avoid thick provisioned, it's not fast. However, you can have warm migration if you have VMware 6.5, so it's kind of automatically spawn on destination when done.