Compute schedulers¶

Compute uses the nova-scheduler service to determine how to dispatch compute requests. For example, the nova-scheduler service determines on which host a VM should launch. In the context of filters, the term host means a physical node that has a nova-compute service running on it. You can configure the scheduler through a variety of options.

Compute is configured with the following default scheduler options in the /etc/nova/nova.conf file:

scheduler_driver_task_period = 60
scheduler_driver = nova.scheduler.filter_scheduler.FilterScheduler
scheduler_available_filters = nova.scheduler.filters.all_filters
scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter

By default, the scheduler_driver is configured as a filter scheduler, as described in the next section. In the default configuration, this scheduler considers hosts that meet all the following criteria:

Have not been attempted for scheduling purposes (RetryFilter).
Are in the requested availability zone (AvailabilityZoneFilter).
Have sufficient RAM available (RamFilter).
Have sufficient disk space available for root and ephemeral storage (DiskFilter).
Can service the request (ComputeFilter).
Satisfy the extra specs associated with the instance type (ComputeCapabilitiesFilter).
Satisfy any architecture, hypervisor type, or virtual machine mode properties specified on the instance’s image properties (ImagePropertiesFilter).
Are on a different host than other instances of a group (if requested) (ServerGroupAntiAffinityFilter).
Are in a set of group hosts (if requested) (ServerGroupAffinityFilter).

The scheduler caches its list of available hosts; use the scheduler_driver_task_period option to specify how often the list is updated.

Note

Do not configure service_down_time to be much smaller than scheduler_driver_task_period; otherwise, hosts appear to be dead while the host list is being cached.

For information about the volume scheduler, see the Block Storage section of OpenStack Administrator Guide.

The scheduler chooses a new host when an instance is migrated.

When evacuating instances from a host, the scheduler service honors the target host defined by the administrator on the nova evacuate command. If a target is not defined by the administrator, the scheduler determines the target host. For information about instance evacuation, see Evacuate instances section of the OpenStack Administrator Guide.

Filter scheduler¶

The filter scheduler (nova.scheduler.filter_scheduler.FilterScheduler) is the default scheduler for scheduling virtual machine instances. It supports filtering and weighting to make informed decisions on where a new instance should be created.

When the filter scheduler receives a request for a resource, it first applies filters to determine which hosts are eligible for consideration when dispatching a resource. Filters are binary: either a host is accepted by the filter, or it is rejected. Hosts that are accepted by the filter are then processed by a different algorithm to decide which hosts to use for that request, described in the Weights section.

Filtering

The scheduler_available_filters configuration option in nova.conf provides the Compute service with the list of the filters that are used by the scheduler. The default setting specifies all of the filter that are included with the Compute service:

scheduler_available_filters = nova.scheduler.filters.all_filters

This configuration option can be specified multiple times. For example, if you implemented your own custom filter in Python called myfilter.MyFilter and you wanted to use both the built-in filters and your custom filter, your nova.conf file would contain:

scheduler_available_filters = nova.scheduler.filters.all_filters
scheduler_available_filters = myfilter.MyFilter

The scheduler_default_filters configuration option in nova.conf defines the list of filters that are applied by the nova-scheduler service. The default filters are:

scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter

Compute filters¶

The following sections describe the available compute filters.

AggregateCoreFilter¶

Filters host by CPU core numbers with a per-aggregate cpu_allocation_ratio value. If the per-aggregate value is not found, the value falls back to the global setting. If the host is in more than one aggregate and more than one value is found, the minimum value will be used. For information about how to use this filter, see Host aggregates and availability zones. See also CoreFilter.

AggregateDiskFilter¶

Filters host by disk allocation with a per-aggregate disk_allocation_ratio value. If the per-aggregate value is not found, the value falls back to the global setting. If the host is in more than one aggregate and more than one value is found, the minimum value will be used. For information about how to use this filter, see Host aggregates and availability zones. See also DiskFilter.

AggregateImagePropertiesIsolation¶

Matches properties defined in an image’s metadata against those of aggregates to determine host matches:

If a host belongs to an aggregate and the aggregate defines one or more metadata that matches an image’s properties, that host is a candidate to boot the image’s instance.
If a host does not belong to any aggregate, it can boot instances from all images.

For example, the following aggregate myWinAgg has the Windows operating system as metadata (named ‘windows’):

$ nova aggregate-details MyWinAgg
+----+----------+-------------------+------------+---------------+
| Id | Name     | Availability Zone | Hosts      | Metadata      |
+----+----------+-------------------+------------+---------------+
| 1  | MyWinAgg | None              | 'sf-devel' | 'os=windows'  |
+----+----------+-------------------+------------+---------------+

In this example, because the following Win-2012 image has the windows property, it boots on the sf-devel host (all other filters being equal):

$ glance image-show Win-2012
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| Property 'os'    | windows                              |
| checksum         | f8a2eeee2dc65b3d9b6e63678955bd83     |
| container_format | ami                                  |
| created_at       | 2013-11-14T13:24:25                  |
| ...

You can configure the AggregateImagePropertiesIsolation filter by using the following options in the nova.conf file:

# Considers only keys matching the given namespace (string).
# Multiple values can be given, as a comma-separated list.
aggregate_image_properties_isolation_namespace = <None>

# Separator used between the namespace and keys (string).
aggregate_image_properties_isolation_separator = .

AggregateInstanceExtraSpecsFilter¶

Matches properties defined in extra specs for an instance type against admin-defined properties on a host aggregate. Works with specifications that are scoped with aggregate_instance_extra_specs. Multiple values can be given, as a comma-separated list. For backward compatibility, also works with non-scoped specifications; this action is highly discouraged because it conflicts with ComputeCapabilitiesFilter filter when you enable both filters. For information about how to use this filter, see the Host aggregates and availability zones section.

AggregateIoOpsFilter¶

Filters host by disk allocation with a per-aggregate max_io_ops_per_host value. If the per-aggregate value is not found, the value falls back to the global setting. If the host is in more than one aggregate and more than one value is found, the minimum value will be used. For information about how to use this filter, see Host aggregates and availability zones. See also IoOpsFilter.

AggregateMultiTenancyIsolation¶

Ensures that the tenant (or list of tenants) creates all instances only on specific Host aggregates and availability zones. If a host is in an aggregate that has the filter_tenant_id metadata key, the host creates instances from only that tenant or list of tenants. A host can be in different aggregates. If a host does not belong to an aggregate with the metadata key, the host can create instances from all tenants. This setting does not isolate the aggregate from other tenants. Any other tenant can continue to build instances on the specified aggregate.

AggregateNumInstancesFilter¶

