You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by se...@apache.org on 2014/02/07 16:20:23 UTC

git commit: finish fixing formatting issues

Updated Branches:
  refs/heads/master 2f312fc08 -> 7fdaf6118


finish fixing formatting issues


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/commit/7fdaf611
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/tree/7fdaf611
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/diff/7fdaf611

Branch: refs/heads/master
Commit: 7fdaf611896afda4a40a85dea07a0cab0342d0de
Parents: 2f312fc
Author: Sebastien Goasguen <ru...@gmail.com>
Authored: Fri Feb 7 16:20:26 2014 +0100
Committer: Sebastien Goasguen <ru...@gmail.com>
Committed: Fri Feb 7 16:20:26 2014 +0100

----------------------------------------------------------------------
 source/managing_networks.rst | 261 ++++++++------------------------------
 source/storage_setup.rst     |  55 ++------
 2 files changed, 64 insertions(+), 252 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/7fdaf611/source/managing_networks.rst
----------------------------------------------------------------------
diff --git a/source/managing_networks.rst b/source/managing_networks.rst
index 8b3d898..6a8f473 100644
--- a/source/managing_networks.rst
+++ b/source/managing_networks.rst
@@ -646,49 +646,14 @@ machines:
    For example, the following table describes three scenarios of guest
    network creation:
 
-   Case
+   =====  ===========  ============  ========================================  =============================================================
+   Case   CIDR         Network CIDR  Reserved IP Range for Non-CloudStack VMs  Description
+   =====  ===========  ============  ========================================  =============================================================
+   1      10.1.1.0/24  None          None                                      No IP Reservation.
+   2      10.1.1.0/26  10.1.1.0/24   10.1.1.64 to 10.1.1.254                   IP Reservation configured by the UpdateNetwork API with guestvmcidr=10.1.1.0/26 or enter 10.1.1.0/26 in the CIDR field in the UI.
+   3      10.1.1.0/24  None          None                                      Removing IP Reservation by the UpdateNetwork API with guestvmcidr=10.1.1.0/24 or enter 10.1.1.0/24 in the CIDR field in the UI.
+   =====  ===========  ============  ========================================  =============================================================
 
-   CIDR
-
-   Network CIDR
-
-   Reserved IP Range for Non-CloudStack VMs
-
-   Description
-
-   1
-
-   10.1.1.0/24
-
-   None
-
-   None
-
-   No IP Reservation.
-
-   2
-
-   10.1.1.0/26
-
-   10.1.1.0/24
-
-   10.1.1.64 to 10.1.1.254
-
-   IP Reservation configured by the UpdateNetwork API with
-   guestvmcidr=10.1.1.0/26 or enter 10.1.1.0/26 in the CIDR field in the
-   UI.
-
-   3
-
-   10.1.1.0/24
-
-   None
-
-   None
-
-   Removing IP Reservation by the UpdateNetwork API with
-   guestvmcidr=10.1.1.0/24 or enter 10.1.1.0/24 in the CIDR field in the
-   UI.
 
 Limitations
 ~~~~~~~~~~~
@@ -1135,12 +1100,7 @@ The EIP work flow is as follows:
    Network Address Translation (INAT) and Reverse NAT (RNAT) rules
    between the public IP and the private IP.
 
-   .. note:: Inbound NAT (INAT) is a type of NAT supported by NetScaler, in which
-   the destination IP address is replaced in the packets from the public
-   network, such as the Internet, with the private IP address of a VM in
-   the private network. Reverse NAT (RNAT) is a type of NAT supported by
-   NetScaler, in which the source IP address is replaced in the packets
-   generated by a VM in the private network with the public IP address.
+   .. note:: Inbound NAT (INAT) is a type of NAT supported by NetScaler, in which the destination IP address is replaced in the packets from the public network, such as the Internet, with the private IP address of a VM in the private network. Reverse NAT (RNAT) is a type of NAT supported by NetScaler, in which the source IP address is replaced in the packets generated by a VM in the private network with the public IP address.
 
 -  
 
