I was thinking more of updating the entire set of the agent and drivers, similar to how XenServer VM Tools for Windows have it implemented. Using a scheduled job, they regularly check whether an update is available, and if so, they carry out the update of both the agent and the drivers themselves.

That would explain things, and also why my latest test using AlmaLinux 10 also failed in the exact same way that Rocky Linux 10 did. I just wish I read this reply 12 hrs ago Think I'll give this stuff a go on v9 of Rocky Linux and AlmaLinux to check things are working, which I imagine will work fine. I've just confirmed the EPEL version running on AlmaLinux 10 at the time of writing this comment is indeed v 10.1 via the command; sudo yum repoinfo epel @dknight-bg What is the best way to keep track of this stuff proactively, i.e. What would I need to look at so that I could have determined what you have commented myself?

Thanks a lot for this In few months ago I have found your topic to try wazuh, and it is working good. After some error on my home lab, I need to install all again and remember your topic. On my installation, I just need to set /dev/xvda1 (if I just put /dev/xvda, VM not start). My home lab is on ProLiant DL360 Gen9.

Hello @florent , You mean, "check" right ? because if it's doesn't check, the job is finished before the merge and the merge run in background in xen orchestra. Best regards,

Ping @florent or @bastien-nollet

@Forza I can confirm the behavior, all points being copied, then pruned to target retention... for now it seems to not be a bug but a feature, to not have to think of what happens in the source job in smart mode (VM added/substracted to the source job) "we copy all and see afterward" but @bastien-nollet and @florent can confirm on that ? ps: I had this on mirror incremental backup, as I do not do full backups.