VMware migration tool: we need your feedback!

olivierlambert

As per the documentation, it's asked to be sure you are on the latest commit on master. It solved countless of reports because people (in general) aren't following this simple rule. Since you are not more special than anyone else (there's dozen of new messages per day, I can't check each situation in details as we all offer assistance on our free time here), you should follow it. This is how it works here, and it's not personal, believe me
"Make some effort": this is a community forum and not a paid assistance here. You should adapt your attitude if you want help, because this is really not helping to be rude or ask for help while nobody owe you anything. Being polite is a far more rewarding strategy to have help from others!

Finally, we are fully open source, so you have also the opportunity to bring your knowledge and modify the code, even providing it via a pull request we'll be happy to read/comment and merge. https://xen-orchestra.com/docs/contributing.html for details.

We'll be happy to assist as soon you understand what this place is: a community forum where people assist on their free time and because they want to assist people. Not because they have to. We (I think I can talk for a large part of the community) do not accept people coming and asking for results. You can criticize and report bugs, as long it's constructive and following our doc. If you want a guarantee of efforts or results, you can have pro support with a service you pay for

I hope it's more clear, happy to assist you when it's understood

florent

@stmboyd Hi

I wrote most of the code for v2v migration. Please note that

there is a huge number of things happening in this error, and this error is probably caused earlier during the api call to the ESXI, which is probably linked to a configuration on your part that we should try to handle, or at least identify. And we'll try, but it will take times, to identify it
The real question, is why the storage is missing the soap api call should return it and the code should format it correctly . And that is why we ask for constructive feedback, making different productes talk together reliably is hard.
If the call to the api fail , the connect won't return anything usefull. If it succeed, we won't have much more to show ( maybe a "password/login seems ok ?) That will add one step for everybody , with , in my advice, little additionnal value, but I am not ready to die on this hill if there are other people advocating for it

As @olivierlambert said, as soon as we are working in the same direction to solves this, we'll do our possible.

pedroalvesbatista

No tested yet, as soon some hosts are fine after our PXE enrollments, will test this out.
Any scripts in the house to accelerate a little bit the process ?

florent

@pedroalvesbatista For now we're working on reliability and ease of use, performance won't be easy to improve. The main clue I have, would be to mount the dtastore of the esxi in XO, it may be faster than the HTTP API ( which does a surprising good job given the number of query we make )

But if there are ideas, I would be happy to discuss them.

DangerKlaus

Hi all,
I've hit an issue testing import and not seen the answer anywhere else so here goes.
Setup:
ESX 6.0
XO build from sources

Issue, when importing from vmware I get the following error

vm.importMultipleFromEsxi
{
  "concurrency": 2,
  "host": "x.x.x.x",
  "network": "7286bb98-7207-610c-0519-44bb366d7b46",
  "password": "* obfuscated *",
  "sr": "22c0b692-4837-d527-ec8f-3e258baabbf2",
  "sslVerify": false,
  "stopOnError": true,
  "stopSource": false,
  "thin": true,
  "user": "administrator@vsphere.local",
  "vms": [
    "vm-13048",
    "vm-784"
  ]
}
{
  "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 (/opt/xen-orchestra/@vates/task/combineEvents.js:51:16)
    at Task.#emit (/opt/xen-orchestra/@vates/task/index.js:126:21)
    at Task.#maybeStart (/opt/xen-orchestra/@vates/task/index.js:133:17)
    at Task.runInside (/opt/xen-orchestra/@vates/task/index.js:152:21)
    at Task.run (/opt/xen-orchestra/@vates/task/index.js:138:31)
    at asyncEach.concurrency.concurrency (file:///opt/xen-orchestra/packages/xo-server/src/api/vm.mjs:1372:58)
    at next (/opt/xen-orchestra/@vates/async-each/index.js:90:37)"
}

I've tried via host and vCenter ip, via thin and thick, snapshot and no snapshot. Also tried via command line.

Any ideas?

olivierlambert

Hello!

Do you have the same issue with XOA on latest? Is your XO from sources is fully up to date on latest master commit?

DangerKlaus

Hey @olivierlambert

I'm using Jarli's install/update script and I ran an update and test before I posted so believe the answer is yes.

This stack (XCP) was only built in the last 24hr so everything is pretty much up to date.

olivierlambert

Okay I would also try with a fully updated XOA on latest channel to compare with your source install. If the result is the same, then @florent will take a look

florent

@DangerKlaus can you try importing only one VM , to see if we have another error message ?

DangerKlaus

@florent It's the same error regardless. Currently testing official XO and will report back asap.

olivierlambert

Don't forget to register/update and select "latest" on the release channel. Thanks for your feedback!

DangerKlaus

@olivierlambert Okay, there is definitely a difference. I've kicked off a migration and I'm getting a spinning wheel on the import button rather than a flat out error.

So I guess is the issue is with source??

olivierlambert

Well, that's a possibility yes. And that's the point of XOA: we test it and we control the environment, so it's a LOT easier to provide pro support for it. Many things can be different on the sources (node version, libs or deps version breaking stuff and such).

At least, that's an interesting feedback that either something new since latest XOA broke on master, or the installation is broken.

Please let the migration happens and let us know

DangerKlaus

@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

olivierlambert

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.

Flying9167

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?

olivierlambert

@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

Flying9167

@olivierlambert

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

olivierlambert

Are you sure the halted VM doesn't have any snapshot?

michmoor0725

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: undefined

ESXi 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)"
}