@@ -1174,9 +1134,7 @@ NAT.
 For more information on the Associate Public IP option, see the
 Administration Guide.
 
-.. note:: The Associate Public IP feature is designed only for use with user VMs.
-The System VMs continue to get both public IP and private by default,
-irrespective of the network offering configuration.
+.. note:: The Associate Public IP feature is designed only for use with user VMs. The System VMs continue to get both public IP and private by default, irrespective of the network offering configuration.
 
 New deployments which use the default shared network offering with EIP
 and ELB services to create a shared network in the Basic zone will
@@ -1589,9 +1547,7 @@ Prerequisites
 
    Before you use PVLAN on XenServer and KVM, enable Open vSwitch (OVS).
 
-   .. note:: OVS on XenServer and KVM does not support PVLAN natively. Therefore,
-   CloudStack managed to simulate PVLAN on OVS for XenServer and KVM by
-   modifying the flow table.
+   .. note:: OVS on XenServer and KVM does not support PVLAN natively. Therefore, CloudStack managed to simulate PVLAN on OVS for XenServer and KVM by modifying the flow table.
 
 Creating a PVLAN-Enabled Guest Network
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1734,8 +1690,7 @@ useful in zones that use basic networking, because there is a single
 guest network for all guest VMs. In advanced zones, security groups are
 supported only on the KVM hypervisor.
 
-.. note:: In a zone that uses advanced networking, you can instead define multiple
-guest networks to isolate traffic to VMs.
+.. note:: In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
 
 Each CloudStack account comes with a default security group that denies
 all inbound traffic and allows all outbound traffic. The default
@@ -1802,10 +1757,7 @@ advanced zone where KVM is the hypervisor. Using security groups in
 advanced zones rather than multiple VLANs allows a greater range of
 options for setting up guest isolation in a cloud.
 
