nova-manage(1)

. .

.

\\$1 \\n[an-margin] level \\n[rst2man-indent-level] level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] - \\n[rst2man-indent0] \\n[rst2man-indent1] \\n[rst2man-indent2]

. RS \\$1 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] . nr rst2man-indent-level +1

. RE

nova-manage - Management tool for the OpenStack Compute services.

nova-manage [ [...]]

nova-manage controls cloud computing instances by managing various admin-only aspects of Nova.

The standard pattern for executing a nova-manage command is:

nova-manage []

Run without arguments to see a list of available command categories:

nova-manage

You can also run with a category argument such as db to see a list of all commands in that category:

nova-manage db

These options apply to all commands and may be given in any order, before or after commands. Individual commands may provide additional options. Options without an argument can be combined after a single dash.

Show a help message and exit

Path to a config directory to pull *.conf files from. This file set is sorted, so as to provide a predictable parse order if individual options are over-ridden. The set is parsed after the file(s) specified via previous \%--config-file, arguments hence over-ridden options in the directory take precedence. This option must be set from the command-line.

Path to a config file to use. Multiple config files can be specified, with values in later files taking precedence. Defaults to None. This option must be set from the command-line.

The name of a logging configuration file. This file is appended to any existing logging configuration files. For details about logging configuration files, see the Python logging module documentation. Note that when logging configuration files are used then all logging configuration is set in the configuration file and other logging configuration options are ignored (for example, \%--log-date-format).

Defines the format string for %(asctime)s in log records. Default: None. This option is ignored if \%--log-config-append is set.

The base directory used for relative log_file paths. This option is ignored if \%--log-config-append is set.

Name of log file to send logging output to. If no default is set, logging will go to stderr as defined by use_stderr. This option is ignored if \%--log-config-append is set.

Syslog facility to receive log lines. This option is ignored if \%--log-config-append is set.

Enable journald for logging. If running in a systemd environment you may wish to enable journal support. Doing so will use the journal native protocol which includes structured metadata in addition to log messages. This option is ignored if \%--log-config-append is set.

The inverse of \%--use-journal.

Use JSON formatting for logging. This option is ignored if \%--log-config-append is set.

The inverse of \%--use-json.

Use syslog for logging. Existing syslog format is DEPRECATED and will be changed later to honor RFC5424. This option is ignored if \%--log-config-append is set.

The inverse of \%--use-syslog.

Uses logging handler designed to watch file system. When log file is moved or removed this handler will open a new log file with specified path instantaneously. It makes sense only if \%--log-file option is specified and Linux platform is used. This option is ignored if \%--log-config-append is set.

The inverse of \%--watch-log-file.

If enabled, the logging level will be set to DEBUG instead of the default INFO level.

The inverse of \%--debug.

Allow post-mortem debugging.

The inverse of \%--post-mortem.

