@Aleksander You would need a gpu that support SR-IOV. From NVIDIA that means a non consumer gpu. Edit the below is Ai output. GPU SR-IOV support varies significantly by vendor and architecture, with Intel offering the most extensive hardware-based SR-IOV for consumer and data center graphics, while NVIDIA and AMD rely heavily on proprietary drivers or specific enterprise hardware. Intel Graphics support is the most widespread for virtualization, with 12th Gen (Alder Lake), 13th Gen (Raptor Lake), and 14th Gen (Raptor Lake Refresh) Core processors supporting SR-IOV, as do the Intel Data Center GPU Flex Series and Intel Arc Pro B-Series (requires driver version 32.0.101.8306 or newer). Older generations (6th through 10th Gen) primarily support GVT-g (software-based mediation) rather than hardware SR-IOV, while the Intel Core Ultra Series 1 (Meteor Lake) and Series 3 (Panther Lake) do not support SR-IOV. NVIDIA supports SR-IOV primarily through its proprietary vGPU and MIG (Multi-Instance GPU) features on enterprise-grade hardware, including the A100, A40, A30, RTX A-series, and Tesla lines. While open-source drivers like Nouveau exist, NVIDIA's proprietary Mdev driver is the standard method for enabling SR-IOV and mediation, often managed via tools like sriov-manage in environments like Harvester or OpenStack. AMD SR-IOV support is limited to older FirePro and Radeon Pro cards (e.g., W7100, S7150, V520) using the deprecated GIM or MxGPU drivers. Support for modern Navi and RDNA architecture consumer GPUs is currently unclear or non-existent in open-source ecosystems, with AMD reportedly focusing SR-IOV capabilities on exclusive enterprise contracts rather than consumer hardware. Vendor Architecture SR-IOV Support Status Key Hardware / Notes Intel 12th-14th Gen Core Yes (Hardware) Iris Xe, Data Center Flex, Arc Pro B-Series Intel 6th-10th Gen Core No (Software/GVT-g) HD Graphics 5500–630, UHD 620/630 Intel Core Ultra (Series 1/3) No Meteor Lake, Panther Lake NVIDIA Ampere/Hopper/Ada Yes (Proprietary) A100, A40, RTX A6000, Tesla T4 (via vGPU/MIG) NVIDIA Maxwell/Pascal/Turing Yes (Proprietary) Tesla P100, T4, Quadro RTX (via vGPU) AMD Tonga/Vega/Navi Limited/Deprecated FirePro S7150, W7100 (GIM driver); Modern support unclear

Hi, Someone from the Hypervisor & Kernel team will have a look shortly, we'll get back to you with our findings. Thanks a lot for the very detailed report! Yann

@TheNorthernLight Thanks for pointing that out, that totally makes sense, I should have realized to look it up that way. I guess I just think of XCP-ng as its own product so much that I forget it's based on Xen even though I know that.

I've seen this happen after a BIOS update or if a CMOS battery starts failing. Sometimes the motherboard resets to 'Legacy' instead of 'UEFI' (or vice versa), and GRUB just loses its mind because it can't find the partition it expects. It’s worth a quick check in your firmware settings to make sure the boot mode and the drive order haven't shifted on you.

@TeddyAstie I hadn't seen anything special was needed in a VM other that a kernel new enough for support which 6.17 has, is there more to the story with adding things to Ubuntu?

@DustyArmstrong Thanks for responding to the GitHub issue. It’s great that more people want this working; it’s difficult to gain traction otherwise. Regarding your list, it’s correct. A reboot should be on the second place. You need to reboot only to detach your PCI device (video card) from its driver and assign it to the pciback driver instead on the next boot. This effectively creates a reservation for the device and allows you to dynamically assign it to VMs. Once your card is free from other kernel drivers, the rest doesn’t require a reboot.

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

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?