Filters host by number of instances with a per-aggregate max_instances_per_host value. If the per-aggregate value is not found, the value falls back to the global setting. If the host is in more than one aggregate and thus more than one value is found, the minimum value will be used. For information about how to use this filter, see Host aggregates and availability zones. See also NumInstancesFilter.

AggregateRamFilter¶

Filters host by RAM allocation of instances with a per-aggregate ram_allocation_ratio value. If the per-aggregate value is not found, the value falls back to the global setting. If the host is in more than one aggregate and thus more than one value is found, the minimum value will be used. For information about how to use this filter, see Host aggregates and availability zones. See also RamFilter.

AggregateTypeAffinityFilter¶

This filter passes hosts if no instance_type key is set or the instance_type aggregate metadata value contains the name of the instance_type requested. The value of the instance_type metadata entry is a string that may contain either a single instance_type name or a comma-separated list of instance_type names, such as m1.nano or m1.nano,m1.small. For information about how to use this filter, see Host aggregates and availability zones. See also TypeAffinityFilter.

AllHostsFilter¶

This is a no-op filter. It does not eliminate any of the available hosts.

AvailabilityZoneFilter¶

Filters hosts by availability zone. You must enable this filter for the scheduler to respect availability zones in requests.

ComputeCapabilitiesFilter¶

Matches properties defined in extra specs for an instance type against compute capabilities. If an extra specs key contains a colon (:), anything before the colon is treated as a namespace and anything after the colon is treated as the key to be matched. If a namespace is present and is not capabilities, the filter ignores the namespace. For backward compatibility, also treats the extra specs key as the key to be matched if no namespace is present; this action is highly discouraged because it conflicts with AggregateInstanceExtraSpecsFilter filter when you enable both filters.

ComputeFilter¶

Passes all hosts that are operational and enabled.

In general, you should always enable this filter.

CoreFilter¶

Only schedules instances on hosts if sufficient CPU cores are available. If this filter is not set, the scheduler might over-provision a host based on cores. For example, the virtual cores running on an instance may exceed the physical cores.

You can configure this filter to enable a fixed amount of vCPU overcommitment by using the cpu_allocation_ratio configuration option in nova.conf. The default setting is:

cpu_allocation_ratio = 16.0

With this setting, if 8 vCPUs are on a node, the scheduler allows instances up to 128 vCPU to be run on that node.

To disallow vCPU overcommitment set:

cpu_allocation_ratio = 1.0

Note

The Compute API always returns the actual number of CPU cores available on a compute node regardless of the value of the cpu_allocation_ratio configuration key. As a result changes to the cpu_allocation_ratio are not reflected via the command line clients or the dashboard. Changes to this configuration key are only taken into account internally in the scheduler.

DifferentHostFilter¶

Schedules the instance on a different host from a set of instances. To take advantage of this filter, the requester must pass a scheduler hint, using different_host as the key and a list of instance UUIDs as the value. This filter is the opposite of the SameHostFilter. Using the nova command-line client, use the --hint flag. For example:

$ nova boot --image cedef40a-ed67-4d10-800e-17455edce175 --flavor 1 \
  --hint different_host=a0cf03a5-d921-4877-bb5c-86d26cf818e1 \
  --hint different_host=8c19174f-4220-44f0-824a-cd1eeef10287 server-1

With the API, use the os:scheduler_hints key. For example:

{
    "server": {
        "name": "server-1",
        "imageRef": "cedef40a-ed67-4d10-800e-17455edce175",
        "flavorRef": "1"
    },
    "os:scheduler_hints": {
        "different_host": [
            "a0cf03a5-d921-4877-bb5c-86d26cf818e1",
            "8c19174f-4220-44f0-824a-cd1eeef10287"
        ]
    }
}

DiskFilter¶

Only schedules instances on hosts if there is sufficient disk space available for root and ephemeral storage.

You can configure this filter to enable a fixed amount of disk overcommitment by using the disk_allocation_ratio configuration option in the nova.conf configuration file. The default setting disables the possibility of the overcommitment and allows launching a VM only if there is a sufficient amount of disk space available on a host:

disk_allocation_ratio = 1.0

DiskFilter always considers the value of the disk_available_least property and not the one of the free_disk_gb property of a hypervisor’s statistics:

$ nova hypervisor-stats
+----------------------+-------+
| Property             | Value |
+----------------------+-------+
| count                |  1    |
| current_workload     |  0    |
| disk_available_least |  29   |
| free_disk_gb         |  35   |
| free_ram_mb          |  3441 |
| local_gb             |  35   |
| local_gb_used        |  0    |
| memory_mb            |  3953 |
| memory_mb_used       |  512  |
| running_vms          |  0    |
| vcpus                |  2    |
| vcpus_used           |  0    |
+----------------------+-------+

As it can be viewed from the command output above, the amount of the available disk space can be less than the amount of the free disk space. It happens because the disk_available_least property accounts for the virtual size rather than the actual size of images. If you use an image format that is sparse or copy on write so that each virtual instance does not require a 1:1 allocation of a virtual disk to a physical storage, it may be useful to allow the overcommitment of disk space.

To enable scheduling instances while overcommitting disk resources on the node, adjust the value of the disk_allocation_ratio configuration option to greater than 1.0:

disk_allocation_ratio > 1.0

Note

If the value is set to >1, we recommend keeping track of the free disk space, as the value approaching 0 may result in the incorrect functioning of instances using it at the moment.

ExactCoreFilter¶

Only schedules instances on hosts if host has the exact number of CPU cores.

ExactDiskFilter¶

Only schedules instances on hosts if host has the exact amount of disk available.

ExactRamFilter¶

Only schedules instances on hosts if host has the exact number of RAM available.

GroupAffinityFilter¶

Note

This filter is deprecated in favor of ServerGroupAffinityFilter.

The GroupAffinityFilter ensures that an instance is scheduled on to a host from a set of group hosts. To take advantage of this filter, the requester must pass a scheduler hint, using group as the key and an arbitrary name as the value. Using the nova command-line client, use the --hint flag. For example:

$ nova boot --image IMAGE_ID --flavor 1 --hint group=foo server-1

This filter should not be enabled at the same time as GroupAntiAffinityFilter or neither filter will work properly.

GroupAntiAffinityFilter¶

Note

This filter is deprecated in favor of ServerGroupAntiAffinityFilter.

The GroupAntiAffinityFilter ensures that each instance in a group is on a different host. To take advantage of this filter, the requester must pass a scheduler hint, using group as the key and an arbitrary name as the value. Using the nova command-line client, use the --hint flag. For example:

$ nova boot --image IMAGE_ID --flavor 1 --hint group=foo server-1

