@samuelolavo Thanks for your answer It's very weird because by seeing the command outputs that you pasted, it looks like everything is behaving as it should be. Even the PCI ID (segment:bus:device:function) seems to stay correct (0000:03:00.0) I'll ask others internally.

@TeddyAstie Thanks for the update. I do actually have a VBIOS for that GPU, but I wasn't entirely sure what to do with it - is there a process to inject it? I've found resources for Proxmox and others, but I really like XCP and equally I don't want to migrate my entire setup just for that. If it's really tricky then I'm not too worried about it, as I say the VM actually runs the cameras perfectly fine on CPU alone, it's negligible. Edit: Looks like this post might answer my question: https://github.com/xcp-ng/xcp/issues/786 "Even when specifying romfile and rombar properties on the xen-pci-passthrough device in QEMU, the ROM region is not mapped into guest memory." timemaster5 created this issue in xcp-ng/xcp open PCI ROM BAR not exposed to guest when using xen-pci-passthrough #786

I am in the same situation as @vhaelan. same as in same iGPU (alderlake) passed-through, same output for those latest commands, same OS (Fedora CoreOS on latest Xcp-Ng stable). Tried current avenues suggested in this thread with no progress. It seems vhaelan has settled with CoreOS under Proxmox (which works!). He also mentioned it works in Debian under XCP-ng, though I haven't tested that myself. I would appreciate additional suggestions for troubleshooting to take this further, in case anyone has any other ideas.

@Greg_E Thanks, I've got another thread up and it's potentially being addressed!

Hi, does anyone have any tips regarding getting the serial port to show up in xcp-ng? I imagine this normally should just work.. I am not sure why it doesnt show up in xcp-ng, while it shows enabled in the bios?

@comdirect Use this command: (replace sda in the command below with the relevant device) cat /sys/block/sda/queue/scheduler The active scheduler will be enclosed in brackets. e.g. noop deadline [cfq] For multiple drives use: grep "" /sys/block/*/queue/scheduler

@stormi Thank you so much. Only now getting around to setting up another set of R660s, will let you know how this works. Edit: worked beautifully on a new set of R660s. Using the old 20250606 ISO, the BCM57414 were not detected. The new ISO works as expected (BIOS install, did not attempt UEFI) and the NICs are all enumerated properly.

@AtaxyaNetwork Hi yes, Sorry I'm not super experienced in this area at all. I'm SSHd into the host and just ran dmesg -T in the root. [image: 1771509732474-0583e493-4d70-40b7-afc0-a88b0d9fd1a4-image.png]

@acebmxer There are older versions of the guest tools still available on Github.

We do upgrade drivers, especially via alt, it's pretty safe (LTS doesn't mean frozen drivers). @stormi could confirm.

Good afternoon, I have resolved the problem. Domo was trying to use the network Controller. Fixed it by using, /opt/xensource/libexec/xen-cmdline --set-dom0 "xen-pciback.hide=(0000:44:00.0)(0000:44:00.1)(0000:45:00.0)(0000:45:00.1)" reboot xl pci-assignable-list Xen Orchestra now allows PCI Networking Card to Pass-Through the VM. Regards

@DustinB said in Recommended DELL Hardware ?: Doesn't using non-shared storage ultimately cause the VM to be started on the other host? No. Live migration can occur between hosts even if: the VDI are located on non-shared storage the hosts are in completely different pools For the cross pool migration to succeed, both pools need to support a common instruction set. Otherwise, use the Warm Migration feature that does reboot the VM so that it is running the correct instruction set on the destination host.

@whyberg Nope... that feature is part of the CPU. But is that the actual problem? Maybe... As that machine is too old to do any real work, it's a fine toy. There are better faster cheap test machines available.

@wlp94114 for example, did you get any warnings in the kernel logs about the firmware version mismatch?

Ahh excellent news. So indeed the new kernel sees the device USB policy will be improved in the future so it's kept after updates, so doing it once will be enough. Thanks for testing!

Hi! See https://docs.xcp-ng.org/releases/release-8-3/#4k-native-disks and https://docs.xcp-ng.org/storage/#largeblock-sr Note that qcow2 format is supporting 4k natively, and it's in release candidate stage, maybe the right approach in a near future

Mentioning also @Team-Hypervisor-Kernel who now manages the drivers. Maybe it's related to https://github.com/xcp-ng-rpms/microsemi-aacraid/issues/2#issuecomment-3837183087 It looks like the switch to the vendor driver instead of the kernel built-in for 8.3 (initiated by XenServer, and that we followed at the time as it was probably made in order to support newer cards) was not without drawbacks. 0nelight created this issue in xcp-ng-rpms/microsemi-aacraid open Microsemi Adaptec Series-8 Card not working in XCP-NG 8.3 #2

Hi @champagnecharly , On the XO side, it seems that this PCI has an empty string ID, which doesn't enable us to delete it. We'll have to do some tests to find out how to prevent that. We might have trouble reproducing the issue, so would you mind helping us with the tests? You would need to add this piece of code on file xo-server/dist/xapi-object-to-xo.mjs before the line that start with if (isHvm) { (that should be near line 475) if ((_vm$attachedPcis = vm.attachedPcis) !== null && _vm$attachedPcis !== void 0 && _vm$attachedPcis.includes('')) { warn('Empty string PCI id:', otherConfig.pci); } then restart xo-server and look at the output of journalctl, there should be some lines looking like: 2026-01-30T09:26:17.763Z xo:server:xapi-objects-to-xo WARN Empty string PCI id: