[1/2] first re-org of installation guide

[se...@apache.org]

Updated Branches:
  refs/heads/master 7fdaf6118 -> 0bbd42645


http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/0bbd4264/source/qig.rst
----------------------------------------------------------------------
diff --git a/source/qig.rst b/source/qig.rst
new file mode 100644
index 0000000..b682183
--- /dev/null
+++ b/source/qig.rst
@@ -0,0 +1,526 @@
+Quick Installation Guide for CentOS
+===================================
+
+
+Overview
+--------
+
+What exactly are we building?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Infrastructure-as-a-Service (IaaS) clouds can be a complex thing to build, and by definition they have a plethora of options,
+which often lead to confusion for even experienced admins who are newcomers to building cloud platforms. The goal for
+this runbook is to provide a straightforward set of instructions to get you up and running with CloudStack with a minimum
+amount of trouble.
+
+
+High level overview of the process
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This runbook will focus on building a CloudStack cloud using KVM with CentOS 6.4 with NFS storage on a flat layer-2
+network utilizing layer-3 network isolation (aka Security Groups), and doing it all on a single piece of hardware.
+
+KVM, or Kernel-based Virtual Machine is a virtualization technology for the Linux kernel. KVM supports native virtualization
+atop processors with hardware virtualization extensions.
+
+Security Groups act as distributed firewalls that control access to a group of virtual machines.
+
+
+Prerequisites
+~~~~~~~~~~~~~
+
+To complete this runbook you'll need the following items:
+
+1. At least one computer which supports hardware virtualization.
+2. The `CentOS 6.4 x86_64 minimal install CD <http://mirrors.kernel.org/centos/6.4/isos/x86_64/CentOS-6.4-x86_64-minimal.iso>`_
+3. A /24 network with the gateway being at xxx.xxx.xxx.1, no DHCP should be on this network and none of the computers running CloudStack will have a dynamic address. Again this is done for the sake of simplicity.
+
+Environment
+-----------
+
+Before you begin , you need to prepare the environment before you install CloudStack. We will go over the steps to
+prepare now.
+
+Operating System
+~~~~~~~~~~~~~~~~
+
+Using the CentOS 6.4 x86_64 minimal install ISO, you'll need to install CentOS on your hardware. The defaults will
+generally be acceptable for this installation.
+
+Once this installation is complete, you'll want to connect to your freshly installed machine via SSH as the root user. Note
+that you should not allow root logins in a production environment, so be sure to turn off remote logins once you have
+finished the installation and configuration.
+
+.. _conf-network:
+
+Configuring the network
+^^^^^^^^^^^^^^^^^^^^^^^
+
+By default the network will not come up on your hardware and you will need to configure it to work in your environment.
+Since we specified that there will be no DHCP server in this environment we will be manually configuring your network
+interface. We will assume, for the purposes of this exercise, that eth0 is the only network interface that will be connected
+and used.
+
+Connecting via the console you should login as root. Check the file /etc/sysconfig/network-scripts/ifcfg-eth0,
+it will look like this by default:
+
+  ::
+
+   DEVICE="eth0"
+   HWADDR="52:54:00:B9:A6:C0"
+   NM_CONTROLLED="yes"
+   ONBOOT="no"
+
+Unfortunately, this configuration will not permit you to connect to the network, and is also unsuitable for our purposes with
+CloudStack. We want to configure that file so that it specifies the IP address, netmask, etc., as shown in the following
+example:
+
+  .. note:: You should not use the Hardware Address (aka the MAC address) from our example for your configuration. It is
+     network interface specific, so you should keep the address already provided in the HWADDR directive.
+
+  :: 
+
+    DEVICE=eth0
+    HWADDR=52:54:00:B9:A6:C0
+    NM_CONTROLLED=no
+    ONBOOT=yes
+    BOOTPROTO=none
+    IPADDR=172.16.10.2
+    NETMASK=255.255.255.0
+    GATEWAY=172.16.10.1
+    DNS1=8.8.8.8
+    DNS2=8.8.4.4
+
+  .. note:: IP Addressing
+     Throughout this document we are assuming that you will have a /24 network for your CloudStack implementation. This can be any RFC 1918 network. However, we are assuming that you will match the machine address that we are using. Thus we may use 172.16.10.2 and because you might be using the 192.168.55.0/24 network you would use 192.168.55.2
+
+Now that we have the configuration files properly set up, we need to run a few commands to start up the network: 
+
+  .. sourcecode:: bash
+
+     # chkconfig network on
+
+     # chkconfig network start
+
+.. _conf-hostname:
+
+Hostname
+^^^^^^^^
+
+CloudStack requires that the hostname be properly set. If you used the default options in the installation, then your
+hostname is currently set to localhost.localdomain. To test this we will run:
+
+  .. sourcecode:: bash
+
+     # hostname --fqdn
+
+At this point it will likely return: 
+
+  .. sourcecode:: bash
+
+     localhost
+
+To rectify this situation - we'll set the hostname by editing the /etc/hosts file so that it follows a similar format to this
+example:
+
+  .. sourcecode:: bash
+
+     127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
+     ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
+     172.16.10.2 srvr1.cloud.priv
+
+After you've modified that file, go ahead and restart the network using:
+
+  .. sourcecode:: bash
+
+     # service network restart
+
+Now recheck with the hostname --fqdn command and ensure that it returns a FQDN response
+
+.. _conf-selinux:
+
+SELinux
+^^^^^^^
+
+At the moment, for CloudStack to work properly SELinux must be set to permissive. We want to both configure this for
+future boots and modify it in the current running system.
+
+To configure SELinux to be permissive in the running system we need to run the following command:
+
+  .. sourcecode:: bash
+
+     # setenforce 0
+
+To ensure that it remains in that state we need to configure the file /etc/selinux/config to reflect the permissive
+state, as shown in this example:
+
+  .. sourcecode:: bash
+
+     # This file controls the state of SELinux on the system.
+     # SELINUX= can take one of these three values:
+     # enforcing - SELinux security policy is enforced.
+     # permissive - SELinux prints warnings instead of enforcing.
+     # disabled - No SELinux policy is loaded.
+     SELINUX=permissive
+     # SELINUXTYPE= can take one of these two values:
+     # targeted - Targeted processes are protected,
+     # mls - Multi Level Security protection.
+     SELINUXTYPE=targeted
+
+.. _conf-ntp:
+
+NTP
+^^^
+
+NTP configuration is a necessity for keeping all of the clocks in your cloud servers in sync. However, NTP is not installed
+by default. So we'll install and and configure NTP at this stage. Installation is accomplished as follows:
+
+  .. sourcecode:: bash
+
+     # yum -y install ntp
+
+The actual default configuration is fine for our purposes, so we merely need to enable it and set it to start on boot as
+follows:
+
+  .. sourcecode:: bash
+
+     # chkconfig ntpd on
+     # service ntpd start
+
+.. _qigconf-pkg-repo:
+
+Configuring the CloudStack Package Repository
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+We need to configure the machine to use a CloudStack package repository. 
+
+  .. note:: The Apache CloudStack official releases are source code. As such there are no 'official' binaries available. The full installation guide describes how to take the source release and generate RPMs and and yum repository. This guide attempts to keep things as simple as possible, and thus we are using one of the community-provided yum repositories.
+
+To add the CloudStack repository, create /etc/yum.repos.d/cloudstack.repo and insert the following information.
+
+  ::
+
+    [cloudstack]
+    name=cloudstack
+    baseurl=http://cloudstack.apt-get.eu/rhel/4.3/
+    enabled=1
+    gpgcheck=0
+
+NFS
+~~~
+
+Our configuration is going to use NFS for both primary and secondary storage. We are going to go ahead and setup two
+NFS shares for those purposes. We'll start out by installing nfs-utils.
+
+  .. sourcecode:: bash
+
+     # yum install nfs-utils
+
+We now need to configure NFS to serve up two different shares. This is handled comparatively easily in the 
+/etc/exports file. You should ensure that it has the following content:
+
+  .. sourcecode:: bash
+
+     /secondary *(rw,async,no_root_squash)
+     /primary *(rw,async,no_root_squash)
+
+You will note that we specified two directories that don't exist (yet) on the system. We'll go ahead and create those
+directories and set permissions appropriately on them with the following commands:
+
+  .. sourcecode:: bash
+
+     # mkdir /primary
+     # mkdir /secondary
+
+CentOS 6.x releases use NFSv4 by default. NFSv4 requires that domain setting matches on all clients. In our case, the
+domain is cloud.priv, so ensure that the domain setting in /etc/idmapd.conf is uncommented and set as follows:
+Domain = cloud.priv
+
+Now you'll need uncomment the configuration values in the file /etc/sysconfig/nfs
+
+  .. sourcecode:: bash
+
+     LOCKD_TCPPORT=32803
+     LOCKD_UDPPORT=32769
+     MOUNTD_PORT=892
+     RQUOTAD_PORT=875
+     STATD_PORT=662
+     STATD_OUTGOING_PORT=2020
+
+Now we need to configure the firewall to permit incoming NFS connections. Edit the file /etc/sysconfig/iptables
+
+  .. sourcecode:: bash
+
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT
+     -A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT
+
+Now you can restart the iptables service with the following command:
+
+  .. sourcecode:: bash
+
+     # service iptables restart
+
+We now need to configure the nfs service to start on boot and actually start it on the host by executing the following
+commands:
+
+  .. sourcecode:: bash
+
+     # service rpcbind start
+     # service nfs start
+     # chkconfig rpcbind on
+     # chkconfig nfs on
+
+Management Server Installation
+------------------------------
+
+We're going to install the CloudStack management server and surrounding tools. 
+
+Database Installation and Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We'll start with installing MySQL and configuring some options to ensure it runs well with CloudStack. 
+
+Install by running the following command: 
+
+  .. sourcecode:: bash
+
+     # yum -y install mysql-server
+
+With MySQL now installed we need to make a few configuration changes to /etc/my.cnf. Specifically we need to add the
+following options to the [mysqld] section:
+
+  ::
+
+     innodb_rollback_on_timeout=1
+     innodb_lock_wait_timeout=600
+     max_connections=350
+     log-bin=mysql-bin
+     binlog-format = 'ROW' 
+
+Now that MySQL is properly configured we can start it and configure it to start on boot as follows:
+
+  .. sourcecode:: bash 
+
+     # service mysqld start
+     # chkconfig mysqld on
+
+Installation
+~~~~~~~~~~~~
+
+We are now going to install the management server. We do that by executing the following command:
+
+  .. sourcecode:: bash
+
+     # yum -y install cloud-client
+
+With the application itself installed we can now setup the database, we'll do that with the following command and options:
+
+  .. sourcecode:: bash
+
+     # cloudstack-setup-databases cloud:password@localhost --deploy-as=root
+
+When this process is finished, you should see a message like "CloudStack has successfully initialized the database."
+
+Now that the database has been created, we can take the final step in setting up the management server by issuing the
+following command:
+
+  .. sourcecode:: bash
+
+     # cloudstack-setup-management
+
+System Template Setup
+~~~~~~~~~~~~~~~~~~~~~
+
+CloudStack uses a number of system VMs to provide functionality for accessing the console of virtual machines,
+providing various networking services, and managing various aspects of storage. This step will acquire those system
+images ready for deployment when we bootstrap your cloud.
+
+Now we need to download the system VM template and deploy that to the share we just mounted. The management
+server includes a script to properly manipulate the system VMs images.
+
+  .. sourcecode:: bash
+
+     # /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m \ 
+     /secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 \
+     -h kvm -F
+
+That concludes our setup of the management server. We still need to configure CloudStack, but we will do that after we
+get our hypervisor set up.
+
+KVM Setup and Installation
+--------------------------
+
+KVM is the hypervisor we'll be using - we will recover the initial setup which has already been done on the hypervisor host
+and cover installation of the agent software, you can use the same steps to add additional KVM nodes to your CloudStack
+environment.
+
+Prerequisites
+~~~~~~~~~~~~~
+
+We explicitly are using the management server as a compute node as well, which means that we have already performed
+many of the prerequisite steps when setting up the management server, but we will list them here for clarity. Those steps
+are:
+
+1. :ref:`conf-network`
+2. :ref:`conf-hostname`
+3. :ref:`conf-selinux`
+4. :ref:`conf-ntp`
+5. :ref:`qigconf-pkg-repo`
+
+You shouldn't need to do that for the management server, of course, but any additional hosts will need for you to complete
+the above steps.
+
+Installation
+~~~~~~~~~~~~
+
+Installation of the KVM agent is trivial with just a single command, but afterwards we'll need to configure a few things.
+
+  .. sourcecode:: bash
+
+     # yum -y install cloud-agent
+
+KVM Configuration
+~~~~~~~~~~~~~~~~~~~~
+
+We have two different parts of KVM to configure, libvirt, and QEMU.
+
+QEMU Configuration
+^^^^^^^^^^^^^^^^^^^
+
+KVM configuration is relatively simple at only a single item. We need to edit the QEMU VNC configuration. This is done by
+editing /etc/libvirt/qemu.conf and ensuring the following line is present and uncommented.
+
+  ..
+
+    vnc_listen=0.0.0.0
+
+Libvirt Configuration
+^^^^^^^^^^^^^^^^^^^^^^^
+
+CloudStack uses libvirt for managing virtual machines. Therefore it is vital that libvirt is configured correctly. Libvirt is a dependency of cloud-agent and should already be installed.
+
+1. In order to have live migration working libvirt has to listen for unsecured TCP connections. We also need to turn off libvirts attempt to use Multicast DNS advertising. Both of these settings are in /etc/libvirt/libvirtd.conf
+
+Set the following paramaters:
+
+ ::
+
+   listen_tls = 0
+   listen_tcp = 1
+   tcp_port = "16059"
+   auth_tcp = "none"
+   mdns_adv = 0
+
+2. Turning on "listen_tcp" in libvirtd.conf is not enough, we have to change the parameters as well we also need to modify /etc/sysconfig/libvirtd:
+
+  Uncomment the following line:
+
+  :: 
+
+    #LIBVIRTD_ARGS="--listen"
+
+3. Restart libvirt
+
+  .. sourcecode:: bash
+
+     # service libvirtd restart
+
+KVM configuration complete
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+That concludes our installation and configuration of KVM, and we'll now move to using the CloudStack UI for the actual
+configuration of our cloud.
+
+Configuration
+-------------
+
+As we noted before we will be using security groups to provide isolation and by default that implies that we'll be using a
+flat layer-2 network. It also means that the simplicity of our setup means that we can use the quick installer.
+
+UI Access
+~~~~~~~~~
+
+To get access to CloudStack's web interface, merely point your browser to http://172.16.10.2:8080/client The default
+username is 'admin', and the default password is 'password'. You should see a splash screen that allows you to choose
+several options for setting up CloudStack. You should choose the Continue with Basic Setup option.
+
+You should now see a prompt requiring you to change the password for the admin user. Please do so.
+
+Setting up a Zone
+~~~~~~~~~~~~~~~~~
+
+A zone is the largest organization entity in CloudStack - and we'll be creating one, this should be the screen that you see
+in front of you now. And for us there are 5 pieces of information that we need.
+
+  1. Name - we will set this to the ever-descriptive 'Zone1' for our cloud.
+  2. Public DNS 1 - we will set this to '8.8.8.8' for our cloud.
+  3. Public DNS 2 - we will set this to '8.8.4.4' for our cloud.
+  4. Internal DNS1 - we will also set this to '8.8.8.8' for our cloud.
+  5. Internal DNS2 - we will also set this to '8.8.4.4' for our cloud. 
+
+  .. note:: 
+     CloudStack distinguishes between internal and public DNS. Internal DNS is assumed to be capable of resolving
+     internal-only hostnames, such as your NFS server’s DNS name. Public DNS is provided to the guest VMs to
+     resolve public IP addresses. You can enter the same DNS server for both types, but if you do so, you must make
+     sure that both internal and public IP addresses can route to the DNS server. In our specific case we will not use
+     any names for resources internally, and we have indeed them set to look to the same external resource so as to
+     not add a namerserver setup to our list of requirements.
+
+Pod Configuration
+~~~~~~~~~~~~~~~~~
+
+Now that we've added a Zone, the next step that comes up is a prompt for information regading a pod. Which is looking
+for several items.
+
+1. Name - We'll use Pod1 for our cloud.
+2. Gateway - We'll use 172.16.10.1 as our gateway
+3. Netmask - We'll use 255.255.255.0
+4. Start/end reserved system IPs - we will use 172.16.10.10-172.16.10.20
+5. Guest gateway - We'll use 172.16.10.1
+6. Guest netmask - We'll use 255.255.255.0
+7. Guest start/end IP - We'll use 172.16.10.30-172.16.10.200
+
+Cluster
+~~~~~~~
+
+Now that we've added a Zone, we need only add a few more items for configuring the cluster.
+
+1. Name - We'll use Cluster1
+2. Hypervisor - Choose KVM
+
+You should be prompted to add the first host to your cluster at this point. Only a few bits of information are needed.
+
+1. Hostname - we'll use the IP address 172.16.10.2 since we didn't set up a DNS server.
+2. Username - we'll use 'root'
+3. Password - enter the operating system password for the root user
+
+Primary Storage
+^^^^^^^^^^^^^^^
+
+With your cluster now setup - you should be prompted for primary storage information. Choose NFS as the storage type
+and then enter the following values in the fields:
+
+1. Name - We'll use 'Primary1'
+2. Server - We'll be using the IP address 172.16.10.2
+3. Path - Well define /primary as the path we are using
+
+Secondary Storage
+^^^^^^^^^^^^^^^^^
+
+If this is a new zone, you'll be prompted for secondary storage information - populate it as follows:
+
+1. NFS server - We'll use the IP address 172.16.10.2
+2. Path - We'll use /secondary
+
+Now, click Launch and your cloud should begin setup - it may take several minutes depending on your internet
+connection speed for setup to finalize.
+
+That's it, you are done with installation of your Apache CloudStack cloud.

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/0bbd4264/source/terminology.rst
----------------------------------------------------------------------
diff --git a/source/terminology.rst b/source/terminology.rst
deleted file mode 100644
index 8082ca6..0000000
--- a/source/terminology.rst
+++ /dev/null
@@ -1,647 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information#
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-   http://www.apache.org/licenses/LICENSE-2.0
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-
-CloudStack Terminology
-======================
-
-About Regions
--------------
-
-To increase reliability of the cloud, you can optionally group resources
-into multiple geographic regions. A region is the largest available
-organizational unit within a CloudStack deployment. A region is made up
-of several availability zones, where each zone is roughly equivalent to
-a datacenter. Each region is controlled by its own cluster of Management
-Servers, running in one of the zones. The zones in a region are
-typically located in close geographical proximity. Regions are a useful
-technique for providing fault tolerance and disaster recovery.
-
-By grouping zones into regions, the cloud can achieve higher
-availability and scalability. User accounts can span regions, so that
-users can deploy VMs in multiple, widely-dispersed regions. Even if one
-of the regions becomes unavailable, the services are still available to
-the end-user through VMs deployed in another region. And by grouping
-communities of zones under their own nearby Management Servers, the
-latency of communications within the cloud is reduced compared to
-managing widely-dispersed zones from a single central Management Server.
-
-Usage records can also be consolidated and tracked at the region level,
-creating reports or invoices for each geographic region.
-
-|region-overview.png: Nested structure of a region.|
-
-Regions are visible to the end user. When a user starts a guest VM on a
-particular CloudStack Management Server, the user is implicitly
-selecting that region for their guest. Users might also be required to
-copy their private templates to additional regions to enable creation of
-guest VMs using their templates in those regions.
-
-About Zones
------------
-
-A zone is the second largest organizational unit within a CloudStack
-deployment. A zone typically corresponds to a single datacenter,
-although it is permissible to have multiple zones in a datacenter. The
-benefit of organizing infrastructure into zones is to provide physical
-isolation and redundancy. For example, each zone can have its own power
-supply and network uplink, and the zones can be widely separated
-geographically (though this is not required).
-
-A zone consists of:
-
--  
-
-   One or more pods. Each pod contains one or more clusters of hosts and
-   one or more primary storage servers.
-
--  
-
-   A zone may contain one or more primary storage servers, which are
-   shared by all the pods in the zone.
-
--  
-
-   Secondary storage, which is shared by all the pods in the zone.
-
-|zone-overview.png: Nested structure of a simple zone.|
-
-Zones are visible to the end user. When a user starts a guest VM, the
-user must select a zone for their guest. Users might also be required to
-copy their private templates to additional zones to enable creation of
-guest VMs using their templates in those zones.
-
-Zones can be public or private. Public zones are visible to all users.
-This means that any user may create a guest in that zone. Private zones
-are reserved for a specific domain. Only users in that domain or its
-subdomains may create guests in that zone.
-
-Hosts in the same zone are directly accessible to each other without
-having to go through a firewall. Hosts in different zones can access
-each other through statically configured VPN tunnels.
-
-For each zone, the administrator must decide the following.
-
--  
-
-   How many pods to place in each zone.
-
--  
-
-   How many clusters to place in each pod.
-
--  
-
-   How many hosts to place in each cluster.
-
--  
-
-   (Optional) How many primary storage servers to place in each zone and
-   total capacity for these storage servers.
-
--  
-
-   How many primary storage servers to place in each cluster and total
-   capacity for these storage servers.
-
--  
-
-   How much secondary storage to deploy in a zone.
-
-When you add a new zone using the CloudStack UI, you will be prompted to
-configure the zone’s physical network and add the first pod, cluster,
-host, primary storage, and secondary storage.
-
-In order to support zone-wide functions for VMware, CloudStack is aware
-of VMware Datacenters and can map each Datacenter to a CloudStack zone.
-To enable features like storage live migration and zone-wide primary
-storage for VMware hosts, CloudStack has to make sure that a zone
-contains only a single VMware Datacenter. Therefore, when you are
-creating a new CloudStack zone, you can select a VMware Datacenter for
-the zone. If you are provisioning multiple VMware Datacenters, each one
-will be set up as a single zone in CloudStack.
-
-.. note:: If you are upgrading from a previous CloudStack version, and your existing deployment contains a zone with clusters from multiple VMware Datacenters, that zone will not be forcibly migrated to the new model. It will continue to function as before. However, any new zone-wide operations, such as zone-wide primary storage and live storage migration, will not be available in that zone.
-
-About Pods
-----------
-
-A pod often represents a single rack. Hosts in the same pod are in the
-same subnet. A pod is the third-largest organizational unit within a
-CloudStack deployment. Pods are contained within zones. Each zone can
-contain one or more pods. A pod consists of one or more clusters of
-hosts and one or more primary storage servers. Pods are not visible to
-the end user.
-
-|pod-overview.png: Nested structure of a simple pod|
-
-About Clusters
---------------
-
-A cluster provides a way to group hosts. To be precise, a cluster is a
-XenServer server pool, a set of KVM servers, , or a VMware cluster
-preconfigured in vCenter. The hosts in a cluster all have identical
-hardware, run the same hypervisor, are on the same subnet, and access
-the same shared primary storage. Virtual machine instances (VMs) can be
-live-migrated from one host to another within the same cluster, without
-interrupting service to the user.
-
-A cluster is the fourth-largest organizational unit within a CloudStack
-deployment. Clusters are contained within pods, and pods are contained
-within zones. Size of the cluster is limited by the underlying
-hypervisor, although the CloudStack recommends less in most cases; see
-Best Practices.
-
-A cluster consists of one or more hosts and one or more primary storage
-servers.
-
-|cluster-overview.png: Structure of a simple cluster|
-
-CloudStack allows multiple clusters in a cloud deployment.
-
-Even when local storage is used exclusively, clusters are still required
-organizationally, even if there is just one host per cluster.
-
-When VMware is used, every VMware cluster is managed by a vCenter
-server. An Administrator must register the vCenter server with
-CloudStack. There may be multiple vCenter servers per zone. Each vCenter
-server may manage multiple VMware clusters.
-
-About Hosts
------------
-
-A host is a single computer. Hosts provide the computing resources that
-run guest virtual machines. Each host has hypervisor software installed
-on it to manage the guest VMs. For example, a host can be a Citrix
-XenServer server, a Linux KVM-enabled server, an ESXi server, or a
-Windows Hyper-V server.
-
-The host is the smallest organizational unit within a CloudStack
-deployment. Hosts are contained within clusters, clusters are contained
-within pods, pods are contained within zones, and zones can be contained
-within regions.
-
-Hosts in a CloudStack deployment:
-
--  
-
-   Provide the CPU, memory, storage, and networking resources needed to
-   host the virtual machines
-
--  
-
-   Interconnect using a high bandwidth TCP/IP network and connect to the
-   Internet
-
--  
-
-   May reside in multiple data centers across different geographic
-   locations
-
--  
-
-   May have different capacities (different CPU speeds, different
-   amounts of RAM, etc.), although the hosts within a cluster must all
-   be homogeneous
-
-Additional hosts can be added at any time to provide more capacity for
-guest VMs.
-
-CloudStack automatically detects the amount of CPU and memory resources
-provided by the hosts.
-
-Hosts are not visible to the end user. An end user cannot determine
-which host their guest has been assigned to.
-
-For a host to function in CloudStack, you must do the following:
-
--  
-
-   Install hypervisor software on the host
-
--  
-
-   Assign an IP address to the host
-
--  
-
-   Ensure the host is connected to the CloudStack Management Server.
-
-About Primary Storage
----------------------
-
-Primary storage is associated with a cluster or (in KVM and VMware) a
-zone, and it stores the disk volumes for all the VMs running on hosts.
-
-You can add multiple primary storage servers to a cluster or zone. At
-least one is required. It is typically located close to the hosts for
-increased performance. CloudStack manages the allocation of guest
-virtual disks to particular primary storage devices.
-
-It is useful to set up zone-wide primary storage when you want to avoid
-extra data copy operations. With cluster-based primary storage, data in
-the primary storage is directly available only to VMs within that
-cluster. If a VM in a different cluster needs some of the data, it must
-be copied from one cluster to another, using the zone's secondary
-storage as an intermediate step. This operation can be unnecessarily
-time-consuming.
-
-For Hyper-V, SMB/CIFS storage is supported. Note that Zone-wide Primary
-Storage is not supported in Hyper-V.
-
-CloudStack is designed to work with all standards-compliant iSCSI and
-NFS servers that are supported by the underlying hypervisor, including,
-for example:
-
--
-
-   SolidFire for iSCSI
-
--  
-
-   Dell EqualLogic™ for iSCSI
-
--  
-
-   Network Appliances filers for NFS and iSCSI
-
--  
-
-   Scale Computing for NFS
-
-If you intend to use only local disk for your installation, you can skip
-adding separate primary storage.
-
-About Secondary Storage
------------------------
-
-Secondary storage stores the following:
-
--  
-
-   Templates — OS images that can be used to boot VMs and can include
-   additional configuration information, such as installed applications
-
--  
-
-   ISO images — disc images containing data or bootable media for
-   operating systems
-
--  
-
-   Disk volume snapshots — saved copies of VM data which can be used for
-   data recovery or to create new templates
-
-The items in secondary storage are available to all hosts in the scope
-of the secondary storage, which may be defined as per zone or per
-region.
-
-To make items in secondary storage available to all hosts throughout the
-cloud, you can add object storage in addition to the zone-based NFS
-Secondary Staging Store. It is not necessary to copy templates and
-snapshots from one zone to another, as would be required when using zone
-NFS alone. Everything is available everywhere.
-
-For Hyper-V hosts, SMB/CIFS storage is supported.
-
-CloudStack provides plugins that enable both OpenStack Object Storage
-(Swift, `swift.openstack.org <http://swift.openstack.org>`__) and Amazon
-Simple Storage Service (S3) object storage. When using one of these
-storage plugins, you configure Swift or S3 storage for the entire
-CloudStack, then set up the NFS Secondary Staging Store for each zone.
-The NFS storage in each zone acts as a staging area through which all
-templates and other secondary storage data pass before being forwarded
-to Swift or S3. The backing object storage acts as a cloud-wide
-resource, making templates and other data available to any zone in the
-cloud.
-
-.. warning:: Heterogeneous Secondary Storage is not supported in Regions. For example, you cannot set up multiple zones, one using NFS secondary and the other using S3 or Swift secondary.
-
-About Physical Networks
------------------------
-
-Part of adding a zone is setting up the physical network. One or (in an
-advanced zone) more physical networks can be associated with each zone.
-The network corresponds to a NIC on the hypervisor host. Each physical
-network can carry one or more types of network traffic. The choices of
-traffic type for each network vary depending on whether you are creating
-a zone with basic networking or advanced networking.
-
-A physical network is the actual network hardware and wiring in a zone.
-A zone can have multiple physical networks. An administrator can:
-
--  
-
-   Add/Remove/Update physical networks in a zone
-
--  
-
-   Configure VLANs on the physical network
-
--  
-
-   Configure a name so the network can be recognized by hypervisors
-
--  
-
-   Configure the service providers (firewalls, load balancers, etc.)
-   available on a physical network
-
--  
-
-   Configure the IP addresses trunked to a physical network
-
--  
-
-   Specify what type of traffic is carried on the physical network, as
-   well as other properties like network speed
-
-Basic Zone Network Traffic Types
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When basic networking is used, there can be only one physical network in
-the zone. That physical network carries the following traffic types:
-
--  
-
-   Guest. When end users run VMs, they generate guest traffic. The guest
-   VMs communicate with each other over a network that can be referred
-   to as the guest network. Each pod in a basic zone is a broadcast
-   domain, and therefore each pod has a different IP range for the guest
-   network. The administrator must configure the IP range for each pod.
-
--  
-
-   Management. When CloudStack's internal resources communicate with
-   each other, they generate management traffic. This includes
-   communication between hosts, system VMs (VMs used by CloudStack to
-   perform various tasks in the cloud), and any other component that
-   communicates directly with the CloudStack Management Server. You must
-   configure the IP range for the system VMs to use.
-
-.. note:: We strongly recommend the use of separate NICs for management traffic
-   and guest traffic.
-
--  
-
-   Public. Public traffic is generated when VMs in the cloud access the
-   Internet. Publicly accessible IPs must be allocated for this purpose.
-   End users can use the CloudStack UI to acquire these IPs to implement
-   NAT between their guest network and the public network, as described
-   in Acquiring a New IP Address.
-
--  
-
-   Storage. While labeled "storage" this is specifically about secondary
-   storage, and doesn't affect traffic for primary storage. This
-   includes traffic such as VM templates and snapshots, which is sent
-   between the secondary storage VM and secondary storage servers.
-   CloudStack uses a separate Network Interface Controller (NIC) named
-   storage NIC for storage network traffic. Use of a storage NIC that
-   always operates on a high bandwidth network allows fast template and
-   snapshot copying. You must configure the IP range to use for the
-   storage network.
-
-In a basic network, configuring the physical network is fairly
-straightforward. In most cases, you only need to configure one guest
-network to carry traffic that is generated by guest VMs. If you use a
-NetScaler load balancer and enable its elastic IP and elastic load
-balancing (EIP and ELB) features, you must also configure a network to
-carry public traffic. CloudStack takes care of presenting the necessary
-network configuration steps to you in the UI when you add a new zone.
-
-Basic Zone Guest IP Addresses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When basic networking is used, CloudStack will assign IP addresses in
-the CIDR of the pod to the guests in that pod. The administrator must
-add a Direct IP range on the pod for this purpose. These IPs are in the
-same VLAN as the hosts.
-
-Advanced Zone Network Traffic Types
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When advanced networking is used, there can be multiple physical
-networks in the zone. Each physical network can carry one or more
-traffic types, and you need to let CloudStack know which type of network
-traffic you want each network to carry. The traffic types in an advanced
-zone are:
-
--  
-
-   Guest. When end users run VMs, they generate guest traffic. The guest
-   VMs communicate with each other over a network that can be referred
-   to as the guest network. This network can be isolated or shared. In
-   an isolated guest network, the administrator needs to reserve VLAN
-   ranges to provide isolation for each CloudStack account’s network
-   (potentially a large number of VLANs). In a shared guest network, all
-   guest VMs share a single network.
-
--  
-
-   Management. When CloudStack’s internal resources communicate with
-   each other, they generate management traffic. This includes
-   communication between hosts, system VMs (VMs used by CloudStack to
-   perform various tasks in the cloud), and any other component that
-   communicates directly with the CloudStack Management Server. You must
-   configure the IP range for the system VMs to use.
-
--  
-
-   Public. Public traffic is generated when VMs in the cloud access the
-   Internet. Publicly accessible IPs must be allocated for this purpose.
-   End users can use the CloudStack UI to acquire these IPs to implement
-   NAT between their guest network and the public network, as described
-   in “Acquiring a New IP Address” in the Administration Guide.
-
--  
-
-   Storage. While labeled "storage" this is specifically about secondary
-   storage, and doesn't affect traffic for primary storage. This
-   includes traffic such as VM templates and snapshots, which is sent
-   between the secondary storage VM and secondary storage servers.
-   CloudStack uses a separate Network Interface Controller (NIC) named
-   storage NIC for storage network traffic. Use of a storage NIC that
-   always operates on a high bandwidth network allows fast template and
-   snapshot copying. You must configure the IP range to use for the
-   storage network.
-
-These traffic types can each be on a separate physical network, or they
-can be combined with certain restrictions. When you use the Add Zone
-wizard in the UI to create a new zone, you are guided into making only
-valid choices.
-
-Advanced Zone Guest IP Addresses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When advanced networking is used, the administrator can create
-additional networks for use by the guests. These networks can span the
-zone and be available to all accounts, or they can be scoped to a single
-account, in which case only the named account may create guests that
-attach to these networks. The networks are defined by a VLAN ID, IP
-range, and gateway. The administrator may provision thousands of these
-networks if desired. Additionally, the administrator can reserve a part
-of the IP address space for non-CloudStack VMs and servers.
-
-Advanced Zone Public IP Addresses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When advanced networking is used, the administrator can create
-additional networks for use by the guests. These networks can span the
-zone and be available to all accounts, or they can be scoped to a single
-account, in which case only the named account may create guests that
-attach to these networks. The networks are defined by a VLAN ID, IP
-range, and gateway. The administrator may provision thousands of these
-networks if desired.
-
-System Reserved IP Addresses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In each zone, you need to configure a range of reserved IP addresses for
-the management network. This network carries communication between the
-CloudStack Management Server and various system VMs, such as Secondary
-Storage VMs, Console Proxy VMs, and DHCP.
-
-The reserved IP addresses must be unique across the cloud. You cannot,
-for example, have a host in one zone which has the same private IP
-address as a host in another zone.
-
-The hosts in a pod are assigned private IP addresses. These are
-typically RFC1918 addresses. The Console Proxy and Secondary Storage
-system VMs are also allocated private IP addresses in the CIDR of the
-pod that they are created in.
-
-Make sure computing servers and Management Servers use IP addresses
-outside of the System Reserved IP range. For example, suppose the System
-Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7.
-CloudStack can use .2 to .7 for System VMs. This leaves the rest of the
-pod CIDR, from .8 to .254, for the Management Server and hypervisor
-hosts.
-
-**In all zones:**
-
-Provide private IPs for the system in each pod and provision them in
-CloudStack.
-
-For KVM and XenServer, the recommended number of private IPs per pod is
-one per host. If you expect a pod to grow, add enough private IPs now to
-accommodate the growth.
-
-**In a zone that uses advanced networking:**
-
-For zones with advanced networking, we recommend provisioning enough
-private IPs for your total number of customers, plus enough for the
-required CloudStack System VMs. Typically, about 10 additional IPs are
-required for the System VMs. For more information about System VMs, see
-the section on working with SystemVMs in the Administrator's Guide.
-
-When advanced networking is being used, the number of private IP
-addresses available in each pod varies depending on which hypervisor is
-running on the nodes in that pod. Citrix XenServer and KVM use
-link-local addresses, which in theory provide more than 65,000 private
-IP addresses within the address block. As the pod grows over time, this
-should be more than enough for any reasonable number of hosts as well as
-IP addresses for guest virtual routers. VMWare ESXi, by contrast uses
-any administrator-specified subnetting scheme, and the typical
-administrator provides only 255 IPs per pod. Since these are shared by
-physical machines, the guest virtual router, and other entities, it is
-possible to run out of private IPs when scaling up a pod whose nodes are
-running ESXi.
-
-To ensure adequate headroom to scale private IP space in an ESXi pod
-that uses advanced networking, use one or both of the following
-techniques:
-
--  
-
-   Specify a larger CIDR block for the subnet. A subnet mask with a /20
-   suffix will provide more than 4,000 IP addresses.
-
--  
-
-   Create multiple pods, each with its own subnet. For example, if you
-   create 10 pods and each pod has 255 IPs, this will provide 2,550 IP
-   addresses.
-
-
-.. |1000-foot-view.png: Overview of CloudStack| image:: ./_static/images/1000-foot-view.png
-.. |basic-deployment.png: Basic two-machine deployment| image:: ./_static/images/basic-deployment.png
-.. |infrastructure_overview.png: Nested organization of a zone| image:: ./_static/images/infrastructure-overview.png
-.. |region-overview.png: Nested structure of a region.| image:: ./_static/images/region-overview.png
-.. |zone-overview.png: Nested structure of a simple zone.| image:: ./_static/images/zone-overview.png
-.. |pod-overview.png: Nested structure of a simple pod| image:: ./_static/images/pod-overview.png
-.. |cluster-overview.png: Structure of a simple cluster| image:: ./_static/images/cluster-overview.png
-.. |installation-complete.png: Finished installs with single Management Server and multiple Management Servers| image:: ./_static/images/installation-complete.png
-.. |change-password.png: button to change a user's password| image:: ./_static/images/change-password.png
-.. |provisioning-overview.png: Conceptual overview of a basic deployment| image:: ./_static/images/provisioning-overview.png
-.. |vsphereclient.png: vSphere client| image:: ./_static/images/vsphere-client.png
-.. |addcluster.png: add a cluster| image:: ./_static/images/add-cluster.png
-.. |ConsoleButton.png: button to launch a console| image:: ./_static/images/console-icon.png
-.. |DeleteButton.png: button to delete dvSwitch| image:: ./_static/images/delete-button.png
-.. |vds-name.png: Name of the dvSwitch as specified in the vCenter.| image:: ./_static/images/vds-name.png
-.. |traffic-type.png: virtual switch type| image:: ./_static/images/traffic-type.png
-.. |dvSwitchConfig.png: Configuring dvSwitch| image:: ./_static/images/dvSwitch-config.png
-.. |Small-Scale Deployment| image:: ./_static/images/small-scale-deployment.png
-.. |Large-Scale Redundant Setup| image:: ./_static/images/large-scale-redundant-setup.png
-.. |Multi-Node Management Server| image:: ./_static/images/multi-node-management-server.png
-.. |Example Of A Multi-Site Deployment| image:: ./_static/images/multi-site-deployment.png
-.. |Separate Storage Network| image:: ./_static/images/separate-storage-network.png
-.. |NIC Bonding And Multipath I/O| image:: ./_static/images/nic-bonding-and-multipath-io.png
-.. |Use the GUI to set the configuration variable to true| image:: ./_static/images/ec2-s3-configuration.png
-.. |Use the GUI to set the name of a compute service offering to an EC2 instance type API name.| image:: ./_static/images/compute-service-offerings.png
-.. |parallel-mode.png: adding a firewall and load balancer in parallel mode.| image:: ./_static/images/parallel-mode.png
-.. |guest-traffic-setup.png: Depicts a guest traffic setup| image:: ./_static/images/guest-traffic-setup.png
-.. |networksinglepod.png: diagram showing logical view of network in a pod| image:: ./_static/images/network-singlepod.png
-.. |networksetupzone.png: Depicts network setup in a single zone| image:: ./_static/images/network-setup-zone.png
-.. |addguestnetwork.png: Add Guest network setup in a single zone| image:: ./_static/images/add-guest-network.png
-.. |remove-nic.png: button to remove a NIC| image:: ./_static/images/remove-nic.png
-.. |set-default-nic.png: button to set a NIC as default one.| image:: ./_static/images/set-default-nic.png
-.. |EditButton.png: button to edit a network| image:: ./_static/images/edit-icon.png
-.. |edit-icon.png: button to edit a network| image:: ./_static/images/edit-icon.png
-.. |addAccount-icon.png: button to assign an IP range to an account.| image:: ./_static/images/addAccount-icon.png
-.. |eip-ns-basiczone.png: Elastic IP in a NetScaler-enabled Basic Zone.| image:: ./_static/images/eip-ns-basiczone.png
-.. |add-ip-range.png: adding an IP range to a network.| image:: ./_static/images/add-ip-range.png
-.. |httpaccess.png: allows inbound HTTP access from anywhere| image:: ./_static/images/http-access.png
-.. |autoscaleateconfig.png: Configuring AutoScale| image:: ./_static/images/autoscale-config.png
-.. |EnableDisable.png: button to enable or disable AutoScale.| image:: ./_static/images/enable-disable-autoscale.png
-.. |gslb.png: GSLB architecture| image:: ./_static/images/gslb.png
-.. |gslb-add.png: adding a gslb rule| image:: ./_static/images/add-gslb.png
-.. |ReleaseIPButton.png: button to release an IP| image:: ./_static/images/release-ip-icon.png
-.. |EnableNATButton.png: button to enable NAT| image:: ./_static/images/enable-disable.png
-.. |egress-firewall-rule.png: adding an egress firewall rule| image:: ./_static/images/egress-firewall-rule.png
-.. |AttachDiskButton.png: button to attach a volume| image:: ./_static/images/vpn-icon.png
-.. |vpn-icon.png: button to enable VPN| image:: ./_static/images/vpn-icon.png
-.. |addvpncustomergateway.png: adding a customer gateway.| image:: ./_static/images/add-vpn-customer-gateway.png
-.. |edit.png: button to edit a VPN customer gateway| image:: ./_static/images/edit-icon.png
-.. |delete.png: button to remove a VPN customer gateway| image:: ./_static/images/delete-button.png
-.. |createvpnconnection.png: creating a VPN connection to the customer gateway.| image:: ./_static/images/create-vpn-connection.png
-.. |remove-vpn.png: button to remove a VPN connection| image:: ./_static/images/remove-vpn.png
-.. |reset-vpn.png: button to reset a VPN connection| image:: ./_static/images/reset-vpn.png
-.. |mutltier.png: a multi-tier setup.| image:: ./_static/images/multi-tier-app.png
-.. |add-vpc.png: adding a vpc.| image:: ./_static/images/add-vpc.png
-.. |add-tier.png: adding a tier to a vpc.| image:: ./_static/images/add-tier.png
-.. |replace-acl-icon.png: button to replace an ACL list| image:: ./_static/images/replace-acl-icon.png
-.. |add-new-gateway-vpc.png: adding a private gateway for the VPC.| image:: ./_static/images/add-new-gateway-vpc.png
-.. |replace-acl-icon.png: button to replace the default ACL behaviour.| image:: ./_static/images/replace-acl-icon.png
-.. |add-vm-vpc.png: adding a VM to a vpc.| image:: ./_static/images/add-vm-vpc.png
-.. |addvm-tier-sharednw.png: adding a VM to a VPC tier and shared network.| image:: ./_static/images/addvm-tier-sharednw.png
-.. |release-ip-icon.png: button to release an IP.| image:: ./_static/images/release-ip-icon.png
-.. |enable-disable.png: button to enable Static NAT.| image:: ./_static/images/enable-disable.png
-.. |select-vmstatic-nat.png: selecting a tier to apply staticNAT.| image:: ./_static/images/select-vm-staticnat-vpc.png
-.. |vpc-lb.png: Configuring internal LB for VPC| image:: ./_static/images/vpc-lb.png
-.. |del-tier.png: button to remove a tier| image:: ./_static/images/del-tier.png
-.. |remove-vpc.png: button to remove a VPC| image:: ./_static/images/remove-vpc.png
-.. |edit-icon.png: button to edit a VPC| image:: ./_static/images/edit-icon.png
-.. |restart-vpc.png: button to restart a VPC| image:: ./_static/images/restart-vpc.png