This filter should not be enabled at the same time as GroupAffinityFilter or neither filter will work properly.

ImagePropertiesFilter¶

Filters hosts based on properties defined on the instance’s image. It passes hosts that can support the specified image properties contained in the instance. Properties include the architecture, hypervisor type, hypervisor version (for Xen hypervisor type only), and virtual machine mode.

For example, an instance might require a host that runs an ARM-based processor, and QEMU as the hypervisor. You can decorate an image with these properties by using:

$ glance image-update img-uuid --property architecture=arm --property hypervisor_type=qemu

The image properties that the filter checks for are:

architecture

describes the machine architecture required by the image. Examples are i686, x86_64, arm, and ppc64.

hypervisor_type

describes the hypervisor required by the image. Examples are xen, qemu, and xenapi.

Note

qemu is used for both QEMU and KVM hypervisor types.

hypervisor_version_requires

describes the hypervisor version required by the image. The property is supported for Xen hypervisor type only. It can be used to enable support for multiple hypervisor versions, and to prevent instances with newer Xen tools from being provisioned on an older version of a hypervisor. If available, the property value is compared to the hypervisor version of the compute host.

To filter the hosts by the hypervisor version, add the hypervisor_version_requires property on the image as metadata and pass an operator and a required hypervisor version as its value:

$ glance image-update img-uuid --property hypervisor_type=xen --property hypervisor_version_requires=">=4.3"

vm_mode

describes the hypervisor application binary interface (ABI) required by the image. Examples are xen for Xen 3.0 paravirtual ABI, hvm for native ABI, uml for User Mode Linux paravirtual ABI, exe for container virt executable ABI.

IsolatedHostsFilter¶

Allows the admin to define a special (isolated) set of images and a special (isolated) set of hosts, such that the isolated images can only run on the isolated hosts, and the isolated hosts can only run isolated images. The flag restrict_isolated_hosts_to_isolated_images can be used to force isolated hosts to only run isolated images.

The admin must specify the isolated set of images and hosts in the nova.conf file using the isolated_hosts and isolated_images configuration options. For example:

isolated_hosts = server1, server2
isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-bd132d6b7d09

IoOpsFilter¶

The IoOpsFilter filters hosts by concurrent I/O operations on it. Hosts with too many concurrent I/O operations will be filtered out. The max_io_ops_per_host option specifies the maximum number of I/O intensive instances allowed to run on a host. A host will be ignored by the scheduler if more than max_io_ops_per_host instances in build, resize, snapshot, migrate, rescue or unshelve task states are running on it.

JsonFilter¶

The JsonFilter allows a user to construct a custom filter by passing a scheduler hint in JSON format. The following operators are supported:

=
<
>
in
<=
>=
not
or
and

The filter supports the following variables:

$free_ram_mb
$free_disk_mb
$total_usable_ram_mb
$vcpus_total
$vcpus_used

Using the nova command-line client, use the --hint flag:

$ nova boot --image 827d564a-e636-4fc4-a376-d36f7ebe1747 \
  --flavor 1 --hint query='[">=","$free_ram_mb",1024]' server1

With the API, use the os:scheduler_hints key:

{
    "server": {
        "name": "server-1",
        "imageRef": "cedef40a-ed67-4d10-800e-17455edce175",
        "flavorRef": "1"
    },
    "os:scheduler_hints": {
        "query": "[>=,$free_ram_mb,1024]"
    }
}

MetricsFilter¶

Filters hosts based on meters weight_setting. Only hosts with the available meters are passed so that the metrics weigher will not fail due to these hosts.

NUMATopologyFilter¶

Filters hosts based on the NUMA topology that was specified for the instance through the use of flavor extra_specs in combination with the image properties, as described in detail in the related nova-spec document. Filter will try to match the exact NUMA cells of the instance to those of the host. It will consider the standard over-subscription limits each cell, and provide limits to the compute host accordingly.

Note

If instance has no topology defined, it will be considered for any host. If instance has a topology defined, it will be considered only for NUMA capable hosts.

NumInstancesFilter¶

Hosts that have more instances running than specified by the max_instances_per_host option are filtered out when this filter is in place.

PciPassthroughFilter¶

The filter schedules instances on a host if the host has devices that meet the device requests in the extra_specs attribute for the flavor.

RamFilter¶

Only schedules instances on hosts that have sufficient RAM available. If this filter is not set, the scheduler may over provision a host based on RAM (for example, the RAM allocated by virtual machine instances may exceed the physical RAM).

You can configure this filter to enable a fixed amount of RAM overcommitment by using the ram_allocation_ratio configuration option in nova.conf. The default setting is:

ram_allocation_ratio = 1.5

This setting enables 1.5 GB instances to run on any compute node with 1 GB of free RAM.

RetryFilter¶

Filters out hosts that have already been attempted for scheduling purposes. If the scheduler selects a host to respond to a service request, and the host fails to respond to the request, this filter prevents the scheduler from retrying that host for the service request.

This filter is only useful if the scheduler_max_attempts configuration option is set to a value greater than zero.

SameHostFilter¶

Schedules the instance on the same host as another instance in a set of instances. To take advantage of this filter, the requester must pass a scheduler hint, using same_host as the key and a list of instance UUIDs as the value. This filter is the opposite of the DifferentHostFilter. Using the nova command-line client, use the --hint flag:

$ nova boot --image cedef40a-ed67-4d10-800e-17455edce175 --flavor 1 \
  --hint same_host=a0cf03a5-d921-4877-bb5c-86d26cf818e1 \
  --hint same_host=8c19174f-4220-44f0-824a-cd1eeef10287 server-1

With the API, use the os:scheduler_hints key:

{
    "server": {
        "name": "server-1",
        "imageRef": "cedef40a-ed67-4d10-800e-17455edce175",
        "flavorRef": "1"
    },
    "os:scheduler_hints": {
        "same_host": [
            "a0cf03a5-d921-4877-bb5c-86d26cf818e1",
            "8c19174f-4220-44f0-824a-cd1eeef10287"
        ]
    }
}

ServerGroupAffinityFilter¶

The ServerGroupAffinityFilter ensures that an instance is scheduled on to a host from a set of group hosts. To take advantage of this filter, the requester must create a server group with an affinity policy, and pass a scheduler hint, using group as the key and the server group UUID as the value. Using the nova command-line tool, use the --hint flag. For example:

$ nova server-group-create --policy affinity group-1
$ nova boot --image IMAGE_ID --flavor 1 --hint group=SERVER_GROUP_UUID server-1

ServerGroupAntiAffinityFilter¶

