@planedrop Not opposed to cloud of course, but it's a network with no internet!

@Pilow Time for a drink, I think.

Well, scratch the help, I have fixed it.

Bad VM:

xe vm-param-list uuid={uuid} | grep "other-config"

other-config (MRW): xo:backup:schedule: one-time; xo:backup:vm: {uuid}; xo:backup:datetime: 20260214T18:13:03Z; xo:backup:job: 97665b6d-1aff-43ba-8afb-11c7455c16ff; xo:backup:sr: {uuid}; auto_poweron: true; base_template_name: Debian Buster 10;

Clean VM:

other-config (MRW): auto_poweron: true; base_template_name: Debian Buster 10; [...]

Stale references to my old backup job causing the VM to disassociate with the VDI chain. Removing the extra config resolved it. Simple when you know where to look.

xe vm-param-remove uuid={uuid} param-name=other-config param-key=xo:backup:job
xe vm-param-remove uuid={uuid}  param-name=other-config param-key=xo:backup:sr
xe vm-param-remove uuid={uuid}  param-name=other-config param-key=xo:backup:vm
xe vm-param-remove uuid={uuid}  param-name=other-config param-key=xo:backup:schedule
xe vm-param-remove uuid={uuid}  param-name=other-config param-key=xo:backup:datetime

VMs now snapshot clean.

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?

@julien-f Thank you and thank you for the quick resolution, you guys rock.

@olivierlambert Yes but didn't see any changes for backup/logs which is where the issue seemed to arise from. I pull the status from each log entry not the job info itself.

@julien-f awesome, thanks!

Testing the agent out on Arch Linux (mainly due to the spotty 'support' in the AUR/generally) and it is working fine - better than what I had before (which did not report VM info properly). I've set it up as a systemd service to replace the previous one I had, also working as expected.

This would be fun to contribute towards.

For anyone who comes across this, you can just add an exception for your management page and shift will work on the console.

Settings > Privacy & Security > Enhanced Tracking Protection > Manage Exceptions > Add the site url e.g. https://xo.fqdn.com.