# Basic Offline Server Consolidation

## Synopsis

display name: `Basic offline consolidation`

goal: `server_consolidation`

> Good server consolidation strategy

> Basic offline consolidation using live migration

> Consolidation of VMs is essential to achieve energy optimization in cloud environments such as OpenStack. As VMs are spinned up and/or moved over time, it becomes necessary to migrate VMs among servers to lower the costs. However, migration of VMs introduces runtime overheads and consumes extra energy, thus a good server consolidation strategy should carefully plan for migration in order to both minimize energy consumption and comply to the various SLAs.

> This algorithm not only minimizes the overall number of used servers, but also minimizes the number of migrations.

> It has been developed only for tests. You must have at least 2 physical compute nodes to run it, so you can easily run it on DevStack. It assumes that live migration is possible on your OpenStack cluster.

## Requirements

### Metrics

The basic strategy requires the following metrics:

metric | service name | plugins | comment
--- | --- | --- | ---
`compute.node.cpu.percent` | ceilometer | none | need to set the `compute_monitors` option to `cpu.virt_driver` in the nova.conf.
`cpu` | ceilometer | none |

### Cluster data model

Default Watcher’s Compute cluster data model:

> Nova cluster data model collector

> The Nova cluster data model collector creates an in-memory representation of the resources exposed by the compute service.

### Actions

Default Watcher’s actions:

> action | description
> --- | ---

> `migration`

> Migrates a server to a destination nova-compute host

> This action will allow you to migrate a server to another compute destination host. Migration type ‘live’ can only be used for migrating active VMs. Migration type ‘cold’ can be used for migrating non-active VMs as well active VMs, which will be shut down while migrating.

> The action schema is:

>     schema = Schema({
>      'resource_id': str,  # should be a UUID
>      'migration_type': str,  # choices -> "live", "cold"
>      'destination_node': str,
>      'source_node': str,
>     })

> The resource_id is the UUID of the server to migrate. The source_node and destination_node parameters are respectively the source and the destination compute hostname.

> Note

> Nova API version must be 2.56 or above if destination_node parameter is given.

> `change_nova_service_state`

> Disables or enables the nova-compute service, deployed on a host

> By using this action, you will be able to update the state of a nova-compute service. A disabled nova-compute service can not be selected by the nova scheduler for future deployment of server.

> The action schema is:

>     schema = Schema({
>      'resource_id': str,
>      'state': str,
>      'disabled_reason': str,
>     })

> The resource_id references a nova-compute service name. The state value should either be up or down. The disabled_reason references the reason why Watcher disables this nova-compute service. The value should be with watcher_ prefix, such as watcher_disabled, watcher_maintaining.

### Planner

Default Watcher’s planner:

> Weight planner implementation

> This implementation builds actions with parents in accordance with weights. Set of actions having a higher weight will be scheduled before the other ones. There are two config options to configure: action_weights and parallelization.

> Limitations

> - This planner requires to have action_weights and parallelization configs tuned well.

## Configuration

Strategy parameter is:

parameter | type | default Value | description
--- | --- | --- | ---
`migration_attempts` | Number | 0 | Maximum number of combinations to be tried by the strategy while searching for potential candidates. To remove the limit, set it to 0
`period` | Number | 7200 | The time interval in seconds for getting statistic aggregation from metric data source

## Efficacy Indicator

    [{'name': 'released_nodes_ratio', 'description': 'Ratio of released compute nodes divided by the total number of enabled compute nodes.', 'unit': '%', 'value': 0}]

## How to use it ?

    $ openstack optimize audittemplate create \
      at1 server_consolidation --strategy basic

    $ openstack optimize audit create -a at1 -p migration_attempts=4

## External Links

None.

this page last updated: 2026-04-01 21:51:00

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug