diff --git a/doc/admin-guide-cloud/ch_blockstorage.xml b/doc/admin-guide-cloud/ch_blockstorage.xml index 5ec4728c7b..0897b3327a 100644 --- a/doc/admin-guide-cloud/ch_blockstorage.xml +++ b/doc/admin-guide-cloud/ch_blockstorage.xml @@ -119,6 +119,7 @@ +
Troubleshoot your installation diff --git a/doc/admin-guide-cloud/section_glusterfs_removal.xml b/doc/admin-guide-cloud/section_glusterfs_removal.xml new file mode 100644 index 0000000000..df51384f42 --- /dev/null +++ b/doc/admin-guide-cloud/section_glusterfs_removal.xml @@ -0,0 +1,34 @@ + +
+ Gracefully remove a GlusterFS volume from usage + Configuring the cinder volume + service to use GlusterFS involves creating a shares file (for + example, /etc/cinder/glusterfs). This + shares file lists each GlusterFS volume (with its + corresponding storage server) that the + cinder volume service can use for + back end storage. + To remove a GlusterFS volume from usage as a back end, + delete the volume's corresponding entry from the shares file. + After doing so, restart the Block Storage services. + To restart the + Block Storage services on CentOS, Fedora, openSUSE, Red Hat + Enterprise Linux, or SUSE Linux Enterprise, run: + # for i in api scheduler volume; do service openstack-cinder-$i restart; done + To restart the Block Storage services + on Ubuntu or Debian, run: + # for i in api scheduler volume; do service cinder-${i} restart; done + Restarting the Block Storage services will prevent + the cinder volume service from + exporting the deleted GlusterFS volume. This will prevent + any instances from mounting the volume from that point + onwards. + However, the removed GlusterFS volume might still be + mounted on an instance at this point. Typically, this is the + case when the volume was already mounted while its entry was + deleted from the shares file. Whenever this occurs, you + will have to unmount the volume as normal after the Block + Storage services are restarted. +