[2/2] git commit: first re-org of installation guide

[se...@apache.org]

first re-org of installation guide


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/0bbd4264
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/tree/0bbd4264
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/diff/0bbd4264

Branch: refs/heads/master
Commit: 0bbd42645f0d9da283b9d734e0bae03c0dbc0d4c
Parents: 7fdaf61
Author: Sebastien Goasguen <ru...@gmail.com>
Authored: Wed Feb 12 16:10:23 2014 +0100
Committer: Sebastien Goasguen <ru...@gmail.com>
Committed: Wed Feb 12 16:10:23 2014 +0100

----------------------------------------------------------------------
 source/best_practices.rst                   | 128 -----
 source/choosing_deployment_architecture.rst | 188 +++++--
 source/choosing_hypervisor.rst              |  45 --
 source/concepts.rst                         | 567 +++++++++++++++++++-
 source/config_params.rst                    | 236 ---------
 source/configuration.rst                    | 153 ++++++
 source/index.rst                            |  72 +--
 source/qig.rst                              | 526 ++++++++++++++++++
 source/terminology.rst                      | 647 -----------------------
 9 files changed, 1418 insertions(+), 1144 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/0bbd4264/source/best_practices.rst
----------------------------------------------------------------------
diff --git a/source/best_practices.rst b/source/best_practices.rst
deleted file mode 100644
index a3174d5..0000000
--- a/source/best_practices.rst
+++ /dev/null
@@ -1,128 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information#
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-   http://www.apache.org/licenses/LICENSE-2.0
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-Best Practices
-==============
-
-Deploying a cloud is challenging. There are many different technology
-choices to make, and CloudStack is flexible enough in its configuration
-that there are many possible ways to combine and configure the chosen
-technology. This section contains suggestions and requirements about
-cloud deployments.
-
-These should be treated as suggestions and not absolutes. However, we do
-encourage anyone planning to build a cloud outside of these guidelines
-to seek guidance and advice on the project mailing lists.
-
-Process Best Practices
-----------------------
-
--  
-
-   A staging system that models the production environment is strongly
-   advised. It is critical if customizations have been applied to
-   CloudStack.
-
--  
-
-   Allow adequate time for installation, a beta, and learning the
-   system. Installs with basic networking can be done in hours. Installs
-   with advanced networking usually take several days for the first
-   attempt, with complicated installations taking longer. For a full
-   production system, allow at least 4-8 weeks for a beta to work
-   through all of the integration issues. You can get help from fellow
-   users on the cloudstack-users mailing list.
-
-Setup Best Practices
---------------------
-
--  
-
-   Each host should be configured to accept connections only from
-   well-known entities such as the CloudStack Management Server or your
-   network monitoring software.
-
--  
-
-   Use multiple clusters per pod if you need to achieve a certain switch
-   density.
-
--  
-
-   Primary storage mountpoints or LUNs should not exceed 6 TB in size.
-   It is better to have multiple smaller primary storage elements per
-   cluster than one large one.
-
--  
-
-   When exporting shares on primary storage, avoid data loss by
-   restricting the range of IP addresses that can access the storage.
-   See "Linux NFS on Local Disks and DAS" or "Linux NFS on iSCSI".
-
--  
-
-   NIC bonding is straightforward to implement and provides increased
-   reliability.
-
--  
-
-   10G networks are generally recommended for storage access when larger
-   servers that can support relatively more VMs are used.
-
--  
-
-   Host capacity should generally be modeled in terms of RAM for the
-   guests. Storage and CPU may be overprovisioned. RAM may not. RAM is
-   usually the limiting factor in capacity designs.
-
--  
-
-   (XenServer) Configure the XenServer dom0 settings to allocate more
-   memory to dom0. This can enable XenServer to handle larger numbers of
-   virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For
-   instructions on how to do this, see
-   `http://support.citrix.com/article/CTX126531 <http://support.citrix.com/article/CTX126531>`__.
-   The article refers to XenServer 5.6, but the same information applies
-   to XenServer 6.0.
-
-Maintenance Best Practices
---------------------------
-
--  
-
-   Monitor host disk space. Many host failures occur because the host's
-   root disk fills up from logs that were not rotated adequately.
-
--  
-
-   Monitor the total number of VM instances in each cluster, and disable
-   allocation to the cluster if the total is approaching the maximum
-   that the hypervisor can handle. Be sure to leave a safety margin to
-   allow for the possibility of one or more hosts failing, which would
-   increase the VM load on the other hosts as the VMs are redeployed.
-   Consult the documentation for your chosen hypervisor to find the
-   maximum permitted number of VMs per host, then use CloudStack global
-   configuration settings to set this as the default limit. Monitor the
-   VM activity in each cluster and keep the total number of VMs below a
-   safe level that allows for the occasional host failure. For example,
-   if there are N hosts in the cluster, and you want to allow for one
-   host in the cluster to be down at any given time, the total number of
-   VM instances you can permit in the cluster is at most (N-1) \*
-   (per-host-limit). Once a cluster reaches this number of VMs, use the
-   CloudStack UI to disable allocation to the cluster.
-
-.. warning:: The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
-
-Be sure all the hotfixes provided by the hypervisor vendor are applied. Track the release of hypervisor patches through your hypervisor vendor’s support channel, and apply patches as soon as possible after they are released. CloudStack will not track or notify you of required hypervisor patches. It is essential that your hosts are completely up to date with the provided hypervisor patches. The hypervisor vendor is likely to refuse to support any system that is not up to date with patches.

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/0bbd4264/source/choosing_deployment_architecture.rst
----------------------------------------------------------------------
diff --git a/source/choosing_deployment_architecture.rst b/source/choosing_deployment_architecture.rst
index b3ede21..c0fe699 100644
--- a/source/choosing_deployment_architecture.rst
+++ b/source/choosing_deployment_architecture.rst
@@ -176,6 +176,154 @@ Multipath I/O (MPIO). NIC bonding configuration involves only one
 network. MPIO involves two separate networks.
 
 
