cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From seb...@apache.org
Subject [1/2] Initial commit to populate repo
Date Sat, 25 Jan 2014 21:18:49 GMT
Updated Branches:
  refs/heads/master [created] 25731f04c


http://git-wip-us.apache.org/repos/asf/cloudstack-docs-install/blob/25731f04/source/installation.rst
----------------------------------------------------------------------
diff --git a/source/installation.rst b/source/installation.rst
new file mode 100644
index 0000000..b86a39f
--- /dev/null
+++ b/source/installation.rst
@@ -0,0 +1,21105 @@
+Legal Notice
+============
+
+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.
+
+Abstract
+
+
+1.1. What Is CloudStack?
+------------------------
+
+CloudStack is an open source software platform that pools computing
+resources to build public, private, and hybrid Infrastructure as a
+Service (IaaS) clouds. CloudStack manages the network, storage, and
+compute nodes that make up a cloud infrastructure. Use CloudStack to
+deploy, manage, and configure cloud computing environments.
+
+Typical users are service providers and enterprises. With CloudStack,
+you can:
+
+-  
+
+   Set up an on-demand, elastic cloud computing service. Service
+   providers can sell self service virtual machine instances, storage
+   volumes, and networking configurations over the Internet.
+
+-  
+
+   Set up an on-premise private cloud for use by employees. Rather than
+   managing virtual machines in the same way as physical machines, with
+   CloudStack an enterprise can offer self-service virtual machines to
+   users without involving IT departments.
+
+|1000-foot-view.png: Overview of CloudStack|
+
+1.2. What Can CloudStack Do?
+----------------------------
+
+**Multiple Hypervisor Support**
+
+CloudStack works with a variety of hypervisors, and a single cloud
+deployment can contain multiple hypervisor implementations. The current
+release of CloudStack supports pre-packaged enterprise solutions like
+Citrix XenServer and VMware vSphere, as well as KVM or Xen running on
+Ubuntu or CentOS.
+
+**Massively Scalable Infrastructure Management**
+
+CloudStack can manage tens of thousands of servers installed in multiple
+geographically distributed datacenters. The centralized management
+server scales linearly, eliminating the need for intermediate
+cluster-level management servers. No single component failure can cause
+a cloud-wide outage. Periodic maintenance of the management server can
+be performed without affecting the functioning of virtual machines
+running in the cloud.
+
+**Automatic Configuration Management**
+
+CloudStack automatically configures each guest virtual machine’s
+networking and storage settings.
+
+CloudStack internally manages a pool of virtual appliances to support
+the cloud itself. These appliances offer services such as firewalling,
+routing, DHCP, VPN access, console proxy, storage access, and storage
+replication. The extensive use of virtual appliances simplifies the
+installation, configuration, and ongoing management of a cloud
+deployment.
+
+**Graphical User Interface**
+
+CloudStack offers an administrator's Web interface, used for
+provisioning and managing the cloud, as well as an end-user's Web
+interface, used for running VMs and managing VM templates. The UI can be
+customized to reflect the desired service provider or enterprise look
+and feel.
+
+**API and Extensibility**
+
+CloudStack provides an API that gives programmatic access to all the
+management features available in the UI. The API is maintained and
+documented. This API enables the creation of command line tools and new
+user interfaces to suit particular needs. See the Developer’s Guide and
+API Reference, both available at `Apache CloudStack
+Guides <http://cloudstack.apache.org/docs/en-US/index.html>`__ and
+`Apache CloudStack API
+Reference <http://cloudstack.apache.org/docs/api/index.html>`__
+respectively.
+
+The CloudStack pluggable allocation architecture allows the creation of
+new types of allocators for the selection of storage and Hosts. See the
+Allocator Implementation Guide
+(`http://docs.cloudstack.org/CloudStack\_Documentation/Allocator\_Implementation\_Guide <http://docs.cloudstack.org/CloudStack_Documentation/Allocator_Implementation_Guide>`__).
+
+**High Availability**
+
+CloudStack has a number of features to increase the availability of the
+system. The Management Server itself may be deployed in a multi-node
+installation where the servers are load balanced. MySQL may be
+configured to use replication to provide for a manual failover in the
+event of database loss. For the hosts, CloudStack supports NIC bonding
+and the use of separate networks for storage as well as iSCSI Multipath.
+
+1.3. Deployment Architecture Overview
+-------------------------------------
+
+A CloudStack installation consists of two parts: the Management Server
+and the cloud infrastructure that it manages. When you set up and manage
+a CloudStack cloud, you provision resources such as hosts, storage
+devices, and IP addresses into the Management Server, and the Management
+Server manages those resources.
+
+The minimum production installation consists of one machine running the
+CloudStack Management Server and another machine to act as the cloud
+infrastructure (in this case, a very simple infrastructure consisting of
+one host running hypervisor software). In its smallest deployment, a
+single machine can act as both the Management Server and the hypervisor
+host (using the KVM hypervisor).
+
+|basic-deployment.png: Basic two-machine deployment|
+
+A more full-featured installation consists of a highly-available
+multi-node Management Server installation and up to tens of thousands of
+hosts using any of several advanced networking setups. For information
+about deployment options, see the "Choosing a Deployment Architecture"
+section of the CloudStack Installation Guide.
+
+1.3.1. Management Server Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Management Server is the CloudStack software that manages cloud
+resources. By interacting with the Management Server through its UI or
+API, you can configure and manage your cloud infrastructure.
+
+The Management Server runs on a dedicated server or VM. It controls
+allocation of virtual machines to hosts and assigns storage and IP
+addresses to the virtual machine instances. The Management Server runs
+in a Tomcat container and requires a MySQL database for persistence.
+
+The machine must meet the system requirements described in System
+Requirements.
+
+The Management Server:
+
+-  
+
+   Provides the web user interface for the administrator and a reference
+   user interface for end users.
+
+-  
+
+   Provides the APIs for CloudStack.
+
+-  
+
+   Manages the assignment of guest VMs to particular hosts.
+
+-  
+
+   Manages the assignment of public and private IP addresses to
+   particular accounts.
+
+-  
+
+   Manages the allocation of storage to guests as virtual disks.
+
+-  
+
+   Manages snapshots, templates, and ISO images, possibly replicating
+   them across data centers.
+
+-  
+
+   Provides a single point of configuration for the cloud.
+
+1.3.2. Cloud Infrastructure Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Management Server manages one or more zones (typically, datacenters)
+containing host computers where guest virtual machines will run. The
+cloud infrastructure is organized as follows:
+
+-  
+
+   Zone: Typically, a zone is equivalent to a single datacenter. A zone
+   consists of one or more pods and secondary storage.
+
+-  
+
+   Pod: A pod is usually one rack of hardware that includes a layer-2
+   switch and one or more clusters.
+
+-  
+
+   Cluster: A cluster consists of one or more hosts and primary storage.
+
+-  
+
+   Host: A single compute node within a cluster. The hosts are where the
+   actual cloud services run in the form of guest virtual machines.
+
+-  
+
+   Primary storage is associated with a cluster, and it stores the disk
+   volumes for all the VMs running on hosts in that cluster.
+
+-  
+
+   Secondary storage is associated with a zone, and it stores templates,
+   ISO images, and disk volume snapshots.
+
+|infrastructure\_overview.png: Nested organization of a zone|
+
+**More Information**
+
+For more information, see documentation on cloud infrastructure
+concepts.
+
+1.3.3. Networking Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CloudStack offers two types of networking scenario:
+
+-  
+
+   Basic. For AWS-style networking. Provides a single network where
+   guest isolation can be provided through layer-3 means such as
+   security groups (IP address source filtering).
+
+-  
+
+   Advanced. For more sophisticated network topologies. This network
+   model provides the most flexibility in defining guest networks.
+
+For more details, see Network Setup.
+
+`2.1. About Regions <#about-regions>`__
+
+`2.2. About Zones <#about-zones>`__
+
+`2.3. About Pods <#about-pods>`__
+
+`2.4. About Clusters <#about-clusters>`__
+
+`2.5. About Hosts <#about-hosts>`__
+
+`2.6. About Primary Storage <#about-primary-storage>`__
+
+`2.7. About Secondary Storage <#about-secondary-storage>`__
+
+`2.8. About Physical Networks <#about-physical-networks>`__
+
+`2.8.1. Basic Zone Network Traffic
+Types <#basic-zone-network-traffic-types>`__
+
+`2.8.2. Basic Zone Guest IP
+Addresses <#basic-zone-guest-ip-addresses>`__
+
+`2.8.3. Advanced Zone Network Traffic
+Types <#advanced-zone-network-traffic-types>`__
+
+`2.8.4. Advanced Zone Guest IP
+Addresses <#advanced-zone-guest-ip-addresses>`__
+
+`2.8.5. Advanced Zone Public IP
+Addresses <#advanced-zone-public-ip-addresses>`__
+
+`2.8.6. System Reserved IP Addresses <#system-reserved-ip-addresses>`__
+
+2.1. 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.
+
+2.2. 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.
+
+2.3. 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|
+
+2.4. 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.
+
+2.5. 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.
+
+2.6. 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:
+
+-  
+
+   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.
+
+2.7. 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.
+
+2.8. 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
+
+2.8.1. 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.
+
+2.8.2. 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.
+
+2.8.3. 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.
+
+2.8.4. 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.
+
+2.8.5. 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.
+
+2.8.6. 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.
+
+`3.1. Getting the release <#sect-source-gettingrelease>`__
+
+`3.2. Verifying the downloaded release <#sect-source-verify>`__
+
+`3.2.1. Getting the KEYS <#sect-source-verify-keys>`__
+
+`3.2.2. GPG <#sect-source-verify-gpg>`__
+
+`3.2.3. MD5 <#sect-source-verify-md5>`__
+
+`3.2.4. SHA512 <#sect-source-verify-sha512>`__
+
+`3.3. Prerequisites for building Apache
+CloudStack <#sect-source-prereq>`__
+
+`3.4. Extracting source <#sect-source-extract>`__
+
+`3.5. Building DEB packages <#sect-source-builddebs>`__
+
+`3.5.1. Setting up an APT repo <#sect-source-builddebs-repo>`__
+
+`3.5.2. Configuring your machines to use the APT
+repository <#sect-source-builddebs-repo2>`__
+
+`3.6. Building RPMs from Source <#sect-source-buildrpm>`__
+
+`3.6.1. Generating RPMS <#generating-rpms>`__
+
+`3.7. Building Non-OSS <#sect-source-nonoss>`__
+
+The official CloudStack release is always in source code form. You will
+likely be able to find "convenience binaries," the source is the
+canonical release. In this section, we'll cover acquiring the source
+release and building that so that you can deploy it using Maven or
+create Debian packages or RPMs.
+
+Note that building and deploying directly from source is typically not
+the most efficient way to deploy an IaaS. However, we will cover that
+method as well as building RPMs or Debian packages for deploying
+CloudStack.
+
+The instructions here are likely version-specific. That is, the method
+for building from source for the 4.0.x series is different from the
+4.1.x series.
+
+If you are working with a unreleased version of CloudStack, see the
+INSTALL.md file in the top-level directory of the release.
+
+3.1. Getting the release
+------------------------
+
+You can download the latest CloudStack release from the `Apache
+CloudStack project download
+page <http://incubator.apache.org/cloudstack/downloads.html>`__.
+
+Prior releases are available via archive.apache.org as well. See the
+downloads page for more information on archived releases.
+
+You'll notice several links under the 'Latest release' section. A link
+to a file ending in ``tar.bz2``, as well as a PGP/GPG signature, MD5,
+and SHA512 file.
+
+-  
+
+   The ``tar.bz2`` file contains the Bzip2-compressed tarball with the
+   source code.
+
+-  
+
+   The ``.asc`` file is a detached cryptographic signature that can be
+   used to help verify the authenticity of the release.
+
+-  
+
+   The ``.md5`` file is an MD5 hash of the release to aid in verify the
+   validity of the release download.
+
+-  
+
+   The ``.sha`` file is a SHA512 hash of the release to aid in verify
+   the validity of the release download.
+
+3.2. Verifying the downloaded release
+-------------------------------------
+
+There are a number of mechanisms to check the authenticity and validity
+of a downloaded release.
+
+3.2.1. Getting the KEYS
+~~~~~~~~~~~~~~~~~~~~~~~
+
+To enable you to verify the GPG signature, you will need to download the
+`KEYS <http://www.apache.org/dist/incubator/cloudstack/KEYS>`__ file.
+
+You next need to import those keys, which you can do by running:
+
+.. code:: programlisting
+
+    # gpg --import KEYS
+
+3.2.2. GPG
+~~~~~~~~~~
+
+The CloudStack project provides a detached GPG signature of the release.
+To check the signature, run the following command:
+
+.. code:: programlisting
+
+    $ gpg --verify apache-cloudstack-4.0.0-incubating-src.tar.bz2.asc
+
+If the signature is valid you will see a line of output that contains
+'Good signature'.
+
+3.2.3. MD5
+~~~~~~~~~~
+
+In addition to the cryptographic signature, CloudStack has an MD5
+checksum that you can use to verify the download matches the release.
+You can verify this hash by executing the following command:
+
+.. code:: programlisting
+
+    $ gpg --print-md MD5 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.md5
+
+If this successfully completes you should see no output. If there is any
+output from them, then there is a difference between the hash you
+generated locally and the hash that has been pulled from the server.
+
+3.2.4. SHA512
+~~~~~~~~~~~~~
+
+In addition to the MD5 hash, the CloudStack project provides a SHA512
+cryptographic hash to aid in assurance of the validity of the downloaded
+release. You can verify this hash by executing the following command:
+
+.. code:: programlisting
+
+    $ gpg --print-md SHA512 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.sha
+
+If this command successfully completes you should see no output. If
+there is any output from them, then there is a difference between the
+hash you generated locally and the hash that has been pulled from the
+server.
+
+3.3. Prerequisites for building Apache CloudStack
+-------------------------------------------------
+
+There are a number of prerequisites needed to build CloudStack. This
+document assumes compilation on a Linux system that uses RPMs or DEBs
+for package management.
+
+You will need, at a minimum, the following to compile CloudStack:
+
+#. 
+
+   Maven (version 3)
+
+#. 
+
+   Java (OpenJDK 1.6 or Java 7/OpenJDK 1.7)
+
+#. 
+
+   Apache Web Services Common Utilities (ws-commons-util)
+
+#. 
+
+   MySQL
+
+#. 
+
+   MySQLdb (provides Python database API)
+
+#. 
+
+   Tomcat 6 (not 6.0.35)
+
+#. 
+
+   genisoimage
+
+#. 
+
+   rpmbuild or dpkg-dev
+
+3.4. Extracting source
+----------------------
+
+Extracting the CloudStack release is relatively simple and can be done
+with a single command as follows:
+
+.. code:: programlisting
+
+    $ tar -jxvf apache-cloudstack-4.1.0.src.tar.bz2
+
+You can now move into the directory:
+
+.. code:: programlisting
+
+    $ cd ./apache-cloudstack-4.1.0-src
+
+3.5. Building DEB packages
+--------------------------
+
+In addition to the bootstrap dependencies, you'll also need to install
+several other dependencies. Note that we recommend using Maven 3, which
+is not currently available in 12.04.1 LTS. So, you'll also need to add a
+PPA repository that includes Maven 3. After running the command
+``add-apt-repository``, you will be prompted to continue and a GPG key
+will be added.
+
+.. code:: screen
+
+    $ sudo apt-get update
+    $ sudo apt-get install python-software-properties
+    $ sudo add-apt-repository ppa:natecarlson/maven3
+    $ sudo apt-get update
+    $ sudo apt-get install ant debhelper openjdk-6-jdk tomcat6 libws-commons-util-java genisoimage python-mysqldb libcommons-codec-java libcommons-httpclient-java liblog4j1.2-java maven3
+
+While we have defined, and you have presumably already installed the
+bootstrap prerequisites, there are a number of build time prerequisites
+that need to be resolved. CloudStack uses maven for dependency
+resolution. You can resolve the buildtime depdencies for CloudStack by
+running:
+
+.. code:: screen
+
+    $ mvn3 -P deps
+
+Now that we have resolved the dependencies we can move on to building
+CloudStack and packaging them into DEBs by issuing the following
+command.
+
+.. code:: screen
+
+    $ dpkg-buildpackage -uc -us
+
+This command will build the following debian packages. You should have
+all of the following:
+
+.. code:: programlisting
+
+    cloudstack-common-4.2.0.amd64.deb
+    cloudstack-management-4.2.0.amd64.deb
+    cloudstack-agent-4.2.0.amd64.deb
+    cloudstack-usage-4.2.0.amd64.deb
+    cloudstack-awsapi-4.2.0.amd64.deb
+    cloudstack-cli-4.2.0.amd64.deb
+    cloudstack-docs-4.2.0.amd64.deb
+
+3.5.1. Setting up an APT repo
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After you've created the packages, you'll want to copy them to a system
+where you can serve the packages over HTTP. You'll create a directory
+for the packages and then use ``dpkg-scanpackages`` to create
+``Packages.gz``, which holds information about the archive structure.
+Finally, you'll add the repository to your system(s) so you can install
+the packages using APT.
+
+The first step is to make sure that you have the **dpkg-dev** package
+installed. This should have been installed when you pulled in the
+**debhelper** application previously, but if you're generating
+``Packages.gz`` on a different system, be sure that it's installed there
+as well.
+
+.. code:: screen
+
+    $ sudo apt-get install dpkg-dev
+
+The next step is to copy the DEBs to the directory where they can be
+served over HTTP. We'll use ``/var/www/cloudstack/repo`` in the
+examples, but change the directory to whatever works for you.
+
+.. code:: screen
+
+    sudo mkdir -p /var/www/cloudstack/repo/binary
+    sudo cp *.deb /var/www/cloudstack/repo/binary
+    sudo cd /var/www/cloudstack/repo/binary
+    sudo dpkg-scanpackages . /dev/null | tee Packages | gzip -9 > Packages.gz
+
+Note: Override Files
+--------------------
+
+You can safely ignore the warning about a missing override file.
+
+Now you should have all of the DEB packages and ``Packages.gz`` in the
+``binary`` directory and available over HTTP. (You may want to use
+``wget`` or ``curl`` to test this before moving on to the next step.)
+
+3.5.2. Configuring your machines to use the APT repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now that we have created the repository, you need to configure your
+machine to make use of the APT repository. You can do this by adding a
+repository file under ``/etc/apt/sources.list.d``. Use your preferred
+editor to create ``/etc/apt/sources.list.d/cloudstack.list`` with this
+line:
+
+.. code:: programlisting
+
+    deb http://server.url/cloudstack/repo binary ./
+
+Now that you have the repository info in place, you'll want to run
+another update so that APT knows where to find the CloudStack packages.
+
+.. code:: screen
+
+    $ sudo apt-get update
+
+You can now move on to the instructions under Install on Ubuntu.
+
+3.6. Building RPMs from Source
+------------------------------
+
+As mentioned previously in `Section 3.3, “Prerequisites for building
+Apache CloudStack” <#sect-source-prereq>`__, you will need to install
+several prerequisites before you can build packages for CloudStack. Here
+we'll assume you're working with a 64-bit build of CentOS or Red Hat
+Enterprise Linux.
+
+.. code:: programlisting
+
+    # yum groupinstall "Development Tools"
+
+.. code:: programlisting
+
+    # yum install java-1.6.0-openjdk-devel.x86_64 genisoimage mysql mysql-server ws-commons-util MySQL-python tomcat6 createrepo
+
+Next, you'll need to install build-time dependencies for CloudStack with
+Maven. We're using Maven 3, so you'll want to `grab a Maven 3
+tarball <http://maven.apache.org/download.cgi>`__ and uncompress it in
+your home directory (or whatever location you prefer):
+
+.. code:: programlisting
+
+    $ tar zxvf apache-maven-3.0.4-bin.tar.gz
+
+.. code:: programlisting
+
+    $ export PATH=/usr/local/apache-maven-3.0.4//bin:$PATH
+
+Maven also needs to know where Java is, and expects the JAVA\_HOME
+environment variable to be set:
+
+.. code:: programlisting
+
+    $ export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/
+
+Verify that Maven is installed correctly:
+
+.. code:: programlisting
+
+    $ mvn --version
+
+You probably want to ensure that your environment variables will survive
+a logout/reboot. Be sure to update ``~/.bashrc`` with the PATH and
+JAVA\_HOME variables.
+
+Building RPMs for CloudStack is fairly simple. Assuming you already have
+the source downloaded and have uncompressed the tarball into a local
+directory, you're going to be able to generate packages in just a few
+minutes.
+
+Packaging has Changed
+---------------------
+
+If you've created packages for CloudStack previously, you should be
+aware that the process has changed considerably since the project has
+moved to using Apache Maven. Please be sure to follow the steps in this
+section closely.
+
+3.6.1. Generating RPMS
+~~~~~~~~~~~~~~~~~~~~~~
+
+Now that we have the prerequisites and source, you will cd to the
+``packaging/centos63/`` directory.
+
+.. code:: programlisting
+
+    $ cd packaging/centos63
+
+Generating RPMs is done using the ``package.sh`` script:
+
+.. code:: programlisting
+
+    $./package.sh
+
+That will run for a bit and then place the finished packages in
+``dist/rpmbuild/RPMS/x86_64/``.
+
+You should see the following RPMs in that directory:
+
+.. code:: programlisting
+
+                cloudstack-agent-4.2.0.el6.x86_64.rpm
+                cloudstack-awsapi-4.2.0.el6.x86_64.rpm
+                cloudstack-cli-4.2.0.el6.x86_64.rpm
+                cloudstack-common-4.2.0.el6.x86_64.rpm
+                cloudstack-docs-4.2.0.el6.x86_64.rpm
+                cloudstack-management-4.2.0.el6.x86_64.rpm
+                cloudstack-usage-4.2.0.el6.x86_64.rpm
+
+3.6.1.1. Creating a yum repo
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+While RPMs is a useful packaging format - it's most easily consumed from
+Yum repositories over a network. The next step is to create a Yum Repo
+with the finished packages:
+
+.. code:: programlisting
+
+    $ mkdir -p ~/tmp/repo
+
+.. code:: programlisting
+
+    $ cp dist/rpmbuild/RPMS/x86_64/*rpm ~/tmp/repo/
+
+.. code:: programlisting
+
+    $ createrepo ~/tmp/repo
+
+The files and directories within ``~/tmp/repo`` can now be uploaded to a
+web server and serve as a yum repository.
+
+3.6.1.2. Configuring your systems to use your new yum repository
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Now that your yum repository is populated with RPMs and metadata we need
+to configure the machines that need to install CloudStack. Create a file
+named ``/etc/yum.repos.d/cloudstack.repo`` with this information:
+
+.. code:: programlisting
+
+                            [apache-cloudstack]
+                            name=Apache CloudStack
+                            baseurl=http://webserver.tld/path/to/repo
+                            enabled=1
+                            gpgcheck=0
+
+Completing this step will allow you to easily install CloudStack on a
+number of machines across the network.
+
+3.7. Building Non-OSS
+---------------------
+
+If you need support for the VMware, NetApp, F5, NetScaler, SRX, or any
+other non-Open Source Software (nonoss) plugins, you'll need to download
+a few components on your own and follow a slightly different procedure
+to build from source.
+
+Why Non-OSS?
+------------
+
+Some of the plugins supported by CloudStack cannot be distributed with
+CloudStack for licensing reasons. In some cases, some of the required
+libraries/JARs are under a proprietary license. In other cases, the
+required libraries may be under a license that's not compatible with
+`Apache's licensing guidelines for third-party
+products <http://www.apache.org/legal/resolved.html#category-x>`__.
+
+#. 
+
+   To build the Non-OSS plugins, you'll need to have the requisite JARs
+   installed under the ``deps`` directory.
+
+   Because these modules require dependencies that can't be distributed
+   with CloudStack you'll need to download them yourself. Links to the
+   most recent dependencies are listed on the `*How to build on master
+   branch* <https://cwiki.apache.org/CLOUDSTACK/how-to-build-on-master-branch.html>`__
+   page on the wiki.
+
+#. 
+
+   You may also need to download
+   `vhd-util <http://download.cloud.com.s3.amazonaws.com/tools/vhd-util>`__,
+   which was removed due to licensing issues. You'll copy vhd-util to
+   the ``scripts/vm/hypervisor/xenserver/`` directory.
+
+#. 
+
+   Once you have all the dependencies copied over, you'll be able to
+   build CloudStack with the ``nonoss`` option:
+
+   .. code:: programlisting
+
+                       $ mvn clean
+                       $ mvn install -Dnonoss
+
+#. 
+
+   Once you've built CloudStack with the ``nonoss`` profile, you can
+   package it using the `Section 3.6, “Building RPMs from
+   Source” <#sect-source-buildrpm>`__ or `Section 3.5, “Building DEB
+   packages” <#sect-source-builddebs>`__ instructions.
+
+`4.1. Who Should Read This <#who-should-read-installation>`__
+
+`4.2. Overview of Installation Steps <#installation-steps-overview>`__
+
+`4.3. Minimum System Requirements <#minimum-system-requirements>`__
+
+`4.3.1. Management Server, Database, and Storage System
+Requirements <#management-server-system-requirements>`__
+
+`4.3.2. Host/Hypervisor System
+Requirements <#hypervisor-system-requirements>`__
+
+`4.4. Configure package repository <#configure-package-repository>`__
+
+`4.4.1. DEB package repository <#configure-package-repository-deb>`__
+
+`4.4.2. RPM package repository <#configure-package-repository-rpm>`__
+
+`4.5. Management Server
+Installation <#management-server-install-flow>`__
+
+`4.5.1. Management Server Installation
+Overview <#management-server-installation-overview>`__
+
+`4.5.2. Prepare the Operating System <#prepare-os>`__
+
+`4.5.3. Install the Management Server on the First
+Host <#management-server-install>`__
+
+`4.5.4. Install the database server <#management-server-install-db>`__
+
+`4.5.5. About Password and Key
+Encryption <#about-password-encryption>`__
+
+`4.5.6. Changing the Default Password
+Encryption <#password-storage-engine>`__
+
+`4.5.7. Prepare NFS Shares <#prepare-nfs-shares>`__
+
+`4.5.8. Prepare and Start Additional Management
+Servers <#install-management-server-multi-nodes>`__
+
+`4.5.9. Prepare the System VM Template <#prepare-system-vm-template>`__
+
+`4.5.10. Installation Complete! Next Steps <#installation-complete>`__
+
+4.1. Who Should Read This
+-------------------------
+
+For those who have already gone through a design phase and planned a
+more sophisticated deployment, or those who are ready to start scaling
+up a trial installation. With the following procedures, you can start
+using the more powerful features of CloudStack, such as advanced VLAN
+networking, high availability, additional network elements such as load
+balancers and firewalls, and support for multiple hypervisors including
+Citrix XenServer, KVM, and VMware vSphere.
+
+4.2. Overview of Installation Steps
+-----------------------------------
+
+For anything more than a simple trial installation, you will need
+guidance for a variety of configuration choices. It is strongly
+recommended that you read the following:
+
+-  
+
+   Choosing a Deployment Architecture
+
+-  
+
+   Choosing a Hypervisor: Supported Features
+
+-  
+
+   Network Setup
+
+-  
+
+   Storage Setup
+
+-  
+
+   Best Practices
+
+#. 
+
+   Make sure you have the required hardware ready. See `Section 4.3,
+   “Minimum System Requirements” <#minimum-system-requirements>`__
+
+#. 
+
+   Install the Management Server (choose single-node or multi-node). See
+   `Section 4.5, “Management Server
+   Installation” <#management-server-install-flow>`__
+
+#. 
+
+   Log in to the UI. See `Chapter 5, *User Interface* <#ui>`__
+
+#. 
+
+   Add a zone. Includes the first pod, cluster, and host. See
+   `Section 6.3, “Adding a Zone” <#zone-add>`__
+
+#. 
+
+   Add more pods (optional). See `Section 6.4, “Adding a
+   Pod” <#pod-add>`__
+
+#. 
+
+   Add more clusters (optional). See `Section 6.5, “Adding a
+   Cluster” <#cluster-add>`__
+
+#. 
+
+   Add more hosts (optional). See `Section 6.6, “Adding a
+   Host” <#host-add>`__
+
+#. 
+
+   Add more primary storage (optional). See `Section 6.7, “Add Primary
+   Storage” <#primary-storage-add>`__
+
+#. 
+
+   Add more secondary storage (optional). See `Section 6.8, “Add
+   Secondary Storage” <#secondary-storage-add>`__
+
+#. 
+
+   Try using the cloud. See `Section 6.9, “Initialize and
+   Test” <#initialize-and-test>`__
+
+4.3. Minimum System Requirements
+--------------------------------
+
+4.3.1. Management Server, Database, and Storage System Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The machines that will run the Management Server and MySQL database must
+meet the following requirements. The same machines can also be used to
+provide primary and secondary storage, such as via localdisk or NFS. The
+Management Server may be placed on a virtual machine.
+
+-  
+
+   Operating system:
+
+   -  
+
+      Preferred: CentOS/RHEL 6.3+ or Ubuntu 12.04(.1)
+
+-  
+
+   64-bit x86 CPU (more cores results in better performance)
+
+-  
+
+   4 GB of memory
+
+-  
+
+   250 GB of local disk (more results in better capability; 500 GB
+   recommended)
+
+-  
+
+   At least 1 NIC
+
+-  
+
+   Statically allocated IP address
+
+-  
+
+   Fully qualified domain name as returned by the hostname command
+
+4.3.2. Host/Hypervisor System Requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The host is where the cloud services run in the form of guest virtual
+machines. Each host is one machine that meets the following
+requirements:
+
+-  
+
+   Must support HVM (Intel-VT or AMD-V enabled).
+
+-  
+
+   64-bit x86 CPU (more cores results in better performance)
+
+-  
+
+   Hardware virtualization support required
+
+-  
+
+   4 GB of memory
+
+-  
+
+   36 GB of local disk
+
+-  
+
+   At least 1 NIC
+
+-  Note
+   ----
+
+   If DHCP is used for hosts, ensure that no conflict occurs between
+   DHCP server used for these hosts and the DHCP router created by
+   CloudStack.
+
+-  
+
+   Latest hotfixes applied to hypervisor software
+
+-  
+
+   When you deploy CloudStack, the hypervisor host must not have any VMs
+   already running
+
+-  
+
+   All hosts within a cluster must be homogeneous. The CPUs must be of
+   the same type, count, and feature flags.
+
+Hosts have additional requirements depending on the hypervisor. See the
+requirements listed at the top of the Installation section for your
+chosen hypervisor:
+
+Warning
+-------
+
+Be sure you fulfill the additional hypervisor requirements and
+installation steps provided in this Guide. Hypervisor hosts must be
+properly prepared to work with CloudStack. For example, the requirements
+for XenServer are listed under Citrix XenServer Installation.
+
+-  
+
+   `Section 8.1.1, “System Requirements for KVM Hypervisor
+   Hosts” <#hypervisor-kvm-requirements>`__
+
+-  
+
+   `Section 8.2.1, “System Requirements for XenServer
+   Hosts” <#system-requirements-xenserver-hosts>`__
+
+-  
+
+   `Section 8.3.1, “System Requirements for Hyper-V Hypervisor
+   Hosts” <#hyperv-requirements>`__
+
+-  
+
+   `Section 8.4.1, “System Requirements for vSphere
+   Hosts” <#vmware-requirements>`__
+
+-  
+
+   `Section 8.5.1, “System Requirements for LXC
+   Hosts” <#lxc-requirements>`__
+
+4.4. Configure package repository
+---------------------------------
+
+CloudStack is only distributed from source from the official mirrors.
+However, members of the CloudStack community may build convenience
+binaries so that users can install Apache CloudStack without needing to
+build from source.
+
+If you didn't follow the steps to build your own packages from source in
+the sections for `Section 3.6, “Building RPMs from
+Source” <#sect-source-buildrpm>`__ or `Section 3.5, “Building DEB
+packages” <#sect-source-builddebs>`__ you may find pre-built DEB and RPM
+packages for your convenience linked from the
+`downloads <http://cloudstack.apache.org/downloads.html>`__ page.
+
+Note
+----
+
+These repositories contain both the Management Server and KVM Hypervisor
+packages.
+
+4.4.1. DEB package repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can add a DEB package repository to your apt sources with the
+following commands. Please note that only packages for Ubuntu 12.04 LTS
+(precise) are being built at this time.
+
+Use your preferred editor and open (or create)
+``/etc/apt/sources.list.d/cloudstack.list``. Add the community provided
+repository to the file:
+
+.. code:: programlisting
+
+    deb http://cloudstack.apt-get.eu/ubuntu precise 4.2
+
+We now have to add the public key to the trusted keys.
+
+.. code:: programlisting
+
+    $ wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
+
+Now update your local apt cache.
+
+.. code:: programlisting
+
+    $ apt-get update
+
+Your DEB package repository should now be configured and ready for use.
+
+4.4.2. RPM package repository
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There is a RPM package repository for CloudStack so you can easily
+install on RHEL based platforms.
+
+If you're using an RPM-based system, you'll want to add the Yum
+repository so that you can install CloudStack with Yum.
+
+Yum repository information is found under ``/etc/yum.repos.d``. You'll
+see several ``.repo`` files in this directory, each one denoting a
+specific repository.
+
+To add the CloudStack repository, create
+``/etc/yum.repos.d/cloudstack.repo`` and insert the following
+information.
+
+.. code:: programlisting
+
+    [cloudstack]
+    name=cloudstack
+    baseurl=http://cloudstack.apt-get.eu/rhel/4.2/
+    enabled=1
+    gpgcheck=0
+
+Now you should be able to install CloudStack using Yum.
+
+4.5. Management Server Installation
+-----------------------------------
+
+4.5.1. Management Server Installation Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This section describes installing the Management Server. There are two
+slightly different installation flows, depending on how many Management
+Server nodes will be in your cloud:
+
+-  
+
+   A single Management Server node, with MySQL on the same node.
+
+-  
+
+   Multiple Management Server nodes, with MySQL on a node separate from
+   the Management Servers.
+
+In either case, each machine must meet the system requirements described
+in System Requirements.
+
+Warning
+-------
+
+For the sake of security, be sure the public Internet can not access
+port 8096 or port 8250 on the Management Server.
+
+The procedure for installing the Management Server is:
+
+#. 
+
+   Prepare the Operating System
+
+#. 
+
+   (XenServer only) Download and install vhd-util.
+
+#. 
+
+   Install the First Management Server
+
+#. 
+
+   Install and Configure the MySQL database
+
+#. 
+
+   Prepare NFS Shares
+
+#. 
+
+   Prepare and Start Additional Management Servers (optional)
+
+#. 
+
+   Prepare the System VM Template
+
+4.5.2. Prepare the Operating System
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The OS must be prepared to host the Management Server using the
+following steps. These steps must be performed on each Management Server
+node.
+
+#. 
+
+   Log in to your OS as root.
+
+#. 
+
+   Check for a fully qualified hostname.
+
+   .. code:: programlisting
+
+       hostname --fqdn
+
+   This should return a fully qualified hostname such as
+   "management1.lab.example.org". If it does not, edit /etc/hosts so
+   that it does.
+
+#. 
+
+   Make sure that the machine can reach the Internet.
+
+   .. code:: programlisting
+
+       ping www.cloudstack.org
+
+#. 
+
+   Turn on NTP for time synchronization.
+
+   Note
+   ----
+
+   NTP is required to synchronize the clocks of the servers in your
+   cloud.
+
+   #. 
+
+      Install NTP.
+
+      .. code:: programlisting
+
+          yum install ntp
+
+      .. code:: programlisting
+
+          apt-get install openntpd
+
+#. 
+
+   Repeat all of these steps on every host where the Management Server
+   will be installed.
+
+4.5.3. Install the Management Server on the First Host
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The first step in installation, whether you are installing the
+Management Server on one host or many, is to install the software on a
+single node.
+
+Note
+----
+
+If you are planning to install the Management Server on multiple nodes
+for high availability, do not proceed to the additional nodes yet. That
+step will come later.
+
+The CloudStack Management server can be installed using either RPM or
+DEB packages. These packages will depend on everything you need to run
+the Management server.
+
+4.5.3.1. Install on CentOS/RHEL
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+We start by installing the required packages:
+
+.. code:: programlisting
+
+    yum install cloudstack-management
+
+4.5.3.2. Install on Ubuntu
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code:: programlisting
+
+    apt-get install cloudstack-management
+
+4.5.3.3. Downloading vhd-util
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This procedure is required only for installations where XenServer is
+installed on the hypervisor hosts.
+
+Before setting up the Management Server, download vhd-util from
+`vhd-util <http://download.cloud.com.s3.amazonaws.com/tools/vhd-util>`__.
+
+If the Management Server is RHEL or CentOS, copy vhd-util to
+/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver.
+
+If the Management Server is Ubuntu, copy vhd-util to
+/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver.
+
+4.5.4. Install the database server
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The CloudStack management server uses a MySQL database server to store
+its data. When you are installing the management server on a single
+node, you can install the MySQL server locally. For an installation that
+has multiple management server nodes, we assume the MySQL database also
+runs on a separate node.
+
+CloudStack has been tested with MySQL 5.1 and 5.5. These versions are
+included in RHEL/CentOS and Ubuntu.
+
+4.5.4.1. Install the Database on the Management Server Node
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section describes how to install MySQL on the same machine with the
+Management Server. This technique is intended for a simple deployment
+that has a single Management Server node. If you have a multi-node
+Management Server deployment, you will typically use a separate node for
+MySQL. See `Section 4.5.4.2, “Install the Database on a Separate
+Node” <#management-server-install-db-external>`__.
+
+#. 
+
+   Install MySQL from the package repository of your distribution:
+
+   .. code:: programlisting
+
+       yum install mysql-server
+
+   .. code:: programlisting
+
+       apt-get install mysql-server
+
+#. 
+
+   Open the MySQL configuration file. The configuration file is
+   ``/etc/my.cnf`` or ``/etc/mysql/my.cnf``, depending on your OS.
+
+#. 
+
+   Insert the following lines in the [mysqld] section.
+
+   You can put these lines below the datadir line. The max\_connections
+   parameter should be set to 350 multiplied by the number of Management
+   Servers you are deploying. This example assumes one Management
+   Server.
+
+   Note
+   ----
+
+   On Ubuntu, you can also create a file
+   ``/etc/mysql/conf.d/cloudstack.cnf`` and add these directives there.
+   Don't forget to add [mysqld] on the first line of the file.
+
+   .. code:: programlisting
+
+       innodb_rollback_on_timeout=1
+       innodb_lock_wait_timeout=600
+       max_connections=350
+       log-bin=mysql-bin
+       binlog-format = 'ROW'
+
+#. 
+
+   Start or restart MySQL to put the new configuration into effect.
+
+   On RHEL/CentOS, MySQL doesn't automatically start after installation.
+   Start it manually.
+
+   .. code:: programlisting
+
+       service mysqld start
+
+   On Ubuntu, restart MySQL.
+
+   .. code:: programlisting
+
+       service mysql restart
+
+#. 
+
+   (CentOS and RHEL only; not required on Ubuntu)
+
+   Warning
+   -------
+
+   On RHEL and CentOS, MySQL does not set a root password by default. It
+   is very strongly recommended that you set a root password as a
+   security precaution.
+
+   Run the following command to secure your installation. You can answer
+   "Y" to all questions.
+
+   .. code:: programlisting
+
+       mysql_secure_installation
+
+#. 
+
+   CloudStack can be blocked by security mechanisms, such as SELinux.
+   Disable SELinux to ensure + that the Agent has all the required
+   permissions.
+
+   Configure SELinux (RHEL and CentOS):
+
+   #. 
+
+      Check whether SELinux is installed on your machine. If not, you
+      can skip this section.
+
+      In RHEL or CentOS, SELinux is installed and enabled by default.
+      You can verify this with:
+
+      .. code:: programlisting
+
+          $ rpm -qa | grep selinux
+
+   #. 
+
+      Set the SELINUX variable in ``/etc/selinux/config`` to
+      "permissive". This ensures that the permissive setting will be
+      maintained after a system reboot.
+
+      In RHEL or CentOS:
+
+      .. code:: programlisting
+
+          vi /etc/selinux/config
+
+      Change the following line
+
+      .. code:: programlisting
+
+          SELINUX=enforcing
+
+      to this:
+
+      .. code:: programlisting
+
+          SELINUX=permissive
+
+   #. 
+
+      Set SELinux to permissive starting immediately, without requiring
+      a system reboot.
+
+      .. code:: programlisting
+
+          $ setenforce permissive
+
+#. 
+
+   Set up the database. The following command creates the "cloud" user
+   on the database.
+
+   -  
+
+      In dbpassword, specify the password to be assigned to the "cloud"
+      user. You can choose to provide no password although that is not
+      recommended.
+
+   -  
+
+      In deploy-as, specify the username and password of the user
+      deploying the database. In the following command, it is assumed
+      the root user is deploying the database and creating the "cloud"
+      user.
+
+   -  
+
+      (Optional) For encryption\_type, use file or web to indicate the
+      technique used to pass in the database encryption password.
+      Default: file. See `Section 4.5.5, “About Password and Key
+      Encryption” <#about-password-encryption>`__.
+
+   -  
+
+      (Optional) For management\_server\_key, substitute the default key
+      that is used to encrypt confidential parameters in the CloudStack
+      properties file. Default: password. It is highly recommended that
+      you replace this with a more secure value. See `Section 4.5.5,
+      “About Password and Key
+      Encryption” <#about-password-encryption>`__.
+
+   -  
+
+      (Optional) For database\_key, substitute the default key that is
+      used to encrypt confidential parameters in the CloudStack
+      database. Default: password. It is highly recommended that you
+      replace this with a more secure value. See `Section 4.5.5, “About
+      Password and Key Encryption” <#about-password-encryption>`__.
+
+   -  
+
+      (Optional) For management\_server\_ip, you may explicitly specify
+      cluster management server node IP. If not specified, the local IP
+      address will be used.
+
+   .. code:: programlisting
+
+       cloudstack-setup-databases cloud:<dbpassword>@localhost \
+       --deploy-as=root:<password> \
+       -e <encryption_type> \
+       -m <management_server_key> \
+       -k <database_key> \
+       -i <management_server_ip>
+
+   When this script is finished, you should see a message like
+   “Successfully initialized the database.”
+
+   Note
+   ----
+
+   If the script is unable to connect to the MySQL database, check the
+   "localhost" loopback address in ``/etc/hosts``. It should be pointing
+   to the IPv4 loopback address "127.0.0.1" and not the IPv6 loopback
+   address ::1. Alternatively, reconfigure MySQL to bind to the IPv6
+   loopback interface.
+
+#. 
+
+   If you are running the KVM hypervisor on the same machine with the
+   Management Server, edit /etc/sudoers and add the following line:
+
+   .. code:: programlisting
+
+       Defaults:cloud !requiretty
+
+#. 
+
+   Now that the database is set up, you can finish configuring the OS
+   for the Management Server. This command will set up iptables,
+   sudoers, and start the Management Server.
+
+   .. code:: programlisting
+
+       # cloudstack-setup-management
+
+   You should see the message “CloudStack Management Server setup is
+   done.”
+
+4.5.4.2. Install the Database on a Separate Node
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section describes how to install MySQL on a standalone machine,
+separate from the Management Server. This technique is intended for a
+deployment that includes several Management Server nodes. If you have a
+single-node Management Server deployment, you will typically use the
+same node for MySQL. See `Section 4.5.4.1, “Install the Database on the
+Management Server Node” <#management-server-install-db-local>`__.
+
+Note
+----
+
+The management server doesn't require a specific distribution for the
+MySQL node. You can use a distribution or Operating System of your
+choice. Using the same distribution as the management server is
+recommended, but not required. See `Section 4.3.1, “Management Server,
+Database, and Storage System
+Requirements” <#management-server-system-requirements>`__.
+
+#. 
+
+   Install MySQL from the package repository from your distribution:
+
+   .. code:: programlisting
+
+       yum install mysql-server
+
+   .. code:: programlisting
+
+       apt-get install mysql-server
+
+#. 
+
+   Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf,
+   depending on your OS) and insert the following lines in the [mysqld]
+   section. You can put these lines below the datadir line. The
+   max\_connections parameter should be set to 350 multiplied by the
+   number of Management Servers you are deploying. This example assumes
+   two Management Servers.
+
+   Note
+   ----
+
+   On Ubuntu, you can also create /etc/mysql/conf.d/cloudstack.cnf file
+   and add these directives there. Don't forget to add [mysqld] on the
+   first line of the file.
+
+   .. code:: programlisting
+
+       innodb_rollback_on_timeout=1
+       innodb_lock_wait_timeout=600
+       max_connections=700
+       log-bin=mysql-bin
+       binlog-format = 'ROW'
+       bind-address = 0.0.0.0
+
+#. 
+
+   Start or restart MySQL to put the new configuration into effect.
+
+   On RHEL/CentOS, MySQL doesn't automatically start after installation.
+   Start it manually.
+
+   .. code:: programlisting
+
+       service mysqld start
+
+   On Ubuntu, restart MySQL.
+
+   .. code:: programlisting
+
+       service mysql restart
+
+#. 
+
+   (CentOS and RHEL only; not required on Ubuntu)
+
+   Warning
+   -------
+
+   On RHEL and CentOS, MySQL does not set a root password by default. It
+   is very strongly recommended that you set a root password as a
+   security precaution.
+
+   Run the following command to secure your installation. You can answer
+   "Y" to all questions except "Disallow root login remotely?". Remote
+   root login is required to set up the databases.
+
+   .. code:: programlisting
+
+       mysql_secure_installation
+
+#. 
+
+   If a firewall is present on the system, open TCP port 3306 so
+   external MySQL connections can be established.
+
+   On Ubuntu, UFW is the default firewall. Open the port with this
+   command:
+
+   .. code:: programlisting
+
+       ufw allow mysql
+
+   On RHEL/CentOS:
+
+   #. 
+
+      Edit the /etc/sysconfig/iptables file and add the following line
+      at the beginning of the INPUT chain.
+
+      .. code:: programlisting
+
+          -A INPUT -p tcp --dport 3306 -j ACCEPT
+
+   #. 
+
+      Now reload the iptables rules.
+
+      .. code:: programlisting
+
+          service iptables restart
+
+#. 
+
+   Return to the root shell on your first Management Server.
+
+#. 
+
+   Set up the database. The following command creates the cloud user on
+   the database.
+
+   -  
+
+      In dbpassword, specify the password to be assigned to the cloud
+      user. You can choose to provide no password.
+
+   -  
+
+      In deploy-as, specify the username and password of the user
+      deploying the database. In the following command, it is assumed
+      the root user is deploying the database and creating the cloud
+      user.
+
+   -  
+
+      (Optional) For encryption\_type, use file or web to indicate the
+      technique used to pass in the database encryption password.
+      Default: file. See `Section 4.5.5, “About Password and Key
+      Encryption” <#about-password-encryption>`__.
+
+   -  
+
+      (Optional) For management\_server\_key, substitute the default key
+      that is used to encrypt confidential parameters in the CloudStack
+      properties file. Default: password. It is highly recommended that
+      you replace this with a more secure value. See About Password and
+      Key Encryption.
+
+   -  
+
+      (Optional) For database\_key, substitute the default key that is
+      used to encrypt confidential parameters in the CloudStack
+      database. Default: password. It is highly recommended that you
+      replace this with a more secure value. See `Section 4.5.5, “About
+      Password and Key Encryption” <#about-password-encryption>`__.
+
+   -  
+
+      (Optional) For management\_server\_ip, you may explicitly specify
+      cluster management server node IP. If not specified, the local IP
+      address will be used.
+
+   .. code:: programlisting
+
+       cloudstack-setup-databases cloud:<dbpassword>@<ip address mysql server> \
+       --deploy-as=root:<password> \
+       -e <encryption_type> \
+       -m <management_server_key> \
+       -k <database_key> \
+       -i <management_server_ip>
+
+   When this script is finished, you should see a message like
+   “Successfully initialized the database.”
+
+4.5.5. About Password and Key Encryption
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CloudStack stores several sensitive passwords and secret keys that are
+used to provide security. These values are always automatically
+encrypted:
+
+-  
+
+   Database secret key
+
+-  
+
+   Database password
+
+-  
+
+   SSH keys
+
+-  
+
+   Compute node root password
+
+-  
+
+   VPN password
+
+-  
+
+   User API secret key
+
+-  
+
+   VNC password
+
+CloudStack uses the Java Simplified Encryption (JASYPT) library. The
+data values are encrypted and decrypted using a database secret key,
+which is stored in one of CloudStack’s internal properties files along
+with the database password. The other encrypted values listed above,
+such as SSH keys, are in the CloudStack internal database.
+
+Of course, the database secret key itself can not be stored in the open
+– it must be encrypted. How then does CloudStack read it? A second
+secret key must be provided from an external source during Management
+Server startup. This key can be provided in one of two ways: loaded from
+a file or provided by the CloudStack administrator. The CloudStack
+database has a configuration setting that lets it know which of these
+methods will be used. If the encryption type is set to "file," the key
+must be in a file in a known location. If the encryption type is set to
+"web," the administrator runs the utility
+com.cloud.utils.crypt.EncryptionSecretKeySender, which relays the key to
+the Management Server over a known port.
+
+The encryption type, database secret key, and Management Server secret
+key are set during CloudStack installation. They are all parameters to
+the CloudStack database setup script (cloudstack-setup-databases). The
+default values are file, password, and password. It is, of course,
+highly recommended that you change these to more secure keys.
+
+4.5.6. Changing the Default Password Encryption
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Passwords are encoded when creating or updating users. CloudStack allows
+you to determine the default encoding and authentication mechanism for
+admin and user logins. Two new configurable lists have been
+introduced—userPasswordEncoders and userAuthenticators.
+userPasswordEncoders allows you to configure the order of preference for
+encoding passwords, whereas userAuthenticators allows you to configure
+the order in which authentication schemes are invoked to validate user
+passwords.
+
+Additionally, the plain text user authenticator has been modified not to
+convert supplied passwords to their md5 sums before checking them with
+the database entries. It performs a simple string comparison between
+retrieved and supplied login passwords instead of comparing the
+retrieved md5 hash of the stored password against the supplied md5 hash
+of the password because clients no longer hash the password. The
+following method determines what encoding scheme is used to encode the
+password supplied during user creation or modification.
+
+When a new user is created, the user password is encoded by using the
+first valid encoder loaded as per the sequence specified in the
+``UserPasswordEncoders`` property in the ``ComponentContext.xml`` or
+``nonossComponentContext.xml`` files. The order of authentication
+schemes is determined by the ``UserAuthenticators`` property in the same
+files. If Non-OSS components, such as VMware environments, are to be
+deployed, modify the ``UserPasswordEncoders`` and ``UserAuthenticators``
+lists in the ``nonossComponentContext.xml`` file, for OSS environments,
+such as XenServer or KVM, modify the ``ComponentContext.xml`` file. It
+is recommended to make uniform changes across both the files. When a new
+authenticator or encoder is added, you can add them to this list. While
+doing so, ensure that the new authenticator or encoder is specified as a
+bean in both these files. The administrator can change the ordering of
+both these properties as preferred to change the order of schemes.
+Modify the following list properties available in
+``client/tomcatconf/nonossComponentContext.xml.in`` or
+``client/tomcatconf/componentContext.xml.in`` as applicable, to the
+desired order:
+
+.. code:: programlisting
+
+    <property name="UserAuthenticators">
+             <list>
+                <ref bean="SHA256SaltedUserAuthenticator"/>
+                <ref bean="MD5UserAuthenticator"/>
+                <ref bean="LDAPUserAuthenticator"/>
+                <ref bean="PlainTextUserAuthenticator"/>
+            </list>
+        </property>
+        <property name="UserPasswordEncoders">
+            <list>
+                <ref bean="SHA256SaltedUserAuthenticator"/>
+                 <ref bean="MD5UserAuthenticator"/>
+                 <ref bean="LDAPUserAuthenticator"/>
+                <ref bean="PlainTextUserAuthenticator"/>
+                </list>
+
+In the above default ordering, SHA256Salt is used first for
+``UserPasswordEncoders``. If the module is found and encoding returns a
+valid value, the encoded password is stored in the user table's password
+column. If it fails for any reason, the MD5UserAuthenticator will be
+tried next, and the order continues. For ``UserAuthenticators``,
+SHA256Salt authentication is tried first. If it succeeds, the user is
+logged into the Management server. If it fails, md5 is tried next, and
+attempts continues until any of them succeeds and the user logs in . If
+none of them works, the user is returned an invalid credential message.
+
+4.5.7. Prepare NFS Shares
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CloudStack needs a place to keep primary and secondary storage (see
+Cloud Infrastructure Overview). Both of these can be NFS shares. This
+section tells how to set up the NFS shares before adding the storage to
+CloudStack.
+
+Alternative Storage
+-------------------
+
+NFS is not the only option for primary or secondary storage. For
+example, you may use Ceph RBD, GlusterFS, iSCSI, and others. The choice
+of storage system will depend on the choice of hypervisor and whether
+you are dealing with primary or secondary storage.
+
+The requirements for primary and secondary storage are described in:
+
+-  
+
+   `Section 2.6, “About Primary Storage” <#about-primary-storage>`__
+
+-  
+
+   `Section 2.7, “About Secondary Storage” <#about-secondary-storage>`__
+
+A production installation typically uses a separate NFS server. See
+`Section 4.5.7.1, “Using a Separate NFS
+Server” <#nfs-shares-on-separate-server>`__.
+
+You can also use the Management Server node as the NFS server. This is
+more typical of a trial installation, but is technically possible in a
+larger deployment. See `Section 4.5.7.2, “Using the Management Server as
+the NFS Server” <#nfs-shares-on-management-server>`__.
+
+4.5.7.1. Using a Separate NFS Server
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section tells how to set up NFS shares for secondary and
+(optionally) primary storage on an NFS server running on a separate node
+from the Management Server.
+
+The exact commands for the following steps may vary depending on your
+operating system version.
+
+Warning
+-------
+
+(KVM only) Ensure that no volume is already mounted at your NFS mount
+point.
+
+#. 
+
+   On the storage server, create an NFS share for secondary storage and,
+   if you are using NFS for primary storage as well, create a second NFS
+   share. For example:
+
+   .. code:: programlisting
+
+       # mkdir -p /export/primary
+       # mkdir -p /export/secondary
+
+#. 
+
+   To configure the new directories as NFS exports, edit /etc/exports.
+   Export the NFS share(s) with
+   rw,async,no\_root\_squash,no\_subtree\_check. For example:
+
+   .. code:: programlisting
+
+       # vi /etc/exports
+
+   Insert the following line.
+
+   .. code:: programlisting
+
+       /export  *(rw,async,no_root_squash,no_subtree_check)
+
+#. 
+
+   Export the /export directory.
+
+   .. code:: programlisting
+
+       # exportfs -a
+
+#. 
+
+   On the management server, create a mount point for secondary storage.
+   For example:
+
+   .. code:: programlisting
+
+       # mkdir -p /mnt/secondary
+
+#. 
+
+   Mount the secondary storage on your Management Server. Replace the
+   example NFS server name and NFS share paths below with your own.
+
+   .. code:: programlisting
+
+       # mount -t nfs nfsservername:/nfs/share/secondary /mnt/secondary
+
+4.5.7.2. Using the Management Server as the NFS Server
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section tells how to set up NFS shares for primary and secondary
+storage on the same node with the Management Server. This is more
+typical of a trial installation, but is technically possible in a larger
+deployment. It is assumed that you will have less than 16TB of storage
+on the host.
+
+The exact commands for the following steps may vary depending on your
+operating system version.
+
+#. 
+
+   On RHEL/CentOS systems, you'll need to install the nfs-utils package:
+
+   .. code:: programlisting
+
+       $ sudo yum install nfs-utils
+
+#. 
+
+   On the Management Server host, create two directories that you will
+   use for primary and secondary storage. For example:
+
+   .. code:: programlisting
+
+       # mkdir -p /export/primary
+       # mkdir -p /export/secondary
+
+#. 
+
+   To configure the new directories as NFS exports, edit /etc/exports.
+   Export the NFS share(s) with
+   rw,async,no\_root\_squash,no\_subtree\_check. For example:
+
+   .. code:: programlisting
+
+       # vi /etc/exports
+
+   Insert the following line.
+
+   .. code:: programlisting
+
+       /export  *(rw,async,no_root_squash,no_subtree_check)
+
+#. 
+
+   Export the /export directory.
+
+   .. code:: programlisting
+
+       # exportfs -a
+
+#. 
+
+   Edit the /etc/sysconfig/nfs file.
+
+   .. code:: programlisting
+
+       # vi /etc/sysconfig/nfs
+
+   Uncomment the following lines:
+
+   .. code:: programlisting
+
+       LOCKD_TCPPORT=32803
+       LOCKD_UDPPORT=32769
+       MOUNTD_PORT=892
+       RQUOTAD_PORT=875
+       STATD_PORT=662
+       STATD_OUTGOING_PORT=2020
+
+#. 
+
+   Edit the /etc/sysconfig/iptables file.
+
+   .. code:: programlisting
+
+       # vi /etc/sysconfig/iptables
+
+   Add the following lines at the beginning of the INPUT chain, where
+   <NETWORK> is the network that you'll be using:
+
+   .. code:: programlisting
+
+       -A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 111 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 111 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 32769 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 892 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 892 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 875 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 875 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 662 -j ACCEPT
+       -A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 662 -j ACCEPT                
+
+#. 
+
+   Run the following commands:
+
+   .. code:: programlisting
+
+       # service iptables restart
+       # service iptables save
+
+#. 
+
+   If NFS v4 communication is used between client and server, add your
+   domain to /etc/idmapd.conf on both the hypervisor host and Management
+   Server.
+
+   .. code:: programlisting
+
+       # vi /etc/idmapd.conf
+
+   Remove the character # from the beginning of the Domain line in
+   idmapd.conf and replace the value in the file with your own domain.
+   In the example below, the domain is company.com.
+
+   .. code:: programlisting
+
+       Domain = company.com
+
+#. 
+
+   Reboot the Management Server host.
+
+   Two NFS shares called /export/primary and /export/secondary are now
+   set up.
+
+#. 
+
+   It is recommended that you test to be sure the previous steps have
+   been successful.
+
+   #. 
+
+      Log in to the hypervisor host.
+
+   #. 
+
+      Be sure NFS and rpcbind are running. The commands might be
+      different depending on your OS. For example:
+
+      .. code:: programlisting
+
+          # service rpcbind start
+          # service nfs start
+          # chkconfig nfs on
+          # chkconfig rpcbind on
+          # reboot
+
+   #. 
+
+      Log back in to the hypervisor host and try to mount the /export
+      directories. For example, substitute your own management server
+      name:
+
+      .. code:: programlisting
+
+          # mkdir /primary
+          # mount -t nfs <management-server-name>:/export/primary
+          # umount /primary
+          # mkdir /secondary
+          # mount -t nfs <management-server-name>:/export/secondary
+          # umount /secondary
+
+4.5.8. Prepare and Start Additional Management Servers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For your second and subsequent Management Servers, you will install the
+Management Server software, connect it to the database, and set up the
+OS for the Management Server.
+
+#. 
+
+   Perform the steps in `Section 4.5.2, “Prepare the Operating
+   System” <#prepare-os>`__ and `Section 3.6, “Building RPMs from
+   Source” <#sect-source-buildrpm>`__ or `Section 3.5, “Building DEB
+   packages” <#sect-source-builddebs>`__ as appropriate.
+
+#. 
+
+   This step is required only for installations where XenServer is
+   installed on the hypervisor hosts.
+
+   Download vhd-util from
+   `vhd-util <http://download.cloud.com.s3.amazonaws.com/tools/vhd-util>`__
+
+   Copy vhd-util to
+   /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver.
+
+#. 
+
+   Ensure that necessary services are started and set to start on boot.
+
+   .. code:: programlisting
+
+       # service rpcbind start
+       # service nfs start
+       # chkconfig nfs on
+       # chkconfig rpcbind on
+
+#. 
+
+   Configure the database client. Note the absence of the --deploy-as
+   argument in this case. (For more details about the arguments to this
+   command, see `Section 4.5.4.2, “Install the Database on a Separate
+   Node” <#management-server-install-db-external>`__.)
+
+   .. code:: programlisting
+
+       # cloudstack-setup-databases cloud:dbpassword@dbhost -e encryption_type -m management_server_key -k database_key -i management_server_ip
+
+#. 
+
+   Configure the OS and start the Management Server:
+
+   .. code:: programlisting
+
+       # cloudstack-setup-management
+
+   The Management Server on this node should now be running.
+
+#. 
+
+   Repeat these steps on each additional Management Server.
+
+#. 
+
+   Be sure to configure a load balancer for the Management Servers. See
+   `Section 13.6, “Management Server Load
+   Balancing” <#management-server-lb>`__.
+
+4.5.9. Prepare the System VM Template
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Secondary storage must be seeded with a template that is used for
+CloudStack system VMs.
+
+Note
+----
+
+When copying and pasting a command, be sure the command has pasted as a
+single line before executing. Some document viewers may introduce
+unwanted line breaks in copied text.
+
+#. 
+
+   On the Management Server, run one or more of the following
+   cloud-install-sys-tmplt commands to retrieve and decompress the
+   system VM template. Run the command for each hypervisor type that you
+   expect end users to run in this Zone.
+
+   If your secondary storage mount point is not named /mnt/secondary,
+   substi

<TRUNCATED>

Mime
View raw message