@Pilow I am rerunning the backups after recreating the schedule to see if the error clears [image: 1775871008868-6f0d3051-1254-4d10-989b-c77a832378c9-image.jpeg]

@omatsei said: @omatsei I figured out the problem. There appears to be a bug in XO that requires you to check "Check Certificate" and/or "Start TLS", save the configuration, then uncheck them, then save again. Then it should work. The bug is that they're unchecked by default, but apparently they're enabled in the background. Thanks for that, I was stump on this one trying to reconfigure a new instance. This is defintely the case even with the latest auth-ldap (v0.10.11) plugin.

@pierrebrunet Hi Pierre, I really appreciate you taking the time to respond here. Noted on the ‘unused XVA’ explanation. So the unlinked metadata is not necessary for VM recovery from a backup exhibiting this warning, right? As for the ‘XVA might be broken’ warning, this draws some concern. For every single backup I run, atleast 1 or more VMs exhibit this message. I just ran a manual backup of all my VMs today, 4 out of 12 of them had ‘XVA might be broken’ attached to them, even for completely idle Rocky Linux web app servers. Surely users can't be expected to just continuously run subsequent manual backup jobs because of this message? What would potentially cause the compressed XVA to become corrupted? And why can't said-corruption be validated in any practical way outside of “just running backups again”? Constantly running backups and hoping the ‘XVA might be broken’ warning doesn't show, and constantly validating past backups who had this message attached to them all sounds incredibly time-consuming. Shouldn't backups bring peace-of-mind, not hours worth of unplanned validation work? Yes of course any good admin should periodically test their backups, but doing so as often as each time this message is shown seems entirely impractical.

@tsukraw It's not your fault, it's a bug (@florent, two bugs) in XO. Backup should fall back to non-NBD and warn there is a network issue, second it should not say delta at the bottom when it's doing a full backup. Known issues, I hit both last month without warnings... I do hourly CR and I have the full interval set to 168 (once a week). You could set it longer if you have a slow link but backups are reliable. The full backup on CR is more of a data integrity issue. Deltas are just updates to the existing data. If there is a data problem with a delta then the copy is no longer 100% correct. The full backup (assuming it makes it over to the other site) ensures a full fresh copy without relying on past deltas being correct. If you do CR nightly then setting full to 30 would be once a month. It would be nice to have a skew option to have full backups automatically done on some VMs but not all at the same time.

Package landed in testing repo please check the related announcement: https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/432 Then please confirm the issue is gone by editing post topic with "[SOLVED]" prefix

Here's a work in progress version of the FAQ that will go with the release. QCOW2 FAQ What storage space available do I need to have on my SR to have large QCOW2 disks to support snapshots? Depending on a thin or thick allocated SR type, the answer is the same as VHD. A thin allocated is almost free, just a bit of data for the metadata of a few new VDI. For thick allocated, you need the space for the base copy, the snapshot and the active disk. Must I create new SRs to create large disks? No. Most existing SR will support QCOW2. LinstorSR and SMBSR (for VDI) does not support QCOW2. Can we have multiples different type of VDIs (VHD and QCOW2) on the same SR? Yes, it’s supported, any existing SR (unless unsupported e.g. linstor) will be able to create QCOW2 beside VHD after installing the new sm package What happen in Live migration scenarios? preferred-image-formats on the PBD of the master of a SR will choose the destination format in case of a migration. source preferred-image-format VHD or no format specified preferred-image-format qcow2 qcow2 >2 TiB X qcow2 qcow2 <2 TiB vhd qcow2 vhd vhd qcow2 Can we create QCOW2 VDI from XO? XO hasn’t yet added the possibility to choose the image format at the VDI creation. But if you try to create a VDI bigger than 2TiB on a SR without any preferred image formats configuration or if preferred image formats contains QCOW2, it will create a QCOW2. Can we change the cluster size? Yes, on File based SR, you can create a QCOW2 with a different cluster size with the command: qemu-img create -f qcow2 -o cluster_size=2M $(uuidgen).qcow2 10G xe sr-scan uuid=<SR UUID> # to introduce it in the XAPI The qemu-img command will print the name, the VDI is <VDI UUI>.qcow2 from the output. We have not exposed the cluster size in any API call, which would allow you to create these VDIs more easily. Can you create a SR which only ever manages QCOW2 disks? How? Yes, you can by setting the preferred-image-formats parameter to only qcow2. Can you convert an existing SR so that it only manages QCOW2 disks? If so, and it had VHDs, what happens to them? You can modify a SR to manage QCOW2 by modifying the preferred-image-formats parameter of the PBD’s device-config. Modifying the PBD necessitates to delete it and recreate it with the new parameter. This implies stopping access to all VDIs of the SR on the master (you can for shared SR migrate all VMs with VDIs on other hosts in the pool and temporarily stop the PBD of the master to recreate it, the parameter only need to be set on the PBD of the master). If the SR had VHDs, they will continue to exist and be usable but won’t be automatically transformed in QCOW2. Can I resize my VDI above 2 TiB? A disk in VHD format can’t be resized above 2 TiB, no automatic format change is implemented. It is technically possible to resize above 2 TiB following a migration that would have transferred the VDI to QCOW2. Is there any thing to do to enable the new feature? Installing updated packages that supports QCOW2 is enough to enable the new feature (packages: xapi, sm, blktap). Creating a VDI bigger than 2 TiB in XO will create a QCOW2 VDI instead of failing. Can I create QCOW2 disks lesser than 2 TiB? Yes, but you need to create it manually while setting sm-config:image-format=qcow2 or configure preferred image formats on the SR. Is QCOW2 format the default format now? Is it the best practice? We kept VHD as the default format in order to limit the impact on production. In the future, QCOW2 will become the default image format for new disks, and VHD progressively deprecated. What’s the maximum disk size? The current limit is set to 16 TiB. It’s not a technical limit, it’s a limit that we corresponds to what we tested. We will raise it progressively in the future. We’ll be able to go up to 64 TiB before meeting a new technical limit related to live migration support, that we will adress at this point. The theoretical maximum is even higher. We’re not limited by the image format anymore. Can I import without modification my KVM QCOW2 disk in XCP-ng? No. You can import them, but they need to be configured to boot with the drivers like in this documentation: https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/#-from-kvm-libvirt You can just skip the conversion to VHD. So it should work depending on different configuration.

main.xxx (azazel.xxx) Snapshot Start: 2026-04-10 00:03 End: 2026-04-10 00:03 Local storage (137.41 GiB free - thin) - legion.xxx transfer Start: 2026-04-10 00:03 End: 2026-04-10 00:09 Duration: 6 minutes Size: 17.08 GiB Speed: 47.42 MiB/s Start: 2026-04-10 00:03 End: 2026-04-10 00:09 Duration: 6 minutes Start: 2026-04-10 00:03 End: 2026-04-10 00:09 Duration: 6 minutes Type: full

@MajorP93 Perfect, if the issue is confirmed resolved, we aim to release a patch early next week so no hurry

Why not using anti affinity with the load balancer? This way, you can have multiple groups of VMs that won't run at the same place

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

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

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