<div dir="ltr">Hi Stefan,<div><br></div><div>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.<div>
<br></div><div>This way the host will have AFFINITY_GROUP="nameA, nameB, nameC" automatically populated, making the scheduling faster.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards<br clear="all">
<div><div dir="ltr">--<br><div>Carlos Martín, MSc<br>Project Engineer</div><div>OpenNebula - Flexible Enterprise Cloud Made Simple<br><div><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:cmartin@opennebula.org" target="_blank">cmartin@opennebula.org</a> | <a href="http://twitter.com/opennebula" target="_blank">@OpenNebula</a></span><span style="border-collapse:collapse;color:rgb(136,136,136);font-family:arial,sans-serif;font-size:13px"><a href="mailto:cmartin@opennebula.org" style="color:rgb(42,93,176)" target="_blank"></a></span></div>
</div></div></div>
<br><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 5:03 PM, Paul Batchelor <span dir="ltr"><<a href="mailto:pbatchelor@blackberry.com" target="_blank">pbatchelor@blackberry.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<div><div class="h5"><br>
-----Original Message-----<br>
From: <a href="mailto:users-bounces@lists.opennebula.org">users-bounces@lists.opennebula.org</a> [mailto:<a href="mailto:users-bounces@lists.opennebula.org">users-bounces@lists.opennebula.org</a>] On Behalf Of Stefan Kooman<br>
Sent: 09 April 2014 14:41<br>
To: <a href="mailto:users@lists.opennebula.org">users@lists.opennebula.org</a><br>
Subject: [one-users] (anti-) affinity groups support for scheduler<br>
<br>
Hi List,<br>
<br>
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.<br>
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"<br>
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.<br>
<br>
You can think of an AFFINITY_GROUP as a selective "black hole": Sucking up VM's it has affinity with.<br>
<br>
What do you think of this? Does it makes sense to you? Would you have use for this funtionality?<br>
<br>
Gr. Stefan<br>
<br>
<br>
--<br>
| BIT BV <a href="http://www.bit.nl/" target="_blank">http://www.bit.nl/</a> Kamer van Koophandel 09090351<br>
| GPG: 0xD14839C6 <a href="tel:%2B31%20318%20648%20688" value="+31318648688">+31 318 648 688</a> / <a href="mailto:info@bit.nl">info@bit.nl</a><br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
</div></div>---------------------------------------------------------------------<br>
BlackBerry UK Limited<br>
Registered in England and Wales. Registered No. 04022422, with registered office at 200 Bath Road, Slough, Berkshire, SL1 3XE, United Kingdom<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
</div></div></blockquote></div><br></div></div>