diff --git a/doc/src/docbkx/openstack-compute-admin/computeadmin.xml b/doc/src/docbkx/openstack-compute-admin/computeadmin.xml
index c04a4d4c6b..3aacf4f8de 100644
--- a/doc/src/docbkx/openstack-compute-admin/computeadmin.xml
+++ b/doc/src/docbkx/openstack-compute-admin/computeadmin.xml
@@ -1364,14 +1364,14 @@ Migration of i-00000001 initiated. Check its progress using euca-describe-instan
A disaster could happen to several components of your architecture : a disk crash,
a network loss, a power cut... In our scenario, we suppose the following setup :
- A cloud controller (nova-api, nova-objecstore, nova-volumes,
+ A cloud controller (nova-api, nova-objecstore, nova-volume,
nova-network)
A compute node (nova-compute)
- - A Storage Area Network used by nova-volumes (aka SAN)
+ A Storage Area Network used by nova-volumes (aka SAN)
Our disaster will be the worst one : a power loss. That power loss
applies to the three components. Let's see what runs and how
@@ -1382,7 +1382,7 @@ Migration of i-00000001 initiated. Check its progress using euca-describe-instan
From the cloud controller to the compute node we also have active
- iscsi sessions (managed by nova-volumes).
+ iscsi sessions (managed by nova-volume).
For every volume an iscsi session is made (so 14 ebs volumes equals 14
@@ -1562,7 +1562,7 @@ Migration of i-00000001 initiated. Check its progress using euca-describe-instan
intances' fstab file.
- Do not add into the nova-volumes' fstab file the entry for the SAN's
+ Do not add into the nova-volume's fstab file the entry for the SAN's
disks.
Some systems would hang on that step, which means you could loose
access to your cloud-controller. In order to re-run the session