+Choosing a Hypervisor
+---------------------
+
+CloudStack supports many popular hypervisors. Your cloud can consist
+entirely of hosts running a single hypervisor, or you can use multiple
+hypervisors. Each cluster of hosts must run the same hypervisor.
+
+You might already have an installed base of nodes running a particular
+hypervisor, in which case, your choice of hypervisor has already been
+made. If you are starting from scratch, you need to decide what
+hypervisor software best suits your needs. A discussion of the relative
+advantages of each hypervisor is outside the scope of our documentation.
+However, it will help you to know which features of each hypervisor are
+supported by CloudStack. The following table provides this information.
+
+======================================================================================================  ===============  ===============  ==============  ===========
+Feature                                                                                                 XenServer 6.0.2  vSphere 4.1/5.0  KVM - RHEL 6.2  Bare Metal
+======================================================================================================  ===============  ===============  ==============  ===========
+Network Throttling                                                                                      Yes              Yes              No              N/A
+Security groups in zones that use basic networking                                                      Yes              No               Yes             No
+iSCSI                                                                                                   Yes              Yes              Yes             N/A
+FibreChannel                                                                                            Yes              Yes              Yes             N/A
+Local Disk                                                                                              Yes              Yes              Yes             Yes
+HA                                                                                                      Yes              Yes (Native)     Yes             N/A
+Snapshots of local disk                                                                                 Yes              Yes              Yes             N/A
+Local disk as data disk                                                                                 No               No               No              N/A
+Work load balancing                                                                                     No               DRS              No              N/A
+Manual live migration of VMs from host to host                                                          Yes              Yes              Yes             N/A
+Conserve management traffic IP address by using link local network to communicate with virtual router   Yes              No               Yes             N/A
+======================================================================================================  ===============  ===============  ==============  ===========
+
+
+Best Practices
+--------------
+
+Deploying a cloud is challenging. There are many different technology
+choices to make, and CloudStack is flexible enough in its configuration
+that there are many possible ways to combine and configure the chosen
+technology. This section contains suggestions and requirements about
+cloud deployments.
+
+These should be treated as suggestions and not absolutes. However, we do
+encourage anyone planning to build a cloud outside of these guidelines
+to seek guidance and advice on the project mailing lists.
+
+Process Best Practices
+~~~~~~~~~~~~~~~~~~~~~~
+
+-  
+
+   A staging system that models the production environment is strongly
+   advised. It is critical if customizations have been applied to
+   CloudStack.
+
+-  
+
+   Allow adequate time for installation, a beta, and learning the
+   system. Installs with basic networking can be done in hours. Installs
+   with advanced networking usually take several days for the first
+   attempt, with complicated installations taking longer. For a full
+   production system, allow at least 4-8 weeks for a beta to work
+   through all of the integration issues. You can get help from fellow
+   users on the cloudstack-users mailing list.
+
+Setup Best Practices
+~~~~~~~~~~~~~~~~~~~~
+
+-  
+
+   Each host should be configured to accept connections only from
+   well-known entities such as the CloudStack Management Server or your
+   network monitoring software.
+
+-  
+
+   Use multiple clusters per pod if you need to achieve a certain switch
+   density.
+
+-  
+
+   Primary storage mountpoints or LUNs should not exceed 6 TB in size.
+   It is better to have multiple smaller primary storage elements per
+   cluster than one large one.
+
+-  
+
+   When exporting shares on primary storage, avoid data loss by
+   restricting the range of IP addresses that can access the storage.
+   See "Linux NFS on Local Disks and DAS" or "Linux NFS on iSCSI".
+
+-  
+
+   NIC bonding is straightforward to implement and provides increased
+   reliability.
+
+-  
+
+   10G networks are generally recommended for storage access when larger
+   servers that can support relatively more VMs are used.
+
+-  
+
+   Host capacity should generally be modeled in terms of RAM for the
+   guests. Storage and CPU may be overprovisioned. RAM may not. RAM is
+   usually the limiting factor in capacity designs.
+
+-  
+
+   (XenServer) Configure the XenServer dom0 settings to allocate more
+   memory to dom0. This can enable XenServer to handle larger numbers of
+   virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For
+   instructions on how to do this, see
+   `http://support.citrix.com/article/CTX126531 <http://support.citrix.com/article/CTX126531>`__.
+   The article refers to XenServer 5.6, but the same information applies
+   to XenServer 6.0.
+
+Maintenance Best Practices
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  
+
+   Monitor host disk space. Many host failures occur because the host's
+   root disk fills up from logs that were not rotated adequately.
+
+-  
+
+   Monitor the total number of VM instances in each cluster, and disable
+   allocation to the cluster if the total is approaching the maximum
+   that the hypervisor can handle. Be sure to leave a safety margin to
+   allow for the possibility of one or more hosts failing, which would
+   increase the VM load on the other hosts as the VMs are redeployed.
+   Consult the documentation for your chosen hypervisor to find the
+   maximum permitted number of VMs per host, then use CloudStack global
+   configuration settings to set this as the default limit. Monitor the
+   VM activity in each cluster and keep the total number of VMs below a
+   safe level that allows for the occasional host failure. For example,
+   if there are N hosts in the cluster, and you want to allow for one
+   host in the cluster to be down at any given time, the total number of
+   VM instances you can permit in the cluster is at most (N-1) \*
+   (per-host-limit). Once a cluster reaches this number of VMs, use the
+   CloudStack UI to disable allocation to the cluster.
+
+.. warning:: The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+
+Be sure all the hotfixes provided by the hypervisor vendor are applied. Track the release of hypervisor patches through your hypervisor vendor’s support channel, and apply patches as soon as possible after they are released. CloudStack will not track or notify you of required hypervisor patches. It is essential that your hosts are completely up to date with the provided hypervisor patches. The hypervisor vendor is likely to refuse to support any system that is not up to date with patches.
+
+
+
 .. |1000-foot-view.png: Overview of CloudStack| image:: ./_static/images/1000-foot-view.png
 .. |basic-deployment.png: Basic two-machine deployment| image:: ./_static/images/basic-deployment.png
 .. |infrastructure_overview.png: Nested organization of a zone| image:: ./_static/images/infrastructure-overview.png
