In case anyone wonders how this played out. At the end of the day, I shutdown the host with the running workloads on it, kept it at BIOS boot so the 8.3 installer would upgrade it cleanly, and then booted it back up. For reasons related to my particular setup, the down time was more than 60 minutes. But that's not related to XCP-ng. The XCP-ng installer was maybe 10 of that. 20 of that was 3 reboots on a server that takes ages to boot. One thing that is a bit difficult is that the 8.3 installer doesn't notice ZFS volumes or help with ZFS. So after the upgrade, I have to follow a modified set of these instructions (modified because the package names have changed over time) to install ZFS and its components into the system. So the sequence is: Shutdown Install via ISO Reboot to single user mode Run yum update to pull in all the updates Run the ZFS commands to install ZFS on the host Reboot again Run normally Of course, I ended up rebooting more than just those 2 times, because I forgot that I would need to install ZFS (even though I did it on 2 different hosts already ) So now the pool is fully upgraded, everybody is happy. I'm now working on creating shared storage across the nodes. It's amateur hour over here. I appreciate all the help.

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.

Figured it out after some digging, appears it's related to Netbox having ipv4 translated into ipv6 for that field, so to use IPv4 you have to have :ffff:x.x.x.x/128 as your IP address (the x's being your octet). Once you do this it works without issue.

@Pilow Agreed however as our xcp-ng hosts are in the cloud with OVH Cloud we cannot use a physical appliance. We are currently setting up a dedicated OVH server for pfSense.

Create an appliance with all those VMs and configure the order and delay inside it.

@fred974 It used to be (and probably still is) that You have to be reasonably near correct time for NTP to accept any changes.

Hi! I'm not sure who to ping exactly for this question @pdonias or @Bastien-Nollet maybe?

@acebmxer Great. These are some YAML basics. You should read more about it . Following AI instructions without understanding is not going to take you far.

@bazzacad great, glad it worked for you

Adding @clemencebx for review/ideas on this;

@mguimond Not sure how old your XO is but this is the current Commit. Master, commit 5349f. Suggest try updating and try again. Maybe someone from Vates will have more information.

Ping @Team-Documentation-Knowledge-Management

I think it's planned for XO 6 adding @gregoire in the loop

@Pilow - so...I powered down the VM and re-attempted the RPU. It seems snapshots is a deterrent for being able to perform a RPU, because I see VMs migrating now so the RPU can run. For specificity - yes, my XCP Hosts are identical (CPU, RAM, etc); there were no affinities set (see screenshot) [image: 1763483116773-cf9b9ae2-5363-4b66-b367-1b0474e54538-image-resized.png] , etc. Thank you for the assist! I think @olivierlambert or his tech writers need to update the RPU requirements area of the docs. Snapshots cannot be present or RPU will fail. Weird why that is

xe pool-enable-tls-verification Was exactly what I needed, thanks! Worked after that.

@Andrew What a day... Have two hosts and needed a RAM upg so scheduled these with OVH, one for 4pm and the other for 8pm. Plan was to migrate the VMs off the host being upgraded to maintain uptime. Got an email from OVH stating that due to parts availability the upg will not proceed and then they downed both hosts at 8pm to upg at the same time and that caused havoc today.

@Danp My apologies for not being more specific. I’m encountering an issue with XOA deployment on a home lab environment. Environment Details: Installation source: USB Hardware: 16GB RAM, 1TB NVMe HDD Initial install: Completes successfully Dashboard: Displays expected status Steps Taken: Installed XCP-NG from USB — installation and setup completed without errors. Verified dashboard — all components appeared healthy. Deployed XOA to the existing HDD — process executed as expected. Observed Behavior: After deployment, XOA appears healthy overall, but the final item labeled “NEW” does not appear in the interface. Expected Behavior: The “NEW” item should be visible after deployment. Mark