Better handle mismatched-RAM scenarios #106

New Issue

2020-10-12T17:48:07-04:00

JoshuaBoniface commented

2020-10-12 17:48:07 -04:00

(Migrated from git.bonifacelabs.ca)

If two nodes have mismatched RAM counts, during a "least used" memory migration (type mem), one can become easily overloaded. Properly handle this in the code.

If two nodes have mismatched RAM counts, during a "least used" memory migration (type `mem`), one can become easily overloaded. Properly handle this in the code.

JoshuaBoniface commented

2020-10-12 17:48:07 -04:00

(Migrated from git.bonifacelabs.ca)

changed milestone to %5

JoshuaBoniface commented

2020-10-12 17:48:31 -04:00

(Migrated from git.bonifacelabs.ca)

mentioned in issue #104

JoshuaBoniface commented

2020-10-18 14:20:16 -04:00

(Migrated from git.bonifacelabs.ca)

Implemented by modifying the mem migration to use the new "provisioned" memory count (#105) instead of the "allocated" memory count which only counted running VMs. This should make this more robust.

Given that we must always operate under the assumption that a VM must live somewhere, this fix still does not prevent selecting an already-overprovisioned node; this will be handled by warning when cluster n-1 of the largest node is violated.

Implemented by modifying the `mem` migration to use the new "provisioned" memory count (#105) instead of the "allocated" memory count which only counted running VMs. This should make this more robust. Given that we must always operate under the assumption that a VM must live *somewhere*, this fix still does not prevent selecting an already-overprovisioned node; this will be handled by warning when cluster n-1 of the largest node is violated.

JoshuaBoniface commented

2020-10-18 14:20:23 -04:00

(Migrated from git.bonifacelabs.ca)

closed

Sign in to join this conversation.