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