It appears that the value of healthCheckTimeout from the config file is indeed not taken into account.
We've created a card on our side to fix this issue, and we'll soon plan it with the team.

If you can't wait for the fix to be released, you can modify the default value of healthCheckTimeout in the code in files @xen-orchestra/backups/_runners/VmsRemote.mjs and @xen-orchestra/backups/_runners/VmsXapi.mjs, then restart XO server, and this should fix it until next update.

As Mathieu answered in this topic, the bug has been reproduced on our side but isn't trivial to fix. We'll discuss with the team to schedule this task, and we'll keep you informed when it's fixed.

@olivierlambert I'll take a look

Hi @KPS,

Thank you for reporting this behavior. We haven't been able to reproduce the bug yet, but we'll look into it with @MathieuRA. We're a bit busy at the moment, so we probably won't be able to fix this issue before the November release.

There is indeed a bug in the perf-alert plugin with removable storages.

This will be fixed in an upcoming XO version by removing these SRs from the perf-alert monitoring.

Hi @nicols ,

As Dan said, we are indeed investigation this issue, and we will try to provide a fix during the next weeks. We will keep you informed.

Regards

@jshiells this value is the average load across all cores on a host. To be more precise, it is a weighted average of the last 30min of this value. Migrations are triggered if this average exceeds 85% of the critical threshold defined in the plugin configuration, which is roughly 64% if you defined the critical threshold at 75%.

Other circumstances can trigger migrations :

• if a host free memory is too close to critical threshold
• anti-affinity rules
• if you defined a performance plan behavior other than default (i.e. Preventive or vCPU balancing), migrations can be triggered even when at low memory and CPU usage

@olivierlambert I'm not familiar with the perf-alert plugin but it seems that @KPS is right, see : https://github.com/vatesfr/xen-orchestra/blob/7882debe7adc7d4945da7e27d9825b1ffcf78ca9/packages/xo-server-perf-alert/src/index.js#L31

@manilx Ok, then I'll have to investigate on this to see if the density plan is still working properly for us, or if there are other things that may be preventing it from working for you.

@manilx said in load balance, density. Doesnt seem to be working:

@Tristis-Oris They don't. Nothing happens.

Edit: Also "In this mode, you can choose to shutdown unused (and compatible) hosts" don't see where to set this.

You actually don't need to set this, it is not configurable. Host are shut down when all their VMs have been migrated.
Thank you for pointing that out, we need to update the doc on this.

Hi,

There are several things that can prevent the density plan from regrouping your VMs to only one host :

• if your hosts can't be restarted
• if some of the VMs on your host don't support pool migration
• if your host doesn't have enough memory or CPU to correctly handle all your VMs
• if the migration would go against anti-affinity rules (but according to your screenshot you haven't defined anti-affinity tags, so this can't happen)

Though, I just noticed that there is probably an issue with the CPU and memory threshold values, which would lead to trying to do migrations even if they are not possible in terms of memory or CPU. I will investigate on that, and test that the density plan is still working correctly for us.

You are right, the documentation isn't up to date, this isn't configurable at the moment.

We are currently working on the load balancer, so this may come in future versions.