Import VMWare error - HANDLE_INVALID

richardwvm

Hi Folks:

vSphere 6.7
XCP-NG 8.2.1
XO (from sources) commit 5cf5d

Attempting to migrate a small VM from our VMWare stack to XCP-NG. Using the UI I received a "Premature close" error, so dropped to the command line to see if it yielded any further information (although not clear if this is the same error):

richard@xo:~$ xo-cli vm.importFromEsxi host="vsphere.ourdomain.co.uk" network="2e52f2da-672e-8455-d95b-52390ce085ae" password="mypassword" sr="42e1c77d-ed20-0f22-06eb-072bbd16492f" sslVerify=false user="richard@ourdomain.co.uk" vm="vm-1214"
✖ JsonRpcError: HANDLE_INVALID(network, OpaqueRef:a240dc2f-a838-48be-8c52-7b5367b24b54)
    at Peer._callee$ (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/json-rpc-peer/dist/index.js:139:44)
    at tryCatch (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:45:16)
    at Generator.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:133:17)
    at Generator.next (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:74:21)
    at asyncGeneratorStep (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24)
    at _next (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/asyncToGenerator.js:22:9)
    at /opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/asyncToGenerator.js:27:7
    at new Promise (<anonymous>)
    at Peer.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/asyncToGenerator.js:19:12)
    at Peer.exec (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/json-rpc-peer/dist/index.js:182:20) {
  code: -32000,
  data: {
    call: {
      method: 'network.get_MTU',
      params: [ 'OpaqueRef:a240dc2f-a838-48be-8c52-7b5367b24b54' ]
    },
    code: 'HANDLE_INVALID',
    message: 'HANDLE_INVALID(network, OpaqueRef:a240dc2f-a838-48be-8c52-7b5367b24b54)',
    name: 'XapiError',
    params: [ 'network', 'OpaqueRef:a240dc2f-a838-48be-8c52-7b5367b24b54' ],
    stack: 'XapiError: HANDLE_INVALID(network, OpaqueRef:a240dc2f-a838-48be-8c52-7b5367b24b54)\n' +
      '    at Function.wrap (file:///opt/xo/xo-builds/xen-orchestra-202312211012/packages/xen-api/_XapiError.mjs:16:12)\n' +
      '    at file:///opt/xo/xo-builds/xen-orchestra-202312211012/packages/xen-api/transports/json-rpc.mjs:35:21'
  }
}

Appears to be throwing a "HANDLE_INVALID" exception when trying to get the network's MTU (although not sure which side the API call is being made!).

Anyone experienced anything similar?

Regards,

Richard.

richardwvm

@florent You got me looking in the right direction, my backup network was set to an interface that has since been bonded and therefore has a different UUID. Changed the backup network to the Bond and it now works perfectly from the web UI, so it was just a simple topology issue after all.

Many thanks for the help, much appreciated.

olivierlambert

Hmm doesn't ring any bell, but let me ping the V2V author, @florent

florent

@richardwvm this look like an error on XCP side . Can you try with another network ?

olivierlambert

@richardwvm said in Import VMWare error - HANDLE_INVALID:

2e52f2da-672e-8455-d95b-52390ce085ae

Are you sure that's the correct ID of a network? Can you do a xe network-param-list uuid=2e52f2da-672e-8455-d95b-52390ce085ae on your host?

richardwvm

@olivierlambert Ah ha, that has got me past one hurdle. I was using the UUID of VM's VIF. I have now changed it to the right UUID for the management network bond on the host running the VM and I can now reproduce the "Premature close" exception at the command line:

✖ JsonRpcError: Premature close
    at Peer._callee$ (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/json-rpc-peer/dist/index.js:139:44)
    at tryCatch (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:45:16)
    at Generator.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:133:17)
    at Generator.next (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/regeneratorRuntime.js:74:21)
    at asyncGeneratorStep (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/asyncToGenerator.js:3:24)
    at _next (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/asyncToGenerator.js:22:9)
    at /opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/asyncToGenerator.js:27:7
    at new Promise (<anonymous>)
    at Peer.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/@babel/runtime/helpers/asyncToGenerator.js:19:12)
    at Peer.exec (/opt/xo/xo-builds/xen-orchestra-202312211012/node_modules/json-rpc-peer/dist/index.js:182:20)

Full response dump: Response Dump.txt

Any pointers much appreciated!

Regards,

Richard.

richardwvm

Xen Orchestra, commit 8b0b2

I have been having another go at this, more information as follows:

If I remove all snapshots from the target VM in vSphere and try again, it appears to succeed; I get a UUID back, I can see the VM (with correct configuration) and disk in XO and the create and copy tasks. However the copy task just never gets going (understandably) and remains at zero percent progress.

So the process must be logging into vSphere correctly, which makes me wonder if the issue is actually on the XO side, also the last line from the stack trace:

url: 'https://localhost/signin'

Being localhost presumably means a loop back to XAPI locally?

@florent Is there anything I can do to help debug this further please?

richardwvm

So now wondering if this is just a topology issue. We are not hyperconverged, so separate compute and storage clusters. 10GbE unrouted SAN network and separate VM/Management network on the LAN side.

Is the network specified in the import meant to be the network to reach vSphere or the network to access the storage? I seem to get the premature close exception regardless of which PIF I choose.

Is the import tool looking to stream the VMDK via the storage network or management network via vSphere?

florent

@richardwvm the import tool will do soap (htt)p queries to both the esxi and the xen host ( importing the data, creating the VM)
It will use the backup network on the xen side ( if set ), and the default one on the esxi side

richardwvm

@florent You got me looking in the right direction, my backup network was set to an interface that has since been bonded and therefore has a different UUID. Changed the backup network to the Bond and it now works perfectly from the web UI, so it was just a simple topology issue after all.

Many thanks for the help, much appreciated.

olivierlambert

Thanks for your feedback and happy to see it works