The ServerGroupAntiAffinityFilter ensures that each instance in a group is on a different host. To take advantage of this filter, the requester must create a server group with an anti-affinity policy, and pass a scheduler hint, using group as the key and the server group UUID as the value. Using the nova command-line client, use the --hint flag. For example:

$ nova server-group-create --policy anti-affinity group-1
$ nova boot --image IMAGE_ID --flavor 1 --hint group=SERVER_GROUP_UUID server-1

SimpleCIDRAffinityFilter¶

Schedules the instance based on host IP subnet range. To take advantage of this filter, the requester must specify a range of valid IP address in CIDR format, by passing two scheduler hints:

build_near_host_ip: The first IP address in the subnet (for example, 192.168.1.1)
cidr: The CIDR that corresponds to the subnet (for example, /24)

Using the nova command-line client, use the --hint flag. For example, to specify the IP subnet 192.168.1.1/24:

$ nova boot --image cedef40a-ed67-4d10-800e-17455edce175 --flavor 1 \
  --hint build_near_host_ip=192.168.1.1 --hint cidr=/24 server-1

With the API, use the os:scheduler_hints key:

{
    "server": {
        "name": "server-1",
        "imageRef": "cedef40a-ed67-4d10-800e-17455edce175",
        "flavorRef": "1"
    },
    "os:scheduler_hints": {
        "build_near_host_ip": "192.168.1.1",
        "cidr": "24"
    }
}

TrustedFilter¶

Filters hosts based on their trust. Only passes hosts that meet the trust requirements specified in the instance properties.

TypeAffinityFilter¶

Dynamically limits hosts to one instance type. An instance can only be launched on a host, if no instance with different instances types are running on it, or if the host has no running instances at all.

Cell filters¶

The following sections describe the available cell filters.

DifferentCellFilter¶

Schedules the instance on a different cell from a set of instances. To take advantage of this filter, the requester must pass a scheduler hint, using different_cell as the key and a list of instance UUIDs as the value.

ImagePropertiesFilter¶

Filters cells based on properties defined on the instance’s image. This filter works specifying the hypervisor required in the image metadata and the supported hypervisor version in cell capabilities.

TargetCellFilter¶

Filters target cells. This filter works by specifying a scheduler hint of target_cell. The value should be the full cell path.

Weights¶

When resourcing instances, the filter scheduler filters and weights each host in the list of acceptable hosts. Each time the scheduler selects a host, it virtually consumes resources on it, and subsequent selections are adjusted accordingly. This process is useful when the customer asks for the same large amount of instances, because weight is computed for each requested instance.

All weights are normalized before being summed up; the host with the largest weight is given the highest priority.

Weighting hosts

If cells are used, cells are weighted by the scheduler in the same manner as hosts.

Hosts and cells are weighted based on the following options in the /etc/nova/nova.conf file:

Host weighting options¶
Section	Option	Description
[DEFAULT]	`ram_weight_multiplier`	By default, the scheduler spreads instances across all hosts evenly. Set the `ram_weight_multiplier` option to a negative number if you prefer stacking instead of spreading. Use a floating-point value.
[DEFAULT]	`scheduler_host_subset_size`	New instances are scheduled on a host that is chosen randomly from a subset of the N best hosts. This property defines the subset size from which a host is chosen. A value of 1 chooses the first host returned by the weighting functions. This value must be at least 1. A value less than 1 is ignored, and 1 is used instead. Use an integer value.
[DEFAULT]	`scheduler_weight_classes`	Defaults to `nova.scheduler.weights.all_weighers`. Hosts are then weighted and sorted with the largest weight winning.
[DEFAULT]	`io_ops_weight_multiplier`	Multiplier used for weighing host I/O operations. A negative value means a preference to choose light workload compute hosts.
[DEFAULT]	`soft_affinity_weight_multiplier`	Multiplier used for weighing hosts for group soft-affinity. Only a positive value is meaningful. Negative means that the behavior will change to the opposite, which is soft-anti-affinity.
[DEFAULT]	`soft_anti_affinity_weight_multiplier`	Multiplier used for weighing hosts for group soft-anti-affinity. Only a positive value is meaningful. Negative means that the behavior will change to the opposite, which is soft-affinity.
[metrics]	`weight_multiplier`	Multiplier for weighting meters. Use a floating-point value.
[metrics]	`weight_setting`	Determines how meters are weighted. Use a comma-separated list of metricName=ratio. For example: `name1=1.0, name2=-1.0` results in: `name1.value * 1.0 + name2.value * -1.0`
[metrics]	`required`	Specifies how to treat unavailable meters: True - Raises an exception. To avoid the raised exception, you should use the scheduler filter `MetricFilter` to filter out hosts with unavailable meters. False - Treated as a negative factor in the weighting process (uses the `weight_of_unavailable` option).
[metrics]	`weight_of_unavailable`	If `required` is set to False, and any one of the meters set by `weight_setting` is unavailable, the `weight_of_unavailable` value is returned to the scheduler.

For example:

[DEFAULT]
scheduler_host_subset_size = 1
scheduler_weight_classes = nova.scheduler.weights.all_weighers
ram_weight_multiplier = 1.0
io_ops_weight_multiplier = 2.0
soft_affinity_weight_multiplier = 1.0
soft_anti_affinity_weight_multiplier = 1.0
[metrics]
weight_multiplier = 1.0
weight_setting = name1=1.0, name2=-1.0
required = false
weight_of_unavailable = -10000.0

Cell weighting options¶
Section	Option	Description
[cells]	`mute_weight_multiplier`	Multiplier to weight mute children (hosts which have not sent capacity or capacity updates for some time). Use a negative, floating-point value.
[cells]	`offset_weight_multiplier`	Multiplier to weight cells, so you can specify a preferred cell. Use a floating point value.
[cells]	`ram_weight_multiplier`	By default, the scheduler spreads instances across all cells evenly. Set the `ram_weight_multiplier` option to a negative number if you prefer stacking instead of spreading. Use a floating-point value.
[cells]	`scheduler_weight_classes`	Defaults to `nova.cells.weights.all_weighers`, which maps to all cell weighers included with Compute. Cells are then weighted and sorted with the largest weight winning.

For example:

[cells]
scheduler_weight_classes = nova.cells.weights.all_weighers
mute_weight_multiplier = -10.0
ram_weight_multiplier = 1.0
offset_weight_multiplier = 1.0

Chance scheduler¶

As an administrator, you work with the filter scheduler. However, the Compute service also uses the Chance Scheduler, nova.scheduler.chance.ChanceScheduler, which randomly selects from lists of filtered hosts.

Utilization aware scheduling¶

