An external scheduler implementation may be able to do that but it must wait for the infrastructure.
Hello Simon, Do we have an idea of what that timeline for an external scheduler implementation might look to be? Is there another BZ open for that request? Thanks, Wesley
(In reply to comment #2) > Hello Simon, > > Do we have an idea of what that timeline for an external scheduler > implementation might look to be? Is there another BZ open for that request? > > Thanks, > Wesley Bug 912076 - (external-scheduler) Implement a plug-in scheduler implementation that interfaces to external scheduler via scheduling API and SDK Currently scheduled to 3.3, but this may change since it's also depends on the bug I've set earlier as blocking this one. I'll update if this is pushed out of 3.3.
This will be handled using OptaPlanner integration, as a recommendation view. Note that the implementation expects an already deployed OptaPlanner we can integrate with.
This is currently implemented using the new ovirt-optimizer project. Please take a look at the Optaplanner integration feature page http://www.ovirt.org/Features/Optaplanner where the project is described.
Original request was: 3. What is the nature and description of the request? RHEV-M should inform users/admins about a possible migration path for VMs when attempting to start a VM on a hypervisor that's not able to house the VM because the hypervisor does not have enough resources to house the VM. 4. Why does the customer need this? (List the business requirements here) Ease of administration. Currently the method would be for the admin/user to look through the list of VMs on each hypervisor and do the calculation themselves. Not the most effective use of time especially if need arises in a critical situation. 5. How would the customer like to achieve this? (List the functional requirements here) When attempting to start a VM on a hypervisor that does not have enough resources to allocate to the VM, RHEV-M should be able to check against the remaining hypervisors first to see if it can start on any of the other hypervisors. If it can, it should have a window pop up stating this, and whether or not it will take the hypervisor above any set threshold. If no hypervisor can start the VM due to not having enough resources available, it should state this, but at the same time be able to suggest possible migrations of current VMs that could occur to allow the larger VM that's unable to start to be started on a specified hypervisor. As one type of example, we have 14x 128G hypervisors, if all are running small (2G) VMs to 60%, that means each hypervisor has a roughly 48G of free memory, and roughly 670G of free memory in total in the cluster. Due to each hypervisor having roughly 48G of free memory a new 64G VM won't be able to boot in the cluster. 6. For each functional requirement listed in question 5, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Attempt to start a VM that won't fit within the available resources on a hypervisor. Including a setup where a different hypervisor has enough resources. And another setup where no other hypervisor has enough resources. In the setup we should be checking existing resources and thresholds before suggesting a possible migration path.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0210.html