VMware migration tool: we need your feedback!

planedrop

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!

olivierlambert

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

planedrop

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

olivierlambert

Frankly IDK, and I'd like more input from VMware users to make a decision based on multiple opinions

planedrop

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

chrispro-21

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

florent

@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+)

alexredston

Hi @florent I'm getting the same on ESXi 6.7 - have tried migrating the disk storage within VMWare first to see if it updated. Looking forwards to testing this new feature as soon as disk format sorted - in the mean time will look for a workaround.

vm.importFromEsxi
{
  "host": "172.29.49.11",
  "network": "b4d861c9-a735-b21c-6f58-655911cf8fb2",
  "password": "* obfuscated *",
  "sr": "1216d3f2-a60d-e68b-ea93-0b1b594a53cb",
  "sslVerify": true,
  "stopSource": false,
  "thin": false,
  "user": "administrator@blue.local",
  "vm": "vm-4292"
}
{
  "message": "sesparse Vmdk reading is not functionnal yet gbr-stf-blue-dc/gbr-stf-blue-dc-000001-sesparse.vmdk",
  "name": "Error",
  "stack": "Error: sesparse Vmdk reading is not functionnal yet gbr-stf-blue-dc/gbr-stf-blue-dc-000001-sesparse.vmdk
    at openDeltaVmdkasVhd (file:///opt/xo/xo-builds/xen-orchestra-202303171405/@xen-orchestra/vmware-explorer/openDeltaVmdkAsVhd.mjs:7:11)
    at file:///opt/xo/xo-builds/xen-orchestra-202303171405/packages/xo-server/src/xo-mixins/migrate-vm.mjs:267:27
    at Task.runInside (/opt/xo/xo-builds/xen-orchestra-202303171405/@vates/task/index.js:158:22)
    at Task.run (/opt/xo/xo-builds/xen-orchestra-202303171405/@vates/task/index.js:137:20)"
}

olivierlambert

@alexredston you can workaround it by stopping the VM and that will work

alexredston

@olivierlambert Thanks - already underway.

3 hours elapsed, 3 hours to go 80GB thick provisioned primary domain controller, unfortunately it was on a slow network card 1G, averaging about 42 MB per second during the transfer. Will try the next one on 10G and will see what the speed is like.

RAID 1 on old server to RAID10 ADM triple mirrored and striped.

olivierlambert

Select thin on the XO V2V tool, that might be faster in the end. Patience is key

rochemike

@alexredston I don't know what "old server" means to you, but 42MB/se could be ~320Mbps which would be about the maximum on a SCSI bus. If I'm right and it's Ultra2 SCSI, there's little that you'll be able to speed up by increasing available network bandwidth.

https://en.wikipedia.org/wiki/Parallel_SCSI#:~:text=At 10 MHz with a,rate of 640 MB%2Fs.

Mike

alexredston

@rochemike SSD - so should go a little faster.

alexredston

@olivierlambert Trying another VM now - Linux this time, on ESXi it is 500GB thin provisioned with about 100GB in use - transfer died at around 20 hours + on thick, seemed to get nowhere on thin, but I'm not sure where to get error message to see what happened - just going to try again now after bringing XO up to date with master. Will try thin.

alexredston

@rochemike it did get there in the end - one down 28 to go

olivierlambert

\o/

Next release will have multi-VM import

florent

@olivierlambert yes
and the multi import will runVM two by two

stmboyd

Hello,

I am not even able to connect. When I enter the credentials for my host and hit connect, I get an error when XO tries to iterate over the data:

esxi.listVms
{
  "host": "10.64.54.4",
  "user": "root",
  "password": "* obfuscated *",
  "sslVerify": false
}
{
  "message": "Cannot read properties of undefined (reading 'perDatastoreUsage')",
  "name": "TypeError",
  "stack": "TypeError: Cannot read properties of undefined (reading 'perDatastoreUsage')
    at file:///opt/xo/xo-builds/xen-orchestra-202303302257/@xen-orchestra/vmware-explorer/esxi.mjs:211:55
    at Array.map (<anonymous>)
    at Esxi.getAllVmMetadata (file:///opt/xo/xo-builds/xen-orchestra-202303302257/@xen-orchestra/vmware-explorer/esxi.mjs:209:31)
    at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202303302257/packages/xo-server/src/xo-mixins/api.mjs:401:20)"
}

Using XO from sources a41037833c960078d8509fd95e01aa0bb5a3670e
ESXi 6.5.0

Regardless of what the issue ends up being, is there maybe a better way of handling the flow? As in, when I click connect, can there be a landing page that says "connected", and allows for partial loading of info? Might be helpful, and will certainly be a better user experience.

olivierlambert

Either try on latest commit on master or XOA with latest to see if it's better
I don't understand the other part of your comment, if the error is during the connection, there's little more we can do

stmboyd

@olivierlambert

Did you even look at the commit I posted? When I ran this, it was 2 commits behind latest master. Was the commit of you updating a document supposed to make things better? How about the commit to Lite, was that really going to fix anything?
Please at least make some effort here, I posted a trace for a reason.

The failing line is this: https://github.com/vatesfr/xen-orchestra/blob/master/%40xen-orchestra/vmware-explorer/esxi.mjs#L211
For some reason, this property is not available on storage.
That code is called from here: https://github.com/vatesfr/xen-orchestra/blob/1942e55f763bd3d74c7cbc3dc1fc4c0ec070414c/packages/xo-server/src/xo-mixins/migrate-vm.mjs#L164

Look at that function for a second, and then re-read what I said in the earlier comment. Why does this function try and do two things? I'm saying it may be a good idea to split this into 2 parts. First, only connect, and then display a page in XO that shows the connection is live, and then after that query the data. This would make things a bit nicer.

More importantly, there needs to be some way for me to help figure out why the data that comes in is not in the format XO is expecting. That way we could solve a problem.

In the future, please don't make several blog posts and a huge thread asking for "feedback" and then tell me "there's little more we can do" when you have done nothing, it doesn't really feel encouraging.