[pve-devel] adding a vm workload scheduler feature
aderumier at odiso.com
Tue Nov 17 15:33:54 CET 2015
>>Also migrations could be blocked when a service is doing stuff like a
block job too (like mirroring). Maybe just look if the vm have a lock should be enough.
----- Mail original -----
De: "Thomas Lamprecht" <t.lamprecht at proxmox.com>
À: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Mardi 17 Novembre 2015 15:26:15
Objet: Re: [pve-devel] adding a vm workload scheduler feature
Am 17.11.2015 um 14:56 schrieb Martin Waschbüsch:
>> Am 17.11.2015 um 14:20 schrieb Alexandre DERUMIER <aderumier at odiso.com>:
>>>> Unless all cluster nodes have identical hardware, how do you determine if a given node is a suitable target for a vm?
>> I think we could add a manual "host cpu weight" option, because it's difficult to compare cpus performance. (frequencies/nb cores/intel|amd).
Manual weighting VMs and (maybe also) Nodes would general be an good
option (which Dietmar proposed once to me as an idea) shift the control
more to the admin, which is normally better able to determine how the
load should be spread, as there are also different use cases.
> Good point. Though, I was more thinking about situations where the cpu-type is not set to default (kvm64, I think?) but to something like 'IvyBridge' or Opteron_G5. (The primary use I had for using non-default cpu types was to expose features such as AES-NI to a vm.)
> Another thing that just occurred to me: Backup schedules and settings are not necessarily the same for each node, which means auto-migration could lead to double, or (worse!) no backup for a vm that was moved around?
> Dunno if these are just corner cases?
Configuration like done in the HA-Manager could be used, so that certain
nodes are in a group and the VM is bound to this group, we could in fact
use the group API from the HA-Manager.
Also migrations could be blocked when a service is doing stuff like a
pve-devel mailing list
pve-devel at pve.proxmox.com
More information about the pve-devel