Hello,<br><br>We have one question/suggestion regarding the approach of
the scheduler face to an result of impossibility on resource allocation
process.<br><br>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.<br>
<br>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 reasons).<br>
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.<br>
<br>This approach also can be considered one of the reasons that
contributed for other similar issues pointed on mailing list, as for
example, on <a href="http://lists.opennebula.org/htdig.cgi/users-opennebula.org/2011-March/004511.html" target="_blank">[one-users] VM creation stuck in "pending" state</a> <a href="http://lists.opennebula.org/htdig.cgi/users-opennebula.org/2011-April/004603.html" target="_blank">thread</a>,
where the same problems could be solved if the OpenNebula would changed
the VM state to fail and logged the appropriate output.<br>
<br>We believe that there are at least two main possibilities to circumvent this problem:<br>1) Change the VM state to "fail" when an impossible result is achieved.<br>2) Add a new state for the virtual machine to indicate when it achieve an impossible result (for example, an impossible state).<br>
<br>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.<br><br>Thank you in advance.<br>
Vinicius Vielmo Cogo