@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

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:

@samuelolavo Yes, I do use NUT, but I don’t want to install any additional packet on XCP-ng. The way I found leverage the SSH authorized keys restrictions, and so you only need to change one file. Thanks for the link anyway

Does it work as you wanted now? If yes, probably something we can put in our official doc! Ping @thomas-dkmt

Hi, In those cases, my first bet is a memtest to check the RAM and CPU.

hardware_report_2025-12-12_17-20-47.txt lspci.txt mlx.txt pci.txt Diagnostic logs

@hoehnp we're aiming at sharing a very first public version before end of year, but don't hope for it to be anything complete or stable

@Joe_dev I have a MF unit with similar igpu. I was not able to get it working under any virtualization platform. There is something about amd igpu that makes passing it hard. I believe some have had it working under proxmox with custom kernel and video bios. I never bothered trying all that out so i just gave up on the unit.

Maybe that's my issue ? Investing this part # journalctl -k | grep -i nvidia [image: aaed86b6-1384-434e-ac5d-bca510405f33-image.png]

@ph7 huh, that is weird. I'll try to troubleshoot more over the weekend. Thanks for pointing it out. @olivierlambert said in Upgraded RAM, It get's detected but not used. Any ideas?: I would first upgrade the BIOS of the motherboard. Consumer grade hardware is pretty buggy in general when you are using "advanced" features, sadly. That's the first thing i tried, no luck unfortunately

Hi, Are you sure your GPU is correctly fed via the power connector?

What GPU do you have? I thought I read something about NVidia's newer stuff having vGPU without the expensive licensing and hardware. But it's possible I'm just conflating that with the increase in concurrent NVENC encodes. On the bright side, you can always get a cheap GPU and just do passthrough with it. I do that for my Jellyfin server with a 2060, it's very easy to do in XCP-ng now and works super reliably.

@andSmv Thanks for taking a look at it. It's not really needed for a modern platform.

Reboot seems to have fixed it and made it visible. Leaving this post up so others have all the commands in one place. [14:15 cloud ~]# ethtool -i eth5 driver: i40e version: 2.26.8 firmware-version: 9.50 0x8000f255 23.0.8 expansion-rom-version: bus-info: 0000:5e:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes

@olivierlambert thank you very much, you are helpful

@gduperrey The thing is, the i40e driver works fine for me with the regular kernel. I was hoping to try kernel-alt to see whether it would resolve my erroneous CPU thermal shutdown issues (to narrow down whether it's a kernel issue or not), but then I ran into the driver issue. I can try that alt driver, though, and see if it works with kernel-alt for me.

@chicagomed there's no need to be editing grub for pass thru, I would use the standard commands and avoid corrupting grub in the process.