Here's the short version: this looks like the known "VDIs show up as snapshots" bug, and you haven't done anything wrong. What happens is a metadata flag on the VDI, is-a-snapshot, gets flipped to true after some of the recent 8.3 host updates, so XO (both 5 and 6) thinks those disks are snapshots and hides them from the per-VM Disks tab, even though the VDIs are fine and xe / XCP-ng Center still show them. A few older threads track the same thing, the main one is https://xcp-ng.org/forum/topic/11715/vdi-not-showing-in-xo-5-from-source . From what's said there, the fix is expected in two parts: stopping it from happening again, and a way to repair the flag on VDIs that are already affected. I don't have a timeline and could be off on the details, so please don't take that as official. In the meantime people have made the disks reappear by migrating the affected VDI to another SR, or snapshot then revert then delete the snapshot, but it's a visual fix and can come back. The VDI_IN_USE you're now hitting on start does sound worth its own detailed report, so yes please file it with the xapi/sm versions and that malformed is-a-snapshot field, and it'd be good to loop in @Team-Storage. Sorry you're stuck on this.

@PessimistTech That looks a bit odd indeed. In addition to what proposed @yannsionneau, can you also give the output of : xl dmesg (in Dom0) dmesg (in Dom0) dmesg (in the guest) So that we can try to pin-point what may be happening.

@JamesG said: So I ordered some mini DP dummy plugs and took a look at this further today. First thought...Just load Windows on the bare metal and see what the card does. No problem. Loaded Win10, loaded the latest drivers, PCIe Gen4x8 lanes. Sweet. At least that works. Put the XCP-ng drive back in, booted up, passed-through the GPU to a Win11 guest, updated the drivers, PCIe Gen1x1. As I explained briefly in https://xcp-ng.org/forum/post/106479, this is mostly display as the real hardware may be running at a different speed. Ultimately I need to install a Linux distro with a really current kernel on the bare metal and see how it sees the GPU. That might be a good project for tomorrow. I think this just comes down to a combination of too new, not well supported hardware with some quirks and somewhat dated code and support in XCP-ng (ReBAR support in guests for example). I did quick checks and I believe that ReBAR works; at least with UEFI guests (our OVMF build does support resizable bar), and it actually works as suggest https://xcp-ng.org/forum/post/106489 (VRAM BAR is 16 GB); but I didn't do extensive testing in that area.

This looks genuinely useful, thanks for building it and opening it up. The "XO config is locked in its own database" pain is real, I've watched people rebuild remotes and backup jobs by hand after a reinstall and it's a slog. Treating the backup surface as declarative YAML with drift detection that drops into CI is a clever angle. I'm curious how it talks to XO underneath, is it going through the JSON-RPC API? There's also the Terraform provider for XO (https://github.com/vatesfr/terraform-provider-xenorchestra), but that leans toward infra provisioning rather than backup config, so this seems to fill a different gap. I'd like to try it against a test XO out of my own curiosity when I get a moment. Really nice work, and folks running bigger XO fleets here will have sharper feedback than I can give.

@pedro_udifar Hi, We think we have found two issues into one: can you test this branch please? It has the changes from previous branch you built: fix_throttled_stream This should fix the stream issue and fix the warning.

I'm having the same problem. The issue occurs with the XO config metadata backup.

Just to give an update. I still am having the issue with current commit 090ce. Regards, Marc

@bvivi57 Hey, merci pour ce tuto ! Je vais comparer ce que tu as fait avec mes template que j'ai créer de mon coté. Si tu veux comparer, le repo est ici https://github.com/disruptivemindseu/xcpng-template-builder/tree/main

Great! I think this is really the best possible approach to make it clean

@olivierlambert said: On your backup remote, look at the file left behind by the failed run It's empty I increased the schedule to every 30 min. All 3 of them are OK [image: 1783076106533-ddfcf1d5-bae9-4a7a-b45d-64ba131fe80c-image.jpeg]

@dvdwx said: Hi Anyone already tried to review why Users with User permission cannot have the topology menu to edit on their Self-Service resource page? the have admin permission on their self service resource set but cannot edit this setting: [image: 1783021889506-620b892c-4c04-47ca-8425-064dbceee3e8-image.jpeg] [image: 1783021936003-28d03549-b715-44b6-966f-5d4a5a905825-image.jpeg] If i log with and full admin account on Xen Orchestra it can be edited: [image: 1783022030501-b4af0d96-e6c9-4aec-bd23-5b0869b9b31a-image.jpeg] We are using an HA Pool with 2 hosts to LAB for our NOC/SOC team. I already tried to create an ACL with user/tag/group with advanced permission but it release a full permission on the pool and it cannot be delivered to the team. if anyone know a workaround to fix it.. I appreciate that. As RBAC ACL is implemented for Xen Orchestra 6 you’ll likely find this more possible than currently on Xen Orchestra 5.

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.

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.