VMware migration tool: we need your feedback!
-
@florent I just checked the branch and I get this error message "404 Not Found https://<vsphere-host>/folder/<vm-name>/<vm-name>.vmx?dcPath=datacenter-61&dsName=<ds-name>"
where
datacenter-61is not the right reference to my datacenter. Please take a look at the following screenshot.
From documentation
dcPath is the inventory path to the Datacenter containing the Datastore.
-
@ismo-conguairta said in VMware migration tool: we need your feedback!:
inventory path to the Datacenter
I updated to use another property (from https://developer.vmware.com/apis/196/vsphere/doc/vim.Datacenter.html ) is it better ? on our lab, theses properties have the same value
-
@florent I have just checked and your last update works like a charm. Great!
-
Hi folks,
I have an error when importing from VMware
I'm using XO from sources :
commit number : ea2c6 Hypervisor : Xcp-ng 8.2.1 node : 18.14.2When I go on import and "from VMware", I put my ESX credentials, check "skip SSL", I do see the list of my VMs from my ESX. I select everything that needed and when I import, I have an error, doesn't matter which option I select or if the VM is running Windows or Linux. Also my ESX are running vmware 5.5.0
Here is the log and screenshot :
vm.importFromEsxi { "host": "IP MASKED", "network": "6277d50c-5d2e-e896-864a-5afcc009ad51", "password": "* obfuscated *", "sr": { "type": "SR", "content_type": "user", "physical_usage": 33929035776, "allocationStrategy": "thin", "current_operations": {}, "inMaintenanceMode": false, "name_description": "VM", "name_label": "NFS", "size": 12884899659776, "shared": true, "SR_type": "nfs", "tags": [], "usage": 289910292480, "VDIs": [ "afef80db-c923-4248-b731-4d1712f02db1", "42fc30c3-4d8f-4126-bb78-fd4a8285b03a", "b286ad66-3d19-4984-aa80-840d93c72cf0", "03869f0c-1a02-4e32-9932-4e221e534eb0", "d17a4e5e-7276-4ef2-84f4-4766c4ad471e" ], "other_config": { "auto-scan": "true" }, "sm_config": {}, "$container": "3eb75cbb-0cc2-3c90-e63e-ae6da1ef9417", "$PBDs": [ "90204213-cbec-5194-439d-ab795a0fe4b8", "2c8adf39-d2a9-8dd5-568d-872fcc04de54" ], "id": "cecb563f-f745-3ed6-1f64-85de34dfbbd5", "uuid": "cecb563f-f745-3ed6-1f64-85de34dfbbd5", "$pool": "3eb75cbb-0cc2-3c90-e63e-ae6da1ef9417", "$poolId": "3eb75cbb-0cc2-3c90-e63e-ae6da1ef9417", "_xapiRef": "OpaqueRef:04f1c17c-357e-428c-bbbe-2a558cd7238a" }, "sslVerify": false, "stopSource": false, "thin": false, "user": "root", "vm": "109" } { "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-202303011617/packages/xo-common/api-errors.js:26:11) at Xo.call (file:///opt/xo/xo-builds/xen-orchestra-202303011617/packages/xo-server/src/xo-mixins/api.mjs:65:20) at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202303011617/packages/xo-server/src/xo-mixins/api.mjs:390:19)" }
-
@Touille As @florent said in a previous message probably the full SR object is sent to the backend instead of its id. This happens when you change the destination SR from the default one to another. You can try to proceed with the export on the default SR.
Take a look at this branch: https://github.com/vatesfr/xen-orchestra/pull/6696/files
It seems to fix the error.closed fix(xo-web/import/vmware): fix invalid params #6696
-
It's even merged in
master(few seconds ago)
-
Hi @ismo-conguairta.
As you and Florent said, before the update, when I tried to import to another SR than the default one, it wouldn't work.Since the update an hour ago, it's fixed
I've just imported a VM from VMware to any SR I wantthank you!!
-
It may have already been mentioned in here more recently, but I still think some kind of system to select specific VHDs from the ESXi box would be super nice.
Sometimes one may only need to move the data of specific VHDs (excluding say logging or other temporary data style VHDs) and this would greatly speed up migrations.
It would also help in the event someone has VHDs that are larger than 2TiB, since you'd be able to only move the smaller ones and find an alternate solution for the larger than 2TiB VHDs.
Just a thought though; this tool is still amazing and has helped me start migrations!
-
@planedrop the issue is that we are about to add multi-VM migration, so it will be a bit harder to make individual choices per disk. However, we could always create a convention based on a tag/name of the disk to ignore it, what do you think?
-
@olivierlambert I think a tag or name based exclusion would be a great idea! Helps in the more niche use cases where not all drives have to be moved.
As an example use case, I have a VM I am going to migrate sometime in the next few weeks, but I only need it's C drive (the other drives are for logging, etc... and are more than 2TiB anyway). Right now I plan to export the VMDK and try importing it but I've had mixed results with that working correctly in the past, whereas this new V2V migration tool has been super reliable so far, so I'd have more confidence in it working (not to mention it's less work haha).
-
In VMware, can you easily tag a VM disk?
-
@olivierlambert I don't think there are tags for them, per-se but you can rename a VMDK file to whatever you want within vCenter. Maybe just looking at the name of the VMDK files and allowing someone to enter ones to exclude would work?
-
Sure, I just need to know what's the easiest way to do this in VMware, since I don't know it at all
-
@olivierlambert Totally understand.
I think going based on the name of the disk would be the best option.
For example, on a test VM I have, the disks all show up like this:
And I can rename them if need be.
Does the current V2V tool just look for .vmdk files and then migrate those?
I guess what I'm thinking is like something that says "exclude the below disks" and then has a list system where you can enter the disk name as it shows up here in ESXi so that it ignores those disks?
I'm not sure how complex this would be though so just throwing out suggestions haha!
-
I would prefer something that's not configured in XO but a convention on the VMware side so it can scale during one import on tons of VMs
-
@olivierlambert I see, this makes sense.
Maybe a naming convention can be used and then users can rename their VMDK files to something specific that is ignored?
Like say you have Ubuntu1.vmdk, Ubuntu2.vmdk, Ubuntu3.vmdk and someone only wants Ubuntu1.vmdk, they could rename Ubuntu2 and 3 ones to ignore1.vmdk and ignore2.vmdk?
-
Frankly IDK, and I'd like more input from VMware users to make a decision based on multiple opinions
-
@olivierlambert I agree, would be good to hear from more people. We only run a handful of VMs on VMware so I may not be the best person to give detailed feedback.
-
@brezlord said in VMware migration tool: we need your feedback!:
TypeError
I got something similar on the latest build of XO.
System: ESXi 6.7.0 Update 3 (Build 15160138)vm.importFromEsxi { "host": "10.20.0.105", "network": "1816a2e5-562a-4559-531d-6b59f8ec1a5c", "password": "* obfuscated *", "sr": "eb23cb22-5b8c-9641-b801-c86397e05520", "sslVerify": false, "stopSource": true, "thin": false, "user": "root", "vm": "9" } { "message": "Cannot read properties of undefined (reading 'stream')", "name": "TypeError", "stack": "TypeError: Cannot read properties of undefined (reading 'stream') at file:///home/node/xen-orchestra/packages/xo-server/src/xo-mixins/migrate-vm.mjs:272:30 at Task.runInside (/home/node/xen-orchestra/@vates/task/index.js:158:22) at Task.run (/home/node/xen-orchestra/@vates/task/index.js:137:20)" } -
@chrispro-21 we're not able to import VM with snapshots from esxi 6.5+ , for now
At least the next release will be able to ignore them or give a meaningfull error, if we have not finished the implementation of sesparse reading ( the disk snapshot format for esxi 6.5+)
