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 it. Few of them are
cinder-manage service list
the output will look like that
Binary Host Zone Status State Updated At RPC Version Object Version Cluster cinder-scheduler controller-server nova enabled :-) 2017-10-15 19:45:37 4.5 4.5 cinder-volume controller-server@ceph nova enabled :-) 2017-10-15 19:45:31 4.6 4.6
The 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.
If you have multiple backends for cinder, or use multiple cinder-scheduler/cinder-volume on multiple controller nodes. The output will look like this
Binary Host Zone Status State Updated At RPC Version Object Version Cluster cinder-scheduler controller-server1 nova enabled :-) 2017-10-15 19:45:37 4.5 4.5 cinder-volume controller-server1@ceph nova enabled :-) 2017-10-15 19:45:31 4.6 4.6 cinder-volume controller-server1@ceph2 nova enabled :-) 2017-10-15 19:45:31 4.6 4.6 cinder-scheduler controller-server2 nova enabled :-) 2017-10-15 19:45:37 4.5 4.65 cinder-volume controller-server2@ceph nova enabled XX 2017-10-15 19:45:37 4.6 4.6
As 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
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
cinder-manage service remove cinder-scheduler controller-server2 cinder-manage service remove cinder-volume controller-server2
If this small use case got you excited, check out the following uses as well
cinder-manage logs errors cinder-manage logs syslog cinder-manage volume delete --> Important in the case of stuck volumes cinder-manage host list cinder-manage config list --> you can use it to verify what the running configuration for cinder is
The manual for cinder-manage is at
Have fun !