diff --git a/doc/src/docbkx/common/getstart.xml b/doc/src/docbkx/common/getstart.xml
index a0dbd38463..3bf18f6c95 100644
--- a/doc/src/docbkx/common/getstart.xml
+++ b/doc/src/docbkx/common/getstart.xml
@@ -116,7 +116,7 @@
                         that let’s you choose (or write) your own algorithm for scheduling.
                         Currently, there are several to choose from (simple, chance, etc) and it is
                         a area of hot development for the future releases of OpenStack
-                        Compute.</para></listitem><listitem><para>The <code>nova-compute</code> process is primarily a worker daemon that creates and terminates virtual machine instances. The process by which it does so is fairly complex (<link xlink:href="http://www.laurentluce.com/?p=227">see this blog post by Laurence Luce for the gritty details</link>) but the basics are simple: accept actions from the queue and then perform a series of system commands (like launching a KVM instance) to carry them out while updating state in the database.</para></listitem><listitem><para>As you can gather by the name, <code>nova-volume</code> manages the creation, attaching and detaching of persistent volumes to compute instances (similar functionality to <link xlink:href="http://aws.amazon.com/ebs/">Amazon’s Elastic Block Storage</link>). It can use volumes from a variety of providers such as iSCSI or AoE.</para></listitem><listitem><para>The <code>nova-network</code> worker daemon is very similar to <code>nova-compute</code> and <code>nova-volume</code>. It accepts networking tasks from the queue and then performs tasks to manipulate the network (such as setting up bridging interfaces or changing <code>iptables</code> rules).</para></listitem><listitem><para>The queue provides a central hub for passing messages between daemons. This is currently implemented with <link xlink:href="http://www.rabbitmq.com/">RabbitMQ</link> today, but theoretically could be any <link xlink:href="http://www.amqp.org/confluence/display/AMQP/Advanced+Message+Queuing+Protocol">AMPQ message queue</link> supported by the python <link xlink:href="http://barryp.org/software/py-amqplib/">ampqlib</link>.</para></listitem><listitem><para>The <link xlink:href="http://en.wikipedia.org/wiki/SQL">SQL database</link> stores most of the
+                        Compute.</para></listitem><listitem><para>The <code>nova-compute</code> process is primarily a worker daemon that creates and terminates virtual machine instances. The process by which it does so is fairly complex (<link xlink:href="http://www.laurentluce.com/?p=227">see this blog post by Laurence Luce for the gritty details</link>) but the basics are simple: accept actions from the queue and then perform a series of system commands (like launching a KVM instance) to carry them out while updating state in the database.</para></listitem><listitem><para>As you can gather by the name, <code>nova-volume</code> manages the creation, attaching and detaching of persistent volumes to compute instances (similar functionality to <link xlink:href="http://aws.amazon.com/ebs/">Amazon’s Elastic Block Storage</link>). It can use volumes from a variety of providers, such as iSCSI.</para></listitem><listitem><para>The <code>nova-network</code> worker daemon is very similar to <code>nova-compute</code> and <code>nova-volume</code>. It accepts networking tasks from the queue and then performs tasks to manipulate the network (such as setting up bridging interfaces or changing <code>iptables</code> rules).</para></listitem><listitem><para>The queue provides a central hub for passing messages between daemons. This is currently implemented with <link xlink:href="http://www.rabbitmq.com/">RabbitMQ</link> today, but theoretically could be any <link xlink:href="http://www.amqp.org/confluence/display/AMQP/Advanced+Message+Queuing+Protocol">AMPQ message queue</link> supported by the python <link xlink:href="http://barryp.org/software/py-amqplib/">ampqlib</link>.</para></listitem><listitem><para>The <link xlink:href="http://en.wikipedia.org/wiki/SQL">SQL database</link> stores most of the
                         build-time and run-time state for a cloud infrastructure. This includes the
                         instance types that are available for use, instances in use, networks
                         available and projects. Theoretically, OpenStack Compute can support any
diff --git a/doc/src/docbkx/openstack-compute-admin/computeconfigure.xml b/doc/src/docbkx/openstack-compute-admin/computeconfigure.xml
index 3176d107ae..c724eeeba6 100644
--- a/doc/src/docbkx/openstack-compute-admin/computeconfigure.xml
+++ b/doc/src/docbkx/openstack-compute-admin/computeconfigure.xml
@@ -656,7 +656,7 @@ sudo bash -c "echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra"</literallayout>
                         </listitem>
                         <listitem>
                             <para><emphasis role="bold">Instances:</emphasis> Instance can 
-                            be migrated with ISCSI/AoE based volumes</para>
+                            be migrated with ISCSI based volumes</para>
                         </listitem>
                         <listitem>
                             <para><emphasis role="bold">Hypervisor:</emphasis>