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