[one-users] Scheduler approach on impossible results

Vinícius Vielmo Cogo vielmo at inf.ufsm.br
Wed Sep 14 09:53:27 PDT 2011


We have one question/suggestion regarding the approach of the scheduler face
to an result of impossibility on resource allocation process.

As the OpenNebula default matchmaking scheduler is an immediate lease
scheduler, it should always return the allocated resources or an error due
to it's impossibility. But, when the scheduler receives an expression which
turns to an impossible result, the VM remains in pending state indefinitely,
which is an approach related with best-effort schedulers.

Specifically in our case, we want to deploy one Virtual Machine on each host
of our cloud (for security reasons) and we don't want to obtain all
information about the entire HostPool in each VM creation (scalability
The problem arises when we achieve the entire set of hosts inside of our
requirements (e.g using "HOSTNAME != \"some-host\"" & "HOSTNAME !=
\"another-host\"", etc), which means that don't exist other host to allocate
the Virtual Machine.

This approach also can be considered one of the reasons that contributed for
other similar issues pointed on mailing list, as for example, on [one-users]
VM creation stuck in "pending"
where the same problems could be solved if the OpenNebula would changed the
VM state to fail and logged the appropriate output.

We believe that there are at least two main possibilities to circumvent this
1) Change the VM state to "fail" when an impossible result is achieved.
2) Add a new state for the virtual machine to indicate when it achieve an
impossible result (for example, an impossible state).

We would like to know your opinion about this approach, if it's possible to
modify the OpenNebula scheduler in those terms and/or if you could indicate
other ways to avoid this pending issue.

Thank you in advance.
Vinicius Vielmo Cogo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20110914/5f21726c/attachment-0002.htm>

More information about the Users mailing list