@nikade Hey Nikade, Did you try to create a new job that will do a new chain ? Just for test.

I did get a snapshot at one of the CR VM's with the 449e7 version. I don't with 5bdd7

I thought I solved it.. but now the problem is back again: Yesterday, 14 March, I did the following: deleted the snapshots on the running Deb12-XO machine, so it was clean deleted the clones of the machine ran the backup job maually - with success (transferred about 30G to the other host) (still on the "old" XO version) Checked the destination host - no clone (backup) of the VM found. manually created two (full, not quick) clones of the VM so it won't be lost of anything goes sideways updated XO to the latest (2aff8) let it do the relication according to the schedule 21:00 replication success Next morning (15 Mar) 09:00 replication also ran without any issues - at least according to the log. no additional copy of the VM on the destination host (retention is set to 2, so I should have one 21:00 and room for the 09:00 too) Evening replication, 21:00, failed. Got that same error message as before: VM Backup report Global status : failure Job ID: 883e2ee8-00c8-43f8-9ecd-9f9aa7aa01d1 Run ID: 1773604800005 Mode: delta Start time: Sunday, March 15th 2026, 9:00:00 pm End time: Sunday, March 15th 2026, 9:00:13 pm Duration: a few seconds Successes: 0 / 1 Transfer size: 126 MiB 1 Failure Deb12-XO Debian 12 XO self-install Pool id: 4cc74549-71c3-31d5-f204-7106e90acd1e UUID: 30829107-2a1b-6b20-a08a-f2c1e612b2ee Start time: Sunday, March 15th 2026, 9:00:02 pm End time: Sunday, March 15th 2026, 9:00:13 pm Duration: a few seconds Error: _removeUnusedSnapshots don't handle vdi related to multiple VMs Deb12-XO - Deb12-XO - (20260315T080004Z) and [XO Backup Deb12-XO] Deb12-XO = I notice the name of the snapshot seems odd: [XO Backup Deb12-XO] Deb12-XO - Deb12-XO Maybe just a new naming convention, but I found the old one better (for my Admin VM): Admin Ubuntu 24 - Admin Ubuntu 24 - (20260201T125508Z) Admin Ubuntu 24 - Admin Ubuntu 24 - (20260208T125508Z) (I assume the double "Admin Ubuntu 24" is because the backup job name is the same as the machine name)

@DustyArmstrong Thanks for responding to the GitHub issue. It’s great that more people want this working; it’s difficult to gain traction otherwise. Regarding your list, it’s correct. A reboot should be on the second place. You need to reboot only to detach your PCI device (video card) from its driver and assign it to the pciback driver instead on the next boot. This effectively creates a reservation for the device and allows you to dynamically assign it to VMs. Once your card is free from other kernel drivers, the rest doesn’t require a reboot.