-Limitations
-'''''''''''
-
-The following are not supported for this feature:
+Limitations: The following are not supported for this feature:
 
 -  
 
@@ -1982,8 +1934,7 @@ balancing in zones that use isolated networking in advanced zones. Set
 up an external load balancer when you want to provide load balancing
 through means other than CloudStack’s provided virtual router.
 
-.. note:: In a Basic zone, load balancing service is supported only if Elastic IP
-or Elastic LB services are enabled.
+.. note:: In a Basic zone, load balancing service is supported only if Elastic IP or Elastic LB services are enabled.
 
 When NetScaler load balancer is used to provide EIP or ELB services in a
 Basic zone, ensure that all guest VM traffic must enter and exit through
@@ -2015,39 +1966,13 @@ Integration (Optional)” <#external-guest-lb-integration>`__.
 The Citrix NetScaler comes in three varieties. The following table
 summarizes how these variants are treated in CloudStack.
 
-NetScaler ADC Type
-
-Description of Capabilities
-
-CloudStack Supported Features
-
-MPX
-
-Physical appliance. Capable of deep packet inspection. Can act as
-application firewall and load balancer
-
-In advanced zones, load balancer functionality fully supported without
-limitation. In basic zones, static NAT, elastic IP (EIP), and elastic
-load balancing (ELB) are also provided.
-
-VPX
-
-Virtual appliance. Can run as VM on XenServer, ESXi, and Hyper-V
-hypervisors. Same functionality as MPX
-
-Supported on ESXi and XenServer. Same functional support as for MPX.
-CloudStack will treat VPX and MPX as the same device type.
-
-SDX
-
-Physical appliance. Can create multiple fully isolated VPX instances on
-a single appliance to support multi-tenant usage
-
-CloudStack will dynamically provision, configure, and manage the life
-cycle of VPX instances on the SDX. Provisioned instances are added into
-CloudStack automatically – no manual configuration by the administrator
-is required. Once a VPX instance is added into CloudStack, it is treated
-the same as a VPX on an ESXi host.
+==================   ========================================================================================================================   ==============================================================
+NetScaler ADC Type   Description of Capabilities                    CloudStack Supported Features
+==================   ========================================================================================================================   ==============================================================
+MPX                  Physical appliance. Capable of deep packet inspection. Can act as application firewall and load balancer.                  In advanced zones, load balancer functionality fully supported without limitation. In basic zones, static NAT, elastic IP (EIP), and elastic load balancing (ELB) are also provided.
+VPX                  Virtual appliance. Can run as VM on XenServer, ESXi, and Hyper-V hypervisors. Same functionality as MPX.                   Supported on ESXi and XenServer. Same functional support as for MPX. CloudStack will treat VPX and MPX as the same device type.
+SDX                  Physical appliance. Can create multiple fully isolated VPX instances on a single appliance to support multi-tenant usage   CloudStack will dynamically provision, configure, and manage the life cycle of VPX instances on the SDX. Provisioned instances are added into CloudStack automatically – no manual configuration by the administrator is required. Once a VPX instance is added into CloudStack, it is treated the same as a VPX on an ESXi host.
+==================   ========================================================================================================================   ==============================================================
 
 Configuring SNMP Community String on a RHEL Server
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2067,7 +1992,7 @@ communication between the NetScaler device and the RHEL machine.
    Ensure that you installed SNMP on RedHat. If not, run the following
    command:
 
-   .. code:: screen
+   .. code:: bash
 
        yum install net-snmp-utils
 
@@ -2081,10 +2006,9 @@ communication between the NetScaler device and the RHEL machine.
       Map the community name into a security name (local and mynetwork,
       depending on where the request is coming from):
 
-      .. note:: Use a strong password instead of public when you edit the
-      following table.
+      .. note:: Use a strong password instead of public when you edit the following table.
 
-      .. code:: screen
+      .. code:: bash
 
           #         sec.name   source        community
           com2sec    local      localhost     public
@@ -2096,7 +2020,7 @@ communication between the NetScaler device and the RHEL machine.
 
       Map the security names into group names:
 
-      .. code:: screen
+      .. code:: bash
 
           #      group.name   sec.model  sec.name
           group   MyRWGroup     v1         local
@@ -2108,7 +2032,7 @@ communication between the NetScaler device and the RHEL machine.
 
       Create a view to allow the groups to have the permission to:
 
-      .. code:: screen
+      .. code:: bash
 
           incl/excl subtree mask view all included .1
 
@@ -2117,7 +2041,7 @@ communication between the NetScaler device and the RHEL machine.
       Grant access with different write permissions to the two groups to
       the view you created.
 
-      .. code:: screen
+      .. code:: bash
 
           # context     sec.model     sec.level     prefix     read     write     notif
             access      MyROGroup ""  any noauth     exact      all      none     none
@@ -2127,7 +2051,7 @@ communication between the NetScaler device and the RHEL machine.
 
    Unblock SNMP in iptables.
 
-   .. code:: screen
+   .. code:: bash
 
        iptables -A INPUT -p udp --dport 161 -j ACCEPT
 
@@ -2135,7 +2059,7 @@ communication between the NetScaler device and the RHEL machine.
 
    Start the SNMP service:
 
-   .. code:: screen
+   .. code:: bash
 
        service snmpd start
 
@@ -2144,7 +2068,7 @@ communication between the NetScaler device and the RHEL machine.
    Ensure that the SNMP service is started automatically during the
    system startup:
 
-   .. code:: screen
+   .. code:: bash
 
        chkconfig snmpd on
 
@@ -2223,12 +2147,7 @@ balance traffic received at a public IP to one or more VMs. A user
 creates a rule, specifies an algorithm, and assigns the rule to a set of
 VMs.
 
-.. note:: If you create load balancing rules while using a network service
-offering that includes an external load balancer device such as
-NetScaler, and later change the network service offering to one that
-uses the CloudStack virtual router, you must create a firewall rule on
-the virtual router for each of your existing load balancing rules so
-that they continue to function.
+.. note:: If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudStack virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
 
 Adding a Load Balancer Rule
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -2437,13 +2356,9 @@ CloudStack uses the NetScaler load balancer to monitor all aspects of a
 system's health and work in unison with CloudStack to initiate scale-up
 or scale-down actions.
 
-.. note:: AutoScale is supported on NetScaler Release 10 Build 74.4006.e and
-beyond.
+.. note:: AutoScale is supported on NetScaler Release 10 Build 74.4006.e and beyond.
 
-Prerequisites
-'''''''''''''
-
-Before you configure an AutoScale rule, consider the following:
+**Prerequisites**: Before you configure an AutoScale rule, consider the following:
 
 -  
 
@@ -2451,9 +2366,7 @@ Before you configure an AutoScale rule, consider the following:
    AutoScale. When a VM is deployed by using a template and when it
    comes up, the application should be up and running.
 
-   .. note:: If the application is not running, the NetScaler device considers the
-   VM as ineffective and continues provisioning the VMs unconditionally
-   until the resource limit is exhausted.
+   .. note:: If the application is not running, the NetScaler device considers the VM as ineffective and continues provisioning the VMs unconditionally until the resource limit is exhausted.
 
 -  
 
@@ -2503,10 +2416,7 @@ Before you configure an AutoScale rule, consider the following:
    in the network ensures that the network is in implemented state for
    configuring AutoScale.
 
-Configuration
-'''''''''''''
-
-Specify the following:
+**Configuration**: Specify the following:
 
 |autoscaleateconfig.png: Configuring AutoScale|
 
@@ -2537,15 +2447,7 @@ Specify the following:
    rule has at least the configured number of active VM instances are
    available to serve the traffic.
 
-   .. note:: If an application, such as SAP, running on a VM instance is down for
-   some reason, the VM is then not counted as part of Min Instance
-   parameter, and the AutoScale feature initiates a scaleup action if
-   the number of active VM instances is below the configured value.
-   Similarly, when an application instance comes up from its earlier
-   down state, this application instance is counted as part of the
-   active instance count and the AutoScale process initiates a scaledown
-   action when the active instance count breaches the Max instance
-   value.
+   .. note:: If an application, such as SAP, running on a VM instance is down for some reason, the VM is then not counted as part of Min Instance parameter, and the AutoScale feature initiates a scaleup action if the number of active VM instances is below the configured value. Similarly, when an application instance comes up from its earlier down state, this application instance is counted as part of the active instance count and the AutoScale process initiates a scaledown action when the active instance count breaches the Max instance value.
 
 -  
 
@@ -2559,13 +2461,7 @@ Specify the following:
    leads to a single load balancing rule exhausting the VM instances
    limit specified at the account or domain level.
 
-   .. note:: If an application, such as SAP, running on a VM instance is down for
-   some reason, the VM is not counted as part of Max Instance parameter.
-   So there may be scenarios where the number of VMs provisioned for a
-   scaleup action might be more than the configured Max Instance value.
-   Once the application instances in the VMs are up from an earlier down
-   state, the AutoScale feature starts aligning to the configured Max
-   Instance value.
+   .. note:: If an application, such as SAP, running on a VM instance is down for some reason, the VM is not counted as part of Max Instance parameter. So there may be scenarios where the number of VMs provisioned for a scaleup action might be more than the configured Max Instance value. Once the application instances in the VMs are up from an earlier down state, the AutoScale feature starts aligning to the configured Max Instance value.
 
 Specify the following scale-up and scale-down policies:
 
@@ -2664,8 +2560,7 @@ advanced settings, and specify the following:
 
    **Apply**: Click Apply to create the AutoScale configuration.
 
-Disabling and Enabling an AutoScale Configuration
-'''''''''''''''''''''''''''''''''''''''''''''''''
+**Disabling and Enabling an AutoScale Configuration**
 
 If you want to perform any maintenance operation on the AutoScale VM
 instances, disable the AutoScale configuration. When the AutoScale
@@ -2681,8 +2576,7 @@ open the AutoScale configuration page again, then click the Enable
 AutoScale |EnableDisable.png: button to enable or disable AutoScale.|
 button.
 
-Updating an AutoScale Configuration
-'''''''''''''''''''''''''''''''''''
+**Updating an AutoScale Configuration**
 
 You can update the various parameters and add or delete the conditions
 in a scaleup or scaledown rule. Before you update an AutoScale
