cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From seb...@apache.org
Subject [2/3] Initial commit to populate repo
Date Sat, 25 Jan 2014 21:17:56 GMT
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/959c71e1/source/administration.rst
----------------------------------------------------------------------
diff --git a/source/administration.rst b/source/administration.rst
new file mode 100644
index 0000000..affdc39
--- /dev/null
+++ b/source/administration.rst
@@ -0,0 +1,23217 @@
+|Product Site|\ |Documentation Site|
+
+Apache CloudStack 4.3.0
+
+Edition 1
+
+Apache CloudStack
+~~~~~~~~~~~~~~~~~
+
+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
+        
+
+Administration Guide for CloudStack.
+
+`1. Concepts <#concepts>`__
+
+`1.1. What Is CloudStack? <#whatis>`__
+
+`1.2. What Can CloudStack Do? <#feature-overview>`__
+
+`1.3. Deployment Architecture
+Overview <#deployment-architecture-overview>`__
+
+`1.3.1. Management Server Overview <#management-server-overview>`__
+
+`1.3.2. Cloud Infrastructure
+Overview <#cloud-infrastructure-overview>`__
+
+`1.3.3. Networking Overview <#networking-overview>`__
+
+`2. Cloud Infrastructure Concepts <#cloud-infrastructure-concepts>`__
+
+`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>`__
+
+`3. Accounts <#accounts>`__
+
+`3.1. Accounts, Users, and Domains <#accounts-users-domains>`__
+
+`3.1.1. Dedicating Resources to Accounts and
+Domains <#dedicated-host-cluster-pod>`__
+
+`3.2. Using an LDAP Server for User
+Authentication <#LDAPserver-for-user-authentication>`__
+
+`3.2.1. Example LDAP Configuration
+Commands <#example-LDAP-configuration-commands>`__
+
+`3.2.2. Search Base <#search-base>`__
+
+`3.2.3. Query Filter <#query-filter>`__
+
+`3.2.4. Search User Bind DN <#search-user-bind-dn>`__
+
+`3.2.5. SSL Keystore Path and
+Password <#SSL-keystore-path-and-password>`__
+
+`4. User Services Overview <#user-services-overview>`__
+
+`4.1. Service Offerings, Disk Offerings, Network Offerings, and
+Templates <#offerings-and-templates>`__
+
+`5. User Interface <#ui>`__
+
+`5.1. Log In to the UI <#log-in>`__
+
+`5.1.1. End User's UI Overview <#end-user-ui-overview>`__
+
+`5.1.2. Root Administrator's UI Overview <#root-admin-ui-overview>`__
+
+`5.1.3. Logging In as the Root Administrator <#log-in-root-admin>`__
+
+`5.1.4. Changing the Root Password <#changing-root-password>`__
+
+`5.2. Using SSH Keys for Authentication <#using-sshkeys>`__
+
+`5.2.1. Creating an Instance Template that Supports SSH
+Keys <#create-ssh-template>`__
+
+`5.2.2. Creating the SSH Keypair <#create-ssh-keypair>`__
+
+`5.2.3. Creating an Instance <#creating-ssh-instance>`__
+
+`5.2.4. Logging In Using the SSH Keypair <#logging-in-ssh>`__
+
+`5.2.5. Resetting SSH Keys <#reset-ssh>`__
+
+`6. Using Projects to Organize Users and Resources <#projects>`__
+
+`6.1. Overview of Projects <#projects-overview>`__
+
+`6.2. Configuring Projects <#configuring-projects>`__
+
+`6.2.1. Setting Up Invitations <#set-up-invitations>`__
+
+`6.2.2. Setting Resource Limits for
+Projects <#set-resource-limits-for-projects>`__
+
+`6.2.3. Setting Project Creator
+Permissions <#set-projects-creator-permissions>`__
+
+`6.3. Creating a New Project <#create-new-projects>`__
+
+`6.4. Adding Members to a Project <#add-members-to-projects>`__
+
+`6.4.1. Sending Project Membership
+Invitations <#send-projects-membership-invitation>`__
+
+`6.4.2. Adding Project Members From the
+UI <#add-projects-members-from-ui>`__
+
+`6.5. Accepting a Membership Invitation <#accept-membership-invite>`__
+
+`6.6. Suspending or Deleting a Project <#suspend-project>`__
+
+`6.7. Using the Project View <#use-project-view>`__
+
+`7. Steps to Provisioning Your Cloud
+Infrastructure <#provisioning-steps>`__
+
+`7.1. Overview of Provisioning Steps <#provisioning-steps-overview>`__
+
+`7.2. Adding Regions (optional) <#region-add>`__
+
+`7.2.1. The First Region: The Default Region <#region-first>`__
+
+`7.2.2. Adding a Region <#region-add-2>`__
+
+`7.2.3. Adding Third and Subsequent Regions <#region-add-n>`__
+
+`7.2.4. Deleting a Region <#region-delete>`__
+
+`7.3. Adding a Zone <#zone-add>`__
+
+`7.3.1. Basic Zone Configuration <#basic-zone-configuration>`__
+
+`7.3.2. Advanced Zone Configuration <#advanced-zone-configuration>`__
+
+`7.4. Adding a Pod <#pod-add>`__
+
+`7.5. Adding a Cluster <#cluster-add>`__
+
+`7.5.1. Add Cluster: KVM or XenServer <#add-clusters-kvm-xenserver>`__
+
+`7.5.2. Add Cluster: vSphere <#add-clusters-vsphere>`__
+
+`7.6. Adding a Host <#host-add>`__
+
+`7.6.1. Adding a Host (XenServer or
+KVM) <#host-add-xenserver-kvm-ovm>`__
+
+`7.6.2. Adding a Host (vSphere) <#host-add-vsphere>`__
+
+`7.7. Add Primary Storage <#primary-storage-add>`__
+
+`7.7.1. System Requirements for Primary
+Storage <#sys-require-primary-storage>`__
+
+`7.7.2. Adding Primary Storage <#adding-primary-storage>`__
+
+`7.7.3. Configuring a Storage Plug-in <#idp140221224805280>`__
+
+`7.8. Add Secondary Storage <#secondary-storage-add>`__
+
+`7.8.1. System Requirements for Secondary
+Storage <#sys-require-secondary-storage>`__
+
+`7.8.2. Adding Secondary Storage <#adding-secondary-storage>`__
+
+`7.8.3. Adding an NFS Secondary Staging Store for Each
+Zone <#secondary-staging-store>`__
+
+`7.9. Initialize and Test <#initialize-and-test>`__
+
+`8. Service Offerings <#offerings>`__
+
+`8.1. Compute and Disk Service
+Offerings <#compute-disk-service-offerings>`__
+
+`8.1.1. Creating a New Compute Offering <#creating-compute-offerings>`__
+
+`8.1.2. Creating a New Disk Offering <#creating-disk-offerings>`__
+
+`8.1.3. Modifying or Deleting a Service
+Offering <#modify-delete-service-offerings>`__
+
+`8.2. System Service Offerings <#system-service-offerings>`__
+
+`8.2.1. Creating a New System Service
+Offering <#creating-system-service-offerings>`__
+
+`8.3. Network Throttling <#network-rate>`__
+
+`8.4. Changing the Default System Offering for System
+VMs <#sys-offering-sysvm>`__
+
+`9. Setting Up Networking for Users <#set-up-network-for-users>`__
+
+`9.1. Overview of Setting Up Networking for
+Users <#networks-for-users-overview>`__
+
+`9.2. About Virtual Networks <#about-virtual-networks>`__
+
+`9.2.1. Isolated Networks <#isolated-networks>`__
+
+`9.2.2. Shared Networks <#shared-networks>`__
+
+`9.2.3. Runtime Allocation of Virtual Network
+Resources <#runtime-allocation-virtual-network-resources>`__
+
+`9.3. Network Service Providers <#network-service-providers>`__
+
+`9.4. Network Offerings <#network-offerings>`__
+
+`9.4.1. Creating a New Network Offering <#creating-network-offerings>`__
+
+`10. Working With Virtual Machines <#virtual-machines>`__
+
+`10.1. About Working with Virtual Machines <#about-working-with-vms>`__
+
+`10.2. Best Practices for Virtual Machines <#best-practices-vm>`__
+
+`10.2.1. Monitor VMs for Max Capacity <#best-practices-vm-monitoring>`__
+
+`10.2.2. Install Required Tools and
+Drivers <#best-practices-vm-tools>`__
+
+`10.3. VM Lifecycle <#vm-lifecycle>`__
+
+`10.4. Creating VMs <#creating-vms>`__
+
+`10.5. Accessing VMs <#accessing-vms>`__
+
+`10.6. Stopping and Starting VMs <#stopping-and-starting-vms>`__
+
+`10.7. Assigning VMs to Hosts <#host-allocation>`__
+
+`10.7.1. Affinity Groups <#affinity-groups>`__
+
+`10.8. Virtual Machine Snapshots <#vm-snapshots>`__
+
+`10.8.1. Limitations on VM Snapshots <#vm-snapshot-restrictions>`__
+
+`10.8.2. Configuring VM Snapshots <#vm-snapshot-configure>`__
+
+`10.8.3. Using VM Snapshots <#vm-snapshot-usage>`__
+
+`10.9. Changing the VM Name, OS, or
+Group <#changing-vm-name-os-group>`__
+
+`10.10. Appending a Display Name to the Guest VM’s Internal
+Name <#append-displayname-vms>`__
+
+`10.11. Changing the Service Offering for a
+VM <#changing-service-offering-for-vm>`__
+
+`10.11.1. CPU and Memory Scaling for Running
+VMs <#change-cpu-ram-for-vm>`__
+
+`10.11.2. Updating Existing VMs <#update-vms>`__
+
+`10.11.3. Configuring Dynamic CPU and RAM
+Scaling <#configure-dynamic-scaling>`__
+
+`10.11.4. How to Dynamically Scale CPU and
+RAM <#dynamic-scaling-howto>`__
+
+`10.11.5. Limitations <#dynamic-scaling-limitations>`__
+
+`10.12. Resetting the Virtual Machine Root Volume on
+Reboot <#reset-volume-on-reboot-vm>`__
+
+`10.13. Moving VMs Between Hosts (Manual Live
+Migration) <#manual-live-migration>`__
+
+`10.14. Deleting VMs <#deleting-vms>`__
+
+`10.15. Working with ISOs <#working-with-iso>`__
+
+`10.15.1. Adding an ISO <#add-iso>`__
+
+`10.15.2. Attaching an ISO to a VM <#attach-iso-to-vm>`__
+
+`10.15.3. Changing a VM's Base Image <#update-iso-vm>`__
+
+`11. Working With Hosts <#working-with-hosts>`__
+
+`11.1. Adding Hosts <#adding-hosts>`__
+
+`11.2. Scheduled Maintenance and Maintenance Mode for
+Hosts <#scheduled-maintenance-maintenance-mode-hosts>`__
+
+`11.2.1. vCenter and Maintenance Mode <#vcenter-maintenance-mode>`__
+
+`11.2.2. XenServer and Maintenance Mode <#xenserver-maintenance-mode>`__
+
+`11.3. Disabling and Enabling Zones, Pods, and
+Clusters <#disable-enable-zones-pods-clusters>`__
+
+`11.4. Removing Hosts <#removing-hosts>`__
+
+`11.4.1. Removing XenServer and KVM
+Hosts <#removing-xenserver-kvm-hosts>`__
+
+`11.4.2. Removing vSphere Hosts <#removing-vsphere-hosts>`__
+
+`11.5. Re-Installing Hosts <#re-install-hosts>`__
+
+`11.6. Maintaining Hypervisors on
+Hosts <#maintain-hypervisors-on-hosts>`__
+
+`11.7. Changing Host Password <#change-host-password>`__
+
+`11.8. Over-Provisioning and Service Offering
+Limits <#over-provisioning-service-offering-limits>`__
+
+`11.8.1. Limitations on Over-Provisioning in XenServer and
+KVM <#overcommit-limitations>`__
+
+`11.8.2. Requirements for
+Over-Provisioning <#overcommit-prerequisites>`__
+
+`11.8.3. Setting Over-Provisioning Ratios <#create-overcommit>`__
+
+`11.8.4. Service Offering Limits and
+Over-Provisioning <#op-service-offering-limits>`__
+
+`11.9. VLAN Provisioning <#vlan-provisioning>`__
+
+`11.9.1. VLAN Allocation Example <#vlan-allocation-eg>`__
+
+`11.9.2. Adding Non Contiguous VLAN Ranges <#non-contiguous-vlan>`__
+
+`11.9.3. Assigning VLANs to Isolated
+Networks <#vlan-assign-isolated-nw>`__
+
+`12. Working with Templates <#working-with-templates>`__
+
+`12.1. Creating Templates: Overview <#create-templates-overview>`__
+
+`12.2. Requirements for Templates <#requirements-templates>`__
+
+`12.3. Best Practices for Templates <#best-practices-templates>`__
+
+`12.4. The Default Template <#default-template>`__
+
+`12.5. Private and Public Templates <#private-public-template>`__
+
+`12.6. Creating a Template from an Existing Virtual
+Machine <#create-template-from-existing-vm>`__
+
+`12.7. Creating a Template from a
+Snapshot <#create-template-from-snapshot>`__
+
+`12.8. Uploading Templates <#upload-template>`__
+
+`12.9. Exporting Templates <#export-template>`__
+
+`12.10. Creating a Linux Template <#create-linux-template>`__
+
+`12.10.1. System preparation for Linux <#prepare-linux-template>`__
+
+`12.11. Creating a Windows Template <#create-windows-template>`__
+
+`12.11.1. System Preparation for Windows Server 2008
+R2 <#sysprep-windows-server-2008R2>`__
+
+`12.11.2. System Preparation for Windows Server 2003
+R2 <#sysprep-for-windows-server-2003R2>`__
+
+`12.12. Importing Amazon Machine Images <#import-ami>`__
+
+`12.13. Converting a Hyper-V VM to a
+Template <#convert-hyperv-vm-to-template>`__
+
+`12.14. Adding Password Management to Your
+Templates <#add-password-management-to-templates>`__
+
+`12.14.1. Linux OS Installation <#linux-installation>`__
+
+`12.14.2. Windows OS Installation <#windows-installation>`__
+
+`12.15. Deleting Templates <#delete-templates>`__
+
+`13. Working With Storage <#storage>`__
+
+`13.1. Storage Overview <#storage-overview>`__
+
+`13.2. Primary Storage <#primary-storage>`__
+
+`13.2.1. Best Practices for Primary
+Storage <#best-practices-primary-storage>`__
+
+`13.2.2. Runtime Behavior of Primary
+Storage <#runtime-behavior-of-primary-storage>`__
+
+`13.2.3. Hypervisor Support for Primary
+Storage <#hypervisor-support-for-primarystorage>`__
+
+`13.2.4. Storage Tags <#storage-tags>`__
+
+`13.2.5. Maintenance Mode for Primary
+Storage <#maintenance-mode-for-primary-storage.xml>`__
+
+`13.3. Secondary Storage <#secondary-storage>`__
+
+`13.4. Working With Volumes <#working-with-volumes>`__
+
+`13.4.1. Creating a New Volume <#creating-new-volumes>`__
+
+`13.4.2. Uploading an Existing Volume to a Virtual
+Machine <#upload-existing-volume-to-vm>`__
+
+`13.4.3. Attaching a Volume <#attaching-volume>`__
+
+`13.4.4. Detaching and Moving Volumes <#detach-move-volumes>`__
+
+`13.4.5. VM Storage Migration <#vm-storage-migration>`__
+
+`13.4.6. Resizing Volumes <#resizing-volumes>`__
+
+`13.4.7. Reset VM to New Root Disk on Reboot <#reset-vm-reboot>`__
+
+`13.4.8. Volume Deletion and Garbage
+Collection <#volume-deletion-garbage-collection>`__
+
+`13.5. Working with Volume Snapshots <#working-with-snapshots>`__
+
+`13.5.1. How to Snapshot a Volume <#how-to-volume-snapshot>`__
+
+`13.5.2. Automatic Snapshot Creation and
+Retention <#automatic-snapshot-creation-retention>`__
+
+`13.5.3. Incremental Snapshots and
+Backup <#incremental-snapshots-backup>`__
+
+`13.5.4. Volume Status <#volume-status>`__
+
+`13.5.5. Snapshot Restore <#snapshot-restore>`__
+
+`13.5.6. Snapshot Job Throttling <#snapshot-throttling>`__
+
+`13.5.7. VMware Volume Snapshot
+Performance <#snapshot-performance-vmware>`__
+
+`14. Working with Usage <#work-with-usage>`__
+
+`14.1. Configuring the Usage Server <#configure-usage-server>`__
+
+`14.2. Setting Usage Limits <#set-usage-limit>`__
+
+`14.3. Globally Configured Limits <#globally-configured-limits>`__
+
+`14.4. Limiting Resource Usage <#limit-accounts-domains>`__
+
+`14.4.1. User Permission <#user-permission-rn>`__
+
+`14.4.2. Limit Usage Considerations <#consideration-rn>`__
+
+`14.4.3. Limiting Resource Usage in a Domain <#per-domain-limits>`__
+
+`14.4.4. Default Account Resource
+Limits <#default-account-resource-limit>`__
+
+`15. Managing Networks and Traffic <#networks>`__
+
+`15.1. Guest Traffic <#guest-traffic>`__
+
+`15.2. Networking in a Pod <#networking-in-a-pod>`__
+
+`15.3. Networking in a Zone <#networking-in-a-zone>`__
+
+`15.4. Basic Zone Physical Network
+Configuration <#basic-zone-physical-network-configuration>`__
+
+`15.5. Advanced Zone Physical Network
+Configuration <#advanced-zone-physical-network-configuration>`__
+
+`15.5.1. Configure Guest Traffic in an Advanced
+Zone <#configure-guest-traffic-in-advanced-zone>`__
+
+`15.5.2. Configure Public Traffic in an Advanced
+Zone <#configure-public-traffic-in-an-advanced-zone>`__
+
+`15.5.3. Configuring a Shared Guest
+Network <#creating-shared-network>`__
+
+`15.6. Using Multiple Guest Networks <#using-multiple-guest-networks>`__
+
+`15.6.1. Adding an Additional Guest
+Network <#add-additional-guest-network>`__
+
+`15.6.2. Reconfiguring Networks in VMs <#add-remove-nic-ui>`__
+
+`15.6.3. Changing the Network Offering on a Guest
+Network <#change-network-offering-on-guest-network>`__
+
+`15.7. IP Reservation in Isolated Guest
+Networks <#reserved-ip-addresses-non-csvms>`__
+
+`15.7.1. IP Reservation Considerations <#ip-reserve-consider>`__
+
+`15.7.2. Limitations <#ip-reserv-limition>`__
+
+`15.7.3. Best Practices <#best-practice-ipreserv>`__
+
+`15.7.4. Reserving an IP Range <#reserve-ip>`__
+
+`15.8. Reserving Public IP Addresses and VLANs for
+Accounts <#ip-vlan-tenant>`__
+
+`15.8.1. Dedicating IP Address Ranges to an
+Account <#howto-dedicate-ip>`__
+
+`15.8.2. Dedicating VLAN Ranges to an Account <#howto-dedicate-vlan>`__
+
+`15.9. Configuring Multiple IP Addresses on a Single
+NIC <#multiple-ip-nic>`__
+
+`15.9.1. Use Cases <#usecases-mip>`__
+
+`15.9.2. Guidelines <#guideline-nic>`__
+
+`15.9.3. Assigning Additional IPs to a VM <#workflow-rn>`__
+
+`15.9.4. Port Forwarding and StaticNAT Services Changes <#caveats>`__
+
+`15.10. About Multiple IP Ranges <#multiple-ip-range>`__
+
+`15.11. About Elastic IP <#elastic-ip>`__
+
+`15.12. Portable IPs <#portable-ip>`__
+
+`15.12.1. About Portable IP <#about-pip>`__
+
+`15.12.2. Configuring Portable IPs <#config-pip>`__
+
+`15.12.3. Acquiring a Portable IP <#acquire-pip>`__
+
+`15.12.4. Transferring Portable IP <#transfer-pip>`__
+
+`15.13. Multiple Subnets in Shared Network <#add-ip-range>`__
+
+`15.13.1. Prerequisites and Guidelines <#guidelines-multiplesubnet>`__
+
+`15.13.2. Adding Multiple Subnets to a Shared
+Network <#how-to-add-ip>`__
+
+`15.14. Isolation in Advanced Zone Using Private VLAN <#pvlan>`__
+
+`15.14.1. About Private VLAN <#about-pvlan>`__
+
+`15.14.2. Prerequisites <#prereq-pvlan>`__
+
+`15.14.3. Creating a PVLAN-Enabled Guest Network <#ability-pvlan>`__
+
+`15.15. Security Groups <#security-groups>`__
+
+`15.15.1. About Security Groups <#about-security-groups>`__
+
+`15.15.2. Adding a Security Group <#add-security-group>`__
+
+`15.15.3. Security Groups in Advanced Zones (KVM
+Only) <#security-groups-advanced-zones>`__
+
+`15.15.4. Enabling Security Groups <#enable-security-groups>`__
+
+`15.15.5. Adding Ingress and Egress Rules to a Security
+Group <#add-ingress-egress-rules>`__
+
+`15.16. External Firewalls and Load
+Balancers <#external-firewalls-and-load-balancers>`__
+
+`15.16.1. About Using a NetScaler Load
+Balancer <#using-netscaler-load-balancers>`__
+
+`15.16.2. Configuring SNMP Community String on a RHEL
+Server <#configure-snmp-rhel>`__
+
+`15.16.3. Initial Setup of External Firewalls and Load
+Balancers <#initial-setup-of-external-firewalls-loadbalancer>`__
+
+`15.16.4. Ongoing Configuration of External Firewalls and Load
+Balancers <#ongoing-config-of-external-firewalls-ld>`__
+
+`15.16.5. Load Balancer Rules <#load-balancer-rules>`__
+
+`15.16.6. Configuring AutoScale <#autoscale>`__
+
+`15.17. Global Server Load Balancing Support <#gslb>`__
+
+`15.17.1. About Global Server Load Balancing <#about-gslb>`__
+
+`15.17.2. Configuring GSLB <#gslb-workflow>`__
+
+`15.17.3. Known Limitation <#idp140221228139200>`__
+
+`15.18. Guest IP Ranges <#guest-ip-ranges>`__
+
+`15.19. Acquiring a New IP Address <#acquire-new-ip-address>`__
+
+`15.20. Releasing an IP Address <#release-ip-address>`__
+
+`15.21. Static NAT <#static-nat>`__
+
+`15.21.1. Enabling or Disabling Static
+NAT <#enable-disable-static-nat>`__
+
+`15.22. IP Forwarding and Firewalling <#ip-forwarding-firewalling>`__
+
+`15.22.1. Firewall Rules <#firewall-rules>`__
+
+`15.22.2. Egress Firewall Rules in an Advanced
+Zone <#egress-firewall-rule>`__
+
+`15.22.3. Port Forwarding <#port-forwarding>`__
+
+`15.23. IP Load Balancing <#ip-load-balancing>`__
+
+`15.24. DNS and DHCP <#dns-dhcp>`__
+
+`15.25. Remote Access VPN <#vpn>`__
+
+`15.25.1. Configuring Remote Access VPN <#configure-vpn>`__
+
+`15.25.2. Configuring Remote Access VPN in VPC <#configure-vpn-vpc>`__
+
+`15.25.3. Using Remote Access VPN with
+Windows <#using-vpn-with-windows>`__
+
+`15.25.4. Using Remote Access VPN with Mac OS X <#using-vpn-with-mac>`__
+
+`15.25.5. Setting Up a Site-to-Site VPN
+Connection <#site-to-site-vpn>`__
+
+`15.26. About Inter-VLAN Routing (nTier Apps) <#inter-vlan-routing>`__
+
+`15.27. Configuring a Virtual Private Cloud <#configure-vpc>`__
+
+`15.27.1. About Virtual Private Clouds <#vpc>`__
+
+`15.27.2. Adding a Virtual Private Cloud <#add-vpc>`__
+
+`15.27.3. Adding Tiers <#add-tier>`__
+
+`15.27.4. Configuring Network Access Control List <#configure-acl>`__
+
+`15.27.5. Adding a Private Gateway to a VPC <#add-gateway-vpc>`__
+
+`15.27.6. Deploying VMs to the Tier <#add-vm-to-tier>`__
+
+`15.27.7. Deploying VMs to VPC Tier and Shared
+Networks <#add-vm-tier-sharednw>`__
+
+`15.27.8. Acquiring a New IP Address for a
+VPC <#acquire-new-ip-for-vpc>`__
+
+`15.27.9. Releasing an IP Address Alloted to a
+VPC <#release-ip-for-vpc>`__
+
+`15.27.10. Enabling or Disabling Static NAT on a
+VPC <#enable-disable-static-nat-vpc>`__
+
+`15.27.11. Adding Load Balancing Rules on a
+VPC <#add-loadbalancer-rule-vpc>`__
+
+`15.27.12. Adding a Port Forwarding Rule on a
+VPC <#add-portforward-vpc>`__
+
+`15.27.13. Removing Tiers <#remove-tier>`__
+
+`15.27.14. Editing, Restarting, and Removing a Virtual Private
+Cloud <#remove-vpc>`__
+
+`15.28. Persistent Networks <#persistent-network>`__
+
+`15.28.1. Persistent Network
+Considerations <#persistent-network-consideration>`__
+
+`15.28.2. Creating a Persistent Guest
+Network <#set-up-persistent-network>`__
+
+`16. Working with System Virtual Machines <#working-with-system-vm>`__
+
+`16.1. The System VM Template <#system-vm-template>`__
+
+`16.2. Changing the Default System VM
+Template <#change-sysmvmtemplate>`__
+
+`16.3. Multiple System VM Support for
+VMware <#multiple-system-vm-vmware>`__
+
+`16.4. Console Proxy <#console-proxy>`__
+
+`16.4.1. Using a SSL Certificate for the Console Proxy <#use-cert>`__
+
+`16.4.2. Changing the Console Proxy SSL Certificate and
+Domain <#change-console-proxy-ssl-certificate-domain>`__
+
+`16.5. Virtual Router <#virtual-router>`__
+
+`16.5.1. Configuring the Virtual Router <#configure-virtual-router>`__
+
+`16.5.2. Upgrading a Virtual Router with System Service
+Offerings <#upgrade-virtual-router-with-service-offering>`__
+
+`16.5.3. Best Practices for Virtual
+Routers <#best-practices-virtual-router>`__
+
+`16.5.4. Service Monitoring Tool for Virtual Router <#vr-monitor>`__
+
+`16.5.5. Enhanced Upgrade for Virtual Routers <#vr-upgrade>`__
+
+`16.6. Secondary Storage VM <#secondary-storage-vm>`__
+
+`17. System Reliability and High
+Availability <#sys-reliability-and-ha>`__
+
+`17.1. HA for Management Server <#ha-management-server>`__
+
+`17.2. Management Server Load Balancing <#management-server-lb>`__
+
+`17.3. HA-Enabled Virtual Machines <#ha-enabled-vm>`__
+
+`17.4. HA for Hosts <#ha-for-hosts>`__
+
+`17.4.1. Dedicated HA Hosts <#dedicated-ha-hosts>`__
+
+`17.5. Primary Storage Outage and Data
+Loss <#primary-storage-outage-and-data-loss>`__
+
+`17.6. Secondary Storage Outage and Data
+Loss <#secondary-storage-outage-and-data-loss>`__
+
+`17.7. Database High Availability <#db-ha>`__
+
+`17.7.1. How to Set Up Database Replication <#db-ha-howto>`__
+
+`17.7.2. Configuring Database High Availability <#db-ha-configure>`__
+
+`17.7.3. Limitations on Database High
+Availability <#db-ha-limitations>`__
+
+`17.8. Limiting the Rate of API Requests <#api-throttling>`__
+
+`17.8.1. Configuring the API Request Rate <#api-throttling-configure>`__
+
+`17.8.2. Limitations on API Throttling <#api-throttling-limitations>`__
+
+`18. Managing the Cloud <#manage-cloud>`__
+
+`18.1. Using Tags to Organize Resources in the
+Cloud <#tagging-resources>`__
+
+`18.2. Changing the Database Configuration <#change-database-config>`__
+
+`18.3. Changing the Database Password <#change-database-password>`__
+
+`18.4. Administrator Alerts <#admin-alerts>`__
+
+`18.4.1. Sending Alerts to External SNMP and Syslog
+Managers <#external-snmp-manager>`__
+
+`18.5. Customizing the Network Domain Name <#customizing-dns>`__
+
+`18.6. Stopping and Restarting the Management
+Server <#stop-restart-management-server>`__
+
+`19. Setting Configuration Parameters <#global-config>`__
+
+`19.1. About Configuration
+Parameters <#about-global-config-parameters>`__
+
+`19.2. Setting Global Configuration Parameters <#global-config-howto>`__
+
+`19.3. Setting Local Configuration Parameters <#local-config-howto>`__
+
+`19.4. Granular Global Configuration Parameters <#granular-param>`__
+
+`20. CloudStack API <#api-overview>`__
+
+`20.1. Provisioning and Authentication API <#provisioning-auth-api>`__
+
+`20.2. User Data and Meta Data <#user-data-and-meta-data>`__
+
+`21. Tuning <#tuning>`__
+
+`21.1. Performance Monitoring <#performance-monitoring>`__
+
+`21.2. Increase Management Server Maximum
+Memory <#increase-management-server-max-memory>`__
+
+`21.3. Set Database Buffer Pool Size <#set-database-buffer-pool-size>`__
+
+`21.4. Set and Monitor Total VM Limits per
+Host <#set-monitor-total-vm-limits-per-host>`__
+
+`21.5. Configure XenServer dom0
+Memory <#configure-xenserver-dom0-memory>`__
+
+`22. Writing a Storage Plugin <#storage-plugins>`__
+
+`22.1. Overview of How to Write a Storage
+Plugin <#storage-plugin-steps>`__
+
+`22.2. Implementing DataStoreDriver <#datastoredriver>`__
+
+`22.3. Implementing DataStoreLifecycle <#datastorelifecycle>`__
+
+`22.4. Implementing DataStoreProvider <#datastoreprovider>`__
+
+`22.5. Implementing
+VMSnapshotStrategy <#implement-vmsnapshotstrategy>`__
+
+`22.6. Place the .jar File in the Right
+Directory <#storage-plugin-code-location>`__
+
+`22.7. Edit Configuration
+Files <#storage-plugin-componentcontext-xml>`__
+
+`22.8. Minimum Required Interfaces <#idp140221247665856>`__
+
+`22.8.1. Interface AmazonS3 <#idp140221247667152>`__
+
+`22.8.2. Class TransferManager <#idp140221236488768>`__
+
+`22.8.3. Class PutObjectRequest <#idp140221225664784>`__
+
+`23. Troubleshooting <#troubleshooting>`__
+
+`23.1. Events <#events>`__
+
+`23.1.1. Event Logs <#events-log>`__
+
+`23.1.2. Event Notification <#event-framework>`__
+
+`23.1.3. Standard Events <#standard-events>`__
+
+`23.1.4. Long Running Job Events <#long-running-job-events>`__
+
+`23.1.5. Event Log Queries <#event-log-queries>`__
+
+`23.1.6. Deleting and Archiving Events and
+Alerts <#delete-event-alerts>`__
+
+`23.2. Working with Server
+Logs <#troubleshooting-working-with-server-logs>`__
+
+`23.3. Data Loss on Exported Primary
+Storage <#troubleshooting-dataloss-on-exported-primary-storage>`__
+
+`23.4. Recovering a Lost Virtual
+Router <#troubleshooting-recover-lost-virtual-router>`__
+
+`23.5. Maintenance mode not working on
+vCenter <#troubleshooting-maintenance-mode-not-working-on-vCenter>`__
+
+`23.6. Unable to deploy VMs from uploaded vSphere
+template <#troubleshooting-unable-to-deploy-vms>`__
+
+`23.7. Unable to power on virtual machine on
+VMware <#troubleshooting-unable-to-power-on-vm>`__
+
+`23.8. Load balancer rules fail after changing network
+offering <#troubleshooting-lb-rules-fails>`__
+
+`A. Time Zones <#time-zones>`__
+
+`B. Event Types <#event-types>`__
+
+`C. Alerts <#alerts>`__
+
+`D. Revision History <#appe-cloudstack-Revision_History>`__
+
+`1.1. What Is CloudStack? <#whatis>`__
+
+`1.2. What Can CloudStack Do? <#feature-overview>`__
+
+`1.3. Deployment Architecture
+Overview <#deployment-architecture-overview>`__
+
+`1.3.1. Management Server Overview <#management-server-overview>`__
+
+`1.3.2. Cloud Infrastructure
+Overview <#cloud-infrastructure-overview>`__
+
+`1.3.3. Networking Overview <#networking-overview>`__
+
+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. Accounts, Users, and Domains <#accounts-users-domains>`__
+
+`3.1.1. Dedicating Resources to Accounts and
+Domains <#dedicated-host-cluster-pod>`__
+
+`3.2. Using an LDAP Server for User
+Authentication <#LDAPserver-for-user-authentication>`__
+
+`3.2.1. Example LDAP Configuration
+Commands <#example-LDAP-configuration-commands>`__
+
+`3.2.2. Search Base <#search-base>`__
+
+`3.2.3. Query Filter <#query-filter>`__
+
+`3.2.4. Search User Bind DN <#search-user-bind-dn>`__
+
+`3.2.5. SSL Keystore Path and
+Password <#SSL-keystore-path-and-password>`__
+
+3.1. Accounts, Users, and Domains
+---------------------------------
+
+Accounts
+''''''''
+
+An account typically represents a customer of the service provider or a
+department in a large organization. Multiple users can exist in an
+account.
+
+Domains
+'''''''
+
+Accounts are grouped by domains. Domains usually contain multiple
+accounts that have some logical relationship to each other and a set of
+delegated administrators with some authority over the domain and its
+subdomains. For example, a service provider with several resellers could
+create a domain for each reseller.
+
+For each account created, the Cloud installation creates three different
+types of user accounts: root administrator, domain administrator, and
+user.
+
+Users
+'''''
+
+Users are like aliases in the account. Users in the same account are not
+isolated from each other, but they are isolated from users in other
+accounts. Most installations need not surface the notion of users; they
+just have one user per account. The same user cannot belong to multiple
+accounts.
+
+Username is unique in a domain across accounts in that domain. The same
+username can exist in other domains, including sub-domains. Domain name
+can repeat only if the full pathname from root is unique. For example,
+you can create root/d1, as well as root/foo/d1, and root/sales/d1.
+
+Administrators are accounts with special privileges in the system. There
+may be multiple administrators in the system. Administrators can create
+or delete other administrators, and change the password for any user in
+the system.
+
+Domain Administrators
+'''''''''''''''''''''
+
+Domain administrators can perform administrative operations for users
+who belong to that domain. Domain administrators do not have visibility
+into physical servers or other domains.
+
+Root Administrator
+''''''''''''''''''
+
+Root administrators have complete access to the system, including
+managing templates, service offerings, customer care administrators, and
+domains
+
+Resource Ownership
+''''''''''''''''''
+
+Resources belong to the account, not individual users in that account.
+For example, billing, resource limits, and so on are maintained by the
+account, not the users. A user can operate on any resource in the
+account provided the user has privileges for that operation. The
+privileges are determined by the role. A root administrator can change
+the ownership of any virtual machine from one account to any other
+account by using the assignVirtualMachine API. A domain or sub-domain
+administrator can do the same for VMs within the domain from one account
+to any other account in the domain or any of its sub-domains.
+
+3.1.1. Dedicating Resources to Accounts and Domains
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The root administrator can dedicate resources to a specific domain or
+account that needs private infrastructure for additional security or
+performance guarantees. A zone, pod, cluster, or host can be reserved by
+the root administrator for a specific domain or account. Only users in
+that domain or its subdomain may use the infrastructure. For example,
+only users in a given domain can create guests in a zone dedicated to
+that domain.
+
+There are several types of dedication available:
+
+-  
+
+   Explicit dedication. A zone, pod, cluster, or host is dedicated to an
+   account or domain by the root administrator during initial deployment
+   and configuration.
+
+-  
+
+   Strict implicit dedication. A host will not be shared across multiple
+   accounts. For example, strict implicit dedication is useful for
+   deployment of certain types of applications, such as desktops, where
+   no host can be shared between different accounts without violating
+   the desktop software's terms of license.
+
+-  
+
+   Preferred implicit dedication. The VM will be deployed in dedicated
+   infrastructure if possible. Otherwise, the VM can be deployed in
+   shared infrastructure.
+
+3.1.1.1. How to Dedicate a Zone, Cluster, Pod, or Host to an Account or Domain
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For explicit dedication: When deploying a new zone, pod, cluster, or
+host, the root administrator can click the Dedicated checkbox, then
+choose a domain or account to own the resource.
+
+To explicitly dedicate an existing zone, pod, cluster, or host: log in
+as the root admin, find the resource in the UI, and click the Dedicate
+button. |dedicate-resource-button.png: button to dedicate a zone, pod,
+cluster, or host|
+
+For implicit dedication: The administrator creates a compute service
+offering and in the Deployment Planner field, chooses
+ImplicitDedicationPlanner. Then in Planner Mode, the administrator
+specifies either Strict or Preferred, depending on whether it is
+permissible to allow some use of shared resources when dedicated
+resources are not available. Whenever a user creates a VM based on this
+service offering, it is allocated on one of the dedicated hosts.
+
+3.1.1.2. How to Use Dedicated Hosts
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To use an explicitly dedicated host, use the explicit-dedicated type of
+affinity group (see `Section 10.7.1, “Affinity
+Groups” <#affinity-groups>`__). For example, when creating a new VM, an
+end user can choose to place it on dedicated infrastructure. This
+operation will succeed only if some infrastructure has already been
+assigned as dedicated to the user's account or domain.
+
+3.1.1.3. Behavior of Dedicated Hosts, Clusters, Pods, and Zones
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The administrator can live migrate VMs away from dedicated hosts if
+desired, whether the destination is a host reserved for a different
+account/domain or a host that is shared (not dedicated to any particular
+account or domain). CloudStack will generate an alert, but the operation
+is allowed.
+
+Dedicated hosts can be used in conjunction with host tags. If both a
+host tag and dedication are requested, the VM will be placed only on a
+host that meets both requirements. If there is no dedicated resource
+available to that user that also has the host tag requested by the user,
+then the VM will not deploy.
+
+If you delete an account or domain, any hosts, clusters, pods, and zones
+that were dedicated to it are freed up. They will now be available to be
+shared by any account or domain, or the administrator may choose to
+re-dedicate them to a different account or domain.
+
+System VMs and virtual routers affect the behavior of host dedication.
+System VMs and virtual routers are owned by the CloudStack system
+account, and they can be deployed on any host. They do not adhere to
+explicit dedication. The presence of system vms and virtual routers on a
+host makes it unsuitable for strict implicit dedication. The host can
+not be used for strict implicit dedication, because the host already has
+VMs of a specific account (the default system account). However, a host
+with system VMs or virtual routers can be used for preferred implicit
+dedication.
+
+3.2. Using an LDAP Server for User Authentication
+-------------------------------------------------
+
+You can use an external LDAP server such as Microsoft Active Directory
+or ApacheDS to authenticate CloudStack end-users. Just map CloudStack
+accounts to the corresponding LDAP accounts using a query filter. The
+query filter is written using the query syntax of the particular LDAP
+server, and can include special wildcard characters provided by
+CloudStack for matching common values such as the user’s email address
+and name. CloudStack will search the external LDAP directory tree
+starting at a specified base directory and return the distinguished name
+(DN) and password of the matching user. This information along with the
+given password is used to authenticate the user..
+
+To set up LDAP authentication in CloudStack, call the CloudStack API
+command ldapConfig and provide the following:
+
+-  
+
+   Hostname or IP address and listening port of the LDAP server
+
+-  
+
+   Base directory and query filter
+
+-  
+
+   Search user DN credentials, which give CloudStack permission to
+   search on the LDAP server
+
+-  
+
+   SSL keystore and password, if SSL is used
+
+3.2.1. Example LDAP Configuration Commands
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To understand the examples in this section, you need to know the basic
+concepts behind calling the CloudStack API, which are explained in the
+Developer’s Guide.
+
+The following shows an example invocation of ldapConfig with an ApacheDS
+LDAP server
+
+.. code:: programlisting
+
+    http://127.0.0.1:8080/client/api?command=ldapConfig&hostname=127.0.0.1&searchbase=ou%3Dtesting%2Co%3Dproject&queryfilter=%28%26%28uid%3D%25u%29%29&binddn=cn%3DJohn+Singh%2Cou%3Dtesting%2Co%project&bindpass=secret&port=10389&ssl=true&truststore=C%3A%2Fcompany%2Finfo%2Ftrusted.ks&truststorepass=secret&response=json&apiKey=YourAPIKey&signature=YourSignatureHash
+
+The command must be URL-encoded. Here is the same example without the
+URL encoding:
+
+.. code:: programlisting
+
+    http://127.0.0.1:8080/client/api?command=ldapConfig
+    &hostname=127.0.0.1
+    &searchbase=ou=testing,o=project
+    &queryfilter=(&(%uid=%u))
+    &binddn=cn=John+Singh,ou=testing,o=project
+    &bindpass=secret
+    &port=10389
+    &ssl=true
+    &truststore=C:/company/info/trusted.ks
+    &truststorepass=secret
+    &response=json
+    &apiKey=YourAPIKey&signature=YourSignatureHash
+
+The following shows a similar command for Active Directory. Here, the
+search base is the testing group within a company, and the users are
+matched up based on email address.
+
+.. code:: programlisting
+
+    http://10.147.29.101:8080/client/api?command=ldapConfig&hostname=10.147.28.250&searchbase=OU%3Dtesting%2CDC%3Dcompany&queryfilter=%28%26%28mail%3D%25e%29%29 &binddn=CN%3DAdministrator%2COU%3Dtesting%2CDC%3Dcompany&bindpass=1111_aaaa&port=389&response=json&apiKey=YourAPIKey&signature=YourSignatureHash
+
+The next few sections explain some of the concepts you will need to know
+when filling out the ldapConfig parameters.
+
+3.2.2. Search Base
+~~~~~~~~~~~~~~~~~~
+
+An LDAP query is relative to a given node of the LDAP directory tree,
+called the search base. The search base is the distinguished name (DN)
+of a level of the directory tree below which all users can be found. The
+users can be in the immediate base directory or in some subdirectory.
+The search base may be equivalent to the organization, group, or domain
+name. The syntax for writing a DN varies depending on which LDAP server
+you are using. A full discussion of distinguished names is outside the
+scope of our documentation. The following table shows some examples of
+search bases to find users in the testing department..
+
+LDAP Server
+
+Example Search Base DN
+
+ApacheDS
+
+ou=testing,o=project
+
+Active Directory
+
+OU=testing, DC=company
+
+3.2.3. Query Filter
+~~~~~~~~~~~~~~~~~~~
+
+The query filter is used to find a mapped user in the external LDAP
+server. The query filter should uniquely map the CloudStack user to LDAP
+user for a meaningful authentication. For more information about query
+filter syntax, consult the documentation for your LDAP server.
+
+The CloudStack query filter wildcards are:
+
+Query Filter Wildcard
+
+Description
+
+%u
+
+User name
+
+%e
+
+Email address
+
+%n
+
+First and last name
+
+The following examples assume you are using Active Directory, and refer
+to user attributes from the Active Directory schema.
+
+If the CloudStack user name is the same as the LDAP user ID:
+
+.. code:: programlisting
+
+    (uid=%u)
+
+If the CloudStack user name is the LDAP display name:
+
+.. code:: programlisting
+
+    (displayName=%u)
+
+To find a user by email address:
+
+.. code:: programlisting
+
+    (mail=%e)
+
+3.2.4. Search User Bind DN
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bind DN is the user on the external LDAP server permitted to search
+the LDAP directory within the defined search base. When the DN is
+returned, the DN and passed password are used to authenticate the
+CloudStack user with an LDAP bind. A full discussion of bind DNs is
+outside the scope of our documentation. The following table shows some
+examples of bind DNs.
+
+LDAP Server
+
+Example Bind DN
+
+ApacheDS
+
+cn=Administrator,dc=testing,ou=project,ou=org
+
+Active Directory
+
+CN=Administrator, OU=testing, DC=company, DC=com
+
+3.2.5. SSL Keystore Path and Password
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If the LDAP server requires SSL, you need to enable it in the ldapConfig
+command by setting the parameters ssl, truststore, and truststorepass.
+Before enabling SSL for ldapConfig, you need to get the certificate
+which the LDAP server is using and add it to a trusted keystore. You
+will need to know the path to the keystore and the password.
+
+`4.1. Service Offerings, Disk Offerings, Network Offerings, and
+Templates <#offerings-and-templates>`__
+
+In addition to the physical and logical infrastructure of your cloud and
+the CloudStack software and servers, you also need a layer of user
+services so that people can actually make use of the cloud. This means
+not just a user UI, but a set of options and resources that users can
+choose from, such as templates for creating virtual machines, disk
+storage, and more. If you are running a commercial service, you will be
+keeping track of what services and resources users are consuming and
+charging them for that usage. Even if you do not charge anything for
+people to use your cloud – say, if the users are strictly internal to
+your organization, or just friends who are sharing your cloud – you can
+still keep track of what services they use and how much of them.
+
+4.1. Service Offerings, Disk Offerings, Network Offerings, and Templates
+------------------------------------------------------------------------
+
+A user creating a new instance can make a variety of choices about its
+characteristics and capabilities. CloudStack provides several ways to
+present users with choices when creating a new instance:
+
+-  
+
+   Service Offerings, defined by the CloudStack administrator, provide a
+   choice of CPU speed, number of CPUs, RAM size, tags on the root disk,
+   and other choices. See Creating a New Compute Offering.
+
+-  
+
+   Disk Offerings, defined by the CloudStack administrator, provide a
+   choice of disk size and IOPS (Quality of Service) for primary data
+   storage. See Creating a New Disk Offering.
+
+-  
+
+   Network Offerings, defined by the CloudStack administrator, describe
+   the feature set that is available to end users from the virtual
+   router or external networking devices on a given guest network. See
+   Network Offerings.
+
+-  
+
+   Templates, defined by the CloudStack administrator or by any
+   CloudStack user, are the base OS images that the user can choose from
+   when creating a new instance. For example, CloudStack includes CentOS
+   as a template. See Working with Templates.
+
+In addition to these choices that are provided for users, there is
+another type of service offering which is available only to the
+CloudStack root administrator, and is used for configuring virtual
+infrastructure resources. For more information, see Upgrading a Virtual
+Router with System Service Offerings.
+
+`5.1. Log In to the UI <#log-in>`__
+
+`5.1.1. End User's UI Overview <#end-user-ui-overview>`__
+
+`5.1.2. Root Administrator's UI Overview <#root-admin-ui-overview>`__
+
+`5.1.3. Logging In as the Root Administrator <#log-in-root-admin>`__
+
+`5.1.4. Changing the Root Password <#changing-root-password>`__
+
+`5.2. Using SSH Keys for Authentication <#using-sshkeys>`__
+
+`5.2.1. Creating an Instance Template that Supports SSH
+Keys <#create-ssh-template>`__
+
+`5.2.2. Creating the SSH Keypair <#create-ssh-keypair>`__
+
+`5.2.3. Creating an Instance <#creating-ssh-instance>`__
+
+`5.2.4. Logging In Using the SSH Keypair <#logging-in-ssh>`__
+
+`5.2.5. Resetting SSH Keys <#reset-ssh>`__
+
+5.1. Log In to the UI
+---------------------
+
+CloudStack provides a web-based UI that can be used by both
+administrators and end users. The appropriate version of the UI is
+displayed depending on the credentials used to log in. The UI is
+available in popular browsers including IE7, IE8, IE9, Firefox 3.5+,
+Firefox 4, Safari 4, and Safari 5. The URL is: (substitute your own
+management server IP address)
+
+.. code:: programlisting
+
+    http://<management-server-ip-address>:8080/client
+
+On a fresh Management Server installation, a guided tour splash screen
+appears. On later visits, you’ll see a login screen where you specify
+the following to proceed to your Dashboard:
+
+Username
+''''''''
+
+The user ID of your account. The default username is admin.
+
+Password
+''''''''
+
+The password associated with the user ID. The password for the default
+username is password.
+
+Domain
+''''''
+
+If you are a root user, leave this field blank.
+
+If you are a user in the sub-domains, enter the full path to the domain,
+excluding the root domain.
+
+For example, suppose multiple levels are created under the root domain,
+such as Comp1/hr. The users in the Comp1 domain should enter Comp1 in
+the Domain field, whereas the users in the Comp1/sales domain should
+enter Comp1/sales.
+
+For more guidance about the choices that appear when you log in to this
+UI, see Logging In as the Root Administrator.
+
+5.1.1. End User's UI Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The CloudStack UI helps users of cloud infrastructure to view and use
+their cloud resources, including virtual machines, templates and ISOs,
+data volumes and snapshots, guest networks, and IP addresses. If the
+user is a member or administrator of one or more CloudStack projects,
+the UI can provide a project-oriented view.
+
+5.1.2. Root Administrator's UI Overview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The CloudStack UI helps the CloudStack administrator provision, view,
+and manage the cloud infrastructure, domains, user accounts, projects,
+and configuration settings. The first time you start the UI after a
+fresh Management Server installation, you can choose to follow a guided
+tour to provision your cloud infrastructure. On subsequent logins, the
+dashboard of the logged-in user appears. The various links in this
+screen and the navigation bar on the left provide access to a variety of
+administrative functions. The root administrator can also use the UI to
+perform all the same tasks that are present in the end-user’s UI.
+
+5.1.3. Logging In as the Root Administrator
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After the Management Server software is installed and running, you can
+run the CloudStack user interface. This UI is there to help you
+provision, view, and manage your cloud infrastructure.
+
+#. 
+
+   Open your favorite Web browser and go to this URL. Substitute the IP
+   address of your own Management Server:
+
+   .. code:: programlisting
+
+       http://<management-server-ip-address>:8080/client
+
+   After logging into a fresh Management Server installation, a guided
+   tour splash screen appears. On later visits, you’ll be taken directly
+   into the Dashboard.
+
+#. 
+
+   If you see the first-time splash screen, choose one of the following.
+
+   -  
+
+      **Continue with basic setup.** Choose this if you're just trying
+      CloudStack, and you want a guided walkthrough of the simplest
+      possible configuration so that you can get started right away.
+      We'll help you set up a cloud with the following features: a
+      single machine that runs CloudStack software and uses NFS to
+      provide storage; a single machine running VMs under the XenServer
+      or KVM hypervisor; and a shared public network.
+
+      The prompts in this guided tour should give you all the
+      information you need, but if you want just a bit more detail, you
+      can follow along in the Trial Installation Guide.
+
+   -  
+
+      **I have used CloudStack before.** Choose this if you have already
+      gone through a design phase and planned a more sophisticated
+      deployment, or you are ready to start scaling up a trial cloud
+      that you set up earlier with the basic setup screens. In the
+      Administrator UI, 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.
+
+      The root administrator Dashboard appears.
+
+#. 
+
+   You should set a new root administrator password. If you chose basic
+   setup, you’ll be prompted to create a new password right away. If you
+   chose experienced user, use the steps in `Section 5.1.4, “Changing
+   the Root Password” <#changing-root-password>`__.
+
+Warning
+-------
+
+You are logging in as the root administrator. This account manages the
+CloudStack deployment, including physical infrastructure. The root
+administrator can modify configuration settings to change basic
+functionality, create or delete user accounts, and take many actions
+that should be performed only by an authorized person. Please change the
+default password to a new, unique password.
+
+5.1.4. Changing the Root Password
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+During installation and ongoing cloud administration, you will need to
+log in to the UI as the root administrator. The root administrator
+account manages the CloudStack deployment, including physical
+infrastructure. The root administrator can modify configuration settings
+to change basic functionality, create or delete user accounts, and take
+many actions that should be performed only by an authorized person. When
+first installing CloudStack, be sure to change the default password to a
+new, unique value.
+
+#. 
+
+   Open your favorite Web browser and go to this URL. Substitute the IP
+   address of your own Management Server:
+
+   .. code:: programlisting
+
+       http://<management-server-ip-address>:8080/client
+
+#. 
+
+   Log in to the UI using the current root user ID and password. The
+   default is admin, password.
+
+#. 
+
+   Click Accounts.
+
+#. 
+
+   Click the admin account name.
+
+#. 
+
+   Click View Users.
+
+#. 
+
+   Click the admin user name.
+
+#. 
+
+   Click the Change Password button. |change-password.png: button to
+   change a user's password|
+
+#. 
+
+   Type the new password, and click OK.
+
+5.2. Using SSH Keys for Authentication
+--------------------------------------
+
+In addition to the username and password authentication, CloudStack
+supports using SSH keys to log in to the cloud infrastructure for
+additional security. You can use the createSSHKeyPair API to generate
+the SSH keys.
+
+Because each cloud user has their own SSH key, one cloud user cannot log
+in to another cloud user's instances unless they share their SSH key
+files. Using a single SSH key pair, you can manage multiple instances.
+
+5.2.1.  Creating an Instance Template that Supports SSH Keys
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Create a instance template that supports SSH Keys.
+
+#. 
+
+   Create a new instance by using the template provided by cloudstack.
+
+   For more information on creating a new instance, see
+
+#. 
+
+   Download the cloudstack script from `The SSH Key Gen
+   Script <http://sourceforge.net/projects/cloudstack/files/SSH%20Key%20Gen%20Script/>`__\ to
+   the instance you have created.
+
+   .. code:: programlisting
+
+       wget http://downloads.sourceforge.net/project/cloudstack/SSH%20Key%20Gen%20Script/cloud-set-guest-sshkey.in?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcloudstack%2Ffiles%2FSSH%2520Key%2520Gen%2520Script%2F&ts=1331225219&use_mirror=iweb
+
+#. 
+
+   Copy the file to /etc/init.d.
+
+   .. code:: programlisting
+
+       cp cloud-set-guest-sshkey.in /etc/init.d/
+
+#. 
+
+   Give the necessary permissions on the script:
+
+   .. code:: programlisting
+
+       chmod +x /etc/init.d/cloud-set-guest-sshkey.in
+
+#. 
+
+   Run the script while starting up the operating system:
+
+   .. code:: programlisting
+
+       chkconfig --add cloud-set-guest-sshkey.in
+
+#. 
+
+   Stop the instance.
+
+5.2.2. Creating the SSH Keypair
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You must make a call to the createSSHKeyPair api method. You can either
+use the CloudStack Python API library or the curl commands to make the
+call to the cloudstack api.
+
+For example, make a call from the cloudstack server to create a SSH
+keypair called "keypair-doc" for the admin account in the root domain:
+
+Note
+----
+
+Ensure that you adjust these values to meet your needs. If you are
+making the API call from a different server, your URL/PORT will be
+different, and you will need to use the API keys.
+
+#. 
+
+   Run the following curl command:
+
+   .. code:: programlisting
+
+       curl --globoff "http://localhost:8096/?command=createSSHKeyPair&name=keypair-doc&account=admin&domainid=5163440e-c44b-42b5-9109-ad75cae8e8a2"
+
+   The output is something similar to what is given below:
+
+   .. code:: programlisting
+
+       <?xml version="1.0" encoding="ISO-8859-1"?><createsshkeypairresponse cloud-stack-version="3.0.0.20120228045507"><keypair><name>keypair-doc</name><fingerprint>f6:77:39:d5:5e:77:02:22:6a:d8:7f:ce:ab:cd:b3:56</fingerprint><privatekey>-----BEGIN RSA PRIVATE KEY-----
+       MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
+       dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
+       AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
+       mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
+       QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
+       VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
+       lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
+       nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
+       4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
+       KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
+       -----END RSA PRIVATE KEY-----
+       </privatekey></keypair></createsshkeypairresponse>
+
+#. 
+
+   Copy the key data into a file. The file looks like this:
+
+   .. code:: programlisting
+
+       -----BEGIN RSA PRIVATE KEY-----
+       MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
+       dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
+       AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
+       mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
+       QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
+       VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
+       lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
+       nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
+       4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
+       KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
+       -----END RSA PRIVATE KEY-----
+
+#. 
+
+   Save the file.
+
+5.2.3. Creating an Instance
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After you save the SSH keypair file, you must create an instance by
+using the template that you created at `Section 5.2.1, “ Creating an
+Instance Template that Supports SSH Keys” <#create-ssh-template>`__.
+Ensure that you use the same SSH key name that you created at
+`Section 5.2.2, “Creating the SSH Keypair” <#create-ssh-keypair>`__.
+
+Note
+----
+
+You cannot create the instance by using the GUI at this time and
+associate the instance with the newly created SSH keypair.
+
+A sample curl command to create a new instance is:
+
+.. code:: programlisting
+
+    curl --globoff http://localhost:<port number>/?command=deployVirtualMachine\&zoneId=1\&serviceOfferingId=18727021-7556-4110-9322-d625b52e0813\&templateId=e899c18a-ce13-4bbf-98a9-625c5026e0b5\&securitygroupids=ff03f02f-9e3b-48f8-834d-91b822da40c5\&account=admin\&domainid=1\&keypair=keypair-doc
+
+Substitute the template, service offering and security group IDs (if you
+are using the security group feature) that are in your cloud
+environment.
+
+5.2.4. Logging In Using the SSH Keypair
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To test your SSH key generation is successful, check whether you can log
+in to the cloud setup.
+
+For exaple, from a Linux OS, run:
+
+.. code:: programlisting
+
+    ssh -i ~/.ssh/keypair-doc <ip address>
+
+The -i parameter tells the ssh client to use a ssh key found at
+~/.ssh/keypair-doc.
+
+5.2.5. Resetting SSH Keys
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+With the API command resetSSHKeyForVirtualMachine, a user can set or
+reset the SSH keypair assigned to a virtual machine. A lost or
+compromised SSH keypair can be changed, and the user can access the VM
+by using the new keypair. Just create or register a new keypair, then
+call resetSSHKeyForVirtualMachine.
+
+`6.1. Overview of Projects <#projects-overview>`__
+
+`6.2. Configuring Projects <#configuring-projects>`__
+
+`6.2.1. Setting Up Invitations <#set-up-invitations>`__
+
+`6.2.2. Setting Resource Limits for
+Projects <#set-resource-limits-for-pr

<TRUNCATED>

Mime
View raw message