<commit_before>---
title: oVirtSchedulerAPI
category: api
authors: doron, gchaplik, lhornyak, nslomian
wiki_category: Feature
wiki_title: Features/oVirtSchedulerAPI
wiki_revision_count: 57
wiki_last_updated: 2014-06-30
---

# o Virt Scheduler API

## [WIP] SLA Pluggable Architecture

### Summary

This feature will model all the scheduling into a single API, that oVirt admins can alter and enhance default scheduling behavior.

### Owner

*   Feature owners: [ <NAME>](User:gchaplik), [ <NAME>](User:dfediuck), [ <NAME>](User:lhornyak)

### Current status

*   Target Release: 3.2
*   Status: Design Phase
*   Last updated date: Mon Oct 22 2012

### Detailed Description

Currently scheduling mechanism is handled by oVirt engine internals. To allow users to enhance scheduling mechanism, we need to provide a way for a user to replace or add a self-written scheduler - or 'SLA Pluggable Architecture'. This feature is meant to model current scheduling methods into a single API (place), which will become the 'Default oVirt Scheduling Mechanism'. The Pluggable Architecture has to be flexible enough to foresee future API changes or at least keep them minimal, in order for API to be backward compatible and stable.

#### Existing Scheduling Mechanisms

Currently, we can divide oVirt scheduling into two flows, direct and indirect. These flows depend on the VM, host and cluster (oVirt scheduling parameters: HA, selection algo, failure policy, etc.). The direct flows are 'Run Vm' and 'Migrate Vm' commands (select host to run on) & Load Balancing task, the indirect flows are Maintanance VDS, SetNonOperationalVdsCommand, etc., which may cause migration (with host selection obviously). Additionally oVirt scheduling parameters (which will be explained next) are specific for existing scheduler. oVirt

##### VM migration policy - migration support (VM HA)

*   migratable, implicitly non migratable (autoStartup)
    -   References:
        -   RunVmCommandBase.canRunVm(Check if iso and floppy path exists ??),
        -   VmRunHandler.performImageChecksForRunningVm(Check isValid, storageDomain and diskSpace only if VM is not HA VM)
    -   commands:
        -   FenceVdsManualyCommand,
        -   ClearNonResponsiveVdsVmsCommand,
        -   MaintananceVdsCommand,
        -   RunVmCommandBase (starts spice)

<!-- -->

*   pin to host (dedicated_vm_for_vds)
    -   References:
        -   selection
        -   load balancing
    -   commands:
        -   ChangeVMClusterCommand (clear pinned host),
        -   RunVmCommand (selection)

<!-- -->

*   priority (priority, VmsComparer)
    -   References:
        -   VmsComparer
    -   Commands:
        -   MaintananceVds (+ numberOf),
        -   MigrateVM (order commands),
        -   LoadBalance (isMigratable),
        -   VdsSelector (pinned to host)

##### Cluster's Host selection policy (selection algorithm)

*   None
*   EvenlyDistribute
*   PowerSave

<!-- -->

*   References:
    -   LoadBalancer
    -   VdsGroupOperationCommandBase.validateMetrics (validating high/low utilization, adding/updating vdsGroup)
    -   VdsSelector

##### Cluster migration policy - resilience policy

MigrateOnErrorOptions: yes, no, HA only References: SetNonOperationalVdsCommand

##### Load Balancer

VdsLoadBalancer (Scheduled task)

#### Scheduler API

In order to really replace (enhance) the scheduler, we need to move all the code and parameters into the API; I know that this is a utopia (to do it all at once), so we'll do it in steps; first replace the 'direct' scheduler (see above), and then we are inspiring to box out also the indirect scheduler, scheduler validations and oVirt scheduler parameters for cluster, host and VM.

The new API is a single interface which extends 5 other interfaces:

*   HostSelector

chooses a host to run on according to selection algorithm. getSelectedHosts(): returns a list containing the last selected hosts. hasAnyHosts(): is called in the validation while running a VM, and returns whether there are hosts to choose from. selectHost(): is called in the execution while running a VM, and returns a host that the implemented algorithm chooses (note: should have shared code with hasAnyHosts).

*   LoadBalancer

Invoked for each cluster every interval and perform load balancing according to a load balancing algorithm. loadBalance() invoked every configValue.VdsLoadBalancingeIntervalInMinutes minutes.

*   TimerInvokedScheduler

Very much similar to the loadBalancer, but has a general purpose and can have a different timer span. onTimerInvoked(): invoked every configValue.SchedulerTimerIntervalInMinutes minutes.

*   VmStatusChanged

implements behavior for VM status transitions for SLA context.

*   HostStatusChanged

implements behavior for Host status transitions for SLA context.

##### Class Diagram

![](schedulerApi.png "schedulerApi.png")

scheduler API implements 5 other interfaces.

Methods' Parameters:
<commit_msg>Scheduler API<commit_after>---
title: oVirtSchedulerAPI
category: api
authors: doron, gchaplik, lhornyak, nslomian
wiki_category: Feature
wiki_title: Features/oVirtSchedulerAPI
wiki_revision_count: 57
wiki_last_updated: 2014-06-30
---

