Feature #846
Scheduler approach on impossible results
Status: | Closed | Start date: | 09/29/2011 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | Carlos Martín | % Done: | 0% | |
Category: | Scheduler | |||
Target version: | Release 4.0 | |||
Resolution: | fixed | Pull request: |
Description
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 reasons).
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" state thread, 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 problem:
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).
Associated revisions
Feature #846: Minor changes in log messages
Feature #846: Add methods to update the VM template from the sched and log messages
Feature #846: Skip the scheduling if there aren't any pending VMs, and omit empty logs
Feature #846: Minor fix for req. syntax errors
feature #846: Add more message types. Template is loaded in the VirtualMachineXML object. OpenNebula API calls are always made through VirtualMachinePoolXML.
History
#1 Updated by Tino Vázquez almost 10 years ago
This feature was suggested by VinÃcius Vielmo Cogo vielmo@inf.ufsm.b
#2 Updated by Ruben S. Montero almost 10 years ago
- Target version deleted (
Release 3.4)
#3 Updated by Ruben S. Montero over 8 years ago
- Target version set to Release 4.0
#4 Updated by Carlos Martín over 8 years ago
- Assignee set to Carlos Martín
#5 Updated by Ruben S. Montero over 8 years ago
- Status changed from New to Closed
- Resolution set to fixed