nova-manage¶

Perform data migration to update all live data.

--max-count controls the maximum number of objects to migrate in a given call. If not specified, migration will occur in batches of 50 until fully complete.

Returns exit code 0 if no (further) updates are possible, 1 if the --max-count option was used and some updates were completed successfully (even if others generated errors), 2 if some updates generated errors and no other migrations were able to take effect in the last batch attempted, or 127 if invalid input is provided (e.g. non-numeric max-count).

This command should be called after upgrading database schema and nova services on all controller nodes. If it exits with partial updates (exit status 1) it should be called again, even if some updates initially generated errors, because some updates may depend on others having completed. If it exits with status 2, intervention is required to resolve the issue causing remaining updates to fail. It should be considered successfully completed only when the exit status is 0.

For example:

$ nova-manage db online_data_migrations
Running batches of 50 until complete
2 rows matched query migrate_instances_add_request_spec, 0 migrated
2 rows matched query populate_queued_for_delete, 2 migrated
+---------------------------------------------+--------------+-----------+
|                  Migration                  | Total Needed | Completed |
+---------------------------------------------+--------------+-----------+
|         create_incomplete_consumers         |      0       |     0     |
| delete_build_requests_with_no_instance_uuid |      0       |     0     |
|      migrate_instances_add_request_spec     |      2       |     0     |
|          migrate_keypairs_to_api_db         |      0       |     0     |
|       migrate_quota_classes_to_api_db       |      0       |     0     |
|        migrate_quota_limits_to_api_db       |      0       |     0     |
|          migration_migrate_to_uuid          |      0       |     0     |
|     populate_missing_availability_zones     |      0       |     0     |
|          populate_queued_for_delete         |      2       |     2     |
|                populate_uuids               |      0       |     0     |
|     service_uuids_online_data_migration     |      0       |     0     |
+---------------------------------------------+--------------+-----------+

In the above example, the migrate_instances_add_request_spec migration found two candidate records but did not need to perform any kind of data migration for either of them. In the case of the populate_queued_for_delete migration, two candidate records were found which did require a data migration. Since --max-count defaults to 50 and only two records were migrated with no more candidates remaining, the command completed successfully with exit code 0.

Perform the ironic flavor migration process against the database while services are offline. This is not recommended for most people. The ironic compute driver will do this online and as necessary if run normally. This routine is provided only for advanced users that may be skipping the 16.0.0 Pike release, never able to run services normally at the Pike level. Since this utility is for use when all services (including ironic) are down, you must pass the resource class set on your node(s) with the --resource_class parameter.

To migrate a specific host and node, provide the hostname and node uuid with --host $hostname --node $uuid. To migrate all instances on nodes managed by a single host, provide only --host. To iterate over all nodes in the system in a single pass, use --all. Note that this process is not lightweight, so it should not be run frequently without cause, although it is not harmful to do so. If you have multiple cellsv2 cells, you should run this once per cell with the corresponding cell config for each (i.e. this does not iterate cells automatically).

Note that this is not recommended unless you need to run this specific data migration offline, and it should be used with care as the work done is non-trivial. Running smaller and more targeted batches (such as specific nodes) is recommended.

Upgrade the API database schema up to the most recent version or [VERSION] if specified. This command does not create the API database, it runs schema migration scripts. The API database connection is determined by [api_database]/connection in the configuration file passed to nova-manage.

Starting in the 18.0.0 Rocky release, this command will also upgrade the optional placement database if [placement_database]/connection is configured.

Map instances to the provided cell. Instances in the nova database will be queried from oldest to newest and mapped to the provided cell. A max_count can be set on the number of instance to map in a single run. Repeated runs of the command will start from where the last run finished so it is not necessary to increase max-count to finish. A reset option can be passed which will reset the marker, thus making the command start from the beginning as opposed to the default behavior of starting from where the last run finished. Returns 0 if all instances have been mapped, and 1 if there are still instances to be mapped.

If --max-count is not specified, all instances in the cell will be mapped in batches of 50. If you have a large number of instances, consider specifying a custom value and run the command until it exits with 0.

Create a cell mapping to the database connection and message queue transport url. If a database_connection is not specified, it will use the one defined by [database]/connection in the configuration file passed to nova-manage. If a transport_url is not specified, it will use the one defined by [DEFAULT]/transport_url in the configuration file. The verbose option will print out the resulting cell mapping uuid. All the cells created are by default enabled. However passing the --disabled option can create a pre-disabled cell, meaning no scheduling will happen to this cell. The meaning of the various exit codes returned by this command are explained below:

• Returns 0 if the cell mapping was successfully created.
• Returns 1 if the transport url or database connection was missing or invalid.
• Returns 2 if another cell is already using that transport url and/or database connection combination.

Updates the properties of a cell by the given uuid. If a database_connection is not specified, it will attempt to use the one defined by [database]/connection in the configuration file. If a transport_url is not specified, it will attempt to use the one defined by [DEFAULT]/transport_url in the configuration file. The meaning of the various exit codes returned by this command are explained below:

• If successful, it will return 0.
• If the cell is not found by the provided uuid, it will return 1.
• If the properties cannot be set, it will return 2.
• If the provided transport_url or/and database_connection is/are same as another cell, it will return 3.
• If an attempt is made to disable and enable a cell at the same time, it will return 4.
• If an attempt is made to disable or enable cell0 it will return 5.

Delete a host by the given host name and the given cell uuid. Returns 0 if the empty host is found and deleted successfully, 1 if a cell with that uuid could not be found, 2 if a host with that name could not be found, 3 if a host with that name is not in a cell with that uuid, 4 if a host with that name has instances (host not empty).

Iterates over non-cell0 cells looking for instances which do not have allocations in the Placement service and which are not undergoing a task state transition. For each instance found, allocations are created against the compute node resource provider for that instance based on the flavor associated with the instance.

There is also a special case handled for instances that do have allocations created before Placement API microversion 1.8 where project_id and user_id values were required. For those types of allocations, the project_id and user_id are updated using the values from the instance.

Specify --max-count to control the maximum number of instances to process. If not specified, all instances in each cell will be mapped in batches of 50. If you have a large number of instances, consider specifying a custom value and run the command until it exits with 0 or 4.

Specify --verbose to get detailed progress output during execution.

Specify --dry-run to print output but not commit any changes. The return code should be 4.

Specify --instance to process a specific instance given its UUID. If specified the --max-count option has no effect.

This command requires that the [api_database]/connection and [placement] configuration options are set. Placement API >= 1.28 is required.

Return codes:

• 0: Command completed successfully and allocations were created.
• 1: –max-count was reached and there are more instances to process.
• 2: Unable to find a compute node record for a given instance.
• 3: Unable to create (or update) allocations for an instance against its compute node resource provider.
• 4: Command completed successfully but no allocations were created.
• 127: Invalid input.

Mirrors compute host aggregates to resource provider aggregates in the Placement service. Requires the [api_database] and [placement] sections of the nova configuration file to be populated.

Specify --verbose to get detailed progress output during execution.

Return codes:

• 0: Successful run
• 1: A host was found with more than one matching compute node record
• 2: An unexpected error occurred while working with the placement API
• 3: Failed updating provider aggregates in placement
• 4: Host mappings not found for one or more host aggregate members
• 5: Compute node records not found for one or more hosts
• 6: Resource provider not found by uuid for a given host