cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ke4...@apache.org
Subject [08/11] networking2.rst
Date Tue, 28 Jan 2014 02:23:29 GMT
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/4bbce96f/source/api.rst
----------------------------------------------------------------------
diff --git a/source/api.rst b/source/api.rst
new file mode 100644
index 0000000..abca92c
--- /dev/null
+++ b/source/api.rst
@@ -0,0 +1,95 @@
+CloudStack API
+==============
+
+The CloudStack API is a low level API that has been used to implement
+the CloudStack web UIs. It is also a good basis for implementing other
+popular APIs such as EC2/S3 and emerging DMTF standards.
+
+Many CloudStack API calls are asynchronous. These will return a Job ID
+immediately when called. This Job ID can be used to query the status of
+the job later. Also, status calls on impacted resources will provide
+some indication of their state.
+
+The API has a REST-like query basis and returns results in XML or JSON.
+
+See `the Developer’s
+Guide <http://docs.cloudstack.org/CloudStack_Documentation/Developer's_Guide%3A_CloudStack>`__
+and `the API
+Reference <http://docs.cloudstack.org/CloudStack_Documentation/API_Reference%3A_CloudStack>`__.
+
+Provisioning and Authentication API
+-----------------------------------------
+
+CloudStack expects that a customer will have their own user provisioning
+infrastructure. It provides APIs to integrate with these existing
+systems where the systems call out to CloudStack to add/remove users..
+
+CloudStack supports pluggable authenticators. By default, CloudStack
+assumes it is provisioned with the user’s password, and as a result
+authentication is done locally. However, external authentication is
+possible as well. For example, see Using an LDAP Server for User
+Authentication.
+
+User Data and Meta Data
+-----------------------------
+
+CloudStack provides API access to attach up to 32KB of user data to a
+deployed VM. Deployed VMs also have access to instance metadata via the
+virtual router.
+
+User data can be accessed once the IP address of the virtual router is
+known. Once the IP address is known, use the following steps to access
+the user data:
+
+#. 
+
+   Run the following command to find the virtual router.
+
+   .. code:: bash
+
+       # cat /var/lib/dhclient/dhclient-eth0.leases | grep dhcp-server-identifier | tail -1
+
+#. 
+
+   Access user data by running the following command using the result of
+   the above command
+
+   .. code:: bash
+
+       # curl http://10.1.1.1/latest/user-data
+
+Meta Data can be accessed similarly, using a URL of the form
+http://10.1.1.1/latest/meta-data/{metadata type}. (For backwards
+compatibility, the previous URL http://10.1.1.1/latest/{metadata type}
+is also supported.) For metadata type, use one of the following:
+
+-  
+
+   service-offering. A description of the VMs service offering
+
+-  
+
+   availability-zone. The Zone name
+
+-  
+
+   local-ipv4. The guest IP of the VM
+
+-  
+
+   local-hostname. The hostname of the VM
+
+-  
+
+   public-ipv4. The first public IP for the router. (E.g. the first IP
+   of eth2)
+
+-  
+
+   public-hostname. This is the same as public-ipv4
+
+-  
+
+   instance-id. The instance name of the VM
+
+

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/4bbce96f/source/events.rst
----------------------------------------------------------------------
diff --git a/source/events.rst b/source/events.rst
new file mode 100644
index 0000000..3eeef43
--- /dev/null
+++ b/source/events.rst
@@ -0,0 +1,1505 @@
+Events
+======
+
+Events
+------------
+
+An event is essentially a significant or meaningful change in the state
+of both virtual and physical resources associated with a cloud
+environment. Events are used by monitoring systems, usage and billing
+systems, or any other event-driven workflow systems to discern a pattern
+and make the right business decision. In CloudStack an event could be a
+state change of virtual or physical resources, an action performed by an
+user (action events), or policy based events (alerts).
+
+Event Logs
+~~~~~~~~~~~~~~~~~~
+
+There are two types of events logged in the CloudStack Event Log.
+Standard events log the success or failure of an event and can be used
+to identify jobs or processes that have failed. There are also long
+running job events. Events for asynchronous jobs log when a job is
+scheduled, when it starts, and when it completes. Other long running
+synchronous jobs log when a job starts, and when it completes. Long
+running synchronous and asynchronous event logs can be used to gain more
+information on the status of a pending job or can be used to identify a
+job that is hanging or has not started. The following sections provide
+more information on these events..
+
+Event Notification
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Event notification framework provides a means for the Management Server
+components to publish and subscribe to CloudStack events. Event
+notification is achieved by implementing the concept of event bus
+abstraction in the Management Server. An event bus is introduced in the
+Management Server that allows the CloudStack components and extension
+plug-ins to subscribe to the events by using the Advanced Message
+Queuing Protocol (AMQP) client. In CloudStack, a default implementation
+of event bus is provided as a plug-in that uses the RabbitMQ AMQP
+client. The AMQP client pushes the published events to a compatible AMQP
+server. Therefore all the CloudStack events are published to an exchange
+in the AMQP server.
+
+A new event for state change, resource state change, is introduced as
+part of Event notification framework. Every resource, such as user VM,
+volume, NIC, network, public IP, snapshot, and template, is associated
+with a state machine and generates events as part of the state change.
+That implies that a change in the state of a resource results in a state
+change event, and the event is published in the corresponding state
+machine on the event bus. All the CloudStack events (alerts, action
+events, usage events) and the additional category of resource state
+change events, are published on to the events bus.
+
+Use Cases
+'''''''''
+
+The following are some of the use cases:
+
+-  
+
+   Usage or Billing Engines: A third-party cloud usage solution can
+   implement a plug-in that can connects to CloudStack to subscribe to
+   CloudStack events and generate usage data. The usage data is consumed
+   by their usage software.
+
+-  
+
+   AMQP plug-in can place all the events on the a message queue, then a
+   AMQP message broker can provide topic-based notification to the
+   subscribers.
+
+-  
+
+   Publish and Subscribe notification service can be implemented as a
+   pluggable service in CloudStack that can provide rich set of APIs for
+   event notification, such as topics-based subscription and
+   notification. Additionally, the pluggable service can deal with
+   multi-tenancy, authentication, and authorization issues.
+
+Configuration
+'''''''''''''
+
+As a CloudStack administrator, perform the following one-time
+configuration to enable event notification framework. At run time no
+changes can control the behaviour.
+
+#. 
+
+   Open ``'componentContext.xml``.
+
+#. 
+
+   Define a bean named ``eventNotificationBus`` as follows:
+
+   -  
+
+      name : Specify a name for the bean.
+
+   -  
+
+      server : The name or the IP address of the RabbitMQ AMQP server.
+
+   -  
+
+      port : The port on which RabbitMQ server is running.
+
+   -  
+
+      username : The username associated with the account to access the
+      RabbitMQ server.
+
+   -  
+
+      password : The password associated with the username of the
+      account to access the RabbitMQ server.
+
+   -  
+
+      exchange : The exchange name on the RabbitMQ server where
+      CloudStack events are published.
+
+      A sample bean is given below:
+
+      .. code:: bash
+
+          <bean id="eventNotificationBus" class="org.apache.cloudstack.mom.rabbitmq.RabbitMQEventBus">
+              <property name="name" value="eventNotificationBus"/>
+              <property name="server" value="127.0.0.1"/>
+              <property name="port" value="5672"/>
+              <property name="username" value="guest"/>
+              <property name="password" value="guest"/>
+             <property name="exchange" value="cloudstack-events"/>
+             </bean>
+
+      The ``eventNotificationBus`` bean represents the
+      ``org.apache.cloudstack.mom.rabbitmq.RabbitMQEventBus`` class.
+
+#. 
+
+   Restart the Management Server.
+
+Standard Events
+~~~~~~~~~~~~~~~~~~~~~~~
+
+The events log records three types of standard events.
+
+-  
+
+   INFO. This event is generated when an operation has been successfully
+   performed.
+
+-  
+
+   WARN. This event is generated in the following circumstances.
+
+   -  
+
+      When a network is disconnected while monitoring a template
+      download.
+
+   -  
+
+      When a template download is abandoned.
+
+   -  
+
+      When an issue on the storage server causes the volumes to fail
+      over to the mirror storage server.
+
+-  
+
+   ERROR. This event is generated when an operation has not been
+   successfully performed
+
+Long Running Job Events
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The events log records three types of standard events.
+
+-  
+
+   INFO. This event is generated when an operation has been successfully
+   performed.
+
+-  
+
+   WARN. This event is generated in the following circumstances.
+
+   -  
+
+      When a network is disconnected while monitoring a template
+      download.
+
+   -  
+
+      When a template download is abandoned.
+
+   -  
+
+      When an issue on the storage server causes the volumes to fail
+      over to the mirror storage server.
+
+-  
+
+   ERROR. This event is generated when an operation has not been
+   successfully performed
+
+Event Log Queries
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Database logs can be queried from the user interface. The list of events
+captured by the system includes:
+
+-  
+
+   Virtual machine creation, deletion, and on-going management
+   operations
+
+-  
+
+   Virtual router creation, deletion, and on-going management operations
+
+-  
+
+   Template creation and deletion
+
+-  
+
+   Network/load balancer rules creation and deletion
+
+-  
+
+   Storage volume creation and deletion
+
+-  
+
+   User login and logout
+
+Deleting and Archiving Events and Alerts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CloudStack provides you the ability to delete or archive the existing
+alerts and events that you no longer want to implement. You can
+regularly delete or archive any alerts or events that you cannot, or do
+not want to resolve from the database.
+
+You can delete or archive individual alerts or events either directly by
+using the Quickview or by using the Details page. If you want to delete
+multiple alerts or events at the same time, you can use the respective
+context menu. You can delete alerts or events by category for a time
+period. For example, you can select categories such as **USER.LOGOUT**,
+**VM.DESTROY**, **VM.AG.UPDATE**, **CONFIGURATION.VALUE.EDI**, and so
+on. You can also view the number of events or alerts archived or
+deleted.
+
+In order to support the delete or archive alerts, the following global
+parameters have been added:
+
+-  
+
+   **alert.purge.delay**: The alerts older than specified number of days
+   are purged. Set the value to 0 to never purge alerts automatically.
+
+-  
+
+   **alert.purge.interval**: The interval in seconds to wait before
+   running the alert purge thread. The default is 86400 seconds (one
+   day).
+
+.. note:: Archived alerts or events cannot be viewed in the UI or by using the
+API. They are maintained in the database for auditing or compliance
+purposes.
+
+Permissions
+^^^^^^^^^^^^^^^^^^^^^
+
+Consider the following:
+
+-  
+
+   The root admin can delete or archive one or multiple alerts or
+   events.
+
+-  
+
+   The domain admin or end user can delete or archive one or multiple
+   events.
+
+Procedure
+^^^^^^^^^^^^^^^^^^^
+
+#. 
+
+   Log in as administrator to the CloudStack UI.
+
+#. 
+
+   In the left navigation, click Events.
+
+#. 
+
+   Perform either of the following:
+
+   -  
+
+      To archive events, click Archive Events, and specify event type
+      and date.
+
+   -  
+
+      To archive events, click Delete Events, and specify event type and
+      date.
+
+#. 
+
+   Click OK.
+
+Working with Server Logs
+------------------------------
+
+The CloudStack Management Server logs all web site, middle tier, and
+database activities for diagnostics purposes in
+/var/log/cloudstack/management/. The CloudStack logs a variety of error
+messages. We recommend this command to find the problematic output in
+the Management Server log:.
+
+.. 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.
+
+.. code:: bash
+
+            grep -i -E 'exception|unable|fail|invalid|leak|warn|error' /var/log/cloudstack/management/management-server.log
+
+The CloudStack processes requests with a Job ID. If you find an error in
+the logs and you are interested in debugging the issue you can grep for
+this job ID in the management server log. For example, suppose that you
+find the following ERROR message:
+
+.. code:: bash
+
+            2010-10-04 13:49:32,595 ERROR [cloud.vm.UserVmManagerImpl] (Job-Executor-11:job-1076) Unable to find any host for [User|i-8-42-VM-untagged]
+
+Note that the job ID is 1076. You can track back the events relating to
+job 1076 with the following grep:
+
+.. code:: bash
+
+            grep "job-1076)" management-server.log
+
+The CloudStack Agent Server logs its activities in
+/var/log/cloudstack/agent/.
+
+Data Loss on Exported Primary Storage
+-------------------------------------------
+
+Symptom
+'''''''
+
+Loss of existing data on primary storage which has been exposed as a
+Linux NFS server export on an iSCSI volume.
+
+Cause
+'''''
+
+It is possible that a client from outside the intended pool has mounted
+the storage. When this occurs, the LVM is wiped and all data in the
+volume is lost
+
+Solution
+''''''''
+
+When setting up LUN exports, restrict the range of IP addresses that are
+allowed access by specifying a subnet mask. For example:
+
+.. code:: bash
+
+    echo “/export 192.168.1.0/24(rw,async,no_root_squash,no_subtree_check)” > /etc/exports
+
+Adjust the above command to suit your deployment needs.
+
+More Information
+''''''''''''''''
+
+See the export procedure in the "Secondary Storage" section of the
+CloudStack Installation Guide
+
+Recovering a Lost Virtual Router
+--------------------------------------
+
+Symptom
+'''''''
+
+A virtual router is running, but the host is disconnected. A virtual
+router no longer functions as expected.
+
+Cause
+'''''
+
+The Virtual router is lost or down.
+
+Solution
+''''''''
+
+If you are sure that a virtual router is down forever, or no longer
+functions as expected, destroy it. You must create one afresh while
+keeping the backup router up and running (it is assumed this is in a
+redundant router setup):
+
+-  
+
+   Force stop the router. Use the stopRouter API with forced=true
+   parameter to do so.
+
+-  
+
+   Before you continue with destroying this router, ensure that the
+   backup router is running. Otherwise the network connection will be
+   lost.
+
+-  
+
+   Destroy the router by using the destroyRouter API.
+
+Recreate the missing router by using the restartNetwork API with
+cleanup=false parameter. For more information about redundant router
+setup, see Creating a New Network Offering.
+
+For more information about the API syntax, see the API Reference at
+`http://docs.cloudstack.org/CloudStack\_Documentation/API\_Reference%3A\_CloudStack <http://docs.cloudstack.org/CloudStack_Documentation/API_Reference%3A_CloudStack>`__\ API
+Reference.
+
+Maintenance mode not working on vCenter
+---------------------------------------------
+
+Symptom
+'''''''
+
+Host was placed in maintenance mode, but still appears live in vCenter.
+
+Cause
+'''''
+
+The CloudStack administrator UI was used to place the host in scheduled
+maintenance mode. This mode is separate from vCenter's maintenance mode.
+
+Solution
+''''''''
+
+Use vCenter to place the host in maintenance mode.
+
+More Information
+''''''''''''''''
+
+See `Section 11.2, “Scheduled Maintenance and Maintenance Mode for
+Hosts” <#scheduled-maintenance-maintenance-mode-hosts>`__
+
+Unable to deploy VMs from uploaded vSphere template
+---------------------------------------------------------
+
+Symptom
+'''''''
+
+When attempting to create a VM, the VM will not deploy.
+
+Cause
+'''''
+
+If the template was created by uploading an OVA file that was created
+using vSphere Client, it is possible the OVA contained an ISO image. If
+it does, the deployment of VMs from the template will fail.
+
+Solution
+''''''''
+
+Remove the ISO and re-upload the template.
+
+Unable to power on virtual machine on VMware
+--------------------------------------------------
+
+Symptom
+'''''''
+
+Virtual machine does not power on. You might see errors like:
+
+-  
+
+   Unable to open Swap File
+
+-  
+
+   Unable to access a file since it is locked
+
+-  
+
+   Unable to access Virtual machine configuration
+
+Cause
+'''''
+
+A known issue on VMware machines. ESX hosts lock certain critical
+virtual machine files and file systems to prevent concurrent changes.
+Sometimes the files are not unlocked when the virtual machine is powered
+off. When a virtual machine attempts to power on, it can not access
+these critical files, and the virtual machine is unable to power on.
+
+Solution
+''''''''
+
+See the following:
+
+`VMware Knowledge Base
+Article <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051/>`__
+
+Load balancer rules fail after changing network offering
+--------------------------------------------------------------
+
+Symptom
+'''''''
+
+After changing the network offering on a network, load balancer rules
+stop working.
+
+Cause
+'''''
+
+Load balancing rules were created while using a network service offering
+that includes an external load balancer device such as NetScaler, and
+later the network service offering changed to one that uses the
+CloudStack virtual router.
+
+Solution
+''''''''
+
+Create a firewall rule on the virtual router for each of your existing
+load balancing rules so that they continue to function.
+
+The following time zone identifiers are accepted by CloudStack. There
+are several places that have a time zone as a required or optional
+parameter. These include scheduling recurring snapshots, creating a
+user, and specifying the usage time zone in the Configuration table.
+
+Etc/GMT+12
+
+Etc/GMT+11
+
+Pacific/Samoa
+
+Pacific/Honolulu
+
+US/Alaska
+
+America/Los\_Angeles
+
+Mexico/BajaNorte
+
+US/Arizona
+
+US/Mountain
+
+America/Chihuahua
+
+America/Chicago
+
+America/Costa\_Rica
+
+America/Mexico\_City
+
+Canada/Saskatchewan
+
+America/Bogota
+
+America/New\_York
+
+America/Caracas
+
+America/Asuncion
+
+America/Cuiaba
+
+America/Halifax
+
+America/La\_Paz
+
+America/Santiago
+
+America/St\_Johns
+
+America/Araguaina
+
+America/Argentina/Buenos\_Aires
+
+America/Cayenne
+
+America/Godthab
+
+America/Montevideo
+
+Etc/GMT+2
+
+Atlantic/Azores
+
+Atlantic/Cape\_Verde
+
+Africa/Casablanca
+
+Etc/UTC
+
+Atlantic/Reykjavik
+
+Europe/London
+
+CET
+
+Europe/Bucharest
+
+Africa/Johannesburg
+
+Asia/Beirut
+
+Africa/Cairo
+
+Asia/Jerusalem
+
+Europe/Minsk
+
+Europe/Moscow
+
+Africa/Nairobi
+
+Asia/Karachi
+
+Asia/Kolkata
+
+Asia/Bangkok
+
+Asia/Shanghai
+
+Asia/Kuala\_Lumpur
+
+Australia/Perth
+
+Asia/Taipei
+
+Asia/Tokyo
+
+Asia/Seoul
+
+Australia/Adelaide
+
+Australia/Darwin
+
+Australia/Brisbane
+
+Australia/Canberra
+
+Pacific/Guam
+
+Pacific/Auckland
+
+Types
+
+Events
+
+VM
+
+VM.CREATE
+
+VM.DESTROY
+
+VM.START
+
+VM.STOP
+
+VM.REBOOT
+
+VM.UPDATE
+
+VM.UPGRADE
+
+VM.DYNAMIC.SCALE
+
+VM.RESETPASSWORD
+
+VM.RESETSSHKEY
+
+VM.MIGRATE
+
+VM.MOVE
+
+VM.RESTORE
+
+Domain Router
+
+ROUTER.CREATE
+
+ROUTER.DESTROY
+
+ROUTER.START
+
+ROUTER.STOP
+
+ROUTER.REBOOT
+
+ROUTER.HA
+
+ROUTER.UPGRADE
+
+Console proxy
+
+PROXY.CREATE
+
+PROXY.DESTROY
+
+PROXY.START
+
+PROXY.STOP
+
+PROXY.REBOOT
+
+PROXY.HA
+
+VNC Console Events
+
+VNC.CONNECT
+
+VNC.DISCONNECT
+
+Network Events
+
+NET.IPASSIGN
+
+NET.IPRELEASE
+
+PORTABLE.IPASSIGN
+
+PORTABLE.IPRELEASE
+
+NET.RULEADD
+
+NET.RULEDELETE
+
+NET.RULEMODIFY
+
+NETWORK.CREATE
+
+NETWORK.DELETE
+
+NETWORK.UPDATE
+
+FIREWALL.OPEN
+
+FIREWALL.CLOSE
+
+NIC Events
+
+NIC.CREATE
+
+NIC.DELETE
+
+NIC.UPDATE
+
+NIC.DETAIL.ADD
+
+NIC.DETAIL.UPDATE
+
+NIC.DETAIL.REMOVE
+
+Load Balancers
+
+LB.ASSIGN.TO.RULE
+
+LB.REMOVE.FROM.RULE
+
+LB.CREATE
+
+LB.DELETE
+
+LB.STICKINESSPOLICY.CREATE
+
+LB.STICKINESSPOLICY.DELETE
+
+LB.HEALTHCHECKPOLICY.CREATE
+
+LB.HEALTHCHECKPOLICY.DELETE
+
+LB.UPDATE
+
+Global Load Balancer rules
+
+GLOBAL.LB.ASSIGN
+
+GLOBAL.LB.REMOVE
+
+GLOBAL.LB.CREATE
+
+GLOBAL.LB.DELETE
+
+GLOBAL.LB.UPDATE
+
+Account events
+
+ACCOUNT.ENABLE
+
+ACCOUNT.DISABLE
+
+ACCOUNT.CREATE
+
+ACCOUNT.DELETE
+
+ACCOUNT.UPDATE
+
+ACCOUNT.MARK.DEFAULT.ZONE
+
+UserVO Events
+
+USER.LOGIN
+
+USER.LOGOUT
+
+USER.CREATE
+
+USER.DELETE
+
+USER.DISABLE
+
+USER.UPDATE
+
+USER.ENABLE
+
+USER.LOCK
+
+Registering SSH keypair events
+
+REGISTER.SSH.KEYPAIR
+
+Register for user API and secret keys
+
+REGISTER.USER.KEY
+
+Template Events
+
+TEMPLATE.CREATE
+
+TEMPLATE.DELETE
+
+TEMPLATE.UPDATE
+
+TEMPLATE.DOWNLOAD.START
+
+TEMPLATE.DOWNLOAD.SUCCESS
+
+TEMPLATE.DOWNLOAD.FAILED
+
+TEMPLATE.COPY
+
+TEMPLATE.EXTRACT
+
+TEMPLATE.UPLOAD
+
+TEMPLATE.CLEANUP
+
+Volume Events
+
+VOLUME.CREATE
+
+VOLUME.DELETE
+
+VOLUME.ATTACH
+
+VOLUME.DETACH
+
+VOLUME.EXTRACT
+
+VOLUME.UPLOAD
+
+VOLUME.MIGRATE
+
+VOLUME.RESIZE
+
+VOLUME.DETAIL.UPDATE
+
+VOLUME.DETAIL.ADD
+
+VOLUME.DETAIL.REMOVE
+
+Domains
+
+DOMAIN.CREATE
+
+DOMAIN.DELETE
+
+DOMAIN.UPDATE
+
+Snapshots
+
+SNAPSHOT.CREATE
+
+SNAPSHOT.DELETE
+
+SNAPSHOTPOLICY.CREATE
+
+SNAPSHOTPOLICY.UPDATE
+
+SNAPSHOTPOLICY.DELETE
+
+ISO
+
+ISO.CREATE
+
+ISO.DELETE
+
+ISO.COPY
+
+ISO.ATTACH
+
+ISO.DETACH
+
+ISO.EXTRACT
+
+ISO.UPLOAD
+
+SSVM
+
+SSVM.CREATE
+
+SSVM.DESTROY
+
+SSVM.START
+
+SSVM.STOP
+
+SSVM.REBOOT
+
+SSVM.HA
+
+Service Offerings
+
+SERVICE.OFFERING.CREATE
+
+SERVICE.OFFERING.EDIT
+
+SERVICE.OFFERING.DELETE
+
+Disk Offerings
+
+DISK.OFFERING.CREATE
+
+DISK.OFFERING.EDIT
+
+DISK.OFFERING.DELETE
+
+Network offerings
+
+NETWORK.OFFERING.CREATE
+
+NETWORK.OFFERING.ASSIGN
+
+NETWORK.OFFERING.EDIT
+
+NETWORK.OFFERING.REMOVE
+
+NETWORK.OFFERING.DELETE
+
+Pods
+
+POD.CREATE
+
+POD.EDIT
+
+POD.DELETE
+
+Zones
+
+ZONE.CREATE
+
+ZONE.EDIT
+
+ZONE.DELETE
+
+VLANs/IP ranges
+
+VLAN.IP.RANGE.CREATE
+
+VLAN.IP.RANGE.DELETE
+
+VLAN.IP.RANGE.DEDICATE
+
+VLAN.IP.RANGE.RELEASE
+
+STORAGE.IP.RANGE.CREATE
+
+STORAGE.IP.RANGE.DELETE
+
+STORAGE.IP.RANGE.UPDATE
+
+Configuration Table
+
+CONFIGURATION.VALUE.EDIT
+
+Security Groups
+
+SG.AUTH.INGRESS
+
+SG.REVOKE.INGRESS
+
+SG.AUTH.EGRESS
+
+SG.REVOKE.EGRESS
+
+SG.CREATE
+
+SG.DELETE
+
+SG.ASSIGN
+
+SG.REMOVE
+
+Host
+
+HOST.RECONNECT
+
+Maintenance
+
+MAINT.CANCEL
+
+MAINT.CANCEL.PS
+
+MAINT.PREPARE
+
+MAINT.PREPARE.PS
+
+VPN
+
+VPN.REMOTE.ACCESS.CREATE
+
+VPN.REMOTE.ACCESS.DESTROY
+
+VPN.USER.ADD
+
+VPN.USER.REMOVE
+
+VPN.S2S.VPN.GATEWAY.CREATE
+
+VPN.S2S.VPN.GATEWAY.DELETE
+
+VPN.S2S.CUSTOMER.GATEWAY.CREATE
+
+VPN.S2S.CUSTOMER.GATEWAY.DELETE
+
+VPN.S2S.CUSTOMER.GATEWAY.UPDATE
+
+VPN.S2S.CONNECTION.CREATE
+
+VPN.S2S.CONNECTION.DELETE
+
+VPN.S2S.CONNECTION.RESET
+
+Network
+
+NETWORK.RESTART
+
+Custom certificates
+
+UPLOAD.CUSTOM.CERTIFICATE
+
+OneToOnenat
+
+STATICNAT.ENABLE
+
+STATICNAT.DISABLE
+
+ZONE.VLAN.ASSIGN
+
+ZONE.VLAN.RELEASE
+
+Projects
+
+PROJECT.CREATE
+
+PROJECT.UPDATE
+
+PROJECT.DELETE
+
+PROJECT.ACTIVATE
+
+PROJECT.SUSPEND
+
+PROJECT.ACCOUNT.ADD
+
+PROJECT.INVITATION.UPDATE
+
+PROJECT.INVITATION.REMOVE
+
+PROJECT.ACCOUNT.REMOVE
+
+Network as a Service
+
+NETWORK.ELEMENT.CONFIGURE
+
+Physical Network Events
+
+PHYSICAL.NETWORK.CREATE
+
+PHYSICAL.NETWORK.DELETE
+
+PHYSICAL.NETWORK.UPDATE
+
+Physical Network Service Provider Events
+
+SERVICE.PROVIDER.CREATE
+
+SERVICE.PROVIDER.DELETE
+
+SERVICE.PROVIDER.UPDATE
+
+Physical Network Traffic Type Events
+
+TRAFFIC.TYPE.CREATE
+
+TRAFFIC.TYPE.DELETE
+
+TRAFFIC.TYPE.UPDATE
+
+External network device events
+
+PHYSICAL.LOADBALANCER.ADD
+
+PHYSICAL.LOADBALANCER.DELETE
+
+PHYSICAL.LOADBALANCER.CONFIGURE
+
+External switch management device events
+
+For example: Cisco Nexus 1000v Virtual Supervisor Module.
+
+SWITCH.MGMT.ADD
+
+SWITCH.MGMT.DELETE
+
+SWITCH.MGMT.CONFIGURE
+
+SWITCH.MGMT.ENABLE
+
+SWITCH.MGMT.DISABLE
+
+PHYSICAL.FIREWALL.ADD
+
+PHYSICAL.FIREWALL.DELETE
+
+PHYSICAL.FIREWALL.CONFIGURE
+
+VPC
+
+VPC.CREATE
+
+VPC.UPDATE
+
+VPC.DELETE
+
+VPC.RESTART
+
+Network ACL
+
+NETWORK.ACL.CREATE
+
+NETWORK.ACL.DELETE
+
+NETWORK.ACL.REPLACE
+
+NETWORK.ACL.ITEM.CREATE
+
+NETWORK.ACL.ITEM.UPDATE
+
+NETWORK.ACL.ITEM.DELETE
+
+VPC offerings
+
+VPC.OFFERING.CREATE
+
+VPC.OFFERING.UPDATE
+
+VPC.OFFERING.DELETE
+
+Private gateway
+
+PRIVATE.GATEWAY.CREATE
+
+PRIVATE.GATEWAY.DELETE
+
+Static routes
+
+STATIC.ROUTE.CREATE
+
+STATIC.ROUTE.DELETE
+
+Tag-related events
+
+CREATE\_TAGS
+
+DELETE\_TAGS
+
+Meta data-related events
+
+CREATE\_RESOURCE\_DETAILS
+
+DELETE\_RESOURCE\_DETAILS
+
+VM snapshot events
+
+VMSNAPSHOT.CREATE
+
+VMSNAPSHOT.DELETE
+
+VMSNAPSHOT.REVERTTO
+
+External network device events
+
+PHYSICAL.NVPCONTROLLER.ADD
+
+PHYSICAL.NVPCONTROLLER.DELETE
+
+PHYSICAL.NVPCONTROLLER.CONFIGURE
+
+AutoScale
+
+COUNTER.CREATE
+
+COUNTER.DELETE
+
+CONDITION.CREATE
+
+CONDITION.DELETE
+
+AUTOSCALEPOLICY.CREATE
+
+AUTOSCALEPOLICY.UPDATE
+
+AUTOSCALEPOLICY.DELETE
+
+AUTOSCALEVMPROFILE.CREATE
+
+AUTOSCALEVMPROFILE.DELETE
+
+AUTOSCALEVMPROFILE.UPDATE
+
+AUTOSCALEVMGROUP.CREATE
+
+AUTOSCALEVMGROUP.DELETE
+
+AUTOSCALEVMGROUP.UPDATE
+
+AUTOSCALEVMGROUP.ENABLE
+
+AUTOSCALEVMGROUP.DISABLE
+
+PHYSICAL.DHCP.ADD
+
+PHYSICAL.DHCP.DELETE
+
+PHYSICAL.PXE.ADD
+
+PHYSICAL.PXE.DELETE
+
+AG.CREATE
+
+AG.DELETE
+
+AG.ASSIGN
+
+AG.REMOVE
+
+VM.AG.UPDATE
+
+INTERNALLBVM.START
+
+INTERNALLBVM.STOP
+
+HOST.RESERVATION.RELEASE
+
+Dedicated guest vlan range
+
+GUESTVLANRANGE.DEDICATE
+
+GUESTVLANRANGE.RELEASE
+
+PORTABLE.IP.RANGE.CREATE
+
+PORTABLE.IP.RANGE.DELETE
+
+PORTABLE.IP.TRANSFER
+
+Dedicated Resources
+
+DEDICATE.RESOURCE
+
+DEDICATE.RESOURCE.RELEASE
+
+VM.RESERVATION.CLEANUP
+
+UCS.ASSOCIATEPROFILE
+
+UCS.DISASSOCIATEPROFILE
+
+The following is the list of alert type numbers. The current alerts can
+be found by calling listAlerts.
+
+.. code:: bash
+
+    MEMORY = 0 // Available Memory below configured threshold
+
+.. code:: bash
+
+    CPU = 1 // Unallocated CPU below configured threshold
+
+.. code:: bash
+
+    STORAGE =2 // Available Storage below configured threshold
+
+.. code:: bash
+
+    STORAGE_ALLOCATED = 3 // Remaining unallocated Storage is below configured threshold
+
+.. code:: bash
+
+    PUBLIC_IP = 4 // Number of unallocated virtual network public IPs is below configured threshold
+
+.. code:: bash
+
+    PRIVATE_IP = 5 // Number of unallocated private IPs is below configured threshold
+
+.. code:: bash
+
+    SECONDARY_STORAGE = 6 //  Available Secondary Storage in availability zone is below configured threshold
+
+.. code:: bash
+
+    HOST = 7 // Host related alerts like host disconnected
+
+.. code:: bash
+
+    USERVM = 8 // User VM stopped unexpectedly
+
+.. code:: bash
+
+    DOMAIN_ROUTER = 9 // Domain Router VM stopped unexpectedly
+
+.. code:: bash
+
+    CONSOLE_PROXY = 10 // Console Proxy VM stopped unexpectedly
+
+.. code:: bash
+
+    ROUTING = 11 // Lost connection to default route (to the gateway)
+
+.. code:: bash
+
+    STORAGE_MISC = 12 // Storage issue in system VMs
+
+.. code:: bash
+
+    USAGE_SERVER = 13 // No usage server process running
+
+.. code:: bash
+
+    MANAGMENT_NODE = 14 // Management network CIDR is not configured originally
+
+.. code:: bash
+
+    DOMAIN_ROUTER_MIGRATE = 15 // Domain Router VM Migration was unsuccessful
+
+.. code:: bash
+
+    CONSOLE_PROXY_MIGRATE = 16 // Console Proxy VM Migration was unsuccessful
+
+.. code:: bash
+
+    USERVM_MIGRATE = 17 // User VM Migration was unsuccessful
+
+.. code:: bash
+
+    VLAN = 18 // Number of unallocated VLANs is below configured threshold in availability zone
+
+.. code:: bash
+
+    SSVM = 19 // SSVM stopped unexpectedly
+
+.. code:: bash
+
+    USAGE_SERVER_RESULT = 20 // Usage job failed
+
+.. code:: bash
+
+    STORAGE_DELETE = 21 // Failed to delete storage pool
+
+.. code:: bash
+
+    UPDATE_RESOURCE_COUNT = 22 // Failed to update the resource count
+
+.. code:: bash
+
+    USAGE_SANITY_RESULT = 23 // Usage Sanity Check failed
+
+.. code:: bash
+
+    DIRECT_ATTACHED_PUBLIC_IP = 24 // Number of unallocated shared network IPs is low in availability zone
+
+.. code:: bash
+
+    LOCAL_STORAGE = 25 // Remaining unallocated Local Storage is below configured threshold
+
+.. code:: bash
+
+    RESOURCE_LIMIT_EXCEEDED = 26 //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only
+
+.. |1000-foot-view.png: Overview of CloudStack| image:: ./_static/images/1000-foot-view.png
+.. |basic-deployment.png: Basic two-machine deployment| image:: ./_static/images/basic-deployment.png
+.. |infrastructure\_overview.png: Nested organization of a zone| image:: ./_static/images/infrastructure-overview.png
+.. |region-overview.png: Nested structure of a region.| image:: ./_static/images/region-overview.png
+.. |zone-overview.png: Nested structure of a simple zone.| image:: ./_static/images/zone-overview.png
+.. |pod-overview.png: Nested structure of a simple pod| image:: ./_static/images/pod-overview.png
+.. |cluster-overview.png: Structure of a simple cluster| image:: ./_static/images/cluster-overview.png
+.. |dedicate-resource-button.png: button to dedicate a zone, pod, cluster, or host| image:: ./_static/images/dedicate-resource-button.png
+.. |change-password.png: button to change a user's password| image:: ./_static/images/change-password.png
+.. |searchbutton.png: Searches projects| image:: ./_static/images/search-button.png
+.. |editbutton.png: Edits parameters| image:: ./_static/images/edit-icon.png
+.. |deletebutton.png: Removes a project| image:: ./_static/images/delete-button.png
+.. |deletebutton.png: suspends a project| image:: ./_static/images/suspend-icon.png
+.. |provisioning-overview.png: Conceptual overview of a basic deployment| image:: ./_static/images/provisioning-overview.png
+.. |vsphereclient.png: vSphere client| image:: ./_static/images/vsphere-client.png
+.. |addcluster.png: add a cluster| image:: ./_static/images/add-cluster.png
+.. |ConsoleButton.png: button to launch a console| image:: ./_static/images/console-icon.png
+.. |basic-deployment.png: Basic two-machine CloudStack deployment| image:: ./_static/images/vm-lifecycle.png
+.. |image20| image:: ./_static/images/view-console-button.png
+.. |change-affinity-button.png: button to assign an affinity group to a virtual machine| image:: ./_static/images/change-affinity-button.png
+.. |image22| image:: ./_static/images/SnapshotButton.png
+.. |image23| image:: ./_static/images/delete-button.png
+.. |image24| image:: ./_static/images/revert-vm.png
+.. |StopButton.png: button to stop a VM| image:: ./_static/images/stop-instance-icon.png
+.. |EditButton.png: button to edit the properties of a VM| image:: ./_static/images/edit-icon.png
+.. |ChangeServiceButton.png: button to change the service of a VM| image:: ./_static/images/change-service-icon.png
+.. |Migrateinstance.png: button to migrate an instance| image:: ./_static/images/migrate-instance.png
+.. |Destroyinstance.png: button to destroy an instance| image:: ./_static/images/destroy-instance.png
+.. |iso.png: depicts adding an iso image| image:: ./_static/images/iso-icon.png
+.. |enable-disable.png: button to enable or disable zone, pod, or cluster.| image:: ./_static/images/enable-disable.png
+.. |image32| image:: ./_static/images/enable-disable.png
+.. |edit-icon.png: button to edit the VLAN range.| image:: ./_static/images/edit-icon.png
+.. |sysmanager.png: System Image Manager| image:: ./_static/images/sysmanager.png
+.. |software-license.png: Depicts hiding the EULA page.| image:: ./_static/images/software-license.png
+.. |change-admin-password.png: Depicts changing the administrator password| image:: ./_static/images/change-admin-password.png
+.. |AttachDiskButton.png: button to attach a volume| image:: ./_static/images/attach-disk-icon.png
+.. |DetachDiskButton.png: button to detach a volume| image:: ./_static/images/detach-disk-icon.png
+.. |Migrateinstance.png: button to migrate a volume| image:: ./_static/images/migrate-instance.png
+.. |Migrateinstance.png: button to migrate a VM or volume| image:: ./_static/images/migrate-instance.png
+.. |resize-volume-icon.png: button to display the resize volume option.| image:: ./_static/images/resize-volume-icon.png
+.. |resize-volume.png: option to resize a volume.| image:: ./_static/images/resize-volume.png
+.. |image43| image:: ./_static/images/SnapshotButton.png
+.. |editbutton.png: edits the settings.| image:: ./_static/images/edit-icon.png
+.. |editbutton.png: edits the settings| image:: ./_static/images/edit-icon.png
+.. |guest-traffic-setup.png: Depicts a guest traffic setup| image:: ./_static/images/guest-traffic-setup.png
+.. |networksinglepod.png: diagram showing logical view of network in a pod| image:: ./_static/images/network-singlepod.png
+.. |networksetupzone.png: Depicts network setup in a single zone| image:: ./_static/images/network-setup-zone.png
+.. |addguestnetwork.png: Add Guest network setup in a single zone| image:: ./_static/images/add-guest-network.png
+.. |remove-nic.png: button to remove a NIC| image:: ./_static/images/remove-nic.png
+.. |set-default-nic.png: button to set a NIC as default one.| image:: ./_static/images/set-default-nic.png
+.. |EditButton.png: button to edit a network| image:: ./_static/images/edit-icon.png
+.. |edit-icon.png: button to edit a network| image:: ./_static/images/edit-icon.png
+.. |addAccount-icon.png: button to assign an IP range to an account.| image:: ./_static/images/addAccount-icon.png
+.. |eip-ns-basiczone.png: Elastic IP in a NetScaler-enabled Basic Zone.| image:: ./_static/images/eip-ns-basiczone.png
+.. |add-ip-range.png: adding an IP range to a network.| image:: ./_static/images/add-ip-range.png
+.. |httpaccess.png: allows inbound HTTP access from anywhere| image:: ./_static/images/http-access.png
+.. |autoscaleateconfig.png: Configuring AutoScale| image:: ./_static/images/autoscale-config.png
+.. |EnableDisable.png: button to enable or disable AutoScale.| image:: ./_static/images/enable-disable-autoscale.png
+.. |gslb.png: GSLB architecture| image:: ./_static/images/gslb.png
+.. |gslb-add.png: adding a gslb rule| image:: ./_static/images/add-gslb.png
+.. |ReleaseIPButton.png: button to release an IP| image:: ./_static/images/release-ip-icon.png
+.. |enabledisablenat.png: button to enable/disable NAT| image:: ./_static/images/enable-disable.png
+.. |egress-firewall-rule.png: adding an egress firewall rule| image:: ./_static/images/egress-firewall-rule.png
+.. |EnableVPNButton.png: button to enable a VPN| image:: ./_static/images/vpn-icon.png
+.. |vpn-icon.png: button to enable VPN| image:: ./_static/images/vpn-icon.png
+.. |addvpncustomergateway.png: adding a customer gateway.| image:: ./_static/images/add-vpn-customer-gateway.png
+.. |edit.png: button to edit a VPN customer gateway| image:: ./_static/images/edit-icon.png
+.. |delete.png: button to remove a VPN customer gateway| image:: ./_static/images/delete-button.png
+.. |createvpnconnection.png: creating a VPN connection to the customer gateway.| image:: ./_static/images/create-vpn-connection.png
+.. |remove-vpn.png: button to remove a VPN connection| image:: ./_static/images/remove-vpn.png
+.. |reset-vpn.png: button to reset a VPN connection| image:: ./_static/images/reset-vpn.png
+.. |mutltier.png: a multi-tier setup.| image:: ./_static/images/multi-tier-app.png
+.. |add-vpc.png: adding a vpc.| image:: ./_static/images/add-vpc.png
+.. |add-tier.png: adding a tier to a vpc.| image:: ./_static/images/add-tier.png
+.. |replace-acl-icon.png: button to replace an ACL list| image:: ./_static/images/replace-acl-icon.png
+.. |add-new-gateway-vpc.png: adding a private gateway for the VPC.| image:: ./_static/images/add-new-gateway-vpc.png
+.. |replace-acl-icon.png: button to replace the default ACL behaviour.| image:: ./_static/images/replace-acl-icon.png
+.. |add-vm-vpc.png: adding a VM to a vpc.| image:: ./_static/images/add-vm-vpc.png
+.. |addvm-tier-sharednw.png: adding a VM to a VPC tier and shared network.| image:: ./_static/images/addvm-tier-sharednw.png
+.. |release-ip-icon.png: button to release an IP.| image:: ./_static/images/release-ip-icon.png
+.. |enable-disable.png: button to enable Static NAT.| image:: ./_static/images/enable-disable.png
+.. |select-vmstatic-nat.png: selecting a tier to apply staticNAT.| image:: ./_static/images/select-vm-staticnat-vpc.png
+.. |vpc-lb.png: Configuring internal LB for VPC| image:: ./_static/images/vpc-lb.png
+.. |del-tier.png: button to remove a tier| image:: ./_static/images/del-tier.png
+.. |remove-vpc.png: button to remove a VPC| image:: ./_static/images/remove-vpc.png
+.. |edit-icon.png: button to edit a VPC| image:: ./_static/images/edit-icon.png
+.. |restart-vpc.png: button to restart a VPC| image:: ./_static/images/restart-vpc.png
+.. |vr-upgrade.png: Button to upgrade VR to use the new template.| image:: ./_static/images/vr-upgrade.png
+
+

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/4bbce96f/source/hosts.rst
----------------------------------------------------------------------
diff --git a/source/hosts.rst b/source/hosts.rst
new file mode 100644
index 0000000..ed859a5
--- /dev/null
+++ b/source/hosts.rst
@@ -0,0 +1,658 @@
+Working with Hosts
+==================
+
+Adding Hosts
+------------------
+
+Additional hosts can be added at any time to provide more capacity for
+guest VMs. For requirements and instructions, see `Section 7.6, “Adding
+a Host” <#host-add>`__.
+
+Scheduled Maintenance and Maintenance Mode for Hosts
+----------------------------------------------------------
+
+You can place a host into maintenance mode. When maintenance mode is
+activated, the host becomes unavailable to receive new guest VMs, and
+the guest VMs already running on the host are seamlessly migrated to
+another host not in maintenance mode. This migration uses live migration
+technology and does not interrupt the execution of the guest.
+
+vCenter and Maintenance Mode
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To enter maintenance mode on a vCenter host, both vCenter and CloudStack
+must be used in concert. CloudStack and vCenter have separate
+maintenance modes that work closely together.
+
+#. 
+
+   Place the host into CloudStack's "scheduled maintenance" mode. This
+   does not invoke the vCenter maintenance mode, but only causes VMs to
+   be migrated off the host
+
+   When the CloudStack maintenance mode is requested, the host first
+   moves into the Prepare for Maintenance state. In this state it cannot
+   be the target of new guest VM starts. Then all VMs will be migrated
+   off the server. Live migration will be used to move VMs off the host.
+   This allows the guests to be migrated to other hosts with no
+   disruption to the guests. After this migration is completed, the host
+   will enter the Ready for Maintenance mode.
+
+#. 
+
+   Wait for the "Ready for Maintenance" indicator to appear in the UI.
+
+#. 
+
+   Now use vCenter to perform whatever actions are necessary to maintain
+   the host. During this time, the host cannot be the target of new VM
+   allocations.
+
+#. 
+
+   When the maintenance tasks are complete, take the host out of
+   maintenance mode as follows:
+
+   #. 
+
+      First use vCenter to exit the vCenter maintenance mode.
+
+      This makes the host ready for CloudStack to reactivate it.
+
+   #. 
+
+      Then use CloudStack's administrator UI to cancel the CloudStack
+      maintenance mode
+
+      When the host comes back online, the VMs that were migrated off of
+      it may be migrated back to it manually and new VMs can be added.
+
+XenServer and Maintenance Mode
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For XenServer, you can take a server offline temporarily by using the
+Maintenance Mode feature in XenCenter. When you place a server into
+Maintenance Mode, all running VMs are automatically migrated from it to
+another host in the same pool. If the server is the pool master, a new
+master will also be selected for the pool. While a server is Maintenance
+Mode, you cannot create or start any VMs on it.
+
+**To place a server in Maintenance Mode:**
+
+#. 
+
+   In the Resources pane, select the server, then do one of the
+   following:
+
+   -  
+
+      Right-click, then click Enter Maintenance Mode on the shortcut
+      menu.
+
+   -  
+
+      On the Server menu, click Enter Maintenance Mode.
+
+#. 
+
+   Click Enter Maintenance Mode.
+
+The server's status in the Resources pane shows when all running VMs
+have been successfully migrated off the server.
+
+**To take a server out of Maintenance Mode:**
+
+#. 
+
+   In the Resources pane, select the server, then do one of the
+   following:
+
+   -  
+
+      Right-click, then click Exit Maintenance Mode on the shortcut
+      menu.
+
+   -  
+
+      On the Server menu, click Exit Maintenance Mode.
+
+#. 
+
+   Click Exit Maintenance Mode.
+
+Disabling and Enabling Zones, Pods, and Clusters
+------------------------------------------------------
+
+You can enable or disable a zone, pod, or cluster without permanently
+removing it from the cloud. This is useful for maintenance or when there
+are problems that make a portion of the cloud infrastructure unreliable.
+No new allocations will be made to a disabled zone, pod, or cluster
+until its state is returned to Enabled. When a zone, pod, or cluster is
+first added to the cloud, it is Disabled by default.
+
+To disable and enable a zone, pod, or cluster:
+
+#. 
+
+   Log in to the CloudStack UI as administrator
+
+#. 
+
+   In the left navigation bar, click Infrastructure.
+
+#. 
+
+   In Zones, click View More.
+
+#. 
+
+   If you are disabling or enabling a zone, find the name of the zone in
+   the list, and click the Enable/Disable button. |enable-disable.png:
+   button to enable or disable zone, pod, or cluster.|
+
+#. 
+
+   If you are disabling or enabling a pod or cluster, click the name of
+   the zone that contains the pod or cluster.
+
+#. 
+
+   Click the Compute tab.
+
+#. 
+
+   In the Pods or Clusters node of the diagram, click View All.
+
+#. 
+
+   Click the pod or cluster name in the list.
+
+#. 
+
+   Click the Enable/Disable button. |image32|
+
+Removing Hosts
+--------------------
+
+Hosts can be removed from the cloud as needed. The procedure to remove a
+host depends on the hypervisor type.
+
+Removing XenServer and KVM Hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A node cannot be removed from a cluster until it has been placed in
+maintenance mode. This will ensure that all of the VMs on it have been
+migrated to other Hosts. To remove a Host from the cloud:
+
+#. 
+
+   Place the node in maintenance mode.
+
+   See `Section 11.2, “Scheduled Maintenance and Maintenance Mode for
+   Hosts” <#scheduled-maintenance-maintenance-mode-hosts>`__.
+
+#. 
+
+   For KVM, stop the cloud-agent service.
+
+#. 
+
+   Use the UI option to remove the node.
+
+   Then you may power down the Host, re-use its IP address, re-install
+   it, etc
+
+Removing vSphere Hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To remove this type of host, first place it in maintenance mode, as
+described in `Section 11.2, “Scheduled Maintenance and Maintenance Mode
+for Hosts” <#scheduled-maintenance-maintenance-mode-hosts>`__. Then use
+CloudStack to remove the host. CloudStack will not direct commands to a
+host that has been removed using CloudStack. However, the host may still
+exist in the vCenter cluster.
+
+Re-Installing Hosts
+-------------------------
+
+You can re-install a host after placing it in maintenance mode and then
+removing it. If a host is down and cannot be placed in maintenance mode,
+it should still be removed before the re-install.
+
+Maintaining Hypervisors on Hosts
+--------------------------------------
+
+When running hypervisor software on hosts, be sure all the hotfixes
+provided by the hypervisor vendor are applied. Track the release of
+hypervisor patches through your hypervisor vendor’s support channel, and
+apply patches as soon as possible after they are released. CloudStack
+will not track or notify you of required hypervisor patches. It is
+essential that your hosts are completely up to date with the provided
+hypervisor patches. The hypervisor vendor is likely to refuse to support
+any system that is not up to date with patches.
+
+.. note:: The lack of up-do-date hotfixes can lead to data corruption and lost
+VMs.
+
+(XenServer) For more information, see `Highly Recommended Hotfixes for
+XenServer in the CloudStack Knowledge
+Base <http://docs.cloudstack.org/Knowledge_Base/Possible_VM_corruption_if_XenServer_Hotfix_is_not_Applied/Highly_Recommended_Hotfixes_for_XenServer_5.6_SP2>`__.
+
+Changing Host Password
+----------------------------
+
+The password for a XenServer Node, KVM Node, or vSphere Node may be
+changed in the database. Note that all Nodes in a Cluster must have the
+same password.
+
+To change a Node's password:
+
+#. 
+
+   Identify all hosts in the cluster.
+
+#. 
+
+   Change the password on all hosts in the cluster. Now the password for
+   the host and the password known to CloudStack will not match.
+   Operations on the cluster will fail until the two passwords match.
+
+#. 
+
+   Get the list of host IDs for the host in the cluster where you are
+   changing the password. You will need to access the database to
+   determine these host IDs. For each hostname "h" (or vSphere cluster)
+   that you are changing the password for, execute:
+
+   .. code:: bash
+
+       mysql> select id from cloud.host where name like '%h%';
+
+#. 
+
+   This should return a single ID. Record the set of such IDs for these
+   hosts.
+
+#. 
+
+   Update the passwords for the host in the database. In this example,
+   we change the passwords for hosts with IDs 5, 10, and 12 to
+   "password".
+
+   .. code:: bash
+
+       mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;
+
+Over-Provisioning and Service Offering Limits
+---------------------------------------------------
+
+(Supported for XenServer, KVM, and VMware)
+
+CPU and memory (RAM) over-provisioning factors can be set for each
+cluster to change the number of VMs that can run on each host in the
+cluster. This helps optimize the use of resources. By increasing the
+over-provisioning ratio, more resource capacity will be used. If the
+ratio is set to 1, no over-provisioning is done.
+
+The administrator can also set global default over-provisioning ratios
+in the cpu.overprovisioning.factor and mem.overprovisioning.factor
+global configuration variables. The default value of these variables is
+1: over-provisioning is turned off by default.
+
+Over-provisioning ratios are dynamically substituted in CloudStack's
+capacity calculations. For example:
+
+Capacity = 2 GB
+
+Over-provisioning factor = 2
+
+Capacity after over-provisioning = 4 GB
+
+With this configuration, suppose you deploy 3 VMs of 1 GB each:
+
+Used = 3 GB
+
+Free = 1 GB
+
+The administrator can specify a memory over-provisioning ratio, and can
+specify both CPU and memory over-provisioning ratios on a per-cluster
+basis.
+
+In any given cloud, the optimum number of VMs for each host is affected
+by such things as the hypervisor, storage, and hardware configuration.
+These may be different for each cluster in the same cloud. A single
+global over-provisioning setting can not provide the best utilization
+for all the different clusters in the cloud. It has to be set for the
+lowest common denominator. The per-cluster setting provides a finer
+granularity for better utilization of resources, no matter where the
+CloudStack placement algorithm decides to place a VM.
+
+The overprovisioning settings can be used along with dedicated resources
+(assigning a specific cluster to an account) to effectively offer
+different levels of service to different accounts. For example, an
+account paying for a more expensive level of service could be assigned
+to a dedicated cluster with an over-provisioning ratio of 1, and a
+lower-paying account to a cluster with a ratio of 2.
+
+When a new host is added to a cluster, CloudStack will assume the host
+has the capability to perform the CPU and RAM over-provisioning which is
+configured for that cluster. It is up to the administrator to be sure
+the host is actually suitable for the level of over-provisioning which
+has been set.
+
+Limitations on Over-Provisioning in XenServer and KVM
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  
+
+   In XenServer, due to a constraint of this hypervisor, you can not use
+   an over-provisioning factor greater than 4.
+
+-  
+
+   The KVM hypervisor can not manage memory allocation to VMs
+   dynamically. CloudStack sets the minimum and maximum amount of memory
+   that a VM can use. The hypervisor adjusts the memory within the set
+   limits based on the memory contention.
+
+Requirements for Over-Provisioning
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Several prerequisites are required in order for over-provisioning to
+function properly. The feature is dependent on the OS type, hypervisor
+capabilities, and certain scripts. It is the administrator's
+responsibility to ensure that these requirements are met.
+
+Balloon Driver
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+All VMs should have a balloon driver installed in them. The hypervisor
+communicates with the balloon driver to free up and make the memory
+available to a VM.
+
+XenServer
+'''''''''
+
+The balloon driver can be found as a part of xen pv or PVHVM drivers.
+The xen pvhvm drivers are included in upstream linux kernels 2.6.36+.
+
+VMware
+''''''
+
+The balloon driver can be found as a part of the VMware tools. All the
+VMs that are deployed in a over-provisioned cluster should have the
+VMware tools installed.
+
+KVM
+'''
+
+All VMs are required to support the virtio drivers. These drivers are
+installed in all Linux kernel versions 2.6.25 and greater. The
+administrator must set CONFIG\_VIRTIO\_BALLOON=y in the virtio
+configuration.
+
+Hypervisor capabilities
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The hypervisor must be capable of using the memory ballooning.
+
+XenServer
+'''''''''
+
+The DMC (Dynamic Memory Control) capability of the hypervisor should be
+enabled. Only XenServer Advanced and above versions have this feature.
+
+VMware, KVM
+'''''''''''
+
+Memory ballooning is supported by default.
+
+Setting Over-Provisioning Ratios
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There are two ways the root admin can set CPU and RAM over-provisioning
+ratios. First, the global configuration settings
+cpu.overprovisioning.factor and mem.overprovisioning.factor will be
+applied when a new cluster is created. Later, the ratios can be modified
+for an existing cluster.
+
+Only VMs deployed after the change are affected by the new setting. If
+you want VMs deployed before the change to adopt the new
+over-provisioning ratio, you must stop and restart the VMs. When this is
+done, CloudStack recalculates or scales the used and reserved capacities
+based on the new over-provisioning ratios, to ensure that CloudStack is
+correctly tracking the amount of free capacity.
+
+.. note:: It is safer not to deploy additional new VMs while the capacity
+recalculation is underway, in case the new values for available capacity
+are not high enough to accommodate the new VMs. Just wait for the new
+used/available values to become available, to be sure there is room for
+all the new VMs you want.
+
+To change the over-provisioning ratios for an existing cluster:
+
+#. 
+
+   Log in as administrator to the CloudStack UI.
+
+#. 
+
+   In the left navigation bar, click Infrastructure.
+
+#. 
+
+   Under Clusters, click View All.
+
+#. 
+
+   Select the cluster you want to work with, and click the Edit button.
+
+#. 
+
+   Fill in your desired over-provisioning multipliers in the fields CPU
+   overcommit ratio and RAM overcommit ratio. The value which is
+   intially shown in these fields is the default value inherited from
+   the global configuration settings.
+
+   .. note:: In XenServer, due to a constraint of this hypervisor, you can not use
+   an over-provisioning factor greater than 4.
+
+Service Offering Limits and Over-Provisioning
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Service offering limits (e.g. 1 GHz, 1 core) are strictly enforced for
+core count. For example, a guest with a service offering of one core
+will have only one core available to it regardless of other activity on
+the Host.
+
+Service offering limits for gigahertz are enforced only in the presence
+of contention for CPU resources. For example, suppose that a guest was
+created with a service offering of 1 GHz on a Host that has 2 GHz cores,
+and that guest is the only guest running on the Host. The guest will
+have the full 2 GHz available to it. When multiple guests are attempting
+to use the CPU a weighting factor is used to schedule CPU resources. The
+weight is based on the clock speed in the service offering. Guests
+receive a CPU allocation that is proportionate to the GHz in the service
+offering. For example, a guest created from a 2 GHz service offering
+will receive twice the CPU allocation as a guest created from a 1 GHz
+service offering. CloudStack does not perform memory over-provisioning.
+
+VLAN Provisioning
+-----------------------
+
+CloudStack automatically creates and destroys interfaces bridged to
+VLANs on the hosts. In general the administrator does not need to manage
+this process.
+
+CloudStack manages VLANs differently based on hypervisor type. For
+XenServer or KVM, the VLANs are created on only the hosts where they
+will be used and then they are destroyed when all guests that require
+them have been terminated or moved to another host.
+
+For vSphere the VLANs are provisioned on all hosts in the cluster even
+if there is no guest running on a particular Host that requires the
+VLAN. This allows the administrator to perform live migration and other
+functions in vCenter without having to create the VLAN on the
+destination Host. Additionally, the VLANs are not removed from the Hosts
+when they are no longer needed.
+
+You can use the same VLANs on different physical networks provided that
+each physical network has its own underlying layer-2 infrastructure,
+such as switches. For example, you can specify VLAN range 500 to 1000
+while deploying physical networks A and B in an Advanced zone setup.
+This capability allows you to set up an additional layer-2 physical
+infrastructure on a different physical NIC and use the same set of VLANs
+if you run out of VLANs. Another advantage is that you can use the same
+set of IPs for different customers, each one with their own routers and
+the guest networks on different physical NICs.
+
+VLAN Allocation Example
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+VLANs are required for public and guest traffic. The following is an
+example of a VLAN allocation scheme:
+
+VLAN IDs
+
+Traffic type
+
+Scope
+
+less than 500
+
+Management traffic. Reserved for administrative purposes.
+
+CloudStack software can access this, hypervisors, system VMs.
+
+500-599
+
+VLAN carrying public traffic.
+
+CloudStack accounts.
+
+600-799
+
+VLANs carrying guest traffic.
+
+CloudStack accounts. Account-specific VLAN is chosen from this pool.
+
+800-899
+
+VLANs carrying guest traffic.
+
+CloudStack accounts. Account-specific VLAN chosen by CloudStack admin to
+assign to that account.
+
+900-999
+
+VLAN carrying guest traffic
+
+CloudStack accounts. Can be scoped by project, domain, or all accounts.
+
+greater than 1000
+
+Reserved for future use
+
+Adding Non Contiguous VLAN Ranges
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CloudStack provides you with the flexibility to add non contiguous VLAN
+ranges to your network. The administrator can either update an existing
+VLAN range or add multiple non contiguous VLAN ranges while creating a
+zone. You can also use the UpdatephysicalNetwork API to extend the VLAN
+range.
+
+#. 
+
+   Log in to the CloudStack UI as an administrator or end user.
+
+#. 
+
+   Ensure that the VLAN range does not already exist.
+
+#. 
+
+   In the left navigation, choose Infrastructure.
+
+#. 
+
+   On Zones, click View More, then click the zone to which you want to
+   work with.
+
+#. 
+
+   Click Physical Network.
+
+#. 
+
+   In the Guest node of the diagram, click Configure.
+
+#. 
+
+   Click Edit |edit-icon.png: button to edit the VLAN range.|
+
+   The VLAN Ranges field now is editable.
+
+#. 
+
+   Specify the start and end of the VLAN range in comma-separated list.
+
+   Specify all the VLANs you want to use, VLANs not specified will be
+   removed if you are adding new ranges to the existing list.
+
+#. 
+
+   Click Apply.
+
+Assigning VLANs to Isolated Networks
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CloudStack provides you the ability to control VLAN assignment to
+Isolated networks. As a Root admin, you can assign a VLAN ID when a
+network is created, just the way it's done for Shared networks.
+
+The former behaviour also is supported — VLAN is randomly allocated to a
+network from the VNET range of the physical network when the network
+turns to Implemented state. The VLAN is released back to the VNET pool
+when the network shuts down as a part of the Network Garbage Collection.
+The VLAN can be re-used either by the same network when it is
+implemented again, or by any other network. On each subsequent
+implementation of a network, a new VLAN can be assigned.
+
+Only the Root admin can assign VLANs because the regular users or domain
+admin are not aware of the physical network topology. They cannot even
+view what VLAN is assigned to a network.
+
+To enable you to assign VLANs to Isolated networks,
+
+#. 
+
+   Create a network offering by specifying the following:
+
+   -  
+
+      **Guest Type**: Select Isolated.
+
+   -  
+
+      **Specify VLAN**: Select the option.
+
+   For more information, see the CloudStack Installation Guide.
+
+#. 
+
+   Using this network offering, create a network.
+
+   You can create a VPC tier or an Isolated network.
+
+#. 
+
+   Specify the VLAN when you create the network.
+
+   When VLAN is specified, a CIDR and gateway are assigned to this
+   network and the state is changed to Setup. In this state, the network
+   will not be garbage collected.
+
+.. note:: You cannot change a VLAN once it's assigned to the network. The VLAN
+remains with the network for its entire life cycle.
+

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/4bbce96f/source/index.rst
----------------------------------------------------------------------
diff --git a/source/index.rst b/source/index.rst
index 7ac2a93..9e16f45 100644
--- a/source/index.rst
+++ b/source/index.rst
@@ -21,17 +21,174 @@
 Welcome to CloudStack Administration Documentation
 ==================================================
 
-Contents:
+.. toctree::
+   :maxdepth: 2
 
+Managing Accounts, Users and Domains
+------------------------------------------
 .. toctree::
    :maxdepth: 2
 
-Administration
+   accounts
+
+User Services
 --------------
 .. toctree::
-    :maxdepth: 2
+   :maxdepth: 2
+
+   user_services
+
+User Interface
+--------------
+.. toctree::
+   :maxdepth: 2
+
+   ui
+
+Using Projects to Organize User Resources
+------------------------------------------
+.. toctree::
+   :maxdepth: 2 
+
+   projects
+
+
+
+Steps to Provision your Cloud Infrastructure
+--------------------------------------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   provisioning
+
+Service Offerings
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   service_offerings
+
+Setting up Networking for Users
+------------------------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   networking
+
+Working with Virtual Machines
+------------------------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   virtual_machines
+
+Working with Hosts
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   hosts
+
+Working with Templates
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   templates
+
+Working with Storage
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   storage
+
+Working with Usage
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   usage
+
+Managing Networks and Traffic
+------------------------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   networking2
+
+Working with System Virtual Machines
+------------------------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   systemvm
+
+System Reliability and Availability
+------------------------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   reliability
+
+Managing the Cloud
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   management
+
+Setting Configuration Parameters
+------------------------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   parameters
+
+CloudStack API
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   api
+
+Tuning
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   tuning
+
+Troubleshooting
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
+
+   troubleshooting
+
+Events
+----------------------------
+
+.. toctree::
+   :maxdepth: 2
 
-    administration
+   events
 
 Indices and tables
 ==================

http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/4bbce96f/source/management.rst
----------------------------------------------------------------------
diff --git a/source/management.rst b/source/management.rst
new file mode 100644
index 0000000..bc41ac2
--- /dev/null
+++ b/source/management.rst
@@ -0,0 +1,435 @@
+Managing the Cloud
+==================
+
+Using Tags to Organize Resources in the Cloud
+---------------------------------------------------
+
+A tag is a key-value pair that stores metadata about a resource in the
+cloud. Tags are useful for categorizing resources. For example, you can
+tag a user VM with a value that indicates the user's city of residence.
+In this case, the key would be "city" and the value might be "Toronto"
+or "Tokyo." You can then request CloudStack to find all resources that
+have a given tag; for example, VMs for users in a given city.
+
+You can tag a user virtual machine, volume, snapshot, guest network,
+template, ISO, firewall rule, port forwarding rule, public IP address,
+security group, load balancer rule, project, VPC, network ACL, or static
+route. You can not tag a remote access VPN.
+
+You can work with tags through the UI or through the API commands
+createTags, deleteTags, and listTags. You can define multiple tags for
+each resource. There is no limit on the number of tags you can define.
+Each tag can be up to 255 characters long. Users can define tags on the
+resources they own, and administrators can define tags on any resources
+in the cloud.
+
+An optional input parameter, "tags," exists on many of the list\* API
+commands. The following example shows how to use this new parameter to
+find all the volumes having tag region=canada OR tag city=Toronto:
+
+.. code:: bash
+
+    command=listVolumes
+                    &listAll=true
+                    &tags[0].key=region
+                    &tags[0].value=canada
+                    &tags[1].key=city
+                    &tags[1].value=Toronto
+
+The following API commands have the "tags" input parameter:
+
+-  
+
+   listVirtualMachines
+
+-  
+
+   listVolumes
+
+-  
+
+   listSnapshots
+
+-  
+
+   listNetworks
+
+-  
+
+   listTemplates
+
+-  
+
+   listIsos
+
+-  
+
+   listFirewallRules
+
+-  
+
+   listPortForwardingRules
+
+-  
+
+   listPublicIpAddresses
+
+-  
+
+   listSecurityGroups
+
+-  
+
+   listLoadBalancerRules
+
+-  
+
+   listProjects
+
+-  
+
+   listVPCs
+
+-  
+
+   listNetworkACLs
+
+-  
+
+   listStaticRoutes
+
+Changing the Database Configuration
+-----------------------------------------
+
+The CloudStack Management Server stores database configuration
+information (e.g., hostname, port, credentials) in the file
+``/etc/cloudstack/management/db.properties``. To effect a change, edit
+this file on each Management Server, then restart the Management Server.
+
+Changing the Database Password
+------------------------------------
+
+You may need to change the password for the MySQL account used by
+CloudStack. If so, you'll need to change the password in MySQL, and then
+add the encrypted password to
+``/etc/cloudstack/management/db.properties``.
+
+#. 
+
+   Before changing the password, you'll need to stop CloudStack's
+   management server and the usage engine if you've deployed that
+   component.
+
+   .. code:: screen
+
+       # service cloudstack-management stop
+       # service cloudstack-usage stop
+
+#. 
+
+   Next, you'll update the password for the CloudStack user on the MySQL
+   server.
+
+   .. code:: screen
+
+       # mysql -u root -p
+
+   At the MySQL shell, you'll change the password and flush privileges:
+
+   .. code:: screen
+
+       update mysql.user set password=PASSWORD("newpassword123") where User='cloud';
+       flush privileges;
+       quit;
+
+#. 
+
+   The next step is to encrypt the password and copy the encrypted
+   password to CloudStack's database configuration
+   (``/etc/cloudstack/management/db.properties``).
+
+   .. code:: screen
+
+           # java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.0.jar \ org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI encrypt.sh \ input="newpassword123" password="`cat /etc/cloudstack/management/key`" \ verbose=false 
+
+   File encryption type
+   --------------------
+
+   Note that this is for the file encryption type. If you're using the
+   web encryption type then you'll use
+   password="management\_server\_secret\_key"
+
+#. 
+
+   Now, you'll update ``/etc/cloudstack/management/db.properties`` with
+   the new ciphertext. Open ``/etc/cloudstack/management/db.properties``
+   in a text editor, and update these parameters:
+
+   .. code:: bash
+
+       db.cloud.password=ENC(encrypted_password_from_above) 
+       db.usage.password=ENC(encrypted_password_from_above)
+
+#. 
+
+   After copying the new password over, you can now start CloudStack
+   (and the usage engine, if necessary).
+
+   .. code:: screen
+
+               # service cloudstack-management start
+               # service cloud-usage start
+
+Administrator Alerts
+--------------------------
+
+The system provides alerts and events to help with the management of the
+cloud. Alerts are notices to an administrator, generally delivered by
+e-mail, notifying the administrator that an error has occurred in the
+cloud. Alert behavior is configurable.
+
+Events track all of the user and administrator actions in the cloud. For
+example, every guest VM start creates an associated event. Events are
+stored in the Management Server’s database.
+
+Emails will be sent to administrators under the following circumstances:
+
+-  
+
+   The Management Server cluster runs low on CPU, memory, or storage
+   resources
+
+-  
+
+   The Management Server loses heartbeat from a Host for more than 3
+   minutes
+
+-  
+
+   The Host cluster runs low on CPU, memory, or storage resources
+
+Sending Alerts to External SNMP and Syslog Managers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In addition to showing administrator alerts on the Dashboard in the
+CloudStack UI and sending them in email, CloudStack can also send the
+same alerts to external SNMP or Syslog management software. This is
+useful if you prefer to use an SNMP or Syslog manager to monitor your
+cloud.
+
+The alerts which can be sent are listed in `Appendix C,
+*Alerts* <#alerts>`__. You can also display the most up to date list by
+calling the API command listAlerts.
+
+SNMP Alert Details
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The supported protocol is SNMP version 2.
+
+Each SNMP trap contains the following information: message, podId,
+dataCenterId, clusterId, and generationTime.
+
+Syslog Alert Details
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+CloudStack generates a syslog message for every alert. Each syslog
+message incudes the fields alertType, message, podId, dataCenterId, and
+clusterId, in the following format. If any field does not have a valid
+value, it will not be included.
+
+.. code:: bash
+
+    Date severity_level Management_Server_IP_Address/Name  alertType:: value dataCenterId:: value  podId:: value  clusterId:: value  message:: value
+
+For example:
+
+.. code:: bash
+
+    Mar  4 10:13:47    WARN    localhost    alertType:: managementNode message:: Management server node 127.0.0.1 is up
+
+Configuring SNMP and Syslog Managers
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To configure one or more SNMP managers or Syslog managers to receive
+alerts from CloudStack:
+
+#. 
+
+   For an SNMP manager, install the CloudStack MIB file on your SNMP
+   manager system. This maps the SNMP OIDs to trap types that can be
+   more easily read by users. The file must be publicly available. For
+   more information on how to install this file, consult the
+   documentation provided with the SNMP manager.
+
+#. 
+
+   Edit the file /etc/cloudstack/management/log4j-cloud.xml.
+
+   .. code:: bash
+
+       # vi /etc/cloudstack/management/log4j-cloud.xml
+
+#. 
+
+   Add an entry using the syntax shown below. Follow the appropriate
+   example depending on whether you are adding an SNMP manager or a
+   Syslog manager. To specify multiple external managers, separate the
+   IP addresses and other configuration values with commas (,).
+
+   .. note:: The recommended maximum number of SNMP or Syslog managers is 20 for
+   each.
+
+   The following example shows how to configure two SNMP managers at IP
+   addresses 10.1.1.1 and 10.1.1.2. Substitute your own IP addresses,
+   ports, and communities. Do not change the other values (name,
+   threshold, class, and layout values).
+
+   .. code:: bash
+
+       <appender name="SNMP" class="org.apache.cloudstack.alert.snmp.SnmpTrapAppender">
+         <param name="Threshold" value="WARN"/>  <!-- Do not edit. The alert feature assumes WARN. -->
+         <param name="SnmpManagerIpAddresses" value="10.1.1.1,10.1.1.2"/>
+         <param name="SnmpManagerPorts" value="162,162"/>
+         <param name="SnmpManagerCommunities" value="public,public"/>
+         <layout class="org.apache.cloudstack.alert.snmp.SnmpEnhancedPatternLayout"> <!-- Do not edit -->
+           <param name="PairDelimeter" value="//"/>
+           <param name="KeyValueDelimeter" value="::"/>
+         </layout>
+       </appender>
+
+   The following example shows how to configure two Syslog managers at
+   IP addresses 10.1.1.1 and 10.1.1.2. Substitute your own IP addresses.
+   You can set Facility to any syslog-defined value, such as LOCAL0 -
+   LOCAL7. Do not change the other values.
+
+   .. code:: bash
+
+       <appender name="ALERTSYSLOG">
+         <param name="Threshold" value="WARN"/>
+         <param name="SyslogHosts" value="10.1.1.1,10.1.1.2"/>
+         <param name="Facility" value="LOCAL6"/>   
+         <layout>
+           <param name="ConversionPattern" value=""/>
+         </layout>
+       </appender>
+
+#. 
+
+   If your cloud has multiple Management Server nodes, repeat these
+   steps to edit log4j-cloud.xml on every instance.
+
+#. 
+
+   If you have made these changes while the Management Server is
+   running, wait a few minutes for the change to take effect.
+
+**Troubleshooting:** If no alerts appear at the configured SNMP or
+Syslog manager after a reasonable amount of time, it is likely that
+there is an error in the syntax of the <appender> entry in
+log4j-cloud.xml. Check to be sure that the format and settings are
+correct.
+
+Deleting an SNMP or Syslog Manager
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To remove an external SNMP manager or Syslog manager so that it no
+longer receives alerts from CloudStack, remove the corresponding entry
+from the file /etc/cloudstack/management/log4j-cloud.xml.
+
+Customizing the Network Domain Name
+-----------------------------------------
+
+The root administrator can optionally assign a custom DNS suffix at the
+level of a network, account, domain, zone, or entire CloudStack
+installation, and a domain administrator can do so within their own
+domain. To specify a custom domain name and put it into effect, follow
+these steps.
+
+#. 
+
+   Set the DNS suffix at the desired scope
+
+   -  
+
+      At the network level, the DNS suffix can be assigned through the
+      UI when creating a new network, as described in `Section 15.6.1,
+      “Adding an Additional Guest
+      Network” <#add-additional-guest-network>`__ or with the
+      updateNetwork command in the CloudStack API.
+
+   -  
+
+      At the account, domain, or zone level, the DNS suffix can be
+      assigned with the appropriate CloudStack API commands:
+      createAccount, editAccount, createDomain, editDomain, createZone,
+      or editZone.
+
+   -  
+
+      At the global level, use the configuration parameter
+      guest.domain.suffix. You can also use the CloudStack API command
+      updateConfiguration. After modifying this global configuration,
+      restart the Management Server to put the new setting into effect.
+
+#. 
+
+   To make the new DNS suffix take effect for an existing network, call
+   the CloudStack API command updateNetwork. This step is not necessary
+   when the DNS suffix was specified while creating a new network.
+
+The source of the network domain that is used depends on the following
+rules.
+
+-  
+
+   For all networks, if a network domain is specified as part of a
+   network's own configuration, that value is used.
+
+-  
+
+   For an account-specific network, the network domain specified for the
+   account is used. If none is specified, the system looks for a value
+   in the domain, zone, and global configuration, in that order.
+
+-  
+
+   For a domain-specific network, the network domain specified for the
+   domain is used. If none is specified, the system looks for a value in
+   the zone and global configuration, in that order.
+
+-  
+
+   For a zone-specific network, the network domain specified for the
+   zone is used. If none is specified, the system looks for a value in
+   the global configuration.
+
+Stopping and Restarting the Management Server
+---------------------------------------------------
+
+The root administrator will need to stop and restart the Management
+Server from time to time.
+
+For example, after changing a global configuration parameter, a restart
+is required. If you have multiple Management Server nodes, restart all
+of them to put the new parameter value into effect consistently
+throughout the cloud..
+
+To stop the Management Server, issue the following command at the
+operating system prompt on the Management Server node:
+
+.. code:: bash
+
+    # service cloudstack-management stop
+
+To start the Management Server:
+
+.. code:: bash
+
+    # service cloudstack-management start
+
+To stop the Management Server:
+
+.. code:: bash
+
+    # service cloudstack-management stop
+


Mime
View raw message