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 / i...@bit.nl _______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
