VMware migration tool: we need your feedback!

michmoor0725

@olivierlambert Understood. I also have a support ticket open as well to track.

Has this been tested on ESXi 8.0.0 ?

olivierlambert

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

michmoor0725

@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

Flying9167

yep I had no snapshots my side either and same error

michmoor0725

@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

olivierlambert

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.

Flying9167

@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.

olivierlambert

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.

Flying9167

@olivierlambert Oh roger that, I didn't realise the distinction!

michmoor0725

@olivierlambert Ahh ok. Im still new to the whole process here so forgive me.
Can you clarify something for me? I have premium support now but im on the community forums (here). Is there another channel i can use to get the issue addressed in accordance to my license level (community vs preimum). Does this affect the open ticket i have with support?

olivierlambert

If you have XOA with pro support, the first reflex is to go for the pro support and create a ticket. You have the guarantee to have an answer and dedicated resources given in a reduced timeframe.

Here, it's only "a bonus", and we try to help, but there's 0 guarantee.

florent

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

michmoor0725

@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?

olivierlambert

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

michmoor0725

@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.

olivierlambert

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)

florent

@michmoor0725 patch is deployed
tell us if it solves the import

source VM should be stopped. Snapshots are only supported till esxi 6.3 for now

michmoor0725

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

Wolfraider

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

julien-f

@Wolfraider This error was fixed a couple of days ago (https://github.com/vatesfr/xen-orchestra/commit/5c436f3870e39776128369d154bcaa23a126ac59), please upgrade.

0

julien-f committed to vatesfr/xen-orchestra

fix(task/combineEvents): defineProperty → defineProperties

Fixes zammad#14566