@@ -206,42 +354,4 @@ network. MPIO involves two separate networks.
 .. |networksinglepod.png: diagram showing logical view of network in a pod| image:: ./_static/images/network-singlepod.png
 .. |networksetupzone.png: Depicts network setup in a single zone| image:: ./_static/images/network-setup-zone.png
 .. |addguestnetwork.png: Add Guest network setup in a single zone| image:: ./_static/images/add-guest-network.png
-.. |remove-nic.png: button to remove a NIC| image:: ./_static/images/remove-nic.png
-.. |set-default-nic.png: button to set a NIC as default one.| image:: ./_static/images/set-default-nic.png
-.. |EditButton.png: button to edit a network| image:: ./_static/images/edit-icon.png
-.. |edit-icon.png: button to edit a network| image:: ./_static/images/edit-icon.png
-.. |addAccount-icon.png: button to assign an IP range to an account.| image:: ./_static/images/addAccount-icon.png
-.. |eip-ns-basiczone.png: Elastic IP in a NetScaler-enabled Basic Zone.| image:: ./_static/images/eip-ns-basiczone.png
-.. |add-ip-range.png: adding an IP range to a network.| image:: ./_static/images/add-ip-range.png
-.. |httpaccess.png: allows inbound HTTP access from anywhere| image:: ./_static/images/http-access.png
-.. |autoscaleateconfig.png: Configuring AutoScale| image:: ./_static/images/autoscale-config.png
-.. |EnableDisable.png: button to enable or disable AutoScale.| image:: ./_static/images/enable-disable-autoscale.png
-.. |gslb.png: GSLB architecture| image:: ./_static/images/gslb.png
-.. |gslb-add.png: adding a gslb rule| image:: ./_static/images/add-gslb.png
-.. |ReleaseIPButton.png: button to release an IP| image:: ./_static/images/release-ip-icon.png
-.. |EnableNATButton.png: button to enable NAT| image:: ./_static/images/enable-disable.png
-.. |egress-firewall-rule.png: adding an egress firewall rule| image:: ./_static/images/egress-firewall-rule.png
-.. |AttachDiskButton.png: button to attach a volume| image:: ./_static/images/vpn-icon.png
-.. |vpn-icon.png: button to enable VPN| image:: ./_static/images/vpn-icon.png
-.. |addvpncustomergateway.png: adding a customer gateway.| image:: ./_static/images/add-vpn-customer-gateway.png
-.. |edit.png: button to edit a VPN customer gateway| image:: ./_static/images/edit-icon.png
-.. |delete.png: button to remove a VPN customer gateway| image:: ./_static/images/delete-button.png
-.. |createvpnconnection.png: creating a VPN connection to the customer gateway.| image:: ./_static/images/create-vpn-connection.png
-.. |remove-vpn.png: button to remove a VPN connection| image:: ./_static/images/remove-vpn.png
-.. |reset-vpn.png: button to reset a VPN connection| image:: ./_static/images/reset-vpn.png
-.. |mutltier.png: a multi-tier setup.| image:: ./_static/images/multi-tier-app.png
-.. |add-vpc.png: adding a vpc.| image:: ./_static/images/add-vpc.png
-.. |add-tier.png: adding a tier to a vpc.| image:: ./_static/images/add-tier.png
-.. |replace-acl-icon.png: button to replace an ACL list| image:: ./_static/images/replace-acl-icon.png
-.. |add-new-gateway-vpc.png: adding a private gateway for the VPC.| image:: ./_static/images/add-new-gateway-vpc.png
-.. |replace-acl-icon.png: button to replace the default ACL behaviour.| image:: ./_static/images/replace-acl-icon.png
-.. |add-vm-vpc.png: adding a VM to a vpc.| image:: ./_static/images/add-vm-vpc.png
-.. |addvm-tier-sharednw.png: adding a VM to a VPC tier and shared network.| image:: ./_static/images/addvm-tier-sharednw.png
-.. |release-ip-icon.png: button to release an IP.| image:: ./_static/images/release-ip-icon.png
-.. |enable-disable.png: button to enable Static NAT.| image:: ./_static/images/enable-disable.png
-.. |select-vmstatic-nat.png: selecting a tier to apply staticNAT.| image:: ./_static/images/select-vm-staticnat-vpc.png
-.. |vpc-lb.png: Configuring internal LB for VPC| image:: ./_static/images/vpc-lb.png
-.. |del-tier.png: button to remove a tier| image:: ./_static/images/del-tier.png
-.. |remove-vpc.png: button to remove a VPC| image:: ./_static/images/remove-vpc.png
-.. |edit-icon.png: button to edit a VPC| image:: ./_static/images/edit-icon.png
-.. |restart-vpc.png: button to restart a VPC| image:: ./_static/images/restart-vpc.png
+

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/0bbd4264/source/choosing_hypervisor.rst
----------------------------------------------------------------------
diff --git a/source/choosing_hypervisor.rst b/source/choosing_hypervisor.rst
deleted file mode 100644
index 2df9425..0000000
--- a/source/choosing_hypervisor.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information#
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-   http://www.apache.org/licenses/LICENSE-2.0
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-Choosing a Hypervisor
-=====================
-
-CloudStack supports many popular hypervisors. Your cloud can consist
-entirely of hosts running a single hypervisor, or you can use multiple
-hypervisors. Each cluster of hosts must run the same hypervisor.
-
-You might already have an installed base of nodes running a particular
-hypervisor, in which case, your choice of hypervisor has already been
-made. If you are starting from scratch, you need to decide what
-hypervisor software best suits your needs. A discussion of the relative
-advantages of each hypervisor is outside the scope of our documentation.
-However, it will help you to know which features of each hypervisor are
-supported by CloudStack. The following table provides this information.
-
-======================================================================================================  ===============  ===============  ==============  ===========
-Feature                                                                                                 XenServer 6.0.2  vSphere 4.1/5.0  KVM - RHEL 6.2  Bare Metal
-======================================================================================================  ===============  ===============  ==============  ===========
-Network Throttling                                                                                      Yes              Yes              No              N/A
-Security groups in zones that use basic networking                                                      Yes              No               Yes             No
-iSCSI                                                                                                   Yes              Yes              Yes             N/A
-FibreChannel                                                                                            Yes              Yes              Yes             N/A
-Local Disk                                                                                              Yes              Yes              Yes             Yes
-HA                                                                                                      Yes              Yes (Native)     Yes             N/A
-Snapshots of local disk                                                                                 Yes              Yes              Yes             N/A
-Local disk as data disk                                                                                 No               No               No              N/A
-Work load balancing                                                                                     No               DRS              No              N/A
-Manual live migration of VMs from host to host                                                          Yes              Yes              Yes             N/A
-Conserve management traffic IP address by using link local network to communicate with virtual router   Yes              No               Yes             N/A
-======================================================================================================  ===============  ===============  ==============  ===========
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/0bbd4264/source/concepts.rst
----------------------------------------------------------------------
diff --git a/source/concepts.rst b/source/concepts.rst
index 7fbdca3..8fdf7b5 100644
--- a/source/concepts.rst
+++ b/source/concepts.rst
@@ -13,8 +13,8 @@
    specific language governing permissions and limitations
    under the License.
 
