@jerry1333 said: There is nothing else on that host and this is only host in pool but it's using 30% of cpu all the time? it's not using 30% of CPU, you see a graph of cumulated (switch is on) core consumption of your 32 cores. never switch this on. it adds up like that : 32x1%=32%, wrongfully letting you think you are at 30%ish CPU usage.

@rzr Great. Thank you!

@Bastien-Nollet I'm running c1e5f btw

Hi, Not sure to get it, XOA isn't meant to be tinkered. Why would you add an npm package on it?

Ping @gregoire

@pierrebrunet Thanks for the update. Glad to know its not something unique to our environment and you were able to track down the cause!

@TechGrips Hi, Unused XVA means a XVA file is not linked to any metadata (to remove a backup, we first remove the metadata file linked to it, then we remove the XVA), it should be removed by clean vm step. It is not an issue, just an information. For the second warning "XVA might be broken", this is because the compressed file seems to be corrupted but we cannot be sure. We prefer to warn the user there may be an issue in the file. This should encourage to remake a backup.

That's indeed more on @Team-Hypervisor-Kernel side. Maybe a driver/firmware version mismatch?

@AshleyDe It was exactly that, but complicated by the abandoned status of the fuse-native module being used for XOA in 2023. That module contained binary blobs, but unfortunately no binary for aarch64. Being abandoned meant getting aarch64 into that module was not possible. My horrible bodge was to swap to an alternative module for fuse-native that built from source. Thus it avoided the missing aarch64 blob, but required additional dependancies for the compile to work. I'm no longer using XOA on the aarch64 platform in my home lab so I haven't kept up to date on whether this is still needed in 2026.