Thanks for the screenshot, Christof. I haven't reproduced it myself yet, but I think I can see why it only hits that one field. In XO Lite's VM creation form, the rows of the disk table seem to be keyed on the disk name itself (line 12 of NewVmSrTable.vue on current master), so each character you type would make Vue treat the row as new and rebuild it, focus included. If I'm reading it right, someone reported the same thing for XO 6 in March (https://xcp-ng.org/forum/post/103160), and the XO 6 form now keys those rows on a separate field, so the fix might be small. Might be worth a mention to @Team-XO-Frontend.

Thanks, that helps. Some VMs fail to the Synology but pass to S3, and some the other way round. So I think the backups on Ark are probably fine (they pass health checks, as you said at the start) and it has more to do with what each target already holds, but I could be wrong. I'd also flag the several delta jobs with different retentions all feeding Ark, I just don't know the mirror code well enough to say whether that matters. @Team-XO-Backend, posts 6 and 10 have the log and the pattern if someone gets to this one.

@mdm thanks for checking Reconnect. If I'm reading the code right, both actions have the same mistake, so one fix should cover both. You already wrote the steps out in your first post, so if you're up for it, an issue on https://github.com/vatesfr/xen-orchestra/issues would put it where the frontend team tracks their work. Their bug form asks for the XO version (or commit if you're on sources) plus your Node and XCP-ng versions, which I don't know for your setup.

If you have the time, an issue on https://github.com/vatesfr/xen-orchestra/issues with your build date and that ps -T output would make the case better than I can.

Thanks for the feedback!