@Pilow Thanks for the heads-up, you should be able to add back concurrency as it was before and get similar performance to before the refactoring.

Hi, thanks for the heads-up, we will see about doing some comparison with the backups refactoring on our dev environment to check if we lost some speed and try to fix it if so. Very happy to hear that the issue is mostly resolved.

We will patch this ASAP.

@MajorP93 Perfect, if the issue is confirmed resolved, we aim to release a patch early next week so no hurry

@pilow @majorp93

Hi again, we have found the most likely source of the issue and fixed it.

Could you checkout the fix_vhd_directory_merge branch and test that the backups take a reasonable length of time again ?

Thanks.

@MajorP93

Hi, yes this has clearly been a blind spot of our testing when we released the backups refactoring and our first step in fixing this issue is to add benchmarks to our testing suite to be sure this can't happen again.

@Pilow
Hi, thanks for the report we will look into this and get back to you ASAP.

@wralb Perfect, thanks for getting back to us.

So the issue only occurs when a delta backup tries to backup a disk that has had an increase in size, so you can either stay on the branch or go back to master if you are not planning on enlarging any disks in the near future.

Anyways, the fix should be available in the next patch or release.

Thanks.

@wmazren Hi, thanks for the report, we are looking into this.

Could you share you config.toml file ? It's most likely located in ~/.config/xo-server/.

Thanks.

Hi @wralb, thank you for the report.

We have identified the source of the issue and implemented a potential fix. It's currently on the branch fix_merge_out_of_range.

Could you check it out, retry the backup and confirm that the issue issue is fixed ?

Thanks.

Thanks for the heads-up and thanks for the help !

@acebmxer

Thanks a lot, the first issue was resolved but your log indicates a separate issue.
We think we resolved it on the "debug_backups" branch, could you test it again ?

Anyways, if this fixes the backup issue, a fix should be available tomorrow Paris time on master.
In the mean time you can revert to the commit a3139 as explained in the first post.

Thanks again for your help.

@acebmxer

Thanks a lot for the logs, we've been able to identify a possible cause for this issue, could you pull the "debug_backups" branch and try running the backups again ?

Hash is cb85e44ae

@manilx @acebmxer @marcoi

Hi, thanks for the reports, we were able to fix an issue with the health check but we weren't able to reproduce the backup issue.

Could you checkout the "debug_backups" branch, try to run the backups again and send the logs here ?

There should be no need to restart or rebuild.

Thanks !

@manilx What storage type/backup repository are you using ?

@manilx said in Master, commit a3139 failing backups:

Can't init vhd directory without using alia

Hi, we are working on this issue and will get back to you ASAP.

@MajorP93 Hi,

In the demo dashboard it is intended yes but these percentages are obtained by dividing the free memory by total memory so changing the dashboard to show GB/GiB should be quite straight forward.

I've forgot to add to the initial post that there is a advanced dot md file that describes all the available metrics located in "xen-orchestra/docs/docs".

Thanks.

Hey everyone,

I'm creating this topic to showcase what's possible with the new Openmetrics data exports in Xen Orchestra using Prometheus and Grafana to build dashboards and monitoring tools.

GIF

Here is the json used for this demo dashboard: JSON

All the available metrics are described in https://docs.xen-orchestra.com/advanced

Here are a few other examples and JSONs from our community:

Xoa Cluster Overview
Xoa Host Overview
Xoa SR Overview
Xoa Vm Overview

Don't hesitate to showcase your dashboards here, share your config files or suggest new metrics !