Note we already gave visibility on this project twice, with the last 2 XO blog post release and newsletter

Hi, It's already planned, but in XO 6, you already have better tasks displayed (you can even track an entire RPU there)

i also have slow speeds. Checked network connections works perfect. Checked disk performance is really good. But on migration speed is around 25mb/s.

[image: 1770534377194-e4d776aa-4e38-4d9c-933a-3a2d470535e7-c0bc0acf-ce0f-4922-a148-45c0e87a9a9d.png] ramp up and stabilization at 2.9Gb RAM need some 48H more data to confirm the behavior have changed XOPROXIES have also been upgraded to latests : [image: 1770534572970-eb5f373d-3f98-4d92-a0fb-c4114a4f59b8-29484b1f-e0b2-4cce-a7ac-e42ca080b12a.png] they didnt present any problem of RAM overusage even before and my 4 proxies are offloading the entire backup jobs from main XOA thats serves only for management

@dinhngtu Really appreciate the help finally got it working. In Debian 12 I was able to boot to it without issues even with 3GB (on both UEFI and BIO) but obviously not recommended for logs etc... Testing for Debian 13 now to see if there is something else affecting it and there is definitely weird issue with UEFI. BIOs boots up fine its the UEFI settings. This seem to affect the display as far as I can tell as I can ssh into the terminal without issue. I think part of the issue is to use only generic or genericcloud and avoid nocloud as its doesn't come with cloud-init install... They mention this on the site where we download it. Didn't quite understand until now...: azure: Optimized for the Microsoft Azure environment ec2: Optimized for the Amazon EC2 generic: Should run in any environment using cloud-init, for e.g. OpenStack, DigitalOcean and also on bare metal. genericcloud: Identical to generic but with a reduced set of hardware drivers in the kernel. If it does not work for your use case, you should use the generic images. nocloud: Does not run cloud-init and boots directly to a root prompt. Useful for local VM instantiation with tools like QEMU. (AVOID as it does not work with cloud init but it boot up so that was extremely deceiving...)

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

@florent Delta backup is also leaving old snapshots on some VMs. It should only have one (current) snapshot for the nightly backup. This is an issue on 1 of 100 VMs. XCP (Jan 2026 update) and XO (91c5d) are current. [image: 1770510564402-30de9803-0b8d-488d-b160-57c623f66e78-image.png]

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

Hi I tried again and failed with the same error message.. xe vm-export vm=c57a4225-3adb-b422-34ec-d2a23c6223c9 filename=/run/sr-mount/a7f6df31-412f-d5e9-4163-8af75b1df8ad/dlt-sin-mducv8.xva The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem. message: Unix.Unix_error(Unix.EIO, "read", "") Hum in this last reproduction, I the issue happened 3hours after I triggered the export... I have a feeling this is an hardware issue here... Anyone any other idea ? Advice where to look at? [EDIT] I have manage to export another vm without issue. Best. Matth.

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