@@ -2693,8 +2587,7 @@ After you modify the required AutoScale parameters, click Apply. To
 apply the new AutoScale policies, open the AutoScale configuration page
 again, then click the Enable AutoScale button.
 
-Runtime Considerations
-''''''''''''''''''''''
+**Runtime Considerations**
 
 -  
 
@@ -3819,9 +3712,7 @@ The VPN user database is shared across all the VPNs created by the
 account owner. All VPN users get access to all VPNs created by the
 account owner.
 
-.. note:: Make sure that not all traffic goes through the VPN. That is, the route
-installed by the VPN should be only for the guest network and not for
-all traffic.
+.. note:: Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
 
 -  
 
@@ -4168,9 +4059,7 @@ The supported endpoints on the remote datacenters are:
 
    CloudStack virtual routers
 
-.. note:: In addition to the specific Cisco and Juniper devices listed above, the
-expectation is that any Cisco or Juniper device running on the supported
-operating systems are able to establish VPN connections.
+.. note:: In addition to the specific Cisco and Juniper devices listed above, the expectation is that any Cisco or Juniper device running on the supported operating systems are able to establish VPN connections.
 
 To set up a Site-to-Site VPN connection, perform the following:
 
@@ -4197,8 +4086,7 @@ To set up a Site-to-Site VPN connection, perform the following:
 Creating and Updating a VPN Customer Gateway
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-.. note:: A VPN customer gateway can be connected to only one VPN gateway at a
-time.
+.. note:: A VPN customer gateway can be connected to only one VPN gateway at a time.
 
 To add a VPN Customer Gateway:
 
@@ -4244,12 +4132,7 @@ To add a VPN Customer Gateway:
       authenticate the customer gateway and the VPC VPN gateway to each
       other.
 
-      .. note:: The IKE peers (VPN end points) authenticate each other by
-      computing and sending a keyed hash of data that includes the
-      Preshared key. If the receiving peer is able to create the same
-      hash independently by using its Preshared key, it knows that both
-      peers must share the same secret, thus authenticating the customer
-      gateway.
+      .. note:: The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.
 
    -  
 
@@ -4258,11 +4141,7 @@ To add a VPN Customer Gateway:
       AES256, and 3DES. Authentication is accomplished through the
       Preshared Keys.
 
-      .. Note:: The phase-1 is the first phase in the IKE process. In this initial
-      negotiation phase, the two VPN endpoints agree on the methods to
-      be used to provide security for the underlying IP traffic. The
-      phase-1 authenticates the two VPN gateways to each other, by
-      confirming that the remote gateway has a matching Preshared Key.
+      .. Note:: The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.
 
    -  
 
@@ -4283,11 +4162,7 @@ To add a VPN Customer Gateway:
       within phase-2. The supported encryption algorithms are AES128,
       AES192, AES256, and 3DES.
 
-      .. note:: The phase-2 is the second phase in the IKE process. The purpose of
-      IKE phase-2 is to negotiate IPSec security associations (SA) to
-      set up the IPSec tunnel. In phase-2, new keying material is
-      extracted from the Diffie-Hellman key exchange in phase-1, to
-      provide session keys to use in protecting the VPN data flow.
+      .. note:: The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.
 
    -  
 
@@ -4306,11 +4181,7 @@ To add a VPN Customer Gateway:
       of the key exchanges increase as the DH groups grow larger, as
       does the time of the exchanges.
 
-      .. note:: When PFS is turned on, for every negotiation of a new phase-2 SA
-      the two gateways must generate a new set of phase-1 keys. This
-      adds an extra layer of protection that PFS adds, which ensures if
-      the phase-2 SA’s have expired, the keys used for new phase-2 SA’s
-      have not been generated from the current phase-1 keying material.
+      .. note:: When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.
 
    -  
 
@@ -4788,8 +4659,7 @@ The major advantages are:
    from a pre-specified set of guest VLANs. All the VMs of a certain
    tier of an account reside on the guest VLAN allotted to that account.
 
-   .. note:: A VLAN allocated for an account cannot be shared between multiple
-   accounts.
+   .. note:: A VLAN allocated for an account cannot be shared between multiple accounts.
 
 -  
 
@@ -5168,8 +5038,7 @@ other tiers within the VPC.
    All the VPC that you have created for the account is listed in the
    page.
 
-   .. note:: The end users can see their own VPCs, while root and domain admin can
-   see any VPC they are authorized to see.
+   .. note:: The end users can see their own VPCs, while root and domain admin can see any VPC they are authorized to see.
 
 #. 
 
@@ -5271,35 +5140,13 @@ behavior is all the incoming traffic is blocked and outgoing traffic is
 allowed from the tiers. Default network ACL cannot be removed or
 modified. Contents of the default Network ACL is:
 
-Rule
-
-Protocol
-
-Traffic type
-
-Action
-
-CIDR
-
-1
-
-All
-
-Ingress
-
-Deny
-
-0.0.0.0/0
-
-2
-
-All
-
-Egress
-
-Deny
+=====  ========  ============  ======  =========  
+Rule   Protocol  Traffic type  Action  CIDR
+=====  ========  ============  ======  =========  
+1      All       Ingress       Deny    0.0.0.0/0
+2      All       Egress        Deny    0.0.0.0/0
+=====  ========  ============  ======  =========  
 
-0.0.0.0/0
 
 Creating ACL Lists
 ^^^^^^^^^^^^^^^^^^

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/7fdaf611/source/storage_setup.rst
----------------------------------------------------------------------
diff --git a/source/storage_setup.rst b/source/storage_setup.rst
index baf74bf..39be232 100644
--- a/source/storage_setup.rst
+++ b/source/storage_setup.rst
@@ -21,43 +21,14 @@ enterprise-grade storage. Local disk may be used as well, if supported
 by the selected hypervisor. Storage type support for guest virtual disks
 differs based on hypervisor selection.
 
-XenServer
-
-vSphere
-
-KVM
-
-NFS
-
-Supported
-
-Supported
-
-Supported
-
-iSCSI
-
-Supported
-
-Supported via VMFS
-
-Supported via Clustered Filesystems
-
-Fiber Channel
-
-Supported via Pre-existing SR
-
-Supported
-
-Supported via Clustered Filesystems
-
-Local Disk
-
-Supported
-
-Supported
-
-Supported
+=============  ==============================  ==================  ===================================
+Storage Type   XenServer                       vSphere             KVM
+=============  ==============================  ==================  ===================================
+NFS            Supported                       Supported           Supported
+iSCSI          Supported                       Supported via VMFS  Supported via Clustered Filesystems
+Fiber Channel  Supported via Pre-existing SR   Supported           Supported via Clustered Filesystems
+Local Disk     Supported                       Supported           Supported
+=============  ==============================  ==================  ===================================
 
 The use of the Cluster Logical Volume Manager (CLVM) for KVM is not
 officially supported with CloudStack.
@@ -76,11 +47,7 @@ CloudStack is designed to work with any scalable secondary storage
 system. The only requirement is the secondary storage system supports
 the NFS protocol.
 
-.. note:: The storage server should be a machine with a large number of disks. The
-disks should ideally be managed by a hardware RAID controller. Modern
-hardware RAID controllers support hot plug functionality independent of
-the operating system so you can replace faulty disks without impacting
-the running operating system.
+.. note:: The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller. Modern hardware RAID controllers support hot plug functionality independent of the operating system so you can replace faulty disks without impacting the running operating system.
 
 Example Configurations
 ----------------------
@@ -199,9 +166,7 @@ operating system version.
 
    An NFS share called /export is now set up.
 
-.. note:: When copying and pasting a command, be sure the command has pasted as a
-single line before executing. Some document viewers may introduce
-unwanted line breaks in copied text.
+.. note:: When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text.
 
 Linux NFS on iSCSI
 ~~~~~~~~~~~~~~~~~~