Restoring from backup error: self-signed certificate
-
Hello @KS unfortunately I deleted the older XO vm, before making a note of the version, and proceeded to upgrade to the latest.
-
@Ismail No worries! Follow up question then, does the restore still work after you've updated to the latest version?
-
@KS Nope, I did one successful restore and then assumed all was good and proceeded to upgrade XO. By the way I'm using Ronivay's XO vm image from https://github.com/ronivay/XenOrchestraInstallerUpdater
-
Same issue on my host, with commit 8e5d9.
I tried the health check, and it is stuck.
I do not see any error message, the log just says pending.I tried a restore check with XOA 5.91.2, no issue on that side, only XO from source seems to be not working.
-
Thanks for your reply. Seems like this might be a bug with the latest version of XO from sources.
I'm trying to use the XO script by Ronivay to install an older branch to see if that solves this issue. In the xo-install.cfg file there is a "BRANCH" variable and it says you can specify a commit number, but that doesn't seem to working for me. I'm sure I'm formatting it incorrectly. Thoughts?
Tried both:
BRANCH="6056a61" BRANCH="6056a618c3e503fcc0de4fe19007574e40bfddd5"Thanks.
-
Same issue here with the latest XO
I tested restore from Qnap with NFS, and there were no errors it's just stuck in tasks with no movement and no way to cancel.
If it helps everything is with default self-signed certificates.
Backups run with no issues, just something with the restore. -
Same issues with restoring on the current commit, but rolled back 21 commits (6056a) and it works again.
-
Same here. I was able to install the same Commit and it works now with the pre-installed certificates.
This appears to be a bug in newer commits.
-
Hi @KS I use Ronivay's precompiled VM which only deploys the latest build. I will have to look into this install script to compile a previous build of the vm. Will let you know if I get it working.
-
Same here, its definately a bug because I was able to do a backup and restore just last week.
I upgraded to the latest 2 days ago and now backups are broken, same version here:
-
I can confirm that in the community edition, something between 0ccfb4b and 8e5d9 breaks restoring to hosts with self signed certs.
I had to try and restore a couple of VMs after the upgrade to 8e5d9 and despite a couple of attempts to compile previous commits and see if they would work, nothing did until I reached 0ccfb4b.
Once I had rolled it back that far, the restores were no longer stuck at 0% and there were no problems restoring any of the backups that I tied.
-
Someone else on this forum is having trouble with self-signed certificates. So this issue must be more general than just self-signed certificates when restoring backups.
It must be a bug introduced recently which is specifically when handling self-signed certificates generally.
https://xcp-ng.org/forum/topic/8636/self-signed-cert
Others with this issue is the link shown above similar to what you are experiencing with backup restoration?
@florent Can you please check this out there may be a bug in Xen Orchestra which is affecting the handling of self-signed certificates generally? As it's affecting not just restoration of backups but also the creation of new VMs as well.
-
@john-c
"Someone else on this forum is having trouble with self-signed certificates. "Unfortunately, this function does not work either.
márc 18 14:13:12 xoa xo-server[22559]: 2024-03-18T13:13:12.703Z xo:api WARN bogi.kornel | backupNg.importVmBackup(...) [184ms] =!> Error: self-signed certificate -
For those finding this post and are using ronivay's XenOrchestraInstallerUpdater, the solution is as follows...
Edit xo-install.cfg with your favourite editor.
Look for the line...
BRANCH="master"
Comment it out and and on a new line add...
#BRANCH="master"
BRANCH="0ccfd4b"If you then run the script and choose 2) Update, it should work.
Because I was in a hurry, I deleted the /opt/ox directory, put the SSL certs that were in it back, and then ran 1) Install so that I knew that I was certain that there were no conflicts with compiling and older version.
But either method should work.
-
@KS Did you try running "xe task-list" to identify the process and then "xe task-cancel force=true uuid=(UUID-of-process)"?
-
@StormMaster thank you. This workaround did exactly what i needed.
-
Thank you @StormMaster
-
A abudef referenced this topic on
-
Ditto the fix from @StormMaster worked for me - many thanks.
-
The command "xe task-cancel force-true ..." with the uuid of the pending tasks did not do anything for me. After trying it on the 3 tasks I had, issuing a "xe task-list" still show me the pending tasks. It it only by rebooting the host that the pending tasks disappear.
-
Going back to an older version of XO source also did the trick for me.
I was in the process of pushing in production a couple VM that were previously in test and that I had backed up a couple of days ago. I was very surprised not to be able to do anything with these VMs stuck on my SR used for VM backup
