Import from VMware err: name: AssertionError: Expected "actual" to be strictly unequal to: undefined

sshughes

@Nick-085
Just did. Reports nothing new.
Import fails with same error.

[info] Checking current node.js version

[ok] node.js version already on 20, checking updates

[info] Fetching Xen Orchestra source code

[info] Creating install directory: /opt/xo/xo-builds/xen-orchestra-202406132228

[info] No changes to Xen Orchestra since previous install. Skipping build. Use the --force to update anyway.
[info] Cleaning up install directory: /opt/xo/xo-builds/xen-orchestra-202406132228

sshughes

@sshughes also ran apt-get update apt-get upgrade, but again... I installed this VM less than 12 hours ago, so nothing new.

nick.lloyd

@sshughes Hmmm, that's frustrating. If I remember correctly, that is a Python error. It might be something with the Python script itself. Is the VM off when you're trying to import it? It shouldn't matter, but just something to try.

ph7

@sshughes
Shoundnt node.js be 18 ?

abudef

@ph7 I also have version 20, but no problem importing from VMware

Danp

@ph7 said in Import from VMware err: name: AssertionError: Expected "actual" to be strictly unequal to: undefined:

Shoundnt node.js be 18 ?

FYI, that is no longer required.

sshughes

above log entry is result of using XO web UI to import from ESXi and is the 3rd vm we tried to import. The first two imports were successful.
I used ronivay's installer and chose to have xo-server run as non-root user.
Decided to try using xo-cli vm.importFromEsxi.
I SSH to the XO VM as root and figure out how to get xo-cli register to work.
Using parameters displayed in the above log entry I think I was able to properly construct the xo-cli vm.importFromEsxi command as follows:

xo-cli vm.importFromEsxi host=10.16.75.5 user=root password=****** sslVerify=false vm=ParishSVR2 sr=2a160b8d-11ec-776b-7ce9-0af0ceb540c7 network=eddfca3c-8b32-7cf8-510d-debef0bff592 template=b6d0600e-677b-376a-507e-8f9dda9424cb-17a818b5-20a6-4d34-a7ef-320da9ef4c14

The result is a different error. Does this offer any more help as to what went wrong?

✖ JsonRpcError: can't get config of object ParishSVR2 (Type: VirtualMachine)
    at Peer._callee$ (/opt/xo/xo-builds/xen-orchestra-202406131610/node_modules/json-rpc-peer/dist/index.js:139:44)
    at tryCatch (/opt/xo/xo-builds/xen-orchestra-202406131610/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:45:16)
    at Generator.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202406131610/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:133:17)
    at Generator.next (/opt/xo/xo-builds/xen-orchestra-202406131610/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:74:21)
    at asyncGeneratorStep (/opt/xo/xo-builds/xen-orchestra-202406131610/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24)
    at _next (/opt/xo/xo-builds/xen-orchestra-202406131610/node_modules/@babel/runtime/helpers/asyncToGenerator.js:22:9)
    at /opt/xo/xo-builds/xen-orchestra-202406131610/node_modules/@babel/runtime/helpers/asyncToGenerator.js:27:7
    at new Promise (<anonymous>)
    at Peer.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202406131610/node_modules/@babel/runtime/helpers/asyncToGenerator.js:19:12)
    at Peer.exec (/opt/xo/xo-builds/xen-orchestra-202406131610/node_modules/json-rpc-peer/dist/index.js:182:20) {
  code: -32000,
  data: {
    message: "can't get config of object ParishSVR2 (Type: VirtualMachine)",
    name: 'Error',
    stack: "Error: can't get config of object ParishSVR2 (Type: VirtualMachine)\n" +
      '    at Esxi.fetchProperty (file:///opt/xo/xo-builds/xen-orchestra-202406131610/@xen-orchestra/vmware-explorer/esxi.mjs:447:13)\n' +
      '    at processTicksAndRejections (node:internal/process/task_queues:95:5)',
    succeeded: {}
  }
}

sshughes

@sshughes Pretty certain there is nothing wrong with XO. Seems there is a problem with this VM on ESX. vSphere can perform Export on the other VMs, but not the one in question. Task list says an Export is running, but we never get the prompt to select components for export. Thanks. If I learn any more, will report back.

olivierlambert

That's interesting, thanks for the feedback @sshughes and keep us posted!

benapetr

Hello, since this never had a clear resolution, here is explanation of the bug and why it happens:

There is a bug in disk iteration in that XO vmware plugin (somewhere in that esxi.mjs I don't remember exact location) - it basically expects that all disks of VM exist in same datastore and if they don't it crashes as the next disk in unexpectedly missing (undefined)

Workaround is rather simple - select the VM in vmware, migrate -> storage, disable DRS (important) and then select any DS that no disks current exist on. If you select and DS that is already used by same VM it will sometimes not get fixed! It also may happen even if VM is "apparently" looking like it's on single DS, even if it reports as such, still try to migrate it to another DS, and disable DRS so that really all files, even meta files are in same directory.

Then run XO import again, it will magically work.

florent

@benapetr said in Import from VMware err: name: AssertionError: Expected "actual" to be strictly unequal to: undefined:

Hello, since this never had a clear resolution, here is explanation of the bug and why it happens:

There is a bug in disk iteration in that XO vmware plugin (somewhere in that esxi.mjs I don't remember exact location) - it basically expects that all disks of VM exist in same datastore and if they don't it crashes as the next disk in unexpectedly missing (undefined)

Workaround is rather simple - select the VM in vmware, migrate -> storage, disable DRS (important) and then select any DS that no disks current exist on. If you select and DS that is already used by same VM it will sometimes not get fixed! It also may happen even if VM is "apparently" looking like it's on single DS, even if it reports as such, still try to migrate it to another DS, and disable DRS so that really all files, even meta files are in same directory.

Then run XO import again, it will magically work.

thanks you for the input
we were under the assumption that all the disk of a VM are in the same datastore
the fix should be too hard now that you did the hard work

edit: card created in our backlog, I will take a look after the release to see how hard it is to implement