@olivierlambert Snapshot is in essence a VDI clone, I don't see any checks being done before the filtering for ignored VDIs is done. And that is done pretty early on, not sure why there are operations affecting virtual block devices from ignored VDIs: https://github.com/xapi-project/xen-api/blob/master/ocaml/xapi/xapi_vm_clone.ml#L416
@cocoon
The best thing we can do here is inspect the actual certificate:
Please run openssl x509 -text -noout -in /etc/xensource/xapi-ssl.pem
xenserver has generated host certificates with 2048-bit RSA keys for years, these should be able to be loaded by stunnel (through openssl) just fine.
If the key is smaller that this then the fix is easy: generate a new certificate for that host: xe host-refresh-server-certificate host uuid=<>
Be mindful that clients that trusted the previous certificate will need to trust the new one in order for the TLS connections to be established
@olivierlambert Snapshot is in essence a VDI clone, I don't see any checks being done before the filtering for ignored VDIs is done. And that is done pretty early on, not sure why there are operations affecting virtual block devices from ignored VDIs: https://github.com/xapi-project/xen-api/blob/master/ocaml/xapi/xapi_vm_clone.ml#L416
There's ongoing effort to avoid opening file descriptors, to avoid this situation. I'll consult whether the current patches avoid this situation in template-export / vm-import
@cocoon
The best thing we can do here is inspect the actual certificate:
Please run openssl x509 -text -noout -in /etc/xensource/xapi-ssl.pem
xenserver has generated host certificates with 2048-bit RSA keys for years, these should be able to be loaded by stunnel (through openssl) just fine.
If the key is smaller that this then the fix is easy: generate a new certificate for that host: xe host-refresh-server-certificate host uuid=<>
Be mindful that clients that trusted the previous certificate will need to trust the new one in order for the TLS connections to be established
