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

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

@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

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.

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.

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