@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

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

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

@Pilow no.

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.

I've installed the latest updates to all hosts, and restarted everything. I also have all xcp-ng logs going into loki now, so next time something happens I will see everything lol. [image: 1782860175138-156f9ac1-f1bb-47f3-a789-8551c8614805-image-resized.jpeg]

Thanks, I made the feedback to the XO team, this will be fixed ASAP.

@yllar I'm not sure, maybe it'll slip to July. But what I can say is that the ISO is currently being tested in our QA process. Brace yourself, it's coming soon

Meant to update this again last night - as a road map for those who might try similar at some point: This community's documentation led me to some relevant information on mouse/keyboard pass-through. Namely, if you want this to work you have to pass the entire PCI controller through to the guest(s), Won't work with motherboard devices. But I'm out of PCIe slots. What to do... Simple. Chuck the two serial adapters and install two dual USB 2.0 adapters in their places. Connect the keyboard/mouse to one of the ports and a 4/8/16 port USB to serial adapter to the other. Then pass the entire controller through. In this particular server (R810) I have 5 available PCIe slots. Two will be used for the video cards, one for a 4x NVMe to PCIe adapter (which is eventually where the VMs will reside) and the remaining two for the USB interfaces. This effectively gives me two discrete physical systems, a third available VM instance (say, for network management, monitoring or whatever) and the XOA instance. For application/radio control systems hypervisors (nested) I'll probably have 2ea Win11 and whatever flavor of Linux that supports the GT730 GPU on the system - each assigned the pass-through devices - but only two running at any given time. So no resource contention issues. As far as the displays: I have the main interface of the server connected via SIP to a 2160AS KVM. I'll take 2 more SIPs and use these as the keyboard/mouse inputs for the USB cards. Video...I use an HDMI active splitter on other systems in the network so I'll employ that here. One of the ports on the add-in GPUs goes to the splitter, one of the splitter outputs goes to the SIP via HDMI to VGA adapter and the other feeds the main ceiling mount monitor. The Primary display will be replicated to the KVM screen. Resolution isn't an issue as I have a video scaler inline with the KVM for just this scenario. The concept could be expanded. I'm looking at picking up a T630 and building 4 effective "systems" out of it, following the same principle. The 630 has 8 available PCIe slots. Will update when the next batch of hardware arrives - or I get the Linux side of things sorted. That's next.

@Tristis-Oris Hi, Can you upload your complete logs from one of these jobs, please? You can DM me if you prefer

@poddingue Thanks for the reply. I have been checking the source code of the Netbox plugin over the weekend and added the necessary code to enable the virtual disk sync. In Netbox itself, you do need to add the correct permission for it to work. Will do some more testing during the week, and create a pull-request once I'm satisfied with the result. Up to the Vates if they want to merge it into the main branch. Thank you for your reply!

@andibing said: I'm seeing this on XOA: xoa@xoa:~$ sudo xoa-updater --upgrade ✖ { message: 'missing string at offset 151' } xoa@xoa:~$ Unless the sun has got to me, I don't seen any other references to this error. And Gemini was confused too! Any thoughts? Can you please run “df -h” to start? If either / or /tmp/xoa-updater are low on space please increase disk space or run a clean up. The disk space on the VM and/or the SR may be too low, for the update to succeed. The XOA update metadata cache may have become corrupted and need to be cleared, before re-attempting the update. Checking the logs will help to determine if that’s the case.

@olivierlambert Thanks for being so transparent about this. I suspect just updating that error message should be helpful enough. I was really struggling yesterday as I couldn’t figure out why my test plan was failing. Your suggestions did indeed work. In my case just disabling HA briefly did the trick

For your storage question, it's fully explained in the doc: https://docs.xcp-ng.org/storage/#-how-to-modify-an-existing-sr-connection And yes, it's planned to get the complete error visible in XO, sadly, it's not "obvious" since the error message isn't returned by XAPI when you try to start but by another method we need to call after it fails ("assert can be started here" from the top of my head). Let me ping @julienXOvates

Well you both just made my Friday! I can follow directions after all!

Evening @pierrebrunet My bad. I am now on commit b440f and the issue persist. I have written you a message with the link to the file. Regards, Marc

@niko thanks, that would help a ton!

mid 2026: you can't add a ipv6 address via XOA (XOA5) because the gui lacs the field for the v6 gateway-address XOA6 lacks feature to configure ips of the host the configuration of ipv6 (static) vie the "gui" on the host seems not be implemented yet (or i am missing something critical) command line configuration inside dom0 of the host is afaik not supported ? Some point looks like minor issues. it would be great to "address" pun intendet that as well