According to a closed issue from Ronivay the problem looks to be resolved.
https://github.com/ronivay/XenOrchestraInstallerUpdater/issues/227
I've just updated to latest from Branch="Master" and successfully performed a health check.
According to a closed issue from Ronivay the problem looks to be resolved.
https://github.com/ronivay/XenOrchestraInstallerUpdater/issues/227
I've just updated to latest from Branch="Master" and successfully performed a health check.
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 ?
@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?
@florent Just updated from sources, but my latest commit looks to be 0f0c0ec0d. Have I missed something ?
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.
@florent Thanks for reaching out
Updated XO from Sources to the commit from the branch.
When I attempt the import from VMware, the process doesn't show an error in the UI and the connect process button looks to spin. However, checking the logs I see the following error (with skip SSL enabled or disabled)
write EPROTO C0F754130E7F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1987:
@florent thanks for the response
This was my initial thought, I tried to drop the MinProtocol to TLSv1.0 in openssl.cnf and recomplile from source. But the error persisted,
Worst case I can look at manually exporting and importing the VMs.
When I try the import from the UI directly I receive the following in the logs:
write EPROTO C0A77278D27F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1987:
I am using Xen Orchestra from sources (commit 6fe79)
xo-server 5.116.3
xo-web 5.119.1
I have a legacy host running VMWare 5.1.0, when attempting to execute
xo-cli --register --allowUnauthorized <host> <user>
I receive the following error
✖ Error: write EPROTO C057D8B5357F0000:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1987:
at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16) {
code: 'EPROTO',
errno: -71,
syscall: 'write'
}
Would VMWare 5.1.0 be too old to transfer via Import from ?
I had an issue with the backing up of a linux VM that had a [nobak] disk associated with it. When attempting the Health Check, I would receive the following error
waitObjectState: timeout reached before OpaqueRef:7c60ab35-dba3-4c4a-887a-0f350a68c3b9 in expected state
Watching the state of the VM startup, I could see the OS would not load. I initially thought this was an issue with XO, but earlier I realised it was the host OS hanging.
This was due to the OS not being able to mount the disk from the health check, as it was not backed up due to [nobak].
Modifying the /etc/fstab in the host OS to include nofail resolved the health check failure. Eg.
UUID=a2c230fd-13e0-4453-9d56-1ab123bfad9e /Cache xfs defaults,nofail 0 0
Hopefully this will help anybody experiencing similar issues.
@olivierlambert many thanks for the very quick response, it is indeed XO from sources. I think the burst explanation makes sense.
Also, thanks for you and your teams continued development and support with both XCP-NG and XO.
I’m running XOA from sources at the moment and have elected to receive a weekly XO Report.
The disk read / write values appear to be either empty or very low in the html report.
I initially thought this could have been connected with either an XCP host restart or a a restart of XOA. But this past week neither have been restarted.
Can anybody advise or shed any light on my experience ?