Show program\(aqs version number and exit

nova-manage db version

Print the current main database version.

nova-manage db sync [--local_cell] [VERSION]

Upgrade the main database schema up to the most recent version or VERSION if specified. By default, this command will also attempt to upgrade the schema for the cell0 database if it is mapped. If \%--local_cell is specified, then only the main database in the current cell is upgraded. The local database connection is determined by \%database.connection in the configuration file, passed to nova-manage using the --config-file option(s).

Refer to the nova-manage cells_v2 map_cell0 or nova-manage cells_v2 simple_cell_setup commands for more details on mapping the cell0 database.

This command should be run after nova-manage api_db sync.

Options

Only sync db in the local cell: do not attempt to fan-out to all cells.

Return codes

center; |l|l|. _ T{ Return code T} T{ Description T} _ T{ 0 T} T{ Successfully synced database schema. T} _ T{ 1 T} T{ Failed to access cell0. T} _

Changed in version 20.0.0: (Train)

Removed support for the legacy --version argument.

Changed in version 24.0.0: (Xena)

Migrated versioning engine to alembic. The optional VERSION argument is now expected to be an alembic-based version. sqlalchemy-migrate-based versions will be rejected.

nova-manage db archive_deleted_rows [--max_rows ] [--verbose] [--until-complete] [--before ] [--purge] [--all-cells] [--task-log] [--sleep]

Move deleted rows from production tables to shadow tables. Note that the corresponding rows in the instance_mappings, request_specs and instance_group_member tables of the API database are purged when instance records are archived and thus, \%api_database.connection is required in the config file.

If automating, this should be run continuously while the result is 1, stopping at 0, or use the \%--until-complete option.

Changed in version 24.0.0: (Xena)

Added \%--task-log, \%--sleep options.

Options

Maximum number of deleted rows to archive. Defaults to 1000. Note that this number does not include the corresponding rows, if any, that are removed from the API database for deleted instances.

Archive rows that have been deleted before . Accepts date strings in the default format output by the date command, as well as YYYY-MM-DD[HH:mm:ss]. For example:

# Purge shadow table rows older than a specific date nova-manage db archive --before 2015-10-21 # or nova-manage db archive --before \(dqOct 21 2015\(dq # Times are also accepted nova-manage db archive --before \(dq2015-10-21 12:00\(dq

Note that relative dates (such as yesterday) are not supported natively. The date command can be helpful here:

# Archive deleted rows more than one month old nova-manage db archive --before \(dq$(date -d \(aqnow - 1 month\(aq)\(dq

Print how many rows were archived per table.

Run continuously until all deleted rows are archived. Use \%--max_rows as a batch size for each iteration.

Purge all data from shadow tables after archive completes.

Run command across all cells.

Also archive task_log table records. Note that task_log records are never deleted, so archiving them will move all of the task_log records up to now into the shadow tables. It is recommended to also specify the \%--before option to avoid races for those consuming task_log record data via the \%/os-instance_usage_audit_log API (example: Telemetry).

The amount of time in seconds to sleep between batches when \%--until-complete is used. Defaults to 0.

Return codes

center; |l|l|. _ T{ Return code T} T{ Description T} _ T{ 0 T} T{ Nothing was archived. T} _ T{ 1 T} T{ Some number of rows were archived. T} _ T{ 2 T} T{ Invalid value for \%--max_rows. T} _ T{ 3 T} T{ No connection to the API database could be established using \%api_database.connection. T} _ T{ 4 T} T{ Invalid value for \%--before. T} _ T{ 255 T} T{ An unexpected error occurred. T} _

nova-manage db purge [--all] [--before ] [--verbose] [--all-cells]

Delete rows from shadow tables. For \%--all-cells to work, the API database connection information must be configured.

New in version 18.0.0: (Rocky)

Options

Purge all rows in the shadow tables.

Delete data that was archived before . Accepts date strings in the default format output by the date command, as well as YYYY-MM-DD[HH:mm:ss]. For example:

# Purge shadow table rows older than a specific date nova-manage db purge --before 2015-10-21 # or nova-manage db purge --before \(dqOct 21 2015\(dq # Times are also accepted nova-manage db purge --before \(dq2015-10-21 12:00\(dq

Note that relative dates (such as yesterday) are not supported natively. The date command can be helpful here:

# Archive deleted rows more than one month old nova-manage db purge --before \(dq$(date -d \(aqnow - 1 month\(aq)\(dq

Print information about purged records.

Run against all cell databases.

Return codes

center; |l|l|. _ T{ Return code T} T{ Description T} _ T{ 0 T} T{ Rows were deleted. T} _ T{ 1 T} T{ Required arguments were not provided. T} _ T{ 2 T} T{ Invalid value for \%--before. T} _ T{ 3 T} T{ Nothing was purged. T} _ T{ 4 T} T{ No connection to the API database could be established using \%api_database.connection. T} _

nova-manage db online_data_migrations [--max-count ]

Perform data migration to update all live data.

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 | | migrate_instances_add_request_spec | 2 | 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 | +---------------------------------------------+--------------+-----------+

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.

New in version 13.0.0: (Mitaka)

Options

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.

Return codes

center; |l|l|. _ T{ Return code T} T{ Description T} _ T{ 0 T} T{ No (further) updates are possible. T} _ T{ 1 T} T{ Some updates were completed successfully. Note that not all updates may have succeeded. T} _ T{ 2 T} T{ Some updates generated errors and no other migrations were able to take effect in the last batch attempted. T} _ T{ 127 T} T{ Invalid input was provided. T} _

nova-manage api_db version

Print the current API database version.

New in version 2015.1.0: (Kilo)

nova-manage api_db sync [VERSION]

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.

This command should be run before nova-manage db sync.

New in version 2015.1.0: (Kilo)