VMware migration tool: we need your feedback!

florent

@andyh I tried to disable TLS V2, can you pull --rebase and retry ?

if it doesn't work, could you check the tls level of your esxi host ?
https://stackoverflow.com/questions/40557031/command-prompt-to-check-tls-version-required-by-a-host
especially curl -Iiv --tlsv1.1 https://example.com

I have

* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS header, Unknown (21):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

on my esxi 6 host

andyh

@florent

Thanks for the quick response, the same error looks to persist.

Running the curl command gives

* Trying 192.168.xx.yy:443...
* Connected to 192.168.xx.yy (192.168.xx.yy) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS alert, protocol version (582):
* error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
* Closing connection 0
curl: (35) error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol

Performing the same check with -tlsv1.0 gives

*   Trying 192.168.xx.yy:443...
* Connected to 192.168.xx.yy (192.168.xx.yy) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.0 (IN), TLS handshake, Certificate (11):
* TLSv1.0 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Not sure if this helps.

akaylee

Hi!

I am having a similar problem to @andyh
Our VMWare is v5.5, xoa CLI throws:

      "result": {
        "message": "Client network socket disconnected before secure TLS connection was established",
        "name": "Error",
        "stack": "Error: Client network socket disconnected before secure TLS connection was established\n    at Function.AxiosError.from (/opt/xo/xo-builds/xen-orchestra-202306231640/node_modules/axios/lib/core/AxiosError.js:89:14)\n    at RedirectableRequest.handleRequestError (/opt/xo/xo-builds/xen-orchestra-202306231640/node_modules/axios/lib/adapters/http.js:591:25)\n    at RedirectableRequest.emit (node:events:527:28)\n    at RedirectableRequest.patchedEmit [as emit] (/opt/xo/xo-builds/xen-orchestra-202306231640/@xen-orchestra/log/configure.js:52:17)\n    at ClientRequest.eventHandlers.<computed> (/opt/xo/xo-builds/xen-orchestra-202306231640/node_modules/follow-redirects/index.js:14:24)\n    at ClientRequest.emit (node:events:527:28)\n    at ClientRequest.patchedEmit [as emit] (/opt/xo/xo-builds/xen-orchestra-202306231640/@xen-orchestra/log/configure.js:52:17)\n    at TLSSocket.socketErrorListener (node:_http_client:454:9)\n    at TLSSocket.emit (node:events:527:28)\n    at TLSSocket.patchedEmit [as emit] (/opt/xo/xo-builds/xen-orchestra-202306231640/@xen-orchestra/log/configure.js:52:17)\n    at emitErrorNT (node:internal/streams/destroy:157:8)\n    at emitErrorCloseNT (node:internal/streams/destroy:122:3)\n    at processTicksAndRejections (node:internal/process/task_queues:83:21)",

While webUI stucks on "Connect" with no apparent logs present..

When checking tls level of my esxi host:

localhost:~ # openssl s_client -connect www.google.com:443 -tls1
CONNECTED(00000003)

Will there be a support for older versions of ESXi? Or maybe I am doing something wrong. Thanks in advance!

florent

@akaylee we brole rejectUnauthorized ( handling of self signed certificate) During the upgrade of node-vpshere-soap, the fixes are coming and it should also work on 5.5

the first one have been merged and should allow you to list the VM on the host. Does it work ?

akaylee

@florent it doesn't seem to work, still stuck on 'Connect', 20 minutes elapsed

florent

@akaylee what is your current commit ?
this is the right one : 0f0c0ec

akaylee

@florent sorry, overlooked!
Yes, I was able to connect to my esxi host after updating to 0f0c0ec, testing migration right now
Thank you!

andyh

@florent Just updated from sources, but my latest commit looks to be 0f0c0ec0d. Have I missed something ?

florent

@andyh that's ok, I only pasted the start of the hash

As long as you're up to date on master, it should work (also it does not disable certifictae check for the whole process now )

andyh

@florent I still look to be receiving the same error, after updating to 0f0c0ec

write EPROTO C0D7ADA7B77F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1987:

Any further thoughts?

andyh

Gave this is a try earlier with some changes to my openssl.cnf

Sadly still coming across the same error, is there a minimum ESXi version that the import tool will connect to ?

KPS

Hi!

I did try the migration from the GUI for the first time.
The job did start and create a VM on XCP-ng. But there is no snapshot on the "VMWare-side" and there is no progress on the import.

The job did start and XO-tasks is now showing "importing vms, duration a few seconds, status green"

There is no "cancel" option.

On the XCP-ng-SR, there are the new disks, but they are empty.

Do you have any idea, what I did wrong and how I can proceed?

Tested on XOA on latest stable

Thank you and best wishes

florent

@KPS is there anything in the log ( journalctl ) ?

we can't migrate live data. Is the VM running ?

KPS

@florent
Sorry, that was the problem.
I was mislead by the wording "Source VM stopped before the last delta transfer (after final snapshot). Needed to fully transfer a running VM" in the GUI.

KPS

Hi!

I am still struggeling with the VMWare migration tool.

According to the docs, it should be possible to "warm-migrate" a VM, but when I try to, I am getting errors:

"message": "500 Internal Server Error https://vcenter/folder/InetTS00_U20.04/InetTS00_U20.04-flat.vmdk?dcPath=HZ&dsName=OpenE-2_vmware-1_LUN2",

What is the "right" way to migrate a running VM?

florent

@KPS It should, but there are some case where the esxi lock all the files of a VM, and other where it only locks the last snapshot. We're still working on the exact limit, what is the version of esxi used ? what storage do you use ( local VMFS, iscsi, NFS, ... ) ?

In parallel we're putting the finishing touch of a huge change that give a big speedup. that way the penalty of stopping the VM will be lighter. You can test by switching to the branch xva_generation
https://github.com/vatesfr/xen-orchestra/pull/7323

fbeauchamp opened this pull request in vatesfr/xen-orchestra

closed Import disks from ESXi to XCP-ng using XVA format #7323

KPS

@florent
Thank you for your answer. I am using vSphere 7 with iSCSI-storage.
Can you give me a hint on the "most stable" way to migrate?

florent

@KPS the most stable is always to stop the VMs
Trying to warm migrate a running VM between different hypervisor is always tricky, if not brittle, and we work to harden this process, define more clearly the limits and extends the possibilty (for example vsan)

What are the rough sizes of the VMs ? how many VM ? What is the timeframe of the full migration ?

Do you think you can give a try to the xva import on a stopped VM ? on some of my tests, this migration is completely saturating my network link and my disks, as shown in the PR. The fastest way is to have the XO doing the migration directly in the ESXI. As an additional bonus, the disk produced is thin

neologic

When migrating VMs from ESXi, the CPU count and Memory allocation is taken over to XCP-ng.
That's all fine for me.
However, after import, the static min memory allocation cannot be reduced.
Is there a workaround?

[02:56 xcp01 ~]# xe vm-param-get uuid=... param-name=memory-static-min
8589934592
[02:57 xcp01 ~]# xe vm-memory-static-range-set uuid=... min=4294967296 max=8589934592
The dynamic memory range violates constraint static_min <= dynamic_min <= dynamic_max <= static_max.

olivierlambert

If you want to change the min, just change the min not the whole range