PRs upstream are in review

Hello @mgr42 I can confirm that indeed today AMD iGPU passthrough is not working on XCP-ng. I am currently (slowly) working on it. There are other references about this topic in the Forum and on GitHub FYI: https://xcp-ng.org/forum/topic/11918/amd-barcelo-passthrough-issues-any-success-stories https://xcp-ng.org/forum/topic/8909/issue-to-load-gpu-passthrough-invalid-pci-rom-header-signature-expecting-0xaa55-got-0x4556 https://github.com/xcp-ng/xcp/issues/806 https://github.com/xapi-project/xen-api/commit/930ffb34e42d674b8234c3d8399fdba97efa6b38 On the setup I am working on, the Expansion ROM is provided indeed by firmware via the VFCT ACPI table. I dumped it to a file and provided it to qemu-dm xen-pci-passthrough device via the romfile= argument (via a modified XAPI build). I can now indeed see a ROM bar in the guest but unfortunately its content is not the content of the file therefore nothing works (amdgpu driver is unable to get its ROM and fails). So now I'm debugging qemu to try to understand the issue with the emulated/passed-through ROM BAR. Regards, Yann Kernel & Hypervisor team timemaster5 created this issue in xcp-ng/xcp open Unable to set romfile for xen-pci-passthrough devices #806 0 freddy77 committed to xapi-project/xen-api CA-418993: Enable PCI ROM BAR before attempting to give permissions to the VM Currently the VM is not able to access the ROM as the host ROM BAR is disabled and not set. Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>

Ping @julienXOVates

Ping @julienXOVates

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

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

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

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

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!

@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

@Danp said: Smart Reboot option found on the host's Advanced tab does what you are asking Very nice!

@Pilow pretty much

@olivierlambert said: I'm not sure it's a great idea, because even 64 hosts is huge in terms of VMs and fallout if you have a problem on your pool DB. Even if you drastically improve the current mechanism, the impact of a problem pool wide is far bigger with 64 hosts than 24 for example. It's more than purely tech, it's also a tech design/choice. Exactly, the failure domain just grows exponentially when going beyond a certain collective pool size. I was doing some more research and I found a few possible choices that Tesco may have moved too, but don't want to detract from this forum here.