I performed a full backup and a delta backup test. The full backup is working, but the delta backup is not. If you look at the image, I performed 2 full backups successfully, but the first backup, which is not encrypted and is a full backup, is not here — only the .json file that generated it is present. Where would the delta backup be located if not in the same folder as the others? According to the log, I only saw the same location being used. [image: 1780419911823-3f42504c-23cc-410d-b3f4-cfaba3b128a3-image.jpeg]

@LucienLassalle — Thanks Lucien, appreciate the detailed reply. Glad we landed on the same result independently, and the CI/testing rationale makes complete sense — stability matters more than rushing a same-day patch. Good to see June Updates #1 out covering Fragnesia, ptrace_may_dream, and Pintheft, and good to know CIFSwitch will likely be treated the same way. I'll keep checking the blog and the VSA registry. And noted on security@ for future reports. Thanks for the great work as always.

@Bryanvh I think I've managed to reproduce the issue. The fact that the master's certificate is missing from /etc/stunnel/certs-pool/ seems to be the problem. On the master, run xe host-refresh-server-certificate host=$(hostname) and then xe pool-certificate-sync. Then, if you run ls -l /etc/stunnel/certs-pool, you should see a certificate with the same name as your master's UUID. It should end with .pem. If it ends with .new.pem, I recommend copying the certificate, removing the .new (which can apparently cause problems). You should then be able to join the pool from your host. I hope this worked. Please let me know if it works. 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