-Concepts
-========
+Concepts and Terminology
+========================
 
 What Is CloudStack?
 -------------------
@@ -241,6 +241,569 @@ CloudStack offers two types of networking scenario:
    Advanced. For more sophisticated network topologies. This network
    model provides the most flexibility in defining guest networks.
 
+
+CloudStack Terminology
+----------------------
+
+About Regions
+~~~~~~~~~~~~~
+
+To increase reliability of the cloud, you can optionally group resources
+into multiple geographic regions. A region is the largest available
+organizational unit within a CloudStack deployment. A region is made up
+of several availability zones, where each zone is roughly equivalent to
+a datacenter. Each region is controlled by its own cluster of Management
+Servers, running in one of the zones. The zones in a region are
+typically located in close geographical proximity. Regions are a useful
+technique for providing fault tolerance and disaster recovery.
+
+By grouping zones into regions, the cloud can achieve higher
+availability and scalability. User accounts can span regions, so that
+users can deploy VMs in multiple, widely-dispersed regions. Even if one
+of the regions becomes unavailable, the services are still available to
+the end-user through VMs deployed in another region. And by grouping
+communities of zones under their own nearby Management Servers, the
+latency of communications within the cloud is reduced compared to
+managing widely-dispersed zones from a single central Management Server.
+
+Usage records can also be consolidated and tracked at the region level,
+creating reports or invoices for each geographic region.
+
+|region-overview.png: Nested structure of a region.|
+
+Regions are visible to the end user. When a user starts a guest VM on a
+particular CloudStack Management Server, the user is implicitly
+selecting that region for their guest. Users might also be required to
+copy their private templates to additional regions to enable creation of
+guest VMs using their templates in those regions.
+
+About Zones
+~~~~~~~~~~~
+
+A zone is the second largest organizational unit within a CloudStack
+deployment. A zone typically corresponds to a single datacenter,
+although it is permissible to have multiple zones in a datacenter. The
+benefit of organizing infrastructure into zones is to provide physical
+isolation and redundancy. For example, each zone can have its own power
+supply and network uplink, and the zones can be widely separated
+geographically (though this is not required).
+
+A zone consists of:
+
+-  
+
+   One or more pods. Each pod contains one or more clusters of hosts and
+   one or more primary storage servers.
+
+-  
+
+   A zone may contain one or more primary storage servers, which are
+   shared by all the pods in the zone.
+
+-  
+
+   Secondary storage, which is shared by all the pods in the zone.
+
+|zone-overview.png: Nested structure of a simple zone.|
+
+Zones are visible to the end user. When a user starts a guest VM, the
+user must select a zone for their guest. Users might also be required to
+copy their private templates to additional zones to enable creation of
+guest VMs using their templates in those zones.
+
+Zones can be public or private. Public zones are visible to all users.
+This means that any user may create a guest in that zone. Private zones
+are reserved for a specific domain. Only users in that domain or its
+subdomains may create guests in that zone.
+
+Hosts in the same zone are directly accessible to each other without
+having to go through a firewall. Hosts in different zones can access
+each other through statically configured VPN tunnels.
+
+For each zone, the administrator must decide the following.
+
+-  
+
+   How many pods to place in each zone.
+
+-  
+
+   How many clusters to place in each pod.
+
+-  
+
+   How many hosts to place in each cluster.
+
+-  
+
+   (Optional) How many primary storage servers to place in each zone and
+   total capacity for these storage servers.
+
+-  
+
+   How many primary storage servers to place in each cluster and total
+   capacity for these storage servers.
+
+-  
+
+   How much secondary storage to deploy in a zone.
+
+When you add a new zone using the CloudStack UI, you will be prompted to
+configure the zone’s physical network and add the first pod, cluster,
+host, primary storage, and secondary storage.
+
+In order to support zone-wide functions for VMware, CloudStack is aware
+of VMware Datacenters and can map each Datacenter to a CloudStack zone.
+To enable features like storage live migration and zone-wide primary
+storage for VMware hosts, CloudStack has to make sure that a zone
+contains only a single VMware Datacenter. Therefore, when you are
+creating a new CloudStack zone, you can select a VMware Datacenter for
+the zone. If you are provisioning multiple VMware Datacenters, each one
+will be set up as a single zone in CloudStack.
+
+.. note:: If you are upgrading from a previous CloudStack version, and your existing deployment contains a zone with clusters from multiple VMware Datacenters, that zone will not be forcibly migrated to the new model. It will continue to function as before. However, any new zone-wide operations, such as zone-wide primary storage and live storage migration, will not be available in that zone.
+
+About Pods
+~~~~~~~~~~
+
+A pod often represents a single rack. Hosts in the same pod are in the
+same subnet. A pod is the third-largest organizational unit within a
+CloudStack deployment. Pods are contained within zones. Each zone can
+contain one or more pods. A pod consists of one or more clusters of
+hosts and one or more primary storage servers. Pods are not visible to
+the end user.
+
+|pod-overview.png: Nested structure of a simple pod|
+
+About Clusters
+~~~~~~~~~~~~~~
+
+A cluster provides a way to group hosts. To be precise, a cluster is a
+XenServer server pool, a set of KVM servers, , or a VMware cluster
+preconfigured in vCenter. The hosts in a cluster all have identical
+hardware, run the same hypervisor, are on the same subnet, and access
+the same shared primary storage. Virtual machine instances (VMs) can be
+live-migrated from one host to another within the same cluster, without
+interrupting service to the user.
+
+A cluster is the fourth-largest organizational unit within a CloudStack
+deployment. Clusters are contained within pods, and pods are contained
+within zones. Size of the cluster is limited by the underlying
+hypervisor, although the CloudStack recommends less in most cases; see
+Best Practices.
+
+A cluster consists of one or more hosts and one or more primary storage
+servers.
+
+|cluster-overview.png: Structure of a simple cluster|
+
+CloudStack allows multiple clusters in a cloud deployment.
+
+Even when local storage is used exclusively, clusters are still required
+organizationally, even if there is just one host per cluster.
+
+When VMware is used, every VMware cluster is managed by a vCenter
+server. An Administrator must register the vCenter server with
+CloudStack. There may be multiple vCenter servers per zone. Each vCenter
+server may manage multiple VMware clusters.
+
+About Hosts
+~~~~~~~~~~~
+
+A host is a single computer. Hosts provide the computing resources that
+run guest virtual machines. Each host has hypervisor software installed
+on it to manage the guest VMs. For example, a host can be a Citrix
+XenServer server, a Linux KVM-enabled server, an ESXi server, or a
+Windows Hyper-V server.
+
+The host is the smallest organizational unit within a CloudStack
+deployment. Hosts are contained within clusters, clusters are contained
+within pods, pods are contained within zones, and zones can be contained
+within regions.
+
+Hosts in a CloudStack deployment:
+
+-  
+
+   Provide the CPU, memory, storage, and networking resources needed to
+   host the virtual machines
+
+-  
+
+   Interconnect using a high bandwidth TCP/IP network and connect to the
+   Internet
+
+-  
+
+   May reside in multiple data centers across different geographic
+   locations
+
+-  
+
+   May have different capacities (different CPU speeds, different
+   amounts of RAM, etc.), although the hosts within a cluster must all
+   be homogeneous
+
+Additional hosts can be added at any time to provide more capacity for
+guest VMs.
+
+CloudStack automatically detects the amount of CPU and memory resources
+provided by the hosts.
+
+Hosts are not visible to the end user. An end user cannot determine
+which host their guest has been assigned to.
+
+For a host to function in CloudStack, you must do the following:
+
+-  
+
+   Install hypervisor software on the host
+
+-  
+
+   Assign an IP address to the host
+
+-  
+
+   Ensure the host is connected to the CloudStack Management Server.
+
+About Primary Storage
+~~~~~~~~~~~~~~~~~~~~~
+
+Primary storage is associated with a cluster or (in KVM and VMware) a
+zone, and it stores the disk volumes for all the VMs running on hosts.
+
+You can add multiple primary storage servers to a cluster or zone. At
+least one is required. It is typically located close to the hosts for
+increased performance. CloudStack manages the allocation of guest
+virtual disks to particular primary storage devices.
+
+It is useful to set up zone-wide primary storage when you want to avoid
+extra data copy operations. With cluster-based primary storage, data in
+the primary storage is directly available only to VMs within that
+cluster. If a VM in a different cluster needs some of the data, it must
+be copied from one cluster to another, using the zone's secondary
+storage as an intermediate step. This operation can be unnecessarily
+time-consuming.
+
+For Hyper-V, SMB/CIFS storage is supported. Note that Zone-wide Primary
+Storage is not supported in Hyper-V.
+
+CloudStack is designed to work with all standards-compliant iSCSI and
+NFS servers that are supported by the underlying hypervisor, including,
+for example:
+
+-
+
+   SolidFire for iSCSI
+
+-  
+
+   Dell EqualLogic™ for iSCSI
+
+-  
+
+   Network Appliances filers for NFS and iSCSI
+
+-  
+
+   Scale Computing for NFS
+
+If you intend to use only local disk for your installation, you can skip
+adding separate primary storage.
+
+About Secondary Storage
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Secondary storage stores the following:
+
+-  
+
+   Templates — OS images that can be used to boot VMs and can include
+   additional configuration information, such as installed applications
+
+-  
+
+   ISO images — disc images containing data or bootable media for
+   operating systems
+
+-  
+
+   Disk volume snapshots — saved copies of VM data which can be used for
+   data recovery or to create new templates
+
+The items in secondary storage are available to all hosts in the scope
+of the secondary storage, which may be defined as per zone or per
+region.
+
+To make items in secondary storage available to all hosts throughout the
+cloud, you can add object storage in addition to the zone-based NFS
+Secondary Staging Store. It is not necessary to copy templates and
+snapshots from one zone to another, as would be required when using zone
+NFS alone. Everything is available everywhere.
+
+For Hyper-V hosts, SMB/CIFS storage is supported.
+
+CloudStack provides plugins that enable both OpenStack Object Storage
+(Swift, `swift.openstack.org <http://swift.openstack.org>`__) and Amazon
+Simple Storage Service (S3) object storage. When using one of these
+storage plugins, you configure Swift or S3 storage for the entire
+CloudStack, then set up the NFS Secondary Staging Store for each zone.
+The NFS storage in each zone acts as a staging area through which all
+templates and other secondary storage data pass before being forwarded
+to Swift or S3. The backing object storage acts as a cloud-wide
+resource, making templates and other data available to any zone in the
+cloud.
+
+.. warning:: Heterogeneous Secondary Storage is not supported in Regions. For example, you cannot set up multiple zones, one using NFS secondary and the other using S3 or Swift secondary.
+
+About Physical Networks
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Part of adding a zone is setting up the physical network. One or (in an
+advanced zone) more physical networks can be associated with each zone.
+The network corresponds to a NIC on the hypervisor host. Each physical
+network can carry one or more types of network traffic. The choices of
+traffic type for each network vary depending on whether you are creating
+a zone with basic networking or advanced networking.
+
+A physical network is the actual network hardware and wiring in a zone.
+A zone can have multiple physical networks. An administrator can:
+
+-  
+
+   Add/Remove/Update physical networks in a zone
+
+-  
+
+   Configure VLANs on the physical network
+
+-  
+
+   Configure a name so the network can be recognized by hypervisors
+
+-  
+
+   Configure the service providers (firewalls, load balancers, etc.)
+   available on a physical network
+
+-  
+
+   Configure the IP addresses trunked to a physical network
+
+-  
+
+   Specify what type of traffic is carried on the physical network, as
+   well as other properties like network speed
+
+Basic Zone Network Traffic Types
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When basic networking is used, there can be only one physical network in
+the zone. That physical network carries the following traffic types:
+
+-  
+
+   Guest. When end users run VMs, they generate guest traffic. The guest
+   VMs communicate with each other over a network that can be referred
+   to as the guest network. Each pod in a basic zone is a broadcast
+   domain, and therefore each pod has a different IP range for the guest
+   network. The administrator must configure the IP range for each pod.
+
+-  
+
+   Management. When CloudStack's internal resources communicate with
+   each other, they generate management traffic. This includes
+   communication between hosts, system VMs (VMs used by CloudStack to
+   perform various tasks in the cloud), and any other component that
+   communicates directly with the CloudStack Management Server. You must
+   configure the IP range for the system VMs to use.
+
+.. note:: We strongly recommend the use of separate NICs for management traffic
+   and guest traffic.
+
+-  
+
+   Public. Public traffic is generated when VMs in the cloud access the
+   Internet. Publicly accessible IPs must be allocated for this purpose.
+   End users can use the CloudStack UI to acquire these IPs to implement
+   NAT between their guest network and the public network, as described
+   in Acquiring a New IP Address.
+
+-  
+
+   Storage. While labeled "storage" this is specifically about secondary
+   storage, and doesn't affect traffic for primary storage. This
+   includes traffic such as VM templates and snapshots, which is sent
+   between the secondary storage VM and secondary storage servers.
+   CloudStack uses a separate Network Interface Controller (NIC) named
+   storage NIC for storage network traffic. Use of a storage NIC that
+   always operates on a high bandwidth network allows fast template and
+   snapshot copying. You must configure the IP range to use for the
+   storage network.
+
+In a basic network, configuring the physical network is fairly
+straightforward. In most cases, you only need to configure one guest
+network to carry traffic that is generated by guest VMs. If you use a
+NetScaler load balancer and enable its elastic IP and elastic load
+balancing (EIP and ELB) features, you must also configure a network to
+carry public traffic. CloudStack takes care of presenting the necessary
+network configuration steps to you in the UI when you add a new zone.
+
+Basic Zone Guest IP Addresses
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When basic networking is used, CloudStack will assign IP addresses in
+the CIDR of the pod to the guests in that pod. The administrator must
+add a Direct IP range on the pod for this purpose. These IPs are in the
+same VLAN as the hosts.
+
+Advanced Zone Network Traffic Types
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When advanced networking is used, there can be multiple physical
+networks in the zone. Each physical network can carry one or more
+traffic types, and you need to let CloudStack know which type of network
+traffic you want each network to carry. The traffic types in an advanced
+zone are:
+
+-  
+
+   Guest. When end users run VMs, they generate guest traffic. The guest
+   VMs communicate with each other over a network that can be referred
+   to as the guest network. This network can be isolated or shared. In
+   an isolated guest network, the administrator needs to reserve VLAN
+   ranges to provide isolation for each CloudStack account’s network
+   (potentially a large number of VLANs). In a shared guest network, all
+   guest VMs share a single network.
+
+-  
+
+   Management. When CloudStack’s internal resources communicate with
+   each other, they generate management traffic. This includes
+   communication between hosts, system VMs (VMs used by CloudStack to
+   perform various tasks in the cloud), and any other component that
+   communicates directly with the CloudStack Management Server. You must
+   configure the IP range for the system VMs to use.
+
+-  
+
+   Public. Public traffic is generated when VMs in the cloud access the
+   Internet. Publicly accessible IPs must be allocated for this purpose.
+   End users can use the CloudStack UI to acquire these IPs to implement
+   NAT between their guest network and the public network, as described
+   in “Acquiring a New IP Address” in the Administration Guide.
+
+-  
+
+   Storage. While labeled "storage" this is specifically about secondary
+   storage, and doesn't affect traffic for primary storage. This
+   includes traffic such as VM templates and snapshots, which is sent
+   between the secondary storage VM and secondary storage servers.
+   CloudStack uses a separate Network Interface Controller (NIC) named
+   storage NIC for storage network traffic. Use of a storage NIC that
+   always operates on a high bandwidth network allows fast template and
+   snapshot copying. You must configure the IP range to use for the
+   storage network.
+
+These traffic types can each be on a separate physical network, or they
+can be combined with certain restrictions. When you use the Add Zone
+wizard in the UI to create a new zone, you are guided into making only
+valid choices.
+
+Advanced Zone Guest IP Addresses
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When advanced networking is used, the administrator can create
+additional networks for use by the guests. These networks can span the
+zone and be available to all accounts, or they can be scoped to a single
+account, in which case only the named account may create guests that
+attach to these networks. The networks are defined by a VLAN ID, IP
+range, and gateway. The administrator may provision thousands of these
+networks if desired. Additionally, the administrator can reserve a part
+of the IP address space for non-CloudStack VMs and servers.
+
+Advanced Zone Public IP Addresses
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When advanced networking is used, the administrator can create
+additional networks for use by the guests. These networks can span the
+zone and be available to all accounts, or they can be scoped to a single
+account, in which case only the named account may create guests that
+attach to these networks. The networks are defined by a VLAN ID, IP
+range, and gateway. The administrator may provision thousands of these
+networks if desired.
+
+System Reserved IP Addresses
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In each zone, you need to configure a range of reserved IP addresses for
+the management network. This network carries communication between the
+CloudStack Management Server and various system VMs, such as Secondary
+Storage VMs, Console Proxy VMs, and DHCP.
+
+The reserved IP addresses must be unique across the cloud. You cannot,
+for example, have a host in one zone which has the same private IP
+address as a host in another zone.
+
+The hosts in a pod are assigned private IP addresses. These are
+typically RFC1918 addresses. The Console Proxy and Secondary Storage
+system VMs are also allocated private IP addresses in the CIDR of the
+pod that they are created in.
+
+Make sure computing servers and Management Servers use IP addresses
+outside of the System Reserved IP range. For example, suppose the System
+Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7.
+CloudStack can use .2 to .7 for System VMs. This leaves the rest of the
+pod CIDR, from .8 to .254, for the Management Server and hypervisor
+hosts.
+
+**In all zones:**
+
+Provide private IPs for the system in each pod and provision them in
+CloudStack.
+
+For KVM and XenServer, the recommended number of private IPs per pod is
+one per host. If you expect a pod to grow, add enough private IPs now to
+accommodate the growth.
+
+**In a zone that uses advanced networking:**
+
+For zones with advanced networking, we recommend provisioning enough
+private IPs for your total number of customers, plus enough for the
+required CloudStack System VMs. Typically, about 10 additional IPs are
+required for the System VMs. For more information about System VMs, see
+the section on working with SystemVMs in the Administrator's Guide.
+
+When advanced networking is being used, the number of private IP
+addresses available in each pod varies depending on which hypervisor is
+running on the nodes in that pod. Citrix XenServer and KVM use
+link-local addresses, which in theory provide more than 65,000 private
+IP addresses within the address block. As the pod grows over time, this
+should be more than enough for any reasonable number of hosts as well as
+IP addresses for guest virtual routers. VMWare ESXi, by contrast uses
+any administrator-specified subnetting scheme, and the typical
+administrator provides only 255 IPs per pod. Since these are shared by
+physical machines, the guest virtual router, and other entities, it is
+possible to run out of private IPs when scaling up a pod whose nodes are
+running ESXi.
+
+To ensure adequate headroom to scale private IP space in an ESXi pod
+that uses advanced networking, use one or both of the following
+techniques:
+
+-  
+
+   Specify a larger CIDR block for the subnet. A subnet mask with a /20
+   suffix will provide more than 4,000 IP addresses.
+
+-  
+
+   Create multiple pods, each with its own subnet. For example, if you
+   create 10 pods and each pod has 255 IPs, this will provide 2,550 IP
+   addresses.
+
+
 .. |1000-foot-view.png: Overview of CloudStack| image:: ./_static/images/1000-foot-view.png
 .. |basic-deployment.png: Basic two-machine deployment| image:: ./_static/images/basic-deployment.png
 .. |infrastructure_overview.png: Nested organization of a zone| image:: ./_static/images/infrastructure-overview.png

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/0bbd4264/source/config_params.rst
----------------------------------------------------------------------
diff --git a/source/config_params.rst b/source/config_params.rst
deleted file mode 100644
index a206dd9..0000000
--- a/source/config_params.rst
+++ /dev/null
@@ -1,236 +0,0 @@
-.. Licensed to the Apache Software Foundation (ASF) under one
-   or more contributor license agreements.  See the NOTICE file
-   distributed with this work for additional information#
-   regarding copyright ownership.  The ASF licenses this file
-   to you under the Apache License, Version 2.0 (the
-   "License"); you may not use this file except in compliance
-   with the License.  You may obtain a copy of the License at
-   http://www.apache.org/licenses/LICENSE-2.0
-   Unless required by applicable law or agreed to in writing,
-   software distributed under the License is distributed on an
-   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-   KIND, either express or implied.  See the License for the
-   specific language governing permissions and limitations
-   under the License.
-
-Configuration Parameters
-========================
-
-About Configuration Parameters
-------------------------------
-
-CloudStack provides a variety of settings you can use to set limits,
-configure features, and enable or disable features in the cloud. Once
-your Management Server is running, you might need to set some of these
-configuration parameters, depending on what optional features you are
-setting up. You can set default values at the global level, which will
-be in effect throughout the cloud unless you override them at a lower
-level. You can make local settings, which will override the global
-configuration parameter values, at the level of an account, zone,
-cluster, or primary storage.
-
-The documentation for each CloudStack feature should direct you to the
-names of the applicable parameters. The following table shows a few of
-the more useful parameters.
-
-=================================  ================================================================================
-Field                              Value
-=================================  ================================================================================
-management.network.cidr            A CIDR that describes the network that the management CIDRs reside on. This                                        variable must be set for deployments that use vSphere. It is recommended to be                                     set for other deployments as well. Example: 192.168.3.0/24.
-xen.setup.multipath                For XenServer nodes, this is a true/false variable that instructs CloudStack to                                    enable iSCSI multipath on the XenServer Hosts when they are added. This                                            defaults to false. Set it to true if you would like CloudStack to enable                                           multipath.If this is true for a NFS-based deployment multipath will still be                                       enabled on the XenServer host. However, this does not impact NFS operation and                                     is harmless.
-secstorage.allowed.internal.sites  This is used to protect your internal network from rogue attempts to download                                      arbitrary files using the template download feature. This is a comma-separated                                     list of CIDRs. If a requested URL matches any of these CIDRs the Secondary                                         Storage VM will use the private network interface to fetch the URL. Other URLs                                     will go through the public interface. We suggest you set this to 1 or 2                                            hardened internal machines where you keep your templates. For example, set it                                      to 192.168.1.66/32.
-use.local.storage                  Determines whether CloudStack will use storage that is local to the Host for                                       data disks, templates, and snapshots. By default CloudStack will not use this                                      storage. You should change this to true if you want to use local storage and                                       you understand the reliability and feature drawbacks to choosing local storage.
-host                               This is the IP address of the Management Server. If you are using multiple                                         Management Servers you should enter a load balanced IP address that is                                             reachable via the private network.
-default.page.size                  Maximum number of items per page that can be returned by a CloudStack API                                          command. The limit applies at the cloud level and can vary from cloud to cloud.                                    You can override this with a lower value on a particular API call by using the                                     page and pagesize API command parameters. For more information, see the                                            Developer's Guide. Default: 500.
-ha.tag                             The label you want to use throughout the cloud to designate certain hosts as                                       dedicated HA hosts. These hosts will be used only for HA-enabled VMs that are                                      restarting due to the failure of another host. For example, you could set this                                     to ha\_host. Specify the ha.tag value asa host tag when you add a new host to                                      the cloud.
-vmware.vcenter.session.timeout     Determines the vCenter session timeout value by using this parameter. The                                          default value is 20 minutes. Increase the timeout value to avoid timeout errors                                    in VMware deployments because certain VMware operations take more than 20                                          minutes.
-=================================  ================================================================================
-
-Setting Global Configuration Parameters
----------------------------------------
-
-Use the following steps to set global configuration parameters. These
-values will be the defaults in effect throughout your CloudStack
-deployment.
-
-#. 
-
-   Log in to the UI as administrator.
-
-#. 
-
-   In the left navigation bar, click Global Settings.
-
-#. 
-
-   In Select View, choose one of the following:
-
-   -  
-
-      Global Settings. This displays a list of the parameters with brief
-      descriptions and current values.
-
-   -  
-
-      Hypervisor Capabilities. This displays a list of hypervisor
-      versions with the maximum number of guests supported for each.
-
-#. 
-
-   Use the search box to narrow down the list to those you are
-   interested in.
-
-#. 
-
-   In the Actions column, click the Edit icon to modify a value. If you
-   are viewing Hypervisor Capabilities, you must click the name of the
-   hypervisor first to display the editing screen.
-
-Setting Local Configuration Parameters
---------------------------------------
-
-Use the following steps to set local configuration parameters for an
-account, zone, cluster, or primary storage. These values will override
-the global configuration settings.
-
-#. 
-
-   Log in to the UI as administrator.
-
-#. 
-
-   In the left navigation bar, click Infrastructure or Accounts,
-   depending on where you want to set a value.
-
-#. 
-
-   Find the name of the particular resource that you want to work with.
-   For example, if you are in Infrastructure, click View All on the
-   Zones, Clusters, or Primary Storage area.
-
-#. 
-
-   Click the name of the resource where you want to set a limit.
-
-#. 
-
-   Click the Settings tab.
-
-#. 
-
-   Use the search box to narrow down the list to those you are
-   interested in.
-
-#. 
-
-   In the Actions column, click the Edit icon to modify a value.
-
-Granular Global Configuration Parameters
-----------------------------------------
-
-The following global configuration parameters have been made more
-granular. The parameters are listed under three different scopes:
-account, cluster, and zone.
-
-========  =========================================================  ======================================================================================================================================
-Field     Field		                                                 Value
-========  =========================================================  ======================================================================================================================================
-account   remote.access.vpn.client.iprange                           The range of IPs to be allocated to remotely access the VPN clients. The first IP in the range is                                                                                                          used by the VPN server.
-account   allow.public.user.templates                                If false, users will not be able to create public templates.
-account   use.system.public.ips                                      If true and if an account has one or more dedicated public IP ranges, IPs are                                                                                                                              acquired from the system pool after all the IPs dedicated to the account have been consumed.
-account   use.system.guest.vlans                                     If true and if an account has one or more dedicated guest VLAN ranges, VLANs are allocated from the                                                                                                        system pool after all the VLANs dedicated to the account have been consumed.
-cluster   cluster.storage.allocated.capacity.notificationthreshold   The percentage, as a value between 0 and 1, of allocated storage utilization                                                                                                                               above which alerts are sent that the storage is below the threshold.
-cluster   cluster.storage.capacity.notificationthreshold             The percentage, as a value between 0 and 1, of storage utilization above which alerts are sent that the available storage is below                                                                         the threshold.
-cluster   cluster.cpu.allocated.capacity.notificationthreshold       The percentage, as a value between 0 and 1, of cpu utilization above which alerts are sent that the available CPU is below the                                                                             threshold.
-cluster   cluster.memory.allocated.capacity.notificationthreshold    The percentage, as a value between 0 and 1, of memory utilization above which alerts are sent that the available memory is below the                                                                       threshold.
-cluster   cluster.cpu.allocated.capacity.disablethreshold            The percentage, as a value between 0 and 1, of CPU utilization above which allocators will disable that cluster from further usage.                                                                        Keep the corresponding notification threshold lower than this value to be notified beforehand.
-cluster   cluster.memory.allocated.capacity.disablethreshold         The percentage, as a value between 0 and 1, of memory utilization above which allocators will disable that cluster from further                                                                            usage. Keep the corresponding notification threshold lower than this value to be notified beforehand.
-cluster   cpu.overprovisioning.factor                                Used for CPU over-provisioning calculation; the available CPU will be
-                                                                     the mathematical product of actualCpuCapacity and cpu.overprovisioning.factor.
-cluster   mem.overprovisioning.factor                                Used for memory over-provisioning calculation.
-cluster   vmware.reserve.cpu                                         Specify whether or not to reserve CPU when not over-provisioning; In case of CPU over-provisioning, CPU is always reserved.
-cluster   vmware.reserve.mem                                         Specify whether or not to reserve memory when not over-provisioning; In case of memory over-provisioning memory is always reserved.
-zone      pool.storage.allocated.capacity.disablethreshold           The percentage, as a value between 0 and 1, of allocated storage utilization above which allocators will disable that pool because the
-                                                                     available allocated storage is below the threshold.
-zone      pool.storage.capacity.disablethreshold                     The percentage, as a value between 0 and 1, of storage utilization above which allocators will disable the pool because the available                                                                      storage capacity is below the threshold.
-zone      storage.overprovisioning.factor                            Used for storage over-provisioning calculation; available storage will be the mathematical product of actualStorageSize and                                                                                storage.overprovisioning.factor.
-zone      network.throttling.rate                                    Default data transfer rate in megabits per second allowed in a network.
-zone      guest.domain.suffix                                        Default domain name for VMs inside a virtual networks with a router.
-zone      router.template.xen                                        Name of the default router template on Xenserver.
-zone      router.template.kvm                                        Name of the default router template on KVM.
-zone      router.template.vmware                                     Name of the default router template on VMware.
-zone      enable.dynamic.scale.vm                                    Enable or diable dynamically scaling of a VM.
-zone      use.external.dns                                           Bypass internal DNS, and use the external DNS1 and DNS2
-zone      blacklisted.routes                                         Routes that are blacklisted cannot be used for creating static routes for a VPC Private Gateway.
-========  =========================================================  ======================================================================================================================================  
-
-
-.. |1000-foot-view.png: Overview of CloudStack| image:: ./_static/images/1000-foot-view.png
-.. |basic-deployment.png: Basic two-machine deployment| image:: ./_static/images/basic-deployment.png
-.. |infrastructure_overview.png: Nested organization of a zone| image:: ./_static/images/infrastructure-overview.png
-.. |region-overview.png: Nested structure of a region.| image:: ./_static/images/region-overview.png
-.. |zone-overview.png: Nested structure of a simple zone.| image:: ./_static/images/zone-overview.png
-.. |pod-overview.png: Nested structure of a simple pod| image:: ./_static/images/pod-overview.png
-.. |cluster-overview.png: Structure of a simple cluster| image:: ./_static/images/cluster-overview.png
-.. |installation-complete.png: Finished installs with single Management Server and multiple Management Servers| image:: ./_static/images/installation-complete.png
-.. |change-password.png: button to change a user's password| image:: ./_static/images/change-password.png
-.. |provisioning-overview.png: Conceptual overview of a basic deployment| image:: ./_static/images/provisioning-overview.png
-.. |vsphereclient.png: vSphere client| image:: ./_static/images/vsphere-client.png
-.. |addcluster.png: add a cluster| image:: ./_static/images/add-cluster.png
-.. |ConsoleButton.png: button to launch a console| image:: ./_static/images/console-icon.png
-.. |DeleteButton.png: button to delete dvSwitch| image:: ./_static/images/delete-button.png
-.. |vds-name.png: Name of the dvSwitch as specified in the vCenter.| image:: ./_static/images/vds-name.png
-.. |traffic-type.png: virtual switch type| image:: ./_static/images/traffic-type.png
-.. |dvSwitchConfig.png: Configuring dvSwitch| image:: ./_static/images/dvSwitch-config.png
-.. |Small-Scale Deployment| image:: ./_static/images/small-scale-deployment.png
-.. |Large-Scale Redundant Setup| image:: ./_static/images/large-scale-redundant-setup.png
-.. |Multi-Node Management Server| image:: ./_static/images/multi-node-management-server.png
-.. |Example Of A Multi-Site Deployment| image:: ./_static/images/multi-site-deployment.png
-.. |Separate Storage Network| image:: ./_static/images/separate-storage-network.png
-.. |NIC Bonding And Multipath I/O| image:: ./_static/images/nic-bonding-and-multipath-io.png
-.. |Use the GUI to set the configuration variable to true| image:: ./_static/images/ec2-s3-configuration.png
-.. |Use the GUI to set the name of a compute service offering to an EC2 instance type API name.| image:: ./_static/images/compute-service-offerings.png
-.. |parallel-mode.png: adding a firewall and load balancer in parallel mode.| image:: ./_static/images/parallel-mode.png
-.. |guest-traffic-setup.png: Depicts a guest traffic setup| image:: ./_static/images/guest-traffic-setup.png
-.. |networksinglepod.png: diagram showing logical view of network in a pod| image:: ./_static/images/network-singlepod.png
-.. |networksetupzone.png: Depicts network setup in a single zone| image:: ./_static/images/network-setup-zone.png
-.. |addguestnetwork.png: Add Guest network setup in a single zone| image:: ./_static/images/add-guest-network.png
-.. |remove-nic.png: button to remove a NIC| image:: ./_static/images/remove-nic.png
-.. |set-default-nic.png: button to set a NIC as default one.| image:: ./_static/images/set-default-nic.png
-.. |EditButton.png: button to edit a network| image:: ./_static/images/edit-icon.png
-.. |edit-icon.png: button to edit a network| image:: ./_static/images/edit-icon.png
-.. |addAccount-icon.png: button to assign an IP range to an account.| image:: ./_static/images/addAccount-icon.png
-.. |eip-ns-basiczone.png: Elastic IP in a NetScaler-enabled Basic Zone.| image:: ./_static/images/eip-ns-basiczone.png
-.. |add-ip-range.png: adding an IP range to a network.| image:: ./_static/images/add-ip-range.png
-.. |httpaccess.png: allows inbound HTTP access from anywhere| image:: ./_static/images/http-access.png
-.. |autoscaleateconfig.png: Configuring AutoScale| image:: ./_static/images/autoscale-config.png
-.. |EnableDisable.png: button to enable or disable AutoScale.| image:: ./_static/images/enable-disable-autoscale.png
-.. |gslb.png: GSLB architecture| image:: ./_static/images/gslb.png
-.. |gslb-add.png: adding a gslb rule| image:: ./_static/images/add-gslb.png
-.. |ReleaseIPButton.png: button to release an IP| image:: ./_static/images/release-ip-icon.png
-.. |EnableNATButton.png: button to enable NAT| image:: ./_static/images/enable-disable.png
-.. |egress-firewall-rule.png: adding an egress firewall rule| image:: ./_static/images/egress-firewall-rule.png
-.. |AttachDiskButton.png: button to attach a volume| image:: ./_static/images/vpn-icon.png
-.. |vpn-icon.png: button to enable VPN| image:: ./_static/images/vpn-icon.png
-.. |addvpncustomergateway.png: adding a customer gateway.| image:: ./_static/images/add-vpn-customer-gateway.png
-.. |edit.png: button to edit a VPN customer gateway| image:: ./_static/images/edit-icon.png
-.. |delete.png: button to remove a VPN customer gateway| image:: ./_static/images/delete-button.png
-.. |createvpnconnection.png: creating a VPN connection to the customer gateway.| image:: ./_static/images/create-vpn-connection.png
-.. |remove-vpn.png: button to remove a VPN connection| image:: ./_static/images/remove-vpn.png
-.. |reset-vpn.png: button to reset a VPN connection| image:: ./_static/images/reset-vpn.png
-.. |mutltier.png: a multi-tier setup.| image:: ./_static/images/multi-tier-app.png
-.. |add-vpc.png: adding a vpc.| image:: ./_static/images/add-vpc.png
-.. |add-tier.png: adding a tier to a vpc.| image:: ./_static/images/add-tier.png
-.. |replace-acl-icon.png: button to replace an ACL list| image:: ./_static/images/replace-acl-icon.png
-.. |add-new-gateway-vpc.png: adding a private gateway for the VPC.| image:: ./_static/images/add-new-gateway-vpc.png
-.. |replace-acl-icon.png: button to replace the default ACL behaviour.| image:: ./_static/images/replace-acl-icon.png
-.. |add-vm-vpc.png: adding a VM to a vpc.| image:: ./_static/images/add-vm-vpc.png
-.. |addvm-tier-sharednw.png: adding a VM to a VPC tier and shared network.| image:: ./_static/images/addvm-tier-sharednw.png
-.. |release-ip-icon.png: button to release an IP.| image:: ./_static/images/release-ip-icon.png
-.. |enable-disable.png: button to enable Static NAT.| image:: ./_static/images/enable-disable.png
-.. |select-vmstatic-nat.png: selecting a tier to apply staticNAT.| image:: ./_static/images/select-vm-staticnat-vpc.png
-.. |vpc-lb.png: Configuring internal LB for VPC| image:: ./_static/images/vpc-lb.png
-.. |del-tier.png: button to remove a tier| image:: ./_static/images/del-tier.png
-.. |remove-vpc.png: button to remove a VPC| image:: ./_static/images/remove-vpc.png
-.. |edit-icon.png: button to edit a VPC| image:: ./_static/images/edit-icon.png
-.. |restart-vpc.png: button to restart a VPC| image:: ./_static/images/restart-vpc.png

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/0bbd4264/source/configuration.rst
----------------------------------------------------------------------
diff --git a/source/configuration.rst b/source/configuration.rst
index 75bcd19..a2adc1c 100644
--- a/source/configuration.rst
+++ b/source/configuration.rst
@@ -2064,6 +2064,159 @@ If you decide to grow your deployment, you can add more hosts, primary
 storage, zones, pods, and clusters.
 
 