# o Virt Scheduler API

## [WIP] SLA Pluggable Architecture

### Summary

This feature will model all the scheduling into a single API, that oVirt admins can alter and enhance default scheduling behavior.

### Owner

*   Feature owners: [ <NAME>](User:gchaplik), [ <NAME>](User:dfediuck), [ <NAME>](User:lhornyak)

### Current status

*   Target Release: 3.2
*   Status: Design Phase
*   Last updated date: Mon Oct 22 2012

### Detailed Description

Currently scheduling mechanism is handled by oVirt engine internals. To allow users to enhance scheduling mechanism, we need to provide a way for a user to replace or add a self-written scheduler - or 'SLA Pluggable Architecture'. This feature is meant to model current scheduling methods into a single API (place), which will become the 'Default oVirt Scheduling Mechanism'. The Pluggable Architecture has to be flexible enough to foresee future API changes or at least keep them minimal, in order for API to be backward compatible and stable.

#### Existing Scheduling Mechanisms

Currently, we can divide oVirt scheduling into two flows, direct and indirect. These flows depend on the VM, host and cluster (oVirt scheduling parameters: HA, selection algo, failure policy, etc.). The direct flows are 'Run Vm' and 'Migrate Vm' commands (select host to run on) & Load Balancing task, the indirect flows are Maintanance VDS, SetNonOperationalVdsCommand, etc., which may cause migration (with host selection obviously). Additionally oVirt scheduling parameters (which will be explained next) are specific for existing scheduler. oVirt

##### VM migration policy - migration support (VM HA)

*   migratable, implicitly non migratable (autoStartup)
    -   References:
        -   RunVmCommandBase.canRunVm(Check if iso and floppy path exists ??),
        -   VmRunHandler.performImageChecksForRunningVm(Check isValid, storageDomain and diskSpace only if VM is not HA VM)
    -   commands:
        -   FenceVdsManualyCommand,
        -   ClearNonResponsiveVdsVmsCommand,
        -   MaintananceVdsCommand,
        -   RunVmCommandBase (starts spice)

<!-- -->

*   pin to host (dedicated_vm_for_vds)
    -   References:
        -   selection
        -   load balancing
    -   commands:
        -   ChangeVMClusterCommand (clear pinned host),
        -   RunVmCommand (selection)

<!-- -->

*   priority (priority, VmsComparer)
    -   References:
        -   VmsComparer
    -   Commands:
        -   MaintananceVds (+ numberOf),
        -   MigrateVM (order commands),
        -   LoadBalance (isMigratable),
        -   VdsSelector (pinned to host)

##### Cluster's Host selection policy (selection algorithm)

*   None
*   EvenlyDistribute
*   PowerSave

<!-- -->

*   References:
    -   LoadBalancer
    -   VdsGroupOperationCommandBase.validateMetrics (validating high/low utilization, adding/updating vdsGroup)
    -   VdsSelector

##### Cluster migration policy - resilience policy

MigrateOnErrorOptions: yes, no, HA only References: SetNonOperationalVdsCommand

##### Load Balancer

VdsLoadBalancer (Scheduled task)

#### Scheduler API

In order to really replace (enhance) the scheduler, we need to move all the code and parameters into the API; I know that this is a utopia (to do it all at once), so we'll do it in steps; first replace the 'direct' scheduler (see above), and then we are inspiring to box out also the indirect scheduler, scheduler validations and oVirt scheduler parameters for cluster, host and VM.

The new API is a single interface which extends 5 other interfaces:

*   HostSelector

Chooses a host to run on according to selection algorithm.

1.  getSelectedHosts(): returns a list containing the last selected hosts.
2.  hasAnyHosts(): is called in the validation while running a VM, and returns whether there are potential hosts to choose from.
3.  selectHost(): is called in the execution while running or migrating a VM, and returns a host that the implemented algorithm chooses (note: may have shared code with hasAnyHosts).

*   LoadBalancer

Invoked for each cluster every interval and perform load balancing according to a load balancing algorithm.

1.  loadBalance(): invoked every configValue.VdsLoadBalancingeIntervalInMinutes minutes.

*   TimerInvokedScheduler

Very much similar to the loadBalancer, but has a general purpose and can have a different timer span.

1.  onTimerInvoked(): invoked every configValue.SchedulerTimerIntervalInMinutes minutes.

*   VmStatusChanged

implements behavior for VM status transitions for SLA context.

*   HostStatusChanged

implements behavior for Host status transitions for SLA context.

##### Class Diagram

![](schedulerApi.png "schedulerApi.png")

scheduler API implements 5 other interfaces.

Methods' Parameters:

{'fraction_non_alphanumeric': 0.06822298249144697, 'fraction_numerical': 0.004528074059166835, 'mean_word_length': 3.903305377405032, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 15, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5883348', 'n_tokens_mistral': 2795, 'n_tokens_neox': 2668, 'n_words': 1153}