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:30 UTC
[09/11] networking2.rst
http://git-wip-us.apache.org/repos/asf/cloudstack-docs-admin/blob/4bbce96f/source/administration.rst
----------------------------------------------------------------------
diff --git a/source/administration.rst b/source/administration.rst
index 33e32fd..eede610 100644
--- a/source/administration.rst
+++ b/source/administration.rst
@@ -13,350 +13,7 @@
specific language governing permissions and limitations
under the License.
-Managing Accounts, Users and Domains
-====================================
-Accounts, Users, and Domains
----------------------------------
-
-Accounts
-''''''''
-
-An account typically represents a customer of the service provider or a
-department in a large organization. Multiple users can exist in an
-account.
-
-Domains
-'''''''
-
-Accounts are grouped by domains. Domains usually contain multiple
-accounts that have some logical relationship to each other and a set of
-delegated administrators with some authority over the domain and its
-subdomains. For example, a service provider with several resellers could
-create a domain for each reseller.
-
-For each account created, the Cloud installation creates three different
-types of user accounts: root administrator, domain administrator, and
-user.
-
-Users
-'''''
-
-Users are like aliases in the account. Users in the same account are not
-isolated from each other, but they are isolated from users in other
-accounts. Most installations need not surface the notion of users; they
-just have one user per account. The same user cannot belong to multiple
-accounts.
-
-Username is unique in a domain across accounts in that domain. The same
-username can exist in other domains, including sub-domains. Domain name
-can repeat only if the full pathname from root is unique. For example,
-you can create root/d1, as well as root/foo/d1, and root/sales/d1.
-
-Administrators are accounts with special privileges in the system. There
-may be multiple administrators in the system. Administrators can create
-or delete other administrators, and change the password for any user in
-the system.
-
-Domain Administrators
-'''''''''''''''''''''
-
-Domain administrators can perform administrative operations for users
-who belong to that domain. Domain administrators do not have visibility
-into physical servers or other domains.
-
-Root Administrator
-''''''''''''''''''
-
-Root administrators have complete access to the system, including
-managing templates, service offerings, customer care administrators, and
-domains
-
-Resource Ownership
-''''''''''''''''''
-
-Resources belong to the account, not individual users in that account.
-For example, billing, resource limits, and so on are maintained by the
-account, not the users. A user can operate on any resource in the
-account provided the user has privileges for that operation. The
-privileges are determined by the role. A root administrator can change
-the ownership of any virtual machine from one account to any other
-account by using the assignVirtualMachine API. A domain or sub-domain
-administrator can do the same for VMs within the domain from one account
-to any other account in the domain or any of its sub-domains.
-
-Dedicating Resources to Accounts and Domains
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The root administrator can dedicate resources to a specific domain or
-account that needs private infrastructure for additional security or
-performance guarantees. A zone, pod, cluster, or host can be reserved by
-the root administrator for a specific domain or account. Only users in
-that domain or its subdomain may use the infrastructure. For example,
-only users in a given domain can create guests in a zone dedicated to
-that domain.
-
-There are several types of dedication available:
-
--
-
- Explicit dedication. A zone, pod, cluster, or host is dedicated to an
- account or domain by the root administrator during initial deployment
- and configuration.
-
--
-
- Strict implicit dedication. A host will not be shared across multiple
- accounts. For example, strict implicit dedication is useful for
- deployment of certain types of applications, such as desktops, where
- no host can be shared between different accounts without violating
- the desktop software's terms of license.
-
--
-
- Preferred implicit dedication. The VM will be deployed in dedicated
- infrastructure if possible. Otherwise, the VM can be deployed in
- shared infrastructure.
-
-How to Dedicate a Zone, Cluster, Pod, or Host to an Account or Domain
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-For explicit dedication: When deploying a new zone, pod, cluster, or
-host, the root administrator can click the Dedicated checkbox, then
-choose a domain or account to own the resource.
-
-To explicitly dedicate an existing zone, pod, cluster, or host: log in
-as the root admin, find the resource in the UI, and click the Dedicate
-button. |dedicate-resource-button.png: button to dedicate a zone, pod,
-cluster, or host|
-
-For implicit dedication: The administrator creates a compute service
-offering and in the Deployment Planner field, chooses
-ImplicitDedicationPlanner. Then in Planner Mode, the administrator
-specifies either Strict or Preferred, depending on whether it is
-permissible to allow some use of shared resources when dedicated
-resources are not available. Whenever a user creates a VM based on this
-service offering, it is allocated on one of the dedicated hosts.
-
-How to Use Dedicated Hosts
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To use an explicitly dedicated host, use the explicit-dedicated type of
-affinity group (see `Section 10.7.1, “Affinity
-Groups” <#affinity-groups>`__). For example, when creating a new VM, an
-end user can choose to place it on dedicated infrastructure. This
-operation will succeed only if some infrastructure has already been
-assigned as dedicated to the user's account or domain.
-
-Behavior of Dedicated Hosts, Clusters, Pods, and Zones
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The administrator can live migrate VMs away from dedicated hosts if
-desired, whether the destination is a host reserved for a different
-account/domain or a host that is shared (not dedicated to any particular
-account or domain). CloudStack will generate an alert, but the operation
-is allowed.
-
-Dedicated hosts can be used in conjunction with host tags. If both a
-host tag and dedication are requested, the VM will be placed only on a
-host that meets both requirements. If there is no dedicated resource
-available to that user that also has the host tag requested by the user,
-then the VM will not deploy.
-
-If you delete an account or domain, any hosts, clusters, pods, and zones
-that were dedicated to it are freed up. They will now be available to be
-shared by any account or domain, or the administrator may choose to
-re-dedicate them to a different account or domain.
-
-System VMs and virtual routers affect the behavior of host dedication.
-System VMs and virtual routers are owned by the CloudStack system
-account, and they can be deployed on any host. They do not adhere to
-explicit dedication. The presence of system vms and virtual routers on a
-host makes it unsuitable for strict implicit dedication. The host can
-not be used for strict implicit dedication, because the host already has
-VMs of a specific account (the default system account). However, a host
-with system VMs or virtual routers can be used for preferred implicit
-dedication.
-
-Using an LDAP Server for User Authentication
--------------------------------------------------
-
-You can use an external LDAP server such as Microsoft Active Directory
-or ApacheDS to authenticate CloudStack end-users. Just map CloudStack
-accounts to the corresponding LDAP accounts using a query filter. The
-query filter is written using the query syntax of the particular LDAP
-server, and can include special wildcard characters provided by
-CloudStack for matching common values such as the user’s email address
-and name. CloudStack will search the external LDAP directory tree
-starting at a specified base directory and return the distinguished name
-(DN) and password of the matching user. This information along with the
-given password is used to authenticate the user..
-
-To set up LDAP authentication in CloudStack, call the CloudStack API
-command ldapConfig and provide the following:
-
--
-
- Hostname or IP address and listening port of the LDAP server
-
--
-
- Base directory and query filter
-
--
-
- Search user DN credentials, which give CloudStack permission to
- search on the LDAP server
-
--
-
- SSL keystore and password, if SSL is used
-
-Example LDAP Configuration Commands
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To understand the examples in this section, you need to know the basic
-concepts behind calling the CloudStack API, which are explained in the
-Developer’s Guide.
-
-The following shows an example invocation of ldapConfig with an ApacheDS
-LDAP server
-
-.. code:: bash
-
- http://127.0.0.1:8080/client/api?command=ldapConfig&hostname=127.0.0.1&searchbase=ou%3Dtesting%2Co%3Dproject&queryfilter=%28%26%28uid%3D%25u%29%29&binddn=cn%3DJohn+Singh%2Cou%3Dtesting%2Co%project&bindpass=secret&port=10389&ssl=true&truststore=C%3A%2Fcompany%2Finfo%2Ftrusted.ks&truststorepass=secret&response=json&apiKey=YourAPIKey&signature=YourSignatureHash
-
-The command must be URL-encoded. Here is the same example without the
-URL encoding:
-
-.. code:: bash
-
- http://127.0.0.1:8080/client/api?command=ldapConfig
- &hostname=127.0.0.1
- &searchbase=ou=testing,o=project
- &queryfilter=(&(%uid=%u))
- &binddn=cn=John+Singh,ou=testing,o=project
- &bindpass=secret
- &port=10389
- &ssl=true
- &truststore=C:/company/info/trusted.ks
- &truststorepass=secret
- &response=json
- &apiKey=YourAPIKey&signature=YourSignatureHash
-
-The following shows a similar command for Active Directory. Here, the
-search base is the testing group within a company, and the users are
-matched up based on email address.
-
-.. code:: bash
-
- http://10.147.29.101:8080/client/api?command=ldapConfig&hostname=10.147.28.250&searchbase=OU%3Dtesting%2CDC%3Dcompany&queryfilter=%28%26%28mail%3D%25e%29%29 &binddn=CN%3DAdministrator%2COU%3Dtesting%2CDC%3Dcompany&bindpass=1111_aaaa&port=389&response=json&apiKey=YourAPIKey&signature=YourSignatureHash
-
-The next few sections explain some of the concepts you will need to know
-when filling out the ldapConfig parameters.
-
-Search Base
-~~~~~~~~~~~~~~~~~~
-
-An LDAP query is relative to a given node of the LDAP directory tree,
-called the search base. The search base is the distinguished name (DN)
-of a level of the directory tree below which all users can be found. The
-users can be in the immediate base directory or in some subdirectory.
-The search base may be equivalent to the organization, group, or domain
-name. The syntax for writing a DN varies depending on which LDAP server
-you are using. A full discussion of distinguished names is outside the
-scope of our documentation. The following table shows some examples of
-search bases to find users in the testing department..
-
-LDAP Server
-
-Example Search Base DN
-
-ApacheDS
-
-ou=testing,o=project
-
-Active Directory
-
-OU=testing, DC=company
-
-Query Filter
-~~~~~~~~~~~~~~~~~~~
-
-The query filter is used to find a mapped user in the external LDAP
-server. The query filter should uniquely map the CloudStack user to LDAP
-user for a meaningful authentication. For more information about query
-filter syntax, consult the documentation for your LDAP server.
-
-The CloudStack query filter wildcards are:
-
-Query Filter Wildcard
-
-Description
-
-%u
-
-User name
-
-%e
-
-Email address
-
-%n
-
-First and last name
-
-The following examples assume you are using Active Directory, and refer
-to user attributes from the Active Directory schema.
-
-If the CloudStack user name is the same as the LDAP user ID:
-
-.. code:: bash
-
- (uid=%u)
-
-If the CloudStack user name is the LDAP display name:
-
-.. code:: bash
-
- (displayName=%u)
-
-To find a user by email address:
-
-.. code:: bash
-
- (mail=%e)
-
-Search User Bind DN
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The bind DN is the user on the external LDAP server permitted to search
-the LDAP directory within the defined search base. When the DN is
-returned, the DN and passed password are used to authenticate the
-CloudStack user with an LDAP bind. A full discussion of bind DNs is
-outside the scope of our documentation. The following table shows some
-examples of bind DNs.
-
-LDAP Server
-
-Example Bind DN
-
-ApacheDS
-
-cn=Administrator,dc=testing,ou=project,ou=org
-
-Active Directory
-
-CN=Administrator, OU=testing, DC=company, DC=com
-
-SSL Keystore Path and Password
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If the LDAP server requires SSL, you need to enable it in the ldapConfig
-command by setting the parameters ssl, truststore, and truststorepass.
-Before enabling SSL for ldapConfig, you need to get the certificate
-which the LDAP server is using and add it to a trusted keystore. You
-will need to know the path to the keystore and the password.
User Services
=============
@@ -412,20070 +69,17 @@ CloudStack root administrator, and is used for configuring virtual
infrastructure resources. For more information, see Upgrading a Virtual
Router with System Service Offerings.
-User Interface
-==============
-
-Log In to the UI
----------------------
-
-CloudStack provides a web-based UI that can be used by both
-administrators and end users. The appropriate version of the UI is
-displayed depending on the credentials used to log in. The UI is
-available in popular browsers including IE7, IE8, IE9, Firefox 3.5+,
-Firefox 4, Safari 4, and Safari 5. The URL is: (substitute your own
-management server IP address)
-
-.. code:: bash
-
- http://<management-server-ip-address>:8080/client
-
-On a fresh Management Server installation, a guided tour splash screen
-appears. On later visits, you’ll see a login screen where you specify
-the following to proceed to your Dashboard:
-
-Username
-''''''''
-
-The user ID of your account. The default username is admin.
-
-Password
-''''''''
-
-The password associated with the user ID. The password for the default
-username is password.
-
-Domain
-''''''
-
-If you are a root user, leave this field blank.
-
-If you are a user in the sub-domains, enter the full path to the domain,
-excluding the root domain.
-
-For example, suppose multiple levels are created under the root domain,
-such as Comp1/hr. The users in the Comp1 domain should enter Comp1 in
-the Domain field, whereas the users in the Comp1/sales domain should
-enter Comp1/sales.
-
-For more guidance about the choices that appear when you log in to this
-UI, see Logging In as the Root Administrator.
-
-End User's UI Overview
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The CloudStack UI helps users of cloud infrastructure to view and use
-their cloud resources, including virtual machines, templates and ISOs,
-data volumes and snapshots, guest networks, and IP addresses. If the
-user is a member or administrator of one or more CloudStack projects,
-the UI can provide a project-oriented view.
-
-Root Administrator's UI Overview
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The CloudStack UI helps the CloudStack administrator provision, view,
-and manage the cloud infrastructure, domains, user accounts, projects,
-and configuration settings. The first time you start the UI after a
-fresh Management Server installation, you can choose to follow a guided
-tour to provision your cloud infrastructure. On subsequent logins, the
-dashboard of the logged-in user appears. The various links in this
-screen and the navigation bar on the left provide access to a variety of
-administrative functions. The root administrator can also use the UI to
-perform all the same tasks that are present in the end-user’s UI.
-
-Logging In as the Root Administrator
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-After the Management Server software is installed and running, you can
-run the CloudStack user interface. This UI is there to help you
-provision, view, and manage your cloud infrastructure.
-
-#.
-
- Open your favorite Web browser and go to this URL. Substitute the IP
- address of your own Management Server:
-
- .. code:: bash
-
- http://<management-server-ip-address>:8080/client
-
- After logging into a fresh Management Server installation, a guided
- tour splash screen appears. On later visits, you’ll be taken directly
- into the Dashboard.
-
-#.
-
- If you see the first-time splash screen, choose one of the following.
-
- -
-
- **Continue with basic setup.** Choose this if you're just trying
- CloudStack, and you want a guided walkthrough of the simplest
- possible configuration so that you can get started right away.
- We'll help you set up a cloud with the following features: a
- single machine that runs CloudStack software and uses NFS to
- provide storage; a single machine running VMs under the XenServer
- or KVM hypervisor; and a shared public network.
-
- The prompts in this guided tour should give you all the
- information you need, but if you want just a bit more detail, you
- can follow along in the Trial Installation Guide.
-
- -
-
- **I have used CloudStack before.** Choose this if you have already
- gone through a design phase and planned a more sophisticated
- deployment, or you are ready to start scaling up a trial cloud
- that you set up earlier with the basic setup screens. In the
- Administrator UI, you can start using the more powerful features
- of CloudStack, such as advanced VLAN networking, high
- availability, additional network elements such as load balancers
- and firewalls, and support for multiple hypervisors including
- Citrix XenServer, KVM, and VMware vSphere.
-
- The root administrator Dashboard appears.
-
-#.
-
- You should set a new root administrator password. If you chose basic
- setup, you’ll be prompted to create a new password right away. If you
- chose experienced user, use the steps in `Section 5.1.4, “Changing
- the Root Password” <#changing-root-password>`__.
-
-.. warning:: You are logging in as the root administrator. This account manages the
-CloudStack deployment, including physical infrastructure. The root
-administrator can modify configuration settings to change basic
-functionality, create or delete user accounts, and take many actions
-that should be performed only by an authorized person. Please change the
-default password to a new, unique password.
-
-Changing the Root Password
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-During installation and ongoing cloud administration, you will need to
-log in to the UI as the root administrator. The root administrator
-account manages the CloudStack deployment, including physical
-infrastructure. The root administrator can modify configuration settings
-to change basic functionality, create or delete user accounts, and take
-many actions that should be performed only by an authorized person. When
-first installing CloudStack, be sure to change the default password to a
-new, unique value.
-
-#.
-
- Open your favorite Web browser and go to this URL. Substitute the IP
- address of your own Management Server:
-
- .. code:: bash
-
- http://<management-server-ip-address>:8080/client
-
-#.
-
- Log in to the UI using the current root user ID and password. The
- default is admin, password.
-
-#.
-
- Click Accounts.
-
-#.
-
- Click the admin account name.
-
-#.
-
- Click View Users.
-
-#.
-
- Click the admin user name.
-
-#.
-
- Click the Change Password button. |change-password.png: button to
- change a user's password|
-
-#.
-
- Type the new password, and click OK.
-
-Using SSH Keys for Authentication
---------------------------------------
-
-In addition to the username and password authentication, CloudStack
-supports using SSH keys to log in to the cloud infrastructure for
-additional security. You can use the createSSHKeyPair API to generate
-the SSH keys.
-
-Because each cloud user has their own SSH key, one cloud user cannot log
-in to another cloud user's instances unless they share their SSH key
-files. Using a single SSH key pair, you can manage multiple instances.
-
-Creating an Instance Template that Supports SSH Keys
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Create a instance template that supports SSH Keys.
-
-#.
-
- Create a new instance by using the template provided by cloudstack.
-
- For more information on creating a new instance, see
-
-#.
-
- Download the cloudstack script from `The SSH Key Gen
- Script <http://sourceforge.net/projects/cloudstack/files/SSH%20Key%20Gen%20Script/>`__\ to
- the instance you have created.
-
- .. code:: bash
-
- wget http://downloads.sourceforge.net/project/cloudstack/SSH%20Key%20Gen%20Script/cloud-set-guest-sshkey.in?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcloudstack%2Ffiles%2FSSH%2520Key%2520Gen%2520Script%2F&ts=1331225219&use_mirror=iweb
-
-#.
-
- Copy the file to /etc/init.d.
-
- .. code:: bash
-
- cp cloud-set-guest-sshkey.in /etc/init.d/
-
-#.
-
- Give the necessary permissions on the script:
-
- .. code:: bash
-
- chmod +x /etc/init.d/cloud-set-guest-sshkey.in
-
-#.
-
- Run the script while starting up the operating system:
-
- .. code:: bash
-
- chkconfig --add cloud-set-guest-sshkey.in
-
-#.
-
- Stop the instance.
-
-Creating the SSH Keypair
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You must make a call to the createSSHKeyPair api method. You can either
-use the CloudStack Python API library or the curl commands to make the
-call to the cloudstack api.
-
-For example, make a call from the cloudstack server to create a SSH
-keypair called "keypair-doc" for the admin account in the root domain:
-
-.. note:: Ensure that you adjust these values to meet your needs. If you are
-making the API call from a different server, your URL/PORT will be
-different, and you will need to use the API keys.
-
-#.
-
- Run the following curl command:
-
- .. code:: bash
-
- curl --globoff "http://localhost:8096/?command=createSSHKeyPair&name=keypair-doc&account=admin&domainid=5163440e-c44b-42b5-9109-ad75cae8e8a2"
-
- The output is something similar to what is given below:
-
- .. code:: bash
-
- <?xml version="1.0" encoding="ISO-8859-1"?><createsshkeypairresponse cloud-stack-version="3.0.0.20120228045507"><keypair><name>keypair-doc</name><fingerprint>f6:77:39:d5:5e:77:02:22:6a:d8:7f:ce:ab:cd:b3:56</fingerprint><privatekey>-----BEGIN RSA PRIVATE KEY-----
- MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
- dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
- AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
- mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
- QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
- VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
- lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
- nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
- 4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
- KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
- -----END RSA PRIVATE KEY-----
- </privatekey></keypair></createsshkeypairresponse>
-
-#.
-
- Copy the key data into a file. The file looks like this:
-
- .. code:: bash
-
- -----BEGIN RSA PRIVATE KEY-----
- MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
- dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
- AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
- mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
- QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
- VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
- lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
- nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
- 4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
- KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
- -----END RSA PRIVATE KEY-----
-
-#.
-
- Save the file.
-
-Creating an Instance
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-After you save the SSH keypair file, you must create an instance by
-using the template that you created at `Section 5.2.1, “ Creating an
-Instance Template that Supports SSH Keys” <#create-ssh-template>`__.
-Ensure that you use the same SSH key name that you created at
-`Section 5.2.2, “Creating the SSH Keypair” <#create-ssh-keypair>`__.
-
-.. note:: You cannot create the instance by using the GUI at this time and
-associate the instance with the newly created SSH keypair.
-
-A sample curl command to create a new instance is:
-
-.. code:: bash
-
- curl --globoff http://localhost:<port number>/?command=deployVirtualMachine\&zoneId=1\&serviceOfferingId=18727021-7556-4110-9322-d625b52e0813\&templateId=e899c18a-ce13-4bbf-98a9-625c5026e0b5\&securitygroupids=ff03f02f-9e3b-48f8-834d-91b822da40c5\&account=admin\&domainid=1\&keypair=keypair-doc
-
-Substitute the template, service offering and security group IDs (if you
-are using the security group feature) that are in your cloud
-environment.
-
-Logging In Using the SSH Keypair
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To test your SSH key generation is successful, check whether you can log
-in to the cloud setup.
-
-For exaple, from a Linux OS, run:
-
-.. code:: bash
-
- ssh -i ~/.ssh/keypair-doc <ip address>
-
-The -i parameter tells the ssh client to use a ssh key found at
-~/.ssh/keypair-doc.
-
-5.2.5. Resetting SSH Keys
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-With the API command resetSSHKeyForVirtualMachine, a user can set or
-reset the SSH keypair assigned to a virtual machine. A lost or
-compromised SSH keypair can be changed, and the user can access the VM
-by using the new keypair. Just create or register a new keypair, then
-call resetSSHKeyForVirtualMachine.
-
-Using Projects to Organize Users and Resources
-==============================================
-
-Overview of Projects
--------------------------
-
-Projects are used to organize people and resources. CloudStack users
-within a single domain can group themselves into project teams so they
-can collaborate and share virtual resources such as VMs, snapshots,
-templates, data disks, and IP addresses. CloudStack tracks resource
-usage per project as well as per user, so the usage can be billed to
-either a user account or a project. For example, a private cloud within
-a software company might have all members of the QA department assigned
-to one project, so the company can track the resources used in testing
-while the project members can more easily isolate their efforts from
-other users of the same cloud
-
-You can configure CloudStack to allow any user to create a new project,
-or you can restrict that ability to just CloudStack administrators. Once
-you have created a project, you become that project’s administrator, and
-you can add others within your domain to the project. CloudStack can be
-set up either so that you can add people directly to a project, or so
-that you have to send an invitation which the recipient must accept.
-Project members can view and manage all virtual resources created by
-anyone in the project (for example, share VMs). A user can be a member
-of any number of projects and can switch views in the CloudStack UI to
-show only project-related information, such as project VMs, fellow
-project members, project-related alerts, and so on.
-
-The project administrator can pass on the role to another project
-member. The project administrator can also add more members, remove
-members from the project, set new resource limits (as long as they are
-below the global defaults set by the CloudStack administrator), and
-delete the project. When the administrator removes a member from the
-project, resources created by that user, such as VM instances, remain
-with the project. This brings us to the subject of resource ownership
-and which resources can be used by a project.
-
-Resources created within a project are owned by the project, not by any
-particular CloudStack account, and they can be used only within the
-project. A user who belongs to one or more projects can still create
-resources outside of those projects, and those resources belong to the
-user’s account; they will not be counted against the project’s usage or
-resource limits. You can create project-level networks to isolate
-traffic within the project and provide network services such as port
-forwarding, load balancing, VPN, and static NAT. A project can also make
-use of certain types of resources from outside the project, if those
-resources are shared. For example, a shared network or public template
-is available to any project in the domain. A project can get access to a
-private template if the template’s owner will grant permission. A
-project can use any service offering or disk offering available in its
-domain; however, you can not create private service and disk offerings
-at the project level..
-
-Configuring Projects
--------------------------
-
-Before CloudStack users start using projects, the CloudStack
-administrator must set up various systems to support them, including
-membership invitations, limits on project resources, and controls on who
-can create projects.
-
-Setting Up Invitations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-CloudStack can be set up either so that project administrators can add
-people directly to a project, or so that it is necessary to send an
-invitation which the recipient must accept. The invitation can be sent
-by email or through the user’s CloudStack account. If you want
-administrators to use invitations to add members to projects, turn on
-and set up the invitations feature in CloudStack.
-
-#.
-
- Log in as administrator to the CloudStack UI.
-
-#.
-
- In the left navigation, click Global Settings.
-
-#.
-
- In the search box, type project and click the search button.
- |searchbutton.png: Searches projects|
-
-#.
-
- In the search results, you can see a few other parameters you need to
- set to control how invitations behave. The table below shows global
- configuration parameters related to project invitations. Click the
- edit button to set each parameter.
-
- Configuration Parameters
-
- Description
-
- project.invite.required
-
- Set to true to turn on the invitations feature.
-
- project.email.sender
-
- The email address to show in the From field of invitation emails.
-
- project.invite.timeout
-
- Amount of time to allow for a new member to respond to the
- invitation.
-
- project.smtp.host
-
- Name of the host that acts as an email server to handle invitations.
-
- project.smtp.password
-
- (Optional) Password required by the SMTP server. You must also set
- project.smtp.username and set project.smtp.useAuth to true.
-
- project.smtp.port
-
- SMTP server’s listening port.
-
- project.smtp.useAuth
-
- Set to true if the SMTP server requires a username and password.
-
- project.smtp.username
-
- (Optional) User name required by the SMTP server for authentication.
- You must also set project.smtp.password and set project.smtp.useAuth
- to true..
-
-#.
-
- Restart the Management Server:
-
- .. code:: bash
-
- service cloudstack-management restart
-
-Setting Resource Limits for Projects
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The CloudStack administrator can set global default limits to control
-the amount of resources that can be owned by each project in the cloud.
-This serves to prevent uncontrolled usage of resources such as
-snapshots, IP addresses, and virtual machine instances. Domain
-administrators can override these resource limits for individual
-projects with their domains, as long as the new limits are below the
-global defaults set by the CloudStack root administrator. The root
-administrator can also set lower resource limits for any project in the
-cloud
-
-Setting Per-Project Resource Limits
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The CloudStack root administrator or the domain administrator of the
-domain where the project resides can set new resource limits for an
-individual project. The project owner can set resource limits only if
-the owner is also a domain or root administrator.
-
-The new limits must be below the global default limits set by the
-CloudStack administrator (as described in `Section 6.2.2, “Setting
-Resource Limits for Projects” <#set-resource-limits-for-projects>`__).
-If the project already owns more of a given type of resource than the
-new maximum, the resources are not affected; however, the project can
-not add any new resources of that type until the total drops below the
-new limit.
-
-#.
-
- Log in as administrator to the CloudStack UI.
-
-#.
-
- In the left navigation, click Projects.
-
-#.
-
- In Select View, choose Projects.
-
-#.
-
- Click the name of the project you want to work with.
-
-#.
-
- Click the Resources tab. This tab lists the current maximum amount
- that the project is allowed to own for each type of resource.
-
-#.
-
- Type new values for one or more resources.
-
-#.
-
- Click Apply.
-
-Setting the Global Project Resource Limits
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-#.
-
- Log in as administrator to the CloudStack UI.
-
-#.
-
- In the left navigation, click Global Settings.
-
-#.
-
- In the search box, type max.projects and click the search button.
-
-#.
-
- In the search results, you will see the parameters you can use to set
- per-project maximum resource amounts that apply to all projects in
- the cloud. No project can have more resources, but an individual
- project can have lower limits. Click the edit button to set each
- parameter. |editbutton.png: Edits parameters|
-
- max.project.public.ips
-
- Maximum number of public IP addresses that can be owned by any
- project in the cloud. See About Public IP Addresses.
-
- max.project.snapshots
-
- Maximum number of snapshots that can be owned by any project in the
- cloud. See Working with Snapshots.
-
- max.project.templates
-
- Maximum number of templates that can be owned by any project in the
- cloud. See Working with Templates.
-
- max.project.uservms
-
- Maximum number of guest virtual machines that can be owned by any
- project in the cloud. See Working With Virtual Machines.
-
- max.project.volumes
-
- Maximum number of data volumes that can be owned by any project in
- the cloud. See Working with Volumes.
-
-#.
-
- Restart the Management Server.
-
- .. code:: bash
-
- # service cloudstack-management restart
-
-Setting Project Creator Permissions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-You can configure CloudStack to allow any user to create a new project,
-or you can restrict that ability to just CloudStack administrators.
-
-#.
-
- Log in as administrator to the CloudStack UI.
-
-#.
-
- In the left navigation, click Global Settings.
-
-#.
-
- In the search box, type allow.user.create.projects.
-
-#.
-
- Click the edit button to set the parameter. |editbutton.png: Edits
- parameters|
-
- allow.user.create.projects
-
- Set to true to allow end users to create projects. Set to false if
- you want only the CloudStack root administrator and domain
- administrators to create projects.
-
-#.
-
- Restart the Management Server.
-
- .. code:: bash
-
- # service cloudstack-management restart
-
-Creating a New Project
----------------------------
-
-CloudStack administrators and domain administrators can create projects.
-If the global configuration parameter allow.user.create.projects is set
-to true, end users can also create projects.
-
-#.
-
- Log in as administrator to the CloudStack UI.
-
-#.
-
- In the left navigation, click Projects.
-
-#.
-
- In Select view, click Projects.
-
-#.
-
- Click New Project.
-
-#.
-
- Give the project a name and description for display to users, then
- click Create Project.
-
-#.
-
- A screen appears where you can immediately add more members to the
- project. This is optional. Click Next when you are ready to move on.
-
-#.
-
- Click Save.
-
-Adding Members to a Project
---------------------------------
-
-New members can be added to a project by the project’s administrator,
-the domain administrator of the domain where the project resides or any
-parent domain, or the CloudStack root administrator. There are two ways
-to add members in CloudStack, but only one way is enabled at a time:
-
--
-
- If invitations have been enabled, you can send invitations to new
- members.
-
--
-
- If invitations are not enabled, you can add members directly through
- the UI.
-
-Sending Project Membership Invitations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Use these steps to add a new member to a project if the invitations
-feature is enabled in the cloud as described in `Section 6.2.1, “Setting
-Up Invitations” <#set-up-invitations>`__. If the invitations feature is
-not turned on, use the procedure in Adding Project Members From the UI.
-
-#.
-
- Log in to the CloudStack UI.
-
-#.
-
- In the left navigation, click Projects.
-
-#.
-
- In Select View, choose Projects.
-
-#.
-
- Click the name of the project you want to work with.
-
-#.
-
- Click the Invitations tab.
-
-#.
-
- In Add by, select one of the following:
-
- #.
-
- Account – The invitation will appear in the user’s Invitations tab
- in the Project View. See Using the Project View.
-
- #.
-
- Email – The invitation will be sent to the user’s email address.
- Each emailed invitation includes a unique code called a token
- which the recipient will provide back to CloudStack when accepting
- the invitation. Email invitations will work only if the global
- parameters related to the SMTP server have been set. See
- `Section 6.2.1, “Setting Up Invitations” <#set-up-invitations>`__.
-
-#.
-
- Type the user name or email address of the new member you want to
- add, and click Invite. Type the CloudStack user name if you chose
- Account in the previous step. If you chose Email, type the email
- address. You can invite only people who have an account in this cloud
- within the same domain as the project. However, you can send the
- invitation to any email address.
-
-#.
-
- To view and manage the invitations you have sent, return to this tab.
- When an invitation is accepted, the new member will appear in the
- project’s Accounts tab.
-
-Adding Project Members From the UI
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The steps below tell how to add a new member to a project if the
-invitations feature is not enabled in the cloud. If the invitations
-feature is enabled cloud,as described in `Section 6.2.1, “Setting Up
-Invitations” <#set-up-invitations>`__, use the procedure in
-`Section 6.4.1, “Sending Project Membership
-Invitations” <#send-projects-membership-invitation>`__.
-
-#.
-
- Log in to the CloudStack UI.
-
-#.
-
- In the left navigation, click Projects.
-
-#.
-
- In Select View, choose Projects.
-
-#.
-
- Click the name of the project you want to work with.
-
-#.
-
- Click the Accounts tab. The current members of the project are
- listed.
-
-#.
-
- Type the account name of the new member you want to add, and click
- Add Account. You can add only people who have an account in this
- cloud and within the same domain as the project.
-
-Accepting a Membership Invitation
---------------------------------------
-
-If you have received an invitation to join a CloudStack project, and you
-want to accept the invitation, follow these steps:
-
-#.
-
- Log in to the CloudStack UI.
-
-#.
-
- In the left navigation, click Projects.
-
-#.
-
- In Select View, choose Invitations.
-
-#.
-
- If you see the invitation listed onscreen, click the Accept button.
-
- Invitations listed on screen were sent to you using your CloudStack
- account name.
-
-#.
-
- If you received an email invitation, click the Enter Token button,
- and provide the project ID and unique ID code (token) from the email.
-
-Suspending or Deleting a Project
--------------------------------------
-
-When a project is suspended, it retains the resources it owns, but they
-can no longer be used. No new resources or members can be added to a
-suspended project.
-
-When a project is deleted, its resources are destroyed, and member
-accounts are removed from the project. The project’s status is shown as
-Disabled pending final deletion.
-
-A project can be suspended or deleted by the project administrator, the
-domain administrator of the domain the project belongs to or of its
-parent domain, or the CloudStack root administrator.
-
-#.
-
- Log in to the CloudStack UI.
-
-#.
-
- In the left navigation, click Projects.
-
-#.
-
- In Select View, choose Projects.
-
-#.
-
- Click the name of the project.
-
-#.
-
- Click one of the buttons:
-
- To delete, use |deletebutton.png: Removes a project|
-
- To suspend, use |deletebutton.png: suspends a project|
-
-Using the Project View
----------------------------
-
-If you are a member of a project, you can use CloudStack’s project view
-to see project members, resources consumed, and more. The project view
-shows only information related to one project. It is a useful way to
-filter out other information so you can concentrate on a project status
-and resources.
-
-#.
-
- Log in to the CloudStack UI.
-
-#.
-
- Click Project View.
-
-#.
-
- The project dashboard appears, showing the project’s VMs, volumes,
- users, events, network settings, and more. From the dashboard, you
- can:
-
- -
-
- Click the Accounts tab to view and manage project members. If you
- are the project administrator, you can add new members, remove
- members, or change the role of a member from user to admin. Only
- one member at a time can have the admin role, so if you set
- another user’s role to admin, your role will change to regular
- user.
-
- -
-
- (If invitations are enabled) Click the Invitations tab to view and
- manage invitations that have been sent to new project members but
- not yet accepted. Pending invitations will remain in this list
- until the new member accepts, the invitation timeout is reached,
- or you cancel the invitation.
-
-Steps to Provision your Cloud Infrastructure
-============================================
-
-This section tells how to add regions, zones, pods, clusters, hosts,
-storage, and networks to your cloud. If you are unfamiliar with these
-entities, please begin by looking through `Chapter 2, *Cloud
-Infrastructure Concepts* <#cloud-infrastructure-concepts>`__.
-
-Overview of Provisioning Steps
------------------------------------
-
-After the Management Server is installed and running, you can add the
-compute resources for it to manage. For an overview of how a CloudStack
-cloud infrastructure is organized, see `Section 1.3.2, “Cloud
-Infrastructure Overview” <#cloud-infrastructure-overview>`__.
-
-To provision the cloud infrastructure, or to scale it up at any time,
-follow these procedures:
-
-#.
-
- Define regions (optional). See `Section 7.2, “Adding Regions
- (optional)” <#region-add>`__.
-
-#.
-
- Add a zone to the region. See `Section 7.3, “Adding a
- Zone” <#zone-add>`__.
-
-#.
-
- Add more pods to the zone (optional). See `Section 7.4, “Adding a
- Pod” <#pod-add>`__.
-
-#.
-
- Add more clusters to the pod (optional). See `Section 7.5, “Adding a
- Cluster” <#cluster-add>`__.
-
-#.
-
- Add more hosts to the cluster (optional). See `Section 7.6, “Adding a
- Host” <#host-add>`__.
-
-#.
-
- Add primary storage to the cluster. See `Section 7.7, “Add Primary
- Storage” <#primary-storage-add>`__.
-
-#.
-
- Add secondary storage to the zone. See `Section 7.8, “Add Secondary
- Storage” <#secondary-storage-add>`__.
-
-#.
-
- Initialize and test the new cloud. See `Section 7.9, “Initialize and
- Test” <#initialize-and-test>`__.
-
-When you have finished these steps, you will have a deployment with the
-following basic structure:
-
-|provisioning-overview.png: Conceptual overview of a basic deployment|
-
-Adding Regions (optional)
-------------------------------
-
-Grouping your cloud resources into geographic regions is an optional
-step when provisioning the cloud. For an overview of regions, see
-`Section 2.1, “About Regions” <#about-regions>`__.
-
-The First Region: The Default Region
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you do not take action to define regions, then all the zones in your
-cloud will be automatically grouped into a single default region. This
-region is assigned the region ID of 1. You can change the name or URL of
-the default region by displaying the region in the CloudStack UI and
-clicking the Edit button.
-
-Adding a Region
-~~~~~~~~~~~~~~~~~~~~~~
-
-Use these steps to add a second region in addition to the default
-region.
-
-#.
-
- Each region has its own CloudStack instance. Therefore, the first
- step of creating a new region is to install the Management Server
- software, on one or more nodes, in the geographic area where you want
- to set up the new region. Use the steps in the Installation guide.
- When you come to the step where you set up the database, use the
- additional command-line flag ``-r <region_id>`` to set a region ID
- for the new region. The default region is automatically assigned a
- region ID of 1, so your first additional region might be region 2.
-
- .. code:: bash
-
- cloudstack-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m <management_server_key> -k <database_key> -r <region_id>
-
-#.
-
- By the end of the installation procedure, the Management Server
- should have been started. Be sure that the Management Server
- installation was successful and complete.
-
-#.
-
- Now add the new region to region 1 in CloudStack.
-
- #.
-
- Log in to CloudStack in the first region as root administrator
- (that is, log in to <region.1.IP.address>:8080/client).
-
- #.
-
- In the left navigation bar, click Regions.
-
- #.
-
- Click Add Region. In the dialog, fill in the following fields:
-
- -
-
- ID. A unique identifying number. Use the same number you set in
- the database during Management Server installation in the new
- region; for example, 2.
-
- -
-
- Name. Give the new region a descriptive name.
-
- -
-
- Endpoint. The URL where you can log in to the Management Server
- in the new region. This has the format
- <region.2.IP.address>:8080/client.
-
-#.
-
- Now perform the same procedure in reverse. Log in to region 2, and
- add region 1.
-
-#.
-
- Copy the account, user, and domain tables from the region 1 database
- to the region 2 database.
-
- In the following commands, it is assumed that you have set the root
- password on the database, which is a CloudStack recommended best
- practice. Substitute your own MySQL root password.
-
- #.
-
- First, run this command to copy the contents of the database:
-
- .. code:: bash
-
- # mysqldump -u root -p<mysql_password> -h <region1_db_host> cloud account user domain > region1.sql
-
- #.
-
- Then run this command to put the data onto the region 2 database:
-
- .. code:: bash
-
- # mysql -u root -p<mysql_password> -h <region2_db_host> cloud < region1.sql
-
-#.
-
- Remove project accounts. Run these commands on the region 2 database:
-
- .. code:: bash
-
- mysql> delete from account where type = 5;
-
-#.
-
- Set the default zone as null:
-
- .. code:: bash
-
- mysql> update account set default_zone_id = null;
-
-#.
-
- Restart the Management Servers in region 2.
-
-Adding Third and Subsequent Regions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To add the third region, and subsequent additional regions, the steps
-are similar to those for adding the second region. However, you must
-repeat certain steps additional times for each additional region:
-
-#.
-
- Install CloudStack in each additional region. Set the region ID for
- each region during the database setup step.
-
- .. code:: bash
-
- cloudstack-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m <management_server_key> -k <database_key> -r <region_id>
-
-#.
-
- Once the Management Server is running, add your new region to all
- existing regions by repeatedly using the Add Region button in the UI.
- For example, if you were adding region 3:
-
- #.
-
- Log in to CloudStack in the first region as root administrator
- (that is, log in to <region.1.IP.address>:8080/client), and add a
- region with ID 3, the name of region 3, and the endpoint
- <region.3.IP.address>:8080/client.
-
- #.
-
- Log in to CloudStack in the second region as root administrator
- (that is, log in to <region.2.IP.address>:8080/client), and add a
- region with ID 3, the name of region 3, and the endpoint
- <region.3.IP.address>:8080/client.
-
-#.
-
- Repeat the procedure in reverse to add all existing regions to the
- new region. For example, for the third region, add the other two
- existing regions:
-
- #.
-
- Log in to CloudStack in the third region as root administrator
- (that is, log in to <region.3.IP.address>:8080/client).
-
- #.
-
- Add a region with ID 1, the name of region 1, and the endpoint
- <region.1.IP.address>:8080/client.
-
- #.
-
- Add a region with ID 2, the name of region 2, and the endpoint
- <region.2.IP.address>:8080/client.
-
-#.
-
- Copy the account, user, and domain tables from any existing region's
- database to the new region's database.
-
- In the following commands, it is assumed that you have set the root
- password on the database, which is a CloudStack recommended best
- practice. Substitute your own MySQL root password.
-
- #.
-
- First, run this command to copy the contents of the database:
-
- .. code:: bash
-
- # mysqldump -u root -p<mysql_password> -h <region1_db_host> cloud account user domain > region1.sql
-
- #.
-
- Then run this command to put the data onto the new region's
- database. For example, for region 3:
-
- .. code:: bash
-
- # mysql -u root -p<mysql_password> -h <region3_db_host> cloud < region1.sql
-
-#.
-
- Remove project accounts. Run these commands on the region 3 database:
-
- .. code:: bash
-
- mysql> delete from account where type = 5;
-
-#.
-
- Set the default zone as null:
-
- .. code:: bash
-
- mysql> update account set default_zone_id = null;
-
-#.
-
- Restart the Management Servers in the new region.
-
-Deleting a Region
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Log in to each of the other regions, navigate to the one you want to
-delete, and click Remove Region. For example, to remove the third region
-in a 3-region cloud:
-
-#.
-
- Log in to <region.1.IP.address>:8080/client.
-
-#.
-
- In the left navigation bar, click Regions.
-
-#.
-
- Click the name of the region you want to delete.
-
-#.
-
- Click the Remove Region button.
-
-#.
-
- Repeat these steps for <region.2.IP.address>:8080/client.
-
-Adding a Zone
-------------------
-
-When you add a new zone, you will be prompted to configure the zone’s
-physical network and add the first pod, cluster, host, primary storage,
-and secondary storage.
-
-#.
-
- Log in to the CloudStack UI as the root administrator. See
- `Section 5.1, “Log In to the UI” <#log-in>`__.
-
-#.
-
- In the left navigation, choose Infrastructure.
-
-#.
-
- On Zones, click View More.
-
-#.
-
- Click Add Zone. The zone creation wizard will appear.
-
-#.
-
- Choose one of the following network types:
-
- -
-
- **Basic.** For AWS-style networking. Provides a single network
- where each VM instance is assigned an IP directly from the
- network. Guest isolation can be provided through layer-3 means
- such as security groups (IP address source filtering).
-
- -
-
- **Advanced.** For more sophisticated network topologies. This
- network model provides the most flexibility in defining guest
- networks and providing custom network offerings such as firewall,
- VPN, or load balancer support.
-
-#.
-
- The rest of the steps differ depending on whether you chose Basic or
- Advanced. Continue with the steps that apply to you:
-
- -
-
- `Section 7.3.1, “Basic Zone
- Configuration” <#basic-zone-configuration>`__
-
- -
-
- `Section 7.3.2, “Advanced Zone
- Configuration” <#advanced-zone-configuration>`__
-
-Basic Zone Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-#.
-
- After you select Basic in the Add Zone wizard and click Next, you
- will be asked to enter the following details. Then click Next.
-
- -
-
- **Name.** A name for the zone.
-
- -
-
- **DNS 1 and 2.** These are DNS servers for use by guest VMs in the
- zone. These DNS servers will be accessed via the public network
- you will add later. The public IP addresses for the zone must have
- a route to the DNS server named here.
-
- -
-
- **Internal DNS 1 and Internal DNS 2.** These are DNS servers for
- use by system VMs in the zone (these are VMs used by CloudStack
- itself, such as virtual routers, console proxies, and Secondary
- Storage VMs.) These DNS servers will be accessed via the
- management traffic network interface of the System VMs. The
- private IP address you provide for the pods must have a route to
- the internal DNS server named here.
-
- -
-
- **Hypervisor.** (Introduced in version 3.0.1) Choose the
- hypervisor for the first cluster in the zone. You can add clusters
- with different hypervisors later, after you finish adding the
- zone.
-
- -
-
- **Network Offering.** Your choice here determines what network
- services will be available on the network for guest VMs.
-
- Network Offering
-
- Description
-
- DefaultSharedNetworkOfferingWithSGService
-
- If you want to enable security groups for guest traffic isolation,
- choose this. (See Using Security Groups to Control Traffic to
- VMs.)
-
- DefaultSharedNetworkOffering
-
- If you do not need security groups, choose this.
-
- DefaultSharedNetscalerEIPandELBNetworkOffering
-
- If you have installed a Citrix NetScaler appliance as part of your
- zone network, and you will be using its Elastic IP and Elastic
- Load Balancing features, choose this. With the EIP and ELB
- features, a basic zone with security groups enabled can offer 1:1
- static NAT and load balancing.
-
- -
-
- **Network Domain.** (Optional) If you want to assign a special
- domain name to the guest VM network, specify the DNS suffix.
-
- -
-
- **Public.** A public zone is available to all users. A zone that
- is not public will be assigned to a particular domain. Only users
- in that domain will be allowed to create guest VMs in this zone.
-
-#.
-
- Choose which traffic types will be carried by the physical network.
-
- The traffic types are management, public, guest, and storage traffic.
- For more information about the types, roll over the icons to display
- their tool tips, or see Basic Zone Network Traffic Types. This screen
- starts out with some traffic types already assigned. To add more,
- drag and drop traffic types onto the network. You can also change the
- network name if desired.
-
-#.
-
- Assign a network traffic label to each traffic type on the physical
- network. These labels must match the labels you have already defined
- on the hypervisor host. To assign each label, click the Edit button
- under the traffic type icon. A popup dialog appears where you can
- type the label, then click OK.
-
- These traffic labels will be defined only for the hypervisor selected
- for the first cluster. For all other hypervisors, the labels can be
- configured after the zone is created.
-
-#.
-
- Click Next.
-
-#.
-
- (NetScaler only) If you chose the network offering for NetScaler, you
- have an additional screen to fill out. Provide the requested details
- to set up the NetScaler, then click Next.
-
- -
-
- **IP address.** The NSIP (NetScaler IP) address of the NetScaler
- device.
-
- -
-
- **Username/Password.** The authentication credentials to access
- the device. CloudStack uses these credentials to access the
- device.
-
- -
-
- **Type.** NetScaler device type that is being added. It could be
- NetScaler VPX, NetScaler MPX, or NetScaler SDX. For a comparison
- of the types, see About Using a NetScaler Load Balancer.
-
- -
-
- **Public interface.** Interface of NetScaler that is configured to
- be part of the public network.
-
- -
-
- **Private interface.** Interface of NetScaler that is configured
- to be part of the private network.
-
- -
-
- **Number of retries.** Number of times to attempt a command on the
- device before considering the operation failed. Default is 2.
-
- -
-
- **Capacity.** Number of guest networks/accounts that will share
- this NetScaler device.
-
- -
-
- **Dedicated.** When marked as dedicated, this device will be
- dedicated to a single account. When Dedicated is checked, the
- value in the Capacity field has no significance – implicitly, its
- value is 1.
-
-#.
-
- (NetScaler only) Configure the IP range for public traffic. The IPs
- in this range will be used for the static NAT capability which you
- enabled by selecting the network offering for NetScaler with EIP and
- ELB. Enter the following details, then click Add. If desired, you can
- repeat this step to add more IP ranges. When done, click Next.
-
- -
-
- **Gateway.** The gateway in use for these IP addresses.
-
- -
-
- **Netmask.** The netmask associated with this IP range.
-
- -
-
- **VLAN.** The VLAN that will be used for public traffic.
-
- -
-
- **Start IP/End IP.** A range of IP addresses that are assumed to
- be accessible from the Internet and will be allocated for access
- to guest VMs.
-
-#.
-
- In a new zone, CloudStack adds the first pod for you. You can always
- add more pods later. For an overview of what a pod is, see
- `Section 2.3, “About Pods” <#about-pods>`__.
-
- To configure the first pod, enter the following, then click Next:
-
- -
-
- **Pod Name.** A name for the pod.
-
- -
-
- **Reserved system gateway.** The gateway for the hosts in that
- pod.
-
- -
-
- **Reserved system netmask.** The network prefix that defines the
- pod's subnet. Use CIDR notation.
-
- -
-
- **Start/End Reserved System IP.** The IP range in the management
- network that CloudStack uses to manage various system VMs, such as
- Secondary Storage VMs, Console Proxy VMs, and DHCP. For more
- information, see System Reserved IP Addresses.
-
-#.
-
- Configure the network for guest traffic. Provide the following, then
- click Next:
-
- -
-
- **Guest gateway.** The gateway that the guests should use.
-
- -
-
- **Guest netmask.** The netmask in use on the subnet the guests
- will use.
-
- -
-
- **Guest start IP/End IP.** Enter the first and last IP addresses
- that define a range that CloudStack can assign to guests.
-
- -
-
- We strongly recommend the use of multiple NICs. If multiple
- NICs are used, they may be in a different subnet.
-
- -
-
- If one NIC is used, these IPs should be in the same CIDR as the
- pod CIDR.
-
-#.
-
- In a new pod, CloudStack adds the first cluster for you. You can
- always add more clusters later. For an overview of what a cluster is,
- see About Clusters.
-
- To configure the first cluster, enter the following, then click Next:
-
- -
-
- **Hypervisor.** (Version 3.0.0 only; in 3.0.1, this field is read
- only) Choose the type of hypervisor software that all hosts in
- this cluster will run. If you choose VMware, additional fields
- appear so you can give information about a vSphere cluster. For
- vSphere servers, we recommend creating the cluster of hosts in
- vCenter and then adding the entire cluster to CloudStack. See Add
- Cluster: vSphere.
-
- -
-
- **Cluster name.** Enter a name for the cluster. This can be text
- of your choosing and is not used by CloudStack.
-
-#.
-
- In a new cluster, CloudStack adds the first host for you. You can
- always add more hosts later. For an overview of what a host is, see
- About Hosts.
-
- .. note:: When you add a hypervisor host to CloudStack, the host must not have
- any VMs already running.
-
- Before you can configure the host, you need to install the hypervisor
- software on the host. You will need to know which version of the
- hypervisor software version is supported by CloudStack and what
- additional configuration is required to ensure the host will work
- with CloudStack. To find these installation details, see:
-
- -
-
- Citrix XenServer Installation and Configuration
-
- -
-
- VMware vSphere Installation and Configuration
-
- -
-
- KVM vSphere Installation and Configuration
-
- To configure the first host, enter the following, then click Next:
-
- -
-
- **Host Name.** The DNS name or IP address of the host.
-
- -
-
- **Username.** The username is root.
-
- -
-
- **Password.** This is the password for the user named above (from
- your XenServer or KVM install).
-
- -
-
- **Host Tags.** (Optional) Any labels that you use to categorize
- hosts for ease of maintenance. For example, you can set this to
- the cloud's HA tag (set in the ha.tag global configuration
- parameter) if you want this host to be used only for VMs with the
- "high availability" feature enabled. For more information, see
- HA-Enabled Virtual Machines as well as HA for Hosts.
-
-#.
-
- In a new cluster, CloudStack adds the first primary storage server
- for you. You can always add more servers later. For an overview of
- what primary storage is, see About Primary Storage.
-
- To configure the first primary storage server, enter the following,
- then click Next:
-
- -
-
- **Name.** The name of the storage device.
-
- -
-
- **Protocol.** For XenServer, choose either NFS, iSCSI, or
- PreSetup. For KVM, choose NFS, SharedMountPoint,CLVM, or RBD. For
- vSphere choose either VMFS (iSCSI or FiberChannel) or NFS. The
- remaining fields in the screen vary depending on what you choose
- here.
-
-Advanced Zone Configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-#.
-
- After you select Advanced in the Add Zone wizard and click Next, you
- will be asked to enter the following details. Then click Next.
-
- -
-
- **Name.** A name for the zone.
-
- -
-
- **DNS 1 and 2.** These are DNS servers for use by guest VMs in the
- zone. These DNS servers will be accessed via the public network
- you will add later. The public IP addresses for the zone must have
- a route to the DNS server named here.
-
- -
-
- **Internal DNS 1 and Internal DNS 2.** These are DNS servers for
- use by system VMs in the zone(these are VMs used by CloudStack
- itself, such as virtual routers, console proxies,and Secondary
- Storage VMs.) These DNS servers will be accessed via the
- management traffic network interface of the System VMs. The
- private IP address you provide for the pods must have a route to
- the internal DNS server named here.
-
- -
-
- **Network Domain.** (Optional) If you want to assign a special
- domain name to the guest VM network, specify the DNS suffix.
-
- -
-
- **Guest CIDR.** This is the CIDR that describes the IP addresses
- in use in the guest virtual networks in this zone. For example,
- 10.1.1.0/24. As a matter of good practice you should set different
- CIDRs for different zones. This will make it easier to set up VPNs
- between networks in different zones.
-
- -
-
- **Hypervisor.** (Introduced in version 3.0.1) Choose the
- hypervisor for the first cluster in the zone. You can add clusters
- with different hypervisors later, after you finish adding the
- zone.
-
- -
-
- **Public.** A public zone is available to all users. A zone that
- is not public will be assigned to a particular domain. Only users
- in that domain will be allowed to create guest VMs in this zone.
-
-#.
-
- Choose which traffic types will be carried by the physical network.
-
- The traffic types are management, public, guest, and storage traffic.
- For more information about the types, roll over the icons to display
- their tool tips, or see `Section 2.8.3, “Advanced Zone Network
- Traffic Types” <#advanced-zone-network-traffic-types>`__. This screen
- starts out with one network already configured. If you have multiple
- physical networks, you need to add more. Drag and drop traffic types
- onto a greyed-out network and it will become active. You can move the
- traffic icons from one network to another; for example, if the
- default traffic types shown for Network 1 do not match your actual
- setup, you can move them down. You can also change the network names
- if desired.
-
-#.
-
- (Introduced in version 3.0.1) Assign a network traffic label to each
- traffic type on each physical network. These labels must match the
- labels you have already defined on the hypervisor host. To assign
- each label, click the Edit button under the traffic type icon within
- each physical network. A popup dialog appears where you can type the
- label, then click OK.
-
- These traffic labels will be defined only for the hypervisor selected
- for the first cluster. For all other hypervisors, the labels can be
- configured after the zone is created.
-
- (VMware only) If you have enabled Nexus dvSwitch in the environment,
- you must specify the corresponding Ethernet port profile names as
- network traffic label for each traffic type on the physical network.
- For more information on Nexus dvSwitch, see Configuring a vSphere
- Cluster with Nexus 1000v Virtual Switch in the Installation Guide. If
- you have enabled VMware dvSwitch in the environment, you must specify
- the corresponding Switch name as network traffic label for each
- traffic type on the physical network. For more information, see
- Configuring a VMware Datacenter with VMware Distributed Virtual
- Switch in the Installation Guide.
-
-#.
-
- Click Next.
-
-#.
-
- Configure the IP range for public Internet traffic. Enter the
- following details, then click Add. If desired, you can repeat this
- step to add more public Internet IP ranges. When done, click Next.
-
- -
-
- **Gateway.** The gateway in use for these IP addresses.
-
- -
-
- **Netmask.** The netmask associated with this IP range.
-
- -
-
- **VLAN.** The VLAN that will be used for public traffic.
-
- -
-
- **Start IP/End IP.** A range of IP addresses that are assumed to
- be accessible from the Internet and will be allocated for access
- to guest networks.
-
-#.
-
- In a new zone, CloudStack adds the first pod for you. You can always
- add more pods later. For an overview of what a pod is, see
- `Section 2.3, “About Pods” <#about-pods>`__.
-
- To configure the first pod, enter the following, then click Next:
-
- -
-
- **Pod Name.** A name for the pod.
-
- -
-
- **Reserved system gateway.** The gateway for the hosts in that
- pod.
-
- -
-
- **Reserved system netmask.** The network prefix that defines the
- pod's subnet. Use CIDR notation.
-
- -
-
- **Start/End Reserved System IP.** The IP range in the management
- network that CloudStack uses to manage various system VMs, such as
- Secondary Storage VMs, Console Proxy VMs, and DHCP. For more
- information, see `Section 2.8.6, “System Reserved IP
- Addresses” <#system-reserved-ip-addresses>`__.
-
-#.
-
- Specify a range of VLAN IDs to carry guest traffic for each physical
- network (see VLAN Allocation Example ), then click Next.
-
-#.
-
- In a new pod, CloudStack adds the first cluster for you. You can
- always add more clusters later. For an overview of what a cluster is,
- see `Section 2.4, “About Clusters” <#about-clusters>`__.
-
- To configure the first cluster, enter the following, then click Next:
-
- -
-
- **Hypervisor.** (Version 3.0.0 only; in 3.0.1, this field is read
- only) Choose the type of hypervisor software that all hosts in
- this cluster will run. If you choose VMware, additional fields
- appear so you can give information about a vSphere cluster. For
- vSphere servers, we recommend creating the cluster of hosts in
- vCenter and then adding the entire cluster to CloudStack. See Add
- Cluster: vSphere .
-
- -
-
- **Cluster name.** Enter a name for the cluster. This can be text
- of your choosing and is not used by CloudStack.
-
-#.
-
- In a new cluster, CloudStack adds the first host for you. You can
- always add more hosts later. For an overview of what a host is, see
- `Section 2.5, “About Hosts” <#about-hosts>`__.
-
- .. note:: When you deploy CloudStack, the hypervisor host must not have any VMs
- already running.
-
- Before you can configure the host, you need to install the hypervisor
- software on the host. You will need to know which version of the
- hypervisor software version is supported by CloudStack and what
- additional configuration is required to ensure the host will work
- with CloudStack. To find these installation details, see:
-
- -
-
- Citrix XenServer Installation for CloudStack
-
- -
-
- VMware vSphere Installation and Configuration
-
- -
-
- KVM Installation and Configuration
-
- To configure the first host, enter the following, then click Next:
-
- -
-
- **Host Name.** The DNS name or IP address of the host.
-
- -
-
- **Username.** Usually root.
-
- -
-
- **Password.** This is the password for the user named above (from
- your XenServer or KVM install).
-
- -
-
- **Host Tags.** (Optional) Any labels that you use to categorize
- hosts for ease of maintenance. For example, you can set to the
- cloud's HA tag (set in the ha.tag global configuration parameter)
- if you want this host to be used only for VMs with the "high
- availability" feature enabled. For more information, see
- HA-Enabled Virtual Machines as well as HA for Hosts, both in the
- Administration Guide.
-
-#.
-
- In a new cluster, CloudStack adds the first primary storage server
- for you. You can always add more servers later. For an overview of
- what primary storage is, see `Section 2.6, “About Primary
- Storage” <#about-primary-storage>`__.
-
- To configure the first primary storage server, enter the following,
- then click Next:
-
- -
-
- **Name.** The name of the storage device.
-
- -
-
- **Protocol.** For XenServer, choose either NFS, iSCSI, or
- PreSetup. For KVM, choose NFS, SharedMountPoint, CLVM, and RBD.
- For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS. The
- remaining fields in the screen vary depending on what you choose
- here.
-
- NFS
-
- -
-
- **Server.** The IP address or DNS name of the storage device.
-
- -
-
- **Path.** The exported path from the server.
-
- -
-
- **Tags (optional).** The comma-separated list of tags for this
- storage device. It should be an equivalent set or superset of
- the tags on your disk offerings.
-
- The tag sets on primary storage across clusters in a Zone must be
- identical. For example, if cluster A provides primary storage that
- has tags T1 and T2, all other clusters in the Zone must also
- provide primary storage that has tags T1 and T2.
-
- iSCSI
-
- -
-
- **Server.** The IP address or DNS name of the storage device.
-
- -
-
- **Target IQN.** The IQN of the target. For example,
- iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
-
- -
-
- **Lun.** The LUN number. For example, 3.
-
- -
-
- **Tags (optional).** The comma-separated list of tags for this
- storage device. It should be an equivalent set or superset of
- the tags on your disk offerings.
-
- The tag sets on primary storage across clusters in a Zone must be
- identical. For example, if cluster A provides primary storage that
- has tags T1 and T2, all other clusters in the Zone must also
- provide primary storage that has tags T1 and T2.
-
- preSetup
-
- -
-
- **Server.** The IP address or DNS name of the storage device.
-
- -
-
- **SR Name-Label.** Enter the name-label of the SR that has been
- set up outside CloudStack.
-
- -
-
- **Tags (optional).** The comma-separated list of tags for this
- storage device. It should be an equivalent set or superset of
- the tags on your disk offerings.
-
- The tag sets on primary storage across clusters in a Zone must be
- identical. For example, if cluster A provides primary storage that
- has tags T1 and T2, all other clusters in the Zone must also
- provide primary storage that has tags T1 and T2.
-
- SharedMountPoint
-
- -
-
- **Path.** The path on each host that is where this primary
- storage is mounted. For example, "/mnt/primary".
-
- -
-
- **Tags (optional).** The comma-separated list of tags for this
- storage device. It should be an equivalent set or superset of
- the tags on your disk offerings.
-
- The tag sets on primary storage across clusters in a Zone must be
- identical. For example, if cluster A provides primary storage that
- has tags T1 and T2, all other clusters in the Zone must also
- provide primary storage that has tags T1 and T2.
-
- VMFS
-
- -
-
- **Server.** The IP address or DNS name of the vCenter server.
-
- -
-
- **Path.** A combination of the datacenter name and the
- datastore name. The format is "/" datacenter name "/" datastore
- name. For example, "/cloud.dc.VM/cluster1datastore".
-
- -
-
- **Tags (optional).** The comma-separated list of tags for this
- storage device. It should be an equivalent set or superset of
- the tags on your disk offerings.
-
- The tag sets on primary storage across clusters in a Zone must be
- identical. For example, if cluster A provides primary storage that
- has tags T1 and T2, all other clusters in the Zone must also
- provide primary storage that has tags T1 and T2.
-
-#.
-
- In a new zone, CloudStack adds the first secondary storage server for
- you. For an overview of what secondary storage is, see `Section 2.7,
- “About Secondary Storage” <#about-secondary-storage>`__.
-
- Before you can fill out this screen, you need to prepare the
- secondary storage by setting up NFS shares and installing the latest
- CloudStack System VM template. See Adding Secondary Storage :
-
- -
-
- **NFS Server.** The IP address of the server or fully qualified
- domain name of the server.
-
- -
-
- **Path.** The exported path from the server.
-
-#.
-
- Click Launch.
-
-Adding a Pod
------------------
-
-When you created a new zone, CloudStack adds the first pod for you. You
-can add more pods at any time using the procedure in this section.
-
-#.
-
- Log in to the CloudStack UI. See `Section 5.1, “Log In to the
- UI” <#log-in>`__.
-
-#.
-
- In the left navigation, choose Infrastructure. In Zones, click View
- More, then click the zone to which you want to add a pod.
-
-#.
-
- Click the Compute and Storage tab. In the Pods node of the diagram,
- click View All.
-
-#.
-
- Click Add Pod.
-
-#.
-
- Enter the following details in the dialog.
-
- -
-
- **Name.** The name of the pod.
-
- -
-
- **Gateway.** The gateway for the hosts in that pod.
-
- -
-
- **Netmask.** The network prefix that defines the pod's subnet. Use
- CIDR notation.
-
- -
-
- **Start/End Reserved System IP.** The IP range in the management
- network that CloudStack uses to manage various system VMs, such as
- Secondary Storage VMs, Console Proxy VMs, and DHCP. For more
- information, see System Reserved IP Addresses.
-
-#.
-
- Click OK.
-
-Adding a Cluster
----------------------
-
-You need to tell CloudStack about the hosts that it will manage. Hosts
-exist inside clusters, so before you begin adding hosts to the cloud,
-you must add at least one cluster.
-
-Add Cluster: KVM or XenServer
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-These steps assume you have already installed the hypervisor on the
-hosts and logged in to the CloudStack UI.
-
-#.
-
- In the left navigation, choose Infrastructure. In Zones, click View
- More, then click the zone in which you want to add the cluster.
-
-#.
-
- Click the Compute tab.
-
-#.
-
- In the Clusters node of the diagram, click View All.
-
-#.
-
- Click Add Cluster.
-
-#.
-
- Choose the hypervisor type for this cluster.
-
-#.
-
- Choose the pod in which you want to create the cluster.
-
-#.
-
- Enter a name for the cluster. This can be text of your choosing and
- is not used by CloudStack.
-
-#.
-
- Click OK.
-
-Add Cluster: vSphere
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Host management for vSphere is done through a combination of vCenter and
-the CloudStack admin UI. CloudStack requires that all hosts be in a
-CloudStack cluster, but the cluster may consist of a single host. As an
-administrator you must decide if you would like to use clusters of one
-host or of multiple hosts. Clusters of multiple hosts allow for features
-like live migration. Clusters also require shared storage such as NFS or
-iSCSI.
-
-For vSphere servers, we recommend creating the cluster of hosts in
-vCenter and then adding the entire cluster to CloudStack. Follow these
-requirements:
-
--
-
- Do not put more than 8 hosts in a vSphere cluster
-
--
-
- Make sure the hypervisor hosts do not have any VMs already running
- before you add them to CloudStack.
-
-To add a vSphere cluster to CloudStack:
-
-#.
-
- Create the cluster of hosts in vCenter. Follow the vCenter
- instructions to do this. You will create a cluster that looks
- something like this in vCenter.
-
- |vsphereclient.png: vSphere client|
-
-#.
-
- Log in to the UI.
-
-#.
-
- In the left navigation, choose Infrastructure. In Zones, click View
- More, then click the zone in which you want to add the cluster.
-
-#.
-
- Click the Compute tab, and click View All on Pods. Choose the pod to
- which you want to add the cluster.
-
-#.
-
- Click View Clusters.
-
-#.
-
- Click Add Cluster.
-
-#.
-
- In Hypervisor, choose VMware.
-
-#.
-
- Provide the following information in the dialog. The fields below
- make reference to the values from vCenter.
-
- |addcluster.png: add a cluster|
-
- -
-
- **Cluster Name**: Enter the name of the cluster you created in
- vCenter. For example, "cloud.cluster.2.2.1"
-
- -
-
- **vCenter Username**: Enter the username that CloudStack should
- use to connect to vCenter. This user must have all the
- administrative privileges.
-
- -
-
- **CPU overcommit ratio**: Enter the CPU overcommit ratio for the
- cluster. The value you enter determines the CPU consumption of
- each VM in the selected cluster. By increasing the
- over-provisioning ratio, more resource capacity will be used. If
- no value is specified, the value is defaulted to 1, which implies
- no over-provisioning is done.
-
- -
-
- **RAM overcommit ratio**: Enter the RAM overcommit ratio for the
- cluster. The value you enter determines the memory consumption of
- each VM in the selected cluster. By increasing the
- over-provisioning ratio, more resource capacity will be used. If
- no value is specified, the value is defaulted to 1, which implies
- no over-provisioning is done.
-
- -
-
- **vCenter Host**: Enter the hostname or IP address of the vCenter
- server.
-
- -
-
- **vCenter Password**: Enter the password for the user named above.
-
- -
-
- **vCenter Datacenter**: Enter the vCenter datacenter that the
- cluster is in. For example, "cloud.dc.VM".
-
- -
-
- **Override Public Traffic**: Enable this option to override the
- zone-wide public traffic for the cluster you are creating.
-
- -
-
- **Public Traffic vSwitch Type**: This option is displayed only if
- you enable the Override Public Traffic option. Select a desirable
- switch. If the vmware.use.dvswitch global parameter is true, the
- default option will be VMware vNetwork Distributed Virtual Switch.
-
- If you have enabled Nexus dvSwitch in the environment, the
- following parameters for dvSwitch configuration are displayed:
-
- -
-
- Nexus dvSwitch IP Address: The IP address of the Nexus VSM
- appliance.
-
- -
-
- Nexus dvSwitch Username: The username required to access the
- Nexus VSM appliance.
-
- -
-
- Nexus dvSwitch Password: The password associated with the
- username specified above.
-
- -
-
- **Override Guest Traffic**: Enable this option to override the
- zone-wide guest traffic for the cluster you are creating.
-
- -
-
- **Guest Traffic vSwitch Type**: This option is displayed only if
- you enable the Override Guest Traffic option. Select a desirable
- switch.
-
- If the vmware.use.dvswitch global parameter is true, the default
- option will be VMware vNetwork Distributed Virtual Switch.
-
- If you have enabled Nexus dvSwitch in the environment, the
- following parameters for dvSwitch configuration are displayed:
-
- -
-
- Nexus dvSwitch IP Address: The IP address of the Nexus VSM
- appliance.
-
- -
-
- Nexus dvSwitch Username: The username required to access the
- Nexus VSM appliance.
-
- -
-
- Nexus dvSwitch Password: The password associated with the
- username specified above.
-
- -
-
- There might be a slight delay while the cluster is provisioned. It
- will automatically display in the UI.
-
-Adding a Host
-------------------
-
-#.
-
- Before adding a host to the CloudStack configuration, you must first
- install your chosen hypervisor on the host. CloudStack can manage
- hosts running VMs under a variety of hypervisors.
-
- The CloudStack Installation Guide provides instructions on how to
- install each supported hypervisor and configure it for use with
- CloudStack. See the appropriate section in the Installation Guide for
- information about which version of your chosen hypervisor is
- supported, as well as crucial additional steps to configure the
- hypervisor hosts for use with CloudStack.
-
- .. warning:: Be sure you have performed the additional CloudStack-specific
- configuration steps described in the hypervisor installation section
- for your particular hypervisor.
-
-#.
-
- Now add the hypervisor host to CloudStack. The technique to use
- varies depending on the hypervisor.
-
- -
-
- `Section 7.6.1, “Adding a Host (XenServer or
- KVM)” <#host-add-xenserver-kvm-ovm>`__
-
- -
-
- `Section 7.6.2, “Adding a Host (vSphere)” <#host-add-vsphere>`__
-
-Adding a Host (XenServer or KVM)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-XenServer and KVM hosts can be added to a cluster at any time.
-
-Requirements for XenServer and KVM Hosts
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. warning:: Make sure the hypervisor host does not have any VMs already running
-before you add it to CloudStack.
-
-Configuration requirements:
-
--
-
- Each cluster must contain only hosts with the identical hypervisor.
-
--
-
- For XenServer, do not put more than 8 hosts in a cluster.
-
--
-
- For KVM, do not put more than 16 hosts in a cluster.
-
-For hardware requirements, see the installation section for your
-hypervisor in the CloudStack Installation Guide.
-
-XenServer Host Additional Requirements
-'''''''''''''''''''''''''''''''''''''''''''''''''
-
-If network bonding is in use, the administrator must cable the new host
-identically to other hosts in the cluster.
-
-For all additional hosts to be added to the cluster, run the following
-command. This will cause the host to join the master in a XenServer
-pool.
-
-.. code:: bash
-
- # xe pool-join master-address=[master IP] master-username=root master-password=[your password]
-
-.. 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.
-
-With all hosts added to the XenServer pool, run the cloud-setup-bond
-script. This script will complete the configuration and setup of the
-bonds on the new hosts in the cluster.
-
-#.
-
- Copy the script from the Management Server in
- /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh
- to the master host and ensure it is executable.
-
-#.
-
- Run the script:
-
- .. code:: bash
-
- # ./cloud-setup-bonding.sh
-
-KVM Host Additional Requirements
-'''''''''''''''''''''''''''''''''''''''''''
-
--
-
- If shared mountpoint storage is in use, the administrator should
- ensure that the new host has all the same mountpoints (with storage
- mounted) as the other hosts in the cluster.
-
--
-
- Make sure the new host has the same network configuration (guest,
- private, and public network) as other hosts in the cluster.
-
--
-
- If you are using OpenVswitch bridges edit the file agent.properties
- on the KVM host and set the parameter network.bridge.type to
- openvswitch before adding the host to CloudStack
-
-Adding a XenServer or KVM Host
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-#.
-
- If you have not already done so, install the hypervisor software on
- the host. You will need to know which version of the hypervisor
- software version is supported by CloudStack and what additional
- configuration is required to ensure the host will work with
- CloudStack. To find these installation details, see the appropriate
- section for your hypervisor in the CloudStack Installation Guide.
-
-#.
-
- Log in to the CloudStack UI as administrator.
-
-#.
-
- In the left navigation, choose Infrastructure. In Zones, click View
- More, then click the zone in which you want to add the host.
-
-#.
-
- Click the Compute tab. In the Clusters node, click View All.
-
-#.
-
- Click the cluster where you want to add the host.
-
-#.
-
- Click View Hosts.
-
-#.
-
- Click Add Host.
-
-#.
-
- Provide the following information.
-
- -
-
- Host Name. The DNS name or IP address of the host.
-
- -
-
- Username. Usually root.
-
- -
-
- Password. This is the password for the user from your XenServer or
- KVM install).
-
- -
-
- Host Tags (Optional). Any labels that you use to categorize hosts
- for ease of maintenance. For example, you can set to the cloud's
- HA tag (set in the ha.tag global configuration parameter) if you
- want this host to be used only for VMs with the "high
- availability" feature enabled. For more information, see
- HA-Enabled Virtual Machines as well as HA for Hosts.
-
- There may be a slight dela
<TRUNCATED>