[one-users] (anti-) affinity groups support for scheduler

[Stefan Kooman]

Hi List,

I'm trying to accomplish the following. I want to have the "match making
scheduler" schedule two or more vm's on the same hypervisor (webserver and
database server, to reduce network traffic between HOSTS. I know
there is a way of doing this with "CURRENT_VMS". CURRENT_VMS only seems
to accept "VM ID's" and not the name of a VM. The drawback of having an
ID hardcoded in a template is that if the VM gets recreated from a
template somewhere in the future (because of some changes in the template)
the REQUIREMENT will never be fullfilled and the vm never deployed.
One way to get around this would be to create so called "(anti-)affinity
groups. So in a VM TEMPLATE you would define "AFFINITY_GROUP=$AFFINITY_GROUP"
and the scheduler would check if a VM with that particular
AFFINITY_GROUP is running on a hypervisor. If so, it would place this VM
on the same hypervisor. If not it deploys the VM on a hypervisor that
has highest priority after filtering. You might wonder why I would not
just select a HOST for these particular VM's. With HOST=$HOST I would not be able to
bring those VM's up on a different hypervisor in case of a disaster
without modifying a template or manually forcing a deploy. Not something
you've got time for while battling a (major) outage.

You can think of an AFFINITY_GROUP as a selective "black hole": Sucking up VM's it
has affinity with.

What do you think of this? Does it makes sense to you? Would you have use
for this funtionality?

Gr. Stefan


-- 
| BIT BV  http://www.bit.nl/        Kamer van Koophandel 09090351
| GPG: 0xD14839C6                   +31 318 648 688 / info at bit.nl