Hi Stefan, How do you plan to implement it? I was thinking that instead of making the scheduler go through all the VMs running on a Host, the core could have support for this. It could add/remove the value of VM's AFFINITY_GROUP to the host on deployment/shutdown.
This way the host will have AFFINITY_GROUP="nameA, nameB, nameC" automatically populated, making the scheduling faster. Regards -- Carlos Martín, MSc Project Engineer OpenNebula - Flexible Enterprise Cloud Made Simple www.OpenNebula.org | cmar...@opennebula.org | @OpenNebula<http://twitter.com/opennebula><cmar...@opennebula.org> On Wed, Apr 9, 2014 at 5:03 PM, Paul Batchelor <pbatche...@blackberry.com>wrote: > We would definitely see a use for this as well. We have had multiple > instances of a supposedly redundant service start on the same hypervisor. > An "anti-affinity" attribute in the template sounds like the perfect fix. > > -----Original Message----- > From: users-boun...@lists.opennebula.org [mailto: > users-boun...@lists.opennebula.org] On Behalf Of Stefan Kooman > Sent: 09 April 2014 14:41 > To: users@lists.opennebula.org > Subject: [one-users] (anti-) affinity groups support for scheduler > > 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 > --------------------------------------------------------------------- > BlackBerry UK Limited > Registered in England and Wales. Registered No. 04022422, with registered > office at 200 Bath Road, Slough, Berkshire, SL1 3XE, United Kingdom > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > > _______________________________________________ > Users mailing list > Users@lists.opennebula.org > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >
_______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
