[pve-devel] features ideas for 3.0 roadmap

Alexandre DERUMIER aderumier at odiso.com
Wed Mar 13 04:38:59 CET 2013


>>Auto-migrate VMs to do resource balancing. I've heard resistance to this with the argument that the migration would cause an even higher load but I think it is still a valid option. If the high load ends up being >>a long term situation it may be beneficial to migrate and cause a high load for a brief period of time. Also if things are kept balanced early enough the problem may be prevented all together. There could be >>tuning options such as when to balance and delay to prevent short periods of high load from causing a migration. This would also be useful for rebalancing the cluster if new hosts are added or if the above option >>is implemented and a host is re-added to the cluster. 

I think we have discuss about this some month ago. It's auto workload balancing.
We can have easily stats of the whole cluster and we have stats history in rrd files . But we don't have a "master" to manage the balancing, so each node need to manage itself.

It should work like this:

for each vm, in a proxmox daemon

- if host total cpu > 80% since X minutes
- find the vms which use the more cpu ? since X minutes.
  choose the vm with the lowest memory (to speedup migration)
- find a target host with the lowest cpu (since X minutes). (We need to have ratio for hosts with differents cpu power)
  and try to have <80% target host cpu after migration.
- migrate the vm to the host


Something like that.


----- Mail original ----- 

De: "James Devine" <fxmulder at gmail.com> 
À: pve-devel at pve.proxmox.com 
Envoyé: Mardi 12 Mars 2013 20:21:02 
Objet: Re: [pve-devel] features ideas for 3.0 roadmap 


Perhaps some type of update mode which would pull a host server out of the cluster and migrate machines off of it. 


Auto-migrate VMs to do resource balancing. I've heard resistance to this with the argument that the migration would cause an even higher load but I think it is still a valid option. If the high load ends up being a long term situation it may be beneficial to migrate and cause a high load for a brief period of time. Also if things are kept balanced early enough the problem may be prevented all together. There could be tuning options such as when to balance and delay to prevent short periods of high load from causing a migration. This would also be useful for rebalancing the cluster if new hosts are added or if the above option is implemented and a host is re-added to the cluster. 



On Wed, Mar 6, 2013 at 3:18 AM, James A. Coyle < james.coyle at jamescoyle.net > wrote: 


I would +1 the backups, it's the one part of Proxmox which drives me mad! I tend to SSH in and rename them manually for major backups. 

I'd like to see some small UI changes: 
- Add a search box under Storage > Content so that we can start to type and the content is filtered. 
- On Create Backup Job - allow a name or comment to describe the backup. 
- As discussed - backups are tricky to manage on VMID alone. 

Overall though, it's a great product! I use 2 x 3 node clusters and use about a 50:50 split between QEMU and OpenVZ. Thanks for your efforts! 


James Coyle 

M: +44 (0) 7809 895 392 
E: james.coyle at jamescoyle.net 
Skype: jac2703 
Gtalk: jac2703 at gmail.com 
www: www.jamescoyle.net 



----- Original Message ----- 
From: "FinnTux" < finntux at gmail.com > 
To: "Alexandre DERUMIER" < aderumier at odiso.com > 
Cc: pve-devel at pve.proxmox.com 
Sent: Wednesday, 6 March, 2013 7:52:56 AM 
Subject: Re: [pve-devel] features ideas for 3.0 roadmap 

> - finish vm/templates copy/clone 
> - storage migration 
> - storage migration + live migration for local disks 
> - add hyperv cpu features for windows > 2008 
> - add spice console support (openstack has added spice-html5 console, so it should work now) 
> - add support for qemu guest agent 
> - finish cleanup of hotplug/unplug with cooperation of guest agent 
> - add dynamic nic vlan change 
> - add dynamic nic rate limit change 
> 
> What do you think about this ? Other ideas are welcome :) 

Sounds great. 

- Add vCPU, vRAM and bridges (networks) to pools 
- Improve backup handling. Like mentioned before on the forums backup 
name based solely on VMID is confusing. Needs somekind of notes 
included in the backup 
_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 
_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 




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


More information about the pve-devel mailing list