+Configuration Parameters
+------------------------
+
+About Configuration Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CloudStack provides a variety of settings you can use to set limits,
+configure features, and enable or disable features in the cloud. Once
+your Management Server is running, you might need to set some of these
+configuration parameters, depending on what optional features you are
+setting up. You can set default values at the global level, which will
+be in effect throughout the cloud unless you override them at a lower
+level. You can make local settings, which will override the global
+configuration parameter values, at the level of an account, zone,
+cluster, or primary storage.
+
+The documentation for each CloudStack feature should direct you to the
+names of the applicable parameters. The following table shows a few of
+the more useful parameters.
+
+=================================  ================================================================================
+Field                              Value
+=================================  ================================================================================
+management.network.cidr            A CIDR that describes the network that the management CIDRs reside on. This                                        variable must be set for deployments that use vSphere. It is recommended to be                                     set for other deployments as well. Example: 192.168.3.0/24.
+xen.setup.multipath                For XenServer nodes, this is a true/false variable that instructs CloudStack to                                    enable iSCSI multipath on the XenServer Hosts when they are added. This                                            defaults to false. Set it to true if you would like CloudStack to enable                                           multipath.If this is true for a NFS-based deployment multipath will still be                                       enabled on the XenServer host. However, this does not impact NFS operation and                                     is harmless.
+secstorage.allowed.internal.sites  This is used to protect your internal network from rogue attempts to download                                      arbitrary files using the template download feature. This is a comma-separated                                     list of CIDRs. If a requested URL matches any of these CIDRs the Secondary                                         Storage VM will use the private network interface to fetch the URL. Other URLs                                     will go through the public interface. We suggest you set this to 1 or 2                                            hardened internal machines where you keep your templates. For example, set it                                      to 192.168.1.66/32.
+use.local.storage                  Determines whether CloudStack will use storage that is local to the Host for                                       data disks, templates, and snapshots. By default CloudStack will not use this                                      storage. You should change this to true if you want to use local storage and                                       you understand the reliability and feature drawbacks to choosing local storage.
+host                               This is the IP address of the Management Server. If you are using multiple                                         Management Servers you should enter a load balanced IP address that is                                             reachable via the private network.
+default.page.size                  Maximum number of items per page that can be returned by a CloudStack API                                          command. The limit applies at the cloud level and can vary from cloud to cloud.                                    You can override this with a lower value on a particular API call by using the                                     page and pagesize API command parameters. For more information, see the                                            Developer's Guide. Default: 500.
+ha.tag                             The label you want to use throughout the cloud to designate certain hosts as                                       dedicated HA hosts. These hosts will be used only for HA-enabled VMs that are                                      restarting due to the failure of another host. For example, you could set this                                     to ha\_host. Specify the ha.tag value asa host tag when you add a new host to                                      the cloud.
+vmware.vcenter.session.timeout     Determines the vCenter session timeout value by using this parameter. The                                          default value is 20 minutes. Increase the timeout value to avoid timeout errors                                    in VMware deployments because certain VMware operations take more than 20                                          minutes.
+=================================  ================================================================================
+
+Setting Global Configuration Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Use the following steps to set global configuration parameters. These
+values will be the defaults in effect throughout your CloudStack
+deployment.
+
+#. 
+
+   Log in to the UI as administrator.
+
+#. 
+
+   In the left navigation bar, click Global Settings.
+
+#. 
+
+   In Select View, choose one of the following:
+
+   -  
+
+      Global Settings. This displays a list of the parameters with brief
+      descriptions and current values.
+
+   -  
+
+      Hypervisor Capabilities. This displays a list of hypervisor
+      versions with the maximum number of guests supported for each.
+
+#. 
+
+   Use the search box to narrow down the list to those you are
+   interested in.
+
+#. 
+
+   In the Actions column, click the Edit icon to modify a value. If you
+   are viewing Hypervisor Capabilities, you must click the name of the
+   hypervisor first to display the editing screen.
+
+Setting Local Configuration Parameters
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Use the following steps to set local configuration parameters for an
+account, zone, cluster, or primary storage. These values will override
+the global configuration settings.
+
+#. 
+
+   Log in to the UI as administrator.
+
+#. 
+
+   In the left navigation bar, click Infrastructure or Accounts,
+   depending on where you want to set a value.
+
+#. 
+
+   Find the name of the particular resource that you want to work with.
+   For example, if you are in Infrastructure, click View All on the
+   Zones, Clusters, or Primary Storage area.
+
+#. 
+
+   Click the name of the resource where you want to set a limit.
+
+#. 
+
+   Click the Settings tab.
+
+#. 
+
+   Use the search box to narrow down the list to those you are
+   interested in.
+
+#. 
+
+   In the Actions column, click the Edit icon to modify a value.
+
+Granular Global Configuration Parameters
+----------------------------------------
+
+The following global configuration parameters have been made more
+granular. The parameters are listed under three different scopes:
+account, cluster, and zone.
+
+========  =========================================================  ======================================================================================================================================
+Field     Field		                                                 Value
+========  =========================================================  ======================================================================================================================================
+account   remote.access.vpn.client.iprange                           The range of IPs to be allocated to remotely access the VPN clients. The first IP in the range is                                                                                                          used by the VPN server.
+account   allow.public.user.templates                                If false, users will not be able to create public templates.
+account   use.system.public.ips                                      If true and if an account has one or more dedicated public IP ranges, IPs are                                                                                                                              acquired from the system pool after all the IPs dedicated to the account have been consumed.
+account   use.system.guest.vlans                                     If true and if an account has one or more dedicated guest VLAN ranges, VLANs are allocated from the                                                                                                        system pool after all the VLANs dedicated to the account have been consumed.
+cluster   cluster.storage.allocated.capacity.notificationthreshold   The percentage, as a value between 0 and 1, of allocated storage utilization                                                                                                                               above which alerts are sent that the storage is below the threshold.
+cluster   cluster.storage.capacity.notificationthreshold             The percentage, as a value between 0 and 1, of storage utilization above which alerts are sent that the available storage is below                                                                         the threshold.
+cluster   cluster.cpu.allocated.capacity.notificationthreshold       The percentage, as a value between 0 and 1, of cpu utilization above which alerts are sent that the available CPU is below the                                                                             threshold.
+cluster   cluster.memory.allocated.capacity.notificationthreshold    The percentage, as a value between 0 and 1, of memory utilization above which alerts are sent that the available memory is below the                                                                       threshold.
+cluster   cluster.cpu.allocated.capacity.disablethreshold            The percentage, as a value between 0 and 1, of CPU utilization above which allocators will disable that cluster from further usage.                                                                        Keep the corresponding notification threshold lower than this value to be notified beforehand.
+cluster   cluster.memory.allocated.capacity.disablethreshold         The percentage, as a value between 0 and 1, of memory utilization above which allocators will disable that cluster from further                                                                            usage. Keep the corresponding notification threshold lower than this value to be notified beforehand.
+cluster   cpu.overprovisioning.factor                                Used for CPU over-provisioning calculation; the available CPU will be
+                                                                     the mathematical product of actualCpuCapacity and cpu.overprovisioning.factor.
+cluster   mem.overprovisioning.factor                                Used for memory over-provisioning calculation.
+cluster   vmware.reserve.cpu                                         Specify whether or not to reserve CPU when not over-provisioning; In case of CPU over-provisioning, CPU is always reserved.
+cluster   vmware.reserve.mem                                         Specify whether or not to reserve memory when not over-provisioning; In case of memory over-provisioning memory is always reserved.
+zone      pool.storage.allocated.capacity.disablethreshold           The percentage, as a value between 0 and 1, of allocated storage utilization above which allocators will disable that pool because the
+                                                                     available allocated storage is below the threshold.
+zone      pool.storage.capacity.disablethreshold                     The percentage, as a value between 0 and 1, of storage utilization above which allocators will disable the pool because the available                                                                      storage capacity is below the threshold.
+zone      storage.overprovisioning.factor                            Used for storage over-provisioning calculation; available storage will be the mathematical product of actualStorageSize and                                                                                storage.overprovisioning.factor.
+zone      network.throttling.rate                                    Default data transfer rate in megabits per second allowed in a network.
+zone      guest.domain.suffix                                        Default domain name for VMs inside a virtual networks with a router.
+zone      router.template.xen                                        Name of the default router template on Xenserver.
+zone      router.template.kvm                                        Name of the default router template on KVM.
+zone      router.template.vmware                                     Name of the default router template on VMware.
+zone      enable.dynamic.scale.vm                                    Enable or diable dynamically scaling of a VM.
+zone      use.external.dns                                           Bypass internal DNS, and use the external DNS1 and DNS2
+zone      blacklisted.routes                                         Routes that are blacklisted cannot be used for creating static routes for a VPC Private Gateway.
+========  =========================================================  ======================================================================================================================================  
+
+
+
 .. |1000-foot-view.png: Overview of CloudStack| image:: ./_static/images/1000-foot-view.png
 .. |basic-deployment.png: Basic two-machine deployment| image:: ./_static/images/basic-deployment.png
 .. |infrastructure_overview.png: Nested organization of a zone| image:: ./_static/images/infrastructure-overview.png

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/0bbd4264/source/index.rst
----------------------------------------------------------------------
diff --git a/source/index.rst b/source/index.rst
index f36663f..07b297e 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -31,27 +31,34 @@ Concepts
 
     concepts
 
