Fix typos, formatting in Admin Guide
Fix header typo, miscellaneous RST formatting. Change-Id: I0f7f6890fe100a79c27e328906f46375b3238f91
This commit is contained in:
parent
8c010b5d3c
commit
c5a2b42cb2
@ -242,8 +242,8 @@ format:
|
||||
|
||||
``<property>.<sub_property>``
|
||||
|
||||
Diver filter and weigher usage examples
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Driver filter and weigher usage examples
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Below are examples for using the filter and weigher separately,
|
||||
together, and using driver-specific properties.
|
||||
@ -350,7 +350,7 @@ properties::
|
||||
|
||||
The above is an example of how back-end specific properties can be used
|
||||
in the filter and goodness functions. In this example the LVM driver's
|
||||
``total\_volumes`` capability is being used to determine which host gets
|
||||
``total_volumes`` capability is being used to determine which host gets
|
||||
used during a volume request. In the above example, lvm-1 and lvm-2 will
|
||||
handle volume requests for all volumes with a size less than 5 GB. The
|
||||
lvm-1 host will have priority until it contains three or more volumes.
|
||||
|
@ -45,9 +45,11 @@ You can apply this process to volumes of any size.
|
||||
|
||||
#. Create a snapshot of a used volume
|
||||
|
||||
* Use this command to list all volumes::
|
||||
* Use this command to list all volumes
|
||||
|
||||
# lvdisplay
|
||||
.. code-block:: console
|
||||
|
||||
# lvdisplay
|
||||
|
||||
* Create the snapshot; you can do this while the volume is attached
|
||||
to an instance::
|
||||
@ -116,9 +118,9 @@ You can apply this process to volumes of any size.
|
||||
instance. Without using the partitions created inside instances,
|
||||
you cannot see its content and create efficient backups.
|
||||
|
||||
::
|
||||
.. code-block::console
|
||||
|
||||
# kpartx -av /dev/cinder-volumes/volume-00000001-snapshot
|
||||
# kpartx -av /dev/cinder-volumes/volume-00000001-snapshot
|
||||
|
||||
.. note::
|
||||
|
||||
@ -141,9 +143,11 @@ You can apply this process to volumes of any size.
|
||||
``cinder--volumes-volume--00000001--snapshot2``,
|
||||
``cinder--volumes-volume--00000001--snapshot3``, and so on.
|
||||
|
||||
* Mount your partition::
|
||||
* Mount your partition
|
||||
|
||||
# mount /dev/mapper/cinder--volumes-volume--volume--00000001--snapshot1 /mnt
|
||||
.. code-block:: console
|
||||
|
||||
# mount /dev/mapper/cinder--volumes-volume--volume--00000001--snapshot1 /mnt
|
||||
|
||||
If the partition mounts successfully, no errors are returned.
|
||||
|
||||
@ -154,7 +158,7 @@ You can apply this process to volumes of any size.
|
||||
|
||||
Allocate more space to the snapshot and try the process again.
|
||||
|
||||
#. Use the tar command to create archives
|
||||
#. Use the :command:`tar` command to create archives
|
||||
|
||||
Create a backup of the volume::
|
||||
|
||||
@ -194,15 +198,15 @@ You can apply this process to volumes of any size.
|
||||
|
||||
* Unmount the volume::
|
||||
|
||||
umount /mnt
|
||||
$ umount /mnt
|
||||
|
||||
* Delete the partition table::
|
||||
|
||||
kpartx -dv /dev/cinder-volumes/volume-00000001-snapshot
|
||||
$ kpartx -dv /dev/cinder-volumes/volume-00000001-snapshot
|
||||
|
||||
* Remove the snapshot::
|
||||
|
||||
lvremove -f /dev/cinder-volumes/volume-00000001-snapshot
|
||||
$ lvremove -f /dev/cinder-volumes/volume-00000001-snapshot
|
||||
|
||||
Repeat these steps for all your volumes.
|
||||
|
||||
|
@ -1,7 +1,5 @@
|
||||
.. _over_subscription:
|
||||
|
||||
.. highlight: ini
|
||||
:linenothreshold: 5
|
||||
|
||||
=====================================
|
||||
Oversubscription in thin provisioning
|
||||
@ -54,10 +52,10 @@ Drivers can report the following capabilities for a back end or a pool:
|
||||
.. code-block:: ini
|
||||
:linenos:
|
||||
|
||||
thin_provisioning_support=True(or False)
|
||||
thick_provisioning_support=True(or False)
|
||||
provisioned_capacity_gb=PROVISIONED_CAPACITY
|
||||
max_over_subscription_ratio=MAX_RATIO
|
||||
thin_provisioning_support = True(or False)
|
||||
thick_provisioning_support = True(or False)
|
||||
provisioned_capacity_gb = PROVISIONED_CAPACITY
|
||||
max_over_subscription_ratio = MAX_RATIO
|
||||
|
||||
Where ``PROVISIONED_CAPACITY`` is the apparent allocated space indicating
|
||||
how much capacity has been provisioned and ``MAX_RATIO`` is the maximum
|
||||
|
@ -220,8 +220,8 @@ capabilities:
|
||||
potentially overlapping IP addresses, neutron-l3-agent defaults to using
|
||||
Linux network namespaces to provide isolated forwarding contexts. As a
|
||||
result, the IP addresses of routers are not visible simply by running
|
||||
the :command:``ip addr list`` or :command:``ifconfig`` command on the node.
|
||||
Similarly, you cannot directly :command:``ping`` fixed IPs.
|
||||
the :command:`ip addr list` or :command:`ifconfig` command on the node.
|
||||
Similarly, you cannot directly :command:`ping` fixed IPs.
|
||||
|
||||
To do either of these things, you must run the command within a
|
||||
particular network namespace for the router. The namespace has the name
|
||||
@ -261,7 +261,7 @@ capabilities:
|
||||
service starts.
|
||||
|
||||
On Red Hat, SUSE and Ubuntu based systems, the neutron-ovs-cleanup
|
||||
service runs the :command:``neutron-ovs-cleanup`` command
|
||||
service runs the :command:`neutron-ovs-cleanup` command
|
||||
automatically. However, on Debian-based systems, you must manually
|
||||
run this command or write your own system script that runs on boot
|
||||
before the neutron-l3-agent service starts.
|
||||
|
@ -240,7 +240,7 @@ neutron server when it starts up.
|
||||
|
||||
#. Show agent details.
|
||||
|
||||
The :command:``agent-show`` command shows details for a specified agent:
|
||||
The :command:`agent-show` command shows details for a specified agent:
|
||||
|
||||
.. code:: console
|
||||
|
||||
@ -310,7 +310,7 @@ neutron server when it starts up.
|
||||
**Manage assignment of networks to DHCP agent**
|
||||
|
||||
Now that you have run the :command:`net-list-on-dhcp-agent` and
|
||||
``dhcp-agent-list-hosting-net`` commands, you can add a network to a
|
||||
:command:`dhcp-agent-list-hosting-net` commands, you can add a network to a
|
||||
DHCP agent and remove one from it.
|
||||
|
||||
#. Default scheduling.
|
||||
|
@ -90,7 +90,7 @@ basic network operations:
|
||||
Administrative operations
|
||||
-------------------------
|
||||
|
||||
The cloud administrator can run any ``neutron`` command on behalf of
|
||||
The cloud administrator can run any :command:`neutron` command on behalf of
|
||||
tenants by specifying an Identity ``tenant_id`` in the command, as
|
||||
follows:
|
||||
|
||||
@ -297,7 +297,7 @@ You must configure security group rules depending on the type of plug-in
|
||||
you are using. If you are using a plug-in that:
|
||||
|
||||
- Implements Networking security groups, you can configure security
|
||||
group rules directly by using the ``neutron security-group-rule-create``
|
||||
group rules directly by using the :command:`neutron security-group-rule-create`
|
||||
command. This example enables ``ping`` and ``ssh`` access to your VMs.
|
||||
|
||||
.. code:: console
|
||||
@ -311,9 +311,9 @@ you are using. If you are using a plug-in that:
|
||||
--port-range-max 22 --direction ingress default
|
||||
|
||||
- Does not implement Networking security groups, you can configure
|
||||
security group rules by using the ``nova secgroup-add-rule`` or
|
||||
``euca-authorize`` command. These ``nova`` commands enable ``ping``
|
||||
and ``ssh`` access to your VMs.
|
||||
security group rules by using the :command:`nova secgroup-add-rule` or
|
||||
:command:`euca-authorize` command. These :command:`nova` commands enable
|
||||
``ping`` and ``ssh`` access to your VMs.
|
||||
|
||||
.. code:: console
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user