You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by ke...@apache.org on 2014/01/28 03:23:29 UTC
[08/11] networking2.rst
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
+