A tool that’s less known-about for cinder is cinder-manage. You might have run into it during upgrades. The most common use case is<\/p>\n
cinder-manage db sync<\/pre>\nThis is normally executed during upgrades to bring the database to the latest version, or to create the schema for a new installation. But there’s actually additional usages for it. Few of them are<\/p>\n
cinder-manage service list<\/pre>\nthe output will look like that<\/p>\n
Binary Host Zone Status State Updated At RPC Version Object Version Cluster \ncinder-scheduler controller-server nova enabled :-) 2017-10-15 19:45:37 4.5 4.5 \ncinder-volume controller-server@ceph nova enabled :-) 2017-10-15 19:45:31 4.6 4.6<\/pre>\nThe output can be used to diagnose issues when cinder-scheduler reports that the volume backend is down although cinder-volume is up. The output of the above command is the only reliable source to show how cinder-scheduler, cinder-volume and cinder-backup status is.<\/p>\n
If you have multiple backends for cinder, or use multiple cinder-scheduler\/cinder-volume on multiple controller nodes. The output will look like this<\/p>\n
Binary Host Zone Status State Updated At RPC Version Object Version Cluster \ncinder-scheduler controller-server1 nova enabled :-) 2017-10-15 19:45:37 4.5 4.5 \ncinder-volume controller-server1@ceph nova enabled :-) 2017-10-15 19:45:31 4.6 4.6\ncinder-volume controller-server1@ceph2 nova enabled :-) 2017-10-15 19:45:31 4.6 4.6\ncinder-scheduler controller-server2 nova enabled :-) 2017-10-15 19:45:37 4.5 4.65\ncinder-volume controller-server2@ceph nova enabled XX 2017-10-15 19:45:37 4.6 4.6<\/pre>\nAs you can see above, there are multiple backends for cinder-volume on controller-server1. One of them is ceph and the other is ceph2 and both are enabled and up. It’s easy to spot that cinder-volume on the controller-server2 is showing as down, so you should expect the ceph backend to not be available. If you check the cinder-volume service using systemctl status, the service itself might be running. If that is the case you need to look deeper to why the ceph backend for cinder-volume is down<\/p>\n
If you decide to remove a certain cinder-volume\/cinder-scheduler\/cinder-backup service from your deployment, you can do that by stopping the service on the controller host, and then removing it using<\/p>\n
cinder-manage service remove cinder-scheduler controller-server2\ncinder-manage service remove cinder-volume controller-server2<\/pre>\nIf this small use case got you excited, check out the following uses as well<\/p>\n
cinder-manage logs errors\ncinder-manage logs syslog\ncinder-manage volume delete --> Important in the case of stuck volumes\ncinder-manage host list\ncinder-manage config list --> you can use it to verify what the running configuration for cinder is<\/pre>\nThe manual for cinder-manage is at<\/p>\n
https:\/\/docs.openstack.org\/cinder\/latest\/man\/cinder-manage.html<\/a><\/p>\n
Have fun !<\/p>\n","protected":false},"excerpt":{"rendered":"
A tool that’s less known-about for cinder is cinder-manage. You might have run into it during upgrades. The most common use case is cinder-manage db sync This is normally executed during upgrades to bring the database to the latest version, or to create the schema for a new installation. But there’s actually additional usages for