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 for the quick response and the effort in recreating the issue! It all played out exactly as you laid it out, even the cert showing up as a .new.pem at first. Out of curiosity, what in your testing did result in causing this issue? Is it possible that my upgrade from 8.2 to 8.3 may have caused the underlying issue?

@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.

@olivierlambert Any chance of revisiting this issue and allowing a VM VIF MTU to be changed from XO? If not in the main display (where it shows the MTU), then in the Advanced settings window (which seems like a good and easy place to have the MTU option). I have a small XCP server that has MTU 9000 set on the main (and only) interface but most VMs need to be set to 1500. The windows Xen network driver just inherits the MTU from XCP. Yes, you can use the CLI in Windows or XCP to change it, but it would be nice to have it in XO for that VIF (VM restart required).

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