@flakpyro that's a good news ( but at least another user saw this) we are currently testing the branch ensuring that at least the fix don't create other issues

@florent I can confirm that this fixes the issue!

@Pilow open a dedicated topic on this . I will ping the relevant team there is it iscsi + CBT ?

@florent Awesome, i have patched a second location's XOA and am not experiencing the issue anymore there either.

I think this is fixed in 6.7: when a delta backup falls back to a full, the task now shows the actual reason instead of just contradicting itself the way you and Andrew both saw (PR #10148). Worth checking after you upgrade.

@flakpyro From my experience, VM with UEFI boots faster than BIOS. For some OS versions UEFI runs faster IF there are no Xen drivers. But for most installs it does not matter much, except for Debian... which has given me problems with pool/migration/reboot with the UEFI installs on XCP (there's a workaround). So, I would vote for UEFI as the default for all OS/VMs that support it correctly since most are moving to that anyway (including XCP hosts).

@olivierlambert Makes sense! I would schedule the replication to occur a couple hours after the backup runs are complete to ensure its a replica of all data and not a partial replica!

@olivierlambert Yes, once CBT with Snapshot purge is production ready that will totally solve our problem! Perhaps its better to just wait for that. I wondered if they were doing something like a partial restore of the metadata as well.

@flakpyro for now there is no tag selector , but you can now select the VM list to be replicated

It is possible to have both AMD and Intel in the same pool. My homelab had it until recently when I upgraded RAM and retired the optiplexes just recently. Live migration will not work, however, shared storage will work. You just have to shutdown the VM and "Start on" the specific host. In the VM Advanced tab.