[one-ecosystem] help for source code

Carlos Martín Sánchez cmartin at opennebula.org
Fri Apr 27 02:51:08 PDT 2012


Hi Simon,

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:

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.

Anyway, please open a feature request at our dev. portal and we will
consider it for next releases.


About the host filtering using this pre & post scripts, if I understood
correctly, that functionality is already implemented as REQUIREMENTS and
RANK:

1- The PRE_SCHED script receives in STDIN the full lists of hosts that
> are online, filter out any unwanted hosts, and output a new list in
> STDOUT.


To filter the unwanted Hosts, you can use the REQUIREMENTS attribute in
your templates [1].


> 2- The scheduler would do normal scheduling policy from the list
> received from PRE_SCHED
> 3- The POST_SCHED receives in STDIN the list of hosts sorted in
> descending order by the scheduler, filter out any unwanted hosts, and
> output  the host to be deployed on in STDOUT.

4- The scheduler calls one.vm.deploy with the host received from POST_SCHED.


You can overwrite the default scheduling policy [2] for each VM using the
RANK attribute.

Regards

[1] http://opennebula.org/documentation:rel3.4:template#placement_section
[2] http://opennebula.org/documentation:rel3.4:schg
--
Carlos Martín, MSc
Project Engineer
OpenNebula - The Open-source Solution for Data Center Virtualization
www.OpenNebula.org | cmartin at opennebula.org |
@OpenNebula<http://twitter.com/opennebula><cmartin at opennebula.org>



2012/4/24 Simon Boulet <simon at nostalgeek.com>

> Hi,
>
> On Tue, Apr 24, 2012 at 10:05 AM, Carlos Martín Sánchez
> <cmartin at opennebula.org> wrote:
>
> >
> > As I said, the scheduler is a separate executable from oned (the core).
> It
> > basically queries periodically oned for the list of pending VMs, the
> > available hosts, and then for each VM filters the Hosts that match the VM
> > requirements: the user has ACL permissions to have his VMs deployed in
> the
> > host, the CPU and MEMORY constraints are met, REQUIREMENTS fit, etc. This
> > list of Hosts is then sorted using the defined RANK. Finally, the
> scheduler
> > performs the one.vm.deploy calls
> >
>
> Is there any plans to make the scheduler more customizable ie. have a
> way for users to hook into the scheduling process and influence the VM
> placement? OpenNebula is very flexible and easy to hack thanks to the
> different modules implementation. However I have yet to find a way to
> easily customize the scheduler.
>
> Here are some of the few things I have in mind:
>
> - Implement scheduler wake up for immediate placement / trigger the
> scheduler upon VM creation. I was thinking of adding a SIGHUP signal
> handler into the scheduler, and then adding the following HOOK into
> oned.conf:
>
> VM_HOOK = [
>   name      = "trigger_scheduler",
>   on        = "CREATE",
>   command   = "/usr/bin/killall -HUP mm_sched",
>   arguments = "$VMID" ]
>
> - Implement PRE_SCHED and POST_SCHED environment variables (or
> something alike). The idea would be to influence the lists of
> available hosts. For example:
>
> 1- The PRE_SCHED script receives in STDIN the full lists of hosts that
> are online, filter out any unwanted hosts, and output a new list in
> STDOUT.
> 2- The scheduler would do normal scheduling policy from the list
> received from PRE_SCHED
> 3- The POST_SCHED receives in STDIN the list of hosts sorted in
> descending order by the scheduler, filter out any unwanted hosts, and
> output  the host to be deployed on in STDOUT.
> 4- The scheduler calls one.vm.deploy with the host received from
> POST_SCHED.
>
> What are your thoughts?
>
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/ecosystem-opennebula.org/attachments/20120427/54f6d303/attachment-0001.htm>


More information about the Ecosystem mailing list