@FagnerMoraes I just realized you are not listing the same folder that what is backed up in your NAS backup job: on the left, you are listing incremental backups from a given folder, but in the logs I analysed the xva are in another folder

@Bryanvh Thank you for your feedback, Your previous certificates look correct. I have not been able to reproduce the issue on my side, but I will try to diagnose it based on the code. [MASTER] I have a few preliminary commands. The first one is to retrieve the MASTER_UUID: cat /etc/xensource-inventory | grep INSTALLATION_UUID | cut -d'=' -f2 | tr -d "'" Then we can compare fingerprints between the master certificate and the one stored for the pool: openssl x509 -in /etc/xensource/xapi-pool-tls.pem -noout -fingerprint -sha256 openssl x509 -in /etc/stunnel/certs-pool/{MASTER_UUID}.pem -noout -fingerprint -sha256 (please replace {MASTER_UUID} with the value retrieved above) Normally, both fingerprints should match. Also check that the CA bundle exists and is not empty: ls -l /etc/stunnel/xapi-pool-ca-bundle.pem If you previously ran: xe host-refresh-server-certificate you should probably run: xe pool-certificate-sync [JOINER] Based on the code, the first phase has already been completed. You should therefore have files under /etc/stunnel/certs-pool/, including the master certificate: openssl x509 -in /etc/stunnel/certs-pool/{MASTER_UUID}.pem -noout -fingerprint -sha256 [Additional checks] Are all hosts synchronized to the same NTP server? date & timedatectl Are all hosts fully updated to XCP-ng 8.3 and rebooted after updates? Do you see the same error when joining the pool using XCP-ng (via Console or CLI) instead of Xen Orchestra? Is there any more detailed error in /var/log/xensource.log ? How many hosts are in your pool? Is stunnel running correctly on all hosts? systemctl status stunnel@xapi Do certificate chains validate correctly? openssl verify -CAfile /etc/stunnel/xapi-pool-ca-bundle.pem /etc/stunnel/certs-pool/{MASTER_UUID}.pem Respectfully,

Hello. Thank you for your input. I am aware, that this is more of a warning message, than a error. I´m just trying to figure out, what is my best way to go here. My plan was: Setup a repljob for the vm in a lets say hourly interval On the day of the migration, shutdown the vm and start the last replication manually Disable the cr job Start the replicated vm on the new pool, check it and if all is ok, use it as new vm, otherwise start the old vm. The documentation says "If you want to start a VM on your destination host without breaking the CR jobs". Tbh i dont care about breaking the job. If everything works fine, i dont need it anymore, if not, i can setup a new job pretty fast. I was just wondering, if the new vm will stay in "blocked mode" for ever. Kind regards

@pierrebrunet I have updated my XOA and Proxies... It seems i did not see the warning on the next round of backups. Will continue to monitor now patches are installed.

@poddingue Confirmed working, thank you so much for the heads-up, this made my day! Got it wired into the n8n flow and it's running perfectly. One gotcha for anyone else landing here, name_description gets rejected with a 422 "excess property", it has to be nameDescription. Working body: { "nameDescription": "nginx, app-1, app-2 | 2026-06-01" }

@Pilow Yeah, I'd run iostat and look to see how th resources are being limited, I'd run something like "iostat -dtkx 10" so you get extended stats every 10 seconds during that replication process and look at the wait, queue states, etc. to see if that helps identify any bottlenecks.

@poddingue Thank you kindly! Honestly, whatever organizational structure you think is best is fine by me.