Throwing my two cents into the hat, as well. I had a similar situation. Snapshots would't be rotated out of retention, regardless of what I set on the retention setting (on a subset of VMs ie not all of the).. The thing that solved it for my, was to recreate the affected schedule. Do note that this will mark the previous backups taken by that technically deleted schedule, as being abandoned/orphaned. But after I did this, snapshots would be properly rotated as expected.

another example, on another client server : yesterday we were on XOA 6.0.3 [image: 1775673583836-44f9a93b-3e8e-45b4-9a98-767489a3cb80-image.jpeg] today we updated to XOA 6.3.2 [image: 1775673618586-91898d80-a37f-4ca7-bcb1-f3340d45530b-image.jpeg] clean-vm get from 4min to an hour on this single VM ! for barely 5Gb transfer size same VMs, same NFS remote on same NAS, nothing changed except XOA version whole backup window on this 12 VMs job is shifted +4hours (still not finished...)

@Tristis-Oris maybe a few comparative screenshots would help

@Andrew Yeah but XOA is still using it hence my interest in aligning my XO-CE instance with XOA as close as possible.

+1 this. We would like to run certain VM's only in certain datacenters, but allow the VM to migrate to other hosts in the same datacenter.

Hi, Someone from the Hypervisor & Kernel team will have a look shortly, we'll get back to you with our findings. Thanks a lot for the very detailed report! Yann

@rzr Great. Thank you!

@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.

@Bastien-Nollet I'm running c1e5f btw

@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.

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

@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.

If you're looking for a quick way to verify those files without running a full restoration test every single time, you can usually run a checksum comparison (MD5 or SHA256) against the original data. For a more 'point and click' approach to double-check specific files or verify hashes quickly, I've used https://thetoolapp.com/utilities/file-integrity-checker/ before. It’s pretty handy for a quick integrity check if you aren't in the mood to mess around with the command line for every single backup set.

Hello @tsukraw , normally your client should be able to bind the new license on their XOA. BTW, you talk about binding the license to a pool but an XOA license is bound to an XOA. I suggest your customer open a support ticket so we can help them with that issue.

For my reference later. wget http://downloads.hpe.com/pub/softlib2/software1/pubsw-linux/p1257348637/v76502/hpacucli-9.20-9.0.x86_64.rpm yum install -y --nogpgcheck hpacucli-9.20-9.0.x86_64.rpm hpacucli controller slot=0 physicaldrive all show

Hi @Pilow, Thanks for the report. We are aware that there are many problems with the FLR. We would like to fix them but they are not easy to fix, and we can't give an estimation date for a fix. I've linked this topic to our investigation ticket. For the moment, when FLR fails, we recommend to manually restore your files by following this documentation: https://github.com/vatesfr/xen-orchestra/blob/master/%40vates/fuse-vhd/README.md#restore-a-file-from-a-vhd-using-fuse-vhd-cli

Replying to an old thread because this one popped up in a search. There is an open source and locally running ignition/combustion generator that I've used on bare metal. To use it with XCP-ng, we would need the ability to have a second "cd rom" drive during the install phase, one for the OS installer, one for the combustion/ignition ISO generated from the tool. https://opensuse.github.io/fuel-ignition/ They say it only runs locally, no info is send out to the web. I didn't monitor my connection on the one time I used it, and probably won't the next time (coming soon to a bare metal cluster in my lab). For the record, I'm using the LEAP version of Micro for my tasks.

@TheNorthernLight Thanks for pointing that out, that totally makes sense, I should have realized to look it up that way. I guess I just think of XCP-ng as its own product so much that I forget it's based on Xen even though I know that.

@DustinB thank you! I suspected as much, but as my wife points out all the time, I am terrible at finding things, so I figured I would ask.