Edit: For anyone with this issue, stopping and starting the Openmetrics plugin after saving the password in XO fixed it. I keep getting the {"error":"Query authentication does not match server setting"} problem, is there something I'm missing? I run XO proxied through Nginx with HTTPS, is there some additional config required to get it working? I have set the key with openssl rand -hex 32 and have verified that is saved correctly in the plugin, and that I am using the same key for curl. I am able to obtain the /health endpoint as expected, I just cannot obtain the full metrics, only returns that error. Command: curl --insecure -H "Authorization: Bearer mytoken" https://xo.mydomain.local/openmetrics/metrics XO commit: 91c5d I should note that running the command inside my Docker container returns only the error, including the health endpoint. Do I need to expose 9004?

Also.. Thank you for taking a look at it and solving it so quickly, @florent It is a quite nice interaction when reporting bugs that they are looked at and triaged. Not saying everything needs to be a priority 1. But I do appreciate being close to the process. And if I can help make things better by reporting bugs, in a hopefully constructive way. Then I'll continue to contribute my way.

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

@dinhngtu tried on a Windows Server 2025 VM, UEFI BIOS working well, no reboot needed

It's not a problem with XO backups

@florent I tried to upload it with the "Upload button" and got this error" [2026-02-05T15_03_26.704Z - backup NG.json](Invalid file type. Allowed types are: .png, .jpg, .bmp, .txt, .diff, .patch, .jpeg) " 2026-02-05T15_03_26.704Z - backup NG_json.txt

@markxc could you tell us what endpoint you used ?

@nvs Hi there, we had a similar issue with on our 5900x boxes. We have about a twenty of these and they have been generally greats hosts for xcp loads. However, one of them was constantly rebooting. While testing the ram the temp jumped to 90/90. They are running in 1U boxes so I expect heat but this seemed silly. We ramped the fans to max but this did not help. We then used bios to drop down various cpu boost profiles and gadgets to lower the heat and re-applied paste to cpu.. so far so good.

I know this is old but I had a similar issue. In the end I told dracut NOT to reassemble my raid array which allowed the system to boot perfectly after. I have no idea why it tries to assemble the same array two but on the second seems to be important

I am running NVIDIA P40s on a DELL R720/R730 and a NVIDIA A2000 12GB on a DELL Optiplex 9010 in my playlab. Getting the GPUs to be accessible for VMs was quite easy: shutdown the XCP-ng host, install the GPUs, start the host again, activate the GPU in the advanced settings of the host in the PCI Devices section (“Passthrough enabled”). The host will restart at this point after displaying a warning. That's it – the GPU can now be assigned to a VM in the VMs advanced settings. I do use the GPUs for AI workloads under Debian though, so your use case might vary.

@Pilow tags can work and the path to them is much more succinct. Thanks!

An intake is created for review with XO team. Thanks for the feedback @puffymob !

@olivierlambert okay, understood. it is small minor cosmetic problem as of now. need to get you an access to our internal developped app, to show you the potential of sub-xoas ^^' almost out of alpha phase

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

Something to document @thomas-dkmt

Hi! ISO-SR over HBA/FC would be very nice, especially when migration form a SAN vmware-System to XCP-NG. One other thing is altering. Errors like "VM cannot be migrated" or similar should not be silent but should be very visible / even mailed to the admin. Another thing (could be cosmetical though) in my opinion is that a failed Rolling upgrade remains visible with a half fulled progress bar in the task-view. this is confusing.

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

@henri9813 Ahh alright, I understand now! Thanks for clarifying.