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.
+