Questions about ONe's internal scheduling logic

Development
1

Hello everyone,

my colleagues are trying to pick apart the ONe scheduler and understand its internal logic. They asked me a few questions and I couldn’t answer some of them. So, I’m turning to you, the community :slight_smile:

  1. What happens when a datastore isn’t assigned to a specific cluster? Does it
    mean this datastore is available on all hosts (across all clusters), on hosts
    without any cluster, or nowhere? Does this logic apply to all objects which can
    be assigned a cluster?
  1. Why is it necessary to check the image datastore capacity before
    matching the datastore for a pending virtual machine?
    In the current scheduler implementation, each disk of an active VM
    consumes storage from an image datastore. VMs that require more
    storage than there is currently available are filtered out (will
    remain in the pending state).
  1. Is it true that if a datastore is shared then its capacity can be found directly
    in the datastore metadata but if it is not shared then its capacity must be checked
    directly in the host monitoring information under DATASTORES?
    What about the MAX_DISK/HOST_SHARE element, sometimes the capacity does
    not match the capacity in the DATASTORES element. What is the right
    way to check the capacity of datastores?

Regarding Q#2, we managed to identify a few key pieces of the code (see below). However, it didn’t help us understand what’s going on there.

Code where the test_image_datastore_capacity is called:

The test_image_datastore_capacity method:

Here is the definition of ImageDatastorePoolXML:

And the test_capacity method:

Any help or advice will be greatly appreciated.

Thanks!

2

What happens when a datastore isn’t assigned to a specific cluster? Does it
mean this datastore is available on all hosts (across all clusters), on hosts
without any cluster, or nowhere? Does this logic apply to all objects which can
be assigned a cluster?

In OpenNebula 5.0 each resource is assigned to a cluster, the “default” (ID:0) cluster is used if no one is specified. By default all resources are assigned to this cluster.

Note that in OpenNebula 4.14 we have the cluster none (ID:-1) that was used to share elements in all clusters (for some resources). Fortunately we got rid of this inconsistency.

Why is it necessary to check the image datastore capacity before
matching the datastore for a pending virtual machine?
In the current scheduler implementation, each disk of an active VM
consumes storage from an image datastore. VMs that require more
storage than there is currently available are filtered out (will
remain in the pending state).

This is needed for datastores with the attribute CLONE_TARGET=“SELF”.For example in Ceph VMs are cloned to the same pool, thus using space for the image datastore. VMs using other storage does not add disk size to the ds_usage variable. So, only disks from a datastore which TM driver sets the SELF flag adds to the image datastore capacity checks.

Is it true that if a datastore is shared then its capacity can be found directly
in the datastore metadata but if it is not shared then its capacity must be checked
directly in the host monitoring information under DATASTORES?

True, in the first case the information is obtained through the datastore monitoring script (new in 5.0) while the local datastore is obtained from the host monitoring.

What about the MAX_DISK/HOST_SHARE element, sometimes the capacity does
not match the capacity in the DATASTORES element. What is the right
way to check the capacity of datastores?

This refers to the space available under to /var/lib/one/datastores, this is only considered when there is no VM deployed in the host and the datastore directory does not exisits. It may differ from the datastore size when it is mounted from other device.

The logic would be,

  1. Get the TM configuration for the datastore driver from oned.conf
  2. If SHARED=“YES” you can use the datastore metadata for all hosts
  3. Otherwise you need to check the DS size in each host

Hope it helps

Cheers!

3

Thanks! That’s exactly what we needed.

4

Hello @ruben
I am working on XML-RPC methods and having following queries:

  1. one.vm.action method takes two parameters id and action, so how can we add scheduled action to it using XML-RPC call.
    CLI provides a command to do the same "onevm poweroff 0 --schedule “09/23 14:15” "
    How can we add scheduled time for action using API call?

Please suggest and guide on the above queries.
Looking for some solution approach as haven’t got much deep in any of the document for these queries.
Thanks in advance!!