@paco I think it's the first time someone asks this, which is surprising to me, because CBT enabled + local storage may not be such a rare thing. I wasn't aware of this blocking situation. We'll need to evaluate it, document it, and if possible find a way to avoid it. In your situation, if all you've done is upgrading the pool master, I would advise to boot the upgrade ISO again and use it to restore the 8.2 backup that was made automatically during the upgrade. Then boot the master again, disable CBT on all your disks, and start again with the upgrade.

Thanks Olivier! That is what we assumed, but with how the 3 hosts per pool was in there under the essentials licenses it was up for debate

But giving your feedback on how you solved it might help many people in the future Thanks!

@MathieuRA The context for my question is I created an app to control my VMs and though my app said a VM started it really didn't. When I went into the logs I noticed an error, so my thought is to be able to check the logs would be helpful to find out if there is an error or not. Let me update my app because I'm thinking I can get around not having access to the logs. Thank you for the prompt response! Have a blessed day!

@vhaelan Hello. What's the output of rpm -qa | grep intel-gpu-firmware ?

Great! Keep us posted

We just merged a PR that changes the UI to allow offline backups for delta backups, disaster recovery and continuous replication: https://github.com/vatesfr/xen-orchestra/pull/9228 Now, if your delta backup makes offline backups, you can disable that without having to change the backup type. b-Nollet opened this pull request in vatesfr/xen-orchestra closed fix(xo-web): allow offline delta backups #9228

any idea anyone ? halp needed

I would like to suggest to configure a remote syslog server. it centralizes all the log s and give you full control over the retention. It would also avoid situation where a disk full would impact your logging as well XCP-ng or XOA host operations. For your XCP-NG host go to you POOl, select Advanced tab and configure the Remote syslog host section to point to your syslog server. For XOA, you can follow the instruction here : https://docs.xen-orchestra.com/backups#send-xo-logs-to-an-external-syslog-server

If one day, some sad soul encounters these errors and nothing seems to be working or making sense you may have the same issue I did. Back story: Earlier this year, I had a Pool with 3 hosts. Through a series of unfortunate events. The Master died, I recovered as best as I could and assumed all was well as I rebuilt the environment since all of my vm's appeared to be working (except Xen Orchestra). I tried different versions (Ubuntu, Debian, XOA, XO via Docker, etc.). Error: backupNg.runJob { "id": "ea4a9d00-db35-45a9-8a15-f700891d55c6", "schedule": "0811579b-8ad3-4f29-8581-15a35c9c4597" } { "library": "SSL routines", "reason": "tlsv1 unrecognized name", "code": "ERR_SSL_TLSV1_UNRECOGNIZED_NAME", "call": { "duration": 21, "method": "session.login_with_password", "params": "* obfuscated *" } } [image: 1765346178618-a19c2386-f194-4268-af87-3c2307bb9cdd-image.png] In my case, my database was corrupted. By rejoining host to the same damaged pool, the issue remained. In was confusing since an old instance of xen orchestra running Ubuntu 18.04 was the only instance that could run backups successfully. Newer instances could do everything except run backups. Either way, hopefully this never happens to you. If it does, your servers backend database might be the issue. Thanks again to everyone that helped me figure this out throughout the year!

In other words, you can safely remove them.