@the_jest Not showen in this picutre but this is where the message would be displayed. Next to the name of the host... [image: 1782931263879-screenshot-2026-07-01-144023.png]

@poddingue Yeah, that does make sense. I understand that this wouldn't necessarily be an intended usecase. I'll probably just get a cheap consumer GPU. And apologies for if this question is painfully obvious, but how would I mention @Team-Hypervisor-Kernel? But if I can hypothesize, firmware is usually accessible via sysfs, there's an Archlinux guide here: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Determine_OpROM_signature for determining OpROM signatures, which includes getting it as a file, so maybe that could be loaded in someway, but I know not of the feasibility of that.

@Pilow no.

@poddingue said: Thanks for the detailed write-up, Pedro. I'm not a backup expert, far from it. but you might be right that https://github.com/vatesfr/xen-orchestra/pull/9396 only fixed the size estimation for direct full backups, not the mirror path. Your error is the same as the maximum size allowed one, just twelve bytes over 209715200000. Before this turns into a GitHub issue, it would help to know whether it reproduces on a fresh mirror job and whether bumping minPartSize actually cleared it, so we can be sure it's the mirror code and not the B2 remote settings. The object storage docs list Backblaze B2 as supported (https://docs.xen-orchestra.com/xo5/object-storage-support#supported-storage-providers) but don't say much about part-size tuning. If it's awkward to test in isolation, a mention to @Team-XO-Backend is probably the quickest route, since they own the backup job code. The XVA checksum warnings in your second screenshot look like a separate non-blocking clean VM directory step rather than the cause. I hope that points somewhere useful! nice catch and the mirror path is easier to fix . Thaks @pedro_udifar and @poddingue we will fix it asap will it be possible to test a potential fix @pedro_udifar , since it's often specific to a provider ( and need huge VM to work )?

I'm doing some testing on my RAID since it appears to be a RAID VDR52: The consistency check found inconsistent parity data on Virtual Disk 1 on Integrated RAID Controller 1. Buffer I/O error on dev dm-9 Buffer I/O error on dev dm-5 Buffer I/O error on dev dm-7 async page read I will keep everyone posted

Hello! Just an idea but maybe the PCI link speed you are seeing is related to some sort of energy saving feature? Background: I have a Nvidia GPU in my PC and when there is no load the PCIe speed is lowered from PCIe 4.0 to 1.1 due to energy saving feature. [image: 1782894839133-fbd06c41-50cb-4334-9c98-92a3b6573389-image.jpeg] So yeah, I think @teddyastie 's idea is a good approach here. Try how your setup behaves during a workload.