cinder-manage — cinder 24.1.0.dev93 documentation (2024)

Cinder Quota¶

Cinder quotas sometimes run out of sync, and while there are some mechanismsin place in Cinder that, with the proper configuration, try to do a resyncof the quotas, they are not perfect and are susceptible to race conditions,so they may result in less than perfect accuracy in refreshed quotas.

The cinder-manage quota commands are meant to help manage these issues whileallowing a finer control of when and what quotas are fixed.

Checking if quotas and reservations are correct.

cinder-manage quota check [-h] [--project-id PROJECT_ID]

Accepted arguments are:

--project-id PROJECT_ID The ID of the project where we want to sync the quotas (defaults to all projects).

This command checks quotas and reservations, for a specific project (passing--project-id) or for all projects, to see if they are out of sync.

The check will also look for duplicated entries.

One way to use this action in combination with the sync action is to run thecheck for all projects, take note of those that are out of sync, and the syncthem one by one at intervals to allow cinder to operate semi-normally.

Fixing quotas and reservations

cinder-manage quota sync [-h] [--project-id PROJECT_ID]

Accepted arguments are:

--project-id PROJECT_ID The ID of the project where we want to sync the quotas (defaults to all projects).

This command refreshes existing quota usage and reservation count for aspecific project or for all projects.

The refresh will also remove duplicated entries.

This operation is best executed when Cinder is not running, but it canbe run with cinder services running as well.

A different transaction is used for each project’s quota sync, so an actionfailure will only rollback the current project’s changes.

Cinder Db¶

cinder-manage db version

Print the current database version.

cinder-manage db sync [--bump-versions] [version]

Sync the database up to the most recent version. This is the standard way tocreate the db as well.

This command interprets the following options when it is invoked:

version Database version

--bump-versions

Update RPC and Objects versions when doing offlineupgrades, with this we no longer need to restart theservices twice after the upgrade to prevent ServiceTooOldexceptions.

cinder-manage db purge [<number of days>]

Purge database entries that are marked as deleted, that are older than thenumber of days specified.

cinder-manage db online_data_migrations [--max_count <n>]

Perform online data migrations for database upgrade between releases inbatches.

This command interprets the following options when it is invoked:

--max_count Maximum number of objects to migrate. If not specified, all possible migrations will be completed, in batches of 50 at a time.

Returns exit status 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 noother migrations were able to take effect in the last batch attempted, or 127if invalid input is provided (e.g. non-numeric max-count).

This command should be run after upgrading the database schema. If it exitswith partial updates (exit status 1) it should be called again, even if someupdates initially generated errors, because some updates may depend on othershaving completed. If it exits with status 2, intervention is required toresolve the issue causing remaining updates to fail. It should be consideredsuccessfully completed only when the exit status is 0.

Cinder Logs¶

cinder-manage logs errors

Displays cinder errors from log files.

cinder-manage logs syslog [<number>]

Displays cinder the most recent entries from syslog. The optional numberargument specifies the number of entries to display (default 10).

Cinder Volume¶

cinder-manage volume delete <volume_id>

Delete a volume without first checking that the volume is available.

cinder-manage volume update_host --currenthost <current host>--newhost <new host>

Updates the host name of all volumes currently associated with a specifiedhost.

Cinder Host¶

cinder-manage host list [<zone>]

Displays a list of all physical hosts and their zone. The optional zoneargument allows the list to be filtered on the requested zone.

Cinder Service¶

cinder-manage service list

Displays a list of all cinder services and their host, zone, status, state andwhen the information was last updated.

cinder-manage service remove <service> <host>

Removes a specified cinder service from a specified host.

Cinder Backup¶

cinder-manage backup list

Displays a list of all backups (including ones in progress) and the host onwhich the backup operation is running.

cinder-manage backup update_backup_host --currenthost <current host>--newhost <new host>

Updates the host name of all backups currently associated with a specifiedhost.

Cinder Version¶

cinder-manage version list

Displays the codebase version cinder is running upon.

Cinder Config¶

cinder-manage config list [<param>]

Displays the current configuration parameters (options) for Cinder. Theoptional flag parameter may be used to display the configuration of oneparameter.

Cinder Util¶

cinder-manage util clean_locks [-h] [--services-offline]

Clean file locks on the current host that were created and are used by driversand cinder services for volumes, snapshots, and the backup service on thecurrent host.

Should be run on any host where we are running a Cinder service (API,Scheduler, Volume, Backup) and can be run with the Cinder services running orstopped.

If the services are running it will check existing resources in the Cinderdatabase in order to only remove resources that are no longer present (it’ssafe to delete the files).

For backups, the way to know if we can remove the startup lock is by checkingif the PGRP in the file name is currently running cinder-backup.

Deleting locks while the services are offline is faster as there’s no need tocheck the database or the running processes.

Default assumes that services are online, must pass --services-offline tospecify that they are offline.

The common use case for running the command with --services-offline is tobe called on startup as a service unit before any cinder service is started.Command will be usually called without the --services-offline parametermanually or from a cron job.