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.

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 ?

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

@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

@olivierlambert

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.

@olivierlambert

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.