Hi Simon,<div><br></div><div>I think the scheduler trigger signal can be interesting to manually force a scheduling action when the configured SCHED_INTERVAL is too high and you need a VM deployed immediately. However, adding a hook to deploy each VM just after its creation can cause unneeded overhead. Let me explain:</div>
<div><br></div><div>If you have 10 pending VMs, the current code will retrieve the list of VMs, Hosts and ACL rules once, and perform the matching and deployments. If the scheduling is triggered 10 times, the Host & ACL list will have to be retrieved 10 times. There is also the problem of the capacity: if two separate scheduling actions are triggered at the same time, both may send a total of 2 VMs to a host that has only capacity for 1.</div>
<div><br></div><div>Anyway, please open a feature request at our dev. portal and we will consider it for next releases.</div><div><br></div><div><br></div><div>About the host filtering using this pre & post scripts, if I understood correctly, that functionality is already implemented as REQUIREMENTS and RANK:</div>
<div><br></div><div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span dir="ltr">1- The PRE_SCHED script receives in STDIN the full lists of hosts that<br></span><span dir="ltr">are online, filter out any unwanted hosts, and output a new list in<br></span><span dir="ltr">STDOUT.</span></blockquote>
<div><br></div><div>To filter the unwanted Hosts, you can use the REQUIREMENTS attribute in your templates [1].</div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span dir="ltr">2- The scheduler would do normal scheduling policy from the list<br></span><span dir="ltr">received from PRE_SCHED<br></span><span dir="ltr">3- The POST_SCHED receives in STDIN the list of hosts sorted in<br>
</span><span dir="ltr">descending order by the scheduler, filter out any unwanted hosts, and<br></span><span dir="ltr">output the host to be deployed on in STDOUT.</span></blockquote><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span dir="ltr">4- The scheduler calls one.vm.deploy with the host received from POST_SCHED.</span></blockquote></div><div><br></div><div>You can overwrite the default scheduling policy [2] for each VM using the RANK attribute.</div>
<div><br></div><div>Regards</div><div><br></div><div>[1] <a href="http://opennebula.org/documentation:rel3.4:template#placement_section">http://opennebula.org/documentation:rel3.4:template#placement_section</a></div><div>
[2] <a href="http://opennebula.org/documentation:rel3.4:schg">http://opennebula.org/documentation:rel3.4:schg</a><br clear="all">--<br>Carlos Martín, MSc<br>Project Engineer<br>OpenNebula - The Open-source Solution for Data Center Virtualization<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>
<br>
<br><br><div class="gmail_quote">2012/4/24 Simon Boulet <span dir="ltr"><<a href="mailto:simon@nostalgeek.com" target="_blank">simon@nostalgeek.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<div class="im"><br>
On Tue, Apr 24, 2012 at 10:05 AM, Carlos Martín Sánchez<br>
<<a href="mailto:cmartin@opennebula.org">cmartin@opennebula.org</a>> wrote:<br>
<br>
><br>
> As I said, the scheduler is a separate executable from oned (the core). It<br>
> basically queries periodically oned for the list of pending VMs, the<br>
> available hosts, and then for each VM filters the Hosts that match the VM<br>
> requirements: the user has ACL permissions to have his VMs deployed in the<br>
> host, the CPU and MEMORY constraints are met, REQUIREMENTS fit, etc. This<br>
> list of Hosts is then sorted using the defined RANK. Finally, the scheduler<br>
> performs the one.vm.deploy calls<br>
><br>
<br>
</div>Is there any plans to make the scheduler more customizable ie. have a<br>
way for users to hook into the scheduling process and influence the VM<br>
placement? OpenNebula is very flexible and easy to hack thanks to the<br>
different modules implementation. However I have yet to find a way to<br>
easily customize the scheduler.<br>
<br>
Here are some of the few things I have in mind:<br>
<br>
- Implement scheduler wake up for immediate placement / trigger the<br>
scheduler upon VM creation. I was thinking of adding a SIGHUP signal<br>
handler into the scheduler, and then adding the following HOOK into<br>
oned.conf:<br>
<br>
VM_HOOK = [<br>
name = "trigger_scheduler",<br>
on = "CREATE",<br>
command = "/usr/bin/killall -HUP mm_sched",<br>
arguments = "$VMID" ]<br>
<br>
- Implement PRE_SCHED and POST_SCHED environment variables (or<br>
something alike). The idea would be to influence the lists of<br>
available hosts. For example:<br>
<br>
1- The PRE_SCHED script receives in STDIN the full lists of hosts that<br>
are online, filter out any unwanted hosts, and output a new list in<br>
STDOUT.<br>
2- The scheduler would do normal scheduling policy from the list<br>
received from PRE_SCHED<br>
3- The POST_SCHED receives in STDIN the list of hosts sorted in<br>
descending order by the scheduler, filter out any unwanted hosts, and<br>
output the host to be deployed on in STDOUT.<br>
4- The scheduler calls one.vm.deploy with the host received from POST_SCHED.<br>
<br>
What are your thoughts?<br>
<span class="HOEnZb"><font color="#888888"><br>
Simon<br>
</font></span></blockquote></div><br></div>