VMware migration tool: we need your feedback!
-
@magicker
it depends hos you installled xo-server, but in general it's injournalctl -u xo-server
-
Hi,
I have 2 succesfull migrate (Windows and Linux). Windows migrate was successfull but i have to configure network interface after vm opened (as i know this is known issue and about Windows). On the Linux vm (Centos 7) i have regenerate initram and LVM structure, and it is working good now. But today i am trying with different vm's and i am gettin the error below:
xoa@xo-from-source:~$ xo-cli vm.importFromEsxi host=xxxxx user=xxxxxpassword=xxxxx sslVerify=false vm=3133 network=f6c27xxxxxxxx2e5 sr=61e7d4xxxxxxxd8ec3 ā Cannot read properties of undefined (reading 'footer') JsonRpcError: Cannot read properties of undefined (reading 'footer') at Peer._callee$ (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/json-rpc-peer/dist/index.js:139:44) at tryCatch (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:44:17) at Generator.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:125:22) at Generator.next (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:69:21) at asyncGeneratorStep (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24) at _next (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/asyncToGenerator.js:22:9) at /opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/asyncToGenerator.js:27:7 at new Promise (<anonymous>) at Peer.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/asyncToGenerator.js:19:12) at Peer.exec (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/json-rpc-peer/dist/index.js:182:20)
And I am getting this error below. I am sure, My Vm id is correct. I tried clone this vm for change id. But it doesn't changed.
xoa@xo-from-source:~$ xo-cli vm.importFromEsxi host=xxxxx user=xxxxx password=xxxxxx sslVerify=false vm=3161 network=f6c27exxxxxxxxa2e5 sr=61exxxxxxd8ec3 ā VM 3161 not found JsonRpcError: VM 3161 not found at Peer._callee$ (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/json-rpc-peer/dist/index.js:139:44) at tryCatch (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:44:17) at Generator.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:125:22) at Generator.next (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:69:21) at asyncGeneratorStep (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24) at _next (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/asyncToGenerator.js:22:9) at /opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/asyncToGenerator.js:27:7 at new Promise (<anonymous>) at Peer.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/@babel/runtime/helpers/asyncToGenerator.js:19:12) at Peer.exec (/opt/xo/xo-builds/xen-orchestra-202302101204/node_modules/json-rpc-peer/dist/index.js:182:20)
You can see my vm's id in this ss : https://prnt.sc/l29WdT8JVaYy
And my third problem is I have a windows vm around 500 GB and migration continues for 40 hour. There is no status indicator or error message and i can't understand if is there a problem or another thing. I have tried with Xoa before 5.79 update, there was a status indicator on tasks tab. Now I am using XO from source and 5.79 update. I can't see any indicator
I am using:
xo server 5.109.0
xo-web 5.111.0
VMware ESXi, 6.7.0, 15160138 -
@ulasdem I will look into the error message, at least I will make it more informative. How many VM have you in this esxi ? is it more than 100 ?
For the long running import : there is a visible Task only when we reached the importing phase. The first step (when using thin=true) will read the whole disks to detect empty blocks. For now it's visible only in the logs, but we're working on it.
-
@florent Thank you for your message. I have 122 Vm on my one ESXI Host and i am planning to distribute this vms to xcp hosts in our other DC. Does it affecting migration tool how many vms are in ESXI?
-
@ulasdem yes, I think I saw that there is limitation to the api, but didn't reach the limit on our test pools
I will try to work around this
-
Hi!
I did my first migration: Everything looks good!
The only thing, that should be noted:
You need to provide the VM-ID in your script. The ID that is shown through vSphere was not valid for your script. I had to login the the current ESXi-host and to get the ID with:vim-cmd vmsvc/getallvms | grep NAME
-
That will be "solved" with the next release: you'll have a VM selector directly in the web UI
-
@ulasdem can you try this branch ? https://github.com/vatesfr/xen-orchestra/pull/6662
there is a new commandesxi.connect
that should show all the VM of an ESXI ( even after the first 100 ones)@KPS thank you, I note the command
-
Have successfully migrated 2 VMs from ESXI, doing MANY Hyper-v migrations, and have a suggestion / feature..
THIS is likely not the forum for this, but I know you guys are in a similar situation...Is it possible to add within XOA or the XCP-ng Center to allow attaching to a hyper-v cluster and do drag and drop style of migrations from hyper-v to XCP?
I had something similar setup for a past company that allowed me to attach to any type of cluster and manage all from within a single pane of glass ( Until all migrations were complete ) -
@florent I will try this branch and inform you in next week
-
@severhart that would really put the orchestra in xen orchestra , but it would be a huge workload
-
We are potentially investigating if HyperV APIs are friendly to do a similar thing than we do with VMware.
However, we do not have the objective to have XO managing VMware or HyperV clusters (at least, not for the next 3 years)
-
@olivierlambert I understand that, just for the migration purposes is all.. some of these migrations take months, if not years to get complete, and having it all under a single hood while that migration work is being done would be nice... I know that it is a HUGE ask
-
Yeah, each platform got its own logic, that's why having an universal one is very very hard, except if you are a very big company able to have dedicated people on it (while doing all the rest).
I mean, if we can do it, it means we had a huge success, so I won't be against that
-
I have two different behaviour on two different XO instances. Each XO instance refers to a different pool (different hosts, same xcp-ng version). In both the instances I try to connect to the same Private Virtual Datacenter based on VMware/vSphere at OVH.
In the first one I get the following error message by using the web UI: "invalid parameters" (take a look at this logfile 2023-02-28T19_25_21.933Z - XO.txt )
In the second one, I get the following error message by using the web UI "404 Not Found https://<vsphere-ip>/folder/<vm-name>/<vm-name>.vmx?dsName=<datastore-name>"
By using the xo-cli I get the "404 Not Found" on both the instances.
Regarding the "404 Not Found", I want to point out that at OVH I have a VMware datacenter (with 2 hosts) and in order to access to the storage I need to specify the parameter
dcPath=<datacenter-name>
So the right URL should be https://<vsphere-ip>/folder/<vm-name>/<vm-name>.vmx?dcPath=<datacenter-name>&dsName=<datastore-name>
Simply adding (in a static way) the dcPath specification on line :54 of esxi.mjs file makes it work.
-
Interesting, that's probably a parameter we need to add (as optional) in the case it's needed. Would you mind test a dedicated branch when @florent will add it?
-
@olivierlambert Yeah sure! No problem, it'll be a pleasure.
Do you have any idea about the issue related to the message "invalid parameters"? Do you have any suggestion in order to go deeper? Thanks.
-
No but @florent will take a look ASAP
-
For what it's worth I'm seeing the same invalid parameters error when I attempt to perform a migration from an on prem ESXI 7.0U2 host.
Error message:
vm.importFromEsxi { "host": "* obfuscated *", "network": "1fb3daf2-b27d-b7ef-48ce-b8986440247a", "password": "* obfuscated *", "sr": { "type": "SR", "content_type": "user", "physical_usage": 26223620096, "allocationStrategy": "thin", "current_operations": {}, "inMaintenanceMode": false, "name_description": "", "name_label": "Local storage", "size": 964124073984, "shared": false, "SR_type": "ext", "tags": [], "usage": 79456894976, "VDIs": [ "393e3767-07c2-4c23-bdca-b573e8ba5980", "16a72d41-a97d-4b8b-ae6e-3b043882ef8e", "59ae272b-00a8-483c-975b-48f55a15119b", "dcf1d26c-1f85-41f5-9045-cb931bf9ab3b" ], "other_config": { "i18n-original-value-name_label": "Local storage", "i18n-key": "local-storage" }, "sm_config": { "devserial": "" }, "$container": "5a58d8a6-0ed1-4825-b1fd-8d720832bf02", "$PBDs": [ "26c0dc31-2cf6-15c5-8683-5c60e10382d0" ], "id": "3662768f-4a40-31ed-54b9-21eb26876205", "uuid": "3662768f-4a40-31ed-54b9-21eb26876205", "$pool": "20ec2c95-dbb7-f4a3-8bb6-a80ff9de4d00", "$poolId": "20ec2c95-dbb7-f4a3-8bb6-a80ff9de4d00", "_xapiRef": "OpaqueRef:e1b6c317-a854-449b-80e3-b69bbeb389fc" }, "sslVerify": false, "stopSource": false, "thin": true, "user": "root", "vm": "16" } { "code": 10, "data": { "errors": [ { "instancePath": "/sr", "schemaPath": "#/properties/sr/type", "keyword": "type", "params": { "type": "string" }, "message": "must be string" } ] }, "message": "invalid parameters", "name": "XoError", "stack": "XoError: invalid parameters at Module.invalidParameters (/opt/xo/xo-builds/xen-orchestra-202302280214/packages/xo-common/api-errors.js:26:11) at Xo.call (file:///opt/xo/xo-builds/xen-orchestra-202302280214/packages/xo-server/src/xo-mixins/api.mjs:65:20) at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202302280214/packages/xo-server/src/xo-mixins/api.mjs:390:19)" }
-
@Seclusion are you doing it while the VM is running on VMware side? If yes, that's normal then, the delta mode (VM on) isn't supported yet on ESXi > 6.5