[pve-devel] adding a vm workload scheduler feature

[Alexandre DERUMIER]

>>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.) 

I think we could find a way to find compatible host.
Another way could be to start the migration, and with the new cpu enforce feature in proxmox 4, the vm migration will stop directly if target host is not compatible and we can try another host or another vm.
But this is solvable. 

>>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? 

This occur only if you restrict a backup job for specific node + specific vms.
(By default, you can backup vms, and it's work if they are on any nodes)

For this case, I think we can exclude this vms from auto-migration.


----- Mail original -----
De: "Martin Waschbüsch" <service at waschbuesch.it>
À: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Mardi 17 Novembre 2015 14:56:39
Objet: Re: [pve-devel] adding a vm workload scheduler feature

> 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). 

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? 

Martin 
_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel