@@ -202,8 +202,8 @@ process to a file in ``LOGDIR``.

         LOGDIR=$DEST/logs

-*Note the use of ``DEST`` to locate the main install directory; this

-is why we suggest setting it in ``local.conf``.*

+Note the use of ``DEST`` to locate the main install directory; this

+is why we suggest setting it in ``local.conf``.

 Enabling Syslog

 ~~~~~~~~~~~~~~~

@@ -239,15 +239,15 @@ Database Backend

 Multiple database backends are available. The available databases are defined

 in the lib/databases directory.

-`mysql` is the default database, choose a different one by putting the

-following in the `localrc` section:

+``mysql`` is the default database, choose a different one by putting the

+following in the ``localrc`` section:

    ::

       disable_service mysql

       enable_service postgresql

-`mysql` is the default database.

+``mysql`` is the default database.

 RPC Backend

 -----------

@@ -260,6 +260,7 @@ RabbitMQ is handled via the usual service functions and

 Example disabling RabbitMQ in ``local.conf``:

 ::

+

     disable_service rabbit

@@ -511,7 +512,7 @@ VM. When running with only one replica the account, container and

 object services will run directly in screen. The others services like

 replicator, updaters or auditor runs in background.

-If you would like to enable Swift you can add this to your `localrc`

+If you would like to enable Swift you can add this to your ``localrc``

 section:

 ::

@@ -519,7 +520,7 @@ section:

     enable_service s-proxy s-object s-container s-account

 If you want a minimal Swift install with only Swift and Keystone you

-can have this instead in your `localrc` section:

+can have this instead in your ``localrc`` section:

 ::

@@ -528,24 +529,24 @@ can have this instead in your `localrc` section:

 If you only want to do some testing of a real normal swift cluster

 with multiple replicas you can do so by customizing the variable

-`SWIFT_REPLICAS` in your `localrc` section (usually to 3).

+``SWIFT_REPLICAS`` in your ``localrc`` section (usually to 3).

 Swift S3

 ++++++++

-If you are enabling `swift3` in `ENABLED_SERVICES` DevStack will

+If you are enabling ``swift3`` in ``ENABLED_SERVICES`` DevStack will

 install the swift3 middleware emulation. Swift will be configured to

 act as a S3 endpoint for Keystone so effectively replacing the

-`nova-objectstore`.

+``nova-objectstore``.

 Only Swift proxy server is launched in the screen session all other

-services are started in background and managed by `swift-init` tool.

+services are started in background and managed by ``swift-init`` tool.

 Heat

 ~~~~

-Heat is disabled by default (see `stackrc` file). To enable it

-explicitly you'll need the following settings in your `localrc`

+Heat is disabled by default (see ``stackrc`` file). To enable it

+explicitly you'll need the following settings in your ``localrc``

 section

 ::

@@ -554,7 +555,7 @@ section

 Heat can also run in standalone mode, and be configured to orchestrate

 on an external OpenStack cloud. To launch only Heat in standalone mode

-you'll need the following settings in your `localrc` section

+you'll need the following settings in your ``localrc`` section

 ::

@@ -590,14 +591,14 @@ Xenserver

 ~~~~~~~~~

 If you would like to use Xenserver as the hypervisor, please refer to

-the instructions in `./tools/xen/README.md`.

+the instructions in ``./tools/xen/README.md``.

 Cells

 ~~~~~

 `Cells <http://wiki.openstack.org/blueprint-nova-compute-cells>`__ is

 an alternative scaling option.  To setup a cells environment add the

-following to your `localrc` section:

+following to your ``localrc`` section:

 ::

@@ -17,7 +17,7 @@ Install devstack

     cd devstack

-Edit your `local.conf` to look like

+Edit your ``local.conf`` to look like

   ::

@@ -50,7 +50,7 @@ the host:

     parm:           nested:bool

 Start your VM, now it should have KVM capabilities -- you can verify

-that by ensuring `/dev/kvm` character device is present.

+that by ensuring ``/dev/kvm`` character device is present.

 Configure Nested KVM for AMD-based Machines

@@ -97,7 +97,7 @@ To make the above value persistent across reboots, add an entry in

 Expose Virtualization Extensions to DevStack VM

 -----------------------------------------------

-Edit the VM's libvirt XML configuration via `virsh` utility:

+Edit the VM's libvirt XML configuration via ``virsh`` utility:

 ::

@@ -115,10 +115,10 @@ Ensure DevStack VM is Using KVM

 -------------------------------

 Before invoking ``stack.sh`` in the VM, ensure that KVM is enabled. This

-can be verified by checking for the presence of the file `/dev/kvm` in

+can be verified by checking for the presence of the file ``/dev/kvm`` in

 your VM. If it is present, DevStack will default to using the config

-attribute `virt_type = kvm` in `/etc/nova.conf`; otherwise, it'll fall

-back to `virt_type=qemu`, i.e. plain QEMU emulation.

+attribute ``virt_type = kvm`` in ``/etc/nova.conf``; otherwise, it'll fall

+back to ``virt_type=qemu``, i.e. plain QEMU emulation.

 Optionally, to explicitly set the type of virtualization, to KVM, by the

 libvirt driver in nova, the below config attribute can be used in

@@ -131,7 +131,7 @@ DevStack's ``local.conf``:

 Once DevStack is configured successfully, verify if the Nova instances

 are using KVM by noticing the QEMU CLI invoked by Nova is using the

-parameter `accel=kvm`, e.g.:

+parameter ``accel=kvm``, e.g.:

 ::

@@ -340,8 +340,8 @@ nova, neutron)

 **Compute Nodes**

 In this example, the nodes that will host guest instances will run

-the `neutron-openvswitch-agent` for network connectivity, as well as

-the compute service `nova-compute`.

+the ``neutron-openvswitch-agent`` for network connectivity, as well as

+the compute service ``nova-compute``.

 DevStack Configuration

 ----------------------

@@ -426,16 +426,16 @@ compute node 1.

         Q_L3_ENABLED=False

 Compute node 2's configuration will be exactly the same, except

-`HOST_IP` will be `10.0.0.4`

+``HOST_IP`` will be ``10.0.0.4``

 When DevStack is configured to use provider networking (via

-`Q_USE_PROVIDER_NETWORKING` is True and `Q_L3_ENABLED` is False) -

+``Q_USE_PROVIDER_NETWORKING`` is True and ``Q_L3_ENABLED`` is False) -

 DevStack will automatically add the network interface defined in

-`PUBLIC_INTERFACE` to the `OVS_PHYSICAL_BRIDGE`

+``PUBLIC_INTERFACE`` to the ``OVS_PHYSICAL_BRIDGE``

 For example, with the above  configuration, a bridge is

-created, named `br-ex` which is managed by Open vSwitch, and the

-second interface on the compute node, `eth1` is attached to the

+created, named ``br-ex`` which is managed by Open vSwitch, and the

+second interface on the compute node, ``eth1`` is attached to the

 bridge, to forward traffic sent by guest VMs.

 Miscellaneous Tips

@@ -477,7 +477,7 @@ Configuring Extension Drivers for the ML2 Plugin

 ------------------------------------------------

 Extension drivers for the ML2 plugin are set with the variable

-`Q_ML2_PLUGIN_EXT_DRIVERS`, and includes the 'port_security' extension

+``Q_ML2_PLUGIN_EXT_DRIVERS``, and includes the 'port_security' extension

 by default. If you want to remove all the extension drivers (even

-'port_security'), set `Q_ML2_PLUGIN_EXT_DRIVERS` to blank.

+'port_security'), set ``Q_ML2_PLUGIN_EXT_DRIVERS`` to blank.