@davx8342 That's a ton of storage, holy cow! So two pools currently, 6 Servers 31TB Shared, and then 16 servers and 400TB Shared. I honestly don't know if there is an upper or lower limit to the amount of storage supported with XOStor, I'd imagine it would work but someone else would have to confirm.

@mohammadm said in XCP-ng 8.3 & AMD Firepro S7150x2: Too bad, so at this point we have 4/5 GPU's that are pretty much useless. Any other alternatives for GPU? When using dGPU, PCI-e passthrough to the VM itself, it does work but after a while the whole screen turn black. They have to disconnect and connect to the RDP session again to see the screen again. Looks like a screen suspend issue, have you tried to disable it ?

@deadman2141 I'm realizing what is happening. After the memory install the system would not boot up, the bios flags the change and forces you to go through the bios setup with a hardware change. My system runs headless so I did not pick this up. After plugging a monitor in I see that message, go into bios and then through the boot sequence. This is when I notice that the system "hangs" after that statement. What I just realized is that xo lite was responding (along with pings) while the system was hung. I pass the GPU to a VM, so once dom0 gets to a certain point the GPU goes away, leaving the monitor stuck, but the system boots just fine.

Are you on XCP-ng 8.2? Because UI to set passthrough is only possible on 8.3 up to date edit: 122 updates detected you really need to stay up to date

No problem

Ah nice catch! Happy to see it working now

@Andrew using the card in windows and using bootutil64e seems to have fix it.

Also, we might have better roles in the future to be sure other people without the right role couldn't use it.

@olivierlambert It ended up not being a resolution issue. We started having the same issue with a Windows-based server with a GUI. Our KVM is a Dell AV2108 (DAV2108) which is Dell-branded but manufactured by Vertiv (Avocent). Our console is a KMMLED185 which again is Dell-branded but manufactured by Vertiv. The KVM was on firmware version 02.02.00.00. After upgrading the firmware version to the most current, 02.08.05.00 and restarting the KVM, the issue was resolved. Hopefully this is able to assist another that encounters the same issue.

I had the same problem with a proxmox node that I'm using and the solution to this issue was solved by adding the serial port using the command qm set 102 --serial0 /dev/ttyS0. I thought that the same thing could be done here using xe or xl command; I just don't know how to achieve it in xcp-ng. The windows 11 vm shows a com1 port that has the same irq and i/o range numbers than the host; is this suppose to work?[image: 1738689956931-2025-02-04-13_13_16-windows-11-test-com-1-properties.png] [image: 1738689956968-2025-02-04-13_15_05-ret-xcpng1-ret-resource-pool-node.png]

@Andrew thanks for all your hard work. I guess time will tell if the Vates team has to add those defaults to their official package or maybe I just got "lucky"

@Shrubbery said in xcp-ng 8.3 not recognizing all host memory: The issue was memory reserved for the integrated graphics card haha.. that is such a silly thing... but good to know then next time I'm working on some hardware and wondering where the RAM is going too...

@scawtydont Thanks for keeping us posted. Dummy plug is still a thing it seems

@CodeMercenary Did some tests with the A2000 and as expected, the 12GB VRAM is the biggest limitation. Used vanilla installations of Ollama and ComfyUI with no tweaking or optimization. Especially in stable diffusion, the A2000 is about three times faster compared to the P40, but that is to be expected. I have added some results below. Stable Diffusion tests A2000 1024x1024, batch 1, iterations 30, cfg 4.0, euler 1.4s/it 1024x1024, batch 4, iterations 30, cfg 4.0, euler 2.5s/it = 0.6s/it P40 1024x1024, batch 1, iterations 30, cfg 4.0, euler 2.8s/it 1024x1024, batch 4, iterations 30, cfg 4.0, euler 12.1s/it = 3s/it Inference tests A2000 qwen2.5:14b 21 token/sec qwen2.5-coder:14b 21 token/sec llama3.2:3b-Q8 50 token/sec llama3.2:3b-Q4 60 token/sec P40 qwen2.5:14b 17 token/sec qwen2.5-coder:14b 17 token/sec llama3.2:3b-Q8 40 token/sec llama3.2:3b-Q4 48 token/sec During heavy testing, the A2000 reached 70°C and the P40 reached 60°C both with the Dell R720 set to automatic fan control.

@steff22 said in Gpu passthrough on Asrock rack B650D4U3-2L2Q will not work: @ravenet Ok I think the pro gpu's work better without so many bugs. I switched to Nvidia RTX 4070. With the Nvidia gpu and this works as it should and gets an image on the screen on the first try. So there must be something wrong with the amd drivers plus that error with the amd reset bug I've setup a test system with a ryzen 7700x and a regular radeon 7600xt, non-pro gpu. Will let you know results. Shouldn't be an issue, it's same hardware and even the drivers work across them. Though they do have different bios on cards

@Andrew Thanks Andrew sounds good , let me know when it suits..

@nick-lloyd thanks, I did! Passthrough for AMD consumer Hardare iGPUs seams not to properly function… or, I should say, the Linux VMs are experiencing troubles correctly dealing with it: the devices are correctly passing down to the VM, but for some reason the ROCm kernel module is not capable of dealing with them. Could it be be ause it expected them to be on a specific bus? (They are assigned a different bus id) Could it be because it expected them to be under the same bus id? (They are scattered around different dedicated bus ids) Not sure, but the end result is the iGPU cannot be correctly initialized, albeit detected.

@gduperrey (unrelated to this fan issue) I loaded the new standard 8.2 testing kernel on my NUC11 and it seems to boot a little faster and also no longer complains about some APIC devices.

Do we have a list of GPUs that actually do support vGPU (not Passthrough) in 8.3? The documentation seems to be lagging behind there, a lot of references to the AMD mxgpu setups which have been deprecated.

Ah indeed it makes sense then