It is possible to schedule VMs using advanced scheduling decisions. These decisions are made based on enhanced usage statistics encompassing data like memory cache utilization, memory bandwidth utilization, or network bandwidth utilization. This is disabled by default. The administrator can configure how the metrics are weighted in the configuration file by using the weight_setting configuration option in the nova.conf configuration file. For example to configure metric1 with ratio1 and metric2 with ratio2:

weight_setting = "metric1=ratio1, metric2=ratio2"

Host aggregates and availability zones¶

Host aggregates are a mechanism for partitioning hosts in an OpenStack cloud, or a region of an OpenStack cloud, based on arbitrary characteristics. Examples where an administrator may want to do this include where a group of hosts have additional hardware or performance characteristics.

Host aggregates are not explicitly exposed to users. Instead administrators map flavors to host aggregates. Administrators do this by setting metadata on a host aggregate, and matching flavor extra specifications. The scheduler then endeavors to match user requests for instance of the given flavor to a host aggregate with the same key-value pair in its metadata. Compute nodes can be in more than one host aggregate.

Administrators are able to optionally expose a host aggregate as an availability zone. Availability zones are different from host aggregates in that they are explicitly exposed to the user, and hosts can only be in a single availability zone. Administrators can configure a default availability zone where instances will be scheduled when the user fails to specify one.

Command-line interface¶

The nova command-line client supports the following aggregate-related commands.

nova aggregate-list: Print a list of all aggregates.
nova aggregate-create <name> [availability-zone]: Create a new aggregate named <name>, and optionally in availability zone [availability-zone] if specified. The command returns the ID of the newly created aggregate. Hosts can be made available to multiple host aggregates. Be careful when adding a host to an additional host aggregate when the host is also in an availability zone. Pay attention when using the nova aggregate-set-metadata and nova aggregate-update commands to avoid user confusion when they boot instances in different availability zones. An error occurs if you cannot add a particular host to an aggregate zone for which it is not intended.
nova aggregate-delete <id>: Delete an aggregate with id <id>.
nova aggregate-details <id>: Show details of the aggregate with id <id>.
nova aggregate-add-host <id> <host>: Add host with name <host> to aggregate with id <id>.
nova aggregate-remove-host <id> <host>: Remove the host with name <host> from the aggregate with id <id>.
nova aggregate-set-metadata <id> <key=value> [<key=value> ...]: Add or update metadata (key-value pairs) associated with the aggregate with id <id>.
nova aggregate-update <id> <name> [<availability_zone>]: Update the name and availability zone (optional) for the aggregate.
nova host-list: List all hosts by service.
nova host-update –maintenance [enable | disable]: Put/resume host into/from maintenance.

Note

Only administrators can access these commands. If you try to use these commands and the user name and tenant that you use to access the Compute service do not have the admin role or the appropriate privileges, these errors occur:

ERROR: Policy doesn't allow compute_extension:aggregates to be performed. (HTTP 403) (Request-ID: req-299fbff6-6729-4cef-93b2-e7e1f96b4864)

ERROR: Policy doesn't allow compute_extension:hosts to be performed. (HTTP 403) (Request-ID: req-ef2400f6-6776-4ea3-b6f1-7704085c27d1)

Configure scheduler to support host aggregates¶

One common use case for host aggregates is when you want to support scheduling instances to a subset of compute hosts because they have a specific capability. For example, you may want to allow users to request compute hosts that have SSD drives if they need access to faster disk I/O, or access to compute hosts that have GPU cards to take advantage of GPU-accelerated code.

To configure the scheduler to support host aggregates, the scheduler_default_filters configuration option must contain the AggregateInstanceExtraSpecsFilter in addition to the other filters used by the scheduler. Add the following line to /etc/nova/nova.conf on the host that runs the nova-scheduler service to enable host aggregates filtering, as well as the other filters that are typically enabled:

scheduler_default_filters=AggregateInstanceExtraSpecsFilter,RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

Example: Specify compute hosts with SSDs¶

This example configures the Compute service to enable users to request nodes that have solid-state drives (SSDs). You create a fast-io host aggregate in the nova availability zone and you add the ssd=true key-value pair to the aggregate. Then, you add the node1, and node2 compute nodes to it.

$ nova aggregate-create fast-io nova
+----+---------+-------------------+-------+----------+
| Id | Name    | Availability Zone | Hosts | Metadata |
+----+---------+-------------------+-------+----------+
| 1  | fast-io | nova              |       |          |
+----+---------+-------------------+-------+----------+

$ nova aggregate-set-metadata 1 ssd=true
+----+---------+-------------------+-------+-------------------+
| Id | Name    | Availability Zone | Hosts | Metadata          |
+----+---------+-------------------+-------+-------------------+
| 1  | fast-io | nova              | []    | {u'ssd': u'true'} |
+----+---------+-------------------+-------+-------------------+

$ nova aggregate-add-host 1 node1
+----+---------+-------------------+------------+-------------------+
| Id | Name    | Availability Zone | Hosts      | Metadata          |
+----+---------+-------------------+------------+-------------------+
| 1  | fast-io | nova              | [u'node1'] | {u'ssd': u'true'} |
+----+---------+-------------------+------------+-------------------+

$ nova aggregate-add-host 1 node2
+----+---------+-------------------+----------------------+-------------------+
| Id | Name    | Availability Zone | Hosts                | Metadata          |
+----+---------+-------------------+----------------------+-------------------+
| 1  | fast-io | nova              | [u'node1', u'node2'] | {u'ssd': u'true'} |
+----+---------+-------------------+----------------------+-------------------+

Use the nova flavor-create command to create the ssd.large flavor called with an ID of 6, 8 GB of RAM, 80 GB root disk, and four vCPUs.

$ nova flavor-create ssd.large 6 8192 80 4
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name      | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+
| 6  | ssd.large | 8192      | 80   | 0         |      | 4     | 1.0         | True      |
+----+-----------+-----------+------+-----------+------+-------+-------------+-----------+

Once the flavor is created, specify one or more key-value pairs that match the key-value pairs on the host aggregates with scope aggregate_instance_extra_specs. In this case, that is the aggregate_instance_extra_specs:ssd=true key-value pair. Setting a key-value pair on a flavor is done using the nova flavor-key command.

$ nova flavor-key ssd.large set aggregate_instance_extra_specs:ssd=true

Once it is set, you should see the extra_specs property of the ssd.large flavor populated with a key of ssd and a corresponding value of true.