-Terminology
------------
+Choosing a Deployment Architecture
+----------------------------------
 .. toctree::
     :maxdepth: 2
 
-    terminology
+    choosing_deployment_architecture
 
-Building from Source
----------------------
+Quick Installation Guide
+------------------------
 .. toctree::
     :maxdepth: 2
 
-    building_from_source
+    qig
 
-Installation
--------------
+General Installation
+--------------------
 .. toctree::
     :maxdepth: 2
 
     installation
 
+Source Installation
+-------------------
+.. toctree::
+    :maxdepth: 2
+
+    building_from_source
+
 User Interface
 ---------------
 .. toctree::
@@ -66,13 +73,6 @@ Configuration
 
     configuration
 
-Configuration Parameters
-------------------------
-.. toctree::
-    :maxdepth: 2
-
-    config_params
-
 Hypervisor Installation
 -----------------------
 .. toctree::
@@ -80,34 +80,6 @@ Hypervisor Installation
 
     hypervisor_installation
 
-Additional Installation Options
--------------------------------
-.. toctree::
-    :maxdepth: 2
-
-    optional_installation
-
-Choosing a Deployment Architecture
-----------------------------------
-.. toctree::
-    :maxdepth: 2
-
-    choosing_deployment_architecture
-
-Choosing a Hypervisor
-----------------------
-.. toctree::
-    :maxdepth: 2
-
-    choosing_hypervisor
-
-Amazon Web Services Interface
------------------------------
-.. toctree::
-    :maxdepth: 2
-
-    aws_interface
-
 Network Setup
 -------------
 .. toctree::
@@ -122,6 +94,13 @@ Storage Setup
 
     storage_setup
 
+Additional Installation Options
+-------------------------------
+.. toctree::
+    :maxdepth: 2
+
+    optional_installation
+
 Managing Networks and Traffics
 -------------------------------
 .. toctree::
@@ -129,13 +108,12 @@ Managing Networks and Traffics
 
     managing_networks
 
-Best Practices
----------------
+Amazon Web Services Interface
+-----------------------------
 .. toctree::
     :maxdepth: 2
 
-    best_practices
-
+    aws_interface
 
 Indices and tables
 ==================