$ nova flavor-show ssd.large
+----------------------------+--------------------------------------------------+
| Property                   | Value                                            |
+----------------------------+--------------------------------------------------+
| OS-FLV-DISABLED:disabled   | False                                            |
| OS-FLV-EXT-DATA:ephemeral  | 0                                                |
| disk                       | 80                                               |
| extra_specs                | {u'aggregate_instance_extra_specs:ssd': u'true'} |
| id                         | 6                                                |
| name                       | ssd.large                                        |
| os-flavor-access:is_public | True                                             |
| ram                        | 8192                                             |
| rxtx_factor                | 1.0                                              |
| swap                       |                                                  |
| vcpus                      | 4                                                |
+----------------------------+--------------------------------------------------+

Now, when a user requests an instance with the ssd.large flavor, the scheduler only considers hosts with the ssd=true key-value pair. In this example, these are node1 and node2.

XenServer hypervisor pools to support live migration¶

When using the XenAPI-based hypervisor, the Compute service uses host aggregates to manage XenServer Resource pools, which are used in supporting live migration.

Configuration options¶

The Compute scheduler configuration options are documented in the tables below.

Description of scheduler configuration options¶
Configuration option = Default value	Description
[DEFAULT]
`aggregate_image_properties_isolation_namespace` = `None`	(String) Images and hosts can be configured so that certain images can only be scheduled to hosts in a particular aggregate. This is done with metadata values set on the host aggregate that are identified by beginning with the value of this option. If the host is part of an aggregate with such a metadata key, the image in the request spec must have the value of that metadata in its properties in order for the scheduler to consider the host as acceptable. Valid values are strings. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Also note that this setting only affects scheduling if the ‘aggregate_image_properties_isolation’ filter is enabled. Related options: aggregate_image_properties_isolation_separator
`aggregate_image_properties_isolation_separator` = `.`	(String) When using the aggregate_image_properties_isolation filter, the relevant metadata keys are prefixed with the namespace defined in the aggregate_image_properties_isolation_namespace configuration option plus a separator. This option defines the separator to be used. It defaults to a period (‘.’). Valid values are strings. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Also note that this setting only affects scheduling if the ‘aggregate_image_properties_isolation’ filter is enabled. Related options: aggregate_image_properties_isolation_namespace
`baremetal_scheduler_default_filters` = `RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ExactRamFilter, ExactDiskFilter, ExactCoreFilter`	(List) This option specifies the filters used for filtering baremetal hosts. The value should be a list of strings, with each string being the name of a filter class to be used. When used, they will be applied in order, so place your most restrictive filters first to make the filtering process more efficient. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: If the ‘scheduler_use_baremetal_filters’ option is False, this option has no effect.
`cpu_allocation_ratio` = `0.0`	(Floating point) This option helps you specify virtual CPU to physical CPU allocation ratio which affects all CPU filters. This configuration specifies ratio for CoreFilter which can be set per compute node. For AggregateCoreFilter, it will fall back to this configuration value if no per-aggregate setting is found. Possible values: Any valid positive integer or float value Default value is 0.0 NOTE: This can be set per-compute, or if set to 0.0, the value set on the scheduler node(s) or compute node(s) will be used and defaulted to 16.0’.
`disk_allocation_ratio` = `0.0`	(Floating point) This option helps you specify virtual disk to physical disk allocation ratio used by the disk_filter.py script to determine if a host has sufficient disk space to fit a requested instance. A ratio greater than 1.0 will result in over-subscription of the available physical disk, which can be useful for more efficiently packing instances created with images that do not use the entire virtual disk, such as sparse or compressed images. It can be set to a value between 0.0 and 1.0 in order to preserve a percentage of the disk for uses other than instances. Possible values: Any valid positive integer or float value Default value is 0.0 NOTE: This can be set per-compute, or if set to 0.0, the value set on the scheduler node(s) or compute node(s) will be used and defaulted to 1.0’.
`disk_weight_multiplier` = `1.0`	(Floating point) Multiplier used for weighing free disk space. Negative numbers mean to stack vs spread.
`io_ops_weight_multiplier` = `-1.0`	(Floating point) This option determines how hosts with differing workloads are weighed. Negative values, such as the default, will result in the scheduler preferring hosts with lighter workloads whereas positive values will prefer hosts with heavier workloads. Another way to look at it is that positive values for this option will tend to schedule instances onto hosts that are already busy, while negative values will tend to distribute the workload across more hosts. The absolute value, whether positive or negative, controls how strong the io_ops weigher is relative to other weighers. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Also note that this setting only affects scheduling if the ‘io_ops’ weigher is enabled. Valid values are numeric, either integer or float. Related options: None
`isolated_hosts` =	(List) If there is a need to restrict some images to only run on certain designated hosts, list those host names here. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Also note that this setting only affects scheduling if the ‘IsolatedHostsFilter’ filter is enabled. Related options: scheduler/isolated_images scheduler/restrict_isolated_hosts_to_isolated_images
`isolated_images` =	(List) If there is a need to restrict some images to only run on certain designated hosts, list those image UUIDs here. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Also note that this setting only affects scheduling if the ‘IsolatedHostsFilter’ filter is enabled. Related options: scheduler/isolated_hosts scheduler/restrict_isolated_hosts_to_isolated_images
`max_instances_per_host` = `50`	(Integer) If you need to limit the number of instances on any given host, set this option to the maximum number of instances you want to allow. The num_instances_filter will reject any host that has at least as many instances as this option’s value. Valid values are positive integers; setting it to zero will cause all hosts to be rejected if the num_instances_filter is active. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Also note that this setting only affects scheduling if the ‘num_instances_filter’ filter is enabled. Related options: None
`max_io_ops_per_host` = `8`	(Integer) This setting caps the number of instances on a host that can be actively performing IO (in a build, resize, snapshot, migrate, rescue, or unshelve task state) before that host becomes ineligible to build new instances. Valid values are positive integers: 1 or greater. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Also note that this setting only affects scheduling if the ‘io_ops_filter’ filter is enabled. Related options: None
`ram_allocation_ratio` = `0.0`	(Floating point) This option helps you specify virtual RAM to physical RAM allocation ratio which affects all RAM filters. This configuration specifies ratio for RamFilter which can be set per compute node. For AggregateRamFilter, it will fall back to this configuration value if no per-aggregate setting found. Possible values: Any valid positive integer or float value Default value is 0.0 NOTE: This can be set per-compute, or if set to 0.0, the value set on the scheduler node(s) or compute node(s) will be used and defaulted to 1.5.
`ram_weight_multiplier` = `1.0`	(Floating point) This option determines how hosts with more or less available RAM are weighed. A positive value will result in the scheduler preferring hosts with more available RAM, and a negative number will result in the scheduler preferring hosts with less available RAM. Another way to look at it is that positive values for this option will tend to spread instances across many hosts, while negative values will tend to fill up (stack) hosts as much as possible before scheduling to a less-used host. The absolute value, whether positive or negative, controls how strong the RAM weigher is relative to other weighers. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Also note that this setting only affects scheduling if the ‘ram’ weigher is enabled. Valid values are numeric, either integer or float. Related options: None
`reserved_host_disk_mb` = `0`	(Integer) Amount of disk resources in MB to make them always available to host. The disk usage gets reported back to the scheduler from nova-compute running on the compute nodes. To prevent the disk resources from being considered as available, this option can be used to reserve disk space for that host. Possible values: Any positive integer representing amount of disk in MB to reserve for the host.
`reserved_host_memory_mb` = `512`	(Integer) Amount of memory in MB to reserve for the host so that it is always available to host processes. The host resources usage is reported back to the scheduler continuously from nova-compute running on the compute node. To prevent the host memory from being considered as available, this option is used to reserve memory for the host. Possible values: Any positive integer representing amount of memory in MB to reserve for the host.
`reserved_huge_pages` = `None`	(Unknown) Reserves a number of huge/large memory pages per NUMA host cells Possible values: A list of valid key=value which reflect NUMA node ID, page size (Default unit is KiB) and number of pages to be reserved. reserved_huge_pages = node:0,size:2048,count:64 reserved_huge_pages = node:1,size:1GB,count:1 In this example we are reserving on NUMA node 0 64 pages of 2MiB and on NUMA node 1 1 page of 1GiB.
`restrict_isolated_hosts_to_isolated_images` = `True`	(Boolean) This setting determines if the scheduler’s isolated_hosts filter will allow non-isolated images on a host designated as an isolated host. When set to True (the default), non-isolated images will not be allowed to be built on isolated hosts. When False, non-isolated images can be built on both isolated and non-isolated hosts alike. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Also note that this setting only affects scheduling if the ‘IsolatedHostsFilter’ filter is enabled. Even then, this option doesn’t affect the behavior of requests for isolated images, which will always be restricted to isolated hosts. Related options: scheduler/isolated_images scheduler/isolated_hosts
`scheduler_available_filters` = `['nova.scheduler.filters.all_filters']`	(Multi-valued) This is an unordered list of the filter classes the Nova scheduler may apply. Only the filters specified in the ‘scheduler_default_filters’ option will be used, but any filter appearing in that option must also be included in this list. By default, this is set to all filters that are included with Nova. If you wish to change this, replace this with a list of strings, where each element is the path to a filter. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: scheduler_default_filters
`scheduler_default_filters` = `RetryFilter, AvailabilityZoneFilter, RamFilter, DiskFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter`	(List) This option is the list of filter class names that will be used for filtering hosts. The use of ‘default’ in the name of this option implies that other filters may sometimes be used, but that is not the case. These filters will be applied in the order they are listed, so place your most restrictive filters first to make the filtering process more efficient. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: All of the filters in this option must be present in the ‘scheduler_available_filters’ option, or a SchedulerHostFilterNotFound exception will be raised.
`scheduler_driver` = `filter_scheduler`	(String) The class of the driver used by the scheduler. This should be chosen from one of the entrypoints under the namespace ‘nova.scheduler.driver’ of file ‘setup.cfg’. If nothing is specified in this option, the ‘filter_scheduler’ is used. This option also supports deprecated full Python path to the class to be used. For example, “nova.scheduler.filter_scheduler.FilterScheduler”. But note: this support will be dropped in the N Release. Other options are: ‘caching_scheduler’ which aggressively caches the system state for better individual scheduler performance at the risk of more retries when running multiple schedulers. ‘chance_scheduler’ which simply picks a host at random. ‘fake_scheduler’ which is used for testing. Related options: None
`scheduler_driver_task_period` = `60`	(Integer) This value controls how often (in seconds) to run periodic tasks in the scheduler. The specific tasks that are run for each period are determined by the particular scheduler being used. If this is larger than the nova-service ‘service_down_time’ setting, Nova may report the scheduler service as down. This is because the scheduler driver is responsible for sending a heartbeat and it will only do that as often as this option allows. As each scheduler can work a little differently than the others, be sure to test this with your selected scheduler. Related options: `nova-service service_down_time`
`scheduler_host_manager` = `host_manager`	(String) The scheduler host manager to use, which manages the in-memory picture of the hosts that the scheduler uses. The option value should be chosen from one of the entrypoints under the namespace ‘nova.scheduler.host_manager’ of file ‘setup.cfg’. For example, ‘host_manager’ is the default setting. Aside from the default, the only other option as of the Mitaka release is ‘ironic_host_manager’, which should be used if you’re using Ironic to provision bare-metal instances. Related options: None
`scheduler_host_subset_size` = `1`	(Integer) New instances will be scheduled on a host chosen randomly from a subset of the N best hosts, where N is the value set by this option. Valid values are 1 or greater. Any value less than one will be treated as 1. Setting this to a value greater than 1 will reduce the chance that multiple scheduler processes handling similar requests will select the same host, creating a potential race condition. By selecting a host randomly from the N hosts that best fit the request, the chance of a conflict is reduced. However, the higher you set this value, the less optimal the chosen host may be for a given request. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: None
`scheduler_instance_sync_interval` = `120`	(Integer) Waiting time interval (seconds) between sending the scheduler a list of current instance UUIDs to verify that its view of instances is in sync with nova. If the CONF option scheduler_tracks_instance_changes is False, changing this option will have no effect.
`scheduler_json_config_location` =	(String) The absolute path to the scheduler configuration JSON file, if any. This file location is monitored by the scheduler for changes and reloads it if needed. It is converted from JSON to a Python data structure, and passed into the filtering and weighing functions of the scheduler, which can use it for dynamic configuration. Related options: None
`scheduler_manager` = `nova.scheduler.manager.SchedulerManager`	(String) DEPRECATED: Full class name for the Manager for scheduler
`scheduler_max_attempts` = `3`	(Integer) This is the maximum number of attempts that will be made to schedule an instance before it is assumed that the failures aren’t due to normal occasional race conflicts, but rather some other problem. When this is reached a MaxRetriesExceeded exception is raised, and the instance is set to an error state. Valid values are positive integers (1 or greater). Related options: None
`scheduler_topic` = `scheduler`	(String) This is the message queue topic that the scheduler ‘listens’ on. It is used when the scheduler service is started up to configure the queue, and whenever an RPC call to the scheduler is made. There is almost never any reason to ever change this value. Related options: None
`scheduler_tracks_instance_changes` = `True`	(Boolean) The scheduler may need information about the instances on a host in order to evaluate its filters and weighers. The most common need for this information is for the (anti-)affinity filters, which need to choose a host based on the instances already running on a host. If the configured filters and weighers do not need this information, disabling this option will improve performance. It may also be disabled when the tracking overhead proves too heavy, although this will cause classes requiring host usage data to query the database on each request instead. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: None
`scheduler_use_baremetal_filters` = `False`	(Boolean) Set this to True to tell the nova scheduler that it should use the filters specified in the ‘baremetal_scheduler_default_filters’ option. If you are not scheduling baremetal nodes, leave this at the default setting of False. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: If this option is set to True, then the filters specified in the ‘baremetal_scheduler_default_filters’ are used instead of the filters specified in ‘scheduler_default_filters’.
`scheduler_weight_classes` = `nova.scheduler.weights.all_weighers`	(List) This is a list of weigher class names. Only hosts which pass the filters are weighed. The weight for any host starts at 0, and the weighers order these hosts by adding to or subtracting from the weight assigned by the previous weigher. Weights may become negative. An instance will be scheduled to one of the N most-weighted hosts, where N is ‘scheduler_host_subset_size’. By default, this is set to all weighers that are included with Nova. If you wish to change this, replace this with a list of strings, where each element is the path to a weigher. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: None
`soft_affinity_weight_multiplier` = `1.0`	(Floating point) Multiplier used for weighing hosts for group soft-affinity. Only a positive value is meaningful. Negative means that the behavior will change to the opposite, which is soft-anti-affinity.
`soft_anti_affinity_weight_multiplier` = `1.0`	(Floating point) Multiplier used for weighing hosts for group soft-anti-affinity. Only a positive value is meaningful. Negative means that the behavior will change to the opposite, which is soft-affinity.
[cells]
`ram_weight_multiplier` = `10.0`	(Floating point) Ram weight multiplier Multiplier used for weighing ram. Negative numbers indicate that Compute should stack VMs on one host instead of spreading out new VMs to more hosts in the cell. Possible values: Numeric multiplier
`scheduler_filter_classes` = `nova.cells.filters.all_filters`	(List) Scheduler filter classes Filter classes the cells scheduler should use. An entry of “nova.cells.filters.all_filters” maps to all cells filters included with nova. As of the Mitaka release the following filter classes are available: Different cell filter: A scheduler hint of ‘different_cell’ with a value of a full cell name may be specified to route a build away from a particular cell. Image properties filter: Image metadata named ‘hypervisor_version_requires’ with a version specification may be specified to ensure the build goes to a cell which has hypervisors of the required version. If either the version requirement on the image or the hypervisor capability of the cell is not present, this filter returns without filtering out the cells. Target cell filter: A scheduler hint of ‘target_cell’ with a value of a full cell name may be specified to route a build to a particular cell. No error handling is done as there’s no way to know whether the full path is a valid. As an admin user, you can also add a filter that directs builds to a particular cell.
`scheduler_retries` = `10`	(Integer) Scheduler retries How many retries when no cells are available. Specifies how many times the scheduler tries to launch a new instance when no cells are available. Possible values: Positive integer value Related options: This value is used with the `scheduler_retry_delay` value while retrying to find a suitable cell.
`scheduler_retry_delay` = `2`	(Integer) Scheduler retry delay Specifies the delay (in seconds) between scheduling retries when no cell can be found to place the new instance on. When the instance could not be scheduled to a cell after `scheduler_retries` in combination with `scheduler_retry_delay`, then the scheduling of the instance failed. Possible values: Time in seconds. Related options: This value is used with the `scheduler_retries` value while retrying to find a suitable cell.
`scheduler_weight_classes` = `nova.cells.weights.all_weighers`	(List) Scheduler weight classes Weigher classes the cells scheduler should use. An entry of “nova.cells.weights.all_weighers” maps to all cell weighers included with nova. As of the Mitaka release the following weight classes are available: mute_child: Downgrades the likelihood of child cells being chosen for scheduling requests, which haven’t sent capacity or capability updates in a while. Options include mute_weight_multiplier (multiplier for mute children; value should be negative). ram_by_instance_type: Select cells with the most RAM capacity for the instance type being requested. Because higher weights win, Compute returns the number of available units for the instance type requested. The ram_weight_multiplier option defaults to 10.0 that adds to the weight by a factor of 10. Use a negative number to stack VMs on one host instead of spreading out new VMs to more hosts in the cell. weight_offset: Allows modifying the database to weight a particular cell. The highest weight will be the first cell to be scheduled for launching an instance. When the weight_offset of a cell is set to 0, it is unlikely to be picked but it could be picked if other cells have a lower weight, like if they’re full. And when the weight_offset is set to a very high value (for example, ‘999999999999999’), it is likely to be picked if another cell do not have a higher weight.
[metrics]
`required` = `True`	(Boolean) This setting determines how any unavailable metrics are treated. If this option is set to True, any hosts for which a metric is unavailable will raise an exception, so it is recommended to also use the MetricFilter to filter out those hosts before weighing. When this option is False, any metric being unavailable for a host will set the host weight to ‘weight_of_unavailable’. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: weight_of_unavailable
`weight_multiplier` = `1.0`	(Floating point) When using metrics to weight the suitability of a host, you can use this option to change how the calculated weight influences the weight assigned to a host as follows: Greater than 1.0: increases the effect of the metric on overall weight. Equal to 1.0: No change to the calculated weight. Less than 1.0, greater than 0: reduces the effect of the metric on overall weight. 0: The metric value is ignored, and the value of the ‘weight_of_unavailable’ option is returned instead. Greater than -1.0, less than 0: the effect is reduced and reversed. -1.0: the effect is reversed Less than -1.0: the effect is increased proportionally and reversed. Valid values are numeric, either integer or float. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: weight_of_unavailable
`weight_of_unavailable` = `-10000.0`	(Floating point) When any of the following conditions are met, this value will be used in place of any actual metric value: One of the metrics named in ‘weight_setting’ is not available for a host, and the value of ‘required’ is False. The ratio specified for a metric in ‘weight_setting’ is 0. The ‘weight_multiplier’ option is set to 0. This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: weight_setting required weight_multiplier
`weight_setting` =	(List) This setting specifies the metrics to be weighed and the relative ratios for each metric. This should be a single string value, consisting of a series of one or more ‘name=ratio’ pairs, separated by commas, where ‘name’ is the name of the metric to be weighed, and ‘ratio’ is the relative weight for that metric. Note that if the ratio is set to 0, the metric value is ignored, and instead the weight will be set to the value of the ‘weight_of_unavailable’ option. As an example, let’s consider the case where this option is set to: `name1=1.0, name2=-1.3` The final weight will be: `(name1.value * 1.0) + (name2.value * -1.3)` This option is only used by the FilterScheduler and its subclasses; if you use a different scheduler, this option has no effect. Related options: weight_of_unavailable