+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+ CloudStack is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. CloudStack manages the network, storage, and compute nodes that make up a cloud infrastructure. Use CloudStack to deploy, manage, and configure cloud computing environments.
+
+ Typical users are service providers and enterprises. With CloudStack, you can:
+
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with CloudStack an enterprise can offer self-service virtual machines to users without involving IT departments.
+
1.2. What Can CloudStack Do?
+ Multiple Hypervisor Support
+
+ CloudStack works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of CloudStack supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+ Massively Scalable Infrastructure Management
+
+ CloudStack can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+ Automatic Configuration Management
+
+ CloudStack automatically configures each guest virtual machine’s networking and storage settings.
+
+ CloudStack internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+ Graphical User Interface
+
+ CloudStack offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+ API and Extensibility
+
+ CloudStack provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at Apache CloudStack Guides and Apache CloudStack API Reference respectively.
+
+ CloudStack has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the hosts, CloudStack supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+
1.3. Deployment Architecture Overview
+ A CloudStack installation consists of two parts: the Management Server and the cloud infrastructure that it manages. When you set up and manage a CloudStack cloud, you provision resources such as hosts, storage devices, and IP addresses into the Management Server, and the Management Server manages those resources.
+
+ The minimum production installation consists of one machine running the CloudStack Management Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure consisting of one host running hypervisor software). In its smallest deployment, a single machine can act as both the Management Server and the hypervisor host (using the KVM hypervisor).
+
+ A more full-featured installation consists of a highly-available multi-node Management Server installation and up to tens of thousands of hosts using any of several advanced networking setups. For information about deployment options, see Choosing a Deployment Architecture.
+
1.3.1. Management Server Overview
+ The Management Server is the CloudStack software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+ The machine must meet the system requirements described in System Requirements.
+
+ The Management Server:
+
+ Provides the web user interface for the administrator and a reference user interface for end users.
+
+ Provides the APIs for CloudStack.
+
+ Manages the assignment of guest VMs to particular hosts.
+
+ Manages the assignment of public and private IP addresses to particular accounts.
+
+ Manages the allocation of storage to guests as virtual disks.
+
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+
+ Provides a single point of configuration for the cloud.
+
1.3.2. Cloud Infrastructure Overview
+ The Management Server manages one or more zones (typically, datacenters) containing host computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
+
+ Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
+
+ Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
+
+ Cluster: A cluster consists of one or more hosts and primary storage.
+
+ Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines.
+
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster.
+
+ Secondary storage is associated with a zone, and it stores templates, ISO images, and disk volume snapshots.
+
+ More Information
+
+ For more information, see documentation on cloud infrastructure concepts.
+
1.3.3. Networking Overview
+ CloudStack offers two types of networking scenario:
+
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+ A zone is the largest organizational unit within a CloudStack deployment. A zone typically corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter. The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required).
+
+ A zone consists of:
+
+ One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
+
+ Secondary storage, which is shared by all the pods in the zone.
+
+ Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones.
+
+ Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone.
+
+ Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels.
+
+ For each zone, the administrator must decide the following.
+
+ How many pods to place in a zone.
+
+ How many clusters to place in each pod.
+
+ How many hosts to place in each cluster.
+
+ How many primary storage servers to place in each cluster and total capacity for the storage servers.
+
+ How much secondary storage to deploy in 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.
+
2.2. About Pods
+ A pod often represents a single rack. Hosts in the same pod are in the same subnet.
+
+ A pod is the second-largest organizational unit within a CloudStack deployment. Pods are contained within zones. Each zone can contain one or more pods.
+
+ Pods are not visible to the end user.
+
+ A pod consists of one or more clusters of hosts and one or more primary storage servers.
+
2.3. About Clusters
+ A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set of KVM servers, , or a VMware cluster preconfigured in vCenter. The hosts in a cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the same shared primary storage. Virtual machine instances (VMs) can be live-migrated from one host to another within the same cluster, without interrupting service to the user.
+
+ A cluster is the third-largest organizational unit within a CloudStack deployment. Clusters are contained within pods, and pods are contained within zones. Size of the cluster is limited by the underlying hypervisor, although the CloudStack recommends less in most cases; see Best Practices.
+
+ A cluster consists of one or more hosts and one or more primary storage servers.
+
+ CloudStack allows multiple clusters in a cloud deployment.
+
+ Even when local storage is used exclusively, clusters are still required organizationally, even if there is just one host per cluster.
+
+ When VMware is used, every VMware cluster is managed by a vCenter server. Administrator must register the vCenter server with CloudStack. There may be multiple vCenter servers per zone. Each vCenter server may manage multiple VMware clusters.
+
2.4. About Hosts
+ A host is a single computer. Hosts provide the computing resources that run the guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a Linux KVM-enabled server, a Citrix XenServer server, and an ESXi server are hosts.
+
+ The host is the smallest organizational unit within a CloudStack deployment. Hosts are contained within clusters, clusters are contained within pods, and pods are contained within zones.
+
+ Hosts in a CloudStack deployment:
+
+ Provide the CPU, memory, storage, and networking resources needed to host the virtual machines
+
+ Interconnect using a high bandwidth TCP/IP network and connect to the Internet
+
+ May reside in multiple data centers across different geographic locations
+
+ May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the hosts within a cluster must all be homogeneous
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs.
+
+ CloudStack automatically detects the amount of CPU and memory resources provided by the Hosts.
+
+ Hosts are not visible to the end user. An end user cannot determine which host their guest has been assigned to.
+
+ For a host to function in CloudStack, you must do the following:
+
+ Install hypervisor software on the host
+
+ Assign an IP address to the host
+
+ Ensure the host is connected to the CloudStack Management Server
+
2.5. About Primary Storage
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required. It is typically located close to the hosts for increased performance.
+
+ CloudStack is designed to work with all standards-compliant iSCSI and NFS servers that are supported by the underlying hypervisor, including, for example:
+
+ Dell EqualLogic™ for iSCSI
+
+ Network Appliances filers for NFS and iSCSI
+
+ Scale Computing for NFS
+
+ If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.
+
2.6. About Secondary Storage
+ Secondary storage is associated with a zone, and it stores the following:
+
+ Templates — OS images that can be used to boot VMs and can include additional configuration information, such as installed applications
+
+ ISO images — disc images containing data or bootable media for operating systems
+
+ Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
+
+ The items in zone-based NFS secondary storage are available to all hosts in the zone. CloudStack manages the allocation of guest virtual disks to particular primary storage devices.
+
+ To make items in secondary storage available to all hosts throughout the cloud, you can add OpenStack Object Storage (Swift, swift.openstack.org) in addition to the zone-based NFS secondary storage. When using Swift, you configure Swift storage for the entire CloudStack, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere.
+
2.7. About Physical Networks
+ Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical networks can be associated with each zone. The network corresponds to a NIC on the hypervisor host. Each physical network can carry one or more types of network traffic. The choices of traffic type for each network vary depending on whether you are creating a zone with basic networking or advanced networking.
+
+ A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can:
+
+ Add/Remove/Update physical networks in a zone
+
+ Configure VLANs on the physical network
+
+ Configure a name so the network can be recognized by hypervisors
+
+ Configure the service providers (firewalls, load balancers, etc.) available on a physical network
+
+ Configure the IP addresses trunked to a physical network
+
+ Specify what type of traffic is carried on the physical network, as well as other properties like network speed
+
2.7.1. Configurable Characteristics of Physical Networks
+ CloudStack provides configuration settings you can use to set up a physical network in a zone, including:
+
+ What type of network traffic it carries (guest, public, management, storage)
+
+ VLANs
+
+ Unique name that the hypervisor can use to find that particular network
+
+ Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator sets the physical network to enabled, and it begins to be used. The administrator can later disable the network again, which prevents any new virtual networks from being created on that physical network; the existing network traffic continues even though the state is disabled.
+
+ Speed
+
+ Tags, so network offerings can be matched to physical networks
+
+ Isolation method
+
2.7.2. Basic Zone Network Traffic Types
+ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
Note
+ We strongly recommend the use of separate NICs for management traffic and guest traffic.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. CloudStack takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.
+
2.7.3. Basic Zone Guest IP Addresses
+ When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts.
+
2.7.4. Advanced Zone Network Traffic Types
+ When advanced networking is used, there can be multiple physical networks in the zone. Each physical network can carry one or more traffic types, and you need to let CloudStack know which type of network traffic you want each network to carry. The traffic types in an advanced zone are:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each CloudStack account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices.
+
2.7.5. Advanced Zone Guest IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.6. Advanced Zone Public IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.7. System Reserved IP Addresses
+ In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the CloudStack Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
+
+ The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone.
+
+ The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in.
+
+ Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. CloudStack can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
+
+ In all zones:
+
+ Provide private IPs for the system in each pod and provision them in CloudStack.
+
+ For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.
+
+ In a zone that uses advanced networking:
+
+ For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required CloudStack System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.
+
+ When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
+
+ To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:
+
+ Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than 4,000 IP addresses.
+
+ Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod has 255 IPs, this will provide 2,550 IP addresses.
+
+ 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
+
+ The 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.
+
3.2. Using an LDAP Server for User Authentication
+ You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate CloudStack end-users. Just map CloudStack accounts to the corresponding LDAP accounts using a query filter. The query filter is written using the query syntax of the particular LDAP server, and can include special wildcard characters provided by CloudStack for matching common values such as the user’s email address and name. CloudStack will search the external LDAP directory tree starting at a specified base directory and return the distinguished name (DN) and password of the matching user. This information along with the given password is used to authenticate the user..
+
+ To set up LDAP authentication in CloudStack, call the CloudStack API command ldapConfig and provide the following:
+
+ Hostname or IP address and listening port of the LDAP server
+
+ Base directory and query filter
+
+ Search user DN credentials, which give CloudStack permission to search on the LDAP server
+
+ SSL keystore and password, if SSL is used
+
3.2.1. Example LDAP Configuration Commands
+ To understand the examples in this section, you need to know the basic concepts behind calling the CloudStack API, which are explained in the Developer’s Guide.
+
+ The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
+
+ 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.
+
+ The next few sections explain some of the concepts you will need to know when filling out the ldapConfig parameters.
+
3.2.2. Search Base
+ An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The search base is the distinguished name (DN) of a level of the directory tree below which all users can be found. The users can be in the immediate base directory or in some subdirectory. The search base may be equivalent to the organization, group, or domain name. The syntax for writing a DN varies depending on which LDAP server you are using. A full discussion of distinguished names is outside the scope of our documentation. The following table shows some examples of search bases to find users in the testing department..
+
+
+ LDAP Server
+
+
+
+ Example Search Base DN
+
+
+
+ ApacheDS
+
+
+
+ ou=testing,o=project
+
+
+
+ Active Directory
+
+
+
+ OU=testing, DC=company
+
+
3.2.3. Query Filter
+ The query filter is used to find a mapped user in the external LDAP server. The query filter should uniquely map the CloudPlatform user to LDAP user for a meaningful authentication. For more information about query filter syntax, consult the documentation for your LDAP server.
+
+ The CloudPlatform 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 CloudPlatform user name is the same as the LDAP user ID:
+
(uid=%u)
+ If the CloudPlatform user name is the LDAP display name:
+
(displayName=%u)
+ To find a user by email address:
+
(mail=%e)
3.2.4. Search User Bind DN
+ The bind DN is the user on the external LDAP server permitted to search the LDAP directory within the defined search base. When the DN is returned, the DN and passed password are used to authenticate the CloudStack user with an LDAP bind. A full discussion of bind DNs is outside the scope of our documentation. The following table shows some examples of bind DNs.
+
+ 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.
+
+ In addition to the physical and logical infrastructure of your cloud, and the CloudStack software and servers, you also need a layer of user services so that people can actually make use of the cloud. This means not just a user UI, but a set of options and resources that users can choose from, such as templates for creating virtual machines, disk storage, and more. If you are running a commercial service, you will be keeping track of what services and resources users are consuming and charging them for that usage. Even if you do not charge anything for people to use your cloud – say, if the users are strictly internal to your organization, or just friends who are sharing your cloud – you can still keep track of what services they use and how much of them.
+
4.1. Service Offerings, Disk Offerings, Network Offerings, and Templates
+ A user creating a new instance can make a variety of choices about its characteristics and capabilities. CloudStack provides several ways to present users with choices when creating a new instance:
+
+ Service Offerings, defined by the CloudStack administrator, provide a choice of CPU speed, number of CPUs, RAM size, tags on the root disk, and other choices. See Creating a New Compute Offering.
+
+ Disk Offerings, defined by the CloudStack administrator, provide a choice of disk size for primary data storage. See Creating a New Disk Offering.
+
+ Network Offerings, defined by the CloudStack administrator, describe the feature set that is available to end users from the virtual router or external networking devices on a given guest network. See Network Offerings.
+
+ Templates, defined by the CloudStack administrator or by any CloudStack user, are the base OS images that the user can choose from when creating a new instance. For example, CloudStack includes CentOS as a template. See Working with Templates.
+
+ In addition to these choices that are provided for users, there is another type of service offering which is available only to the CloudStack root administrator, and is used for configuring virtual infrastructure resources. For more information, see Upgrading a Virtual Router with System Service Offerings.
+
+ 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)
+
http://<management-server-ip-address>:8080/client
+ On a fresh Management Server installation, a guided tour splash screen appears. On later visits, you’ll see a login screen where you specify the following to proceed to your Dashboard:
+
Username
+ The user ID of your account. The default username is admin.
+
Password
+ The password associated with the user ID. The password for the default username is password.
+
Domain
+ If you are a root user, leave this field blank.
+
+ If you are a user in the sub-domains, enter the full path to the domain, excluding the root domain.
+
+ For example, suppose multiple levels are created under the root domain, such as Comp1/hr. The users in the Comp1 domain should enter Comp1 in the Domain field, whereas the users in the Comp1/sales domain should enter Comp1/sales.
+
+ For more guidance about the choices that appear when you log in to this UI, see Logging In as the Root Administrator.
+
5.1.1. End User's UI Overview
+ The CloudStack UI helps users of cloud infrastructure to view and use their cloud resources, including virtual machines, templates and ISOs, data volumes and snapshots, guest networks, and IP addresses. If the user is a member or administrator of one or more CloudStack projects, the UI can provide a project-oriented view.
+
5.1.2. Root Administrator's UI Overview
+ The CloudStack UI helps the CloudStack administrator provision, view, and manage the cloud infrastructure, domains, user accounts, projects, and configuration settings. The first time you start the UI after a fresh Management Server installation, you can choose to follow a guided tour to provision your cloud infrastructure. On subsequent logins, the dashboard of the logged-in user appears. The various links in this screen and the navigation bar on the left provide access to a variety of administrative functions. The root administrator can also use the UI to perform all the same tasks that are present in the end-user’s UI.
+
5.1.3. Logging In as the Root Administrator
+ After the Management Server software is installed and running, you can run the CloudStack user interface. This UI is there to help you provision, view, and manage your cloud infrastructure.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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 can enter a user ID and password and proceed to your 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 CloudPlatform, 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”.
+
Warning
+ You are logging in as the root administrator. This account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. Please change the default password to a new, unique password.
+
5.1.4. Changing the Root Password
+ During installation and ongoing cloud administration, you will need to log in to the UI as the root administrator. The root administrator account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. When first installing CloudStack, be sure to change the default password to a new, unique value.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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.
+
+
+ Type the new password, and click OK.
+
5.2. Using SSH Keys for Authentication
+ In addition to the username and password authentication, CloudStack supports using SSH keys to log in to the cloud infrastructure for additional security. You can use the createSSHKeyPair API to generate the SSH keys.
+
+ Because each cloud user has their own SSH key, one cloud user cannot log in to another cloud user's instances unless they share their SSH key files. Using a single SSH key pair, you can manage multiple instances.
+
5.2.1. Creating an Instance Template that Supports SSH Keys
+ Create a instance template that supports SSH Keys.
+
+ Create a new instance by using the template provided by cloudstack.
+
+ For more information on creating a new instance, see
+
+ Download the cloudstack script from The SSH Key Gen Scriptto the instance you have created.
+
+ Run the script while starting up the operating system:
+
chkconfig --add cloud-set-guest-sshkey.in
+ Stop the instance.
+
5.2.2. Creating the SSH Keypair
+ You must make a call to the createSSHKeyPair api method. You can either use the CloudStack Python API library or the curl commands to make the call to the cloudstack api.
+
+ For example, make a call from the cloudstack server to create a SSH keypair called "keypair-doc" for the admin account in the root domain:
+
Note
+ Ensure that you adjust these values to meet your needs. If you are making the API call from a different server, your URL/PORT will be different, and you will need to use the API keys.
+
+ 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..
+
6.2. Configuring Projects
+ Before CloudPlatform users start using projects, the CloudPlatform administrator must set up various systems to support them, including membership invitations, limits on project resources, and controls on who can create projects.
+
6.2.1. 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.
+
+ In the search box, type project and click the search button.
+
+
+ In the search results, you will 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
+
service cloud-management restart
6.2.2. 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
+
6.2.2.1. 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”). 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.
+
6.2.2.2. 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.
+
+
+
+ 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.
+
# service cloud-management restart
6.2.3. 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.
+
+
+
+ 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.
+
# service cloud-management restart
6.3. 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.
+
6.4. 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.
+
6.4.1. 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”. 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”.
+
+ 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.
+
+ 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.
+
6.5. 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.
+
6.6. 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
+
+
+ To suspend, use
+
+
6.7. 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.
+
Chapter 7. Steps to Provisioning Your Cloud Infrastructure
+ This section tells how to add 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.
+
7.1. 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”.
+
+ To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
+
+ (Optional) If you are going to use Swift for cloud-wide secondary storage, you need to add it before you add zones.
+
+ Log in to the CloudStack UI as administrator.
+
+ If this is your first time visiting the UI, you will see the guided tour splash screen. Choose “Experienced user.” The Dashboard appears.
+
+ In the left navigation bar, click Global Settings.
+
+ In the search box, type swift.enable and click the search button.
+
+ Click the edit button and set swift.enable to true.
+
+
+
+ Restart the Management Server.
+
# service cloud-management restart
+ Refresh the CloudStack UI browser tab and log back in.
+
+ In the left navigation, choose Infrastructure.
+
+ On Zones, click View More.
+
+ (Optional) If you are using Swift storage, click Enable Swift. Provide the following:
+
+ URL. The Swift URL.
+
+ Account. The Swift account.
+
+ Username. The Swift account’s username.
+
+ Key. The Swift key.
+
+ 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.
+
+ For more information about the network types, see Network Setup.
+
+ The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you:
+
+ 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.
+
+ 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.
+
+ (Introduced in version 3.0.1) 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.2, “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, CloudPlatform 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.
+
7.2.2. 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.7.4, “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.
+
+ 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.2, “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.7.7, “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.3, “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.4, “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.5, “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.6, “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.
+
+ Path. The exported path from the server.
+
+ Click Launch.
+
7.3. 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.
+
+ 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.
+
7.4. 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.
+
7.4.1. 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.
+
7.4.2. 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.
+
+ 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 values from vCenter.
+
+ Cluster Name. Enter the name of the cluster you created in vCenter. For example, "cloud.cluster.2.2.1"
+
+ vCenter Host. Enter the hostname or IP address of the vCenter server.
+
+ vCenter Username. Enter the username that CloudStack should use to connect to vCenter. This user must have all administrative privileges.
+
+ 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".
+
+ There might be a slight delay while the cluster is provisioned. It will automatically display in the UI
+
7.5. 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.
+
+ 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/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+
+ Run the script:
+
# ./cloud-setup-bonding.sh
7.5.1.1.2. 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.
+
7.5.1.2. 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 delay while the host is provisioned. It should automatically display in the UI.
+
+ Repeat for additional hosts.
+
7.5.2. Adding a Host (vSphere)
+ For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the entire cluster to CloudStack. See Add Cluster: vSphere.
+
7.6. Add Primary Storage
7.6.1. System Requirements for Primary Storage
+ Hardware requirements:
+
+ Any standards-compliant iSCSI or NFS server that is supported by the underlying hypervisor.
+
+ The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller.
+
+ Minimum required capacity depends on your needs.
+
+ When setting up primary storage, follow these restrictions:
+
+ Primary storage cannot be added until a host has been added to the cluster.
+
+ If you do not provision shared primary storage, you must set the global configuration parameter system.vm.local.storage.required to true, or else you will not be able to start VMs.
+
7.6.2. Adding Primary Stroage
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+
+ Click the Compute tab.
+
+ In the Primary Storage node of the diagram, click View All.
+
+ Click Add Primary Storage.
+
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+
+ Pod. The pod for the storage device.
+
+ Cluster. The cluster for the storage device.
+
+ Name. The name of the storage device.
+
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS.
+
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device.
+
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+
+ Path (for NFS). In NFS this is the exported path from the server.
+
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside CloudStack.
+
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
+
+ Lun # (for iSCSI). In iSCSI this is 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.
+
+ Click OK.
+
7.7. Add Secondary Storage
7.7.1. System Requirements for Secondary Storage
+ NFS storage appliance or Linux NFS server
+
+ (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org)
+
+ 100GB minimum capacity
+
+ A secondary storage device must be located in the same zone as the guest VMs it serves.
+
+ Each Secondary Storage server must be available to all hosts in the zone.
+
7.7.2. Adding Secondary Storage
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to CloudStack before you add the local zone secondary storage servers. See Section 7.2, “Adding a Zone”.
+
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See Preparing NFS Shares in the Installation Guide.
+
+ Make sure you prepared the system VM template during Management Server installation. See Prepare the System VM Template in the Installation Guide.
+
+ Now that the secondary storage server for per-zone storage is prepared, add it to CloudStack. Secondary storage is added as part of the procedure for adding a new zone. See Section 7.2, “Adding a Zone”.
+
7.8. Initialize and Test
+ After everything is configured, CloudStack will perform its initialization. This can take 30 minutes or more, depending on the speed of your network. When the initialization has completed successfully, the administrator's Dashboard should be displayed in the CloudStack UI.
+
+ Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS 5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do not proceed to the next step until this status is displayed.
+
+ Go to the Instances tab, and filter by My Instances.
+
+ Click Add Instance and follow the steps in the wizard.
+
+ Choose the zone you just added.
+
+ In the template selection, choose the template to use in the VM. If this is a fresh installation, likely only the provided CentOS template is available.
+
+ Select a service offering. Be sure that the hardware you have allows starting the selected service offering.
+
+ In data disk offering, if desired, add another data disk. This is a second volume that will be available to but not mounted in the guest. For example, in Linux on XenServer you will see /dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PV-enabled OS kernel in use.
+
+ In default network, choose the primary network for the guest. In a trial installation, you would have only one option here.
+
+ Optionally give your VM a name and a group. Use any descriptive text you would like.
+
+ Click Launch VM. Your VM will be created and started. It might take some time to download the template and complete the VM startup. You can watch the VM’s progress in the Instances screen.
+
+ To use the VM, click the View Console button.
+
+
+
+ Congratulations! You have successfully completed a CloudStack Installation.
+
+ If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
+
+ In this chapter we discuss compute, disk, and system service offerings. Network offerings are discussed in the section on setting up networking for users.
+
8.1. Compute and Disk Service Offerings
+ A service offering is a set of virtual hardware features such as CPU core count and speed, memory, and disk size. The CloudStack administrator can set up various offerings, and then end users choose from the available offerings when they create a new VM. A service offering includes the following elements:
+
+ CPU, memory, and network resource guarantees
+
+ How resources are metered
+
+ How the resource usage is charged
+
+ How often the charges are generated
+
+ For example, one service offering might allow users to create a virtual machine instance that is equivalent to a 1 GHz Intel® Core™ 2 CPU, with 1 GB memory at $0.20/hour, with network traffic metered at $0.10/GB. Based on the user’s selected offering, CloudStack emits usage records that can be integrated with billing systems. CloudStack separates service offerings into compute offerings and disk offerings. The computing service offering specifies:
+
+ Guest CPU
+
+ Guest RAM
+
+ Guest Networking type (virtual or direct)
+
+ Tags on the root disk
+
+ The disk offering specifies:
+
+ Disk size (optional). An offering without a disk size will allow users to pick their own
+
+ Tags on the data disk
+
8.1.1. Creating a New Compute Offering
+ To create a new compute offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Compute Offering.
+
+ Click Add Compute Offering.
+
+ In the dialog, make the following choices:
+
+ Name: Any desired name for the service offering.
+
+ Description: A short description of the offering that can be displayed to users
+
+ Storage type: The type of disk that should be allocated. Local allocates from storage attached directly to the host where the system VM is running. Shared allocates from storage accessible via NFS.
+
+ # of CPU cores: The number of cores which should be allocated to a system VM with this offering
+
+ CPU (in MHz): The CPU speed of the cores that the system VM is allocated. For example, “2000” would provide for a 2 GHz clock.
+
+ Memory (in MB): The amount of memory in megabytes that the system VM should be allocated. For example, “2048” would provide for a 2 GB RAM allocation.
+
+ Network Rate: Allowed data transfer rate in MB per second.
+
+ Offer HA: If yes, the administrator can choose to have the system VM be monitored and as highly available as possible.
+
+ Storage Tags: The tags that should be associated with the primary storage used by the system VM.
+
+ Host Tags: (Optional) Any tags that you use to organize your hosts
+
+ CPU cap: Whether to limit the level of CPU usage even if spare capacity is available.
+
+ Public: Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.2. Creating a New Disk Offering
+ To create a system service offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Disk Offering.
+
+ Click Add Disk Offering.
+
+ In the dialog, make the following choices:
+
+ Name. Any desired name for the system offering.
+
+ Description. A short description of the offering that can be displayed to users
+
+ Custom Disk Size. If checked, the user can set their own disk size. If not checked, the root administrator must define a value in Disk Size.
+
+ Disk Size. Appears only if Custom Disk Size is not selected. Define the volume size in GB.
+
+ (Optional)Storage Tags. The tags that should be associated with the primary storage for this disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue". Tags are also added on Primary Storage. CloudStack matches tags on a disk offering to tags on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation from the disk offering will fail..
+
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.3. Modifying or Deleting a Service Offering
+ Service offerings cannot be changed once created. This applies to both compute offerings and disk offerings.
+
+ A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently. If the service offering is still in use, it will remain in the database until all the virtual machines referencing it have been deleted. After deletion by the administrator, a service offering will not be available to end users that are creating new instances.
+
8.2. System Service Offerings
+ System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the CloudStack root administrator. CloudStack provides default system service offerings. The CloudStack root administrator can create additional custom system service offerings.
+
+ When CloudStack creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering.
+
+ People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a CloudStack administrator, you can do the following things to set up networking for your users:
+
+ Set up physical networks in zones
+
+ Set up several different providers for the same service on a single physical network (for example, both Cisco and Juniper firewalls)
+
+ Bundle different types of network services into network offerings, so users can choose the desired network services for any given virtual machine
+
+ Add new network offerings as time goes on so end users can upgrade to a better class of service on their network
+
+ Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member
+
9.2. About Virtual Networks
+ A virtual network is a logical construct that enables multi-tenancy on a single physical network. In CloudStack a virtual network can be shared or isolated.
+
9.2.1. Isolated Networks
+ An isolated network can be accessed only by virtual machines of a single account. Isolated networks have the following properties.
+
+ Resources such as VLAN are allocated and garbage collected dynamically
+
+ There is one network offering for the entire network
+
+ The network offering can be upgraded or downgraded but it is for the entire network
+
9.2.2. Shared Networks
+ A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in CloudStack 3.0.3).
+
+ Shared Networks are created by the administrator
+
+ Shared Networks can be designated to a certain domain
+
+ Shared Network resources such as VLAN and physical network that it maps to are designated by the administrator
+
+ Shared Networks are isolated by security groups
+
+ Public Network is a shared network that is not shown to the end users
+
9.2.3. Runtime Allocation of Virtual Network Resources
+ When you define a new virtual network, all your settings for that network are stored in CloudStack. The actual network resources are activated only when the first virtual machine starts in the network. When all virtual machines have left the virtual network, the network resources are garbage collected so they can be allocated again. This helps to conserve network resources..
+
9.3. Network Service Providers
Note
+ For the most up-to-date list of supported network service providers, see the CloudPlatform UI or call listNetworkServiceProviders.
+
+ A service provider (also called a network element) is hardware or virtual appliance that makes a network service possible; for example, a firewall appliance can be installed in the cloud to provide firewall service. On a single network, multiple providers can provide the same network service. For example, a firewall service may be provided by Cisco or Juniper devices in the same physical network.
+
+ You can have multiple instances of the same service provider in a network (say, more than one Juniper SRX device).
+
+ If different providers are set up to provide the same service on the network, the administrator can create network offerings so users can specify which network service provider they prefer (along with the other choices offered in network offerings). Otherwise, CloudPlatform will choose which provider to use whenever the service is called for.
+
Supported Network Service Providers
+ CloudPlatform ships with an internal list of the supported service providers, and you can choose from this list when creating a network offering.
+
9.4. Network Offerings
Note
+ For the most up-to-date list of supported network services, see the CloudPlatform UI or call listNetworkServices.
+
+ A network offering is a named set of network services, such as:
+
+ DHCP
+
+ DNS
+
+ Source NAT
+
+ Static NAT
+
+ Port Forwarding
+
+ Load Balancing
+
+ Firewall
+
+ VPN
+
+ Optional) Name one of several available providers to use for a given service, such as Juniper for the firewall
+
+ (Optional) Network tag to specify which physical network to use
+
+ When creating a new VM, the user chooses one of the available network offerings, and that determines which network services the VM can use.
+
+ The CloudPlatform administrator can create any number of custom network offerings, in addition to the default network offerings provided by CloudPlatform. By creating multiple custom network offerings, you can set up your cloud to offer different classes of service on a single multi-tenant physical network. For example, while the underlying physical wiring may be the same for two tenants, tenant A may only need simple firewall protection for their website, while tenant B may be running a web server farm and require a scalable firewall solution, load balancing solution, and alternate networks for accessing the database backend.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudPlatform virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+ When creating a new virtual network, the CloudPlatform administrator chooses which network offering to enable for that network. Each virtual network is associated with one network offering. A virtual network can be upgraded or downgraded by changing its associated network offering. If you do this, be sure to reprogram the physical network to match.
+
+ CloudPlatform also has internal network offerings for use by CloudPlatform system VMs. These network offerings are not visible to users but can be modified by administrators.
+
+ CloudStack provides administrators with complete control over the lifecycle of all guest VMs executing in the cloud. CloudStack provides several guest management operations for end users and administrators. VMs may be stopped, started, rebooted, and destroyed.
+
+ Guest VMs have a name and group. VM names and groups are opaque to CloudStack and are available for end users to organize their VMs. Each VM can have three names for use in different contexts. Only two of these names can be controlled by the user:
+
+ Instance name – a unique, immutable ID that is generated by CloudStack and can not be modified by the user. This name conforms to the requirements in IETF RFC 1123.
+
+ Display name – the name displayed in the CloudStack web UI. Can be set by the user. Defaults to instance name.
+
+ Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to instance name
+
+ Guest VMs can be configured to be Highly Available (HA). An HA-enabled VM is monitored by the system. If the system detects that the VM is down, it will attempt to restart the VM, possibly on a different host. For more information, see HA-Enabled Virtual Machines on
+
+ Each new VM is allocated one public IP address. When the VM is started, CloudStack automatically creates a static NAT between this public IP address and the private IP address of the VM.
+
+ If elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new VM is not marked as elastic. The user must replace the automatically configured IP with a specifically acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s private IP. The VM’s original IP address is then released and returned to the pool of available public IPs.
+
+ CloudStack cannot distinguish a guest VM that was shut down by the user (such as with the “shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut down from inside the VM, CloudStack will restart it. To shut down an HA-enabled VM, you must go through the CloudStack UI or API.
+
10.2. Best Practices for Virtual Machines
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
10.3. VM Lifecycle
+ Virtual machines can be in the following states:
+
+ Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual machine will be reclaimed by the system. This includes the virtual machine’s IP address.
+
+ A stop will attempt to gracefully shut down the operating system, which typically involves terminating all the running applications. If the operation system cannot be stopped, it will be forcefully terminated. This has the same effect as pulling the power cord to a physical machine.
+
+ A reboot is a stop followed by a start.
+
+ CloudPlatform preserves the state of the virtual machine hard disk until the machine is destroyed.
+
+ A running virtual machine may fail because of hardware or network issues. A failed virtual machine is in the down state.
+
+ The system places the virtual machine into the down state if it does not receive the heartbeat from the hypervisor for three minutes.
+
+ The user can manually restart the virtual machine from the down state.
+
+ The system will start the virtual machine from the down state automatically if the virtual machine is marked as HA-enabled.
+
10.4. Creating VMs
+ Virtual machines are usually created from a template. Users can also create blank virtual machines. A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and install the OS from the CD/DVD-ROM.
+
+ To create a VM from a template:
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select a template, then follow the steps in the wizard. (For more information about how the templates came to be in this list, see Working with Templates.
+
+ Be sure that the hardware you have allows starting the selected service offering.
+
+ Click Submit and your VM will be created and started.
+
Note
+ For security reason, the internal name of the VM is visible only to the root admin.
+
Note
+ Starting with v3.0.3, you can create a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A new request parameter, startVM, is introduced in the deployVm API to support this feature. For more information, see the Developer's Guide
+
+ To create a VM from an ISO:
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select ISO Boot, and follow the steps in the wizard.
+
+ Click Submit and your VM will be created and started.
+
10.5. Accessing VMs
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
+ To access a VM through the CloudStack UI:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ Click Instances, then click the name of a running VM.
+
+ Click the View Console button .
+
+ To access a VM directly over the network:
+
+ The VM must have some port open to incoming traffic. For example, in a basic zone, a new VM might be assigned to a security group which allows incoming traffic. This depends on what security group you picked when creating the VM. In other cases, you can open a port by setting up a port forwarding policy. See IP Forwarding and Firewalling.
+
+ If a port is open but you can not access the VM using ssh, it’s possible that ssh is not already enabled on the VM. This will depend on whether ssh is enabled in the template you picked when creating the VM. Access the VM through the CloudStack UI and enable ssh on the machine using the commands for the VM’s operating system.
+
+ If the network has an external firewall device, you will need to create a firewall rule to allow access. See IP Forwarding and Firewalling.
+
10.6. Stopping and Starting VMs
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
10.7. Changing the VM Name, OS, or Group
+ After a VM is created, you can modify the display name, operating system, and the group it belongs to.
+
+ To access a VM through the CloudStack UI:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Select the VM that you want to modify.
+
+ Click the Stop button to stop the VM
+
+
+
+ Click Edit
+
+ .
+
+ Make the desired changes to the following:
+
+ Display name: Enter a new display name if you want to change the name of the VM.
+
+ OS Type: Select the desired operating system.
+
+ Group: Enter the group name for the VM.
+
+ Click Apply.
+
10.8. Changing the Service Offering for a VM
+ To upgrade or downgrade the level of compute resources available to a virtual machine, you can change the VM's compute offering.
+
+ Log in to the CloudStack UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to work with.
+
+ Click the Stop button to stop the VM
+
+
+
+ Click the Change Service button
+
+ . The Change service dialog box is displayed.
+
+ Select the offering you want.
+
+ Click OK.
+
10.9. Moving VMs Between Hosts (Manual Live Migration)
+ The CloudPlatform administrator can move a running VM from one host to another without interrupting service to users or going into maintenance mode. This is called manual live migration, and can be done under the following conditions:
+
+ The root administrator is logged in. Domain admins and users can not perform manual live migration of VMs.
+
+ The VM is running. Stopped VMs can not be live migrated.
+
+ The destination host must be in the same cluster as the original host.
+
+ The VM must not be using local disk storage.
+
+ The destination host must have enough available capacity. If not, the VM will remain in the "migrating" state until memory becomes available.
+
+ To manually live migrate a virtual machine
+
+ Log in to the CloudPlatform UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to migrate.
+
+ Click the Migrate Instance button
+
+
+
+ From the list of hosts, choose the one to which you want to move the VM.
+
+ Click OK.
+
10.10. Deleting VMs
+ Users can delete their own virtual machines. A running virtual machine will be abruptly stopped before it is deleted. Administrators can delete any virtual machines.
+
+ To delete a virtual machine:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to delete.
+
+ Click the Destroy Instance button
+
+
+
10.11. Working with ISOs
+ CloudStack supports ISOs and their attachment to guest VMs. An ISO is a read-only file that has an ISO/CD-ROM style file system. Users can upload their own ISOs and mount them on their guest VMs.
+
+ ISOs are uploaded based on a URL. HTTP is the supported protocol. Once the ISO is available via HTTP specify an upload URL such as http://my.web.server/filename.iso.
+
+ ISOs may be public or private, like templates.ISOs are not hypervisor-specific. That is, a guest on vSphere can mount the exact same image that a guest on KVM can mount.
+
+ ISO images may be stored in the system and made available with a privacy level similar to templates. ISO images are classified as either bootable or not bootable. A bootable ISO image is one that contains an OS image. CloudStack allows a user to boot a guest VM off of an ISO image. Users can also attach ISO images to guest VMs. For example, this enables installing PV drivers into Windows. ISO images are not hypervisor-specific.
+
10.11.1. Adding an ISO
+ To make additional operating system or other software available for use with guest VMs, you can add an ISO. The ISO is typically thought of as an operating system image, but you can also add ISOs for other types of software, such as desktop applications that you want to be installed as part of a template.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation bar, click Templates.
+
+ In Select View, choose ISOs.
+
+ Click Add ISO.
+
+ In the Add ISO screen, provide the following:
+
+ Name: Short name for the ISO image. For example, CentOS 6.2 64-bit.
+
+ Description: Display test for the ISO image. For example, CentOS 6.2 64-bit.
+
+ URL: The URL that hosts the ISO image. The Management Server must be able to access this location via HTTP. If needed you can place the ISO image directly on the Management Server
+
+ Zone: Choose the zone where you want the ISO to be available, or All Zones to make it available throughout CloudStack.
+
+ Bootable: Whether or not a guest could boot off this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not bootable.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of your desired ISO image is listed, choose it.
+
+ If the OS Type of the ISO is not listed or if the ISO is not bootable, choose Other.
+
+ (XenServer only) If you want to boot from this ISO in PV mode, choose Other PV (32-bit) or Other PV (64-bit)
+
+ (KVM only) If you choose an OS that is PV-enabled, the VMs created from this ISO will have a SCSI (virtio) root disk. If the OS is not PV-enabled, the VMs will have an IDE root disk. The PV-enabled types are:
+
+
+ Fedora 13
+
+
+
+ Fedora 12
+
+
+
+ Fedora 11
+
+
+
+ Fedora 10
+
+
+
+ Fedora 9
+
+
+
+ Other PV
+
+
+
+ Debian GNU/Linux
+
+
+
+ CentOS 5.3
+
+
+
+ CentOS 5.4
+
+
+
+ CentOS 5.5
+
+
+
+ Red Hat Enterprise Linux 5.3
+
+
+
+ Red Hat Enterprise Linux 5.4
+
+
+
+ Red Hat Enterprise Linux 5.5
+
+
+
+ Red Hat Enterprise Linux 6
+
+
+
Note
+ It is not recommended to choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not work. In these cases, choose Other.
+
+ Extractable: Choose Yes if the ISO should be available for extraction.
+
+ Public: Choose Yes if this ISO should be available to other users.
+
+ Featured: Choose Yes if you would like this ISO to be more prominent for users to select. The ISO will appear in the Featured ISOs list. Only an administrator can make an ISO Featured.
+
+ Click OK.
+
+ The Management Server will download the ISO. Depending on the size of the ISO, this may take a long time. The ISO status column will display Ready once it has been successfully downloaded into secondary storage. Clicking Refresh updates the download percentage.
+
+ Important: Wait for the ISO to finish downloading. If you move on to the next task and try to use the ISO right away, it will appear to fail. The entire ISO must be available before CloudStack can work with it.
+
10.11.2. Attaching an ISO to a VM
+ In the left navigation, click Instances.
+
+ Choose the virtual machine you want to work with.
+
+ Click the Attach ISO button
+
+
+ In the Attach ISO dialog box, select the desired ISO.
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs. For requirements and instructions, see Section 7.5, “Adding a Host”.
+
11.2. 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.
+
11.3. 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.
+
+
+
+ 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.
+
+
11.4. Removing Hosts
+ Hosts can be removed from the cloud as needed. The procedure to remove a host depends on the hypervisor type.
+
11.4.1. 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:
+
+ Then you may power down the Host, re-use its IP address, re-install it, etc
+
11.4.2. 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”. 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.
+
11.5. 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.
+
11.6. 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.
+
+ 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:
+
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".
+
mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;
11.8. Host Allocation
+ The system automatically picks the most appropriate host to run each virtual machine. End users may specify the zone in which the virtual machine will be created. End users do not have control over which host will run the virtual machine instance.
+
+ CloudStack administrators can specify that certain hosts should have a preference for particular types of guest instances. For example, an administrator could state that a host should have a preference to run Windows guests. The default host allocator will attempt to place guests of that OS type on such hosts first. If no such host is available, the allocator will place the instance wherever there is sufficient physical capacity.
+
+ Both vertical and horizontal allocation is allowed. Vertical allocation consumes all the resources of a given host before allocating any guests on a second host. This reduces power consumption in the cloud. Horizontal allocation places a guest on each host in a round-robin fashion. This may yield better performance to the guests in some cases. CloudStack also allows an element of CPU over-provisioning as configured by the administrator. Over-provisioning allows the administrator to commit more CPU cycles to the allocated guests than are actually available from the hardware.
+
+ CloudStack also provides a pluggable interface for adding new allocators. These custom allocators can provide any policy the administrator desires.
+
11.9. 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.
+
+ A template is a reusable configuration for virtual machines. When users launch VMs, they can choose from a list of templates in CloudStack.
+
+ Specifically, a template is a virtual disk image that includes one of a variety of operating systems, optional additional software such as office applications, and settings such as access control to determine who can use the template. Each template is associated with a particular type of hypervisor, which is specified when the template is added to CloudStack.
+
+ CloudStack ships with a default template. In order to present more choices to users, CloudStack administrators and users can create templates and add them to CloudStack.
+
12.1. Creating Templates: Overview
+ CloudStack ships with a default template for the CentOS operating system. There are a variety of ways to add more templates. Administrators and end users can add templates. The typical sequence of events is:
+
+ Launch a VM instance that has the operating system you want. Make any other desired configuration changes to the VM.
+
+ Stop the VM.
+
+ Convert the volume into a template.
+
+ There are other ways to add templates to CloudStack. For example, you can take a snapshot of the VM's volume and create a template from the snapshot, or import a VHD from another system into CloudStack
+
+ The various techniques for creating templates are described in the next few sections.
+
12.2. Requirements for Templates
+ For XenServer, install PV drivers / Xen tools on each template that you create. This will enable live migration and clean guest shutdown.
+
+ For vSphere, install VMware Tools on each template that you create. This will enable console view to work properly.
+
12.3. Best Practices for Templates
+ If you plan to use large templates (100 GB or larger), be sure you have a 10-gigabit network to support the large templates. A slower network can lead to timeouts and other errors when large templates are used.
+
12.4. The Default Template
+ CloudStack includes a CentOS template. This template is downloaded by the Secondary Storage VM after the primary and secondary storage are configured. You can use this template in your production deployment or you can delete it and use custom templates.
+
+ The root password for the default template is "password".
+
+ A default template is provided for each of XenServer, KVM, and vSphere. The templates that are downloaded depend on the hypervisor type that is available in your cloud. Each template is approximately 2.5 GB physical size.
+
+ The default template includes the standard iptables rules, which will block most access to the template excluding ssh.
+
+ When a user creates a template, it can be designated private or public.
+
+ Private templates are only available to the user who created them. By default, an uploaded template is private.
+
+ When a user marks a template as “public,” the template becomes available to all users in all accounts in the user's domain, as well as users in any other domains that have access to the Zone where the template is stored. This depends on whether the Zone, in turn, was defined as private or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any domain. If a public template is created in a private Zone, it is available only to users in the domain assigned to that Zone. If a public template is created in a public Zone, it is available to all users in all domains.
+
12.6. Creating a Template from an Existing Virtual Machine
+ Once you have at least one VM set up in the way you want, you can use it as the prototype for other VMs.
+
+ Make any desired configuration changes on the running VM, then click Stop.
+
+ Wait for the VM to stop. When the status shows Stopped, go to the next step.
+
+ Click Create Template and provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ OS Type. This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
+ If you want to boot from this template in PV mode, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServere:
+
Note
+ Note: Generally you should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates.
+
+ Click Add.
+
+ The new template will be visible in the Templates section when the template creation process has been completed. The template is then available when creating a new VM
+
+ If you are uploading a template that was created using vSphere Client, be sure the OVA file does not contain an ISO. If it does, the deployment of VMs from the template will fail.
+
+ Templates are uploaded based on a URL. HTTP is the supported access protocol. Templates are frequently large files. You can optionally gzip them to decrease upload times.
+
+ To upload a template:
+
+ In the left navigation bar, click Templates.
+
+ Click Create Template.
+
+ Provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ URL. The Management Server will download the file from the specified URL, such as http://my.web.server/filename.vhd.gz.
+
+ Zone. Choose the zone where you want the template to be available, or All Zones to make it available throughout CloudStack.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following:
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
Note
+ You should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Hypervisor
+
+ Format. The format of the template upload file, such as VHD or OVA.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates
+
+ Extractable. Choose Yes if the template is available for extraction. If this option is selected, end users can download a full image of a template.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”
+
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. The template will appear in the Featured Templates list. Only an administrator can make a template Featured.
+
12.9. Exporting Templates
+ End users and Administrators may export templates from the CloudStack. Navigate to the template in the UI and choose the Download function from the Actions menu.
+
12.10. Creating a Windows Template
+ Windows templates must be prepared with Sysprep before they can be provisioned on multiple machines. Sysprep allows you to create a generic Windows template and avoid any possible SID conflicts.
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Follow the steps in Sysprep for Windows Server 2008 R2 (below) or Sysprep for Windows Server 2003 R2, depending on your version of Windows Server
+
+ The preparation steps are complete. Now you can actually create the template as described in Creating the Windows Template.
+
12.10.1. System Preparation for Windows Server 2008 R2
+ For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location:
+
+ Windows AIK should not be installed on the Windows 2008 R2 VM you just created. Windows AIK should not be part of the template you create. It is only used to create the sysprep answer file.
+
+ Copy the install.wim file in the \sources directory of the Windows 2008 R2 installation DVD to the hard disk. This is a very large file and may take a long time to copy. Windows AIK requires the WIM file to be writable.
+
+ Start the Windows System Image Manager, which is part of the Windows AIK.
+
+ In the Windows Image pane, right click “Select a Windows image or catalog file” to load the install.wim file you just copied.
+
+ Select the Windows 2008 R2 Edition
+
+ You may be prompted with a warning that the catalog file cannot be opened. Click Yes to create a new catalog file.
+
+ In the Answer File pane, right click to create a new answer file.
+
+ Generate the answer file from the Windows System Image Manager using the following steps:
+
+ The first page you need to automate is the Language and Country or Region Selection page. To automate this, expand Components in your Windows Image pane, right-click and add the Microsoft-Windows-International-Core setting to Pass 7 oobeSystem. In your Answer File pane, configure the InputLocale, SystemLocale, UILanguage, and UserLocale with the appropriate settings for your language and country or region. Should you have a question about any of these settings, you can right-click on the specific setting and select Help. This will open the appropriate CHM help file with more information, including examples on the setting you are attempting to configure.
+
+ You need to automate the Software License Terms Selection page, otherwise known as the End-User License Agreement (EULA). To do this, expand the Microsoft-Windows-Shell-Setup component. High-light the OOBE setting, and add the setting to the Pass 7 oobeSystem. In Settings, set HideEULAPage true.
+
+ Make sure the license key is properly set. If you use MAK key, you can just enter the MAK key on the Windows 2008 R2 VM. You need not input the MAK into the Windows System Image Manager. If you use KMS host for activation you need not enter the Product Key. Details of Windows Volume Activation can be found at http://technet.microsoft.com/en-us/library/bb892849.aspx
+
+ You need to automate is the Change Administrator Password page. Expand the Microsoft-Windows-Shell-Setup component (if it is not still expanded), expand UserAccounts, right-click on AdministratorPassword, and add the setting to the Pass 7 oobeSystem configuration pass of your answer file. Under Settings, specify a password next to Value.
+
+ You may read the AIK documentation and set many more options that suit your deployment. The steps above are the minimum needed to make Windows unattended setup work.
+
+ Save the answer file as unattend.xml. You can ignore the warning messages that appear in the validation window.
+
+ Copy the unattend.xml file into the c:\windows\system32\sysprep directory of the Windows 2008 R2 Virtual Machine
+
+ Once you place the unattend.xml file in c:\windows\system32\sysprep directory, you run the sysprep tool as follows:
+
cd c:\Windows\System32\sysprep
+sysprep.exe /oobe /generalize /shutdown
+
+ The Windows 2008 R2 VM will automatically shut down after sysprep is complete.
+
12.10.2. Sysprep for Windows Server 2003 R2
+ Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2.
+
+ Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM.
+
+ Run c:\sysprep\setupmgr.exe to create the sysprep.inf file.
+
+ Select Create New to create a new Answer File.
+
+ Enter “Sysprep setup” for the Type of Setup.
+
+ Select the appropriate OS version and edition.
+
+ On the License Agreement screen, select “Yes fully automate the installation”.
+
+ Provide your name and organization.
+
+ Leave display settings at default.
+
+ Set the appropriate time zone.
+
+ Provide your product key.
+
+ Select an appropriate license mode for your deployment
+
+ Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up.
+
+ Leave Network Components at “Typical Settings”.
+
+ Select the “WORKGROUP” option.
+
+ Leave Telephony options at default.
+
+ Select appropriate Regional Settings.
+
+ Select appropriate language settings.
+
+ Do not install printers.
+
+ Do not specify “Run Once commands”.
+
+ You need not specify an identification string.
+
+ Save the Answer File as c:\sysprep\sysprep.inf.
+
+ Run the following command to sysprep the image:
+
c:\sysprep\sysprep.exe -reseal -mini -activated
+ After this step the machine will automatically shut down
+
12.11. Importing Amazon Machine Images
+ The following procedures describe how to import an Amazon Machine Image (AMI) into CloudStack when using the XenServer hypervisor.
+
+ Assume you have an AMI file and this file is called CentOS_6.2_x64. Assume further that you are working on a CentOS host. If the AMI is a Fedora image, you need to be working on a Fedora host initially.
+
+ You need to have a XenServer host with a file-based storage repository (either a local ext3 SR or an NFS SR) to convert to a VHD once the image file has been customized on the Centos/Fedora host.
+
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.
+
+ Determine the name of the PV kernel that has been installed into the image.
+
# cd /mnt/loop/centos62
+# ls lib/modules/
+2.6.16.33-xenU 2.6.16-xenU 2.6.18-164.15.1.el5xen 2.6.18-164.6.1.el5.centos.plus 2.6.18-xenU-ec2-v1.0 2.6.21.7-2.fc8xen 2.6.31-302-ec2
+# ls boot/initrd*
+boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
+# ls boot/vmlinuz*
+boot/vmlinuz-2.6.18-164.15.1.el5xen boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus boot/vmlinuz-2.6.18-xenU-ec2-v1.0 boot/vmlinuz-2.6.21-2952.fc8xen
+
+ Xen kernels/ramdisk always end with "xen". For the kernel version you choose, there has to be an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.
+
+ Based on your findings, create an entry in the grub.conf file. Below is an example entry.
+
+ Enable login via the console. The default console device in a XenServer system is xvc0. Ensure that etc/inittab and etc/securetty have the following lines respectively:
+
+ Copy the image file to your XenServer host's file-based storage repository. In the example below, the Xenserver is "xenhost". This XenServer has an NFS repository whose uuid is a9c5b8c8-536b-a193-a6dc-51af3e5ff799.
+
+ To convert a Hyper-V VM to a XenServer-compatible CloudStack template, you will need a standalone XenServer host with an attached NFS VHD SR. Use whatever XenServer version you are using with CloudStack, but use XenCenter 5.6 FP1 or SP2 (it is backwards compatible to 5.6). Additionally, it may help to have an attached NFS ISO SR.
+
+ For Linux VMs, you may need to do some preparation in Hyper-V before trying to get the VM to work in XenServer. Clone the VM and work on the clone if you still want to use the VM in Hyper-V. Uninstall Hyper-V Integration Components and check for any references to device names in /etc/fstab:
+
+ From the linux_ic/drivers/dist directory, run make uninstall (where "linux_ic" is the path to the copied Hyper-V Integration Components files).
+
+ Restore the original initrd from backup in /boot/ (the backup is named *.backup0).
+
+ Remove the "hdX=noprobe" entries from /boot/grub/menu.lst.
+
+ Check /etc/fstab for any partitions mounted by device name. Change those entries (if any) to mount by LABEL or UUID (get that information with the "blkid" command)..
+
+ The next step is make sure the VM is not running in Hyper-V, then get the VHD into XenServer. There are two options for doing this.
+
+ Option one:
+
+ Import the VHD using XenCenter. In XenCenter, go to Tools>Virtual Appliance Tools>Disk Image Import.
+
+ Choose the VHD, then click Next.
+
+ Name the VM, choose the NFS VHD SR under Storage, enable "Run Operating System Fixups" and choose the NFS ISO SR.
+
+ Click Next, then Finish. A VM should be created.
+
+ Option two
+
+ Run XenConvert, under From choose VHD, under To choose XenServer. Click Next.
+
+ Choose the VHD, then click Next.
+
+ Input the XenServer host info, then click Next.
+
+ Name the VM, then click Next, then Convert. A VM should be created
+
+ Once you have a VM created from the Hyper-V VHD, prepare it using the following steps:
+
+ Boot the VM, uninstall Hyper-V Integration Services, and reboot.
+
+ Either option above will create a VM in HVM mode. This is fine for Windows VMs, but Linux VMs may not perform optimally. Converting a Linux VM to PV mode will require additional steps and will vary by distribution.
+
+ Shut down the VM and copy the VHD from the NFS storage to a web server; for example, mount the NFS share on the web server and copy it, or from the XenServer host use sftp or scp to upload it to the web server.
+
+ In CloudStack, create a new template using the following values:
+
+ URL. Give the URL for the VHD
+
+ OS Type. Use the appropriate OS. For PV mode on CentOS, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServer.
+
+ Hypervisor. XenServer
+
+ Format. VHD
+
+ The template will be created, and you can create instances from it.
+
12.13. Adding Password Management to Your Templates
+ CloudStack provides an optional password reset feature that allows users to set a temporary admin or root password as well as reset the existing admin or root password from the CloudStack UI.
+
+ To enable the Reset Password feature, you will need to download an additional script to patch your template. When you later upload the template into CloudStack, you can specify whether reset admin/root password feature should be enabled for this template.
+
+ The password management feature works always resets the account password on instance boot. The script does an HTTP call to the virtual router to retrieve the account password that should be set. As long as the virtual router is accessible the guest will have access to the account password that should be used. When the user requests a password reset the management server generates and sends a new password to the virtual router for the account. Thus an instance reboot is necessary to effect any password changes.
+
+ If the script is unable to contact the virtual router during instance boot it will not set the password but boot will continue normally.
+
12.13.1. Linux OS Installation
+ Use the following steps to begin the Linux OS installation:
+
+ Download the script file cloud-set-guest-password:
+
+ On some Linux distributions, copy the file to /etc/rc.d/init.d.
+
+ Run the following command to make the script executable:
+
chmod +x /etc/init.d/cloud-set-guest-password
+ Depending on the Linux distribution, continue with the appropriate step.
+
+ On Fedora, CentOS/RHEL, and Debian, run:
+
chkconfig --add cloud-set-guest-password
12.13.2. Windows OS Installation
+ Download the installer, CloudInstanceManager.msi, from Download page and run the installer in the newly created Windows VM.
+
12.14. Deleting Templates
+ Templates may be deleted. In general, when a template spans multiple Zones, only the copy that is selected for deletion will be deleted; the same template in other Zones will not be deleted. The provided CentOS template is an exception to this. If the provided CentOS template is deleted, it will be deleted from all Zones.
+
+ When templates are deleted, the VMs instantiated from them will continue to run. However, new VMs cannot be created based on the deleted template.
+
+ CloudStack defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS.
+
+ There is no ephemeral storage in CloudStack. All volumes on all nodes are persistent.
+
13.2. Primary Storage
+ This section gives concepts and technical details about CloudPlatform primary storage. For information about how to install and configure primary storage through the CloudPlatform UI, see the Advanced Installation Guide.
+
13.3. Secondary Storage
+ This section gives concepts and technical details about CloudStack secondary storage. For information about how to install and configure secondary storage through the CloudStack UI, see the Advanced Installation Guide.
+
13.4. Using Swift for Secondary Storage
+ A volume provides storage to a guest VM. The volume can provide for a root disk or an additional data disk. CloudStack supports additional volumes for guest VMs.
+
+ Volumes are created for a specific hypervisor type. A volume that has been attached to guest using one hypervisor type (e.g, XenServer) may not be attached to a guest that is using another hypervisor type (e.g. vSphere, KVM). This is because the different hypervisors use different disk image formats.
+
+ CloudStack defines a volume as a unit of storage available to a guest VM. Volumes are either root disks or data disks. The root disk has "/" in the file system and is usually the boot device. Data disks provide for additional storage (e.g. As "/opt" or "D:"). Every guest VM has a root disk, and VMs can also optionally have a data disk. End users can mount multiple data disks to guest VMs. Users choose data disks from the disk offerings created by administrators. The user can create a template from a volume as well; this is the standard procedure for private template creation. Volumes are hypervisor-specific: a volume from one hypervisor type may not be used on a guest of another hypervisor type.
+
13.5. Working with Snapshots
+ (Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)
+
+ CloudStack supports snapshots of disk volumes. Snapshots are a point-in-time capture of virtual machine disks. Memory and CPU states are not captured.
+
+ Snapshots may be taken for volumes, including both root and data disks. The administrator places a limit on the number of stored snapshots per user. Users can create new volumes from the snapshot for recovery of particular files and they can create templates from snapshots to boot from a restored disk.
+
+ Users can create snapshots manually or by setting up automatic recurring snapshot policies. Users can also create disk volumes from snapshots, which may be attached to a VM like any other disk volume. Snapshots of both root disks and data disks are supported. However, CloudStack does not currently support booting a VM from a recovered root disk. A disk recovered from snapshot of a root disk is treated as a regular data disk; the data on recovered disk can be accessed by attaching the disk to a VM.
+
+ A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot.
+
+ The Usage Server is an optional, separately-installed part of CloudStack that provides aggregated usage records which you can use to create billing integration for CloudStack. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances.
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day.
+
14.1. Configuring the Usage Server
+ To configure the usage server:
+
+ Be sure the Usage Server has been installed. This requires extra steps beyond just installing the CloudStack software. See Installing the Usage Server (Optional) in the Advanced Installation Guide.
+
+ Log in to the CloudStack UI as administrator.
+
+ Click Global Settings.
+
+ In Search, type usage. Find the configuration parameter that controls the behavior you want to set. See the table below for a description of the available parameters.
+
+ In Actions, click the Edit icon.
+
+ Type the desired value and click the Save icon.
+
+ Restart the Management Server (as usual with any global configuration change) and also the Usage Server:
+
# service cloud-management restart
+# service cloud-usage restart
+
+ The following table shows the global configuration settings that control the behavior of the Usage Server.
+
+
+ Parameter Name
+
+
+
+ Description
+
+
+
+ enable.usage.server
+
+
+
+ Whether the Usage Server is active.
+
+
+
+ usage.aggregation.timezone
+
+
+
+ Time zone of usage records. Set this if the usage records and daily job execution are in different time zones. For example, with the following settings, the usage job will run at PST 00:15 and generate usage records for the 24 hours from 00:00:00 GMT to 23:59:59 GMT:
+
+ The time zone of usage.stats.job.exec.time. Valid values for the time zone are specified in Appendix A, Time Zones
+
+
+ Default: The time zone of the management server.
+
+
+
+
+ usage.sanity.check.interval
+
+
+
+ The number of days between sanity checks. Set this in order to periodically search for records with erroneous data before issuing customer invoices. For example, this checks for VM usage records created after the VM was destroyed, and similar checks for templates, volumes, and so on. It also checks for usage times longer than the aggregation range. If any issue is found, the alert ALERT_TYPE_USAGE_SANITY_RESULT = 21 is sent.
+
+
+
+ usage.stats.job.aggregation.range
+
+
+
+ The time period in minutes between Usage Server processing jobs. For example, if you set it to 1440, the Usage Server will run once per day. If you set it to 600, it will run every ten hours. In general, when a Usage Server job runs, it processes all events generated since usage was last run.
+
+
+ There is special handling for the case of 1440 (once per day). In this case the Usage Server does not necessarily process all records since Usage was last run. CloudStack assumes that you require processing once per day for the previous, complete day’s records. For example, if the current day is October 7, then it is assumed you would like to process records for October 6, from midnight to midnight. CloudStack assumes this "midnight to midnight" is relative to the usage.execution.timezone.
+
+
+ Default: 1440
+
+
+
+
+ usage.stats.job.exec.time
+
+
+
+ The time when the Usage Server processing will start. It is specified in 24-hour format (HH:MM) in the time zone of the server, which should be GMT. For example, to start the Usage job at 10:30 GMT, enter "10:30".
+
+
+ If usage.stats.job.aggregation.range is also set, and its value is not 1440, then its value will be added to usage.stats.job.exec.time to get the time to run the Usage Server job again. This is repeated until 24 hours have elapsed, and the next day's processing begins again at usage.stats.job.exec.time.
+
+
+ Default: 00:15.
+
+
+
+ For example, suppose that your server is in GMT, your user population is predominantly in the East Coast of the United States, and you would like to process usage records every night at 2 AM local (EST) time. Choose these settings:
+
+ enable.usage.server = true
+
+ usage.execution.timezone = America/New_York
+
+ usage.stats.job.exec.time = 07:00. This will run the Usage job at 2:00 AM EST. Note that this will shift by an hour as the East Coast of the U.S. enters and exits Daylight Savings Time.
+
+ usage.stats.job.aggregation.range = 1440
+
+ With this configuration, the Usage job will run every night at 2 AM EST and will process records for the previous day’s midnight-midnight as defined by the EST (America/New_York) time zone.
+
Note
+ Because the special value 1440 has been used for usage.stats.job.aggregation.range, the Usage Server will ignore the data between midnight and 2 AM. That data will be included in the next day's run
+
14.2. Setting Usage Limits
+ CloudStack provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis.
+
+ Aggregate limits may be set on a per-domain basis. For example, you may limit a domain and all subdomains to the creation of 100 VMs.
+
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+
+ The following table lists limits set in the Global Configuration:
+
+
+ Parameter Name
+
+
+
+ Definition
+
+
+
+ max.account.public.ips
+
+
+
+ Number of public IP addresses that can be owned by an account
+
+
+
+ max.account.snapshots
+
+
+
+ Number of snapshots that can exist for an account
+
+
+
+ max.account.templates
+
+
+
+ Number of templates that can exist for an account
+
+
+
+ max.account.user.vms
+
+
+
+ Number of virtual machine instances that can exist for an account
+
+
+
+ max.account.volumes
+
+
+
+ Number of disk volumes that can exist for an account
+
+
+
+ max.template.iso.size
+
+
+
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+ max.volume.size.gb
+
+
+
+ Maximum size for a volume in GB
+
+
+
+ network.throttling.rate
+
+
+
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+
+ snapshot.max.hourly
+
+
+
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+ snapshot.max.daily
+
+
+
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+
+ snapshot.max.weekly
+
+
+
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+ snapshot.max.monthly
+
+
+
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+ To modify global configuration parameters, use the global configuration screen in the CloudStack UI. See Setting Global Configuration Parameters
+
14.4. Default Account Resource Limits
+ You can limit resource use by accounts. The default limits are set using global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account (max.account.snapshots, etc.)..
+
+ To override a default limit for a particular account, set a per-account resource limit.
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Accounts.
+
+ Select the account you want to modify. The current limits are displayed. A value of -1 shows that there is no limit in place
+
+ Click the Edit button
+
+
14.5. Per-Domain Limits
+ CloudStack allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of all accounts in the domain as well as all accounts in all subdomains of that domain. Limits set at the root domain level apply to the sum of resource usage by the accounts in all domains and sub-domains below that root domain.
+
+ To set a domain limit:
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Domains.
+
+ Select the domain you want to modify. The current domain limits are displayed. A value of -1 shows that there is no limit in place.
+
+ In a CloudStack, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN. The CloudStack virtual router is the main component providing networking features for guest traffic.
+
15.1. Guest Traffic
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+
+ Figure 1 illustrates a typical guest traffic setup:
+
+ The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+
+ The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
+
+ Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
+
15.2. Networking in a Pod
+ Figure 2 illustrates network setup within a single pod. The hosts are connected to a pod-level switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
+
+ Servers are connected as follows:
+
+ Storage devices are connected to only the network that carries management traffic.
+
+ Hosts are connected to networks for both management traffic and public traffic.
+
+ Hosts are also connected to one or more networks carrying guest traffic.
+
+ We recommend the use of multiple physical Ethernet cards to implement each network interface as well as redundant switch fabric in order to maximize throughput and improve reliability.
+
15.3. Networking in a Zone
+ Figure 3 illustrates the network setup within a single zone.
+
+ A firewall for management traffic operates in the NAT mode. The network typically is assigned IP addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses in the 192.168.*.0/24 Class C private address space.
+
+ Each zone has its own set of public IP addresses. Public IP addresses from different zones do not overlap.
+
15.4. Basic Zone Physical Network Configuration
+ In a basic network, configuring the physical network is fairly straightforward. You only need to configure one guest network to carry traffic that is generated by guest VMs. When you first add a zone to CloudPlatform, you set up the guest network through the Add Zone screens.
+
15.5. Advanced Zone Physical Network Configuration
+ Within a zone that uses advanced networking, you need to tell the Management Server how the physical network is set up to carry different kinds of traffic in isolation.
+
15.5.1. Configure Guest Traffic in an Advanced Zone
+ These steps assume you have already logged in to the CloudStack UI. To configure the base guest network:
+
+ In the left navigation, choose Infrastructure. On Zones, click View More, then click the zone to which you want to add a network.
+
+ Click the Network tab.
+
+ Click Add guest network.
+
+ The Add guest network window is displayed:
+
+ Provide the following information:
+
+ Name. The name of the network. This will be user-visible
+
+ Display Text: The description of the network. This will be user-visible
+
+ Zone: The zone in which you are configuring the guest network.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network
+
+ Guest Gateway: The gateway that the guests should use
+
+ Guest Netmask: The netmask in use on the subnet the guests will use
+
+ Click OK.
+
15.5.2. Configure Public Traffic in an Advanced Zone
+ In a zone that uses advanced networking, you need to configure at least one range of IP addresses for Internet traffic.
+
15.6. Using Multiple Guest Networks
+ In zones that use advanced networking, additional networks for guest traffic may be added at any time after the initial installation. You can also customize the domain name associated with the network by specifying a DNS suffix for each network.
+
+ A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has been created, although the user can go into the guest and remove the IP address from the NIC on a particular network.
+
+ Each VM has just one default network. The virtual router's DHCP reply will set the guest's default gateway as that for the default network. Multiple non-default networks may be added to a guest in addition to the single, required default network. The administrator can control which networks are available as the default network.
+
+ Additional networks can either be available to all accounts or be assigned to a specific account. Networks that are available to all accounts are zone-wide. Any user with access to the zone can create a VM with access to that network. These zone-wide networks provide little or no isolation between guests.Networks that are assigned to a specific account provide strong isolation.
+
15.6.1. Adding an Additional Guest Network
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click Add guest network. Provide the following information:
+
+ Name: The name of the network. This will be user-visible.
+
+ Display Text: The description of the network. This will be user-visible.
+
+ Zone. The name of the zone this network applies to. Each zone is a broadcast domain, and therefore each zone has a different IP range for the guest network. The administrator must configure the IP range for each zone.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network.
+
+ Guest Gateway: The gateway that the guests should use.
+
+ Guest Netmask: The netmask in use on the subnet the guests will use.
+
+ Click Create.
+
15.6.2. Changing the Network Offering on a Guest Network
+ A user or administrator can change the network offering that is associated with an existing guest network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ If you are changing from a network offering that uses the CloudStack virtual router to one that uses external devices as network service providers, you must first stop all the VMs on the network. See Stopping and Starting VMs. Then return here and continue to the next step
+
+ In the left navigation, choose Network
+
+ Click the name of the network you want to modify
+
+ .
+
+ In Network Offering, choose the new network offering, then click Apply.
+
+ A prompt appears asking whether you want to keep the existing CIDR. This is to let you know that if you change the network offering, the CIDR will be affected. Choose No to proceed with the change.
+
+ Wait for the update to complete. Don’t try to restart VMs until after the network change is complete.
+
+ If you stopped any VMs in step 2, restart them.
+
15.7. Security Groups
15.7.1. About Security Groups
+ Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In CloudStack 3.0.3 - 3.0.5, security groups are supported only in zones that use basic networking.
+
Note
+ In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
+
+
+ Each CloudStack account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.
+
+ Any CloudStack user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.
+
+ You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.
+
+ If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
15.7.2. Adding a Security Group
+ A user or administrator can define a new security group.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups.
+
+ Click Add Security Group.
+
+ Provide a name and description.
+
+ Click OK.
+
+ The new security group appears in the Security Groups Details tab.
+
+ To make the security group useful, continue to Adding Ingress and Egress Rules to a Security Group.
+
15.7.3. Enabling Security Groups
+ In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide.
+
15.7.4. Adding Ingress and Egress Rules to a Security Group
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups, then click the security group you want .
+
+ To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify what network traffic is allowed into VM instances in this security group. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
+ Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow incoming traffic from all VMs in another security group
+
+ Protocol. The networking protocol that sources will use to send traffic to the security group. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be accepted.
+
+ CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To accept only traffic from another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter the same name you used in step 7.
+
+ The following example allows inbound HTTP access from anywhere:
+
+ To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been allowed in through an ingress rule
+
+ Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow outgoing traffic to all VMs in another security group.
+
+ Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
+
+ CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To allow traffic to be sent to another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter its name.
+
+ Click Add.
+
15.8. External Firewalls and Load Balancers
+ CloudStack is capable of replacing its Virtual Router with an external Juniper SRX device and an optional external NetScaler or F5 load balancer for gateway and load balancing services. In this case, the VMs use the SRX as their gateway.
+
15.9. Load Balancer Rules
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudStack virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
15.10. Guest IP Ranges
+ The IP ranges for guest network traffic are set on a per-account basis by the user. This allows the users to configure their network in a fashion that will enable VPN linking between their guest network and their clients.
+
15.11. Acquiring a New IP Address
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click the name of the network where you want to work with.
+
+ Click View IP Addresses.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.
+
15.12. Releasing an IP Address
+ Log in to the CloudPlatform UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click the name of the network where you want to work with.
+
+ Click View IP Addresses.
+
+ Click the IP address you want to release.
+
+ Click the Release IP button
+
+ .
+
15.13. Static NAT
+ A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
+
15.14. IP Forwarding and Firewalling
+ By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is translated via NAT to the public IP address and is allowed.
+
+ To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example, you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44. Then use port forwarding rules to direct traffic from individual ports within that range to specific ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public IP's port 33 to port 100 on one user VM's private IP.
+
+ For the steps to implement these rules, see Firewall Rules and Port Forwarding.
+
15.15. IP Load Balancing
+ The user may choose to associate the same public IP for multiple guests. CloudStack implements a TCP-level load balancer with the following policies.
+
+ Round-robin
+
+ Least connection
+
+ Source IP
+
+ This is similar to port forwarding but the destination may be multiple IP addresses.
+
15.16. DNS and DHCP
+ The Virtual Router provides DNS and DHCP services to the guests. It proxies DNS requests to the DNS server configured on the Availability Zone.
+
15.17. VPN
+ CloudStack account owners can create virtual private networks (VPN) to access their virtual machines. If the guest network is instantiated from a network offering that offers the Remote Access VPN service, the virtual router (based on the System VM) is used to provide the service. CloudStack provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN. CloudStack does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.
+
Note
+ Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
+
+ Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
+
+ Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.
+
15.17.1. Configuring VPN
+ To set up VPN for the cloud:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, click Global Settings.
+
+ Set the following global configuration parameters.
+
+ remote.access.vpn.client.ip.range – The range of IP addressess to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
+
+ remote.access.vpn.psk.length – Length of the IPSec key.
+
+ remote.access.vpn.user.limit – Maximum number of VPN users per account.
+
+ To enable VPN for a particular network:
+
+ Log in as a user or administrator to the CloudStack UI.
+
+ In the left navigation, click Network.
+
+ Click the name of the network you want to work with.
+
+ Click View IP Addresses.
+
+ Click one of the displayed IP address names.
+
+ Click the Enable VPN button
+
+ .
+
+ The IPsec key is displayed in a popup window.
+
15.17.2. Using VPN with Windows
+ The procedure to use VPN varies by Windows version. Generally, the user must edit the VPN properties and make sure that the default route is not the VPN. The following steps are for Windows L2TP clients on Windows Vista. The commands should be similar for other Windows versions.
+
+ Log in to the CloudStack UI and click on the source NAT IP for the account. The VPN tab should display the IPsec preshared key. Make a note of this and the source NAT IP. The UI also lists one or more users and their passwords. Choose one of these users, or, if none exists, add a user and password.
+
+ On the Windows box, go to Control Panel, then select Network and Sharing center. Click Setup a connection or network.
+
+ In the next dialog, select No, create a new connection.
+
+ In the next dialog, select Use my Internet Connection (VPN).
+
+ In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check Don't connect now.
+
+ In the next dialog, enter the user name and password selected in step 1.
+
+ Click Create.
+
+ Go back to the Control Panel and click Network Connections to see the new connection. The connection is not active yet.
+
+ Right-click the new connection and select Properties. In the Properties dialog, select the Networking tab.
+
+ In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key. Enter the preshared key from Step 1.
+
+ The connection is ready for activation. Go back to Control Panel -> Network Connections and double-click the created connection.
+
+ Enter the user name and password from Step 1.
+
15.17.3. Using VPN with Mac OS X
+ In Mac OS X, in Network Preferences - Advanced, make sure Send all traffic over VPN connection is not checked.
+
15.17.4. Setting Up a Site-to-Site VPN Connection
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+
+ Cisco ISR with IOS 12.4 or later
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
Note
+ In addition to the specific Cisco and Juniper devices listed above, the expectation is that any Cisco or Juniper device running on the supported operating systems are able to establish VPN connections.
+
+ To set up a Site-to-Site VPN connection, perform the following:
+
+ Create a VPN gateway for the VPC that you created.
+
+ Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
+
15.17.4.1. Creating and Updating a VPN Customer Gateway
Note
+ A VPN customer gateway can be connected to only one VPN gateway at a time.
+
+ To add a VPN Customer Gateway:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Click Add site-to-site VPN.
+
+ Provide the following information:
+
+ Name: A unique name for the VPN customer gateway you create.
+
+ Gateway: The IP address for the remote gateway.
+
+ CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be RFC1918-compliant.
+
+ IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share a secret key. This key value is used to authenticate the customer gateway and the VPC VPN gateway to each other.
+
Note
+ The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.
+
+ IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is accomplished through the Preshared Keys.
+
Note
+ The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.
+
+ IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.
+
+ IKE DH: A public-key cryptography protocol which allows two parties to establish a shared secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).
+
+ ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192, AES256, and 3DES.
+
Note
+ The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.
+
+ ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash algorithms are SHA1 and MD5.
+
+ Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised. This property enforces a new Diffie-Hellman key exchange. It provides the keying material that has greater key material life and thereby greater resistance to cryptographic attacks. The available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key exchanges increase as the DH groups grow larger, as does the time of the exchanges.
+
Note
+ When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.
+
+ IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is 86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.
+
+ ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a new IPsec encryption and authentication session keys.
+
+ Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual router to query the liveliness of its IKE peer at regular intervals. It’s recommended to have the same configuration of DPD on both side of VPN connection.
+
+ Click OK.
+
Updating and Removing a VPN Customer Gateway
+ You can update a customer gateway either with no VPN connection, or related VPN connection is in error state.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Select the VPN customer gateway you want to work with.
+
+ To modify the required parameters, click the Edit VPN Customer Gateway button
+
+
+ To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
+
+
+ Click OK.
+
15.17.4.2. Creating a VPN gateway for the VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Site-to-Site VPN.
+
+ If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN prompts you to create a VPN gateway.
+
+ In the confirmation dialog, click Yes to confirm.
+
+ Within a few moments, the VPN gateway is created. You will be prompted to view the details of the VPN gateway you have created. Click Yes to confirm.
+
+ The following details are displayed in the VPN Gateway page:
+
+ IP Address
+
+ Account
+
+ Domain
+
15.17.4.3. Creating a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you create for the account are listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ Click Create VPN Connection.
+
+ The Create VPN Connection dialog is displayed:
+
+ Select the desired customer gateway, then click OK to confirm.
+
+ Within a few moments, the VPN Connection is displayed.
+
+ The following information on the VPN connection is displayed:
+
+ IP Address
+
+ Gateway
+
+ State
+
+ IPSec Preshared Key
+
+ IKE Policy
+
+ ESP Policy
+
15.17.4.4. Restarting and Removing a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ All the VPN connections you created are displayed.
+
+ Select the VPN connection you want to work with.
+
+ The Details tab is displayed.
+
+ To remove a VPN connection, click the Delete VPN connection button
+
+
+ To restart a VPN connection, click the Reset VPN connection button present in the Details tab.
+
+
15.18. About Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You provision VLANs to the tiers your create, and VMs can be deployed on different tiers. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications, such as Web, Application, or Database. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+ The major advantages are:
+
+ The administrator can deploy a set of VLANs and allow users to deploy VMs on these VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that account.
+
Note
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+
+ The administrator can allow users create their own VPC and deploy the application. In this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that account.
+
+ Both administrators and users can create multiple VPCs. The guest network NIC is plugged to the VPC virtual router when the first VM is deployed in a tier.
+
+ The administrator can create the following gateways to send to or receive traffic from the VMs:
+
+ Public Gateway: The public gateway for a VPC is added to the virtual router when the virtual router is created for VPC. The public gateway is not exposed to the end users. You are not allowed to list it, nor allowed to create any static routes.
+
+ Both administrators and users can create various possible destinations-gateway combinations. However, only one gateway of each type can be used in a deployment.
+
+ For example:
+
+ VLANs and Public Gateway: For example, an application is deployed in the cloud, and the Web application VMs communicate with the Internet.
+
+ VLANs, VPN Gateway, and Public Gateway: For example, an application is deployed in the cloud; the Web application VMs communicate with the Internet; and the database VMs communicate with the on-premise devices.
+
+ The administrator can define Access Control List (ACL) on the virtual router to filter the traffic among the VLANs or between the Internet and a VLAN. You can define ACL based on CIDR, port range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress type.
+
+ The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
+
+ CloudStack Virtual Private Cloud is a private, isolated part of CloudStack. A VPC can have its own virtual network topology that resembles a traditional physical network. You can launch VMs in the virtual network that can have private addresses in the range of your choice, for example: 10.0.0.0/16. You can define network tiers within your VPC network range, which in turn enables you to group similar kinds of instances based on IP address range.
+
+ For example, if a VPC has the private range 10.0.0.0/16, its guest networks can have the network ranges 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on.
+
Major Components of a VPC:
+ A VPC is comprised of the following network components:
+
+ VPC: A VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router.
+
+ Network Tiers: Each tier acts as an isolated network with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
+
+ Virtual Router: A virtual router is automatically created and started when you create a VPC. The virtual router connect the tiers and direct traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and DHCP services through its IP.
+
+ Public Gateway: The traffic to and from the Internet routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to the end user; therefore, static routes are not support for the public gateway.
+
+ In a VPC, the following four basic options of network architectures are present:
+
+ VPC with a public gateway only
+
+ VPC with public and private gateways
+
+ VPC with public and private gateways and site-to-site VPN access
+
+ VPC with a private gateway only and site-to-site VPN access
+
Connectivity Options for a VPC
+ You can connect your VPC to:
+
+ The Internet through the public gateway.
+
+ The corporate datacenter by using a site-to-site VPN connection through the VPN gateway.
+
+ Both the Internet and your corporate datacenter by using both the public gateway and a VPN gateway.
+
VPC Network Considerations
+ Consider the following before you create a VPC:
+
+ A VPC, by default, is created in the enabled state.
+
+ A VPC can be created in Advance zone only, and can't belong to more than one zone at a time.
+
+ The default number of VPCs an account can create is 20. However, you can change it by using the max.account.vpcs global parameter, which controls the maximum number of VPCs an account is allowed to create.
+
+ The default number of tiers an account can create within a VPC is 3. You can configure this number by using the vpc.max.networks parameter.
+
+ Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be within the VPC CIDR range.
+
+ A tier belongs to only one VPC.
+
+ All network tiers inside the VPC should belong to the same account.
+
+ When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP is released only when the VPC is removed.
+
+ A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it cannot be used for StaticNAT or port forwarding.
+
+ The instances only have a private IP address that you provision. To communicate with the Internet, enable NAT to an instance that you launch in your VPC.
+
+ Only new networks can be added to a VPC. The maximum number of networks per VPC is limited by the value you specify in the vpc.max.networks parameter. The default value is three.
+
+ The load balancing service can be supported by only one tier inside the VPC.
+
+ If an IP address is assigned to a tier:
+
+ That IP can't be used by more than one tier at a time in the VPC. For example, if you have tiers A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A or B, but not for both.
+
+ That IP can't be used for StaticNAT, load balancing, or port forwarding rules for another guest network inside the VPC.
+
+ Remote access VPN is not supported in VPC networks.
+
15.19.2. Adding a Virtual Private Cloud
+ When creating the VPC, you simply provide the zone and a set of IP addresses for the VPC network address space. You specify this set of addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ Click Add VPC. The Add VPC page is displayed as follows:
+
+ Provide the following information:
+
+ Name: A short name for the VPC that you are creating.
+
+ Description: A brief description of the VPC.
+
+ Zone: Choose the zone where you want the VPC to be available.
+
+ Super CIDR for Guest Networks: Defines the CIDR range for all the tiers (guest networks) within a VPC. When you create a tier, ensure that its CIDR is within the Super CIDR value you enter. The CIDR must be RFC1918 compliant.
+
+ DNS domain for Guest Networks: If you want to assign a special domain name, specify the DNS suffix. This parameter is applied to all the tiers within the VPC. That implies, all the tiers you create in the VPC belong to the same DNS domain. If the parameter is not specified, a DNS domain name is generated automatically.
+
15.19.3. Adding Tiers
+ Tiers are distinct locations within a VPC that act as isolated networks, which do not have access to other tiers by default. Tiers are set up on different VLANs that can communicate with each other by using a virtual router. Tiers provide inexpensive, low latency network connectivity to other tiers within the VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
Note
+ The end users can see their own VPCs, while root and domain admin can see any VPC they are authorized to see.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Add new tier dialog is displayed, as follows:
+
+ If you have already created tiers, the VPC diagram is displayed. Click Create Tier to add a new tier.
+
+ Specify the following:
+
+ All the fields are mandatory.
+
+ Name: A unique name for the tier you create.
+
+ Network Offering: The following default network offerings are listed: DefaultIsolatedNetworkOfferingForVpcNetworksNoLB, DefaultIsolatedNetworkOfferingForVpcNetworks
+
+ In a VPC, only one tier can be created by using LB-enabled network offering.
+
+ Gateway: The gateway for the tier you create. Ensure that the gateway is within the Super CIDR range that you specified while creating the VPC, and is not overlapped with the CIDR of any existing tier within the VPC.
+
+ Netmask: The netmask for the tier you create.
+
+ For example, if the VPC CIDR is 10.0.0.0/16 and the network tier CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the netmask of the tier is 255.255.255.0.
+
+ Click OK.
+
+ Continue with configuring access control list for the tier.
+
15.19.4. Configuring Access Control List
+ Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service is supported.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Network ACLs.
+
+ The Network ACLs page is displayed.
+
+ Click Add Network ACLs.
+
+ To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed in this tier.
+
+ CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or to the IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Protocol: The networking protocol that sources use to send traffic to the tier. The TCP and UDP protocols are typically used for data exchange and end-user communications. The ICMP protocol is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ Select Tier: Select the tier for which you want to add this ACL rule.
+
+ ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
+
+ Traffic Type: Select the traffic type you want to apply.
+
+ Egress: To add an egress rule, select Egress from the Traffic type drop-down box and click Add. This specifies what type of traffic is allowed to be sent out of VM instances in this tier. If no egress rules are specified, all traffic from the tier is allowed out at the VPC virtual router. Once egress rules are specified, only the traffic specified in egress rules and the responses to any traffic that has been allowed in through an ingress rule are allowed out. No egress rule is required for the VMs in a tier to communicate with each other.
+
+ Ingress: To add an ingress rule, select Ingress from the Traffic type drop-down box and click Add. This specifies what network traffic is allowed into the VM instances in this tier. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
Note
+ By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, create a new network ACL.
+
+ Click Add. The ACL rule is added.
+
+ To view the list of ACL rules you have added, click the desired tier from the Network ACLs page, then select the Network ACL tab.
+
+ You can edit the tags assigned to the ACL rules and delete the ACL rules you have created. Click the appropriate button in the Actions column.
+
15.19.5. Adding a Private Gateway to a VPC
+ A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. No gateways with duplicated VLAN and IP are allowed in the same data center.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Private Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Private Gateways.
+
+ The Gateways page is displayed.
+
+ Click Add new gateway:
+
+ Specify the following:
+
+ Physical Network: The physical network you have created in the zone.
+
+ IP Address: The IP address associated with the VPC gateway.
+
+ Gateway: The gateway through which the traffic is routed to and from the VPC.
+
+ Netmask: The netmask associated with the VPC gateway.
+
+ VLAN: The VLAN associated with the VPC gateway.
+
+ The new gateway appears in the list. You can repeat these steps to add more gateway for this VPC.
+
15.19.6. Deploying VMs to the Tier
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed.
+
+ Click the Add VM button of the tier for which you want to add a VM.
+
+ The Add Instance page is displayed.
+
+ Follow the on-screen instruction to add an instance. For information on adding an instance, see Adding Instances section in the Installation Guide.
+
15.19.7. Acquiring a New IP Address for a VPC
+ When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks within the VPC. The IPs are associated to the guest network only when the first port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP can't be associated to more than one network at a time.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding, load balancing, and static NAT rules.
+
15.19.8. Releasing an IP Address Alloted to a VPC
+ The IP address is a limited resource. If you no longer need a particular IP, you can disassociate it from its VPC and return it to the pool of available addresses. An IP address can be released from its tier, only when all the networking ( port forwarding, load balancing, or StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC whose IP you want to release.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to release.
+
+ In the Details tab, click the Release IP button
+
+
15.19.9. Enabling or Disabling Static NAT on a VPC
+ A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to allow Internet traffic to it. This section tells how to enable or disable static NAT for a particular IP address in a VPC.
+
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to work with.
+
+ In the Details tab,click the Static NAT button.
+
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+
+ If you are enabling static NAT, a dialog appears as follows:
+
+ Select the tier and the destination VM, then click Apply.
+
15.19.10. Adding Load Balancing Rules on a VPC
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Load Balancing node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
Note
+ In a VPC, the load balancing service is supported only on a single tier.
+
+ Specify the following:
+
+ Name: A name for the load balancer rule.
+
+ Public Port: The port that receives the incoming traffic to be balanced.
+
+ Private Port: The port that the VMs will use to receive the traffic.
+
+ Algorithm. Choose the load balancing algorithm you want CloudStack to use. CloudStack supports the following well-known algorithms:
+
+ Round-robin
+
+ Least connections
+
+ Source
+
+ Stickiness. (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
+
+ Add VMs: Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.
+
+ The new load balancing rule appears in the list. You can repeat these steps to add more load balancing rules for this IP address.
+
15.19.11. Adding a Port Forwarding Rule on a VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Choose an existing IP address or acquire a new IP address. Click the name of the IP address in the list.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Port Forwarding node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
+ Specify the following:
+
+ Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+
+ Private Port: The port on which the instance is listening for forwarded public traffic.
+
+ Protocol: The communication protocol in use between the two ports.
+
+ TCP
+
+ UDP
+
+ Add VM: Click Add VM. Select the name of the instance to which this rule applies, and click Apply.
+
+ You can test the rule by opening an ssh session to the instance.
+
15.19.12. Removing Tiers
+ You can remove a tier from a VPC. A removed tier cannot be revoked. When a tier is removed, only the resources of the tier are expunged. All the network rules (port forwarding, load balancing and staticNAT) and the IP addresses associated to the tier are removed. The IP address still be belonging to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Configure VPC page is displayed. Locate the tier you want to work with.
+
+ Click the Remove VPC button:
+
+ Wait for some time for the tier to be removed.
+
15.19.13. Editing, Restarting, and Removing a Virtual Private Cloud
Note
+ Ensure that all the tiers are removed before you remove a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Select the VPC you want to work with.
+
+ To remove, click the Remove VPC button
+
+
+ You can edit the name and description of a VPC. To do that, select the VPC, then click the Edit button.
+
+
+ To restart a VPC, select the VPC, then click the Restart button.
+
+
+ CloudStack uses several types of system virtual machines to perform tasks in the cloud. In general CloudStack manages these system VMs and creates, starts, and stops them as needed based on scale and immediate needs. However, the administrator should be aware of them and their roles to assist in debugging issues.
+
16.1. The System VM Template
+ The System VMs come from a single template. The System VM has the following characteristics:
+
+ Debian 6.0 ("Squeeze"), 2.6.32 kernel with the latest security patches from the Debian security APT repository
+
+ Has a minimal set of packages installed thereby reducing the attack surface
+
+ 32-bit for enhanced performance on Xen/VMWare
+
+ pvops kernel with Xen PV drivers, KVM virtio drivers, and VMware tools for optimum performance on all hypervisors
+
+ Latest versions of HAProxy, iptables, IPsec, and Apache from debian repository ensures improved security and speed
+
+ Latest version of JRE from Sun/Oracle ensures improved security and speed
+
16.2. Multiple System VM Support for VMware
+ Every CloudStack zone has single System VM for template processing tasks such as downloading templates, uploading templates, and uploading ISOs. In a zone where VMware is being used, additional System VMs can be launched to process VMware-specific tasks such as taking snapshots and creating private templates. The CloudStack management server launches additional System VMs for VMware-specific tasks as the load increases. The management server monitors and weights all commands sent to these System VMs and performs dynamic load balancing and scaling-up of more System VMs.
+
16.3. Console Proxy
+ The Console Proxy is a type of System Virtual Machine that has a role in presenting a console view via the web UI. It connects the user’s browser to the VNC port made available via the hypervisor for the console of the guest. Both the administrator and end user web UIs offer a console connection.
+
+ Clicking on a console icon brings up a new window. The AJAX code downloaded into that window refers to the public IP address of a console proxy VM. There is exactly one public IP address allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then proxies the connection to the VNC port for the requested VM on the Host hosting the guest. .
+
Note
+ The hypervisors will have many ports assigned to VNC usage so that multiple VNC sessions can occur simultaneously.
+
+ There is never any traffic to the guest virtual IP, and there is no need to enable VNC within the guest.
+
+ The console proxy VM will periodically report its active session count to the Management Server. The default reporting interval is five seconds. This can be changed through standard Management Server configuration with the parameter consoleproxy.loadscan.interval.
+
+ Assignment of guest VM to console proxy is determined by first determining if the guest VM has a previous session associated with a console proxy. If it does, the Management Server will assign the guest VM to the target Console Proxy VM regardless of the load on the proxy VM. Failing that, the first available running Console Proxy VM that has the capacity to handle new sessions is used.
+
+ Console proxies can be restarted by administrators but this will interrupt existing console sessions for users.
+
+ The console viewing functionality uses a dynamic DNS service under the domain name realhostip.com to assist in providing SSL security to console sessions. The console proxy is assigned a public IP address. In order to avoid browser warnings for mismatched SSL certificates, the URL for the new console window is set to the form of https://aaa-bbb-ccc-ddd.realhostip.com. Customers will see this URL during console session creation. CloudStack includes the realhostip.com SSL certificate in the console proxy VM. Of course, CloudStack cannot know about DNS A records for our customers' public IPs prior to shipping the software. CloudStack therefore runs a dynamic DNS server that is authoritative for the realhostip.com domain. It maps the aaa-bbb-ccc-ddd part of the DNS name to the IP address aaa.bbb.ccc.ddd on lookups. This allows the browser to correctly connect to the console proxy's public IP, where it then expects and receives a SSL certificate for realhostip.com, and SSL is set up without browser warnings.
+
16.4. Virtual Router
+ The virtual router is a type of System Virtual Machine. The virtual router is one of the most frequently used service providers in CloudStack. The end user has no direct access to the virtual router. Users can ping the virtual router and take actions that affect it (such as setting up port forwarding), but users do not have SSH access into the virtual router.
+
+ There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be restarted by administrators, but this will interrupt public network access and other services for end users. A basic test in debugging networking issues is to attempt to ping the virtual router from a guest VM. Some of the characteristics of the virtual router are determined by its associated system service offering.
+
16.5. Secondary Storage VM
+ In addition to the hosts, CloudStack’s Secondary Storage VM mounts and writes to secondary storage.
+
+ Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols.
+
+ The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups.
+
+ The administrator can log in to the secondary storage VM if needed.
+
Chapter 17. System Reliability and High Availability
+ The CloudStack Management Server should be deployed in a multi-node configuration such that it is not susceptible to individual server failures. The Management Server itself (as distinct from the MySQL database) is stateless and may be placed behind a load balancer.
+
+ Normal operation of Hosts is not impacted by an outage of all Management Serves. All guest VMs will continue to work.
+
+ When the Management Server is down, no new VMs can be created, and the end user and admin UI, API, dynamic load distribution, and HA will cease to work.
+
17.2. HA-Enabled Virtual Machines
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
17.3. HA for Hosts
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
17.4. Primary Storage Outage and Data Loss
+ When a primary storage outage occurs the hypervisor immediately stops all VMs stored on that storage device. Guests that are marked for HA will be restarted as soon as practical when the primary storage comes back on line. With NFS, the hypervisor may allow the virtual machines to continue running depending on the nature of the issue. For example, an NFS hang will cause the guest VMs to be suspended until storage connectivity is restored.Primary storage is not designed to be backed up. Individual volumes in primary storage can be backed up using snapshots.
+
17.5. Secondary Storage Outage and Data Loss
+ For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online.
+
+ Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system.
+
18.1. 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:
+
+ The following API commands have the "tags" input parameter:
+
+ listVirtualMachines
+
+ listVolumes
+
+ listSnapshots
+
+ listNetworks
+
+ listTemplates
+
+ listIsos
+
+ listFirewallRules
+
+ listPortForwardingRules
+
+ listPublicIpAddresses
+
+ listSecurityGroups
+
+ listLoadBalancerRules
+
+ listProjects
+
+ listVPCs
+
+ listNetworkACLs
+
+ listStaticRoutes
+
18.2. Changing the Database Configuration
+ The CloudStack Management Server stores database configuration information (e.g., hostname, port, credentials) in the file /etc/cloud/management/db.properties. To effect a change, edit this file on each Management Server, then restart the Management Server.
+
18.3. 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
+
18.4. 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” 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.
+
18.5. 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:
+
# service cloud-management stop
+ To start the Management Server:
+
# service cloud-management start
+ To stop the Management Server:
+
# service cloud-management stop
Chapter 19. Setting Global Configuration Parameters
+ CloudStack provides parameters that you can set to control many aspects of the cloud. When CloudStack is first installed, and periodically thereafter, you might need to modify these settings.
+
+ Log in to the UI as administrator.
+
+ In the left navigation bar, click Global Settings.
+
+ In Select View, choose one of the following:
+
+ Global Settings. This displays a list of the parameters with brief descriptions and current values.
+
+ Hypervisor Capabilities. This displays a list of hypervisor versions with the maximum number of guests supported for each.
+
+ Use the search box to narrow down the list to those you are interested in.
+
+ Click the Edit icon to modify a value. If you are viewing Hypervisor Capabilities, you must click the name of the hypervisor first to display the editing screen.
+
+ 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.
+
+ 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.
+
20.2. Allocators
+ CloudStack enables administrators to write custom allocators that will choose the Host to place a new guest and the storage host from which to allocate guest virtual disk images.
+
20.3. User Data and Meta Data
+ CloudStack provides API access to attach 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.
+
+ Access user data by running the following command using the result of the above command
+
# 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
+
+ This section provides tips on how to improve the performance of your cloud.
+
21.1. Performance Monitoring
+ Host and guest performance monitoring is available to end users and administrators. This allows the user to monitor their utilization of resources and determine when it is appropriate to choose a more powerful service offering or larger disk.
+
21.2. Increase Management Server Maximum Memory
+ If the Management Server is subject to high demand, the default maximum JVM memory allocation can be insufficient. To increase the memory:
+
+ Edit the Tomcat configuration file:
+
/etc/cloud/management/tomcat6.conf
+ Change the command-line parameter -XmxNNNm to a higher value of N.
+
+ For example, if the current value is -Xmx128m, change it to -Xmx1024m or higher.
+
+ To put the new setting into effect, restart the Management Server.
+
# service cloud-management restart
+ For more information about memory issues, see "FAQ: Memory" at Tomcat Wiki.
+
21.3. Set Database Buffer Pool Size
+ It is important to provide enough memory space for the MySQL database to cache data and indexes:
+
+ Edit the Tomcat configuration file:
+
/etc/my.cnf
+ Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM.
+
innodb_buffer_pool_size=700M
+ Restart the MySQL service.
+
# service mysqld restart
+ For more information about the buffer pool, see "The InnoDB Buffer Pool" at MySQL Reference Manual.
+
21.4. Set and Monitor Total VM Limits per Host
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
21.5. Configure XenServer dom0 Memory
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+
+ 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..
+
22.1.2. 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
+
22.1.3. 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
+
22.1.4. 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
+
22.2. Working with Server Logs
+ The CloudStack Management Server logs all web site, middle tier, and database activities for diagnostics purposes in /var/log/cloud/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.
+
+ 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:
+
+ 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:
+
+ grep "job-1076)" management-server.log
+
+ The CloudStack Agent Server logs its activities in /var/log/cloud/agent/.
+
22.3. 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:
+
+ 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
+
22.4. 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.
+
+ Host was placed in maintenance mode, but still appears live in vCenter.
+
Cause
+ The CloudPlatform 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.
+
22.6. 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.
+
22.7. 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.
+
22.8. 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 CloudPlatform 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.
+
Time Zones
+ 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
+
+
+
+
+
Event Types
+
+ VM.CREATE
+
+
+
+ TEMPLATE.EXTRACT
+
+
+
+ SG.REVOKE.INGRESS
+
+
+
+ VM.DESTROY
+
+
+
+ TEMPLATE.UPLOAD
+
+
+
+ HOST.RECONNECT
+
+
+
+ VM.START
+
+
+
+ TEMPLATE.CLEANUP
+
+
+
+ MAINT.CANCEL
+
+
+
+ VM.STOP
+
+
+
+ VOLUME.CREATE
+
+
+
+ MAINT.CANCEL.PS
+
+
+
+ VM.REBOOT
+
+
+
+ VOLUME.DELETE
+
+
+
+ MAINT.PREPARE
+
+
+
+ VM.UPGRADE
+
+
+
+ VOLUME.ATTACH
+
+
+
+ MAINT.PREPARE.PS
+
+
+
+ VM.RESETPASSWORD
+
+
+
+ VOLUME.DETACH
+
+
+
+ VPN.REMOTE.ACCESS.CREATE
+
+
+
+ ROUTER.CREATE
+
+
+
+ VOLUME.UPLOAD
+
+
+
+ VPN.USER.ADD
+
+
+
+ ROUTER.DESTROY
+
+
+
+ SERVICEOFFERING.CREATE
+
+
+
+ VPN.USER.REMOVE
+
+
+
+ ROUTER.START
+
+
+
+ SERVICEOFFERING.UPDATE
+
+
+
+ NETWORK.RESTART
+
+
+
+ ROUTER.STOP
+
+
+
+ SERVICEOFFERING.DELETE
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+ ROUTER.REBOOT
+
+
+
+ DOMAIN.CREATE
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+ ROUTER.HA
+
+
+
+ DOMAIN.DELETE
+
+
+
+ STATICNAT.DISABLE
+
+
+
+ PROXY.CREATE
+
+
+
+ DOMAIN.UPDATE
+
+
+
+ SSVM.CREATE
+
+
+
+ PROXY.DESTROY
+
+
+
+ SNAPSHOT.CREATE
+
+
+
+ SSVM.DESTROY
+
+
+
+ PROXY.START
+
+
+
+ SNAPSHOT.DELETE
+
+
+
+ SSVM.START
+
+
+
+ PROXY.STOP
+
+
+
+ SNAPSHOTPOLICY.CREATE
+
+
+
+ SSVM.STOP
+
+
+
+ PROXY.REBOOT
+
+
+
+ SNAPSHOTPOLICY.UPDATE
+
+
+
+ SSVM.REBOOT
+
+
+
+ PROXY.HA
+
+
+
+ SNAPSHOTPOLICY.DELETE
+
+
+
+ SSVM.H
+
+
+
+ VNC.CONNECT
+
+
+
+ VNC.DISCONNECT
+
+
+
+ NET.IPASSIGN
+
+
+
+ NET.IPRELEASE
+
+
+
+ NET.RULEADD
+
+
+
+ NET.RULEDELETE
+
+
+
+ NET.RULEMODIFY
+
+
+
+ NETWORK.CREATE
+
+
+
+ NETWORK.DELETE
+
+
+
+ LB.ASSIGN.TO.RULE
+
+
+
+ LB.REMOVE.FROM.RULE
+
+
+
+ LB.CREATE
+
+
+
+ LB.DELETE
+
+
+
+ LB.UPDATE
+
+
+
+ USER.LOGIN
+
+
+
+ USER.LOGOUT
+
+
+
+ USER.CREATE
+
+
+
+ USER.DELETE
+
+
+
+ USER.UPDATE
+
+
+
+ USER.DISABLE
+
+
+
+ TEMPLATE.CREATE
+
+
+
+ TEMPLATE.DELETE
+
+
+
+ TEMPLATE.UPDATE
+
+
+
+ TEMPLATE.COPY
+
+
+
+ TEMPLATE.DOWNLOAD.START
+
+
+
+ TEMPLATE.DOWNLOAD.SUCCESS
+
+
+
+ TEMPLATE.DOWNLOAD.FAILED
+
+
+
+ ISO.CREATE
+
+
+
+ ISO.DELETE
+
+
+
+ ISO.COPY
+
+
+
+ ISO.ATTACH
+
+
+
+ ISO.DETACH
+
+
+
+ ISO.EXTRACT
+
+
+
+ ISO.UPLOAD
+
+
+
+ SERVICE.OFFERING.CREATE
+
+
+
+ SERVICE.OFFERING.EDIT
+
+
+
+ SERVICE.OFFERING.DELETE
+
+
+
+ DISK.OFFERING.CREATE
+
+
+
+ DISK.OFFERING.EDIT
+
+
+
+ DISK.OFFERING.DELETE
+
+
+
+ NETWORK.OFFERING.CREATE
+
+
+
+ NETWORK.OFFERING.EDIT
+
+
+
+ NETWORK.OFFERING.DELETE
+
+
+
+ POD.CREATE
+
+
+
+ POD.EDIT
+
+
+
+ POD.DELETE
+
+
+
+ ZONE.CREATE
+
+
+
+ ZONE.EDIT
+
+
+
+ ZONE.DELETE
+
+
+
+ VLAN.IP.RANGE.CREATE
+
+
+
+ VLAN.IP.RANGE.DELETE
+
+
+
+ CONFIGURATION.VALUE.EDIT
+
+
+
+ SG.AUTH.INGRESS
+
+
+
+
+
Alerts
+ The following is the list of alert type numbers. The current alerts can be found by calling listAlerts.
+
MEMORY = 0
CPU = 1
STORAGE =2
STORAGE_ALLOCATED = 3
PUBLIC_IP = 4
PRIVATE_IP = 5
HOST = 6
USERVM = 7
DOMAIN_ROUTER = 8
CONSOLE_PROXY = 9
ROUTING = 10// lost connection to default route (to the gateway)
STORAGE_MISC = 11 // lost connection to default route (to the gateway)
USAGE_SERVER = 12 // lost connection to default route (to the gateway)
MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)
DOMAIN_ROUTER_MIGRATE = 14
CONSOLE_PROXY_MIGRATE = 15
USERVM_MIGRATE = 16
VLAN = 17
SSVM = 18
USAGE_SERVER_RESULT = 19
STORAGE_DELETE = 20;
UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource count
USAGE_SANITY_RESULT = 22;
DIRECT_ATTACHED_PUBLIC_IP = 23;
LOCAL_STORAGE = 24;
RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only
+ You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate CloudStack end-users. Just map CloudStack accounts to the corresponding LDAP accounts using a query filter. The query filter is written using the query syntax of the particular LDAP server, and can include special wildcard characters provided by CloudStack for matching common values such as the user’s email address and name. CloudStack will search the external LDAP directory tree starting at a specified base directory and return the distinguished name (DN) and password of the matching user. This information along with the given password is used to authenticate the user..
+
+ To set up LDAP authentication in CloudStack, call the CloudStack API command ldapConfig and provide the following:
+
+ Hostname or IP address and listening port of the LDAP server
+
+ Base directory and query filter
+
+ Search user DN credentials, which give CloudStack permission to search on the LDAP server
+
+ SSL keystore and password, if SSL is used
+
3.2.1. Example LDAP Configuration Commands
+ To understand the examples in this section, you need to know the basic concepts behind calling the CloudStack API, which are explained in the Developer’s Guide.
+
+ The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
+
+ 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.
+
+ The next few sections explain some of the concepts you will need to know when filling out the ldapConfig parameters.
+
3.2.2. Search Base
+ An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The search base is the distinguished name (DN) of a level of the directory tree below which all users can be found. The users can be in the immediate base directory or in some subdirectory. The search base may be equivalent to the organization, group, or domain name. The syntax for writing a DN varies depending on which LDAP server you are using. A full discussion of distinguished names is outside the scope of our documentation. The following table shows some examples of search bases to find users in the testing department..
+
+
+ LDAP Server
+
+
+
+ Example Search Base DN
+
+
+
+ ApacheDS
+
+
+
+ ou=testing,o=project
+
+
+
+ Active Directory
+
+
+
+ OU=testing, DC=company
+
+
3.2.3. Query Filter
+ The query filter is used to find a mapped user in the external LDAP server. The query filter should uniquely map the CloudPlatform user to LDAP user for a meaningful authentication. For more information about query filter syntax, consult the documentation for your LDAP server.
+
+ The CloudPlatform 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 CloudPlatform user name is the same as the LDAP user ID:
+
(uid=%u)
+ If the CloudPlatform user name is the LDAP display name:
+
(displayName=%u)
+ To find a user by email address:
+
(mail=%e)
3.2.4. Search User Bind DN
+ The bind DN is the user on the external LDAP server permitted to search the LDAP directory within the defined search base. When the DN is returned, the DN and passed password are used to authenticate the CloudStack user with an LDAP bind. A full discussion of bind DNs is outside the scope of our documentation. The following table shows some examples of bind DNs.
+
+ 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.
+
+ A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set of KVM servers, , or a VMware cluster preconfigured in vCenter. The hosts in a cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the same shared primary storage. Virtual machine instances (VMs) can be live-migrated from one host to another within the same cluster, without interrupting service to the user.
+
+ A cluster is the third-largest organizational unit within a CloudStack deployment. Clusters are contained within pods, and pods are contained within zones. Size of the cluster is limited by the underlying hypervisor, although the CloudStack recommends less in most cases; see Best Practices.
+
+ A cluster consists of one or more hosts and one or more primary storage servers.
+
+ CloudStack allows multiple clusters in a cloud deployment.
+
+ Even when local storage is used exclusively, clusters are still required organizationally, even if there is just one host per cluster.
+
+ When VMware is used, every VMware cluster is managed by a vCenter server. Administrator must register the vCenter server with CloudStack. There may be multiple vCenter servers per zone. Each vCenter server may manage multiple VMware clusters.
+
+ A host is a single computer. Hosts provide the computing resources that run the guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a Linux KVM-enabled server, a Citrix XenServer server, and an ESXi server are hosts.
+
+ The host is the smallest organizational unit within a CloudStack deployment. Hosts are contained within clusters, clusters are contained within pods, and pods are contained within zones.
+
+ Hosts in a CloudStack deployment:
+
+ Provide the CPU, memory, storage, and networking resources needed to host the virtual machines
+
+ Interconnect using a high bandwidth TCP/IP network and connect to the Internet
+
+ May reside in multiple data centers across different geographic locations
+
+ May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the hosts within a cluster must all be homogeneous
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs.
+
+ CloudStack automatically detects the amount of CPU and memory resources provided by the Hosts.
+
+ Hosts are not visible to the end user. An end user cannot determine which host their guest has been assigned to.
+
+ For a host to function in CloudStack, you must do the following:
+
+ Install hypervisor software on the host
+
+ Assign an IP address to the host
+
+ Ensure the host is connected to the CloudStack Management Server
+
+ Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical networks can be associated with each zone. The network corresponds to a NIC on the hypervisor host. Each physical network can carry one or more types of network traffic. The choices of traffic type for each network vary depending on whether you are creating a zone with basic networking or advanced networking.
+
+ A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can:
+
+ Add/Remove/Update physical networks in a zone
+
+ Configure VLANs on the physical network
+
+ Configure a name so the network can be recognized by hypervisors
+
+ Configure the service providers (firewalls, load balancers, etc.) available on a physical network
+
+ Configure the IP addresses trunked to a physical network
+
+ Specify what type of traffic is carried on the physical network, as well as other properties like network speed
+
2.7.1. Configurable Characteristics of Physical Networks
+ CloudStack provides configuration settings you can use to set up a physical network in a zone, including:
+
+ What type of network traffic it carries (guest, public, management, storage)
+
+ VLANs
+
+ Unique name that the hypervisor can use to find that particular network
+
+ Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator sets the physical network to enabled, and it begins to be used. The administrator can later disable the network again, which prevents any new virtual networks from being created on that physical network; the existing network traffic continues even though the state is disabled.
+
+ Speed
+
+ Tags, so network offerings can be matched to physical networks
+
+ Isolation method
+
2.7.2. Basic Zone Network Traffic Types
+ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
Note
+ We strongly recommend the use of separate NICs for management traffic and guest traffic.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. CloudStack takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.
+
2.7.3. Basic Zone Guest IP Addresses
+ When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts.
+
2.7.4. Advanced Zone Network Traffic Types
+ When advanced networking is used, there can be multiple physical networks in the zone. Each physical network can carry one or more traffic types, and you need to let CloudStack know which type of network traffic you want each network to carry. The traffic types in an advanced zone are:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each CloudStack account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices.
+
2.7.5. Advanced Zone Guest IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.6. Advanced Zone Public IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.7. System Reserved IP Addresses
+ In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the CloudStack Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
+
+ The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone.
+
+ The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in.
+
+ Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. CloudStack can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
+
+ In all zones:
+
+ Provide private IPs for the system in each pod and provision them in CloudStack.
+
+ For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.
+
+ In a zone that uses advanced networking:
+
+ For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required CloudStack System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.
+
+ When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
+
+ To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:
+
+ Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than 4,000 IP addresses.
+
+ Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod has 255 IPs, this will provide 2,550 IP addresses.
+
+ A pod often represents a single rack. Hosts in the same pod are in the same subnet.
+
+ A pod is the second-largest organizational unit within a CloudStack deployment. Pods are contained within zones. Each zone can contain one or more pods.
+
+ Pods are not visible to the end user.
+
+ A pod consists of one or more clusters of hosts and one or more primary storage servers.
+
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required. It is typically located close to the hosts for increased performance.
+
+ CloudStack is designed to work with all standards-compliant iSCSI and NFS servers that are supported by the underlying hypervisor, including, for example:
+
+ Dell EqualLogic™ for iSCSI
+
+ Network Appliances filers for NFS and iSCSI
+
+ Scale Computing for NFS
+
+ If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.
+
+ Secondary storage is associated with a zone, and it stores the following:
+
+ Templates — OS images that can be used to boot VMs and can include additional configuration information, such as installed applications
+
+ ISO images — disc images containing data or bootable media for operating systems
+
+ Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
+
+ The items in zone-based NFS secondary storage are available to all hosts in the zone. CloudStack manages the allocation of guest virtual disks to particular primary storage devices.
+
+ To make items in secondary storage available to all hosts throughout the cloud, you can add OpenStack Object Storage (Swift, swift.openstack.org) in addition to the zone-based NFS secondary storage. When using Swift, you configure Swift storage for the entire CloudStack, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere.
+
+ A virtual network is a logical construct that enables multi-tenancy on a single physical network. In CloudStack a virtual network can be shared or isolated.
+
9.2.1. Isolated Networks
+ An isolated network can be accessed only by virtual machines of a single account. Isolated networks have the following properties.
+
+ Resources such as VLAN are allocated and garbage collected dynamically
+
+ There is one network offering for the entire network
+
+ The network offering can be upgraded or downgraded but it is for the entire network
+
9.2.2. Shared Networks
+ A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in CloudStack 3.0.3).
+
+ Shared Networks are created by the administrator
+
+ Shared Networks can be designated to a certain domain
+
+ Shared Network resources such as VLAN and physical network that it maps to are designated by the administrator
+
+ Shared Networks are isolated by security groups
+
+ Public Network is a shared network that is not shown to the end users
+
9.2.3. Runtime Allocation of Virtual Network Resources
+ When you define a new virtual network, all your settings for that network are stored in CloudStack. The actual network resources are activated only when the first virtual machine starts in the network. When all virtual machines have left the virtual network, the network resources are garbage collected so they can be allocated again. This helps to conserve network resources..
+
+ CloudStack provides administrators with complete control over the lifecycle of all guest VMs executing in the cloud. CloudStack provides several guest management operations for end users and administrators. VMs may be stopped, started, rebooted, and destroyed.
+
+ Guest VMs have a name and group. VM names and groups are opaque to CloudStack and are available for end users to organize their VMs. Each VM can have three names for use in different contexts. Only two of these names can be controlled by the user:
+
+ Instance name – a unique, immutable ID that is generated by CloudStack and can not be modified by the user. This name conforms to the requirements in IETF RFC 1123.
+
+ Display name – the name displayed in the CloudStack web UI. Can be set by the user. Defaults to instance name.
+
+ Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to instance name
+
+ Guest VMs can be configured to be Highly Available (HA). An HA-enabled VM is monitored by the system. If the system detects that the VM is down, it will attempt to restart the VM, possibly on a different host. For more information, see HA-Enabled Virtual Machines on
+
+ Each new VM is allocated one public IP address. When the VM is started, CloudStack automatically creates a static NAT between this public IP address and the private IP address of the VM.
+
+ If elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new VM is not marked as elastic. The user must replace the automatically configured IP with a specifically acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s private IP. The VM’s original IP address is then released and returned to the pool of available public IPs.
+
+ CloudStack cannot distinguish a guest VM that was shut down by the user (such as with the “shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut down from inside the VM, CloudStack will restart it. To shut down an HA-enabled VM, you must go through the CloudStack UI or API.
+
+ A zone is the largest organizational unit within a CloudStack deployment. A zone typically corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter. The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required).
+
+ A zone consists of:
+
+ One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
+
+ Secondary storage, which is shared by all the pods in the zone.
+
+ Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones.
+
+ Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone.
+
+ Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels.
+
+ For each zone, the administrator must decide the following.
+
+ How many pods to place in a zone.
+
+ How many clusters to place in each pod.
+
+ How many hosts to place in each cluster.
+
+ How many primary storage servers to place in each cluster and total capacity for the storage servers.
+
+ How much secondary storage to deploy in 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.
+
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
+ To access a VM through the CloudStack UI:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ Click Instances, then click the name of a running VM.
+
+ Click the View Console button .
+
+ To access a VM directly over the network:
+
+ The VM must have some port open to incoming traffic. For example, in a basic zone, a new VM might be assigned to a security group which allows incoming traffic. This depends on what security group you picked when creating the VM. In other cases, you can open a port by setting up a port forwarding policy. See IP Forwarding and Firewalling.
+
+ If a port is open but you can not access the VM using ssh, it’s possible that ssh is not already enabled on the VM. This will depend on whether ssh is enabled in the template you picked when creating the VM. Access the VM through the CloudStack UI and enable ssh on the machine using the commands for the VM’s operating system.
+
+ If the network has an external firewall device, you will need to create a firewall rule to allow access. See IP Forwarding and Firewalling.
+
+ 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
+
+ The 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.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click the name of the network where you want to work with.
+
+ Click View IP Addresses.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.
+
+ 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.
+
6.4.1. 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”. 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”.
+
+ 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.
+
+ 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.
+
12.13. Adding Password Management to Your Templates
+ CloudStack provides an optional password reset feature that allows users to set a temporary admin or root password as well as reset the existing admin or root password from the CloudStack UI.
+
+ To enable the Reset Password feature, you will need to download an additional script to patch your template. When you later upload the template into CloudStack, you can specify whether reset admin/root password feature should be enabled for this template.
+
+ The password management feature works always resets the account password on instance boot. The script does an HTTP call to the virtual router to retrieve the account password that should be set. As long as the virtual router is accessible the guest will have access to the account password that should be used. When the user requests a password reset the management server generates and sends a new password to the virtual router for the account. Thus an instance reboot is necessary to effect any password changes.
+
+ If the script is unable to contact the virtual router during instance boot it will not set the password but boot will continue normally.
+
12.13.1. Linux OS Installation
+ Use the following steps to begin the Linux OS installation:
+
+ Download the script file cloud-set-guest-password:
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs. For requirements and instructions, see Section 7.5, “Adding a Host”.
+
+ 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
+
15.5. Advanced Zone Physical Network Configuration
+ Within a zone that uses advanced networking, you need to tell the Management Server how the physical network is set up to carry different kinds of traffic in isolation.
+
15.5.1. Configure Guest Traffic in an Advanced Zone
+ These steps assume you have already logged in to the CloudStack UI. To configure the base guest network:
+
+ In the left navigation, choose Infrastructure. On Zones, click View More, then click the zone to which you want to add a network.
+
+ Click the Network tab.
+
+ Click Add guest network.
+
+ The Add guest network window is displayed:
+
+ Provide the following information:
+
+ Name. The name of the network. This will be user-visible
+
+ Display Text: The description of the network. This will be user-visible
+
+ Zone: The zone in which you are configuring the guest network.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network
+
+ Guest Gateway: The gateway that the guests should use
+
+ Guest Netmask: The netmask in use on the subnet the guests will use
+
+ Click OK.
+
15.5.2. Configure Public Traffic in an Advanced Zone
+ In a zone that uses advanced networking, you need to configure at least one range of IP addresses for Internet traffic.
+
+ CloudStack enables administrators to write custom allocators that will choose the Host to place a new guest and the storage host from which to allocate guest virtual disk images.
+
+ 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.
+
+ Asynchronous commands were introduced in CloudStack 2.x. Commands are designated as asynchronous when they can potentially take a long period of time to complete such as creating a snapshot or disk volume. They differ from synchronous commands by the following:
+
+ They are identified in the API Reference by an (A).
+
+ They will immediately return a job ID to refer to the job that will be responsible in processing the command.
+
+ If executed as a "create" resource command, it will return the resource ID as well as the job ID.
+
+ You can periodically check the status of the job by making a simple API call to the command, queryAsyncJobResult and passing in the job ID.
+
4.5.1. Job Status
+ The key to using an asynchronous command is the job ID that is returned immediately once the command has been executed. With the job ID, you can periodically check the job status by making calls to queryAsyncJobResult command. The command will return three possible job status integer values:
+
+ 0 - Job is still in progress. Continue to periodically poll for any status changes.
+
+ 1 - Job has successfully completed. The job will return any successful response values associated with command that was originally executed.
+
+ 2 - Job has failed to complete. Please check the "jobresultcode" tag for failure reason code and "jobresult" for the failure reason.
+
4.5.2. Example
+ The following shows an example of using an asynchronous command. Assume the API command:
+
+ The software that provides AWS API compatibility is installed along with CloudPlatform. However, you must enable the feature and perform some setup steps.
+
+ Create a set of CloudStack service offerings with names that match the Amazon service offerings. You can do this through the CloudStack UI as described in the Administration Guide.
+
Warning
+ Be sure you have included the Amazon default service offering, m1.small.
+
+ If you did not already do so when you set the configuration parameter in step 1, restart the Management Server.
+
# service cloud-management restart
+ (Optional) The AWS API listens for requests on port 7080. If you prefer AWS API to listen on another port, you can change it as follows:
+
+ Edit the files /etc/cloud/management/server.xml, /etc/cloud/management/server-nonssl.xml, and /etc/cloud/management/server-ssl.xml.
+
+ In each file, find the tag <Service name="Catalina7080">. Under this tag, locate <Connector executor="tomcatThreadPool-internal" port= ....<.
+
+ Change the port to whatever port you want to use, then save the files.
+
+ Restart the Management Server.
+
Note
+ If you re-install CloudStack, you will have to make these changes again.
+
10.1. Amazon Web Services EC2 Compatible Interface
+ CloudStack can translate Amazon Web Services (AWS) API calls to native CloudStack API calls so that users can continue using existing AWS-compatible tools. This translation service runs as a separate web application in the same tomcat server as the management server of CloudStack, listening on the same port. This Amazon EC2-compatible API is accessible through a SOAP web service.
+
Note
+ This service was previously enabled by separate software called CloudBridge. It is now fully integrated with the CloudStack management server.
+
+ Limitations
+
+ Supported only in zones that use basic networking.
+
+ Available in fresh installations of CloudStack. Not available through upgrade of previous versions.
+
+ If you need to support features such as elastic IP, set up a Citrix NetScaler to provide this service. The commands such as ec2-associate-address will not work without EIP setup. Users running VMs in this zone will be using the NetScaler-enabled network offering (DefaultSharedNetscalerEIP and ELBNetworkOffering).
+
+ The following Amazon EC2 commands are supported by CloudStack when the AWS API compatibility feature is enabled. For a few commands, there are differences between the CloudStack and Amazon EC2 versions, and these differences are noted. The underlying SOAP call for each command is also given, for those who have built tools using those calls.
+
10.5. Using Timeouts to Ensure AWS API Command Completion
+ The Amazon EC2 command-line tools have a default connection timeout. When used with CloudStack, a longer timeout might be needed for some commands. If you find that commands are not completing due to timeouts, you can gain more time for commands to finish by overriding the default timeouts on individual commands. You can add the following optional command-line parameters to any CloudStack-supported EC2 command:
+
+
+
--connection-timeout TIMEOUT
+
+ Specifies a connection timeout (in seconds). Example:
+
--connection-timeout 30
+
+
+
+
--request-timeout TIMEOUT
+
+ Specifies a request timeout (in seconds). Example:
+
+ In general, users need not be aware that they are using a translation service provided by CloudStack. They need only send AWS API calls to CloudStack's endpoint, and it will translate the calls to the native API. Users of the Amazon EC2 compatible interface will be able to keep their existing EC2 tools and scripts and use them with their CloudStack deployment, by specifying the endpoint of the management server and using the proper user credentials. In order to do this, each user must perform the following configuration steps:
+
+
+ Generate user credentials and register with the service.
+
+ Set up the environment variables for the EC2 command-line tools.
+
+ For SOAP access, use the endpoint http://CloudStack-management-server:8080/awsapi. The CloudStack-management-server can be specified by a fully-qualified domain name or IP address.
+
+
+
10.4.1. AWS API User Registration
+ Each user must perform a one-time registration. The user follows these steps:
+
+ Obtain the following by looking in the CloudStack UI, using the API, or asking the cloud administrator:
+
+ The CloudStack server's publicly available DNS name or IP address
+
+ The user account's API key and Secret key
+
+ Generate a private key and a self-signed X.509 certificate. The user substitutes their own desired storage location for /path/to/… below.
+
+ Register the mapping from the X.509 certificate to the API/Secret keys. Download the following script from http://download.cloud.com/releases/3.0.3/cloudstack-aws-api-register and run it. Substitute the values that were obtained in step 1 in the URL below.
+
+ A user with an existing AWS certificate could choose to use the same certificate with CloudStack, but the public key would be uploaded to the CloudStack management server database.
+
10.4.2. AWS API Command-Line Tools Setup
+ To use the EC2 command-line tools, the user must perform these steps:
+
+ Set up the environment variables that will direct the tools to the server. As a best practice, you may wish to place these commands in a script that may be sourced before using the AWS API translation feature.
+
+ In a basic network, configuring the physical network is fairly straightforward. You only need to configure one guest network to carry traffic that is generated by guest VMs. When you first add a zone to CloudPlatform, you set up the guest network through the Add Zone screens.
+
+ If you plan to use large templates (100 GB or larger), be sure you have a 10-gigabit network to support the large templates. A slower network can lead to timeouts and other errors when large templates are used.
+
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
+ The CloudStack Management Server stores database configuration information (e.g., hostname, port, credentials) in the file /etc/cloud/management/db.properties. To effect a change, edit this file on each Management Server, then restart the Management Server.
+
+ 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:
+
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".
+
mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/changing-service-offering-for-vm.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/changing-service-offering-for-vm.html
new file mode 100644
index 00000000000..0b2729c8943
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/changing-service-offering-for-vm.html
@@ -0,0 +1,30 @@
+
+
+10.8. Changing the Service Offering for a VM
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/changing-vm-name-os-group.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/changing-vm-name-os-group.html
new file mode 100644
index 00000000000..71b7319e2d7
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/changing-vm-name-os-group.html
@@ -0,0 +1,38 @@
+
+
+10.7. Changing the VM Name, OS, or Group
+ The architecture used in a deployment will vary depending on the size and purpose of the deployment. This section contains examples of deployment architecture, including a small-scale deployment useful for test and trial deployments and a fully-redundant large-scale setup for production deployments.
+
+ If you want to use the Citrix XenServer hypervisor to run guest virtual machines, install XenServer 6.0 or XenServer 6.0.2 on the host(s) in your cloud. For an initial installation, follow the steps below. If you have previously installed XenServer and want to upgrade to another version, see Section 8.2.11, “Upgrading XenServer Versions”.
+
8.2.1. System Requirements for XenServer Hosts
+ The host must be certified as compatible with one of the following. See the Citrix Hardware Compatibility Guide: http://hcl.xensource.com
+
+ XenServer 5.6 SP2
+
+ XenServer 6.0
+
+ XenServer 6.0.2
+
+ You must re-install Citrix XenServer if you are going to re-use a host from a previous install.
+
+ Must support HVM (Intel-VT or AMD-V enabled)
+
+ 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.
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+ Must support HVM (Intel-VT or AMD-V enabled in BIOS)
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ Hardware virtualization support required
+
+ 4 GB of memory
+
+ 36 GB of local disk
+
+ At least 1 NIC
+
+ Statically allocated IP Address
+
+ When you deploy CloudStack, the hypervisor host must not have any VMs already running
+
Warning
+ The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see http://support.citrix.com/article/CTX126531. The article refers to XenServer 5.6, but the same information applies to XenServer 6.0.
+
8.2.4. Username and Password
+ All XenServers in a cluster must have the same username and password as configured in CloudStack.
+
8.2.5. Time Synchronization
+ The host must be set to use NTP. All hosts in a pod must have the same time.
+
+ Install NTP.
+
# yum install ntp
+ Edit the NTP configuration file to point to your NTP server.
+
# vi /etc/ntp.conf
+ Add one or more server lines in this file with the names of the NTP servers you want to use. For example:
+
server 0.xenserver.pool.ntp.org
+server 1.xenserver.pool.ntp.org
+server 2.xenserver.pool.ntp.org
+server 3.xenserver.pool.ntp.org
+
+ Restart the NTP client.
+
# service ntpd restart
+ Make sure NTP will start again upon reboot.
+
# chkconfig ntpd on
8.2.6. Licensing
+ Citrix XenServer Free version provides 30 days usage without a license. Following the 30 day trial, XenServer requires a free activation and license. You can choose to install a license now or skip this step. If you skip this step, you will need to install a license when you activate and license the XenServer.
+
8.2.6.1. Getting and Deploying a License
+ If you choose to install a license now you will need to use the XenCenter to activate and get a license.
+
+ In XenCenter, click Tools > License manager.
+
+ Select your XenServer and select Activate Free XenServer.
+
+ Request a license.
+
+ You can install the license with XenCenter or using the xe command line tool.
+
8.2.7. Install CloudStack XenServer Support Package (CSP)
+ (Optional)
+
+ To enable security groups, elastic load balancing, and elastic IP on XenServer, download and install the CloudStack XenServer Support Package (CSP). After installing XenServer, perform the following additional steps on each XenServer host.
+
+ Download the CSP software onto the XenServer host from one of the following links:
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
# xe-switch-network-backend bridge
+ Restart the host machine when prompted.
+
+ The XenServer host is now ready to be added to CloudStack.
+
8.2.8. Primary Storage Setup for XenServer
+ CloudStack natively supports NFS, iSCSI and local storage. If you are using one of these storage types, there is no need to create the XenServer Storage Repository ("SR").
+
+ If, however, you would like to use storage connected via some other technology, such as FiberChannel, you must set up the SR yourself. To do so, perform the following steps. If you have your hosts in a XenServer pool, perform the steps on the master node. If you are working with a single XenServer which is not part of a cluster, perform the steps on that XenServer.
+
+ Connect FiberChannel cable to all hosts in the cluster and to the FiberChannel storage host.
+
+ Rescan the SCSI bus. Either use the following command or use XenCenter to perform an HBA rescan.
+
# scsi-rescan
+ Repeat step 2 on every host.
+
+ Check to be sure you see the new SCSI disk.
+
# ls /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -l
+ The output should look like this, although the specific file name will be different (scsi-<scsiID>):
+
+ This command returns a unique ID for the SR, like the following example (your ID will be different):
+
7a143820-e893-6c6a-236e-472da6ee66bf
+ To create a human-readable description for the SR, use the following command. In uuid, use the SR ID returned by the previous command. In name-description, set whatever friendly text you prefer.
+
+ Make note of the values you will need when you add this storage to CloudStack later (see Section 6.6, “Add Primary Storage”). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the name-label you set earlier (in this example, e6849e96-86c3-4f2c-8fcc-350cc711be3d).
+
+ (Optional) If you want to enable multipath I/O on a FiberChannel SAN, refer to the documentation provided by the SAN vendor.
+
8.2.9. iSCSI Multipath Setup for XenServer (Optional)
+ When setting up the storage repository on a Citrix XenServer, you can enable multipath I/O, which uses redundant physical components to provide greater reliability in the connection between the server and the SAN. To enable multipathing, use a SAN solution that is supported for Citrix servers and follow the procedures in Citrix documentation. The following links provide a starting point:
+
+ You can also ask your SAN vendor for advice about setting up your Citrix repository for multipathing.
+
+ Make note of the values you will need when you add this storage to the CloudStack later (see Section 6.6, “Add Primary Storage”). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the same name used to create the SR.
+
+ If you encounter difficulty, address the support team for the SAN provided by your vendor. If they are not able to solve your issue, see Contacting Support.
+
8.2.10. Physical Networking Setup for XenServer
+ Once XenServer has been installed, you may need to do some additional network configuration. At this point in the installation, you should have a plan for what NICs the host will have and what traffic each NIC will carry. The NICs should be cabled as necessary to implement your plan.
+
+ If you plan on using NIC bonding, the NICs on all hosts in the cluster must be cabled exactly the same. For example, if eth0 is in the private bond on one host in a cluster, then eth0 must be in the private bond on all hosts in the cluster.
+
+ The IP address assigned for the management network interface must be static. It can be set on the host itself or obtained via static DHCP.
+
+ CloudStack configures network traffic of various types to use different NICs or bonds on the XenServer host. You can control this process and provide input to the Management Server through the use of XenServer network name labels. The name labels are placed on physical interfaces or bonds and configured in CloudStack. In some simple cases the name labels are not required.
+
8.2.10.1. Configuring Public Network with a Dedicated NIC for XenServer (Optional)
+ CloudStack supports the use of a second NIC (or bonded pair of NICs, described in Section 8.2.10.4, “NIC Bonding for XenServer (Optional)”) for the public network. If bonding is not used, the public network can be on any NIC and can be on different NICs on the hosts in a cluster. For example, the public network can be on eth0 on node A and eth1 on node B. However, the XenServer name-label for the public network must be identical across all hosts. The following examples set the network label to "cloud-public". After the management server is installed and running you must configure it with the name of the chosen network label (e.g. "cloud-public"); this is discussed in Section 4.5, “Management Server Installation”.
+
+ If you are using a single dedicated NIC to provide public network access, follow this procedure on each new host that is added to CloudStack before adding the host.
+
+ Run xe network-list and find the public network. This is usually attached to the NIC that is public. Once you find the network make note of its UUID. Call this <UUID-Public>.
+
8.2.10.2. Configuring Multiple Guest Networks for XenServer (Optional)
+ CloudStack supports the use of multiple guest networks with the XenServer hypervisor. Each network is assigned a name-label in XenServer. For example, you might have two networks with the labels "cloud-guest" and "cloud-guest2". After the management server is installed and running, you must add the networks and use these labels so that CloudStack is aware of the networks.
+
+ Follow this procedure on each new host before adding the host to CloudStack:
+
+ Run xe network-list and find one of the guest networks. Once you find the network make note of its UUID. Call this <UUID-Guest>.
+
+ Run the following command, substituting your own name-label and uuid values.
+
+ Repeat these steps for each additional guest network, using a different name-label and uuid each time.
+
8.2.10.3. Separate Storage Network for XenServer (Optional)
+ You can optionally set up a separate storage network. This should be done first on the host, before implementing the bonding steps below. This can be done using one or two available NICs. With two NICs bonding may be done as above. It is the administrator's responsibility to set up a separate storage network.
+
+ Give the storage network a different name-label than what will be given for other networks.
+
+ For the separate storage network to work correctly, it must be the only interface that can ping the primary storage device's IP address. For example, if eth0 is the management network NIC, ping -I eth0 <primary storage device IP> must fail. In all deployments, secondary storage devices must be pingable from the management network NIC or bond. If a secondary storage device has been placed on the storage network, it must also be pingable via the storage network NIC or bond on the hosts as well.
+
+ You can set up two separate storage networks as well. For example, if you intend to implement iSCSI multipath, dedicate two non-bonded NICs to multipath. Each of the two networks needs a unique name-label.
+
+ If no bonding is done, the administrator must set up and name-label the separate storage network on all hosts (masters and slaves).
+
+ Here is an example to set up eth5 to access a storage network on 172.16.0.0/24.
+
+ XenServer supports Source Level Balancing (SLB) NIC bonding. Two NICs can be bonded together to carry public, private, and guest traffic, or some combination of these. Separate storage networks are also possible. Here are some example supported configurations:
+
+ 2 NICs on private, 2 NICs on public, 2 NICs on storage
+
+ 2 NICs on private, 1 NIC on public, storage uses management network
+
+ 2 NICs on private, 2 NICs on public, storage uses management network
+
+ 1 NIC for private, public, and storage
+
+ All NIC bonding is optional.
+
+ XenServer expects all nodes in a cluster will have the same network cabling and same bonds implemented. In an installation the master will be the first host that was added to the cluster and the slave hosts will be all subsequent hosts added to the cluster. The bonds present on the master set the expectation for hosts added to the cluster later. The procedure to set up bonds on the master and slaves are different, and are described below. There are several important implications of this:
+
+ You must set bonds on the first host added to a cluster. Then you must use xe commands as below to establish the same bonds in the second and subsequent hosts added to a cluster.
+
+ Slave hosts in a cluster must be cabled exactly the same as the master. For example, if eth0 is in the private bond on the master, it must be in the management network for added slave hosts.
+
8.2.10.4.1. Management Network Bonding
+ The administrator must bond the management network NICs prior to adding the host to CloudStack.
+
8.2.10.4.2. Creating a Private Bond on the First Host in the Cluster
+ Use the following steps to create a bond in XenServer. These steps should be run on only the first host in a cluster. This example creates the cloud-private network with two physical NICs (eth0 and eth1) bonded into it.
+
+ Find the physical NICs that you want to bond together.
+
+ These command shows the eth0 and eth1 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
+
+ Create a new network for the bond. For example, a new network with name "cloud-private".
+
+ This label is important. CloudStack looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the management network.
+
# xe network-create name-label=cloud-private
+# xe bond-create network-uuid=[uuid of cloud-private created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+ Now you have a bonded pair that can be recognized by CloudStack as the management network.
+
8.2.10.4.3. Public Network Bonding
+ Bonding can be implemented on a separate, public network. The administrator is responsible for creating a bond for the public network if that network will be bonded and will be separate from the management network.
+
8.2.10.4.4. Creating a Public Bond on the First Host in the Cluster
+ These steps should be run on only the first host in a cluster. This example creates the cloud-public network with two physical NICs (eth2 and eth3) bonded into it.
+
+ Find the physical NICs that you want to bond together.
+
+ These command shows the eth2 and eth3 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
+
+ Create a new network for the bond. For example, a new network with name "cloud-public".
+
+ This label is important. CloudStack looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the public network.
+
# xe network-create name-label=cloud-public
+# xe bond-create network-uuid=[uuid of cloud-public created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+ Now you have a bonded pair that can be recognized by CloudStack as the public network.
+
8.2.10.4.5. Adding More Hosts to the Cluster
+ With the bonds (if any) established on the master, you should add additional, slave hosts. Run the following command for all additional hosts to be added to the cluster. This will cause the host to join the master in a single XenServer pool.
+
8.2.10.4.6. Complete the Bonding Setup Across the Cluster
+ With all hosts added to the pool, run the cloud-setup-bond script. This script will complete the configuration and set up of the bonds across all hosts in the cluster.
+
+ Copy the script from the Management Server in /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+
+ Run the script:
+
# ./cloud-setup-bonding.sh
+ Now the bonds are set up and configured properly across the cluster.
+
8.2.11. Upgrading XenServer Versions
+ This section tells how to upgrade XenServer software on CloudStack hosts. The actual upgrade is described in XenServer documentation, but there are some additional steps you must perform before and after the upgrade.
+
Note
+ Be sure the hardware is certified compatible with the new version of XenServer.
+
+ To upgrade XenServer:
+
+ Upgrade the database. On the Management Server node:
+
+ You might need to change the OS type settings for VMs running on the upgraded hosts.
+
+ If you upgraded from XenServer 5.6 GA to XenServer 5.6 SP2, change any VMs that have the OS type CentOS 5.5 (32-bit), Oracle Enterprise Linux 5.5 (32-bit), or Red Hat Enterprise Linux 5.5 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit).
+
+ If you upgraded from XenServer 5.6 SP2 to XenServer 6.0.2, change any VMs that have the OS type CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux 5.6 (32-bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.6 (32-bit) , or Red Hat Enterprise Linux 5.7 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit).
+
+ If you upgraded from XenServer 5.6 to XenServer 6.0.2, do all of the above.
+
+ Restart the Management Server and Usage Server. You only need to do this once for all clusters.
+
# service cloud-management start
+# service cloud-usage start
+ Disconnect the XenServer cluster from CloudStack.
+
+ Log in to the CloudStack UI as root.
+
+ Navigate to the XenServer cluster, and click Actions – Unmanage.
+
+ Watch the cluster status until it shows Unmanaged.
+
+ Log in to one of the hosts in the cluster, and run this command to clean up the VLAN:
+
# . /opt/xensource/bin/cloud-clean-vlan.sh
+ Still logged in to the host, run the upgrade preparation script:
+
# /opt/xensource/bin/cloud-prepare-upgrade.sh
+ Troubleshooting: If you see the error "can't eject CD," log in to the VM and umount the CD, then run the script again.
+
+ Upgrade the XenServer software on all hosts in the cluster. Upgrade the master first.
+
+ Live migrate all VMs on this host to other hosts. See the instructions for live migration in the Administrator's Guide.
+
+ Troubleshooting: You might see the following error when you migrate a VM:
+
[root@xenserver-qa-2-49-4 ~]# xe vm-migrate live=true host=xenserver-qa-2-49-5 vm=i-2-8-VM
+You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected.
+vm: b6cf79c8-02ee-050b-922f-49583d9f1a14 (i-2-8-VM)
+ Troubleshooting: If you see the following error message, you can safely ignore it.
+
mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory
+ Plug in the storage repositories (physical block devices) to the XenServer host:
+
# for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; done
+ Note: If you add a host to this XenServer pool, you need to migrate all VMs on this host to other hosts, and eject this host from XenServer pool.
+
+ Repeat these steps to upgrade every host in the cluster to the same version of XenServer.
+
+ Run the following command on one host in the XenServer cluster to clean up the host tags:
+
# for host in $(xe host-list | grep ^uuid | awk '{print $NF}') ; do xe host-param-clear uuid=$host param-name=tags; done;
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.
+
+ Reconnect the XenServer cluster to CloudStack.
+
+ Log in to the CloudStack UI as root.
+
+ Navigate to the XenServer cluster, and click Actions – Manage.
+
+ Watch the status to see that all the hosts come up.
+
+ After all hosts are up, run the following on one host in the 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.
+
7.4.1. 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.
+
7.4.2. 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.
+
+ 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 values from vCenter.
+
+ Cluster Name. Enter the name of the cluster you created in vCenter. For example, "cloud.cluster.2.2.1"
+
+ vCenter Host. Enter the hostname or IP address of the vCenter server.
+
+ vCenter Username. Enter the username that CloudStack should use to connect to vCenter. This user must have all administrative privileges.
+
+ 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".
+
+ There might be a slight delay while the cluster is provisioned. It will automatically display in the UI
+
+ A service offering is a set of virtual hardware features such as CPU core count and speed, memory, and disk size. The CloudStack administrator can set up various offerings, and then end users choose from the available offerings when they create a new VM. A service offering includes the following elements:
+
+ CPU, memory, and network resource guarantees
+
+ How resources are metered
+
+ How the resource usage is charged
+
+ How often the charges are generated
+
+ For example, one service offering might allow users to create a virtual machine instance that is equivalent to a 1 GHz Intel® Core™ 2 CPU, with 1 GB memory at $0.20/hour, with network traffic metered at $0.10/GB. Based on the user’s selected offering, CloudStack emits usage records that can be integrated with billing systems. CloudStack separates service offerings into compute offerings and disk offerings. The computing service offering specifies:
+
+ Guest CPU
+
+ Guest RAM
+
+ Guest Networking type (virtual or direct)
+
+ Tags on the root disk
+
+ The disk offering specifies:
+
+ Disk size (optional). An offering without a disk size will allow users to pick their own
+
+ Tags on the data disk
+
8.1.1. Creating a New Compute Offering
+ To create a new compute offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Compute Offering.
+
+ Click Add Compute Offering.
+
+ In the dialog, make the following choices:
+
+ Name: Any desired name for the service offering.
+
+ Description: A short description of the offering that can be displayed to users
+
+ Storage type: The type of disk that should be allocated. Local allocates from storage attached directly to the host where the system VM is running. Shared allocates from storage accessible via NFS.
+
+ # of CPU cores: The number of cores which should be allocated to a system VM with this offering
+
+ CPU (in MHz): The CPU speed of the cores that the system VM is allocated. For example, “2000” would provide for a 2 GHz clock.
+
+ Memory (in MB): The amount of memory in megabytes that the system VM should be allocated. For example, “2048” would provide for a 2 GB RAM allocation.
+
+ Network Rate: Allowed data transfer rate in MB per second.
+
+ Offer HA: If yes, the administrator can choose to have the system VM be monitored and as highly available as possible.
+
+ Storage Tags: The tags that should be associated with the primary storage used by the system VM.
+
+ Host Tags: (Optional) Any tags that you use to organize your hosts
+
+ CPU cap: Whether to limit the level of CPU usage even if spare capacity is available.
+
+ Public: Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.2. Creating a New Disk Offering
+ To create a system service offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Disk Offering.
+
+ Click Add Disk Offering.
+
+ In the dialog, make the following choices:
+
+ Name. Any desired name for the system offering.
+
+ Description. A short description of the offering that can be displayed to users
+
+ Custom Disk Size. If checked, the user can set their own disk size. If not checked, the root administrator must define a value in Disk Size.
+
+ Disk Size. Appears only if Custom Disk Size is not selected. Define the volume size in GB.
+
+ (Optional)Storage Tags. The tags that should be associated with the primary storage for this disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue". Tags are also added on Primary Storage. CloudStack matches tags on a disk offering to tags on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation from the disk offering will fail..
+
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.3. Modifying or Deleting a Service Offering
+ Service offerings cannot be changed once created. This applies to both compute offerings and disk offerings.
+
+ A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently. If the service offering is still in use, it will remain in the database until all the virtual machines referencing it have been deleted. After deletion by the administrator, a service offering will not be available to end users that are creating new instances.
+
+ CloudStack is only distributed from source from the official mirrors. However, members of the CloudStack community may build convenience binaries so that users can install Apache CloudStack without needing to build from source.
+
+ These repositories contain both the Management Server and KVM Hypervisor packages.
+
4.4.1. DEB package repository
+ You can add a DEB package repository to your apt sources with the following commands. Please note that currently only packages for Ubuntu 12.04 LTS (precise) are being build.
+
+ Use your preferred editor and open (or create) /etc/apt/sources.list.d/cloudstack. Add the community provided repository to the file:
+
deb http://cloudstack.apt-get.eu/ubuntu precise 4.0
+ We now have to add the public key to the trusted keys.
+
+ Your DEB package repository should now be configured and ready for use.
+
4.4.2. RPM package repository
+ If you're using an RPM-based system, you'll want to add the Yum repository so that you can install CloudStack with Yum.
+
+ Yum repository information is found under /etc/yum.repos.d. You'll see several .repo files in this directory, each one denoting a specific repository.
+
+ To add the CloudStack repository, visit the downloads page for the repository information. It will look something like this:
+
+ Be sure the Usage Server has been installed. This requires extra steps beyond just installing the CloudStack software. See Installing the Usage Server (Optional) in the Advanced Installation Guide.
+
+ Log in to the CloudStack UI as administrator.
+
+ Click Global Settings.
+
+ In Search, type usage. Find the configuration parameter that controls the behavior you want to set. See the table below for a description of the available parameters.
+
+ In Actions, click the Edit icon.
+
+ Type the desired value and click the Save icon.
+
+ Restart the Management Server (as usual with any global configuration change) and also the Usage Server:
+
# service cloud-management restart
+# service cloud-usage restart
+
+ The following table shows the global configuration settings that control the behavior of the Usage Server.
+
+
+ Parameter Name
+
+
+
+ Description
+
+
+
+ enable.usage.server
+
+
+
+ Whether the Usage Server is active.
+
+
+
+ usage.aggregation.timezone
+
+
+
+ Time zone of usage records. Set this if the usage records and daily job execution are in different time zones. For example, with the following settings, the usage job will run at PST 00:15 and generate usage records for the 24 hours from 00:00:00 GMT to 23:59:59 GMT:
+
+ The time zone of usage.stats.job.exec.time. Valid values for the time zone are specified in Appendix A, Time Zones
+
+
+ Default: The time zone of the management server.
+
+
+
+
+ usage.sanity.check.interval
+
+
+
+ The number of days between sanity checks. Set this in order to periodically search for records with erroneous data before issuing customer invoices. For example, this checks for VM usage records created after the VM was destroyed, and similar checks for templates, volumes, and so on. It also checks for usage times longer than the aggregation range. If any issue is found, the alert ALERT_TYPE_USAGE_SANITY_RESULT = 21 is sent.
+
+
+
+ usage.stats.job.aggregation.range
+
+
+
+ The time period in minutes between Usage Server processing jobs. For example, if you set it to 1440, the Usage Server will run once per day. If you set it to 600, it will run every ten hours. In general, when a Usage Server job runs, it processes all events generated since usage was last run.
+
+
+ There is special handling for the case of 1440 (once per day). In this case the Usage Server does not necessarily process all records since Usage was last run. CloudStack assumes that you require processing once per day for the previous, complete day’s records. For example, if the current day is October 7, then it is assumed you would like to process records for October 6, from midnight to midnight. CloudStack assumes this "midnight to midnight" is relative to the usage.execution.timezone.
+
+
+ Default: 1440
+
+
+
+
+ usage.stats.job.exec.time
+
+
+
+ The time when the Usage Server processing will start. It is specified in 24-hour format (HH:MM) in the time zone of the server, which should be GMT. For example, to start the Usage job at 10:30 GMT, enter "10:30".
+
+
+ If usage.stats.job.aggregation.range is also set, and its value is not 1440, then its value will be added to usage.stats.job.exec.time to get the time to run the Usage Server job again. This is repeated until 24 hours have elapsed, and the next day's processing begins again at usage.stats.job.exec.time.
+
+
+ Default: 00:15.
+
+
+
+ For example, suppose that your server is in GMT, your user population is predominantly in the East Coast of the United States, and you would like to process usage records every night at 2 AM local (EST) time. Choose these settings:
+
+ enable.usage.server = true
+
+ usage.execution.timezone = America/New_York
+
+ usage.stats.job.exec.time = 07:00. This will run the Usage job at 2:00 AM EST. Note that this will shift by an hour as the East Coast of the U.S. enters and exits Daylight Savings Time.
+
+ usage.stats.job.aggregation.range = 1440
+
+ With this configuration, the Usage job will run every night at 2 AM EST and will process records for the previous day’s midnight-midnight as defined by the EST (America/New_York) time zone.
+
Note
+ Because the special value 1440 has been used for usage.stats.job.aggregation.range, the Usage Server will ignore the data between midnight and 2 AM. That data will be included in the next day's run
+
+ CloudStack Virtual Private Cloud is a private, isolated part of CloudStack. A VPC can have its own virtual network topology that resembles a traditional physical network. You can launch VMs in the virtual network that can have private addresses in the range of your choice, for example: 10.0.0.0/16. You can define network tiers within your VPC network range, which in turn enables you to group similar kinds of instances based on IP address range.
+
+ For example, if a VPC has the private range 10.0.0.0/16, its guest networks can have the network ranges 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on.
+
Major Components of a VPC:
+ A VPC is comprised of the following network components:
+
+ VPC: A VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router.
+
+ Network Tiers: Each tier acts as an isolated network with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
+
+ Virtual Router: A virtual router is automatically created and started when you create a VPC. The virtual router connect the tiers and direct traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and DHCP services through its IP.
+
+ Public Gateway: The traffic to and from the Internet routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to the end user; therefore, static routes are not support for the public gateway.
+
+ In a VPC, the following four basic options of network architectures are present:
+
+ VPC with a public gateway only
+
+ VPC with public and private gateways
+
+ VPC with public and private gateways and site-to-site VPN access
+
+ VPC with a private gateway only and site-to-site VPN access
+
Connectivity Options for a VPC
+ You can connect your VPC to:
+
+ The Internet through the public gateway.
+
+ The corporate datacenter by using a site-to-site VPN connection through the VPN gateway.
+
+ Both the Internet and your corporate datacenter by using both the public gateway and a VPN gateway.
+
VPC Network Considerations
+ Consider the following before you create a VPC:
+
+ A VPC, by default, is created in the enabled state.
+
+ A VPC can be created in Advance zone only, and can't belong to more than one zone at a time.
+
+ The default number of VPCs an account can create is 20. However, you can change it by using the max.account.vpcs global parameter, which controls the maximum number of VPCs an account is allowed to create.
+
+ The default number of tiers an account can create within a VPC is 3. You can configure this number by using the vpc.max.networks parameter.
+
+ Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be within the VPC CIDR range.
+
+ A tier belongs to only one VPC.
+
+ All network tiers inside the VPC should belong to the same account.
+
+ When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP is released only when the VPC is removed.
+
+ A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it cannot be used for StaticNAT or port forwarding.
+
+ The instances only have a private IP address that you provision. To communicate with the Internet, enable NAT to an instance that you launch in your VPC.
+
+ Only new networks can be added to a VPC. The maximum number of networks per VPC is limited by the value you specify in the vpc.max.networks parameter. The default value is three.
+
+ The load balancing service can be supported by only one tier inside the VPC.
+
+ If an IP address is assigned to a tier:
+
+ That IP can't be used by more than one tier at a time in the VPC. For example, if you have tiers A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A or B, but not for both.
+
+ That IP can't be used for StaticNAT, load balancing, or port forwarding rules for another guest network inside the VPC.
+
+ Remote access VPN is not supported in VPC networks.
+
15.19.2. Adding a Virtual Private Cloud
+ When creating the VPC, you simply provide the zone and a set of IP addresses for the VPC network address space. You specify this set of addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ Click Add VPC. The Add VPC page is displayed as follows:
+
+ Provide the following information:
+
+ Name: A short name for the VPC that you are creating.
+
+ Description: A brief description of the VPC.
+
+ Zone: Choose the zone where you want the VPC to be available.
+
+ Super CIDR for Guest Networks: Defines the CIDR range for all the tiers (guest networks) within a VPC. When you create a tier, ensure that its CIDR is within the Super CIDR value you enter. The CIDR must be RFC1918 compliant.
+
+ DNS domain for Guest Networks: If you want to assign a special domain name, specify the DNS suffix. This parameter is applied to all the tiers within the VPC. That implies, all the tiers you create in the VPC belong to the same DNS domain. If the parameter is not specified, a DNS domain name is generated automatically.
+
15.19.3. Adding Tiers
+ Tiers are distinct locations within a VPC that act as isolated networks, which do not have access to other tiers by default. Tiers are set up on different VLANs that can communicate with each other by using a virtual router. Tiers provide inexpensive, low latency network connectivity to other tiers within the VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
Note
+ The end users can see their own VPCs, while root and domain admin can see any VPC they are authorized to see.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Add new tier dialog is displayed, as follows:
+
+ If you have already created tiers, the VPC diagram is displayed. Click Create Tier to add a new tier.
+
+ Specify the following:
+
+ All the fields are mandatory.
+
+ Name: A unique name for the tier you create.
+
+ Network Offering: The following default network offerings are listed: DefaultIsolatedNetworkOfferingForVpcNetworksNoLB, DefaultIsolatedNetworkOfferingForVpcNetworks
+
+ In a VPC, only one tier can be created by using LB-enabled network offering.
+
+ Gateway: The gateway for the tier you create. Ensure that the gateway is within the Super CIDR range that you specified while creating the VPC, and is not overlapped with the CIDR of any existing tier within the VPC.
+
+ Netmask: The netmask for the tier you create.
+
+ For example, if the VPC CIDR is 10.0.0.0/16 and the network tier CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the netmask of the tier is 255.255.255.0.
+
+ Click OK.
+
+ Continue with configuring access control list for the tier.
+
15.19.4. Configuring Access Control List
+ Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service is supported.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Network ACLs.
+
+ The Network ACLs page is displayed.
+
+ Click Add Network ACLs.
+
+ To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed in this tier.
+
+ CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or to the IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Protocol: The networking protocol that sources use to send traffic to the tier. The TCP and UDP protocols are typically used for data exchange and end-user communications. The ICMP protocol is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ Select Tier: Select the tier for which you want to add this ACL rule.
+
+ ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
+
+ Traffic Type: Select the traffic type you want to apply.
+
+ Egress: To add an egress rule, select Egress from the Traffic type drop-down box and click Add. This specifies what type of traffic is allowed to be sent out of VM instances in this tier. If no egress rules are specified, all traffic from the tier is allowed out at the VPC virtual router. Once egress rules are specified, only the traffic specified in egress rules and the responses to any traffic that has been allowed in through an ingress rule are allowed out. No egress rule is required for the VMs in a tier to communicate with each other.
+
+ Ingress: To add an ingress rule, select Ingress from the Traffic type drop-down box and click Add. This specifies what network traffic is allowed into the VM instances in this tier. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
Note
+ By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, create a new network ACL.
+
+ Click Add. The ACL rule is added.
+
+ To view the list of ACL rules you have added, click the desired tier from the Network ACLs page, then select the Network ACL tab.
+
+ You can edit the tags assigned to the ACL rules and delete the ACL rules you have created. Click the appropriate button in the Actions column.
+
15.19.5. Adding a Private Gateway to a VPC
+ A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. No gateways with duplicated VLAN and IP are allowed in the same data center.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Private Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Private Gateways.
+
+ The Gateways page is displayed.
+
+ Click Add new gateway:
+
+ Specify the following:
+
+ Physical Network: The physical network you have created in the zone.
+
+ IP Address: The IP address associated with the VPC gateway.
+
+ Gateway: The gateway through which the traffic is routed to and from the VPC.
+
+ Netmask: The netmask associated with the VPC gateway.
+
+ VLAN: The VLAN associated with the VPC gateway.
+
+ The new gateway appears in the list. You can repeat these steps to add more gateway for this VPC.
+
15.19.6. Deploying VMs to the Tier
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed.
+
+ Click the Add VM button of the tier for which you want to add a VM.
+
+ The Add Instance page is displayed.
+
+ Follow the on-screen instruction to add an instance. For information on adding an instance, see Adding Instances section in the Installation Guide.
+
15.19.7. Acquiring a New IP Address for a VPC
+ When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks within the VPC. The IPs are associated to the guest network only when the first port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP can't be associated to more than one network at a time.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding, load balancing, and static NAT rules.
+
15.19.8. Releasing an IP Address Alloted to a VPC
+ The IP address is a limited resource. If you no longer need a particular IP, you can disassociate it from its VPC and return it to the pool of available addresses. An IP address can be released from its tier, only when all the networking ( port forwarding, load balancing, or StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC whose IP you want to release.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to release.
+
+ In the Details tab, click the Release IP button
+
+
15.19.9. Enabling or Disabling Static NAT on a VPC
+ A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to allow Internet traffic to it. This section tells how to enable or disable static NAT for a particular IP address in a VPC.
+
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to work with.
+
+ In the Details tab,click the Static NAT button.
+
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+
+ If you are enabling static NAT, a dialog appears as follows:
+
+ Select the tier and the destination VM, then click Apply.
+
15.19.10. Adding Load Balancing Rules on a VPC
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Load Balancing node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
Note
+ In a VPC, the load balancing service is supported only on a single tier.
+
+ Specify the following:
+
+ Name: A name for the load balancer rule.
+
+ Public Port: The port that receives the incoming traffic to be balanced.
+
+ Private Port: The port that the VMs will use to receive the traffic.
+
+ Algorithm. Choose the load balancing algorithm you want CloudStack to use. CloudStack supports the following well-known algorithms:
+
+ Round-robin
+
+ Least connections
+
+ Source
+
+ Stickiness. (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
+
+ Add VMs: Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.
+
+ The new load balancing rule appears in the list. You can repeat these steps to add more load balancing rules for this IP address.
+
15.19.11. Adding a Port Forwarding Rule on a VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Choose an existing IP address or acquire a new IP address. Click the name of the IP address in the list.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Port Forwarding node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
+ Specify the following:
+
+ Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+
+ Private Port: The port on which the instance is listening for forwarded public traffic.
+
+ Protocol: The communication protocol in use between the two ports.
+
+ TCP
+
+ UDP
+
+ Add VM: Click Add VM. Select the name of the instance to which this rule applies, and click Apply.
+
+ You can test the rule by opening an ssh session to the instance.
+
15.19.12. Removing Tiers
+ You can remove a tier from a VPC. A removed tier cannot be revoked. When a tier is removed, only the resources of the tier are expunged. All the network rules (port forwarding, load balancing and staticNAT) and the IP addresses associated to the tier are removed. The IP address still be belonging to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Configure VPC page is displayed. Locate the tier you want to work with.
+
+ Click the Remove VPC button:
+
+ Wait for some time for the tier to be removed.
+
15.19.13. Editing, Restarting, and Removing a Virtual Private Cloud
Note
+ Ensure that all the tiers are removed before you remove a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Select the VPC you want to work with.
+
+ To remove, click the Remove VPC button
+
+
+ You can edit the name and description of a VPC. To do that, select the VPC, then click the Edit button.
+
+
+ To restart a VPC, select the VPC, then click the Restart button.
+
+
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+
+ Before CloudPlatform users start using projects, the CloudPlatform administrator must set up various systems to support them, including membership invitations, limits on project resources, and controls on who can create projects.
+
6.2.1. 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.
+
+ In the search box, type project and click the search button.
+
+
+ In the search results, you will 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
+
service cloud-management restart
6.2.2. 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
+
6.2.2.1. 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”). 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.
+
6.2.2.2. 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.
+
+
+
+ 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.
+
# service cloud-management restart
6.2.3. 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.
+
+
+
+ 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.
+
+ The Console Proxy is a type of System Virtual Machine that has a role in presenting a console view via the web UI. It connects the user’s browser to the VNC port made available via the hypervisor for the console of the guest. Both the administrator and end user web UIs offer a console connection.
+
+ Clicking on a console icon brings up a new window. The AJAX code downloaded into that window refers to the public IP address of a console proxy VM. There is exactly one public IP address allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then proxies the connection to the VNC port for the requested VM on the Host hosting the guest. .
+
Note
+ The hypervisors will have many ports assigned to VNC usage so that multiple VNC sessions can occur simultaneously.
+
+ There is never any traffic to the guest virtual IP, and there is no need to enable VNC within the guest.
+
+ The console proxy VM will periodically report its active session count to the Management Server. The default reporting interval is five seconds. This can be changed through standard Management Server configuration with the parameter consoleproxy.loadscan.interval.
+
+ Assignment of guest VM to console proxy is determined by first determining if the guest VM has a previous session associated with a console proxy. If it does, the Management Server will assign the guest VM to the target Console Proxy VM regardless of the load on the proxy VM. Failing that, the first available running Console Proxy VM that has the capacity to handle new sessions is used.
+
+ Console proxies can be restarted by administrators but this will interrupt existing console sessions for users.
+
+ The console viewing functionality uses a dynamic DNS service under the domain name realhostip.com to assist in providing SSL security to console sessions. The console proxy is assigned a public IP address. In order to avoid browser warnings for mismatched SSL certificates, the URL for the new console window is set to the form of https://aaa-bbb-ccc-ddd.realhostip.com. Customers will see this URL during console session creation. CloudStack includes the realhostip.com SSL certificate in the console proxy VM. Of course, CloudStack cannot know about DNS A records for our customers' public IPs prior to shipping the software. CloudStack therefore runs a dynamic DNS server that is authoritative for the realhostip.com domain. It maps the aaa-bbb-ccc-ddd part of the DNS name to the IP address aaa.bbb.ccc.ddd on lookups. This allows the browser to correctly connect to the console proxy's public IP, where it then expects and receives a SSL certificate for realhostip.com, and SSL is set up without browser warnings.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/convert-hyperv-vm-to-template.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/convert-hyperv-vm-to-template.html
new file mode 100644
index 00000000000..28a5826c090
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/convert-hyperv-vm-to-template.html
@@ -0,0 +1,68 @@
+
+
+12.12. Converting a Hyper-V VM to a Template
+ To convert a Hyper-V VM to a XenServer-compatible CloudStack template, you will need a standalone XenServer host with an attached NFS VHD SR. Use whatever XenServer version you are using with CloudStack, but use XenCenter 5.6 FP1 or SP2 (it is backwards compatible to 5.6). Additionally, it may help to have an attached NFS ISO SR.
+
+ For Linux VMs, you may need to do some preparation in Hyper-V before trying to get the VM to work in XenServer. Clone the VM and work on the clone if you still want to use the VM in Hyper-V. Uninstall Hyper-V Integration Components and check for any references to device names in /etc/fstab:
+
+ From the linux_ic/drivers/dist directory, run make uninstall (where "linux_ic" is the path to the copied Hyper-V Integration Components files).
+
+ Restore the original initrd from backup in /boot/ (the backup is named *.backup0).
+
+ Remove the "hdX=noprobe" entries from /boot/grub/menu.lst.
+
+ Check /etc/fstab for any partitions mounted by device name. Change those entries (if any) to mount by LABEL or UUID (get that information with the "blkid" command)..
+
+ The next step is make sure the VM is not running in Hyper-V, then get the VHD into XenServer. There are two options for doing this.
+
+ Option one:
+
+ Import the VHD using XenCenter. In XenCenter, go to Tools>Virtual Appliance Tools>Disk Image Import.
+
+ Choose the VHD, then click Next.
+
+ Name the VM, choose the NFS VHD SR under Storage, enable "Run Operating System Fixups" and choose the NFS ISO SR.
+
+ Click Next, then Finish. A VM should be created.
+
+ Option two
+
+ Run XenConvert, under From choose VHD, under To choose XenServer. Click Next.
+
+ Choose the VHD, then click Next.
+
+ Input the XenServer host info, then click Next.
+
+ Name the VM, then click Next, then Convert. A VM should be created
+
+ Once you have a VM created from the Hyper-V VHD, prepare it using the following steps:
+
+ Boot the VM, uninstall Hyper-V Integration Services, and reboot.
+
+ Either option above will create a VM in HVM mode. This is fine for Windows VMs, but Linux VMs may not perform optimally. Converting a Linux VM to PV mode will require additional steps and will vary by distribution.
+
+ Shut down the VM and copy the VHD from the NFS storage to a web server; for example, mount the NFS share on the web server and copy it, or from the XenServer host use sftp or scp to upload it to the web server.
+
+ In CloudStack, create a new template using the following values:
+
+ URL. Give the URL for the VHD
+
+ OS Type. Use the appropriate OS. For PV mode on CentOS, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServer.
+
+ Hypervisor. XenServer
+
+ Format. VHD
+
+ The template will be created, and you can create instances from it.
+
+ 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.
+
+ Make any desired configuration changes on the running VM, then click Stop.
+
+ Wait for the VM to stop. When the status shows Stopped, go to the next step.
+
+ Click Create Template and provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ OS Type. This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
+ If you want to boot from this template in PV mode, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServere:
+
Note
+ Note: Generally you should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates.
+
+ Click Add.
+
+ The new template will be visible in the Templates section when the template creation process has been completed. The template is then available when creating a new VM
+
+ CloudStack ships with a default template for the CentOS operating system. There are a variety of ways to add more templates. Administrators and end users can add templates. The typical sequence of events is:
+
+ Launch a VM instance that has the operating system you want. Make any other desired configuration changes to the VM.
+
+ Stop the VM.
+
+ Convert the volume into a template.
+
+ There are other ways to add templates to CloudStack. For example, you can take a snapshot of the VM's volume and create a template from the snapshot, or import a VHD from another system into CloudStack
+
+ The various techniques for creating templates are described in the next few sections.
+
+ Windows templates must be prepared with Sysprep before they can be provisioned on multiple machines. Sysprep allows you to create a generic Windows template and avoid any possible SID conflicts.
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Follow the steps in Sysprep for Windows Server 2008 R2 (below) or Sysprep for Windows Server 2003 R2, depending on your version of Windows Server
+
+ The preparation steps are complete. Now you can actually create the template as described in Creating the Windows Template.
+
12.10.1. System Preparation for Windows Server 2008 R2
+ For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location:
+
+ Windows AIK should not be installed on the Windows 2008 R2 VM you just created. Windows AIK should not be part of the template you create. It is only used to create the sysprep answer file.
+
+ Copy the install.wim file in the \sources directory of the Windows 2008 R2 installation DVD to the hard disk. This is a very large file and may take a long time to copy. Windows AIK requires the WIM file to be writable.
+
+ Start the Windows System Image Manager, which is part of the Windows AIK.
+
+ In the Windows Image pane, right click “Select a Windows image or catalog file” to load the install.wim file you just copied.
+
+ Select the Windows 2008 R2 Edition
+
+ You may be prompted with a warning that the catalog file cannot be opened. Click Yes to create a new catalog file.
+
+ In the Answer File pane, right click to create a new answer file.
+
+ Generate the answer file from the Windows System Image Manager using the following steps:
+
+ The first page you need to automate is the Language and Country or Region Selection page. To automate this, expand Components in your Windows Image pane, right-click and add the Microsoft-Windows-International-Core setting to Pass 7 oobeSystem. In your Answer File pane, configure the InputLocale, SystemLocale, UILanguage, and UserLocale with the appropriate settings for your language and country or region. Should you have a question about any of these settings, you can right-click on the specific setting and select Help. This will open the appropriate CHM help file with more information, including examples on the setting you are attempting to configure.
+
+ You need to automate the Software License Terms Selection page, otherwise known as the End-User License Agreement (EULA). To do this, expand the Microsoft-Windows-Shell-Setup component. High-light the OOBE setting, and add the setting to the Pass 7 oobeSystem. In Settings, set HideEULAPage true.
+
+ Make sure the license key is properly set. If you use MAK key, you can just enter the MAK key on the Windows 2008 R2 VM. You need not input the MAK into the Windows System Image Manager. If you use KMS host for activation you need not enter the Product Key. Details of Windows Volume Activation can be found at http://technet.microsoft.com/en-us/library/bb892849.aspx
+
+ You need to automate is the Change Administrator Password page. Expand the Microsoft-Windows-Shell-Setup component (if it is not still expanded), expand UserAccounts, right-click on AdministratorPassword, and add the setting to the Pass 7 oobeSystem configuration pass of your answer file. Under Settings, specify a password next to Value.
+
+ You may read the AIK documentation and set many more options that suit your deployment. The steps above are the minimum needed to make Windows unattended setup work.
+
+ Save the answer file as unattend.xml. You can ignore the warning messages that appear in the validation window.
+
+ Copy the unattend.xml file into the c:\windows\system32\sysprep directory of the Windows 2008 R2 Virtual Machine
+
+ Once you place the unattend.xml file in c:\windows\system32\sysprep directory, you run the sysprep tool as follows:
+
cd c:\Windows\System32\sysprep
+sysprep.exe /oobe /generalize /shutdown
+
+ The Windows 2008 R2 VM will automatically shut down after sysprep is complete.
+
12.10.2. Sysprep for Windows Server 2003 R2
+ Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2.
+
+ Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM.
+
+ Run c:\sysprep\setupmgr.exe to create the sysprep.inf file.
+
+ Select Create New to create a new Answer File.
+
+ Enter “Sysprep setup” for the Type of Setup.
+
+ Select the appropriate OS version and edition.
+
+ On the License Agreement screen, select “Yes fully automate the installation”.
+
+ Provide your name and organization.
+
+ Leave display settings at default.
+
+ Set the appropriate time zone.
+
+ Provide your product key.
+
+ Select an appropriate license mode for your deployment
+
+ Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up.
+
+ Leave Network Components at “Typical Settings”.
+
+ Select the “WORKGROUP” option.
+
+ Leave Telephony options at default.
+
+ Select appropriate Regional Settings.
+
+ Select appropriate language settings.
+
+ Do not install printers.
+
+ Do not specify “Run Once commands”.
+
+ You need not specify an identification string.
+
+ Save the Answer File as c:\sysprep\sysprep.inf.
+
+ Run the following command to sysprep the image:
+
c:\sysprep\sysprep.exe -reseal -mini -activated
+ After this step the machine will automatically shut down
+
+ Virtual machines are usually created from a template. Users can also create blank virtual machines. A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and install the OS from the CD/DVD-ROM.
+
+ To create a VM from a template:
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select a template, then follow the steps in the wizard. (For more information about how the templates came to be in this list, see Working with Templates.
+
+ Be sure that the hardware you have allows starting the selected service offering.
+
+ Click Submit and your VM will be created and started.
+
Note
+ For security reason, the internal name of the VM is visible only to the root admin.
+
Note
+ Starting with v3.0.3, you can create a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A new request parameter, startVM, is introduced in the deployVm API to support this feature. For more information, see the Developer's Guide
+
+ To create a VM from an ISO:
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select ISO Boot, and follow the steps in the wizard.
+
+ Click Submit and your VM will be created and started.
+
+ 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” 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.
+
+ Usage records include a start date and an end date. These dates define the period of time for which the raw usage number was calculated. If daily aggregation is used, the start date is midnight on the day in question and the end date is 23:59:59 on the day in question (with one exception; see below). A virtual machine could have been deployed at noon on that day, stopped at 6pm on that day, then started up again at 11pm. When usage is calculated on that day, there will be 7 hours of running VM usage (usage type 1) and 12 hours of allocated VM usage (usage type 2). If the same virtual machine runs for the entire next day, there will 24 hours of both running VM usage (type 1) and allocated VM usage (type 2).
+
+ Note: The start date is not the time a virtual machine was started, and the end date is not the time when a virtual machine was stopped. The start and end dates give the time range within which usage was calculated.
+
+ For network usage, the start date and end date again define the range in which the number of bytes transferred was calculated. If a user downloads 10 MB and uploads 1 MB in one day, there will be two records, one showing the 10 megabytes received and one showing the 1 megabyte sent.
+
+ There is one case where the start date and end date do not correspond to midnight and 11:59:59pm when daily aggregation is used. This occurs only for network usage records. When the usage server has more than one day's worth of unprocessed data, the old data will be included in the aggregation period. The start date in the usage record will show the date and time of the earliest event. For other types of usage, such as IP addresses and VMs, the old unprocessed data is not included in daily aggregation.
+
+ You can limit resource use by accounts. The default limits are set using global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account (max.account.snapshots, etc.)..
+
+ To override a default limit for a particular account, set a per-account resource limit.
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Accounts.
+
+ Select the account you want to modify. The current limits are displayed. A value of -1 shows that there is no limit in place
+
+ CloudStack includes a CentOS template. This template is downloaded by the Secondary Storage VM after the primary and secondary storage are configured. You can use this template in your production deployment or you can delete it and use custom templates.
+
+ The root password for the default template is "password".
+
+ A default template is provided for each of XenServer, KVM, and vSphere. The templates that are downloaded depend on the hypervisor type that is available in your cloud. Each template is approximately 2.5 GB physical size.
+
+ The default template includes the standard iptables rules, which will block most access to the template excluding ssh.
+
+ Templates may be deleted. In general, when a template spans multiple Zones, only the copy that is selected for deletion will be deleted; the same template in other Zones will not be deleted. The provided CentOS template is an exception to this. If the provided CentOS template is deleted, it will be deleted from all Zones.
+
+ When templates are deleted, the VMs instantiated from them will continue to run. However, new VMs cannot be created based on the deleted template.
+
+ Users can delete their own virtual machines. A running virtual machine will be abruptly stopped before it is deleted. Administrators can delete any virtual machines.
+
+ To delete a virtual machine:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ A CloudStack installation consists of two parts: the Management Server and the cloud infrastructure that it manages. When you set up and manage a CloudStack cloud, you provision resources such as hosts, storage devices, and IP addresses into the Management Server, and the Management Server manages those resources.
+
+ The minimum production installation consists of one machine running the CloudStack Management Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure consisting of one host running hypervisor software). In its smallest deployment, a single machine can act as both the Management Server and the hypervisor host (using the KVM hypervisor).
+
+ A more full-featured installation consists of a highly-available multi-node Management Server installation and up to tens of thousands of hosts using any of several advanced networking setups. For information about deployment options, see Choosing a Deployment Architecture.
+
1.3.1. Management Server Overview
+ The Management Server is the CloudStack software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+ The machine must meet the system requirements described in System Requirements.
+
+ The Management Server:
+
+ Provides the web user interface for the administrator and a reference user interface for end users.
+
+ Provides the APIs for CloudStack.
+
+ Manages the assignment of guest VMs to particular hosts.
+
+ Manages the assignment of public and private IP addresses to particular accounts.
+
+ Manages the allocation of storage to guests as virtual disks.
+
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+
+ Provides a single point of configuration for the cloud.
+
1.3.2. Cloud Infrastructure Overview
+ The Management Server manages one or more zones (typically, datacenters) containing host computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
+
+ Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
+
+ Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
+
+ Cluster: A cluster consists of one or more hosts and primary storage.
+
+ Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines.
+
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster.
+
+ Secondary storage is associated with a zone, and it stores templates, ISO images, and disk volume snapshots.
+
+ More Information
+
+ For more information, see documentation on cloud infrastructure concepts.
+
1.3.3. Networking Overview
+ CloudStack offers two types of networking scenario:
+
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
11.3. 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.
+
+
+
+ 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.
+
+ You can set an expiry timestamp on API calls to prevent replay attacks over non-secure channels, such as HTTP. The server tracks the expiry timestamp you have specified and rejects all the subsequent API requests that come in after this validity period.
+
+ To enable this feature, add the following parameters to the API request:
+
+ signatureVersion=3: If the signatureVersion parameter is missing or is not equal to 3, the expires parameter is ignored in the API request.
+
+ expires=YYYY-MM-DDThh:mm:ssZ: Specifies the date and time at which the signature included in the request is expired. The timestamp is expressed in the YYYY-MM-DDThh:mm:ssZ format, as specified in the ISO 8601 standard.
+
+ For example:
+
expires=2011-10-10T12:00:00+0530
+ A sample API request with expiration is given below:
+
+ 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..
+
22.1.2. 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
+
22.1.3. 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
+
22.1.4. 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
+
+ All CloudStack API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+
+ End users and Administrators may export templates from the CloudStack. Navigate to the template in the UI and choose the Download function from the Actions menu.
+
+ CloudStack is capable of replacing its Virtual Router with an external Juniper SRX device and an optional external NetScaler or F5 load balancer for gateway and load balancing services. In this case, the VMs use the SRX as their gateway.
+
+ CloudStack works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of CloudStack supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+ Massively Scalable Infrastructure Management
+
+ CloudStack can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+ Automatic Configuration Management
+
+ CloudStack automatically configures each guest virtual machine’s networking and storage settings.
+
+ CloudStack internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+ Graphical User Interface
+
+ CloudStack offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+ API and Extensibility
+
+ CloudStack provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at Apache CloudStack Guides and Apache CloudStack API Reference respectively.
+
+ CloudStack has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the hosts, CloudStack supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+
Chapter 19. Setting Global Configuration Parameters
+ CloudStack provides parameters that you can set to control many aspects of the cloud. When CloudStack is first installed, and periodically thereafter, you might need to modify these settings.
+
+ Log in to the UI as administrator.
+
+ In the left navigation bar, click Global Settings.
+
+ In Select View, choose one of the following:
+
+ Global Settings. This displays a list of the parameters with brief descriptions and current values.
+
+ Hypervisor Capabilities. This displays a list of hypervisor versions with the maximum number of guests supported for each.
+
+ Use the search box to narrow down the list to those you are interested in.
+
+ Click the Edit icon to modify a value. If you are viewing Hypervisor Capabilities, you must click the name of the hypervisor first to display the editing screen.
+
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+
+ The following table lists limits set in the Global Configuration:
+
+
+ Parameter Name
+
+
+
+ Definition
+
+
+
+ max.account.public.ips
+
+
+
+ Number of public IP addresses that can be owned by an account
+
+
+
+ max.account.snapshots
+
+
+
+ Number of snapshots that can exist for an account
+
+
+
+ max.account.templates
+
+
+
+ Number of templates that can exist for an account
+
+
+
+ max.account.user.vms
+
+
+
+ Number of virtual machine instances that can exist for an account
+
+
+
+ max.account.volumes
+
+
+
+ Number of disk volumes that can exist for an account
+
+
+
+ max.template.iso.size
+
+
+
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+ max.volume.size.gb
+
+
+
+ Maximum size for a volume in GB
+
+
+
+ network.throttling.rate
+
+
+
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+
+ snapshot.max.hourly
+
+
+
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+ snapshot.max.daily
+
+
+
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+
+ snapshot.max.weekly
+
+
+
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+ snapshot.max.monthly
+
+
+
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+ To modify global configuration parameters, use the global configuration screen in the CloudStack UI. See Setting Global Configuration Parameters
+
+ The IP ranges for guest network traffic are set on a per-account basis by the user. This allows the users to configure their network in a fashion that will enable VPN linking between their guest network and their clients.
+
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+
+ Figure 1 illustrates a typical guest traffic setup:
+
+ The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+
+ The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
+
+ Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
+
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/ha-management-server.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/ha-management-server.html
new file mode 100644
index 00000000000..30b1a4a05b0
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/ha-management-server.html
@@ -0,0 +1,16 @@
+
+
+17.1. HA for Management Server
+ The CloudStack Management Server should be deployed in a multi-node configuration such that it is not susceptible to individual server failures. The Management Server itself (as distinct from the MySQL database) is stateless and may be placed behind a load balancer.
+
+ Normal operation of Hosts is not impacted by an outage of all Management Serves. All guest VMs will continue to work.
+
+ When the Management Server is down, no new VMs can be created, and the end user and admin UI, API, dynamic load distribution, and HA will cease to work.
+
+ 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.
+
+ 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/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+
+ Run the script:
+
# ./cloud-setup-bonding.sh
7.5.1.1.2. 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.
+
7.5.1.2. 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 delay while the host is provisioned. It should automatically display in the UI.
+
+ Repeat for additional hosts.
+
7.5.2. Adding a Host (vSphere)
+ For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the entire cluster to CloudStack. See Add Cluster: vSphere.
+
+ The system automatically picks the most appropriate host to run each virtual machine. End users may specify the zone in which the virtual machine will be created. End users do not have control over which host will run the virtual machine instance.
+
+ CloudStack administrators can specify that certain hosts should have a preference for particular types of guest instances. For example, an administrator could state that a host should have a preference to run Windows guests. The default host allocator will attempt to place guests of that OS type on such hosts first. If no such host is available, the allocator will place the instance wherever there is sufficient physical capacity.
+
+ Both vertical and horizontal allocation is allowed. Vertical allocation consumes all the resources of a given host before allocating any guests on a second host. This reduces power consumption in the cloud. Horizontal allocation places a guest on each host in a round-robin fashion. This may yield better performance to the guests in some cases. CloudStack also allows an element of CPU over-provisioning as configured by the administrator. Over-provisioning allows the administrator to commit more CPU cycles to the allocated guests than are actually available from the hardware.
+
+ CloudStack also provides a pluggable interface for adding new allocators. These custom allocators can provide any policy the administrator desires.
+
8.1.1. System Requirements for KVM Hypervisor Hosts
+ KVM is included with a variety of Linux-based operating systems. Although you are not required to run these distributions, the following are recommended:
+
+ CentOS / RHEL: 6.3
+
+ Ubuntu: 12.04(.1)
+
+ The main requirement for KVM hypervisors is the libvirt and Qemu version. No matter what Linux distribution you are using, make sure the following requirements are met:
+
+ libvirt: 0.9.4 or higher
+
+ Qemu/KVM: 1.0 or higher
+
+ In addition, the following hardware requirements apply:
+
+ Within a single cluster, the hosts must be of the same distribution version.
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+ Must support HVM (Intel-VT or AMD-V enabled)
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ 4 GB of memory
+
+ At least 1 NIC
+
+ When you deploy CloudStack, the hypervisor host must not have any VMs already running
+
8.1.2. KVM Installation Overview
+ If you want to use the Linux Kernel Virtual Machine (KVM) hypervisor to run guest virtual machines, install KVM on the host(s) in your cloud. The material in this section doesn't duplicate KVM installation docs. It provides the CloudStack-specific steps that are needed to prepare a KVM host to work with CloudStack.
+
Warning
+ Before continuing, make sure that you have applied the latest updates to your host.
+
Warning
+ It is NOT recommended to run services on this host not controlled by CloudStack.
+
+ The procedure for installing a KVM Hypervisor Host is:
+
+ Prepare the Operating System
+
+ Install and configure libvirt
+
+ Configure Security Policies (AppArmor and SELinux)
+
+ Install and configure the Agent
+
8.1.3. Prepare the Operating System
+ The OS of the Host must be prepared to host the CloudStack Agent and run KVM instances.
+
+ Log in to your OS as root.
+
+ Check for a fully qualified hostname.
+
$ hostname --fqdn
+ This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+ Make sure that the machine can reach the Internet.
+
$ ping www.cloudstack.org
+ Turn on NTP for time synchronization.
+
Note
+ NTP is required to synchronize the clocks of the servers in your cloud. Unsynchronized clocks can cause unexpected problems.
+
+ Install NTP
+
$ yum install ntp
$ apt-get install openntpd
+ Repeat all of these steps on every hypervisor host.
+
8.1.4. Install and configure the Agent
+ To manage KVM instances on the host CloudStack uses a Agent. This Agent communicates with the Management server and controls all the instances on the host.
+
+ First we start by installing the agent:
+
+ In RHEL or CentOS:
+
$ yum install cloud-agent
+ In Ubuntu:
+
$ apt-get install cloud-agent
+ The host is now ready to be added to a cluster. This is covered in a later section, see Section 6.5, “Adding a Host”. It is recommended that you continue to read the documentation before adding the host!
+
8.1.5. Install and Configure libvirt
+ CloudStack uses libvirt for managing virtual machines. Therefore it is vital that libvirt is configured correctly. Libvirt is a dependency of cloud-agent and should already be installed.
+
+ In order to have live migration working libvirt has to listen for unsecured TCP connections. We also need to turn off libvirts attempt to use Multicast DNS advertising. Both of these settings are in /etc/libvirt/libvirtd.conf
+
+ Set the following paramaters:
+
listen_tls = 0
listen_tcp = 1
tcp_port = 16059
auth_tcp = "none"
mdns_adv = 0
+ Turning on "listen_tcp" in libvirtd.conf is not enough, we have to change the parameters as well:
+
+ On RHEL or CentOS modify /etc/sysconfig/libvirtd:
+
+ Uncomment the following line:
+
#LIBVIRTD_ARGS="--listen"
+ On Ubuntu: modify /etc/init/libvirt-bin.conf
+
+ Change the following line (at the end of the file):
+
exec /usr/sbin/libvirtd -d
+ to (just add -l)
+
exec /usr/sbin/libvirtd -d -l
+ Restart libvirt
+
+ In RHEL or CentOS:
+
$ service libvirtd restart
+ In Ubuntu:
+
$ service libvirt-bin restart
8.1.6. Configure the Security Policies
+ CloudStack does various things which can be blocked by security mechanisms like AppArmor and SELinux. These have to be disabled to ensure the Agent has all the required permissions.
+
+ Configure SELinux (RHEL and CentOS)
+
+ Check to see whether SELinux is installed on your machine. If not, you can skip this section.
+
+ In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
+
$ rpm -qa |grep selinux
+ Set the SELINUX variable in /etc/selinux/config to "permissive". This ensures that the permissive setting will be maintained after a system reboot.
+
+ In RHEL or CentOS:
+
vi /etc/selinux/config
+ Change the following line
+
SELINUX=enforcing
+ to this
+
SELINUX=permissive
+ Then set SELinux to permissive starting immediately, without requiring a system reboot.
+
$ setenforce permissive
+ Configure Apparmor (Ubuntu)
+
+ Check to see whether AppArmor is installed on your machine. If not, you can skip this section.
+
+ In Ubuntu AppArmor is installed and enabled by default. You can verify this with:
+
+ This is a very important section, please make sure you read this thoroughly.
+
+ In order to forward traffic to your instances you will need at least two bridges: public and private.
+
+ By default these bridges are called cloudbr0 and cloudbr1, but you do have to make sure they are available on each hypervisor.
+
+ The most important factor is that you keep the configuration consistent on all your hypervisors.
+
8.1.7.1. Network example
+ There are many ways to configure your network. In the Basic networking mode you should have two (V)LAN's, one for your private network and one for the public network.
+
+ We assume that the hypervisor has one NIC (eth0) with three tagged VLAN's:
+
+ VLAN 100 for management of the hypervisor
+
+ VLAN 200 for public network of the instances (cloudbr0)
+
+ VLAN 300 for private network of the instances (cloudbr1)
+
+ On VLAN 100 we give the Hypervisor the IP-Address 192.168.42.11/24 with the gateway 192.168.42.1
+
Note
+ The Hypervisor and Management server don't have to be in the same subnet!
+
8.1.7.2. Configuring the network bridges
+ It depends on the distribution you are using how to configure these, below you'll find examples for RHEL/CentOS and Ubuntu.
+
Note
+ The goal is to have two bridges called 'cloudbr0' and 'cloudbr1' after this section. This should be used as a guideline only. The exact configuration will depend on your network layout.
+
8.1.7.2.1. Configure in RHEL or CentOS
+ The required packages were installed when libvirt was installed, we can proceed to configuring the network.
+
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+
Warning
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+
8.1.7.2.2. Configure in Ubuntu
+ All the required packages were installed when you installed libvirt, so we only have to configure the network.
+
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+
Warning
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+
8.1.8. Configuring the firewall
+ The hypervisor needs to be able to communicate with other hypervisors and the management server needs to be able to reach the hypervisor.
+
+ In order to do so we have to open the following TCP ports (if you are using a firewall):
+
+ 22 (SSH)
+
+ 1798
+
+ 16509 (libvirt)
+
+ 5900 - 6100 (VNC consoles)
+
+ 49152 - 49216 (libvirt live migration)
+
+ It depends on the firewall you are using how to open these ports. Below you'll find examples how to open these ports in RHEL/CentOS and Ubuntu.
+
8.1.8.1. Open ports in RHEL/CentOS
+ RHEL and CentOS use iptables for firewalling the system, you can open extra ports by executing the following iptable commands:
+
+ These iptable settings are not persistent accross reboots, we have to save them first.
+
$ iptables-save > /etc/sysconfig/iptables
8.1.8.2. Open ports in Ubuntu
+ The default firewall under Ubuntu is UFW (Uncomplicated FireWall), which is a Python wrapper around iptables.
+
+ To open the required ports, execute the following commands:
+
$ ufw allow proto tcp from any to any port 22
$ ufw allow proto tcp from any to any port 1798
$ ufw allow proto tcp from any to any port 16509
$ ufw allow proto tcp from any to any port 5900:6100
$ ufw allow proto tcp from any to any port 49152:49216
Note
+ By default UFW is not enabled on Ubuntu. Executing these commands with the firewall disabled does not enable the firewall.
+
8.1.9. Add the host to CloudStack
+ The host is now ready to be added to a cluster. This is covered in a later section, see Section 6.5, “Adding a Host”. It is recommended that you continue to read the documentation before adding the host!
+
+ The following procedures describe how to import an Amazon Machine Image (AMI) into CloudStack when using the XenServer hypervisor.
+
+ Assume you have an AMI file and this file is called CentOS_6.2_x64. Assume further that you are working on a CentOS host. If the AMI is a Fedora image, you need to be working on a Fedora host initially.
+
+ You need to have a XenServer host with a file-based storage repository (either a local ext3 SR or an NFS SR) to convert to a VHD once the image file has been customized on the Centos/Fedora host.
+
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.
+
+ Determine the name of the PV kernel that has been installed into the image.
+
# cd /mnt/loop/centos62
+# ls lib/modules/
+2.6.16.33-xenU 2.6.16-xenU 2.6.18-164.15.1.el5xen 2.6.18-164.6.1.el5.centos.plus 2.6.18-xenU-ec2-v1.0 2.6.21.7-2.fc8xen 2.6.31-302-ec2
+# ls boot/initrd*
+boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
+# ls boot/vmlinuz*
+boot/vmlinuz-2.6.18-164.15.1.el5xen boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus boot/vmlinuz-2.6.18-xenU-ec2-v1.0 boot/vmlinuz-2.6.21-2952.fc8xen
+
+ Xen kernels/ramdisk always end with "xen". For the kernel version you choose, there has to be an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.
+
+ Based on your findings, create an entry in the grub.conf file. Below is an example entry.
+
+ Enable login via the console. The default console device in a XenServer system is xvc0. Ensure that etc/inittab and etc/securetty have the following lines respectively:
+
+ Copy the image file to your XenServer host's file-based storage repository. In the example below, the Xenserver is "xenhost". This XenServer has an NFS repository whose uuid is a9c5b8c8-536b-a193-a6dc-51af3e5ff799.
+
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+ After everything is configured, CloudStack will perform its initialization. This can take 30 minutes or more, depending on the speed of your network. When the initialization has completed successfully, the administrator's Dashboard should be displayed in the CloudStack UI.
+
+ Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS 5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do not proceed to the next step until this status is displayed.
+
+ Go to the Instances tab, and filter by My Instances.
+
+ Click Add Instance and follow the steps in the wizard.
+
+ Choose the zone you just added.
+
+ In the template selection, choose the template to use in the VM. If this is a fresh installation, likely only the provided CentOS template is available.
+
+ Select a service offering. Be sure that the hardware you have allows starting the selected service offering.
+
+ In data disk offering, if desired, add another data disk. This is a second volume that will be available to but not mounted in the guest. For example, in Linux on XenServer you will see /dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PV-enabled OS kernel in use.
+
+ In default network, choose the primary network for the guest. In a trial installation, you would have only one option here.
+
+ Optionally give your VM a name and a group. Use any descriptive text you would like.
+
+ Click Launch VM. Your VM will be created and started. It might take some time to download the template and complete the VM startup. You can watch the VM’s progress in the Instances screen.
+
+ To use the VM, click the View Console button.
+
+
+
+ Congratulations! You have successfully completed a CloudStack Installation.
+
+ If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
+
+ For anything more than a simple trial installation, you will need guidance for a variety of configuration choices. It is strongly recommended that you read the following:
+
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You provision VLANs to the tiers your create, and VMs can be deployed on different tiers. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications, such as Web, Application, or Database. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+ The major advantages are:
+
+ The administrator can deploy a set of VLANs and allow users to deploy VMs on these VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that account.
+
Note
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+
+ The administrator can allow users create their own VPC and deploy the application. In this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that account.
+
+ Both administrators and users can create multiple VPCs. The guest network NIC is plugged to the VPC virtual router when the first VM is deployed in a tier.
+
+ The administrator can create the following gateways to send to or receive traffic from the VMs:
+
+ Public Gateway: The public gateway for a VPC is added to the virtual router when the virtual router is created for VPC. The public gateway is not exposed to the end users. You are not allowed to list it, nor allowed to create any static routes.
+
+ Both administrators and users can create various possible destinations-gateway combinations. However, only one gateway of each type can be used in a deployment.
+
+ For example:
+
+ VLANs and Public Gateway: For example, an application is deployed in the cloud, and the Web application VMs communicate with the Internet.
+
+ VLANs, VPN Gateway, and Public Gateway: For example, an application is deployed in the cloud; the Web application VMs communicate with the Internet; and the database VMs communicate with the on-premise devices.
+
+ The administrator can define Access Control List (ACL) on the virtual router to filter the traffic among the VLANs or between the Internet and a VLAN. You can define ACL based on CIDR, port range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress type.
+
+ The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
+
+ By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is translated via NAT to the public IP address and is allowed.
+
+ To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example, you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44. Then use port forwarding rules to direct traffic from individual ports within that range to specific ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public IP's port 33 to port 100 on one user VM's private IP.
+
+ For the steps to implement these rules, see Firewall Rules and Port Forwarding.
+
+ The user may choose to associate the same public IP for multiple guests. CloudStack implements a TCP-level load balancer with the following policies.
+
+ Round-robin
+
+ Least connection
+
+ Source IP
+
+ This is similar to port forwarding but the destination may be multiple IP addresses.
+
+ This diagram illustrates the network architecture of a large-scale CloudStack deployment.
+
+ A layer-3 switching layer is at the core of the data center. A router redundancy protocol like VRRP should be deployed. Typically high-end core switches also include firewall modules. Separate firewall appliances may also be used if the layer-3 switch does not have integrated firewall capabilities. The firewalls are configured in NAT mode. The firewalls provide the following functions:
+
+ Forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+
+ When the cloud spans multiple zones, the firewalls should enable site-to-site VPN such that servers in different zones can directly reach each other.
+
+ A layer-2 access switch layer is established for each pod. Multiple switches can be stacked to increase port count. In either case, redundant pairs of layer-2 switches should be deployed.
+
+ The Management Server cluster (including front-end load balancers, Management Server nodes, and the MySQL database) is connected to the management network through a pair of load balancers.
+
+ Secondary storage servers are connected to the management network.
+
+ Each pod contains storage and computing servers. Each storage and computing server should have redundant NICs connected to separate layer-2 access switches.
+
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudStack virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+ 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)
+
http://<management-server-ip-address>:8080/client
+ On a fresh Management Server installation, a guided tour splash screen appears. On later visits, you’ll see a login screen where you specify the following to proceed to your Dashboard:
+
Username
+ The user ID of your account. The default username is admin.
+
Password
+ The password associated with the user ID. The password for the default username is password.
+
Domain
+ If you are a root user, leave this field blank.
+
+ If you are a user in the sub-domains, enter the full path to the domain, excluding the root domain.
+
+ For example, suppose multiple levels are created under the root domain, such as Comp1/hr. The users in the Comp1 domain should enter Comp1 in the Domain field, whereas the users in the Comp1/sales domain should enter Comp1/sales.
+
+ For more guidance about the choices that appear when you log in to this UI, see Logging In as the Root Administrator.
+
5.1.1. End User's UI Overview
+ The CloudStack UI helps users of cloud infrastructure to view and use their cloud resources, including virtual machines, templates and ISOs, data volumes and snapshots, guest networks, and IP addresses. If the user is a member or administrator of one or more CloudStack projects, the UI can provide a project-oriented view.
+
5.1.2. Root Administrator's UI Overview
+ The CloudStack UI helps the CloudStack administrator provision, view, and manage the cloud infrastructure, domains, user accounts, projects, and configuration settings. The first time you start the UI after a fresh Management Server installation, you can choose to follow a guided tour to provision your cloud infrastructure. On subsequent logins, the dashboard of the logged-in user appears. The various links in this screen and the navigation bar on the left provide access to a variety of administrative functions. The root administrator can also use the UI to perform all the same tasks that are present in the end-user’s UI.
+
5.1.3. Logging In as the Root Administrator
+ After the Management Server software is installed and running, you can run the CloudStack user interface. This UI is there to help you provision, view, and manage your cloud infrastructure.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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 can enter a user ID and password and proceed to your 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 CloudPlatform, 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”.
+
Warning
+ You are logging in as the root administrator. This account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. Please change the default password to a new, unique password.
+
5.1.4. Changing the Root Password
+ During installation and ongoing cloud administration, you will need to log in to the UI as the root administrator. The root administrator account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. When first installing CloudStack, be sure to change the default password to a new, unique value.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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.
+
+ 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.
+
+ All CloudStack API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+
+ CloudStack API URL: This is the web services API entry point(for example, http://www.cloud.com:8080/client/api)
+
+ Command: The web services command you wish to execute, such as start a virtual machine or create a disk volume
+
+ Parameters: Any additional required or optional parameters for the command
+
+ A sample API GET request looks like the following:
+
+ The first line is the CloudStack API URL. This is the Cloud instance you wish to interact with.
+
+ The second line refers to the command you wish to execute. In our example, we are attempting to deploy a fresh new virtual machine. It is preceded by a (?) to separate itself from the CloudStack API URL.
+
+ Lines 3-6 are the parameters for this given command. To see the command and its request parameters, please refer to the appropriate section in the CloudStack API documentation. Each parameter field-value pair (field=value) is preceded by an ampersand character (&).
+
+ Line 7 is the user API Key that uniquely identifies the account. See Signing API Requests on page 7.
+
+ Line 8 is the signature hash created to authenticate the user account executing the API command. See Signing API Requests on page 7.
+
+ This section describes installing the Management Server. There are two slightly different installation flows, depending on how many Management Server nodes will be in your cloud:
+
+ A single Management Server node, with MySQL on the same node.
+
+ Multiple Management Server nodes, with MySQL on a node separate from the Management Servers.
+
+ In either case, each machine must meet the system requirements described in System Requirements.
+
Warning
+ For the sake of security, be sure the public Internet can not access port 8096 or port 8250 on the Management Server.
+
+ The procedure for installing the Management Server is:
+
+ Prepare the Operating System
+
+ Download and install vhd-util.
+
+ Install the First Management Server
+
+ Install and Configure the MySQL database
+
+ Prepare NFS Shares
+
+ Prepare and Start Additional Management Servers (optional)
+
+ Prepare the System VM Template
+
4.5.2. Prepare the Operating System
+ The OS must be prepared to host the Management Server using the following steps. These steps must be performed on each Management Server node.
+
+ Log in to your OS as root.
+
+ Check for a fully qualified hostname.
+
hostname --fqdn
+ This should return a fully qualified hostname such as "managament1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+ Make sure that the machine can reach the Internet.
+
ping www.cloudstack.org
+ Turn on NTP for time synchronization.
+
Note
+ NTP is required to synchronize the clocks of the servers in your cloud.
+
+ Install NTP.
+
yum install ntp
apt-get install openntpd
+ Repeat all of these steps on every host where the Management Server will be installed.
+
4.5.3. Install the Management Server on the First Host
+ The first step in installation, whether you are installing the Management Server on one host or many, is to install the software on a single node.
+
Note
+ If you are planning to install the Management Server on multiple nodes for high availability, do not proceed to the additional nodes yet. That step will come later.
+
+ The CloudStack Management server can be installed using either RPM or DEB packages. These packages will depend on everything you need to run the Management server.
+
4.5.3.1. Downloading vhd-util
+ Before setting up the Management Server, download vhd-util from vhd-util
+
+ If the Management Server is RHEL or CentOS, copy vhd-util to /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver.
+
+ If the Management Server is Ubuntu, copy vhd-util to /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util.
+
4.5.3.2. Install on CentOS/RHEL
+ We start by installing the required packages:
+
yum install cloud-client
4.5.3.3. Install on Ubuntu
apt-get install cloud-client
4.5.4. Install the database server
+ The CloudStack management server uses a MySQL database server to store it's data. When you are installing the management server on a single node you can install the MySQL server locally. When using a multi-node installation the MySQL database has to run on an external node.
+
+ CloudStack has been tested with MySQL 5.1 and 5.5, both should work fine. These versions are included in RHEL/CentOS and Ubuntu.
+
4.5.4.1. Install the Database on the Management Server Node
+ This section describes how to install MySQL on the same machine with the Management Server. This technique is intended for a simple deployment that has a single Management Server node. If you have a multi-node Management Server deployment, you will typically use a separate node for MySQL. See Section 4.5.4.2, “Install the Database on a Separate Node”.
+
+ Install MySQL from the package repository from your distribution:
+
yum install mysql-server
apt-get install mysql-server
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes one Management Server.
+
Note
+ On Ubuntu you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add these directives there. Don't forget to add [mysqld] on the first line of the file.
+
+ On RHEL/CentOS MySQL doesn't start after installation, start it manually.
+
service mysqld start
Warning
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password. This step is not required on Ubuntu as it asks for a root password during installation.
+
+ Run this command to secure your installation. Since we are running MySQL locally you can answer "Y" to all questions.
+
mysql_secure_installation
+ Set up the database. The following command creates the "cloud" user on the database.
+
+ In dbpassword, specify the password to be assigned to the "cloud" user. You can choose to provide no password although that is not recommended.
+
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the "cloud" user.
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
4.5.4.2. Install the Database on a Separate Node
+ This section describes how to install MySQL on a standalone machine, separate from the Management Server. This technique is intended for a deployment that includes several Management Server nodes. If you have a single-node Management Server deployment, you will typically use the same node for MySQL. See Section 4.5.4.1, “Install the Database on the Management Server Node”.
+
Note
+ The management server doesn't require a specific distribution for the MySQL node. You can use a distribution or Operating System of your choice. Using the same distribution as the management server is recommended, but not required. See Section 4.3.1, “Management Server, Database, and Storage System Requirements”.
+
+ Install MySQL from the package repository from your distribution:
+
yum install mysql-server
apt-get install mysql-server
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes two Management Servers.
+
Note
+ On Ubuntu you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add these directives there. Don't forget to add [mysqld] on the first line of the file.
+
+ On RHEL/CentOS MySQL doesn't start after installation, start it manually.
+
service mysqld start
Warning
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password. This step is not required on Ubuntu as it asks for a root password during installation.
+
+ Run this command to secure your installation. You can answer "Y" to all questions except to "Disallow root login remotely?". This is required to set up the databases.
+
mysql_secure_installation
+ If a firewall is present on the system, open TCP port 3306 so external MySQL connections can be established.
+
+ On RHEL/CentOS:
+
+ Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the INPUT chain.
+
-A INPUT -p tcp --dport 3306 -j ACCEPT
+ Now reload the iptables rules.
+
service iptables restart
+ On Ubuntu:
+
+ UFW is the default firewall on Ubuntu, open the port with this command:
+
ufw allow mysql
+ Set up the database. The following command creates the cloud user on the database.
+
Note
+ This command should be run on the first Management server node!
+
+ In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password.
+
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
4.5.5. Prepare NFS Shares
+ CloudStack needs a place to keep primary and secondary storage (see Cloud Infrastructure Overview). Both of these can be NFS shares. This section tells how to set up the NFS shares before adding the storage to CloudStack.
+
+ For primary storage, you can use iSCSI instead.
+
+ The requirements for primary and secondary storage are described in:
+
+ This section tells how to set up NFS shares for secondary and (optionally) primary storage on an NFS server running on a separate node from the Management Server.
+
+ The exact commands for the following steps may vary depending on your operating system version.
+
Warning
+ (KVM only) Ensure that no volume is already mounted at your NFS mount point.
+
+ On the storage server, create an NFS share for secondary storage and, if you are using NFS for primary storage as well, create a second NFS share. For example:
+
+ To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s) with rw,async,no_root_squash. For example:
+
# vi /etc/exports
+ Insert the following line.
+
/export *(rw,async,no_root_squash)
+ Export the /export directory.
+
# exportfs -a
+ On the management server, create a mount point for secondary storage. For example:
+
# mkdir -p /mnt/secondary
+ Mount the secondary storage on your Management Server. Replace the example NFS server name and NFS share paths below with your own.
+
# mount -t nfs nfsservername:/nfs/share/secondary /mnt/secondary
4.5.5.2. Using the Management Server As the NFS Server
+ This section tells how to set up NFS shares for primary and secondary storage on the same node with the Management Server. This is more typical of a trial installation, but is technically possible in a larger deployment. It is assumed that you will have less than 16TB of storage on the host.
+
+ The exact commands for the following steps may vary depending on your operating system version.
+
+ On the Management Server host, create two directories that you will use for primary and secondary storage. For example:
+
+ Add the following lines at the beginning of the INPUT chain where <NETWORK> is the network that you'll be using:
+
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 32769 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 662 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 662 -j ACCEPT
+
+ Run the following commands:
+
+# service iptables restart
+# service iptables save
+
+ If NFS v4 communication is used between client and server, add your domain to /etc/idmapd.conf on both the hypervisor host and Management Server.
+
# vi /etc/idmapd.conf
+ Remove the character # from the beginning of the Domain line in idmapd.conf and replace the value in the file with your own domain. In the example below, the domain is company.com.
+
Domain = company.com
+ Reboot the Management Server host.
+
+ Two NFS shares called /export/primary and /export/secondary are now set up.
+
+ It is recommended that you test to be sure the previous steps have been successful.
+
+ Log in to the hypervisor host.
+
+ Be sure NFS and rpcbind are running. The commands might be different depending on your OS. For example:
+
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+# reboot
+
+ Log back in to the hypervisor host and try to mount the /export directories. For example (substitute your own management server name):
+
4.5.6. Prepare and Start Additional Management Servers
+ For your second and subsequent Management Servers, you will install the Management Server software, connect it to the database, and set up the OS for the Management Server.
+
+ Configure the OS and start the Management Server:
+
#cloud-setup-management
+ The Management Server on this node should now be running.
+
+ Repeat these steps on each additional Management Server.
+
+ Be sure to configure a load balancer for the Management Servers. See Management Server Load Balancing.
+
4.5.7. Prepare the System VM Template
+ Secondary storage must be seeded with a template that is used for CloudStack system VMs.
+
Note
+ When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text.
+
+ On the Management Server, run one or more of the following cloud-install-sys-tmplt commands to retrieve and decompress the system VM template. Run the command for each hypervisor type that you expect end users to run in this Zone.
+
+ If your secondary storage mount point is not named /mnt/secondary, substitute your own mount point name.
+
+ If you set the CloudStack database encryption type to "web" when you set up the database, you must now add the parameter -s <management-server-secret-key>. See About Password and Key Encryption.
+
+ This process will require approximately 5 GB of free space on the local file system and up to 30 minutes each time it runs.
+
+ If you are using a separate NFS server, perform this step. If you are using the Management Server as the NFS server, you MUST NOT perform this step.
+
+ When the script has finished, unmount secondary storage and remove the created directory.
+
# umount /mnt/secondary
+# rmdir /mnt/secondary
+ Repeat these steps for each secondary storage server.
+
4.5.8. Installation Complete! Next Steps
+ Congratulations! You have now installed CloudStack Management Server and the database it uses to persist system data.
+
+ What should you do next?
+
+ Even without adding any cloud infrastructure, you can run the UI to get a feel for what's offered and how you will interact with CloudStack on an ongoing basis. See Log In to the UI.
+
+ When you're ready, add the cloud infrastructure and try running some virtual machines on it, so you can watch how CloudStack manages the infrastructure. See Provision Your Cloud Infrastructure.
+
10.9. Moving VMs Between Hosts (Manual Live Migration)
+ The CloudPlatform administrator can move a running VM from one host to another without interrupting service to users or going into maintenance mode. This is called manual live migration, and can be done under the following conditions:
+
+ The root administrator is logged in. Domain admins and users can not perform manual live migration of VMs.
+
+ The VM is running. Stopped VMs can not be live migrated.
+
+ The destination host must be in the same cluster as the original host.
+
+ The VM must not be using local disk storage.
+
+ The destination host must have enough available capacity. If not, the VM will remain in the "migrating" state until memory becomes available.
+
+ To manually live migrate a virtual machine
+
+ Log in to the CloudPlatform UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to migrate.
+
+ Click the Migrate Instance button
+
+
+
+ From the list of hosts, choose the one to which you want to move the VM.
+
4.3.1. Management Server, Database, and Storage System Requirements
+ The machines that will run the Management Server and MySQL database must meet the following requirements. The same machines can also be used to provide primary and secondary storage, such as via localdisk or NFS. The Management Server may be placed on a virtual machine.
+
+ Operating system:
+
+ Preferred: CentOS/RHEL 6.3+ or Ubuntu 12.04(.1)
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ 4 GB of memory
+
+ 50 GB of local disk (When running secondary storage on the management server 500GB is recommended)
+
+ At least 1 NIC
+
+ Statically allocated IP address
+
+ Fully qualified domain name as returned by the hostname command
+
4.3.2. Host/Hypervisor System Requirements
+ The host is where the cloud services run in the form of guest virtual machines. Each host is one machine that meets the following requirements:
+
+ Must support HVM (Intel-VT or AMD-V enabled).
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ Hardware virtualization support required
+
+ 4 GB of memory
+
+ 36 GB of local disk
+
+ At least 1 NIC
+
Note
+ If DHCP is used for hosts, ensure that no conflict occurs between DHCP server used for these hosts and the DHCP router created by CloudStack.
+
+ Latest hotfixes applied to hypervisor software
+
+ When you deploy CloudStack, the hypervisor host must not have any VMs already running
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+ Hosts have additional requirements depending on the hypervisor. See the requirements listed at the top of the Installation section for your chosen hypervisor:
+
Warning
+ Be sure you fulfill the additional hypervisor requirements and installation steps provided in this Guide. Hypervisor hosts must be properly prepared to work with CloudStack. For example, the requirements for XenServer are listed under Citrix XenServer Installation.
+
+ The CloudStack Management Server is deployed on one or more front-end servers connected to a single MySQL database. Optionally a pair of hardware load balancers distributes requests from the web. A backup management server set may be deployed using MySQL replication at a remote site to add DR capabilities.
+
+ The administrator must decide the following.
+
+ Whether or not load balancers will be used.
+
+ How many Management Servers will be deployed.
+
+ Whether MySQL replication will be deployed to enable disaster recovery.
+
+ The CloudStack platform scales well into multiple sites through the use of zones. The following diagram shows an example of a multi-site deployment.
+
+ Data Center 1 houses the primary Management Server as well as zone 1. The MySQL database is replicated in real time to the secondary Management Server installation in Data Center 2.
+
+ This diagram illustrates a setup with a separate storage network. Each server has four NICs, two connected to pod-level network switches and two connected to storage network switches.
+
+ There are two ways to configure the storage network:
+
+ Bonded NIC and redundant switches can be deployed for NFS. In NFS deployments, redundant switches and bonded NICs still result in one network (one CIDR block+ default gateway address).
+
+ iSCSI can take advantage of two separate storage networks (two CIDR blocks each with its own default gateway). Multipath iSCSI client can failover and load balance between separate storage networks.
+
+ This diagram illustrates the differences between NIC bonding and Multipath I/O (MPIO). NIC bonding configuration involves only one network. MPIO involves two separate networks.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/multiple-system-vm-vmware.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/multiple-system-vm-vmware.html
new file mode 100644
index 00000000000..8e2eda51aa2
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/multiple-system-vm-vmware.html
@@ -0,0 +1,12 @@
+
+
+16.2. Multiple System VM Support for VMware
+ Every CloudStack zone has single System VM for template processing tasks such as downloading templates, uploading templates, and uploading ISOs. In a zone where VMware is being used, additional System VMs can be launched to process VMware-specific tasks such as taking snapshots and creating private templates. The CloudStack management server launches additional System VMs for VMware-specific tasks as the load increases. The management server monitors and weights all commands sent to these System VMs and performs dynamic load balancing and scaling-up of more System VMs.
+
+ For the most up-to-date list of supported network services, see the CloudPlatform UI or call listNetworkServices.
+
+ A network offering is a named set of network services, such as:
+
+ DHCP
+
+ DNS
+
+ Source NAT
+
+ Static NAT
+
+ Port Forwarding
+
+ Load Balancing
+
+ Firewall
+
+ VPN
+
+ Optional) Name one of several available providers to use for a given service, such as Juniper for the firewall
+
+ (Optional) Network tag to specify which physical network to use
+
+ When creating a new VM, the user chooses one of the available network offerings, and that determines which network services the VM can use.
+
+ The CloudPlatform administrator can create any number of custom network offerings, in addition to the default network offerings provided by CloudPlatform. By creating multiple custom network offerings, you can set up your cloud to offer different classes of service on a single multi-tenant physical network. For example, while the underlying physical wiring may be the same for two tenants, tenant A may only need simple firewall protection for their website, while tenant B may be running a web server farm and require a scalable firewall solution, load balancing solution, and alternate networks for accessing the database backend.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudPlatform virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+ When creating a new virtual network, the CloudPlatform administrator chooses which network offering to enable for that network. Each virtual network is associated with one network offering. A virtual network can be upgraded or downgraded by changing its associated network offering. If you do this, be sure to reprogram the physical network to match.
+
+ CloudPlatform also has internal network offerings for use by CloudPlatform system VMs. These network offerings are not visible to users but can be modified by administrators.
+
+ For the most up-to-date list of supported network service providers, see the CloudPlatform UI or call listNetworkServiceProviders.
+
+ A service provider (also called a network element) is hardware or virtual appliance that makes a network service possible; for example, a firewall appliance can be installed in the cloud to provide firewall service. On a single network, multiple providers can provide the same network service. For example, a firewall service may be provided by Cisco or Juniper devices in the same physical network.
+
+ You can have multiple instances of the same service provider in a network (say, more than one Juniper SRX device).
+
+ If different providers are set up to provide the same service on the network, the administrator can create network offerings so users can specify which network service provider they prefer (along with the other choices offered in network offerings). Otherwise, CloudPlatform will choose which provider to use whenever the service is called for.
+
Supported Network Service Providers
+ CloudPlatform ships with an internal list of the supported service providers, and you can choose from this list when creating a network offering.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/networking-in-a-pod.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/networking-in-a-pod.html
new file mode 100644
index 00000000000..d5496bd8495
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/networking-in-a-pod.html
@@ -0,0 +1,22 @@
+
+
+15.2. Networking in a Pod
+ Figure 2 illustrates network setup within a single pod. The hosts are connected to a pod-level switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
+
+ Servers are connected as follows:
+
+ Storage devices are connected to only the network that carries management traffic.
+
+ Hosts are connected to networks for both management traffic and public traffic.
+
+ Hosts are also connected to one or more networks carrying guest traffic.
+
+ We recommend the use of multiple physical Ethernet cards to implement each network interface as well as redundant switch fabric in order to maximize throughput and improve reliability.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/networking-in-a-zone.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/networking-in-a-zone.html
new file mode 100644
index 00000000000..8950e1e9633
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/networking-in-a-zone.html
@@ -0,0 +1,16 @@
+
+
+15.3. Networking in a Zone
+ Figure 3 illustrates the network setup within a single zone.
+
+ A firewall for management traffic operates in the NAT mode. The network typically is assigned IP addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses in the 192.168.*.0/24 Class C private address space.
+
+ Each zone has its own set of public IP addresses. Public IP addresses from different zones do not overlap.
+
+ People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a CloudStack administrator, you can do the following things to set up networking for your users:
+
+ Set up physical networks in zones
+
+ Set up several different providers for the same service on a single physical network (for example, both Cisco and Juniper firewalls)
+
+ Bundle different types of network services into network offerings, so users can choose the desired network services for any given virtual machine
+
+ Add new network offerings as time goes on so end users can upgrade to a better class of service on their network
+
+ Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member
+
+ In a CloudStack, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN. The CloudStack virtual router is the main component providing networking features for guest traffic.
+
4.1. Service Offerings, Disk Offerings, Network Offerings, and Templates
+ A user creating a new instance can make a variety of choices about its characteristics and capabilities. CloudStack provides several ways to present users with choices when creating a new instance:
+
+ Service Offerings, defined by the CloudStack administrator, provide a choice of CPU speed, number of CPUs, RAM size, tags on the root disk, and other choices. See Creating a New Compute Offering.
+
+ Disk Offerings, defined by the CloudStack administrator, provide a choice of disk size for primary data storage. See Creating a New Disk Offering.
+
+ Network Offerings, defined by the CloudStack administrator, describe the feature set that is available to end users from the virtual router or external networking devices on a given guest network. See Network Offerings.
+
+ Templates, defined by the CloudStack administrator or by any CloudStack user, are the base OS images that the user can choose from when creating a new instance. For example, CloudStack includes CentOS as a template. See Working with Templates.
+
+ In addition to these choices that are provided for users, there is another type of service offering which is available only to the CloudStack root administrator, and is used for configuring virtual infrastructure resources. For more information, see Upgrading a Virtual Router with System Service Offerings.
+
+ In this chapter we discuss compute, disk, and system service offerings. Network offerings are discussed in the section on setting up networking for users.
+
+ CloudStack allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of all accounts in the domain as well as all accounts in all subdomains of that domain. Limits set at the root domain level apply to the sum of resource usage by the accounts in all domains and sub-domains below that root domain.
+
+ To set a domain limit:
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Domains.
+
+ Select the domain you want to modify. The current domain limits are displayed. A value of -1 shows that there is no limit in place.
+
+ Host and guest performance monitoring is available to end users and administrators. This allows the user to monitor their utilization of resources and determine when it is appropriate to choose a more powerful service offering or larger disk.
+
+ 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.
+
+ Any standards-compliant iSCSI or NFS server that is supported by the underlying hypervisor.
+
+ The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller.
+
+ Minimum required capacity depends on your needs.
+
+ When setting up primary storage, follow these restrictions:
+
+ Primary storage cannot be added until a host has been added to the cluster.
+
+ If you do not provision shared primary storage, you must set the global configuration parameter system.vm.local.storage.required to true, or else you will not be able to start VMs.
+
7.6.2. Adding Primary Stroage
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+
+ Click the Compute tab.
+
+ In the Primary Storage node of the diagram, click View All.
+
+ Click Add Primary Storage.
+
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+
+ Pod. The pod for the storage device.
+
+ Cluster. The cluster for the storage device.
+
+ Name. The name of the storage device.
+
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS.
+
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device.
+
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+
+ Path (for NFS). In NFS this is the exported path from the server.
+
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside CloudStack.
+
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
+
+ Lun # (for iSCSI). In iSCSI this is 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.
+
+ When a primary storage outage occurs the hypervisor immediately stops all VMs stored on that storage device. Guests that are marked for HA will be restarted as soon as practical when the primary storage comes back on line. With NFS, the hypervisor may allow the virtual machines to continue running depending on the nature of the issue. For example, an NFS hang will cause the guest VMs to be suspended until storage connectivity is restored.Primary storage is not designed to be backed up. Individual volumes in primary storage can be backed up using snapshots.
+
+ This section gives concepts and technical details about CloudPlatform primary storage. For information about how to install and configure primary storage through the CloudPlatform UI, see the Advanced Installation Guide.
+
+ When a user creates a template, it can be designated private or public.
+
+ Private templates are only available to the user who created them. By default, an uploaded template is private.
+
+ When a user marks a template as “public,” the template becomes available to all users in all accounts in the user's domain, as well as users in any other domains that have access to the Zone where the template is stored. This depends on whether the Zone, in turn, was defined as private or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any domain. If a public template is created in a private Zone, it is available only to users in the domain assigned to that Zone. If a public template is created in a public Zone, it is available to all users in all domains.
+
+ 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..
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects.html
new file mode 100644
index 00000000000..07939abbb71
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/projects.html
@@ -0,0 +1,10 @@
+
+
+Chapter 6. Using Projects to Organize Users and Resources
+ 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.
+
+ 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”.
+
+ To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
+
+ This section tells how to add 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.
+
+ 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.
+
+ Hosts can be removed from the cloud as needed. The procedure to remove a host depends on the hypervisor type.
+
11.4.1. 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:
+
+ Then you may power down the Host, re-use its IP address, re-install it, etc
+
11.4.2. 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”. 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.
+
+ CloudStack supports two formats as the response to an API call. The default response is XML. If you would like the response to be in JSON, add &response=json to the Command String.
+
+ For each cloud, there is a default upper limit on the number of results that any API command will return in a single page. This is to help prevent overloading the cloud servers and prevent DOS attacks. For example, if the page size limit is 500 and a command returns 10,000 results, the command will return 20 pages.
+
+ The default page size limit can be different for each cloud. It is set in the global configuration parameter default.page.size. If your cloud has many users with lots of VMs, you might need to increase the value of this parameter. At the same time, be careful not to set it so high that your site can be taken down by an enormous return from an API call. For more information about how to set global configuration parameters, see "Describe Your Deployment" in the Installation Guide.
+
+ To decrease the page size limit for an individual API command, override the global setting with the page and pagesize parameters, which are available in any list* command (listCapabilities, listDiskOfferings, etc.).
+
+ Both parameters must be specified together.
+
+ The value of the pagesize parameter must be smaller than the value of default.page.size. That is, you can not increase the number of possible items in a result page, only decrease it.
+
+ For syntax information on the list* commands, see the API Reference.
+
4.4.3. Error Handling
+ If an error occurs while processing an API request, the appropriate response in the format specified is returned. Each error response consists of an error code and an error text describing what possibly can go wrong. For an example error response, see page 12.
+
+ An HTTP error code of 401 is always returned if API request was rejected due to bad signatures, missing API Keys, or the user simply did not have the permissions to execute the command.
+
11.2. 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.
+
+ (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org)
+
+ 100GB minimum capacity
+
+ A secondary storage device must be located in the same zone as the guest VMs it serves.
+
+ Each Secondary Storage server must be available to all hosts in the zone.
+
7.7.2. Adding Secondary Storage
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to CloudStack before you add the local zone secondary storage servers. See Section 7.2, “Adding a Zone”.
+
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See Preparing NFS Shares in the Installation Guide.
+
+ Make sure you prepared the system VM template during Management Server installation. See Prepare the System VM Template in the Installation Guide.
+
+ Now that the secondary storage server for per-zone storage is prepared, add it to CloudStack. Secondary storage is added as part of the procedure for adding a new zone. See Section 7.2, “Adding a Zone”.
+
+ For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online.
+
+ Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system.
+
+ In addition to the hosts, CloudStack’s Secondary Storage VM mounts and writes to secondary storage.
+
+ Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols.
+
+ The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups.
+
+ The administrator can log in to the secondary storage VM if needed.
+
+ This section gives concepts and technical details about CloudStack secondary storage. For information about how to install and configure secondary storage through the CloudStack UI, see the Advanced Installation Guide.
+
+ In addition to the bootstrap dependencies, you'll also need to install several other dependencies. Note that we recommend using Maven 3, which is not currently available in 12.04.1 LTS. So, you'll also need to add a PPA repository that includes Maven 3. After running the command add-apt-repository, you will be prompted to continue and a GPG key will be added.
+
+ While we have defined, and you have presumably already installed the bootstrap prerequisites, there are a number of build time prerequisites that need to be resolved. CloudStack uses maven for dependency resolution. You can resolve the buildtime depdencies for CloudStack by running:
+
$ mvn3 -P deps
+ Now that we have resolved the dependencies we can move on to building CloudStack and packaging them into DEBs by issuing the following command.
+
+$ dpkg-buildpackge -uc -us
+ This command will build 16 Debian packages. You should have all of the following:
+
+ After you've created the packages, you'll want to copy them to a system where you can serve the packages over HTTP. You'll create a directory for the packages and then use dpkg-scanpackages to create Packages.gz, which holds information about the archive structure. Finally, you'll add the repository to your system(s) so you can install the packages using APT.
+
+ The first step is to make sure that you have the dpkg-dev package installed. This should have been installed when you pulled in the debhelper application previously, but if you're generating Packages.gz on a different system, be sure that it's installed there as well.
+
$ sudo apt-get install dpkg-dev
+ The next step is to copy the DEBs to the directory where they can be served over HTTP. We'll use /var/www/cloudstack/repo in the examples, but change the directory to whatever works for you.
+
+ You can safely ignore the warning about a missing override file.
+
+ Now you should have all of the DEB packages and Packages.gz in the binary directory and available over HTTP. (You may want to use wget or curl to test this before moving on to the next step.)
+
3.5.2. Configuring your machines to use the APT repository
+ Now that we have created the repository, you need to configure your machine to make use of the APT repository. You can do this by adding a repository file under /etc/apt/sources.list.d. Use your preferred editor to create /etc/apt/sources.list.d/cloudstack.list with this line:
+
deb http://server.url/cloudstack/repo binary/
+ Now that you have the repository info in place, you'll want to run another update so that APT knows where to find the CloudStack packages.
+
$ sudo apt-get update
+ You can now move on to the instructions under Install on Ubuntu.
+
+ While we have defined, and you have presumably already installed the bootstrap prerequisites, there are a number of build time prerequisites that need to be resolved. CloudStack uses maven for dependency resolution. You can resolve the buildtime depdencies for CloudStack by running the following command:
+
$mvn -P deps
+
+
+ Now that we have resolved the dependencies we can move on to building CloudStack and packaging them into RPMs by issuing the following command.
+
$./waf rpm
+
+
+ Once this completes, you should find assembled RPMs in artifacts/rpmbuild/RPMS/x86_64
+
3.6.1. Creating a yum repo
+ While RPMs is an ideal packaging format - it's most easily consumed from yum repositories over a network. We'll move into the directory with the newly created RPMs by issuing the following command:
+
$cd artifacts/rpmbuild/RPMS/x86_64
+
+
+ Next we'll issue a command to create the repository metadata by issuing the following command:
+
$createrepo ./
+
+
+ The files and directories within our current working directory can now be uploaded to a web server and serve as a yum repository
+
3.6.2. Configuring your systems to use your new yum repository
+ Now that your yum repository is populated with RPMs and metadata we need to configure our machines that need to install CloudStack. We will create a file at /etc/yum.repos.d/cloudstack.repo with the following content:
+
+ There are a number of prerequisites needed to build CloudStack. This document assumes compilation on a Linux system that uses RPMs or DEBs for package management.
+
+ The minimum bootstrapped prerequisites for building CloudStack includes the following:
+
+ If the signature is valid you will see a line of output that contains 'Good signature'.
+
3.2.3. MD5
+ In addition to the cryptographic signature, the CloudStack provides a number of cryptographic hashes to aid in assurance of validity of the downloaded release. You can verify this hash by executing the following command:
+
+ If this successfully completes you should see no output. If there is any output from them, then there is a difference between the hash you generated locally and the hash that has been pulled from the server.
+
3.2.4. SHA512
+ In addition to the MD5 hash, the CloudStack project provides a SHA512 cryptographic hash to aid in assurance of the validity of the downloaded release. You can verify this hash by executing the following command:
+
+ If this command successfully completes you should see no output. If there is any output from them, then there is a difference between the hash you generated locally and the hash that has been pulled from the server.
+
+ The official CloudStack release is always in source code form. While there may exist convenience binaries in various forms from a number of places, the source is the canonical release will be source. In this document we'll cover acquiring the source release, building that into binary, deployable packages.
+
+ While building and deploying directly from source is certainly possible, the reality of Infrastructure-as-a-Service cloud computing implies a need to deploy packages on a potentially large number of systems, which RPMs and DEBs fill nicely.
+
+ Building and deploying directly from source is thus outside the scope of this document, but is documented in the INSTALL.md file in the release.
+
+ Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In CloudStack 3.0.3 - 3.0.5, security groups are supported only in zones that use basic networking.
+
Note
+ In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
+
+
+ Each CloudStack account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.
+
+ Any CloudStack user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.
+
+ You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.
+
+ If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
15.7.2. Adding a Security Group
+ A user or administrator can define a new security group.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups.
+
+ Click Add Security Group.
+
+ Provide a name and description.
+
+ Click OK.
+
+ The new security group appears in the Security Groups Details tab.
+
+ To make the security group useful, continue to Adding Ingress and Egress Rules to a Security Group.
+
15.7.3. Enabling Security Groups
+ In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide.
+
15.7.4. Adding Ingress and Egress Rules to a Security Group
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups, then click the security group you want .
+
+ To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify what network traffic is allowed into VM instances in this security group. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
+ Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow incoming traffic from all VMs in another security group
+
+ Protocol. The networking protocol that sources will use to send traffic to the security group. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be accepted.
+
+ CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To accept only traffic from another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter the same name you used in step 7.
+
+ The following example allows inbound HTTP access from anywhere:
+
+ To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been allowed in through an ingress rule
+
+ Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow outgoing traffic to all VMs in another security group.
+
+ Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
+
+ CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To allow traffic to be sent to another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter its name.
+
+ In the large-scale redundant setup described in the previous section, storage traffic can overload the management network. A separate storage network is optional for deployments. Storage protocols such as iSCSI are sensitive to network delays. A separate storage network ensures guest network traffic contention does not impact storage performance.
+
+ It is important to provide enough memory space for the MySQL database to cache data and indexes:
+
+ Edit the Tomcat configuration file:
+
/etc/my.cnf
+ Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM.
+
innodb_buffer_pool_size=700M
+ Restart the MySQL service.
+
# service mysqld restart
+ For more information about the buffer pool, see "The InnoDB Buffer Pool" at MySQL Reference Manual.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/set-monitor-total-vm-limits-per-host.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/set-monitor-total-vm-limits-per-host.html
new file mode 100644
index 00000000000..a0059005615
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/set-monitor-total-vm-limits-per-host.html
@@ -0,0 +1,12 @@
+
+
+21.4. Set and Monitor Total VM Limits per Host
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
+ CloudStack provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis.
+
+ Aggregate limits may be set on a per-domain basis. For example, you may limit a domain and all subdomains to the creation of 100 VMs.
+
+ Whether you access the CloudStack API with HTTP or HTTPS, it must still be signed so that CloudStack can verify the caller has been authenticated and authorized to execute the command. Make sure that you have both the API Key and Secret Key provided by the CloudStack administrator for your account before proceeding with the signing process.
+
+ To show how to sign a request, we will re-use the previous example.
+
+ Signature: This is the hashed signature of the Base URL that is generated using a combination of the user’s Secret Key and the HMAC SHA-1 hashing algorithm.
+
+ &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+ Every API request has the format Base URL+API Path+Command String+Signature.
+
+ To generate the signature.
+
+ For each field-value pair (as separated by a '&') in the Command String, URL encode each value so that it can be safely sent via HTTP GET.
+
Note
+ Make sure all spaces are encoded as "%20" rather than "+".
+
+ Lower case the entire Command String and sort it alphabetically via the field for each field-value pair. The result of this step would look like the following.
+
+ Take the sorted Command String and run it through the HMAC SHA-1 hashing algorithm (most programming languages offer a utility method to do this) with the user’s Secret Key. Base64 encode the resulting byte array in UTF-8 so that it can be safely transmitted via HTTP. The final string produced after Base64 encoding should be "Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D".
+
+ By reconstructing the final URL in the format Base URL+API Path+Command String+Signature, the final URL should look like:
+
+ This diagram illustrates the network architecture of a small-scale CloudStack deployment.
+
+ A firewall provides a connection to the Internet. The firewall is configured in NAT mode. The firewall forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+
+ A layer-2 switch connects all physical servers and storage.
+
+ A single NFS server functions as both the primary and secondary storage.
+
+ The Management Server is connected to the management network.
+
+ A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
+
18.5. 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:
+
+ CloudStack defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS.
+
+ There is no ephemeral storage in CloudStack. All volumes on all nodes are persistent.
+
+ The Apache CloudStack project has mailing lists for users and developers. These are the official channels of communication for the project and are the best way to get answers about using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users mailing list if you've deployed or are deploying CloudStack into production, and even for test deployments.
+
+ The CloudStack developer's mailing list (cloudstack-dev) is for discussions about CloudStack development, and is the best list for discussing possible bugs in CloudStack. Anyone contributing to CloudStack should be on this mailing list.
+
+ 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.
+
+ System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the CloudStack root administrator. CloudStack provides default system service offerings. The CloudStack root administrator can create additional custom system service offerings.
+
+ When CloudStack creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/system-vm-template.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/system-vm-template.html
new file mode 100644
index 00000000000..f7f10299cb3
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/system-vm-template.html
@@ -0,0 +1,26 @@
+
+
+16.1. The System VM Template
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/tagging-resources.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/tagging-resources.html
new file mode 100644
index 00000000000..e1566996281
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/tagging-resources.html
@@ -0,0 +1,55 @@
+
+
+18.1. Using Tags to Organize Resources in the Cloud
18.1. 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:
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/time-zones.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/time-zones.html
new file mode 100644
index 00000000000..bf6dbcbed45
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/time-zones.html
@@ -0,0 +1,251 @@
+
+
+Appendix A. Time Zones
+ 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.
+
+ 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:
+
22.8. 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 CloudPlatform 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.
+
+ Host was placed in maintenance mode, but still appears live in vCenter.
+
Cause
+ The CloudPlatform 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.
+
+ 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.
+
22.6. 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.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/troubleshooting-unable-to-power-on-vm.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/troubleshooting-unable-to-power-on-vm.html
new file mode 100644
index 00000000000..0ed9b70b8ee
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/troubleshooting-unable-to-power-on-vm.html
@@ -0,0 +1,24 @@
+
+
+22.7. Unable to power on virtual machine on VMware
22.7. 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.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/troubleshooting-working-with-server-logs.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/troubleshooting-working-with-server-logs.html
new file mode 100644
index 00000000000..cbcf3513ecb
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/troubleshooting-working-with-server-logs.html
@@ -0,0 +1,26 @@
+
+
+22.2. Working with Server Logs
+ The CloudStack Management Server logs all web site, middle tier, and database activities for diagnostics purposes in /var/log/cloud/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.
+
+ 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:
+
+ 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:
+
+ grep "job-1076)" management-server.log
+
+ The CloudStack Agent Server logs its activities in /var/log/cloud/agent/.
+
+ Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note that some of the steps here are only required if you're using a specific hypervisor. The steps that are hypervisor-specific are called out with a note.
+
+ Ensure that you query your IP address usage records and process them or make a backup. During the upgrade you will lose the old IP address usage records.
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading, any existing IP address usage records in the old format will no longer be available.
+
Note
+ The following upgrade instructions apply only if you're using VMware hosts. If you're not using VMware hosts, skip this step and move on to step 3: stopping all usage servers.
+
+ In each zone that includes VMware hosts, you need to add a new system VM template.
+
+ While running the existing 3.0.2 system, log in to the UI as root administrator.
+
+ In the left navigation bar, click Templates.
+
+ In Select view, click Templates.
+
+ Click Register template.
+
+ The Register template dialog box is displayed.
+
+ In the Register template dialog box, specify the following values (do not change these):
+
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful.
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+
# service cloud-usage stop
+ Stop the Management Servers. Run this on all Management Server hosts.
+
# service cloud-management stop
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+ 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.
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
+
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
+
#yum update cloud-*
+
+
#apt-get update
+#apt-get upgrade cloud-*
+
+
Note
+ If the upgrade output includes a message similar to the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+
warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+ Instructions follow in the next step.
+
+ If you have made changes to your copy of /etc/cloud/management/components.xml the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+ Make a backup copy of /etc/cloud/management/components.xml. For example:
+
+ Merge your changes from the backup file into the new components.xml.
+
# vi /etc/cloud/management/components.xml
Note
+ If you have more than one management server node, repeat the upgrade steps on each node.
+
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+
# service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. After confirmation, start the other Management Servers one at a time by running the same command on each node.
+
Note
+ Failing to restart the Management Server indicates a problem in the upgrade. Having the Management Server restarted without any issues indicates that the upgrade is successfully completed.
+
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
+ # service cloud-usage start
+
Note
+ Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+
+ Configure a yum or apt respository containing the CloudStack packages as outlined in the Installation Guide.
+
+ Stop the running agent.
+
+ # service cloud-agent stop
+
+ Update the agent software with one of the following command sets as appropriate for your environment.
+
+ # yum update cloud-*
+
+ # apt-get update
+
+ # apt-get upgrade cloud-*
+
+ Start the agent.
+
# service cloud-agent start
+ Edit /etc/cloud/agent/agent.properties to change the resource parameter from "com.cloud.agent.resource.computing.LibvirtComputingResource" to "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
+
+ Start the cloud agent and cloud management services.
+
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+
+ Log in to the CloudStack UI as administrator, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
Note
+ Troubleshooting: If login fails, clear your browser cache and reload the page.
+
+
+ Do not proceed to the next step until the hosts show in Up state.
+
+ If you are upgrading from 3.0.2, perform the following:
+
+ Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter.
+
+ This port is used by the cloud-sysvmadm script at the end of the upgrade procedure. For information about how to set this parameter, see "Setting Global Configuration Parameters" in the Installation Guide.
+
+ Restart the Management Server.
+
Note
+ If you don't want the admin port to remain open, you can set it to null after the upgrade is done and restart the management server.
+
+ Run the cloud-sysvmadm script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the -c and -r arguments. For example:
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+
+ Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+
+ Disconnect the XenServer cluster from CloudStack.
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+
+ To clean up the VLAN, log in to one XenServer host and run:
+
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+ Now prepare the upgrade by running the following on one XenServer host:
+
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+
+ If you see a message like "can't eject CD", log in to the VM and unmount the CD, then run this script again.
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /tmp.
+
+ On the Xen pool master, upload the hotfix with this command:
+
+ xe patch-upload file-name=XS602E003.xsupdate
+
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+
Note
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
+ # xe vm-list
+
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+ Apply the hotfix. First, get the UUID of this host:
+
# xe host-list
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
# xe-switch-network-backend bridge
+ Reboot this XenServer host.
+
+ Run the following:
+
/opt/xensource/bin/setupxenserver.sh
Note
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+
+ Run the following:
+
for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+
Troubleshooting Tip
+ If passwords which you know to be valid appear not to work after upgrade, or other UI issues are seen, try clearing your browser cache and reloading the UI page.
+
2.2. Upgrade from 2.2.14 to 4.0.0-incubating
+ Ensure that you query your IPaddress usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading to 4.0.0-incubating, any existing IP address usage records in the old format will no longer be available.
+
+ If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the instructions in the 2.2.14 Release Notes.
+
KVM Hosts
+ If KVM hypervisor is used in your cloud, be sure you completed the step to insert a valid username and password into the host_details table on each KVM node as described in the 2.2.14 Release Notes. This step is critical, as the database will be encrypted after the upgrade to 4.0.0-incubating.
+
+ While running the 2.2.14 system, log in to the UI as root administrator.
+
+ Using the UI, add a new System VM template for each hypervisor type that is used in your cloud. In each zone, add a system VM template for each hypervisor used in that zone
+
+ In the left navigation bar, click Templates.
+
+ In Select view, click Templates.
+
+ Click Register template.
+
+ The Register template dialog box is displayed.
+
+ In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: VMware
+
+
+ Format: OVA
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful
+
+ WARNING: If you use more than one type of hypervisor in your cloud, be sure you have repeated these steps to download the system VM template for each hypervisor type. Otherwise, the upgrade will fail.
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+
# service cloud-usage stop
+ Stop the Management Servers. Run this on all Management Server hosts.
+
# service cloud-management stop
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+ 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.
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
+
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
+
#yum update cloud-*
+
+
#apt-get update
+#apt-get upgrade cloud-*
+
+
+ If you have made changes to your existing copy of the file components.xml in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
Note
+ How will you know whether you need to do this? If the upgrade output in the previous step included a message like the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+
warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+ Make a backup copy of your /etc/cloud/management/components.xml file. For example:
+
+ Merge your changes from the backup file into the new components.xml file.
+
#vi/etc/cloud/management/components.xml
+
+ If you have made changes to your existing copy of the /etc/cloud/management/db.properties file in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+ Make a backup copy of your file /etc/cloud/management/db.properties. For example:
+
+ Merge your changes from the backup file into the new db.properties file.
+
#vi/etc/cloud/management/db.properties
+ On the management server node, run the following command. It is recommended that you use the command-line flags to provide your own encryption keys. See Password and Key Encryption in the Installation Guide.
+
+ When used without arguments, as in the following example, the default encryption type and keys will be used:
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file.
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the properties file. Default: password. It is highly recommended that you replace this with a more secure value
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value.
+
+ Repeat steps 10 - 14 on every management server node. If you provided your own encryption key in step 14, use the same key on all other management servers.
+
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+
# service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. You should see a message like "Complete! Done." After confirmation, start the other Management Servers one at a time by running the same command on each node.
+
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
# service cloud-usage start
+ (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+
+ Configure your CloudStack package repositories as outlined in the Installation Guide
+
+ Stop the running agent.
+
# service cloud-agent stop
+ Update the agent software with one of the following command sets as appropriate.
+
#yum update cloud-*
+ #apt-get update
+#apt-get upgrade cloud-*
+
+ Start the agent.
+
# service cloud-agent start
+ Copy the contents of the agent.properties file to the new agent.properties file by using the following command
+
sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.properties
+ Start the cloud agent and cloud management services.
+
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+
+ Log in to the CloudStack UI as admin, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
+ Do not proceed to the next step until the hosts show in the Up state. If the hosts do not come to the Up state, contact support.
+
+ Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers.
+
+ Run the command once on one management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the "-c" and "-r" arguments. For example:
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+
+ After the script terminates, check the log to verify correct execution:
+
#tail -f sysvm.log
+ The content should be like the following:
+
+Stopping and starting 1 secondary storage vm(s)...
+Done stopping and starting secondary storage vm(s)
+Stopping and starting 1 console proxy vm(s)...
+Done stopping and starting console proxy vm(s).
+Stopping and starting 4 running routing vm(s)...
+Done restarting router(s).
+
+ If you would like additional confirmation that the new system VM templates were correctly applied when these system VMs were rebooted, SSH into the System VM and check the version.
+
+ Use one of the following techniques, depending on the hypervisor.
+
XenServer or KVM:
+ SSH in by using the link local IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own link local IP.
+
+ Run the following commands on the XenServer or KVM host on which the system VM is present:
+
Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
ESXi
+ SSH in using the private IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own private IP.
+
+ Run the following commands on the Management Server:
+
Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+
+ Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+
+ Disconnect the XenServer cluster from CloudStack.
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+
+ To clean up the VLAN, log in to one XenServer host and run:
+
/opt/xensource/bin/cloud-clean-vlan.sh
+ Prepare the upgrade by running the following on one XenServer host:
+
/opt/xensource/bin/cloud-prepare-upgrade.sh
+ If you see a message like "can't eject CD", log in to the VM and umount the CD, then run this script again.
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /root or /tmp.
+
+ On the Xen pool master, upload the hotfix with this command:
+
xe patch-upload file-name=XS602E003.xsupdate
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+
Note
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
# xe vm-list
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+ Apply the hotfix. First, get the UUID of this host:
+
+ # xe host-list
+
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+ If you are uploading a template that was created using vSphere Client, be sure the OVA file does not contain an ISO. If it does, the deployment of VMs from the template will fail.
+
+ Templates are uploaded based on a URL. HTTP is the supported access protocol. Templates are frequently large files. You can optionally gzip them to decrease upload times.
+
+ To upload a template:
+
+ In the left navigation bar, click Templates.
+
+ Click Create Template.
+
+ Provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ URL. The Management Server will download the file from the specified URL, such as http://my.web.server/filename.vhd.gz.
+
+ Zone. Choose the zone where you want the template to be available, or All Zones to make it available throughout CloudStack.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following:
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
Note
+ You should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Hypervisor
+
+ Format. The format of the template upload file, such as VHD or OVA.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates
+
+ Extractable. Choose Yes if the template is available for extraction. If this option is selected, end users can download a full image of a template.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”
+
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. The template will appear in the Featured Templates list. Only an administrator can make a template Featured.
+
+ For running and allocated virtual machine usage, the following fields exist in a usage record:
+
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for VM running time)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ virtualMachineId – The ID of the virtual machine
+
+ name – The name of the virtual machine
+
+ offeringid – The ID of the service offering
+
+ templateid – The ID of the template or the ID of the parent template. The parent template value is present when the current template was created from a volume.
+
+ usageid – Virtual machine
+
+ type – Hypervisor
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.2. Network Usage Record Format
+ For network usage (bytes sent/received), the following fields exist in a usage record.
+
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – Device ID (virtual router ID or external device ID)
+
+ type – Device type (domain router, external load balancer, etc.)
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.3. IP Address Usage Record Format
+ For IP address usage the following fields exist in a usage record.
+
+ account - name of the account
+
+ accountid - ID of the account
+
+ domainid - ID of the domain in which this account resides
+
+ zoneid - Zone where the usage occurred
+
+ description - A string describing what the usage record is tracking
+
+ usage - String representation of the usage, including the units of usage
+
+ usagetype - A number representing the usage type (see Usage Types)
+
+ rawusage - A number representing the actual usage in hours
+
+ usageid - IP address ID
+
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+ issourcenat - Whether source NAT is enabled for the IP address
+
+ iselastic - True if the IP address is elastic.
+
5.1.4. Disk Volume Usage Record Format
+ For disk volumes, the following fields exist in a usage record.
+
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – The volume ID
+
+ offeringid – The ID of the disk offering
+
+ type – Hypervisor
+
+ templateid – ROOT template ID
+
+ size – The amount of storage allocated
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.5. Template, ISO, and Snapshot Usage Record Format
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – The ID of the the template, ISO, or snapshot
+
+ offeringid – The ID of the disk offering
+
+ templateid – – Included only for templates (usage type 7). Source template ID.
+
+ size – Size of the template, ISO, or snapshot
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.6. Load Balancer Policy or Port Forwarding Rule Usage Record Format
+ account - name of the account
+
+ accountid - ID of the account
+
+ domainid - ID of the domain in which this account resides
+
+ zoneid - Zone where the usage occurred
+
+ description - A string describing what the usage record is tracking
+
+ usage - String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype - A number representing the usage type (see Usage Types)
+
+ rawusage - A number representing the actual usage in hours
+
+ usageid - ID of the load balancer policy or port forwarding rule
+
+ usagetype - A number representing the usage type (see Usage Types)
+
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.7. Network Offering Usage Record Format
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – ID of the network offering
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ offeringid – Network offering ID
+
+ virtualMachineId – The ID of the virtual machine
+
+ virtualMachineId – The ID of the virtual machine
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.8. VPN User Usage Record Format
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – VPN user ID
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+ Tracks the total running time of a VM per usage record period. If the VM is upgraded during the usage period, you will get a separate Usage Record for the new upgraded VM.
+
+
+ 2
+
+
+
+ ALLOCATED_VM
+
+
+
+ Tracks the total time the VM has been created to the time when it has been destroyed. This usage type is also useful in determining usage for specific templates such as Windows-based templates.
+
+
+
+ 3
+
+
+
+ IP_ADDRESS
+
+
+
+ Tracks the public IP address owned by the account.
+
+
+
+ 4
+
+
+
+ NETWORK_BYTES_SENT
+
+
+
+ Tracks the total number of bytes sent by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+
+ 5
+
+
+
+ NETWORK_BYTES_RECEIVED
+
+
+
+ Tracks the total number of bytes received by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+
+ 6
+
+
+
+ VOLUME
+
+
+
+ Tracks the total time a disk volume has been created to the time when it has been destroyed.
+
+
+
+ 7
+
+
+
+ TEMPLATE
+
+
+
+ Tracks the total time a template (either created from a snapshot or uploaded to the cloud) has been created to the time it has been destroyed. The size of the template is also returned.
+
+
+
+ 8
+
+
+
+ ISO
+
+
+
+ Tracks the total time an ISO has been uploaded to the time it has been removed from the cloud. The size of the ISO is also returned.
+
+
+
+ 9
+
+
+
+ SNAPSHOT
+
+
+
+ Tracks the total time from when a snapshot has been created to the time it have been destroyed.
+
+
+
+ 11
+
+
+
+ LOAD_BALANCER_POLICY
+
+
+
+ Tracks the total time a load balancer policy has been created to the time it has been removed. Cloud.com does not track whether a VM has been assigned to a policy.
+
+
+
+ 12
+
+
+
+ PORT_FORWARDING_RULE
+
+
+
+ Tracks the time from when a port forwarding rule was created until the time it was removed.
+
+
+
+ 13
+
+
+
+ NETWORK_OFFERING
+
+
+
+ The time from when a network offering was assigned to a VM until it is removed.
+
+
+
+ 14
+
+
+
+ VPN_USERS
+
+
+
+ The time from when a VPN user is created until it is removed.
+
+ 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.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/user-data-and-meta-data.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/user-data-and-meta-data.html
new file mode 100644
index 00000000000..6d914306531
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/user-data-and-meta-data.html
@@ -0,0 +1,34 @@
+
+
+20.3. User Data and Meta Data
+ CloudStack provides API access to attach 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.
+
+ Access user data by running the following command using the result of the above command
+
# 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
+
+ In addition to the physical and logical infrastructure of your cloud, and the CloudStack software and servers, you also need a layer of user services so that people can actually make use of the cloud. This means not just a user UI, but a set of options and resources that users can choose from, such as templates for creating virtual machines, disk storage, and more. If you are running a commercial service, you will be keeping track of what services and resources users are consuming and charging them for that usage. Even if you do not charge anything for people to use your cloud – say, if the users are strictly internal to your organization, or just friends who are sharing your cloud – you can still keep track of what services they use and how much of them.
+
+ In zones that use advanced networking, additional networks for guest traffic may be added at any time after the initial installation. You can also customize the domain name associated with the network by specifying a DNS suffix for each network.
+
+ A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has been created, although the user can go into the guest and remove the IP address from the NIC on a particular network.
+
+ Each VM has just one default network. The virtual router's DHCP reply will set the guest's default gateway as that for the default network. Multiple non-default networks may be added to a guest in addition to the single, required default network. The administrator can control which networks are available as the default network.
+
+ Additional networks can either be available to all accounts or be assigned to a specific account. Networks that are available to all accounts are zone-wide. Any user with access to the zone can create a VM with access to that network. These zone-wide networks provide little or no isolation between guests.Networks that are assigned to a specific account provide strong isolation.
+
15.6.1. Adding an Additional Guest Network
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click Add guest network. Provide the following information:
+
+ Name: The name of the network. This will be user-visible.
+
+ Display Text: The description of the network. This will be user-visible.
+
+ Zone. The name of the zone this network applies to. Each zone is a broadcast domain, and therefore each zone has a different IP range for the guest network. The administrator must configure the IP range for each zone.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network.
+
+ Guest Gateway: The gateway that the guests should use.
+
+ Guest Netmask: The netmask in use on the subnet the guests will use.
+
+ Click Create.
+
15.6.2. Changing the Network Offering on a Guest Network
+ A user or administrator can change the network offering that is associated with an existing guest network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ If you are changing from a network offering that uses the CloudStack virtual router to one that uses external devices as network service providers, you must first stop all the VMs on the network. See Stopping and Starting VMs. Then return here and continue to the next step
+
+ In the left navigation, choose Network
+
+ Click the name of the network you want to modify
+
+ .
+
+ In Network Offering, choose the new network offering, then click Apply.
+
+ A prompt appears asking whether you want to keep the existing CIDR. This is to let you know that if you change the network offering, the CIDR will be affected. Choose No to proceed with the change.
+
+ Wait for the update to complete. Don’t try to restart VMs until after the network change is complete.
+
+ If you stopped any VMs in step 2, restart them.
+
+ In addition to the username and password authentication, CloudStack supports using SSH keys to log in to the cloud infrastructure for additional security. You can use the createSSHKeyPair API to generate the SSH keys.
+
+ Because each cloud user has their own SSH key, one cloud user cannot log in to another cloud user's instances unless they share their SSH key files. Using a single SSH key pair, you can manage multiple instances.
+
5.2.1. Creating an Instance Template that Supports SSH Keys
+ Create a instance template that supports SSH Keys.
+
+ Create a new instance by using the template provided by cloudstack.
+
+ For more information on creating a new instance, see
+
+ Download the cloudstack script from The SSH Key Gen Scriptto the instance you have created.
+
+ Run the script while starting up the operating system:
+
chkconfig --add cloud-set-guest-sshkey.in
+ Stop the instance.
+
5.2.2. Creating the SSH Keypair
+ You must make a call to the createSSHKeyPair api method. You can either use the CloudStack Python API library or the curl commands to make the call to the cloudstack api.
+
+ For example, make a call from the cloudstack server to create a SSH keypair called "keypair-doc" for the admin account in the root domain:
+
Note
+ Ensure that you adjust these values to meet your needs. If you are making the API call from a different server, your URL/PORT will be different, and you will need to use the API keys.
+
+ Apache CloudStack 4.0.0-incubating includes the following new features:
+
3.1.1. Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You can provision VLANs to the tiers your create, and VMs can be deployed on different tiers, such as Web, Application, or Database. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+
3.1.2. Site-to-Site VPN
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+
+ Cisco ISR with IOS 12.4 or later
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
3.1.3. Local Storage Support for Data Volumes
+ You can now create data volumes on local storage. The data volume is placed on the same XenServer host as the VM instance that is attached to the data volume. These local data volumes can be attached to virtual machines, detached, re-attached, and deleted just as with the other types of data volume. In earlier releases of CloudStack, only the root disk could be placed in local storage.
+
+ Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some of the benefits include reduced disk I/O latency and cost reduction from using inexpensive local disks.
+
+ In order for local volumes to be used, the feature must be enabled for the zone.
+
+ You can create a data disk offering for local storage. When a user creates a new VM, they can select this disk offering in order to cause the data disk volume to be placed in local storage.
+
+ You can not migrate a VM that has a volume in local storage to a different host, nor migrate the volume itself away to a different host. If you want to put a host into maintenance mode, you must first stop any VMs with local data volumes on that host.
+
+ Local storage support for volumes is available for XenServer, KVM, and VMware hypervisors.
+
3.1.4. Tags
+ 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 new 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.
+
+ A new optional input parameter, "tags," has been added to 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:
+
+ The following API commands have the new "tags" input parameter:
+
+ listVirtualMachines
+
+ listVolumes
+
+ listSnapshots
+
+ listNetworks
+
+ listTemplates
+
+ listIsos
+
+ listFirewallRules
+
+ listPortForwardingRules
+
+ listPublicIpAddresses
+
+ listSecurityGroups
+
+ listLoadBalancerRules
+
+ listProjects
+
+ listVPCs
+
+ listNetworkACLs
+
+ listStaticRoutes
+
3.1.5. AWS API Changes for Tags
+ Some changes have been made to the Amazon Web Services API compatibility support in order to accommodate the new tagging feature.
+
+ New APIs:
+
+
+ New API
+
+
+
+
+ Description
+
+
+
+
+ ec2-create-tags
+
+
+
+
+ Add tags to one or more resources.
+
+
+
+
+ ec2-delete-tags
+
+
+
+
+ Remove tags from one or more resources.
+
+
+
+ ec2-describe-tags
+
+
+ Show currently defined tags.
+
+
+
+ Changed APIs:
+
+
+ Changed API
+
+
+
+
+ Description
+
+
+
+ ec2-describe-images
+
+
+ Output now shows tags defined for each image.
+
+
+
+
+ ec2-describe-instances
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+ ec2-describe-snapshots
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+ ec2-describe-volumes
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
3.1.6. Secure Console Access on XenServer
+ With the addition of Secure Console feature, users can now securely access the VM consoles on the XenServer hypervisor. You can either SSH or use the View Console option in the Management Server to securely connect to the VMs on the XenServer host. The Management Server uses the xapi API to stream the VM consoles. However, there is no change in the way you can access the console of a VM. This feature is supported on XenServer 5.6 and 6.0 versions.
+
3.1.7. Stopped VM
+ This release supports creating VMs without starting them on the backend. You can determine whether the VM needs to be started as part of the VM deployment. A VM can be deployed in two ways: create and start a VM (the default method); create a VM and leave it in the stopped state.
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. The possible values are:
+
+ true - The VM starts as a part of the VM deployment
+
+ false - The VM is left in stopped state at the end of the VM deployment
+
3.1.8. Uploading an Existing Volume to a Virtual Machine
+ Existing data can now be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs. The upload is performed by using HTTP. The uploaded volume is placed in the zone's secondary storage.
+
+ This functionality is supported for the following hypervisors:
+
+ Hypervisor : Disk Image Format
+
+ XenServer : VHD
+
+ VMware : OVA
+
+ KVM : QCOW2
+
3.1.9. Dedicated High-Availability Hosts
+ One or more hosts can now be designated for use only by high-availability (HA) enabled VMs that are restarted due to a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HA-enabled VMs make it easier to determine which VMs are restarted as part of the high-availability function. You can designate a host as a dedicated-HA restart node only if the Dedicated HA Hosts feature is enabled by setting the appropriate global configuration parameter.
+
3.1.10. Support for Amazon Web Services API
+ This release supports Amazon Web Services APIs, including Elastic Compute Cloud (EC2) API. Fidelity with the EC2 API and the installation experience for this functionality are both enhanced. In prior releases, users were required to install a separate component called CloudBridge, in addition to installing the Management Server. For new installations of CloudStack 4.0.0-incubating, this software is installed automatically along with CloudStack and runs in a more closely integrated fashion. The feature is disabled by default, but can be easily enabled by setting the appropriate global configuration parameter and performing a few setup steps.
+
3.1.11. The Nicira NVP Plugin
+ The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating this plug-in supports the Connectivity service. This service is responsible for creating Layer 2 networks supporting the networks created by guests. When a tenant creates a new network, instead of a traditional VLAN, a logical network will be created by sending the appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira NVP versions 2.1.0, 2.2.0 and 2.2.1.
+
3.1.12. Support for CAStor Cluster
+ CloudStack 4.0.0-incubating supports using a CAStor cluster as the back-end storage system for a CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends the existing storage classes and allows the storage configuration attribute to point to a CAStor cluster. This feature makes use of the CloudStack server's local disk to spool files before writing them to CAStor when handling the PUT operations. However, a file must be successfully written into the CAStor cluster prior to the return of a success code to the S3 client to ensure that the transaction outcome is correctly reported.
+
+ The S3 multipart file upload is not supported in this release. You are prompted with proper error message if a multipart upload is attempted.
+
3.1.13. Clustered Logical Volume Manager Support for KVM
+ This release adds Clustered Logical Volume Manager (CLVM) storage support for KVM hosts. With this support, you can use CLVM as primary storage.
+
+ The CLVM support for KVM allows root and data disks (primary storage) to reside on Linux logical volumes. The administrators are required to configure CLVM on the KVM hosts independent of CloudStack. When the volume groups are available, an administrator can simply add primary storage of type CLVM, providing the volume group name. Then CloudStack creates and manages logical volumes as needed.
+
+ CLVM also supports Snapshots. CloudStack creates an LVM snapshot, copy the applicable logical volume to the secondary storage in the qcow2 format, and then delete the LVM snapshot.
+
3.1.14. Rados Block Device Support for KVM
+ You can now use Rados Block Device (RBD) to run instances on Apache CloudStack 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least 0.10 with RBD enabled on the KVM host
+
+ Create a disk offering for RBD so that you can ensure that StoragePoolAllocator chooses the RBD pool to deploy instances.
+
3.2. Issues Fixed in 4.0.0-incubating
+ Many bugs include a defect number that reflects the bug number that was held in the bug tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira to manage its bugs, so some of the bugs that are referenced here may not be available to view. However, we are still including them for completeness.
+
+
+ Defect
+
+
+
+
+ Description
+
+
+
+
+ Many
+
+
+
+ vSphere 5.0 now has GA support. Formerly only Beta support was provided.
+
+
+
+ CS-16135
+
+
+
+ Creating volumes after upgrading from snapshot taken in 2.2.14 no longer deletes the snapshot physically from the secondary storage.
+
+
+
+ CS-16122
+
+
+
+ In a site-to-site VPN setup, alerts are generated when the VPC virtual router is rebooted with multiple vpn connections.
+
+
+
+ CS-16022
+
+
+
+ If host connection fails due to a database error, host now disconnects and the Managerment Server id is removed.
+
+
+
+ CS-16011
+
+
+
+ Name of network offering is no longer truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+ CS-15978
+
+
+
+ When the virtual router and its host go down, the high availability mechanism now works for the virtual router.
+
+
+
+
+ CS-15921
+
+
+
+ The 2.2.x security group script now accounts for the VMs created in the version 2.1 timeframe.
+
+
+
+
+ CS-15919
+
+
+
+ A level parameter is added to the listVolumes command; therefore queries return the response more quickly.
+
+
+
+ CS-15904
+
+
+
+ Upgrade from version 2.2.14 to CloudStack-3.0.5-0.2944-rhel5 works as expected. The upgrade script, /usr/share/cloud/setup/db/schema-2214to30-cleanup.sql, works as expected.
+
+
+
+ CS-15879
+
+
+
+ The database upgrade from version 3.0.4 to 3.0.5 works as expected.
+
+
+
+
+ CS-15807
+
+
+
+ Network label for OVM now available in UI.
+
+
+
+
+ CS-15779
+
+
+
+ When the thumbnail is requested, the console session will not be terminated.
+
+
+
+
+ CS-15778
+
+
+
+ Fetching a VM thumbnail now gets a thumbnail of appropriate visual dimensions.
+
+
+
+
+ CS-15734
+
+
+
+ KVM Snapshots no longer shows incorrect disk usage.
+
+
+
+ CS-15733
+
+
+
+ The domainId parameter for the listNetworks command now lists the resources belonging to the domain specified.
+
+
+
+ CS-15676
+
+
+
+ Stopping the router no longer fails with the null pointer exception.
+
+
+
+
+ CS-15648
+
+
+
+ If creating a volume from a snapshot fails, the error is reported on the UI but the volume is stuck in the creating state.
+
+
+
+
+ CS-15646
+
+
+
+ createFirewallRule API no longer causes null pointer exception.
+
+
+
+ CS-15628
+
+
+
+ In a KVM host, the high availability mechanism no longer takes a long time to migrate VMs to another KVM host if there are multiple storage pools.
+
+
+
+ CS-15627
+
+
+
+ Metadata instance-id and vm-id for existing VMs stays the same after upgrade.
+
+
+
+ CS-15621
+
+
+
+ Solved difficulty with allocating disk volumes when running multiple VM deployment in parallel.
+
+
+
+ CS-15603
+
+
+
+ CloudStack now stop the VMs when destroyVM command is called.
+
+
+
+ CS-15586
+
+
+
+ Public Vlan for an account no longer fails if multiple physical networks are present.
+
+
+
+ CS-15582
+
+
+
+ The dns-name filter is now supported for ec2-describe-instances in the Amazon Web Services API compatibility commands. The filter maps to the name of a user VM.
+
+
+
+ CS-15503
+
+
+
+ An IP address which has static NAT rules can now be released. Subsequently, restarting this network after it was shutdown can succeed.
+
+
+
+ CS-15464
+
+
+
+ Can now delete static route whose state is set to Revoke.
+
+
+
+ CS-15443
+
+
+
+ Creating a firewall rule no longer fails with an internal server error.
+
+
+
+ CS-15398
+
+
+
+ Corrected technique for programming DNS on the user VMs.
+
+
+
+ CS-15356
+
+
+
+ Internal DNS 2 entry now correctly shown in UI.
+
+
+
+ CS-15335
+
+
+
+ The CloudBridge S3 Engine now connects to the database by using the deciphered password in the db.properties file.
+
+
+
+ CS-15318
+
+
+
+ UI now correctly prevents the user from stopping a VM that is in the Starting state.
+
+
+
+ CS-15307
+
+
+
+ Fixed Japanese localization of instance statuses in the Instances menu.
+
+
+
+ CS-15278
+
+
+
+ The deployment planner no longer takes long time to locate a suitable host to deploy VMs when large number of clusters are present.
+
+
+
+ CS-15274
+
+
+
+ Creating a VLAN range using Zone ID without network ID now succeeds.
+
+
+
+ CS-15243
+
+
+
+ Now check to be sure source NAT and VPN have same provider.
+
+
+
+ CS-15232
+
+
+
+ Ensure that networks using external load balancer/firewall in 2.2.14 or earlier can properly upgrade.
+
+
+
+ CS-15200
+
+
+
+ No exception when trying to attach the same volume while attaching the first volume is in progress.
+
+
+
+ CS-15173
+
+
+
+ Additional cluster can no longer be added with same VSM IP address as another cluster.
+
+
+
+ CS-15167
+
+
+
+ AWS API calls now honor the admin account's ability to view or act on the resources owned by the regular users.
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+ CS-15157
+
+
+
+ Can now add/enable service providers for multiple physical networks through the UI.
+
+
+
+ CS-15145
+
+
+
+ AWS API call ec2-register has better error handling for negative cases.
+
+
+
+ CS-15122
+
+
+
+ Filters now supported for AWS API call ec2-describe-availability-zones.
+
+
+
+ CS-15120
+
+
+
+ Actions column in UI of Volume page now shows action links.
+
+
+
+ CS-15099
+
+
+
+ Buttons no longer overlap text on Account Deletion confirmation page in UI.
+
+
+
+ CS-15095
+
+
+
+ Ensures you can not create a VM with a CPU frequency greater than the host CPU frequency.
+
+
+
+ CS-15094
+
+
+
+ CPU cap now set properly in VMware.
+
+
+
+ CS-15077
+
+
+
+ NullPointerException is no longer observed while executing the command to list the public IP in a basic zone created with the default shared NetScaler EIP and ELB network offering.
+
+
+
+ CS-15044
+
+
+
+ UI now provides option to view the list of instances which are part of the guest network.
+
+
+
+ CS-15026
+
+
+
+ UI in Deploy VM dialog now lists only templates or ISOs depending on which is selected in previous dialog.
+
+
+
+ CS-14989
+
+
+
+ In KVM, the Create Instance wizard now shows only templates from the current (KVM) zone.
+
+
+
+ CS-14986, CS-14985
+
+
+
+ Listing filters works as expected in the ec2-describe-volumes and ec2-describe-snapshots commands.
+
+
+
+ CS-14964
+
+
+
+ Automatically starting the Console Proxy no longer fails due to its missing volume on the primary storage
+
+
+
+ CS-14907
+
+
+
+ User is now correctly prevented from trying to download an uploaded volume which has not yet been moved to primary storage.
+
+
+
+ CS-14879
+
+
+
+ When a user VM is stopped or terminated, the static NAT associated with this VM is now disabled. This public IP address is no longer owned by this account and can be associated to any other user VM.
+
+
+
+ CS-14854
+
+
+
+ Only the admin user can change the template permission to Public, so this option is removed from the UI for domain Admins and regular Users.
+
+
+
+ CS-14817
+
+
+
+ While checking if network has any external provider, CloudStack will consider all providers in the network.
+
+
+
+ CS-14796
+
+
+
+ When deploying a VM with ec2-run-instances, userdata is now encoded.
+
+
+
+ CS-14770
+
+
+
+ The API returns the keypair information when a VM is deployed with sshkey. This affects the API commands related to virtual machines (deployVirtualMachine, listVirtualMachines, ... *VirtualMachine), as well as the corresponding AWS APIs.
+
+
+
+ CS-14724
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+ CS-14345
+
+
+
+ Logout API returns XML header.
+
+
+
+ CS-14724
+
+
+
+ Host IPs now associated with appropriate IPs according to traffic type.
+
+
+
+ CS-14253
+
+
+
+ Can now delete and re-create port forwarding rule on same firewall.
+
+
+
+ CS-14724
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+ CS-14452
+
+
+
+ Data disk volumes are now automatically copied from one cluster to another.
+
+
+
+ CS-13539
+
+
+
+ Windows VM can get IP after reboot.
+
+
+
+ CS-13537
+
+
+
+ When user tries to delete a domain that contains sub-domains, an error message is now sent to convey the reason for the delete failure.
+
+
+
+ CS-13153
+
+
+
+ System VMs support HTTP proxy.
+
+
+
+ CS-12642
+
+
+
+ Added Close button to Select Project list view popup in UI.
+
+
+
+ CS-12510
+
+
+
+ Deleting and reinserting host_details no longer causes deadlocks.
+
+
+
+ CS-12407
+
+
+
+ F5 and Netscaler - when dedicated is selected, capacity field is disabled.
+
+
+
+ CS-12111
+
+
+
+ Email validation for edit user form.
+
+
+
+ CS-10928
+
+
+
+ Network read/write values now always positive numbers.
+
+
+
+ CS-15376, CS-15373
+
+
+
+ The AWS APIs (EC2 and S3) now listen on the 7080 port and send request to CloudStack on the 8080 port just as any other clients of CloudStack.
+
+
+
+ CS-13944
+
+
+
+ The CloudStack 2.2.x to 3.0.x database upgrade for multiple physical networks is now supported.
+
+
+
+ CS-15300
+
+
+
+ The admin accounts of a domain now honour the limits imposed on that domain just like the regular accounts do. A domain admin now is not allowed to create an unlimited number of instances, volumes, snapshots, and so on.
+
+
+
+ CS-15396
+
+
+
+ The CloudStack database now contain the UUD information after the 2.2.14 to 3.0.4 upgrade.
+
+
+
+ CS-15450
+
+
+
+ Upgrade from 2.2.14 to 3.0.4 no longer fails on a VMware host.
+
+
+
+ CS-15449
+
+
+
+ Running cloudstack-aws-api-register no longer fails with the "User registration failed with error: [Errno 113] No route to host" error.
+
+
+
+ CS-15455
+
+
+
+ The iptable rules are configured to open the awsapi port (7080) as part of the installation.
+
+
+
+ CS-15429
+
+
+
+ While creating an instance with data volume, disk offering also is considered while checking the account limit on volume resources.
+
+
+
+ CS-15414
+
+
+
+ After the 2.2.14 to 3.0.4 upgrade, the value of the global parameter xen.guest.network.device is now decrypted before setting the traffic label.
+
+
+
+ CS-15382
+
+
+
+ During 2.2.14 to 3.0.4 upgrade, the hosts no longer go to the Alert state if destroyed networks existed with non-existent tags prior to upgrade.
+
+
+
+ CS-15323
+
+
+
+ CloudStack supports the following Citrix XenServer hotfixes: XS602E003, XS602E004, and XS602E005.
+
+
+
+ CS-15430
+
+
+
+ Create snapshot now fails if creating a snapshot exceeds the snapshot resource limit for a domain admin or a user account.
+
+
+
+ CS-14256
+
+
+
+ Virtual Router no longer remains in starting state for subdomain or user on a KVM 3.0.1 prerlease host on RHEL 6.2.
+
+
+
+ CS-7495
+
+
+
+ Implemented a variety of Xen management host improvements.
+
+
+
+ CS-8105
+
+
+
+ NFS v4 for primary storage now works as expected on KVM hosts.
+
+
+
+ CS-9989
+
+
+
+ The error messages returned during VM deployment failure will have much more details than before.
+
+
+
+ CS-12584
+
+
+
+ You can no longer add security groups not supported by the hypervisor in use.
+
+
+
+ CS-12705
+
+
+
+ When creating a Network offering by using SRX as the service provider for SourceNAT servcies, an option is given in the CloudStack UI now to set the source_nat type to "per Zone"/"per account".
+
+
+
+ CS-12782
+
+
+
+ Assigning a VM from Basic to Advanced zone no longer ignores the network ID. A warning message is displayed for VM movements across zones.
+
+
+
+ CS-12591
+
+
+
+ Broadcast Address on the Second Public IP NIC is now corrected.
+
+
+
+ CS-13272
+
+
+
+ When a user is deleted, all the associated properties, such as IPs and virtual routers, are now deleted.
+
+
+
+ CS-13377
+
+
+
+ Creating template from a root disk of a stopped instance now provides an option to make it a "Featured template".
+
+
+
+ CS-13500
+
+
+
+ Reaching the first guest VM by using its public IP from the second guest VM no longer fails.
+
+
+
+ CS-13853
+
+
+
+ The default gateway can no longer be 0.0.0.0 in the Secondary Storage VM (SSVM).
+
+
+
+ CS-13863
+
+
+
+ The queryAsyncJobResult command in XML format now returns the correct UUIDs.
+
+
+
+ CS-13867
+
+
+
+ Corrected CSP xenserver-cloud-supp.tgz for XenServer 5.6 and 6.0.
+
+
+
+ CS-13904
+
+
+
+ Labels and values for the service offerings CPU and memory are now consistent.
+
+
+
+ CS-13998
+
+
+
+ The SSVM kernel panic issue is fixed on XenServer.
+
+
+
+ CS-14090
+
+
+
+ The issue is fixed where running the VMware snapshots randomly fails with the ArrayIndexOutOfBoundsException error.
+
+
+
+ CS-14021
+
+
+
+ The java.lang.OutOfMemoryError is fixed on the Management Server.
+
+
+
+ CS-14025
+
+
+
+ The Python Eggs are provided to easily package the test client for each branch of CloudStack.
+
+
+
+ CS-14068
+
+
+
+ Resetting the VM password through the CloudStack UI no longer causes any error.
+
+
+
+ CS-14156
+
+
+
+ The pod which has the administrator's virtual router is no longer selected while creating the virtual routers for guests.
+
+
+
+ CS-14182
+
+
+
+ The users can now delete their ISOs as normal users.
+
+
+
+ CS-14185
+
+
+
+ The listOSTypes API now filters out the types of operating system by using the keywords.
+
+
+
+ CS-14204
+
+
+
+ The cloud-setup-bonding.sh command no longer generates the "command not found" error.
+
+
+
+ CS-14214
+
+
+
+ The Specify VLAN option cannot be enabled now for an isolated Network offering with SourceNAT enabled.
+
+
+
+ CS-14234
+
+
+
+ Sending project invite email to an account now requires SMTP configured in CloudStack.
+
+
+
+ CS-14237
+
+
+
+ The garbage collector of the primary storage no longer fails when the first host in the cluster is not up.
+
+
+
+ CS-14241
+
+
+
+ Custom Volume Disk Offering is now matching the Global configuration value.
+
+
+
+ CS-14270
+
+
+
+ The listNetworks API no longer assumes that the broadcast type is always VLAN.
+
+
+
+ CS-14319
+
+
+
+ The internal name of the VM is no longer present in the error message that is displayed to a domain administrator.
+
+
+
+ CS-14321
+
+
+
+ The listVolumes API call now returns a valid value for the isExtractable parameter for the ISO-derived disk and data disk volumes.
+
+
+
+ CS-14323
+
+
+
+ Invalid API calls will now give valid response in json/xml format.
+
+
+
+ CS-14339
+
+
+
+ Custom Disk Size will now allow values larger than 100GB.
+
+
+
+ CS-14357
+
+
+
+ The ConsoleProxyLoadReportCommand is no longer fired continuously.
+
+
+
+ CS-14421
+
+
+
+ Fixed the issue of virtual router deployments. The DHCP entries can now be assigned to the router.
+
+
+
+ CS-14555
+
+
+
+ Unzipped downloaded template MD5SUM will no longer override the zipped template MD5SUM in the database.
+
+
+
+ CS-14598
+
+
+
+ The complete screen of the running VM is now displayed in the console proxy.
+
+
+
+ CS-14600
+
+
+
+ Windows or Linux based consoles are no longer lost upon rebooting VMs.
+
+
+
+ CS-14784
+
+
+
+ Multiple subnets with the same VLAN now work as expected.
+
+
+
+ CS-13303, 14874, 13897, 13944, 14088, 14190
+
+
+
+ A variety of upgrade issues have been fixed in release 3.0.3.
+
+
+
+ CS-15080
+
+
+
+ Setting a private network on a VLAN for VMWare environment is now supported.
+
+
+
+ CS-15168
+
+
+
+ The console proxy now works as expected and no exception is shown in the log after upgrading from version 2.2.14 to 3.0.2.
+
+
+
+ CS-15172
+
+
+
+ Version 3.0.2 now accepts the valid public key.
+
+
3.3. Known Issues in 4.0.0-incubating
+
+ Issue ID
+
+
+
+
+ Description
+
+
+
+
+ CLOUDSTACK-301
+
+
+
+ Nexus 1000v DVS integration is not functional
+
+
+ This source code release includes some partial functionality to support the Cisco Nexus 1000v Distributed Virtual Switch within a VMware hypervisor environment. The functionality is not complete at this time.
+
+
+
+
+ CLOUDSTACK-368
+
+
+
+ OVM - cannot create guest VM
+
+
+ This source code release has regressed from the CloudStack 2.2.x code and is unable to support Oracle VM (OVM).
+
+
+
+
+ CLOUDSTACK-279
+
+
+
+ Deleting a project fails when executed by the regular user. This works as expected for root/domain admin. To workaround, perform either of the following:
+
+
+ Use the account cleanup thread which will eventually complete the project deletion.
+
+ Execute the call as the root/domain admin on behalf of the regular user.
+
+
+
+
+ CS-16067
+
+
+
+ The command=listTags&key=city command does not work as expected. The command does not return tags for the resources of the account with the tag, city
+
+
+
+
+ CS-16063
+
+
+
+ The current values of volumes and snapshots are incorrect when using KVM as a host. To fix this, the database upgrade codes, volumes.size and snapshots.size, should be changed to show the virtual sizes.
+
+
+
+
+ CS-16058
+
+
+
+ Null pointer Exception while deleting the host after moving the host to maintenance state.
+
+
+
+
+ CS-16045
+
+
+
+ Only the root administrator can handle the API keys. The domain administrators are not allowed to create, delete, or retrieve API keys for the users in their domain.
+
+
+
+
+ CS-16019
+
+
+
+ CIDR list in the Add VPN Customer Gateway dialog does not prompt the user that they can provide a comma separated CIDRs if multiple CIDRs have to be supplied.
+
+
+
+
+ CS-16015
+
+
+
+ Deleting a network is not supported when its network providers are disabled.
+
+
+
+
+ CS-16012
+
+
+
+ Unable to delete a zone in the UI because the necessary cleanup cannot be completed. When the hosts are removed, the expunge process fails to delete the volumes as no hosts are present to send the commands to. Therefore, the storage pool removal fails, and zone can't be cleaned and deleted.
+
+
+
+
+ CS-16011
+
+
+
+ Name of network offering might be truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+ CS-15789
+
+
+
+ Invalid global setting prevents management server to restart. For example, if you configure the "project.invite.timeout" parameter to "300" and attempt to restart management server, it fails without throwing a warning or setting the value to the default.
+
+
+
+
+ CS-15749
+
+
+
+ Restarting VPC is resulting in intermittent connection loss to the port forwarding and StaticNAT rules.
+
+
+
+
+ CS-15690
+
+
+
+ The IpAssoc command failed as a part of starting the virtual router, but the final start result is reported as succes.
+
+
+
+
+ CS-15672, CS-15635
+
+
+
+ The FQDN of the VM is not configured if it is deployed as a part of default shared network and isolated guest network (DefaultIsolatedNetworkOfferingWithSourceNatService).
+
+
+
+
+ CS-15634
+
+
+
+ The FQDN of a VM that is deployed as a part of both a shared network and default isolated guest network has the suffix of the shared network instead of the default isolated guest network.
+
+
+
+
+ CS-15576
+
+
+
+ Stopping a VM on XenServer creates a backlog of API commands. For example, the Attach volume calls become delayed while waiting for the stopVirtualMachine command to be executed.
+
+
+
+
+ CS-15569
+
+
+
+ Misleading error message in the exception when creating a StaticNAT rule fails in a VPC.
+
+
+
+
+ CS-15566
+
+
+
+ External device such as Netscaler is not supported in VPC.
+
+
+
+ CS-15557
+
+
+
+ Intermittent traffic loss in the VPN connection if Juniper is the remote router and the life time is 300 seconds.
+
+
+
+
+ CS-15361
+
+
+
+ Egress rules are not working in NetScaler loadbalancer.
+
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+ CS-15105
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+ CS-15092
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+ CS-15037
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+ CS-15009
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+ CS-14939
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+ CS-14780
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+ CS-14756
+
+
+
+ Installing KVM on RHEL 6.2 will result in unreliable network performance. Workaround: blacklist vhost-net. Edit /etc/modprobe.d/blacklist-kvm.conf and include vhost-net.
+
+
+
+ CS-14346
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+ CS-14303 (was 14537)
+
+
+
+ The IP addresses for a shared network are still being consumed even if no services are defined for that network.
+
+
+
+ CS-14296 (was 14530)
+
+
+
+ OVM: Network traffic labels are not supported.
+
+
+
+ CS-14291 (was 14523)
+
+
+
+ The EIP/ELB network offering for basic zones does not support multiple NetScalers.
+
+
+
+ CS-14275 (was 14506)
+
+
+
+ F5: Unable to properly remove a F5 device.
+
+
+
+ CS-14201 (was 14430)
+
+
+
+ VMWare: Template sizes are being reported different depending on whether the primary storage is using ISCSI or NFS.
+
+
+
+ CS-13758 (was 13963)
+
+
+
+ vSphere: template download from templates created off of the root volume does not work properly.
+
+
+
+ CS-13733 (was 13935)
+
+
+
+ vSphere: detaching an ISO from a restored VM instance fails.
+
+
+
+ CS-13682 (was 13883)
+
+
+
+ Multiple NetScalers are not supported in Basic Networking.
+
+
+
+ CS-13599 (was 13359)
+
+
+
+ Programming F5/NetScaler rules can be better optimized.
+
+
+
+ CS-13337 (was 13518)
+
+
+
+ Security Groups are not supported in Advanced Networking
+
+
+
+ CS-13173 (was 13336)
+
+
+
+ vSphere: cross cluster volume migration does not work properly.
+
+
+
+ CS-12714 (was 12840)
+
+
+
+ Capacity view is not available for pods or clusters.
+
+
+
+ CS-12624 (was 12741)
+
+
+
+ vSphere: maintenance mode will not live migrate system VM to another host.
+
+
+
+ CS-15476
+
+
+
+
+ The 2.2.14 to 4.0.0-incubating upgrade fails if multiple untagged physical networks exist before the upgrade.
+
+
+
+
+ CS-15407
+
+
+
+
+ After the 2.2.14 to 4.0.0-incubating upgrade, VLAN allocation on multiple physical networks does not happen as expected.
+
+
+ To workaround this issue, follow the instructions given below:
+
+
+ Revert to your 2.2.14 setup.
+
+ Stop all the VMs with the isolated virtual networks in your cloud setup.
+
+ Run following query to find if any networks still have the NICs allocated:
+
+ Check if any virtual guest networks have the NICs allocated:
+
#SELECT DISTINCT op.id from `cloud`.`op_networks` op JOIN `cloud`.`networks` n on op.id=n.id WHERE nics_count != 0 AND guest_type = 'Virtual';
+ If this returns any network IDs, then ensure the following:
+
+ All the VMs are stopped.
+
+ No new VM is started.
+
+ Shutdown the Management Server.
+
+ Remove the NICs count for the virtual network IDs returned in step (a), and set the NIC count to 0:
+
UPDATE `cloud`.`op_networks` SET nics_count = 0 WHERE id = enter id of virtual network
+ Restart the Management Server, and wait for all the networks to shut down.
+
Note
+ Networks shutdown is determined by the network.gc.interval and network.gc.wait parameters.
+
+ Ensure that all the networks are shut down and all the guest VNETs are free.
+
+ Run the upgrade script.
+
+ This allocates all your guest VNET ranges to the first physical network.
+
+ By using the updatePhysicalNetwork API, reconfigure the VNET ranges for each physical network as desired.
+
+ Start all the VMs.
+
+
+
+
+ CS-14680
+
+
+
+
+ CloudStack and LDAP user validation cannot happen simultaneously because the user password is hashed and stored in the database, and LDAP requires the passwords in plain text.
+
+
+ To work with the LDAP user, the MD5 hash should be disabled in the login process by commenting the following variable in sharedFunctions.js file available at /usr/share/cloud/management/webapps/client/scripts, and restart the cloud-management service.
+
+
+
var md5HashedLogin = false;
+
+ However, if md5HashedLogin is set to false, the end user can login with the LDAP credentials but not with the CloudStack user credentials.
+
+
+
+
+ CS-14346
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+ CS-15130
+
+
+
+ Data disk volumes are not automatically copied from one cluster to another.
+
+
+
+ CS-14780
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+ CS-14939
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+ CS-15009
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+ CS-15037
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+ CS-15092
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+ CS-15105
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+ The virtual router is a type of System Virtual Machine. The virtual router is one of the most frequently used service providers in CloudStack. The end user has no direct access to the virtual router. Users can ping the virtual router and take actions that affect it (such as setting up port forwarding), but users do not have SSH access into the virtual router.
+
+ There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be restarted by administrators, but this will interrupt public network access and other services for end users. A basic test in debugging networking issues is to attempt to ping the virtual router from a guest VM. Some of the characteristics of the virtual router are determined by its associated system service offering.
+
+ 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.
+
+ Virtual machines can be in the following states:
+
+ Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual machine will be reclaimed by the system. This includes the virtual machine’s IP address.
+
+ A stop will attempt to gracefully shut down the operating system, which typically involves terminating all the running applications. If the operation system cannot be stopped, it will be forcefully terminated. This has the same effect as pulling the power cord to a physical machine.
+
+ A reboot is a stop followed by a start.
+
+ CloudPlatform preserves the state of the virtual machine hard disk until the machine is destroyed.
+
+ A running virtual machine may fail because of hardware or network issues. A failed virtual machine is in the down state.
+
+ The system places the virtual machine into the down state if it does not receive the heartbeat from the hypervisor for three minutes.
+
+ The user can manually restart the virtual machine from the down state.
+
+ The system will start the virtual machine from the down state automatically if the virtual machine is marked as HA-enabled.
+
8.3. VMware vSphere Installation and Configuration
+ If you want to use the VMware vSphere hypervisor to run guest virtual machines, install vSphere on the host(s) in your cloud.
+
8.3.1. System Requirements for vSphere Hosts
8.3.1.1. Software requirements:
+ vSphere and vCenter, both version 4.1 or 5.0.
+
+ vSphere Standard is recommended. Note however that customers need to consider the CPU constraints in place with vSphere licensing. See http://www.vmware.com/files/pdf/vsphere_pricing.pdf and discuss with your VMware sales representative.
+
+ vCenter Server Standard is recommended.
+
+ 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.
+
Apply All Necessary Hotfixes
+ The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled).
+
+ All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ Hardware virtualization support required
+
+ 4 GB of memory
+
+ 36 GB of local disk
+
+ At least 1 NIC
+
+ Statically allocated IP Address
+
8.3.1.3. vCenter Server requirements:
+ Processor - 2 CPUs 2.0GHz or higher Intel or AMD x86 processors. Processor requirements may be higher if the database runs on the same machine.
+
+ Memory - 3GB RAM. RAM requirements may be higher if your database runs on the same machine.
+
+ Disk storage - 2GB. Disk requirements may be higher if your database runs on the same machine.
+
+ Microsoft SQL Server 2005 Express disk requirements. The bundled database requires up to 2GB free disk space to decompress the installation archive.
+
+ VMware vCenter Standard Edition 4.1 or 5.0 must be installed and available to manage the vSphere hosts.
+
+ vCenter must be configured to use the standard port 443 so that it can communicate with the CloudStack Management Server.
+
+ You must re-install VMware ESXi if you are going to re-use a host from a previous install.
+
+ CloudStack requires VMware vSphere 4.1 or 5.0. VMware vSphere 4.0 is not supported.
+
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled). All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+
+ The CloudStack management network must not be configured as a separate virtual network. The CloudStack management network is the same as the vCenter management network, and will inherit its configuration. See Section 8.3.5.2, “Configure vCenter Management Network”.
+
+ CloudStack requires ESXi. ESX is not supported.
+
+ All resources used for CloudStack must be used for CloudStack only. CloudStack cannot share instance of ESXi or storage with other management consoles. Do not share the same storage volumes that will be used by CloudStack with a different set of ESXi servers that are not managed by CloudStack.
+
+ Put all target ESXi hypervisors in a cluster in a separate Datacenter in vCenter.
+
+ The cluster that will be managed by CloudStack should not contain any VMs. Do not run the management server, vCenter or any other VMs on the cluster that is designated for CloudStack use. Create a separate cluster for use of CloudStack and make sure that they are no VMs in this cluster.
+
+ All the required VLANS must be trunked into all network switches that are connected to the ESXi hypervisor hosts. These would include the VLANS for Management, Storage, vMotion, and guest VLANs. The guest VLAN (used in Advanced Networking; see Network Setup) is a contiguous range of VLANs that will be managed by CloudStack.
+
8.3.2. Preparation Checklist for VMware
+ For a smoother installation, gather the following information before you start:
+
+ You will need the following information about vCenter.
+
+
+ vCenter Requirement
+
+
+
+ Value
+
+
+
+ Notes
+
+
+
+ vCenter User
+
+
+
+
+
+
+ This user must have admin privileges.
+
+
+
+ vCenter User Password
+
+
+
+
+
+
+ Password for the above user.
+
+
+
+ vCenter Datacenter Name
+
+
+
+
+
+
+ Name of the datacenter.
+
+
+
+ vCenter Cluster Name
+
+
+
+
+
+
+ Name of the cluster.
+
+
8.3.2.2. Networking Checklist for VMware
+ You will need the following information about VLAN.
+
+
+ VLAN Information
+
+
+
+ Value
+
+
+
+ Notes
+
+
+
+ ESXi VLAN
+
+
+
+
+
+
+ VLAN on which all your ESXi hypervisors reside.
+
+
+
+ ESXI VLAN IP Address
+
+
+
+
+
+
+ IP Address Range in the ESXi VLAN. One address per Virtual Router is used from this range.
+
+
+
+ ESXi VLAN IP Gateway
+
+
+
+
+
+
+
+
+
+ ESXi VLAN Netmask
+
+
+
+
+
+
+
+
+
+ Management Server VLAN
+
+
+
+
+
+
+ VLAN on which the CloudStack Management server is installed.
+
+
+
+ Public VLAN
+
+
+
+
+
+
+ VLAN for the Public Network.
+
+
+
+ Public VLAN Gateway
+
+
+
+
+
+
+
+
+
+ Public VLAN Netmask
+
+
+
+
+
+
+
+
+
+ Public VLAN IP Address Range
+
+
+
+
+
+
+ Range of Public IP Addresses available for CloudStack use. These addresses will be used for virtual router on CloudStack to route private traffic to external networks.
+
+
+
+ VLAN Range for Customer use
+
+
+
+
+
+
+ A contiguous range of non-routable VLANs. One VLAN will be assigned for each customer.
+
+ Following installation, perform the following configuration, which are described in the next few sections:
+
+
+ Required
+
+
+
+ Optional
+
+
+
+ ESXi host setup
+
+
+
+ NIC bonding
+
+
+
+ Configure host physical networking, virtual switch, vCenter Management Network, and extended port range
+
+
+
+ Multipath storage
+
+
+
+ Prepare storage for iSCSI
+
+
+
+
+
+
+ Configure clusters in vCenter and add hosts to them, or add hosts without clusters to vCenter
+
+
+
+
+
8.3.4. ESXi Host setup
+ All ESXi hosts should enable CPU hardware virtualization support in BIOS. Please note hardware virtualization support is not enabled by default on most servers.
+
8.3.5. Physical Host Networking
+ You should have a plan for cabling the vSphere hosts. Proper network configuration is required before adding a vSphere host to CloudStack. To configure an ESXi host, you can use vClient to add it as standalone host to vCenter first. Once you see the host appearing in the vCenter inventory tree, click the host node in the inventory tree, and navigate to the Configuration tab.
+
+ In the host configuration tab, click the "Hardware/Networking" link to bring up the networking configuration page as above.
+
8.3.5.1. Configure Virtual Switch
+ A default virtual switch vSwitch0 is created. CloudStack requires all ESXi hosts in the cloud to use the same set of virtual switch names. If you change the default virtual switch name, you will need to configure one or more CloudStack configuration variables as well.
+
8.3.5.1.1. Separating Traffic
+ CloudStack allows you to use vCenter to configure three separate networks per ESXi host. These networks are identified by the name of the vSwitch they are connected to. The allowed networks for configuration are public (for traffic to/from the public internet), guest (for guest-guest traffic), and private (for management and usually storage traffic). You can use the default virtual switch for all three, or create one or two other vSwitches for those traffic types.
+
+ If you want to separate traffic in this way you should first create and configure vSwitches in vCenter according to the vCenter instructions. Take note of the vSwitch names you have used for each traffic type. You will configure CloudStack to use these vSwitches.
+
8.3.5.1.2. Increasing Ports
+ By default a virtual switch on ESXi hosts is created with 56 ports. We recommend setting it to 4088, the maximum number of ports allowed. To do that, click the "Properties..." link for virtual switch (note this is not the Properties link for Networking).
+
+ In vSwitch properties dialog, select the vSwitch and click Edit. You should see the following dialog:
+
+ In this dialog, you can change the number of switch ports. After you've done that, ESXi hosts are required to reboot in order for the setting to take effect.
+
8.3.5.2. Configure vCenter Management Network
+ In the vSwitch properties dialog box, you may see a vCenter management network. This same network will also be used as the CloudStack management network. CloudStack requires the vCenter management network to be configured properly. Select the management network item in the dialog, then click Edit.
+
+ Make sure the following values are set:
+
+ VLAN ID set to the desired ID
+
+ vMotion enabled.
+
+ Management traffic enabled.
+
+ If the ESXi hosts have multiple VMKernel ports, and ESXi is not using the default value "Management Network" as the management network name, you must follow these guidelines to configure the management network port group so that CloudStack can find it:
+
+ Use one label for the management network port across all ESXi hosts.
+
+ In the CloudStack UI, go to Configuration - Global Settings and set vmware.management.portgroup to the management network label from the ESXi hosts.
+
8.3.5.3. Extend Port Range for CloudStack Console Proxy
+ (Applies only to VMware vSphere version 4.x)
+
+ You need to extend the range of firewall ports that the console proxy works with on the hosts. This is to enable the console proxy to work with VMware-based VMs. The default additional port range is 59000-60000. To extend the port range, log in to the VMware ESX service console on each host and run the following commands:
+
+ NIC bonding on vSphere hosts may be done according to the vSphere installation guide.
+
8.3.6. Storage Preparation for vSphere (iSCSI only)
+ Use of iSCSI requires preparatory work in vCenter. You must add an iSCSI target and create an iSCSI datastore.
+
+ If you are using NFS, skip this section.
+
8.3.6.1. Enable iSCSI initiator for ESXi hosts
+ In vCenter, go to hosts and Clusters/Configuration, and click Storage Adapters link. You will see:
+
+ Select iSCSI software adapter and click Properties.
+
+ Click the Configure... button.
+
+ Check Enabled to enable the initiator.
+
+ Click OK to save.
+
8.3.6.2. Add iSCSI target
+ Under the properties dialog, add the iSCSI target info:
+
+ Repeat these steps for all ESXi hosts in the cluster.
+
8.3.6.3. Create an iSCSI datastore
+ You should now create a VMFS datastore. Follow these steps to do so:
+
+ Select Home/Inventory/Datastores.
+
+ Right click on the datacenter node.
+
+ Choose Add Datastore... command.
+
+ Follow the wizard to create a iSCSI datastore.
+
+ This procedure should be done on one host in the cluster. It is not necessary to do this on all hosts.
+
8.3.6.4. Multipathing for vSphere (Optional)
+ Storage multipathing on vSphere nodes may be done according to the vSphere installation guide.
+
8.3.7. Add Hosts or Configure Clusters (vSphere)
+ Use vCenter to create a vCenter cluster and add your desired hosts to the cluster. You will later add the entire cluster to CloudStack. (see Section 6.4.2, “Add Cluster: vSphere”).
+
+ CloudStack account owners can create virtual private networks (VPN) to access their virtual machines. If the guest network is instantiated from a network offering that offers the Remote Access VPN service, the virtual router (based on the System VM) is used to provide the service. CloudStack provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN. CloudStack does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.
+
Note
+ Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
+
+ Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
+
+ Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.
+
15.17.1. Configuring VPN
+ To set up VPN for the cloud:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, click Global Settings.
+
+ Set the following global configuration parameters.
+
+ remote.access.vpn.client.ip.range – The range of IP addressess to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
+
+ remote.access.vpn.psk.length – Length of the IPSec key.
+
+ remote.access.vpn.user.limit – Maximum number of VPN users per account.
+
+ To enable VPN for a particular network:
+
+ Log in as a user or administrator to the CloudStack UI.
+
+ In the left navigation, click Network.
+
+ Click the name of the network you want to work with.
+
+ Click View IP Addresses.
+
+ Click one of the displayed IP address names.
+
+ Click the Enable VPN button
+
+ .
+
+ The IPsec key is displayed in a popup window.
+
15.17.2. Using VPN with Windows
+ The procedure to use VPN varies by Windows version. Generally, the user must edit the VPN properties and make sure that the default route is not the VPN. The following steps are for Windows L2TP clients on Windows Vista. The commands should be similar for other Windows versions.
+
+ Log in to the CloudStack UI and click on the source NAT IP for the account. The VPN tab should display the IPsec preshared key. Make a note of this and the source NAT IP. The UI also lists one or more users and their passwords. Choose one of these users, or, if none exists, add a user and password.
+
+ On the Windows box, go to Control Panel, then select Network and Sharing center. Click Setup a connection or network.
+
+ In the next dialog, select No, create a new connection.
+
+ In the next dialog, select Use my Internet Connection (VPN).
+
+ In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check Don't connect now.
+
+ In the next dialog, enter the user name and password selected in step 1.
+
+ Click Create.
+
+ Go back to the Control Panel and click Network Connections to see the new connection. The connection is not active yet.
+
+ Right-click the new connection and select Properties. In the Properties dialog, select the Networking tab.
+
+ In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key. Enter the preshared key from Step 1.
+
+ The connection is ready for activation. Go back to Control Panel -> Network Connections and double-click the created connection.
+
+ Enter the user name and password from Step 1.
+
15.17.3. Using VPN with Mac OS X
+ In Mac OS X, in Network Preferences - Advanced, make sure Send all traffic over VPN connection is not checked.
+
15.17.4. Setting Up a Site-to-Site VPN Connection
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+
+ Cisco ISR with IOS 12.4 or later
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
Note
+ In addition to the specific Cisco and Juniper devices listed above, the expectation is that any Cisco or Juniper device running on the supported operating systems are able to establish VPN connections.
+
+ To set up a Site-to-Site VPN connection, perform the following:
+
+ Create a VPN gateway for the VPC that you created.
+
+ Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
+
15.17.4.1. Creating and Updating a VPN Customer Gateway
Note
+ A VPN customer gateway can be connected to only one VPN gateway at a time.
+
+ To add a VPN Customer Gateway:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Click Add site-to-site VPN.
+
+ Provide the following information:
+
+ Name: A unique name for the VPN customer gateway you create.
+
+ Gateway: The IP address for the remote gateway.
+
+ CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be RFC1918-compliant.
+
+ IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share a secret key. This key value is used to authenticate the customer gateway and the VPC VPN gateway to each other.
+
Note
+ The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.
+
+ IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is accomplished through the Preshared Keys.
+
Note
+ The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.
+
+ IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.
+
+ IKE DH: A public-key cryptography protocol which allows two parties to establish a shared secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).
+
+ ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192, AES256, and 3DES.
+
Note
+ The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.
+
+ ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash algorithms are SHA1 and MD5.
+
+ Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised. This property enforces a new Diffie-Hellman key exchange. It provides the keying material that has greater key material life and thereby greater resistance to cryptographic attacks. The available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key exchanges increase as the DH groups grow larger, as does the time of the exchanges.
+
Note
+ When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.
+
+ IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is 86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.
+
+ ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a new IPsec encryption and authentication session keys.
+
+ Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual router to query the liveliness of its IKE peer at regular intervals. It’s recommended to have the same configuration of DPD on both side of VPN connection.
+
+ Click OK.
+
Updating and Removing a VPN Customer Gateway
+ You can update a customer gateway either with no VPN connection, or related VPN connection is in error state.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Select the VPN customer gateway you want to work with.
+
+ To modify the required parameters, click the Edit VPN Customer Gateway button
+
+
+ To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
+
+
+ Click OK.
+
15.17.4.2. Creating a VPN gateway for the VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Site-to-Site VPN.
+
+ If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN prompts you to create a VPN gateway.
+
+ In the confirmation dialog, click Yes to confirm.
+
+ Within a few moments, the VPN gateway is created. You will be prompted to view the details of the VPN gateway you have created. Click Yes to confirm.
+
+ The following details are displayed in the VPN Gateway page:
+
+ IP Address
+
+ Account
+
+ Domain
+
15.17.4.3. Creating a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you create for the account are listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ Click Create VPN Connection.
+
+ The Create VPN Connection dialog is displayed:
+
+ Select the desired customer gateway, then click OK to confirm.
+
+ Within a few moments, the VPN Connection is displayed.
+
+ The following information on the VPN connection is displayed:
+
+ IP Address
+
+ Gateway
+
+ State
+
+ IPSec Preshared Key
+
+ IKE Policy
+
+ ESP Policy
+
15.17.4.4. Restarting and Removing a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ All the VPN connections you created are displayed.
+
+ Select the VPN connection you want to work with.
+
+ The Details tab is displayed.
+
+ To remove a VPN connection, click the Delete VPN connection button
+
+
+ To restart a VPN connection, click the Reset VPN connection button present in the Details tab.
+
+
+ CloudStack is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. CloudStack manages the network, storage, and compute nodes that make up a cloud infrastructure. Use CloudStack to deploy, manage, and configure cloud computing environments.
+
+ Typical users are service providers and enterprises. With CloudStack, you can:
+
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with CloudStack an enterprise can offer self-service virtual machines to users without involving IT departments.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/whats-new-in-api-3.0.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/whats-new-in-api-3.0.html
new file mode 100644
index 00000000000..e9819bd4738
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/whats-new-in-api-3.0.html
@@ -0,0 +1,628 @@
+
+
+3.2. What's New in the API for 3.0
+ Port 8096, which allows API calls without authentication, is closed and disabled by default on any fresh 3.0.1 installations. You can enable 8096 (or another port) for this purpose as follows:
+
+ Ensure that the first Management Server is installed and running.
+
+ Set the global configuration parameter integration.api.port to the desired port.
+
+ Restart the Management Server.
+
+ On the Management Server host machine, create an iptables rule allowing access to that port.
+
3.2.2. Stopped VM
+ CloudStack now supports creating a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A VM can now be deployed in two ways: create and start a VM (the default method); or create a VM and leave it in the stopped state.
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature.
+
+ The possible values are:
+
+ true - The VM starts as a part of the VM deployment.
+
+ false - The VM is left in the stopped state at the end of the VM deployment.
+
+ The default value is true.
+
3.2.3. Change to Behavior of List Commands
+ There was a major change in how our List* API commands work in CloudStack 3.0 compared to 2.2.x. The rules below apply only for managed resources – those that belong to an account, domain, or project. They are irrelevant for the List* commands displaying unmanaged (system) resources, such as hosts, clusters, and external network resources.
+
+ When no parameters are passed in to the call, the caller sees only resources owned by the caller (even when the caller is the administrator). Previously, the administrator saw everyone else's resources by default.
+
+ When accountName and domainId are passed in:
+
+ The caller sees the resources dedicated to the account specified.
+
+ If the call is executed by a regular user, the user is authorized to specify only the user's own account and domainId.
+
+ If the caller is a domain administrator, CloudStack performs an authorization check to see whether the caller is permitted to view resources for the given account and domainId.
+
+ When projectId is passed in, only resources belonging to that project are listed.
+
+ When domainId is passed in, the call returns only resources belonging to the domain specified. To see the resources of subdomains, use the parameter isRecursive=true. Again, the regular user can see only resources owned by that user, the root administrator can list anything, and a domain administrator is authorized to see only resources of the administrator's own domain and subdomains.
+
+ To see all resources the caller is authorized to see, except for Project resources, use the parameter listAll=true.
+
+ To see all Project resources the caller is authorized to see, use the parameter projectId=-1.
+
+ There is one API command that doesn't fall under the rules above completely: the listTemplates command. This command has its own flags defining the list rules:
+
+
+ listTemplates Flag
+
+
+
+ Description
+
+
+
+ featured
+
+
+
+ Returns templates that have been marked as featured and public.
+
+
+
+ self
+
+
+
+ Returns templates that have been registered or created by the calling user.
+
+
+
+ selfexecutable
+
+
+
+ Same as self, but only returns templates that are ready to be deployed with.
+
+
+
+ sharedexecutable
+
+
+
+ Ready templates that have been granted to the calling user by another user.
+
+
+
+ executable
+
+
+
+ Templates that are owned by the calling user, or public templates, that can be used to deploy a new VM.
+
+
+
+ community
+
+
+
+ Returns templates that have been marked as public but not featured.
+
+
+
+ all
+
+
+
+ Returns all templates (only usable by admins).
+
+
+ The CloudStack UI on a general view will display all resources that the logged-in user is authorized to see, except for project resources. To see the project resources, select the project view.
+
+ Changes the service offering for a system VM (console proxy or secondary storage). The system VM must be in a "Stopped" state for this command to take effect.
+
3.2.5.2. Added in 3.0.1
+ changeServiceForSystemVm
+
+ Changes the service offering for a system VM (console proxy or secondary storage). The system VM must be in a "Stopped" state for this command to take effect.
+
3.2.5.3. Added in 3.0.0
+
+ assignVirtualMachine (Move a user VM to another user under same domain.)
+
+
+
+ restoreVirtualMachine (Restore a VM to original template or specific snapshot)
+
+
+
+ createLBStickinessPolicy (Creates a Load Balancer stickiness policy )
+
+
+
+ deleteLBStickinessPolicy (Deletes a LB stickiness policy.)
+
+ listNetscalerLoadBalancerNetworks (lists network that are using a netscaler load balancer device)
+
+
+
+ createVirtualRouterElement (Create a virtual router element.)
+
+
+
+ configureVirtualRouterElement (Configures a virtual router element.)
+
+
+
+ listVirtualRouterElements (Lists all available virtual router elements.)
+
+
+
+
+
+
+
+
3.2.6. Added CloudStack Error Codes
+ You can now find the CloudStack-specific error code in the exception response for each type of exception. The following list of error codes is added to the new class named CSExceptionErrorCode. These codes are applicable in CloudStack 3.0.3 and later versions.
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/whats-new-in-api-4.0.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/whats-new-in-api-4.0.html
new file mode 100644
index 00000000000..09e4ebdc73b
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/whats-new-in-api-4.0.html
@@ -0,0 +1,538 @@
+
+
+3.1. What's New in the API for 4.0
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/who-should-read-installation.html b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/who-should-read-installation.html
new file mode 100644
index 00000000000..65dffee2120
--- /dev/null
+++ b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/who-should-read-installation.html
@@ -0,0 +1,5 @@
+
+
+4.1. Who Should Read This
+ For those who have already gone through a design phase and planned a more sophisticated deployment, or those who are ready to start scaling up a trial installation. With the following procedures, you can start using the more powerful features of CloudStack, such as advanced VLAN networking, high availability, additional network elements such as load balancers and firewalls, and support for multiple hypervisors including Citrix XenServer, KVM, and VMware vSphere.
+
+ The Usage Server is an optional, separately-installed part of CloudStack that provides aggregated usage records which you can use to create billing integration for CloudStack. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances.
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day.
+
+ CloudStack supports ISOs and their attachment to guest VMs. An ISO is a read-only file that has an ISO/CD-ROM style file system. Users can upload their own ISOs and mount them on their guest VMs.
+
+ ISOs are uploaded based on a URL. HTTP is the supported protocol. Once the ISO is available via HTTP specify an upload URL such as http://my.web.server/filename.iso.
+
+ ISOs may be public or private, like templates.ISOs are not hypervisor-specific. That is, a guest on vSphere can mount the exact same image that a guest on KVM can mount.
+
+ ISO images may be stored in the system and made available with a privacy level similar to templates. ISO images are classified as either bootable or not bootable. A bootable ISO image is one that contains an OS image. CloudStack allows a user to boot a guest VM off of an ISO image. Users can also attach ISO images to guest VMs. For example, this enables installing PV drivers into Windows. ISO images are not hypervisor-specific.
+
10.11.1. Adding an ISO
+ To make additional operating system or other software available for use with guest VMs, you can add an ISO. The ISO is typically thought of as an operating system image, but you can also add ISOs for other types of software, such as desktop applications that you want to be installed as part of a template.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation bar, click Templates.
+
+ In Select View, choose ISOs.
+
+ Click Add ISO.
+
+ In the Add ISO screen, provide the following:
+
+ Name: Short name for the ISO image. For example, CentOS 6.2 64-bit.
+
+ Description: Display test for the ISO image. For example, CentOS 6.2 64-bit.
+
+ URL: The URL that hosts the ISO image. The Management Server must be able to access this location via HTTP. If needed you can place the ISO image directly on the Management Server
+
+ Zone: Choose the zone where you want the ISO to be available, or All Zones to make it available throughout CloudStack.
+
+ Bootable: Whether or not a guest could boot off this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not bootable.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of your desired ISO image is listed, choose it.
+
+ If the OS Type of the ISO is not listed or if the ISO is not bootable, choose Other.
+
+ (XenServer only) If you want to boot from this ISO in PV mode, choose Other PV (32-bit) or Other PV (64-bit)
+
+ (KVM only) If you choose an OS that is PV-enabled, the VMs created from this ISO will have a SCSI (virtio) root disk. If the OS is not PV-enabled, the VMs will have an IDE root disk. The PV-enabled types are:
+
+
+ Fedora 13
+
+
+
+ Fedora 12
+
+
+
+ Fedora 11
+
+
+
+ Fedora 10
+
+
+
+ Fedora 9
+
+
+
+ Other PV
+
+
+
+ Debian GNU/Linux
+
+
+
+ CentOS 5.3
+
+
+
+ CentOS 5.4
+
+
+
+ CentOS 5.5
+
+
+
+ Red Hat Enterprise Linux 5.3
+
+
+
+ Red Hat Enterprise Linux 5.4
+
+
+
+ Red Hat Enterprise Linux 5.5
+
+
+
+ Red Hat Enterprise Linux 6
+
+
+
Note
+ It is not recommended to choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not work. In these cases, choose Other.
+
+ Extractable: Choose Yes if the ISO should be available for extraction.
+
+ Public: Choose Yes if this ISO should be available to other users.
+
+ Featured: Choose Yes if you would like this ISO to be more prominent for users to select. The ISO will appear in the Featured ISOs list. Only an administrator can make an ISO Featured.
+
+ Click OK.
+
+ The Management Server will download the ISO. Depending on the size of the ISO, this may take a long time. The ISO status column will display Ready once it has been successfully downloaded into secondary storage. Clicking Refresh updates the download percentage.
+
+ Important: Wait for the ISO to finish downloading. If you move on to the next task and try to use the ISO right away, it will appear to fail. The entire ISO must be available before CloudStack can work with it.
+
10.11.2. Attaching an ISO to a VM
+ In the left navigation, click Instances.
+
+ Choose the virtual machine you want to work with.
+
+ Click the Attach ISO button
+
+
+ In the Attach ISO dialog box, select the desired ISO.
+
+ (Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)
+
+ CloudStack supports snapshots of disk volumes. Snapshots are a point-in-time capture of virtual machine disks. Memory and CPU states are not captured.
+
+ Snapshots may be taken for volumes, including both root and data disks. The administrator places a limit on the number of stored snapshots per user. Users can create new volumes from the snapshot for recovery of particular files and they can create templates from snapshots to boot from a restored disk.
+
+ Users can create snapshots manually or by setting up automatic recurring snapshot policies. Users can also create disk volumes from snapshots, which may be attached to a VM like any other disk volume. Snapshots of both root disks and data disks are supported. However, CloudStack does not currently support booting a VM from a recovered root disk. A disk recovered from snapshot of a root disk is treated as a regular data disk; the data on recovered disk can be accessed by attaching the disk to a VM.
+
+ A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot.
+
+ CloudStack uses several types of system virtual machines to perform tasks in the cloud. In general CloudStack manages these system VMs and creates, starts, and stops them as needed based on scale and immediate needs. However, the administrator should be aware of them and their roles to assist in debugging issues.
+
+ A template is a reusable configuration for virtual machines. When users launch VMs, they can choose from a list of templates in CloudStack.
+
+ Specifically, a template is a virtual disk image that includes one of a variety of operating systems, optional additional software such as office applications, and settings such as access control to determine who can use the template. Each template is associated with a particular type of hypervisor, which is specified when the template is added to CloudStack.
+
+ CloudStack ships with a default template. In order to present more choices to users, CloudStack administrators and users can create templates and add them to CloudStack.
+
+ The Usage Server provides aggregated usage records which you can use to create billing integration for the CloudStack platform. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances. In the special case of bare metal instances, no template storage resources are consumed, but records showing zero usage are still included in the Usage Server's output.
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day. Its behavior is controlled by configuration settings as described in the CloudStack Administration Guide.
+
+ A volume provides storage to a guest VM. The volume can provide for a root disk or an additional data disk. CloudStack supports additional volumes for guest VMs.
+
+ Volumes are created for a specific hypervisor type. A volume that has been attached to guest using one hypervisor type (e.g, XenServer) may not be attached to a guest that is using another hypervisor type (e.g. vSphere, KVM). This is because the different hypervisors use different disk image formats.
+
+ CloudStack defines a volume as a unit of storage available to a guest VM. Volumes are either root disks or data disks. The root disk has "/" in the file system and is usually the boot device. Data disks provide for additional storage (e.g. As "/opt" or "D:"). Every guest VM has a root disk, and VMs can also optionally have a data disk. End users can mount multiple data disks to guest VMs. Users choose data disks from the disk offerings created by administrators. The user can create a template from a volume as well; this is the standard procedure for private template creation. Volumes are hypervisor-specific: a volume from one hypervisor type may not be used on a guest of another hypervisor type.
+
+ (Optional) If you are going to use Swift for cloud-wide secondary storage, you need to add it before you add zones.
+
+ Log in to the CloudStack UI as administrator.
+
+ If this is your first time visiting the UI, you will see the guided tour splash screen. Choose “Experienced user.” The Dashboard appears.
+
+ In the left navigation bar, click Global Settings.
+
+ In the search box, type swift.enable and click the search button.
+
+ Click the edit button and set swift.enable to true.
+
+
+
+ Restart the Management Server.
+
# service cloud-management restart
+ Refresh the CloudStack UI browser tab and log back in.
+
+ In the left navigation, choose Infrastructure.
+
+ On Zones, click View More.
+
+ (Optional) If you are using Swift storage, click Enable Swift. Provide the following:
+
+ URL. The Swift URL.
+
+ Account. The Swift account.
+
+ Username. The Swift account’s username.
+
+ Key. The Swift key.
+
+ 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.
+
+ For more information about the network types, see Network Setup.
+
+ The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you:
+
+ 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.
+
+ 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.
+
+ (Introduced in version 3.0.1) 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.2, “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, CloudPlatform 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.
+
7.2.2. 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.7.4, “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.
+
+ 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.2, “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.7.7, “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.3, “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.4, “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.5, “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.6, “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 :
+
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-API_Developers_Guide-en-US.pdf b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-API_Developers_Guide-en-US.pdf
new file mode 100644
index 00000000000..0b3e60f4fa6
Binary files /dev/null and b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-API_Developers_Guide-en-US.pdf differ
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-Admin_Guide-en-US.pdf b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-Admin_Guide-en-US.pdf
new file mode 100644
index 00000000000..2cebce1a3a9
Binary files /dev/null and b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-Admin_Guide-en-US.pdf differ
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-Installation_Guide-en-US.pdf b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-Installation_Guide-en-US.pdf
new file mode 100644
index 00000000000..a0f762bbd17
Binary files /dev/null and b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-Installation_Guide-en-US.pdf differ
diff --git a/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-release-notes-en-US.pdf b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-release-notes-en-US.pdf
new file mode 100644
index 00000000000..87edf84ed74
Binary files /dev/null and b/docs/publish/en-US/Apache_CloudStack/4.0.0-incubating/pdf/Admin_Guide/Apache_CloudStack-4.0.0-incubating-release-notes-en-US.pdf differ
diff --git a/docs/runbook/tmp/en-US/pdf/Apache_CloudStack-3.0.2-Runbook-en-US.pdf b/docs/runbook/tmp/en-US/pdf/Apache_CloudStack-3.0.2-Runbook-en-US.pdf
new file mode 100644
index 00000000000..d3b6ba0d212
Binary files /dev/null and b/docs/runbook/tmp/en-US/pdf/Apache_CloudStack-3.0.2-Runbook-en-US.pdf differ
diff --git a/docs/runbook/tmp/en-US/xml/Author_Group.xml b/docs/runbook/tmp/en-US/xml/Author_Group.xml
new file mode 100644
index 00000000000..c0e946a4de0
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Author_Group.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Apache
+ CloudStack
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Book_Info.xml b/docs/runbook/tmp/en-US/xml/Book_Info.xml
new file mode 100644
index 00000000000..4d32f7eef7a
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Book_Info.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Runbook
+ Prescriptive instructions for deploying Apache CloudStack
+ Apache CloudStack
+ 3.0.2
+ 0
+ 0
+
+
+ These runbooks are designed to provide a strict environment to guarantee a higher degree of success in initial deployments of Apache CloudStack. All of the elements of the environment will be provided to you. Apache CloudStack is capable of much more complex configurations, but they are beyond the scope of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Chapter.xml b/docs/runbook/tmp/en-US/xml/Chapter.xml
new file mode 100644
index 00000000000..d760ed81a82
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Chapter.xml
@@ -0,0 +1,55 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Test Chapter
+
+ This is a test paragraph
+
+
+ Test Section 1
+
+ This is a test paragraph in a section
+
+
+
+
+
+ Test Section 2
+
+ This is a test paragraph in Section 2
+
+
+
+ listitem text
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/Conventions.xml b/docs/runbook/tmp/en-US/xml/Common_Content/Conventions.xml
new file mode 100644
index 00000000000..cd7e8d46ae6
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/Conventions.xml
@@ -0,0 +1,178 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Document Conventions
+
+ This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.
+
+
+ In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default.
+
+
+ Typographic Conventions
+
+ Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.
+
+
+ Mono-spaced Bold
+
+
+ Used to highlight system input, including shell commands, file names and paths. Also used to highlight keycaps and key combinations. For example:
+
+
+
+ To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.
+
+
+
+
+ The above includes a file name, a shell command and a keycap, all presented in mono-spaced bold and all distinguishable thanks to context.
+
+
+ Key combinations can be distinguished from keycaps by the hyphen connecting each part of a key combination. For example:
+
+
+
+ Press Enter to execute the command.
+
+
+ Press CtrlAltF2 to switch to the first virtual terminal. Press CtrlAltF1 to return to your X-Windows session.
+
+
+
+
+ The first paragraph highlights the particular keycap to press. The second highlights two key combinations (each a set of three keycaps with each set pressed simultaneously).
+
+
+ If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:
+
+
+
+ File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.
+
+
+
+
+ Proportional Bold
+
+
+ This denotes words or phrases encountered on a system, including application names; dialog box text; labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:
+
+
+
+ Choose SystemPreferencesMouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
+
+
+ To insert a special character into a gedit file, choose ApplicationsAccessoriesCharacter Map from the main menu bar. Next, choose SearchFind… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose EditPaste from the gedit menu bar.
+
+
+
+
+ The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context.
+
+
+ Mono-spaced Bold Italic or Proportional Bold Italic
+
+
+ Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
+
+
+
+ To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.
+
+
+ The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.
+
+
+ To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.
+
+
+
+
+ Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
+
+
+ Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
+
+
+
+ Publican is a DocBook publishing system.
+
+
+
+
+
+
+
+ Pull-quote Conventions
+
+ Terminal output and source code listings are set off visually from the surrounding text.
+
+
+ Output sent to a terminal is set in mono-spaced roman and presented thus:
+
+
+books Desktop documentation drafts mss photos stuff svn
+books_tests Desktop1 downloads images notes scripts svgs
+
+ Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:
+
+
+package org.jboss.book.jca.ex1;
+
+import javax.naming.InitialContext;
+
+public class ExClient
+{
+ public static void main(String args[])
+ throws Exception
+ {
+ InitialContext iniCtx = new InitialContext();
+ Object ref = iniCtx.lookup("EchoBean");
+ EchoHome home = (EchoHome) ref;
+ Echo echo = home.create();
+
+ System.out.println("Created Echo");
+
+ System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
+ }
+}
+
+
+
+
+ Notes and Warnings
+
+ Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.
+
+
+ Note
+
+ Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.
+
+
+
+
+ Important
+
+ Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled 'Important' will not cause data loss but may cause irritation and frustration.
+
+
+
+
+ Warning
+
+ Warnings should not be ignored. Ignoring warnings will most likely cause data loss.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/Feedback.xml b/docs/runbook/tmp/en-US/xml/Common_Content/Feedback.xml
new file mode 100644
index 00000000000..0f8803bf4d5
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/Feedback.xml
@@ -0,0 +1,22 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ We Need Feedback!
+
+ feedback1
+ contact information for this brand
+
+
+
+ If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a bug: http://bugs.cloudstack.org against the component Doc
+
+
+ If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/Legal_Notice.xml b/docs/runbook/tmp/en-US/xml/Common_Content/Legal_Notice.xml
new file mode 100644
index 00000000000..c193284071f
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/Legal_Notice.xml
@@ -0,0 +1,23 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/css/common.css b/docs/runbook/tmp/en-US/xml/Common_Content/css/common.css
new file mode 100644
index 00000000000..d7dc3f27be8
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/css/common.css
@@ -0,0 +1,1528 @@
+* {
+ widows: 2 !important;
+ orphans: 2 !important;
+}
+
+body, h1, h2, h3, h4, h5, h6, pre, li, div {
+ line-height: 1.29em;
+}
+
+body {
+ background-color: white;
+ margin:0 auto;
+ font-family: "liberation sans", "Myriad ", "Bitstream Vera Sans", "Lucida Grande", "Luxi Sans", "Trebuchet MS", helvetica, verdana, arial, sans-serif;
+ font-size:12px;
+ max-width:55em;
+ color:black;
+}
+
+body.toc_embeded {
+ /*for web hosting system only*/
+ margin-left: 300px;
+}
+
+object.toc, iframe.toc {
+ /*for web hosting system only*/
+ border-style:none;
+ position:fixed;
+ width:290px;
+ height:99.99%;
+ top:0;
+ left:0;
+ z-index: 100;
+ border-style:none;
+ border-right:1px solid #999;
+}
+
+/* Hide web menu */
+
+body.notoc {
+ margin-left: 3em;
+}
+
+iframe.notoc {
+ border-style:none;
+ border: none;
+ padding: 0em;
+ position:fixed;
+ width: 21px;
+ height: 29px;
+ top: 0px;
+ left:0;
+ overflow: hidden;
+ margin: 0em;
+ margin-left: -3px;
+}
+/* End hide web menu */
+
+/* desktop styles */
+body.desktop {
+ margin-left: 26em;
+}
+
+body.desktop .book > .toc {
+ display:block;
+ width:24em;
+ height:99%;
+ position:fixed;
+ overflow:auto;
+ top:0px;
+ left:0px;
+ padding-left:1em;
+ background-color:#EEEEEE;
+}
+
+.toc {
+ line-height:1.35em;
+}
+
+.toc .glossary,
+.toc .chapter, .toc .appendix {
+ margin-top:1em;
+}
+
+.toc .part {
+ margin-top:1em;
+ display:block;
+}
+
+span.glossary,
+span.appendix {
+ display:block;
+ margin-top:0.5em;
+}
+
+div {
+ padding-top:0px;
+}
+
+div.section {
+ padding-top:1em;
+}
+
+p, div.para, div.formalpara {
+ padding-top:0px;
+ margin-top:0.3em;
+ padding-bottom:0px;
+ margin-bottom:1em;
+}
+
+/*Links*/
+a {
+ outline: none;
+}
+
+a:link {
+ text-decoration:none;
+ border-bottom: 1px dotted ;
+ color:#3366cc;
+}
+
+a:visited {
+ text-decoration:none;
+ border-bottom: 1px dotted ;
+ color:#003366;
+}
+
+div.longdesc-link {
+ float:right;
+ color:#999;
+}
+
+.toc a, .qandaset a {
+ font-weight:normal;
+ border:none;
+}
+
+.toc a:hover, .qandaset a:hover
+{
+ border-bottom: 1px dotted;
+}
+
+/*headings*/
+h1, h2, h3, h4, h5, h6 {
+ color: #336699;
+ margin-top: 0em;
+ margin-bottom: 0em;
+ background-color: transparent;
+ page-break-inside: avoid;
+ page-break-after: avoid;
+}
+
+h1 {
+ font-size:2.0em;
+}
+
+.titlepage h1.title {
+ font-size: 3.0em;
+ padding-top: 1em;
+ text-align:left;
+}
+
+.book > .titlepage h1.title {
+ text-align:center;
+}
+
+.article > .titlepage h1.title {
+ text-align:center;
+}
+
+.set .titlepage > div > div > h1.title {
+ text-align:center;
+}
+
+.producttitle {
+ margin-top: 0em;
+ margin-bottom: 0em;
+ font-size: 3.0em;
+ font-weight: bold;
+ background: #003d6e url(../images/h1-bg.png) top left repeat-x;
+ color: white;
+ text-align: center;
+ padding: 0.7em;
+}
+
+.titlepage .corpauthor {
+ margin-top: 1em;
+ text-align: center;
+}
+
+.section h1.title {
+ font-size: 1.6em;
+ padding: 0em;
+ color: #336699;
+ text-align: left;
+ background: white;
+}
+
+h2 {
+ font-size:1.6em;
+}
+
+
+h2.subtitle, h3.subtitle {
+ margin-top: 1em;
+ margin-bottom: 1em;
+ font-size: 1.4em;
+ text-align: center;
+}
+
+.preface > div > div > div > h2.title {
+ margin-top: 1em;
+ font-size: 2.0em;
+}
+
+.appendix h2 {
+ margin-top: 1em;
+ font-size: 2.0em;
+}
+
+
+
+h3 {
+ font-size:1.3em;
+ padding-top:0em;
+ padding-bottom:0em;
+}
+h4 {
+ font-size:1.1em;
+ padding-top:0em;
+ padding-bottom:0em;
+}
+
+h5 {
+ font-size:1em;
+}
+
+h6 {
+ font-size:1em;
+}
+
+h5.formalpara {
+ font-size:1em;
+ margin-top:2em;
+ margin-bottom:.8em;
+}
+
+.abstract h6 {
+ margin-top:1em;
+ margin-bottom:.5em;
+ font-size:2em;
+}
+
+/*element rules*/
+hr {
+ border-collapse: collapse;
+ border-style:none;
+ border-top: 1px dotted #ccc;
+ width:100%;
+ margin-top: 3em;
+}
+
+/* web site rules */
+ul.languages, .languages li {
+ display:inline;
+ padding:0em;
+}
+
+.languages li a {
+ padding:0em .5em;
+ text-decoration: none;
+}
+
+.languages li p, .languages li div.para {
+ display:inline;
+}
+
+.languages li a:link, .languages li a:visited {
+ color:#444;
+}
+
+.languages li a:hover, .languages li a:focus, .languages li a:active {
+ color:black;
+}
+
+ul.languages {
+ display:block;
+ background-color:#eee;
+ padding:.5em;
+}
+
+/*supporting stylesheets*/
+
+/*unique to the webpage only*/
+.books {
+ position:relative;
+}
+
+.versions li {
+ width:100%;
+ clear:both;
+ display:block;
+}
+
+a.version {
+ font-size:2em;
+ text-decoration:none;
+ width:100%;
+ display:block;
+ padding:1em 0em .2em 0em;
+ clear:both;
+}
+
+a.version:before {
+ content:"Version";
+ font-size:smaller;
+}
+
+a.version:visited, a.version:link {
+ color:#666;
+}
+
+a.version:focus, a.version:hover {
+ color:black;
+}
+
+.books {
+ display:block;
+ position:relative;
+ clear:both;
+ width:100%;
+}
+
+.books li {
+ display:block;
+ width:200px;
+ float:left;
+ position:relative;
+ clear: none ;
+}
+
+.books .html {
+ width:170px;
+ display:block;
+}
+
+.books .pdf {
+ position:absolute;
+ left:170px;
+ top:0px;
+ font-size:smaller;
+}
+
+.books .pdf:link, .books .pdf:visited {
+ color:#555;
+}
+
+.books .pdf:hover, .books .pdf:focus {
+ color:#000;
+}
+
+.books li a {
+ text-decoration:none;
+}
+
+.books li a:hover {
+ color:black;
+}
+
+/*products*/
+.products li {
+ display: block;
+ width:300px;
+ float:left;
+}
+
+.products li a {
+ width:300px;
+ padding:.5em 0em;
+}
+
+.products ul {
+ clear:both;
+}
+
+/*revision history*/
+.revhistory {
+ display:block;
+}
+
+.revhistory table {
+ background-color:transparent;
+ border-color:#fff;
+ padding:0em;
+ margin: 0;
+ border-collapse:collapse;
+ border-style:none;
+}
+
+.revhistory td {
+ text-align :left;
+ padding:0em;
+ border: none;
+ border-top: 1px solid #fff;
+ font-weight: bold;
+}
+
+.revhistory .simplelist td {
+ font-weight: normal;
+}
+
+.revhistory .simplelist {
+ margin-bottom: 1.5em;
+ margin-left: 1em;
+}
+
+.revhistory table th {
+ display: none;
+}
+
+
+/*credits*/
+.authorgroup div {
+ clear:both;
+ text-align: center;
+}
+
+h3.author {
+ margin: 0em;
+ padding: 0em;
+ padding-top: 1em;
+}
+
+.authorgroup h4 {
+ padding: 0em;
+ margin: 0em;
+ padding-top: 1em;
+ margin-top: 1em;
+}
+
+.author,
+.editor,
+.translator,
+.othercredit,
+.contrib {
+ display: block;
+}
+
+.revhistory .author {
+ display: inline;
+}
+
+.othercredit h3 {
+ padding-top: 1em;
+}
+
+
+.othercredit {
+ margin:0em;
+ padding:0em;
+}
+
+.releaseinfo {
+ clear: both;
+}
+
+.copyright {
+ margin-top: 1em;
+}
+
+/* qanda sets */
+.answer {
+ margin-bottom:1em;
+ border-bottom:1px dotted #ccc;
+}
+
+.qandaset .toc {
+ border-bottom:1px dotted #ccc;
+}
+
+.question {
+ font-weight:bold;
+}
+
+.answer .data, .question .data {
+ padding-left: 2.6em;
+}
+
+.answer label, .question label {
+ float:left;
+ font-weight:bold;
+}
+
+/* inline syntax highlighting */
+.perl_Alert {
+ color: #0000ff;
+}
+
+.perl_BaseN {
+ color: #007f00;
+}
+
+.perl_BString {
+ color: #5C3566;
+}
+
+.perl_Char {
+ color: #ff00ff;
+}
+
+.perl_Comment {
+ color: #FF00FF;
+}
+
+
+.perl_DataType {
+ color: #0000ff;
+}
+
+
+.perl_DecVal {
+ color: #00007f;
+}
+
+
+.perl_Error {
+ color: #ff0000;
+}
+
+
+.perl_Float {
+ color: #00007f;
+}
+
+
+.perl_Function {
+ color: #007f00;
+}
+
+
+.perl_IString {
+ color: #5C3566;
+}
+
+
+.perl_Keyword {
+ color: #002F5D;
+}
+
+
+.perl_Operator {
+ color: #ffa500;
+}
+
+
+.perl_Others {
+ color: #b03060;
+}
+
+
+.perl_RegionMarker {
+ color: #96b9ff;
+}
+
+
+.perl_Reserved {
+ color: #9b30ff;
+}
+
+
+.perl_String {
+ color: #5C3566;
+}
+
+
+.perl_Variable {
+ color: #0000ff;
+}
+
+
+.perl_Warning {
+ color: #0000ff;
+}
+
+/*Lists*/
+ul {
+ padding-left:1.6em;
+ list-style-image:url(../images/dot.png);
+ list-style-type: circle;
+}
+
+ul ul {
+ list-style-image:url(../images/dot2.png);
+ list-style-type: circle;
+}
+
+ol {
+ list-style-image:none;
+ list-style-type: decimal;
+}
+
+ol ol {
+ list-style-type: lower-alpha;
+}
+
+ol.arabic {
+ list-style-type: decimal;
+}
+
+ol.loweralpha {
+ list-style-type: lower-alpha;
+}
+
+ol.lowerroman {
+ list-style-type: lower-roman;
+}
+
+ol.upperalpha {
+ list-style-type: upper-alpha;
+}
+
+ol.upperroman {
+ list-style-type: upper-roman;
+}
+
+dt {
+ font-weight:bold;
+ margin-bottom:0em;
+ padding-bottom:0em;
+}
+
+dd {
+ margin:0em;
+ margin-left:2em;
+ padding-top:0em;
+ padding-bottom: 1em;
+}
+
+li {
+ padding-top:0px;
+ margin-top:0em;
+ padding-bottom:0px;
+ margin-bottom:0.4em;
+}
+
+li p, li div.para {
+ padding-top:0px;
+ margin-top:0em;
+ padding-bottom:0px;
+ margin-bottom:0.3em;
+}
+
+/*images*/
+img {
+ display:block;
+ margin: 2em 0;
+}
+
+.inlinemediaobject, .inlinemediaobject img {
+ display:inline;
+ margin:0em;
+}
+
+.figure img {
+ display:block;
+ margin:0;
+ page-break-inside: avoid;
+}
+
+.figure .title {
+ margin:0em;
+ margin-bottom:2em;
+ padding:0px;
+}
+
+/*document modes*/
+.confidential {
+ background-color:#900;
+ color:White;
+ padding:.5em .5em;
+ text-transform:uppercase;
+ text-align:center;
+}
+
+.longdesc-link {
+ display:none;
+}
+
+.longdesc {
+ display:none;
+}
+
+.prompt {
+ padding:0em .3em;
+}
+
+/*user interface styles*/
+.screen .replaceable {
+}
+
+.guibutton, .guilabel {
+ font-family: "liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-weight: bold;
+ white-space: nowrap;
+}
+
+.example {
+ background-color: #ffffff;
+ border-left: 3px solid #aaaaaa;
+ padding-top: 1em;
+ padding-bottom: 0.1em;
+}
+
+.example h6 {
+ padding-left: 10px;
+}
+
+.example-contents {
+ padding-left: 10px;
+ background-color: #ffffff;
+}
+
+.example-contents .para {
+/* padding: 10px;*/
+}
+
+/*terminal/console text*/
+.computeroutput,
+.option {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-weight:bold;
+}
+
+.replaceable {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-style: italic;
+}
+
+.command, .filename, .keycap, .classname, .literal {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-weight:bold;
+}
+
+/* no bold in toc */
+.toc * {
+ font-weight: inherit;
+}
+
+pre {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ display:block;
+ background-color: #f5f5f5;
+ color: #000000;
+ border: 1px solid #aaaaaa;
+ margin-bottom: 0.3em;
+ padding:.5em 1em;
+ white-space: pre-wrap; /* css-3 */
+ white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
+ white-space: -pre-wrap; /* Opera 4-6 */
+ white-space: -o-pre-wrap; /* Opera 7 */
+ word-wrap: break-word; /* Internet Explorer 5.5+ */
+ font-size: 0.9em;
+}
+
+pre .replaceable,
+pre .keycap {
+}
+
+code {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+/* white-space: nowrap;*/
+ white-space: pre-wrap;
+ word-wrap: break-word;
+ font-weight:bold;
+}
+
+.parameter code {
+ display: inline;
+ white-space: pre-wrap; /* css-3 */
+ white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
+ white-space: -pre-wrap; /* Opera 4-6 */
+ white-space: -o-pre-wrap; /* Opera 7 */
+ word-wrap: break-word; /* Internet Explorer 5.5+ */
+}
+
+/*Notifications*/
+div.warning:before {
+ content:url(../images/warning.png);
+ padding-left: 5px;
+}
+
+div.note:before {
+ content:url(../images/note.png);
+ padding-left: 5px;
+}
+
+div.important:before {
+ content:url(../images/important.png);
+ padding-left: 5px;
+}
+
+div.warning, div.note, div.important {
+ color: black;
+ margin: 0em;
+ padding: 0em;
+ background: none;
+ background-color: white;
+ margin-bottom: 1em;
+ border-bottom: 1px solid #aaaaaa;
+ page-break-inside: avoid;
+}
+
+div.warning h2, div.note h2,div.important h2 {
+ margin: 0em;
+ padding: 0em;
+ color: #eeeeec;
+ padding-top: 0px;
+ padding-bottom: 0px;
+ height: 1.4em;
+ line-height: 1.4em;
+ font-size: 1.4em;
+ display:inline;
+}
+
+div.admonition_header {
+ clear: both;
+ margin: 0em;
+ padding: 0em;
+ margin-top: -3.3em;
+ padding-left: 58px;
+ line-height: 1.0em;
+ font-size: 1.0em;
+}
+
+div.warning div.admonition_header {
+ background: url(../images/red.png) top left repeat-x;
+ background-color: #590000;
+}
+
+div.note div.admonition_header {
+ background: url(../images/green.png) top right repeat-x;
+ background-color: #597800;
+}
+
+div.important div.admonition_header {
+ background: url(../images/yellow.png) top right repeat-x;
+ background-color: #a6710f;
+}
+
+div.warning p, div.warning div.para,
+div.note p, div.note div.para,
+div.important p, div.important div.para {
+ padding: 0em;
+ margin: 0em;
+}
+
+div.admonition {
+ border: none;
+ border-left: 1px solid #aaaaaa;
+ border-right: 1px solid #aaaaaa;
+ padding:0em;
+ margin:0em;
+ padding-top: 1.5em;
+ padding-bottom: 1em;
+ padding-left: 2em;
+ padding-right: 1em;
+ background-color: #eeeeec;
+ -moz-border-radius: 0px;
+ -webkit-border-radius: 0px;
+ border-radius: 0px;
+}
+
+/*Page Title*/
+#title {
+ display:block;
+ height:45px;
+ padding-bottom:1em;
+ margin:0em;
+}
+
+#title a.left{
+ display:inline;
+ border:none;
+}
+
+#title a.left img{
+ border:none;
+ float:left;
+ margin:0em;
+ margin-top:.7em;
+}
+
+#title a.right {
+ padding-bottom:1em;
+}
+
+#title a.right img {
+ border:none;
+ float:right;
+ margin:0em;
+ margin-top:.7em;
+}
+
+/*Table*/
+div.table {
+ page-break-inside: avoid;
+}
+
+table {
+ border:1px solid #6c614b;
+ width:100%;
+ border-collapse:collapse;
+}
+
+table.simplelist, .calloutlist table {
+ border-style: none;
+}
+
+table th {
+ text-align:left;
+ background-color:#6699cc;
+ padding:.3em .5em;
+ color:white;
+}
+
+table td {
+ padding:.15em .5em;
+}
+
+table tr.even td {
+ background-color:#f5f5f5;
+}
+
+table th p:first-child, table td p:first-child, table li p:first-child,
+table th div.para:first-child, table td div.para:first-child, table li div.para:first-child {
+ margin-top:0em;
+ padding-top:0em;
+ display:inline;
+}
+
+th, td {
+ border-style:none;
+ vertical-align: top;
+ border: 1px solid #000;
+}
+
+.simplelist th, .simplelist td {
+ border: none;
+}
+
+table table td {
+ border-bottom:1px dotted #aaa;
+ background-color:white;
+ padding:.6em 0em;
+}
+
+table table {
+ border:1px solid white;
+}
+
+td.remarkval {
+ color:#444;
+}
+
+td.fieldval {
+ font-weight:bold;
+}
+
+.lbname, .lbtype, .lbdescr, .lbdriver, .lbhost {
+ color:white;
+ font-weight:bold;
+ background-color:#999;
+ width:120px;
+}
+
+td.remarkval {
+ width:230px;
+}
+
+td.tname {
+ font-weight:bold;
+}
+
+th.dbfield {
+ width:120px;
+}
+
+th.dbtype {
+ width:70px;
+}
+
+th.dbdefault {
+ width:70px;
+}
+
+th.dbnul {
+ width:70px;
+}
+
+th.dbkey {
+ width:70px;
+}
+
+span.book {
+ margin-top:4em;
+ display:block;
+ font-size:11pt;
+}
+
+span.book a{
+ font-weight:bold;
+}
+span.chapter {
+ display:block;
+ margin-top:0.5em;
+}
+
+table.simplelist td, .calloutlist table td {
+ border-style: none;
+}
+
+/*Breadcrumbs*/
+#breadcrumbs ul li.first:before {
+ content:" ";
+}
+
+#breadcrumbs {
+ color:#900;
+ padding:3px;
+ margin-bottom:25px;
+}
+
+#breadcrumbs ul {
+ margin-left:0;
+ padding-left:0;
+ display:inline;
+ border:none;
+}
+
+#breadcrumbs ul li {
+ margin-left:0;
+ padding-left:2px;
+ border:none;
+ list-style:none;
+ display:inline;
+}
+
+#breadcrumbs ul li:before {
+ content:"\0020 \0020 \0020 \00BB \0020";
+ color:#333;
+}
+
+/*index*/
+.glossary h3,
+.index h3 {
+ font-size: 2em;
+ color:#aaa;
+ margin:0em;
+}
+
+.indexdiv {
+ margin-bottom:1em;
+}
+
+.glossary dt,
+.index dt {
+ color:#444;
+ padding-top:.5em;
+}
+
+.glossary dl dl dt,
+.index dl dl dt {
+ color:#777;
+ font-weight:normal;
+ padding-top:0em;
+}
+
+.index dl dl dt:before {
+ content:"- ";
+ color:#ccc;
+}
+
+/*changes*/
+.footnote {
+ font-size: .7em;
+ margin:0em;
+ color:#222;
+}
+
+table .footnote {
+}
+
+sup {
+ color:#999;
+ margin:0em;
+ padding:0em;
+ line-height: .4em;
+ font-size: 1em;
+ padding-left:0em;
+}
+
+.footnote {
+ position:relative;
+}
+
+.footnote sup {
+ color:#e3dcc0;
+ position:absolute;
+ left: .4em;
+}
+
+.footnote sup a:link,
+.footnote sup a:visited {
+ color:#92917d;
+ text-decoration:none;
+}
+
+.footnote:hover sup a {
+ text-decoration:none;
+}
+
+.footnote p,.footnote div.para {
+ padding-left:2em;
+}
+
+.footnote a:link,
+.footnote a:visited {
+ color:#00537c;
+}
+
+.footnote a:hover {
+}
+
+/**/
+div.chapter {
+ margin-top:3em;
+ page-break-inside: avoid;
+}
+
+div.preface {
+ page-break-inside: avoid;
+}
+
+div.section {
+ margin-top:1em;
+ page-break-inside: auto;
+}
+
+div.note .replaceable,
+div.important .replaceable,
+div.warning .replaceable,
+div.note .keycap,
+div.important .keycap,
+div.warning .keycap
+{
+}
+
+ul li p:last-child, ul li div.para:last-child {
+ margin-bottom:0em;
+ padding-bottom:0em;
+}
+
+/*document navigation*/
+.docnav a, .docnav strong {
+ border:none;
+ text-decoration:none;
+ font-weight:normal;
+}
+
+.docnav {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+ position:relative;
+ width:100%;
+ padding-bottom:2em;
+ padding-top:1em;
+ border-top:1px dotted #ccc;
+}
+
+.docnav li {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+ display:inline;
+ font-size:.8em;
+}
+
+.docnav li:before {
+ content:" ";
+}
+
+.docnav li.previous, .docnav li.next {
+ position:absolute;
+ top:1em;
+}
+
+.docnav li.up, .docnav li.home {
+ margin:0em 1.5em;
+}
+
+.docnav li.previous {
+ left:0px;
+ text-align:left;
+}
+
+.docnav li.next {
+ right:0px;
+ text-align:right;
+}
+
+.docnav li.previous strong, .docnav li.next strong {
+ height:22px;
+ display:block;
+}
+
+.docnav {
+ margin:0 auto;
+ text-align:center;
+}
+
+.docnav li.next a strong {
+ background: url(../images/stock-go-forward.png) top right no-repeat;
+ padding-top:3px;
+ padding-bottom:4px;
+ padding-right:28px;
+ font-size:1.2em;
+}
+
+.docnav li.previous a strong {
+ background: url(../images/stock-go-back.png) top left no-repeat;
+ padding-top:3px;
+ padding-bottom:4px;
+ padding-left:28px;
+ padding-right:0.5em;
+ font-size:1.2em;
+}
+
+.docnav li.home a strong {
+ background: url(../images/stock-home.png) top left no-repeat;
+ padding:5px;
+ padding-left:28px;
+ font-size:1.2em;
+}
+
+.docnav li.up a strong {
+ background: url(../images/stock-go-up.png) top left no-repeat;
+ padding:5px;
+ padding-left:28px;
+ font-size:1.2em;
+}
+
+.docnav a:link, .docnav a:visited {
+ color:#666;
+}
+
+.docnav a:hover, .docnav a:focus, .docnav a:active {
+ color:black;
+}
+
+.docnav a {
+ max-width: 10em;
+ overflow:hidden;
+}
+
+.docnav a:link strong {
+ text-decoration:none;
+}
+
+.docnav {
+ margin:0 auto;
+ text-align:center;
+}
+
+ul.docnav {
+ margin-bottom: 1em;
+}
+/* Reports */
+.reports ul {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+}
+
+.reports li{
+ margin:0em;
+ padding:0em;
+}
+
+.reports li.odd {
+ background-color: #eeeeee;
+ margin:0em;
+ padding:0em;
+}
+
+.reports dl {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ float:right;
+ margin-right: 17em;
+ margin-top:-1.3em;
+}
+
+.reports dt {
+ display:inline;
+ margin:0em;
+ padding:0em;
+}
+
+.reports dd {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ padding-right:.5em;
+}
+
+.reports h2, .reports h3{
+ display:inline;
+ padding-right:.5em;
+ font-size:10pt;
+ font-weight:normal;
+}
+
+.reports div.progress {
+ display:inline;
+ float:right;
+ width:16em;
+ background:#c00 url(../images/shine.png) top left repeat-x;
+ margin:0em;
+ margin-top:-1.3em;
+ padding:0em;
+ border:none;
+}
+
+/*uniform*/
+body.results, body.reports {
+ max-width:57em ;
+ padding:0em;
+}
+
+/*Progress Bar*/
+div.progress {
+ display:block;
+ float:left;
+ width:16em;
+ background:#c00 url(../images/shine.png) top left repeat-x;
+ height:1em;
+}
+
+div.progress span {
+ height:1em;
+ float:left;
+}
+
+div.progress span.translated {
+ background:#6c3 url(../images/shine.png) top left repeat-x;
+}
+
+div.progress span.fuzzy {
+ background:#ff9f00 url(../images/shine.png) top left repeat-x;
+}
+
+
+/*Results*/
+
+.results ul {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+}
+
+.results li{
+ margin:0em;
+ padding:0em;
+}
+
+.results li.odd {
+ background-color: #eeeeee;
+ margin:0em;
+ padding:0em;
+}
+
+.results dl {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ float:right;
+ margin-right: 17em;
+ margin-top:-1.3em;
+}
+
+.results dt {
+ display:inline;
+ margin:0em;
+ padding:0em;
+}
+
+.results dd {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ padding-right:.5em;
+}
+
+.results h2, .results h3 {
+ display:inline;
+ padding-right:.5em;
+ font-size:10pt;
+ font-weight:normal;
+}
+
+.results div.progress {
+ display:inline;
+ float:right;
+ width:16em;
+ background:#c00 url(../images/shine.png) top left repeat-x;
+ margin:0em;
+ margin-top:-1.3em;
+ padding:0em;
+ border:none;
+}
+
+/* Dirty EVIL Mozilla hack for round corners */
+pre {
+ -moz-border-radius:11px;
+ -webkit-border-radius:11px;
+ border-radius: 11px;
+ page-break-inside: avoid;
+}
+
+.example {
+ -moz-border-radius:0px;
+ -webkit-border-radius:0px;
+ border-radius: 0px;
+ page-break-inside: avoid;
+}
+
+.package, .citetitle {
+ font-style: italic;
+}
+
+.titlepage .edition {
+ color: #336699;
+ background-color: transparent;
+ margin-top: 1em;
+ margin-bottom: 1em;
+ font-size: 1.4em;
+ font-weight: bold;
+ text-align: center;
+}
+
+span.remark {
+ background-color: #ff00ff;
+}
+
+.draft {
+ background-image: url(../images/watermark-draft.png);
+ background-repeat: repeat-y;
+ background-position: center;
+}
+
+.foreignphrase {
+ font-style: inherit;
+}
+
+dt {
+ clear:both;
+}
+
+dt img {
+ border-style: none;
+ max-width: 112px;
+}
+
+dt object {
+ max-width: 112px;
+}
+
+dt .inlinemediaobject, dt object {
+ display: inline;
+ float: left;
+ margin-bottom: 1em;
+ padding-right: 1em;
+ width: 112px;
+}
+
+dl:after {
+ display: block;
+ clear: both;
+ content: "";
+}
+
+.toc dd {
+ padding-bottom: 0em;
+ margin-bottom: 1em;
+ padding-left: 1.3em;
+ margin-left: 0em;
+}
+
+div.toc > dl > dt {
+ padding-bottom: 0em;
+ margin-bottom: 0em;
+ margin-top: 1em;
+}
+
+
+.strikethrough {
+ text-decoration: line-through;
+}
+
+.underline {
+ text-decoration: underline;
+}
+
+.calloutlist img, .callout {
+ padding: 0em;
+ margin: 0em;
+ width: 12pt;
+ display: inline;
+ vertical-align: middle;
+}
+
+.stepalternatives {
+ list-style-image: none;
+ list-style-type: none;
+}
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/css/default.css b/docs/runbook/tmp/en-US/xml/Common_Content/css/default.css
new file mode 100644
index 00000000000..bf38ebb5931
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/css/default.css
@@ -0,0 +1,3 @@
+@import url("common.css");
+@import url("overrides.css");
+@import url("lang.css");
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/css/lang.css b/docs/runbook/tmp/en-US/xml/Common_Content/css/lang.css
new file mode 100644
index 00000000000..81c3115605a
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/css/lang.css
@@ -0,0 +1,2 @@
+/* place holder */
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/css/overrides.css b/docs/runbook/tmp/en-US/xml/Common_Content/css/overrides.css
new file mode 100644
index 00000000000..ebd9730b690
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/css/overrides.css
@@ -0,0 +1,57 @@
+a:link {
+ color:#0066cc;
+}
+
+a:visited {
+ color:#6699cc;
+}
+
+h1 {
+ color:#3c6eb4;
+}
+
+.producttitle {
+ background: #3c6eb4 url(../images/h1-bg.png) top left repeat;
+}
+
+.section h1.title {
+ color:#3c6eb4;
+}
+
+
+h2,h3,h4,h5,h6 {
+ color:#3c6eb4
+}
+
+table {
+ border:1px solid #3c6eb4;
+}
+
+table th {
+ background-color:#3c6eb4;
+}
+
+table tr.even td {
+ background-color:#f5f5f5;
+}
+
+#title a {
+ height:54px;
+}
+
+.term{
+ color:#a70000;
+}
+
+.revhistory table th {
+ color:#3c6eb4;
+}
+
+.edition {
+ color: #3c6eb4;
+}
+
+span.remark{
+ background-color: #ffff00;
+}
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/css/print.css b/docs/runbook/tmp/en-US/xml/Common_Content/css/print.css
new file mode 100644
index 00000000000..773d8ae1b1c
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/css/print.css
@@ -0,0 +1,16 @@
+@import url("common.css");
+@import url("overrides.css");
+@import url("lang.css");
+
+#tocframe {
+ display: none;
+}
+
+body.toc_embeded {
+ margin-left: 30px;
+}
+
+.producttitle {
+ color: #336699;
+}
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/1.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/1.png
new file mode 100644
index 00000000000..ef0beba8510
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/1.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/1.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/1.svg
new file mode 100644
index 00000000000..4c6bf579527
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/1.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/10.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/10.png
new file mode 100644
index 00000000000..05f22391ea7
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/10.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/10.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/10.svg
new file mode 100644
index 00000000000..0edda5b6fa6
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/10.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/11.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/11.png
new file mode 100644
index 00000000000..32b4a04831e
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/11.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/11.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/11.svg
new file mode 100644
index 00000000000..c95afcc14a1
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/11.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/12.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/12.png
new file mode 100644
index 00000000000..45fa4892a94
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/12.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/12.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/12.svg
new file mode 100644
index 00000000000..e3c3fd66c7d
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/12.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/13.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/13.png
new file mode 100644
index 00000000000..0b766d3f87b
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/13.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/13.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/13.svg
new file mode 100644
index 00000000000..35b4969143d
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/13.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/14.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/14.png
new file mode 100644
index 00000000000..2e1d73716c2
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/14.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/14.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/14.svg
new file mode 100644
index 00000000000..832f816799a
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/14.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/15.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/15.png
new file mode 100644
index 00000000000..7d21c66bb04
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/15.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/15.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/15.svg
new file mode 100644
index 00000000000..830d65439c6
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/15.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/16.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/16.png
new file mode 100644
index 00000000000..ff396af2fa6
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/16.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/16.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/16.svg
new file mode 100644
index 00000000000..24d1eea0458
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/16.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/17.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/17.png
new file mode 100644
index 00000000000..f1ba68a7f60
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/17.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/17.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/17.svg
new file mode 100644
index 00000000000..7796bd1d7db
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/17.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/18.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/18.png
new file mode 100644
index 00000000000..df920d02515
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/18.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/18.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/18.svg
new file mode 100644
index 00000000000..356f207eefb
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/18.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/19.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/19.png
new file mode 100644
index 00000000000..bda9a8c559d
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/19.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/19.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/19.svg
new file mode 100644
index 00000000000..385378074ed
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/19.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/2.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/2.png
new file mode 100644
index 00000000000..b95445a4e73
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/2.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/2.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/2.svg
new file mode 100644
index 00000000000..236a8dacbc4
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/2.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/20.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/20.png
new file mode 100644
index 00000000000..c30191a3653
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/20.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/20.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/20.svg
new file mode 100644
index 00000000000..d41206eec57
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/20.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/21.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/21.png
new file mode 100644
index 00000000000..fa3aa907dcf
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/21.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/21.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/21.svg
new file mode 100644
index 00000000000..b17f23a5a9a
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/21.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/22.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/22.png
new file mode 100644
index 00000000000..b724ced1311
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/22.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/22.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/22.svg
new file mode 100644
index 00000000000..22deeb3edbb
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/22.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/23.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/23.png
new file mode 100644
index 00000000000..8b69b829282
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/23.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/23.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/23.svg
new file mode 100644
index 00000000000..c0a33eeb0b0
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/23.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/24.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/24.png
new file mode 100644
index 00000000000..863ce3b6632
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/24.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/24.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/24.svg
new file mode 100644
index 00000000000..27e1d39c94f
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/24.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/25.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/25.png
new file mode 100644
index 00000000000..cc23b9b2b04
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/25.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/25.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/25.svg
new file mode 100644
index 00000000000..114e1a26ba6
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/25.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/26.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/26.png
new file mode 100644
index 00000000000..583fe34867d
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/26.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/26.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/26.svg
new file mode 100644
index 00000000000..e9b5d239b55
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/26.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/27.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/27.png
new file mode 100644
index 00000000000..d1c3dfa457a
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/27.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/27.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/27.svg
new file mode 100644
index 00000000000..4a80177b68d
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/27.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/28.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/28.png
new file mode 100644
index 00000000000..f5db74735d7
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/28.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/28.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/28.svg
new file mode 100644
index 00000000000..d453f299fa2
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/28.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/29.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/29.png
new file mode 100644
index 00000000000..9a3141ec42e
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/29.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/29.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/29.svg
new file mode 100644
index 00000000000..04b5c5034fc
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/29.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/3.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/3.png
new file mode 100644
index 00000000000..a4754f0615c
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/3.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/3.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/3.svg
new file mode 100644
index 00000000000..e2f17168da1
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/3.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/30.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/30.png
new file mode 100644
index 00000000000..9d3db242d90
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/30.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/30.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/30.svg
new file mode 100644
index 00000000000..5cdcf65e846
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/30.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/31.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/31.png
new file mode 100644
index 00000000000..9e2675da589
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/31.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/31.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/31.svg
new file mode 100644
index 00000000000..f0fdb294dd8
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/31.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/32.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/32.png
new file mode 100644
index 00000000000..20f1bb23c4b
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/32.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/32.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/32.svg
new file mode 100644
index 00000000000..93829281032
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/32.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/33.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/33.png
new file mode 100644
index 00000000000..01407e6bcce
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/33.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/33.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/33.svg
new file mode 100644
index 00000000000..f46815f7ea6
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/33.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/34.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/34.png
new file mode 100644
index 00000000000..ba443525397
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/34.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/34.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/34.svg
new file mode 100644
index 00000000000..7bbdf5b9ab2
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/34.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/35.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/35.png
new file mode 100644
index 00000000000..21d4575cf27
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/35.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/35.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/35.svg
new file mode 100644
index 00000000000..8e19553af20
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/35.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/36.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/36.png
new file mode 100644
index 00000000000..b5402b57788
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/36.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/36.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/36.svg
new file mode 100644
index 00000000000..d364dbf51bb
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/36.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/37.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/37.png
new file mode 100644
index 00000000000..9fd99d22058
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/37.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/37.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/37.svg
new file mode 100644
index 00000000000..771fa4d110b
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/37.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/38.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/38.png
new file mode 100644
index 00000000000..3ce6027f00f
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/38.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/38.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/38.svg
new file mode 100644
index 00000000000..487e0ef3051
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/38.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/39.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/39.png
new file mode 100644
index 00000000000..d6894500c24
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/39.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/39.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/39.svg
new file mode 100644
index 00000000000..cea69f715f9
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/39.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/4.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/4.png
new file mode 100644
index 00000000000..f6c113563a1
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/4.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/4.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/4.svg
new file mode 100644
index 00000000000..3b537d4a19b
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/4.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/40.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/40.png
new file mode 100644
index 00000000000..0d3532e0f3f
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/40.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/40.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/40.svg
new file mode 100644
index 00000000000..bb4e1d7b8fc
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/40.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/5.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/5.png
new file mode 100644
index 00000000000..4ced5472dfc
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/5.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/5.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/5.svg
new file mode 100644
index 00000000000..ec2715dea0b
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/5.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/6.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/6.png
new file mode 100644
index 00000000000..22fc272c050
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/6.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/6.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/6.svg
new file mode 100644
index 00000000000..b8062936898
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/6.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/7.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/7.png
new file mode 100644
index 00000000000..9b1f20a9816
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/7.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/7.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/7.svg
new file mode 100644
index 00000000000..871e0eff74f
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/7.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/8.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/8.png
new file mode 100644
index 00000000000..ac38ae5bffd
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/8.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/8.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/8.svg
new file mode 100644
index 00000000000..10e612f6eb9
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/8.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/9.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/9.png
new file mode 100644
index 00000000000..a2972dbc216
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/9.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/9.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/9.svg
new file mode 100644
index 00000000000..c488b6e4fa4
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/9.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/dot.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/dot.png
new file mode 100644
index 00000000000..079add95ded
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/dot.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/dot2.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/dot2.png
new file mode 100644
index 00000000000..8348fcd054a
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/dot2.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/green.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/green.png
new file mode 100644
index 00000000000..ebb3c247dea
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/green.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/h1-bg.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/h1-bg.png
new file mode 100644
index 00000000000..a2aad24b329
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/h1-bg.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/image_left.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/image_left.png
new file mode 100644
index 00000000000..2831477642c
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/image_left.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/image_right.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/image_right.png
new file mode 100644
index 00000000000..19a6cca5336
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/image_right.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/important.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/important.png
new file mode 100644
index 00000000000..969562b7bc7
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/important.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/important.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/important.svg
new file mode 100644
index 00000000000..064c783b538
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/important.svg
@@ -0,0 +1,30 @@
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/note.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/note.png
new file mode 100644
index 00000000000..d04775d9905
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/note.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/note.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/note.svg
new file mode 100644
index 00000000000..abe5a602468
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/note.svg
@@ -0,0 +1,28 @@
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/red.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/red.png
new file mode 100644
index 00000000000..d32d5e2e80a
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/red.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/shine.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/shine.png
new file mode 100644
index 00000000000..a18f7c4612e
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/shine.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-go-back.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-go-back.png
new file mode 100644
index 00000000000..00850b21b23
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-go-back.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-go-forward.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-go-forward.png
new file mode 100644
index 00000000000..cc2797a4686
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-go-forward.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-go-up.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-go-up.png
new file mode 100644
index 00000000000..1ebf2799c35
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-go-up.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-home.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-home.png
new file mode 100644
index 00000000000..3f0c1906343
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/stock-home.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/title_logo.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/title_logo.png
new file mode 100644
index 00000000000..58a1b56cfe8
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/title_logo.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/title_logo.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/title_logo.svg
new file mode 100644
index 00000000000..e8b3eca8d82
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/title_logo.svg
@@ -0,0 +1,335 @@
+
+
+
+
\ No newline at end of file
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/warning.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/warning.png
new file mode 100644
index 00000000000..94b69d1ff1f
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/warning.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/warning.svg b/docs/runbook/tmp/en-US/xml/Common_Content/images/warning.svg
new file mode 100644
index 00000000000..4231e5ac041
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Common_Content/images/warning.svg
@@ -0,0 +1,130 @@
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/watermark-draft.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/watermark-draft.png
new file mode 100644
index 00000000000..0ead5af8bb8
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/watermark-draft.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Common_Content/images/yellow.png b/docs/runbook/tmp/en-US/xml/Common_Content/images/yellow.png
new file mode 100644
index 00000000000..223865d77fa
Binary files /dev/null and b/docs/runbook/tmp/en-US/xml/Common_Content/images/yellow.png differ
diff --git a/docs/runbook/tmp/en-US/xml/Environment.xml b/docs/runbook/tmp/en-US/xml/Environment.xml
new file mode 100644
index 00000000000..93b765d72ce
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Environment.xml
@@ -0,0 +1,248 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Environment
+
+ Before you begin, you need to prepare the environment before you install CloudStack. We will go over the steps to prepare now.
+
+
+ Operating System
+
+ Using the CentOS 6.2 x86_64 minimal install ISO, you'll need to install CentOS on your hardware. The defaults will generally be acceptable for this installation.
+
+
+ Once this installation is complete, you'll want to connect to your freshly installed machine via SSH as the root user. Note that you should not allow root logins in a production environment, so be sure to turn off remote logins once you have finished the installation and configuration.
+
+
+ Configuring the network
+
+ By default the network will not come up on your hardware and you will need to configure it to work in your environment. Since we specified that there will be no DHCP server in this environment we will be manually configuring your network interface. We will assume, for the purposes of this exercise, that eth0 is the only network interface that will be connected and used.
+
+
+ Connecting via the console you should login as root. Check the file /etc/sysconfig/network-scripts/ifcfg-eth0, it will look like this by default:
+
+DEVICE="eth0"
+HWADDR="52:54:00:B9:A6:C0"
+NM_CONTROLLED="yes"
+ONBOOT="no"
+
+
+
+
+ Unfortunately, this configuration will not permit you to connect to the network, and is also unsuitable for our purposes with CloudStack. We want to configure that file so that it specifies the IP address, netmask, etc., as shown in the following example:
+
+
+ Hardware Addresses
+
+ You should not use the hardware address (aka MAC address) from our example for your configuration. It is network interface specific, so you should keep the address already provided in the HWADDR directive.
+
+
+
+
+
+DEVICE=eth0
+HWADDR=52:54:00:B9:A6:C0
+NM_CONTROLLED=no
+ONBOOT=yes
+BOOTPROTO=none
+IPADDR=172.16.10.2
+NETMASK=255.255.255.0
+GATEWAY=172.16.10.1
+DNS1=8.8.8.8
+DNS2=8.8.4.4
+
+
+ IP Addressing
+
+ Throughout this document we are assuming that you will have a /24 network for your CloudStack implementation. This can be any RFC 1918 network. However, we are assuming that you will match the machine address that we are using. Thus we may use 172.16.10.2 and because you might be using the 192.168.55.0/24 network you would use 192.168.55.2
+
+
+
+
+ Now that we have the configuration files properly set up, we need to run a few commands to start up the network
+
+
+# chkconfig network on
+
+# service network start
+
+
+
+
+ Hostname
+
+ Cloudstack requires that the hostname be properly set. If you used the default options in the installation, then your hostname is currently set to localhost.localdomain. To test this we will run:
+
+
+# hostname --fqdn
+
+ At this point it will likely return:
+
+
+localhost
+
+ To rectify this situation - we'll set the hostname by editing the /etc/hosts file so that it follows a similar format to this example:
+
+127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
+172.16.10.2 srvr1.cloud.priv
+
+
+
+
+ After you've modified that file, go ahead and restart the network using:
+
+
+# service network restart
+
+ Now recheck with the hostname --fqdn command and ensure that it returns a FQDN response
+
+
+
+
+
+ SELinux
+
+ At the moment, for CloudStack to work properly SELinux must be set to permissive. We want to both configure this for future boots and modify it in the current running system.
+
+
+ To configure SELinux to be permissive in the running system we need to run the following command:
+
+
+# setenforce 0
+
+ To ensure that it remains in that state we need to configure the file /etc/selinux/config to reflect the permissive state, as shown in this example:
+
+
+
+
+# This file controls the state of SELinux on the system.
+# SELINUX= can take one of these three values:
+# enforcing - SELinux security policy is enforced.
+# permissive - SELinux prints warnings instead of enforcing.
+# disabled - No SELinux policy is loaded.
+SELINUX=permissive
+# SELINUXTYPE= can take one of these two values:
+# targeted - Targeted processes are protected,
+# mls - Multi Level Security protection.
+SELINUXTYPE=targeted
+
+
+
+
+
+ NTP
+
+ NTP configuration is a necessity for keeping all of the clocks in your cloud servers in sync. However, NTP is not installed by default. So we'll install and and configure NTP at this stage. Installation is accomplished as follows:
+
+
+# yum install ntp
+
+ The actual default configuration is fine for our purposes, so we merely need to enable it and set it to start on boot as follows:
+
+
+# chkconfig ntpd on
+
+# service ntpd start
+
+
+
+
+
+
+
+ NFS
+
+ Our configuration is going to use NFS for both primary and secondary storage. We are going to go ahead and setup two NFS shares for those purposes. We'll start out by installing nfs-utils.
+
+
+# yum install nfs-utils
+
+ We now need to configure NFS to serve up two different shares. This is handled comparatively easily in the /etc/exports file. You should ensure that it has the following content:
+
+
+
+/secondary *(rw,async,no_root_squash)
+/primary *(rw,async,no_root_squash)
+
+
+ You will note that we specified two directories that don't exist (yet) on the system. We'll go ahead and create those directories and set permissions appropriately on them with the following commands:
+
+
+
+# mkdir /primary
+# mkdir /secondary
+
+
+ CentOS 6.x releases use NFSv4 by default. NFSv4 requires that domain setting matches on all clients. In our case, the domain is cloud.priv, so ensure that the domain setting in /etc/idmapd.conf is uncommented and set as follows:
+
+
+Domain = cloud.priv
+
+ Now you'll need uncomment the configuration values in the file /etc/sysconfig/nfs
+
+
+
+LOCKD_TCPPORT=32803
+LOCKD_UDPPORT=32769
+MOUNTD_PORT=892
+RQUOTAD_PORT=875
+STATD_PORT=662
+STATD_OUTGOING_PORT=2020
+
+
+ Now we need to configure the firewall to permit incoming NFS connections. Edit the file /etc/sysconfig/iptables
+
+
+
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT
+
+
+ Now you can restart the iptables service with the following command:
+
+
+# service iptables restart
+
+ We now need to configure nfs service to start on boot and actually start it on the host by executing the following commands:
+
+
+
+ # service rpcbind start
+ # service nfs start
+ # chkconfig rpcbind on
+ # chkconfig nfs on
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Management.xml b/docs/runbook/tmp/en-US/xml/Management.xml
new file mode 100644
index 00000000000..8cbd8f87d34
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Management.xml
@@ -0,0 +1,125 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Installation of the management server
+
+ Now it is time to start installing CloudStack's management server and some of the related components.
+
+
+ Database Installation and Configuration
+
+ We'll start out by installing MySQL and configuring some options to ensure CloudStack runs well.
+
+
+ To install MySQL run the following command:
+# yum -y install mysql-server
+
+
+
+ With MySQL installed we need to make a few configuration changes to /etc/my.cnf. Specifically we need to add the following options to the [mysqld] section:
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=350
+log-bin=mysql-bin
+binlog-format = 'ROW'
+
+
+
+
+ Now that MySQL is properly configured we can start it and configure it to start on boot as follows:
+
+ # service mysqld start
+ # chkconfig mysqld on
+
+
+
+
+
+
+
+ Extraction
+
+ The next step is to extract the contents of the CloudStack tarball (mentioned in ) you downloaded previously. To extract the contents of this tarball use the following command:
+
+
+
+ # tar -xzvf CloudStack-oss-3.0.2-1-rhel6.2.tar.gz
+
+
+ For the next few sections you'll need to cd into the first level that was just created.
+
+
+
+
+
+ Installation
+
+ Now that you are in the directory created by extracting the tarball, it's now time to install. We'll run ./install.sh and choose option . This will install the management server and necessary dependencies.
+
+
+ With the application itself installed we can now setup the database, we'll do that with the following command and options:
+
+
+
+ # cloud-setup-databases cloud:password@localhost --deploy-as=root
+
+
+ When this process is finished, you should see a message like "CloudStack has successfully initialized the database."
+
+
+ Now that the database has been created, we can take the final step in setting up the management server by issuing the following command:
+
+
+
+ # cloud-setup-mangament
+
+
+
+
+
+ System Template Setup
+
+ CloudStack uses a number of system VMs to provide functionality for accessing the console of virtual machines, providing various networking services, and managing various aspects of storage. This step will acquire those system images ready for deployment when we bootstrap your cloud.
+
+
+ The place we are going to download these images to is the secondary storage share that we setup earlier, so we'll need to mount that share with the mount command run on the management server:
+
+
+
+ # mount -t nfs 172.16.10.2:/secondary /mnt/secondary
+
+
+ Now we need to download the system VM template and deploy that to the share we just mounted. The management server includes a script to properly manipulate the system VMs images.
+
+
+
+ # /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -F
+
+
+ That concludes our setup of the management server. We still need to configure CloudStack, but we will do that after we get our hypervisor set up.
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Overview.xml b/docs/runbook/tmp/en-US/xml/Overview.xml
new file mode 100644
index 00000000000..05b6e8d6126
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Overview.xml
@@ -0,0 +1,87 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Overview
+
+ Infrastructure-as-a-Service (IaaS) clouds can be a complex thing to build, and by definition they have a plethora of options, which often lead to confusion for even experienced admins who are newcomers to building cloud platforms. The goal for this runbook is to provide a straightforward set of instructions to get you up and running with CloudStack with a minimum amount of trouble.
+
+
+ What exactly are we building?
+
+ This runbook will focus on building a CloudStack cloud using KVM with CentOS 6.2 with NFS storage on a flat layer-2 network utilizing layer-3 network isolation (aka Security Groups), and doing it all on a single piece of hardware.
+
+
+ KVM, or Kernel-based Virtual Machine is a virtualization technology for the Linux kernel. KVM supports native virtualization atop processors with hardware virtualization extensions.
+
+
+ Security Groups act as distributed firewalls that control access to a group of virtual machines.
+
+
+
+
+
+ High level overview of the process
+
+ Before we actually get to installing CloudStack, we'll start with installing our base operating system, and then configuring that to act as an NFS server for several types of storage. We'll install the management server, download the systemVMs, and finally install the agent software. Finally we'll spend a good deal of time configuring the entire cloud in the CloudStack web interface.
+
+
+
+
+
+ Prerequisites
+
+ To complete this runbook you'll need the following items:
+
+
+
+ At least one computer which supports hardware virtualization.
+
+
+
+
+
+ The CentOS 6.2 x86_64 minimal install CD
+
+
+
+
+
+ A /24 network with the gateway being at xxx.xxx.xxx.1, no DHCP should be on this network and none of the computers running CloudStack may have a dynamic address.
+
+
+
+
+
+ Copy of CloudStack 3.0.2 for RHEL and CentOS 6.2
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Preface.xml b/docs/runbook/tmp/en-US/xml/Preface.xml
new file mode 100644
index 00000000000..556e2121d28
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Preface.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Preface
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Revision_History.xml b/docs/runbook/tmp/en-US/xml/Revision_History.xml
new file mode 100644
index 00000000000..1927b3c5510
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Revision_History.xml
@@ -0,0 +1,43 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Revision History
+
+
+
+ 0-0
+ Mon Jun 25 2012
+
+
+ Initial creation of book by publican
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Runbook.ent b/docs/runbook/tmp/en-US/xml/Runbook.ent
new file mode 100644
index 00000000000..cdc00b05f62
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Runbook.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Runbook.fo b/docs/runbook/tmp/en-US/xml/Runbook.fo
new file mode 100644
index 00000000000..96b05a6d61c
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Runbook.fo
@@ -0,0 +1,416 @@
+
+Runbook - Prescriptive instructions for deploying Apache CloudStackDocBook XSL Stylesheets with Apache FOPRunbookTable of ContentsPreface1. Document Conventions1.1. Typographic Conventions1.2. Pull-quote Conventions1.3. Notes and Warnings2. We Need Feedback!Chapter 1. Overview1.1. What exactly are we building?1.2. High level overview of the process1.3. PrerequisitesChapter 2. Environment2.1. Operating System2.1.1. Configuring the network2.1.2. Hostname2.1.3. SELinux2.1.4. NTP2.2. NFSChapter 3. Installation of the management server3.1. Database Installation and Configuration3.2. Extraction3.3. Installation3.4. System Template SetupChapter 4. KVM Setup and installation4.1. Prerequisites4.2. Installation4.3. KVM ConfigurationChapter 5. Configuration5.1. UI Access5.2. Setting up a Zone5.3. Pod Configuration5.4. Cluster5.4.1. Primary Storage5.4.2. Secondary StorageAppendix A. Revision HistoryRunbookApache CloudStack 3.0.2RunbookPrescriptive instructions for deploying Apache CloudStack
+
+
+ Apache CloudStackApache CloudStack 3.0.2 RunbookPrescriptive instructions for deploying Apache CloudStackEdition 0AuthorApache CloudStack
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+ These runbooks are designed to provide a strict environment to guarantee a higher degree of success in initial deployments of Apache CloudStack. All of the elements of the environment will be provided to you. Apache CloudStack is capable of much more complex configurations, but they are beyond the scope of this document.
+ RunbookPreface1. Document Conventions1.1. Typographic Conventions1.2. Pull-quote Conventions1.3. Notes and Warnings2. We Need Feedback!1. Overview1.1. What exactly are we building?1.2. High level overview of the process1.3. Prerequisites2. Environment2.1. Operating System2.1.1. Configuring the network2.1.2. Hostname2.1.3. SELinux2.1.4. NTP2.2. NFS3. Installation of the management server3.1. Database Installation and Configuration3.2. Extraction3.3. Installation3.4. System Template Setup4. KVM Setup and installation4.1. Prerequisites4.2. Installation4.3. KVM Configuration5. Configuration5.1. UI Access5.2. Setting up a Zone5.3. Pod Configuration5.4. Cluster5.4.1. Primary Storage5.4.2. Secondary StorageA. Revision HistoryPrefacePrefaceDocument Conventions1. Document Conventions
+ This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.
+
+ In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts11https://fedorahosted.org/liberation-fonts/ set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default.
+ Typographic Conventions1.1. Typographic Conventions
+ Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.
+
+ Mono-spaced Bold
+
+ Used to highlight system input, including shell commands, file names and paths. Also used to highlight keycaps and key combinations. For example:
+
+ To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.
+
+ The above includes a file name, a shell command and a keycap, all presented in mono-spaced bold and all distinguishable thanks to context.
+
+ Key combinations can be distinguished from keycaps by the hyphen connecting each part of a key combination. For example:
+
+ Press Enter to execute the command.
+
+ Press Ctrl+Alt+F2 to switch to the first virtual terminal. Press Ctrl+Alt+F1 to return to your X-Windows session.
+
+ The first paragraph highlights the particular keycap to press. The second highlights two key combinations (each a set of three keycaps with each set pressed simultaneously).
+
+ If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:
+
+ File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.
+
+ Proportional Bold
+
+ This denotes words or phrases encountered on a system, including application names; dialog box text; labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:
+
+ Choose System → Preferences → Mouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
+
+ To insert a special character into a gedit file, choose Applications → Accessories → Character Map from the main menu bar. Next, choose Search → Find… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose Edit → Paste from the gedit menu bar.
+
+ The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context.
+
+ Mono-spaced Bold Italic or Proportional Bold Italic
+
+ Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
+
+ To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.
+
+ The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.
+
+ To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.
+
+ Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
+
+ Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
+
+ Publican is a DocBook publishing system.
+ Pull-quote Conventions1.2. Pull-quote Conventions
+ Terminal output and source code listings are set off visually from the surrounding text.
+
+ Output sent to a terminal is set in mono-spaced roman and presented thus:
+ books Desktop documentation drafts mss photos stuff svn
+books_tests Desktop1 downloads images notes scripts svgs
+ Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:
+ package org.jboss.book.jca.ex1;
+
+import javax.naming.InitialContext;
+
+publicclass ExClient
+{
+ publicstaticvoidmain(String args[])
+ throws Exception
+ {
+ InitialContext iniCtx = new InitialContext();
+ Object ref = iniCtx.lookup("EchoBean");
+ EchoHome home = (EchoHome) ref;
+ Echo echo = home.create();
+
+ System.out.println("Created Echo");
+
+ System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
+ }
+}Notes and Warnings1.3. Notes and Warnings
+ Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.
+ Note
+ Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.
+ Important
+ Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled 'Important' will not cause data loss but may cause irritation and frustration.
+ Warning
+ Warnings should not be ignored. Ignoring warnings will most likely cause data loss.
+ We Need Feedback!2. We Need Feedback!
+ If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a bug: http://bugs.cloudstack.org against the component Doc
+
+ If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.
+ Chapter 1.Chapter 1. OverviewOverview
+ Infrastructure-as-a-Service (IaaS) clouds can be a complex thing to build, and by definition they have a plethora of options, which often lead to confusion for even experienced admins who are newcomers to building cloud platforms. The goal for this runbook is to provide a straightforward set of instructions to get you up and running with CloudStack with a minimum amount of trouble.
+ What exactly are we building?1.1. What exactly are we building?
+ This runbook will focus on building a CloudStack cloud using KVM with CentOS 6.2 with NFS storage on a flat layer-2 network utilizing layer-3 network isolation (aka Security Groups), and doing it all on a single piece of hardware.
+
+ KVM, or Kernel-based Virtual Machine is a virtualization technology for the Linux kernel. KVM supports native virtualization atop processors with hardware virtualization extensions.
+
+ Security Groups act as distributed firewalls that control access to a group of virtual machines.
+ High level overview of the process1.2. High level overview of the process
+ Before we actually get to installing CloudStack, we'll start with installing our base operating system, and then configuring that to act as an NFS server for several types of storage. We'll install the management server, download the systemVMs, and finally install the agent software. Finally we'll spend a good deal of time configuring the entire cloud in the CloudStack web interface.
+ Prerequisites1.3. Prerequisites
+ To complete this runbook you'll need the following items:
+ 1.
+ At least one computer which supports hardware virtualization.
+ 2.
+ The CentOS 6.2 x86_64 minimal install CD 11http://mirrors.kernel.org/centos/6.2/isos/x86_64/CentOS-6.2-x86_64-minimal.iso
+ 3.
+ A /24 network with the gateway being at xxx.xxx.xxx.1, no DHCP should be on this network and none of the computers running CloudStack may have a dynamic address.
+ 4.
+ Copy of CloudStack 3.0.2 for RHEL and CentOS 6.2 22http://sourceforge.net/projects/cloudstack/files/CloudStack%20Acton/3.0.2/CloudStack-oss-3.0.2-1-rhel6.2.tar.gz/download
+
+
+ Chapter 2.Chapter 2. EnvironmentEnvironment
+ Before you begin, you need to prepare the environment before you install CloudStack. We will go over the steps to prepare now.
+ Operating System2.1. Operating System
+ Using the CentOS 6.2 x86_64 minimal install ISO, you'll need to install CentOS on your hardware. The defaults will generally be acceptable for this installation.
+
+ Once this installation is complete, you'll want to connect to your freshly installed machine via SSH as the root user. Note that you should not allow root logins in a production environment, so be sure to turn off remote logins once you have finished the installation and configuration.
+ Configuring the network2.1.1. Configuring the network
+ By default the network will not come up on your hardware and you will need to configure it to work in your environment. Since we specified that there will be no DHCP server in this environment we will be manually configuring your network interface. We will assume, for the purposes of this exercise, that eth0 is the only network interface that will be connected and used.
+
+ Connecting via the console you should login as root. Check the file /etc/sysconfig/network-scripts/ifcfg-eth0, it will look like this by default:
+
+DEVICE="eth0"
+HWADDR="52:54:00:B9:A6:C0"
+NM_CONTROLLED="yes"
+ONBOOT="no"
+
+
+
+ Unfortunately, this configuration will not permit you to connect to the network, and is also unsuitable for our purposes with CloudStack. We want to configure that file so that it specifies the IP address, netmask, etc., as shown in the following example:
+ Hardware Addresses
+ You should not use the hardware address (aka MAC address) from our example for your configuration. It is network interface specific, so you should keep the address already provided in the HWADDR directive.
+
+DEVICE=eth0
+HWADDR=52:54:00:B9:A6:C0
+NM_CONTROLLED=no
+ONBOOT=yes
+BOOTPROTO=none
+IPADDR=172.16.10.2
+NETMASK=255.255.255.0
+GATEWAY=172.16.10.1
+DNS1=8.8.8.8
+DNS2=8.8.4.4
+IP Addressing
+ Throughout this document we are assuming that you will have a /24 network for your CloudStack implementation. This can be any RFC 1918 network. However, we are assuming that you will match the machine address that we are using. Thus we may use 172.16.10.2 and because you might be using the 192.168.55.0/24 network you would use 192.168.55.2
+
+ Now that we have the configuration files properly set up, we need to run a few commands to start up the network
+ # chkconfig network on# service network startHostname2.1.2. Hostname
+ Cloudstack requires that the hostname be properly set. If you used the default options in the installation, then your hostname is currently set to localhost.localdomain. To test this we will run:
+ # hostname --fqdn
+ At this point it will likely return:
+ localhost
+ To rectify this situation - we'll set the hostname by editing the /etc/hosts file so that it follows a similar format to this example:
+
+127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
+172.16.10.2 srvr1.cloud.priv
+
+
+
+ After you've modified that file, go ahead and restart the network using:
+ # service network restart
+ Now recheck with the hostname --fqdn command and ensure that it returns a FQDN response
+ SELinux2.1.3. SELinux
+ At the moment, for CloudStack to work properly SELinux must be set to permissive. We want to both configure this for future boots and modify it in the current running system.
+
+ To configure SELinux to be permissive in the running system we need to run the following command:
+ # setenforce 0
+ To ensure that it remains in that state we need to configure the file /etc/selinux/config to reflect the permissive state, as shown in this example:
+
+
+# This file controls the state of SELinux on the system.
+# SELINUX= can take one of these three values:
+# enforcing - SELinux security policy is enforced.
+# permissive - SELinux prints warnings instead of enforcing.
+# disabled - No SELinux policy is loaded.
+SELINUX=permissive
+# SELINUXTYPE= can take one of these two values:
+# targeted - Targeted processes are protected,
+# mls - Multi Level Security protection.
+SELINUXTYPE=targeted
+NTP2.1.4. NTP
+ NTP configuration is a necessity for keeping all of the clocks in your cloud servers in sync. However, NTP is not installed by default. So we'll install and and configure NTP at this stage. Installation is accomplished as follows:
+ # yum install ntp
+ The actual default configuration is fine for our purposes, so we merely need to enable it and set it to start on boot as follows:
+ # chkconfig ntpd on# service ntpd startNFS2.2. NFS
+ Our configuration is going to use NFS for both primary and secondary storage. We are going to go ahead and setup two NFS shares for those purposes. We'll start out by installing nfs-utils.
+ # yum install nfs-utils
+ We now need to configure NFS to serve up two different shares. This is handled comparatively easily in the /etc/exports file. You should ensure that it has the following content:
+
+/secondary *(rw,async,no_root_squash)
+/primary *(rw,async,no_root_squash)
+
+ You will note that we specified two directories that don't exist (yet) on the system. We'll go ahead and create those directories and set permissions appropriately on them with the following commands:
+
+# mkdir /primary
+# mkdir /secondary
+
+ CentOS 6.x releases use NFSv4 by default. NFSv4 requires that domain setting matches on all clients. In our case, the domain is cloud.priv, so ensure that the domain setting in /etc/idmapd.conf is uncommented and set as follows:
+ Domain = cloud.priv
+ Now you'll need uncomment the configuration values in the file /etc/sysconfig/nfs
+
+LOCKD_TCPPORT=32803
+LOCKD_UDPPORT=32769
+MOUNTD_PORT=892
+RQUOTAD_PORT=875
+STATD_PORT=662
+STATD_OUTGOING_PORT=2020
+
+ Now we need to configure the firewall to permit incoming NFS connections. Edit the file /etc/sysconfig/iptables
+
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT
+
+ Now you can restart the iptables service with the following command:
+ # service iptables restart
+ We now need to configure nfs service to start on boot and actually start it on the host by executing the following commands:
+
+ # service rpcbind start
+ # service nfs start
+ # chkconfig rpcbind on
+ # chkconfig nfs on
+Chapter 3.Chapter 3. Installation of the management serverInstallation of the management server
+ Now it is time to start installing CloudStack's management server and some of the related components.
+ Database Installation and Configuration3.1. Database Installation and Configuration
+ We'll start out by installing MySQL and configuring some options to ensure CloudStack runs well.
+
+ To install MySQL run the following command:
+# yum -y install mysql-server
+
+
+ With MySQL installed we need to make a few configuration changes to /etc/my.cnf. Specifically we need to add the following options to the [mysqld] section:
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=350
+log-bin=mysql-bin
+binlog-format = 'ROW'
+
+
+
+ Now that MySQL is properly configured we can start it and configure it to start on boot as follows:
+
+ # service mysqld start
+ # chkconfig mysqld on
+
+
+ Extraction3.2. Extraction
+ The next step is to extract the contents of the CloudStack tarball (mentioned in Section 1.3, “Prerequisites”) you downloaded previously. To extract the contents of this tarball use the following command:
+
+ # tar -xzvf CloudStack-oss-3.0.2-1-rhel6.2.tar.gz
+
+ For the next few sections you'll need to cd into the first level that was just created.
+ Installation3.3. Installation
+ Now that you are in the directory created by extracting the tarball, it's now time to install. We'll run ./install.sh and choose option M. This will install the management server and necessary dependencies.
+
+ With the application itself installed we can now setup the database, we'll do that with the following command and options:
+
+ # cloud-setup-databases cloud:password@localhost --deploy-as=root
+
+ When this process is finished, you should see a message like "CloudStack has successfully initialized the database."
+
+ Now that the database has been created, we can take the final step in setting up the management server by issuing the following command:
+
+ # cloud-setup-mangament
+System Template Setup3.4. System Template Setup
+ CloudStack uses a number of system VMs to provide functionality for accessing the console of virtual machines, providing various networking services, and managing various aspects of storage. This step will acquire those system images ready for deployment when we bootstrap your cloud.
+
+ The place we are going to download these images to is the secondary storage share that we setup earlier, so we'll need to mount that share with the mount command run on the management server:
+
+ # mount -t nfs 172.16.10.2:/secondary /mnt/secondary
+
+ Now we need to download the system VM template and deploy that to the share we just mounted. The management server includes a script to properly manipulate the system VMs images.
+
+ # /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -F
+
+ That concludes our setup of the management server. We still need to configure CloudStack, but we will do that after we get our hypervisor set up.
+ Chapter 4.Chapter 4. KVM Setup and installationKVM Setup and installation
+ KVM is the hypervisor we'll be using - we will recover the initial setup which has already been done on the hypervisor host and cover installation of the agent software, you can use the same steps to add additional KVM nodes to your CloudStack environment.
+ Prerequisites4.1. Prerequisites
+ We explicitly are using the management server as a compute node as well, which means that we have already performed many of the prerequisite steps when setting up the management server, but we will list them here for clarity. Those steps are:
+ 1.
+ Section 2.1.1, “Configuring the network”
+ 2.
+ Section 2.1.2, “Hostname”
+ 3.
+ Section 2.1.3, “SELinux”
+ 4.
+ Section 2.1.4, “NTP”
+
+
+
+ You shouldn't need to do that for the management server, of course, but any additional hosts will need for you to complete the above steps.
+ Installation4.2. Installation
+ You'll need to ensure that you are in the directory that was created when we extracted the the tarball. Section 3.2, “Extraction”
+
+ You'll be running ./install.sh again and this time choosing A which will install the software necessary for managing a KVM node.
+ KVM Configuration4.3. KVM Configuration
+ KVM configuration is relatively simple at only a single item. We need to edit the QEMU VNC configuration. This is done by editing /etc/libvirt/qemu.conf and ensuring the following line is present and uncommented.
+vnc_listen=0.0.0.0
+
+
+ You can now just restart the libvirt daemon by issuing the following command:
+# service libvirt restart
+
+
+ That concludes our installation and configuration of KVM, and we'll now move to using the CloudStack UI for the actual configuration of our cloud.
+ Chapter 5.Chapter 5. ConfigurationConfiguration
+ As we noted before we will be using security groups to provide isolation and by default that implies that we'll be using a flat layer-2 network. It also means that the simplicity of our setup means that we can use the quick installer.
+ UI Access5.1. UI Access
+ To get access to CloudStack's web interface, merely point your browser to http://172.16.10.2:8080/client The default username is 'admin', and the default password is 'password'. You should see a splash screen that allows you to choose several options for setting up CloudStack. You should choose the Continue with Basic Setup option.
+
+ You should now see a prompt requiring you to change the password for the admin user. Please do so.
+ Setting up a Zone5.2. Setting up a Zone
+ A zone is the largest organization entity in CloudStack - and we'll be creating one, this should be the screen that you see in front of you now. And for us there are 5 pieces of information that we need.
+ 1.
+ Name - we will set this to the ever-descriptive 'Zone1' for our cloud.
+ 2.
+ Public DNS 1 - we will set this to '8.8.8.8' for our cloud.
+ 3.
+ Public DNS 2 - we will set this to '8.8.4.4' for our cloud.
+ 4.
+ Internal DNS1 - we will also set this to '8.8.8.8' for our cloud.
+ 5.
+ Internal DNS2 - we will also set this to '8.8.8.4' for our cloud.
+
+
+ Notes about DNS settings
+ CloudStack distinguishes between internal and public DNS. Internal DNS is assumed to be capable of resolving internal-only hostnames, such as your NFS server’s DNS name. Public DNS is provided to the guest VMs to resolve public IP addresses. You can enter the same DNS server for both types, but if you do so, you must make sure that both internal and public IP addresses can route to the DNS server. In our specific case we will not use any names for resources internally, and we have indeed them set to look to the same external resource so as to not add a namerserver setup to our list of requirements.
+ Pod Configuration5.3. Pod Configuration
+ Now that we've added a Zone, the next step that comes up is a prompt for information regading a pod. Which is looking for 4 items.
+ 1.
+ Name - We'll use Pod1 for our cloud.
+ 2.
+ Gateway - We'll use 172.16.10.1 as our gateway
+ 3.
+ Netmask - We'll use 255.255.255.0
+ 4.
+ Start/end reserved system IPs - we will use 172.16.10.10-172.16.10.20
+ 5.
+ Guest gateway - We'll use 172.16.10.1
+ 6.
+ Guest netmask - We'll use 255.255.255.0
+ 7.
+ Guest start/end IP - We'll use 172.16.10.30-172.16.10.200
+
+
+ Cluster5.4. Cluster
+ Now that we've added a Zone, we need only add a few more items for configuring the cluster.
+ 1.
+ Name - We'll use Cluster1
+ 2.
+ Hypervisor - Choose KVM
+
+
+
+ You should be prompted to add the first host to your cluster at this point. Only a few bits of information are needed.
+ 1.
+ Hostname - we'll use the IP address 172.16.10.2 since we didn't set up a DNS server.
+ 2.
+ Username - we'll use 'root'
+ 3.
+ Password - enter the operating system password for the root user
+
+
+ Primary Storage5.4.1. Primary Storage
+ With you cluster now setup - you should be prompted for primary storage information. Choose NFS as the storage type and then enter the following values in the fields:
+ 1.
+ Name - We'll use 'Primary1'
+ 2.
+ Server - We'll be using the IP address 172.16.10.2
+ 3.
+ Path - Well define /primary as the path we are using
+
+
+ Secondary Storage5.4.2. Secondary Storage
+ If this is a new zone, you'll be prompted for secondary storage information - populate it as follows:
+ 1.
+ NFS server - We'll use the IP address 172.16.10.2
+ 2.
+ Path - We'll use /secondary
+
+
+
+ Now, click Launch and your cloud should begin setup - it may take several minutes depending on your internet connection speed for setup to finalize.
+ Appendix A. Revision HistoryAppendix A. Revision History
+ Revision 0-0Mon Jun 25 2012
+ Initial creation of book by publican
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/Runbook.xml b/docs/runbook/tmp/en-US/xml/Runbook.xml
new file mode 100644
index 00000000000..cf200cff74f
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/Runbook.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/config.xml b/docs/runbook/tmp/en-US/xml/config.xml
new file mode 100644
index 00000000000..ce6bf16a2d9
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/config.xml
@@ -0,0 +1,249 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configuration
+
+ As we noted before we will be using security groups to provide isolation and by default that implies that we'll be using a flat layer-2 network. It also means that the simplicity of our setup means that we can use the quick installer.
+
+
+ UI Access
+
+ To get access to CloudStack's web interface, merely point your browser to http://172.16.10.2:8080/client The default username is 'admin', and the default password is 'password'. You should see a splash screen that allows you to choose several options for setting up CloudStack. You should choose the option.
+
+
+ You should now see a prompt requiring you to change the password for the admin user. Please do so.
+
+
+
+
+
+ Setting up a Zone
+
+ A zone is the largest organization entity in CloudStack - and we'll be creating one, this should be the screen that you see in front of you now. And for us there are 5 pieces of information that we need.
+
+
+
+ Name - we will set this to the ever-descriptive 'Zone1' for our cloud.
+
+
+
+
+
+ Public DNS 1 - we will set this to '8.8.8.8' for our cloud.
+
+
+
+
+
+ Public DNS 2 - we will set this to '8.8.4.4' for our cloud.
+
+
+
+
+
+ Internal DNS1 - we will also set this to '8.8.8.8' for our cloud.
+
+
+
+
+
+ Internal DNS2 - we will also set this to '8.8.8.4' for our cloud.
+
+
+
+
+
+
+
+
+ Notes about DNS settings
+
+ CloudStack distinguishes between internal and public DNS. Internal DNS is assumed to be capable of resolving internal-only hostnames, such as your NFS server’s DNS name. Public DNS is provided to the guest VMs to resolve public IP addresses. You can enter the same DNS server for both types, but if you do so, you must make sure that both internal and public IP addresses can route to the DNS server. In our specific case we will not use any names for resources internally, and we have indeed them set to look to the same external resource so as to not add a namerserver setup to our list of requirements.
+
+
+
+
+
+
+
+ Pod Configuration
+
+ Now that we've added a Zone, the next step that comes up is a prompt for information regading a pod. Which is looking for 4 items.
+
+
+
+ Name - We'll use Pod1 for our cloud.
+
+
+
+
+
+ Gateway - We'll use 172.16.10.1 as our gateway
+
+
+
+
+
+ Netmask - We'll use 255.255.255.0
+
+
+
+
+
+ Start/end reserved system IPs - we will use 172.16.10.10-172.16.10.20
+
+
+
+
+
+ Guest gateway - We'll use 172.16.10.1
+
+
+
+
+
+ Guest netmask - We'll use 255.255.255.0
+
+
+
+
+
+ Guest start/end IP - We'll use 172.16.10.30-172.16.10.200
+
+
+
+
+
+
+
+
+
+
+
+ Cluster
+
+ Now that we've added a Zone, we need only add a few more items for configuring the cluster.
+
+
+
+ Name - We'll use Cluster1
+
+
+
+
+
+ Hypervisor - Choose KVM
+
+
+
+
+
+
+
+
+ You should be prompted to add the first host to your cluster at this point. Only a few bits of information are needed.
+
+
+
+ Hostname - we'll use the IP address 172.16.10.2 since we didn't set up a DNS server.
+
+
+
+
+
+ Username - we'll use 'root'
+
+
+
+
+
+ Password - enter the operating system password for the root user
+
+
+
+
+
+
+
+
+ Primary Storage
+
+ With you cluster now setup - you should be prompted for primary storage information. Choose NFS as the storage type and then enter the following values in the fields:
+
+
+
+ Name - We'll use 'Primary1'
+
+
+
+
+
+ Server - We'll be using the IP address 172.16.10.2
+
+
+
+
+
+ Path - Well define /primary as the path we are using
+
+
+
+
+
+
+
+
+
+
+
+ Secondary Storage
+
+ If this is a new zone, you'll be prompted for secondary storage information - populate it as follows:
+
+
+
+ NFS server - We'll use the IP address 172.16.10.2
+
+
+
+
+
+ Path - We'll use /secondary
+
+
+
+
+
+
+
+
+ Now, click Launch and your cloud should begin setup - it may take several minutes depending on your internet connection speed for setup to finalize.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml/kvm.xml b/docs/runbook/tmp/en-US/xml/kvm.xml
new file mode 100644
index 00000000000..b60e3537ad4
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml/kvm.xml
@@ -0,0 +1,97 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ KVM Setup and installation
+
+ KVM is the hypervisor we'll be using - we will recover the initial setup which has already been done on the hypervisor host and cover installation of the agent software, you can use the same steps to add additional KVM nodes to your CloudStack environment.
+
+
+ Prerequisites
+
+ We explicitly are using the management server as a compute node as well, which means that we have already performed many of the prerequisite steps when setting up the management server, but we will list them here for clarity. Those steps are:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ You shouldn't need to do that for the management server, of course, but any additional hosts will need for you to complete the above steps.
+
+
+
+
+
+ Installation
+
+ You'll need to ensure that you are in the directory that was created when we extracted the the tarball.
+
+
+ You'll be running ./install.sh again and this time choosing which will install the software necessary for managing a KVM node.
+
+
+
+
+
+ KVM Configuration
+
+ KVM configuration is relatively simple at only a single item. We need to edit the QEMU VNC configuration. This is done by editing /etc/libvirt/qemu.conf and ensuring the following line is present and uncommented.
+vnc_listen=0.0.0.0
+
+
+
+ You can now just restart the libvirt daemon by issuing the following command:
+# service libvirt restart
+
+
+
+ That concludes our installation and configuration of KVM, and we'll now move to using the CloudStack UI for the actual configuration of our cloud.
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Author_Group.xml b/docs/runbook/tmp/en-US/xml_tmp/Author_Group.xml
new file mode 100644
index 00000000000..ba9e651f876
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Author_Group.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+ Apache
+ CloudStack
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Book_Info.xml b/docs/runbook/tmp/en-US/xml_tmp/Book_Info.xml
new file mode 100644
index 00000000000..ec591446856
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Book_Info.xml
@@ -0,0 +1,52 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ Runbook
+ Prescriptive instructions for deploying Apache CloudStack
+ Apache CloudStack
+ 3.0.2
+ 0
+ 0
+
+
+ These runbooks are designed to provide a strict environment to guarantee
+ a higher degree of success in initial deployments of Apache CloudStack.
+ All of the elements of the environment will be provided to you.
+ Apache CloudStack is capable of much more complex configurations,
+ but they are beyond the scope of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Chapter.xml b/docs/runbook/tmp/en-US/xml_tmp/Chapter.xml
new file mode 100644
index 00000000000..4adf63c207a
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Chapter.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ Test Chapter
+
+ This is a test paragraph
+
+
+ Test Section 1
+
+ This is a test paragraph in a section
+
+
+
+
+ Test Section 2
+
+ This is a test paragraph in Section 2
+
+
+
+ listitem text
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Environment.xml b/docs/runbook/tmp/en-US/xml_tmp/Environment.xml
new file mode 100644
index 00000000000..781e05de182
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Environment.xml
@@ -0,0 +1,235 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ Environment
+
+ Before you begin, you need to prepare the environment before you install CloudStack.
+ We will go over the steps to prepare now.
+
+
+ Operating System
+
+ Using the CentOS 6.2 x86_64 minimal install ISO, you'll need to install CentOS
+ on your hardware. The defaults will generally be acceptable for this installation.
+
+
+ Once this installation is complete, you'll want to connect to your freshly
+ installed machine via SSH as the root user. Note that you should not allow root
+ logins in a production environment, so be sure to turn off remote logins once you
+ have finished the installation and configuration.
+
+
+ Configuring the network
+
+ By default the network will not come up on your hardware and you
+ will need to configure it to work in your environment. Since we
+ specified that there will be no DHCP server in this environment
+ we will be manually configuring your network interface. We will
+ assume, for the purposes of this exercise, that eth0 is the only network
+ interface that will be connected and used.
+
+
+ Connecting via the console you should login as root. Check the
+ file /etc/sysconfig/network-scripts/ifcfg-eth0,
+ it will look like this by default:
+
+DEVICE="eth0"
+HWADDR="52:54:00:B9:A6:C0"
+NM_CONTROLLED="yes"
+ONBOOT="no"
+
+
+
+ Unfortunately, this configuration will not permit you to connect to the network,
+ and is also unsuitable for our purposes with CloudStack. We want to
+ configure that file so that it specifies the IP address, netmask, etc., as shown
+ in the following example:
+
+
+ Hardware Addresses
+ You should not use the hardware address (aka MAC address) from our example
+ for your configuration. It is network interface specific, so you should keep the
+ address already provided in the HWADDR directive.
+
+
+
+DEVICE=eth0
+HWADDR=52:54:00:B9:A6:C0
+NM_CONTROLLED=no
+ONBOOT=yes
+BOOTPROTO=none
+IPADDR=172.16.10.2
+NETMASK=255.255.255.0
+GATEWAY=172.16.10.1
+DNS1=8.8.8.8
+DNS2=8.8.4.4
+
+
+ IP Addressing
+ Throughout this document we are assuming that you will
+ have a /24 network for your CloudStack implementation. This can be any
+ RFC 1918 network. However, we are assuming that you will match the
+ machine address that we are using. Thus we may use
+ 172.16.10.2 and because
+ you might be using the 192.168.55.0/24 network you would use
+ 192.168.55.2
+
+
+ Now that we have the configuration files properly set up, we need to run a
+ few commands to start up the network
+ # chkconfig network on
+ # service network start
+
+
+ Hostname
+
+ Cloudstack requires that the hostname be properly set. If you used the default
+ options in the installation, then your hostname is currently set to
+ localhost.localdomain. To test this we will run:
+ # hostname --fqdn
+ At this point it will likely return:
+ localhost
+ To rectify this situation - we'll set the hostname by editing the
+ /etc/hosts file so that it follows a similar format to this example:
+127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
+172.16.10.2 srvr1.cloud.priv
+
+
+ After you've modified that file, go ahead and restart the network using:
+# service network restart
+ Now recheck with the hostname --fqdn command and ensure that it returns
+ a FQDN response
+
+
+ SELinux
+ At the moment, for CloudStack to work properly SELinux must be
+ set to permissive. We want to both configure this for future boots and modify it
+ in the current running system.
+
+ To configure SELinux to be permissive in the running system we need to run
+ the following command:
+ # setenforce 0
+
+ To ensure that it remains in that state we need to configure the file
+ /etc/selinux/config to reflect the permissive state,
+ as shown in this example:
+
+
+# This file controls the state of SELinux on the system.
+# SELINUX= can take one of these three values:
+# enforcing - SELinux security policy is enforced.
+# permissive - SELinux prints warnings instead of enforcing.
+# disabled - No SELinux policy is loaded.
+SELINUX=permissive
+# SELINUXTYPE= can take one of these two values:
+# targeted - Targeted processes are protected,
+# mls - Multi Level Security protection.
+SELINUXTYPE=targeted
+
+
+
+
+ NTP
+ NTP configuration is a necessity for keeping all of the clocks in your cloud
+ servers in sync. However, NTP is not installed by default. So we'll install and
+ and configure NTP at this stage. Installation is accomplished as follows:
+
+ # yum install ntp
+ The actual default configuration is fine for our purposes, so we merely need to
+ enable it and set it to start on boot as follows:
+ # chkconfig ntpd on
+ # service ntpd start
+
+
+
+ NFS
+
+ Our configuration is going to use NFS for both primary and secondary
+ storage. We are going to go ahead and setup two NFS shares for those
+ purposes. We'll start out by installing
+ nfs-utils.
+
+ # yum install nfs-utils
+
+ We now need to configure NFS to serve up two different shares. This is handled comparatively easily
+ in the /etc/exports file. You should ensure that it has the following content:
+
+
+/secondary *(rw,async,no_root_squash)
+/primary *(rw,async,no_root_squash)
+
+
+ You will note that we specified two directories that don't exist (yet) on the system.
+ We'll go ahead and create those directories and set permissions appropriately on them with the following commands:
+
+
+# mkdir /primary
+# mkdir /secondary
+
+ CentOS 6.x releases use NFSv4 by default. NFSv4 requires that domain setting matches on all clients.
+ In our case, the domain is cloud.priv, so ensure that the domain setting in /etc/idmapd.conf
+ is uncommented and set as follows:
+ Domain = cloud.priv
+ Now you'll need uncomment the configuration values in the file /etc/sysconfig/nfs
+
+LOCKD_TCPPORT=32803
+LOCKD_UDPPORT=32769
+MOUNTD_PORT=892
+RQUOTAD_PORT=875
+STATD_PORT=662
+STATD_OUTGOING_PORT=2020
+
+ Now we need to configure the firewall to permit incoming NFS connections.
+ Edit the file /etc/sysconfig/iptables
+
+
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT
+-A INPUT -s 172.16.10.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT
+
+ Now you can restart the iptables service with the following command:
+
+ # service iptables restart
+ We now need to configure nfs service to start on boot and actually start it on the host by
+ executing the following commands:
+
+ # service rpcbind start
+ # service nfs start
+ # chkconfig rpcbind on
+ # chkconfig nfs on
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Management.xml b/docs/runbook/tmp/en-US/xml_tmp/Management.xml
new file mode 100644
index 00000000000..0df2bf118f9
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Management.xml
@@ -0,0 +1,127 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ Installation of the management server
+
+ Now it is time to start installing CloudStack's management server
+ and some of the related components.
+
+
+ Database Installation and Configuration
+
+ We'll start out by installing MySQL and configuring
+ some options to ensure CloudStack runs well.
+
+
+ To install MySQL run the following command:
+ # yum -y install mysql-server
+
+ With MySQL installed we need to make
+ a few configuration changes to /etc/my.cnf.
+ Specifically we need to add the following options to the [mysqld] section:
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=350
+log-bin=mysql-bin
+binlog-format = 'ROW'
+
+
+
+ Now that MySQL is properly configured we can
+ start it and configure it to start on boot as follows:
+
+ # service mysqld start
+ # chkconfig mysqld on
+
+
+
+
+
+
+ Extraction
+
+ The next step is to extract the contents of the CloudStack tarball
+ (mentioned in ) you
+ downloaded previously. To extract the contents of this tarball use
+ the following command:
+
+
+ # tar -xzvf CloudStack-oss-3.0.2-1-rhel6.2.tar.gz
+
+ For the next few sections you'll need to cd into the first level that was just created.
+
+
+
+ Installation
+ Now that you are in the directory created by extracting the tarball, it's now time to install. We'll run
+ ./install.sh and choose option . This will install the management server
+ and necessary dependencies.
+
+ With the application itself installed we can now setup the database, we'll do that with the following command
+ and options:
+
+
+ # cloud-setup-databases cloud:password@localhost --deploy-as=root
+
+ When this process is finished, you should see a message like "CloudStack has successfully initialized the database."
+
+ Now that the database has been created, we can take the final step in setting up the management server by issuing the following command:
+
+ # cloud-setup-mangament
+
+
+
+ System Template Setup
+ CloudStack uses a number of system VMs to provide functionality for
+ accessing the console of virtual machines, providing various networking
+ services, and managing various aspects of storage. This step will
+ acquire those system images ready for deployment when we bootstrap
+ your cloud.
+
+
+ The place we are going to download these images to is the secondary
+ storage share that we setup earlier, so we'll need to mount that share
+ with the mount command run on the management server:
+
+
+ # mount -t nfs 172.16.10.2:/secondary /mnt/secondary
+
+
+ Now we need to download the system VM template and deploy that to the
+ share we just mounted. The management server includes a script to properly
+ manipulate the system VMs images.
+
+
+ # /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -F
+
+
+ That concludes our setup of the management server. We still need to
+ configure CloudStack, but we will do that after we get our hypervisor
+ set up.
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Overview.xml b/docs/runbook/tmp/en-US/xml_tmp/Overview.xml
new file mode 100644
index 00000000000..f69798fdb67
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Overview.xml
@@ -0,0 +1,100 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ Overview
+
+ Infrastructure-as-a-Service (IaaS) clouds can be a complex thing to build,
+ and by definition they have a plethora of options, which often lead to confusion
+ for even experienced admins who are newcomers to building cloud platforms.
+ The goal for this runbook is to provide a straightforward set of instructions
+ to get you up and running with CloudStack with a minimum amount of trouble.
+
+
+ What exactly are we building?
+
+ This runbook will focus on building a CloudStack cloud using KVM with
+ CentOS 6.2 with NFS storage on a flat layer-2 network utilizing
+ layer-3 network isolation (aka Security Groups), and doing it all
+ on a single piece of hardware.
+
+
+ KVM, or Kernel-based Virtual Machine is a virtualization technology
+ for the Linux kernel. KVM supports native virtualization atop
+ processors with hardware virtualization extensions.
+
+
+ Security Groups act as distributed firewalls that control access
+ to a group of virtual machines.
+
+
+
+ High level overview of the process
+
+ Before we actually get to installing CloudStack, we'll start with
+ installing our base operating system, and then configuring that to act
+ as an NFS server for several types of storage. We'll install the
+ management server, download the systemVMs, and finally install the agent
+ software. Finally we'll spend a good deal of time configuring the entire
+ cloud in the CloudStack web interface.
+
+
+
+ Prerequisites
+
+ To complete this runbook you'll need the following items:
+
+
+
+ At least one computer which supports hardware virtualization.
+
+
+
+
+ The
+
+ CentOS 6.2 x86_64 minimal install CD
+
+
+
+
+
+ A /24 network with the gateway being at xxx.xxx.xxx.1, no DHCP should be on this network and
+ none of the computers running CloudStack may have a dynamic address.
+
+
+
+
+ Copy of
+
+ CloudStack 3.0.2 for RHEL and CentOS 6.2
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Preface.xml b/docs/runbook/tmp/en-US/xml_tmp/Preface.xml
new file mode 100644
index 00000000000..7a622674443
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Preface.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ Preface
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Revision_History.xml b/docs/runbook/tmp/en-US/xml_tmp/Revision_History.xml
new file mode 100644
index 00000000000..4aecafd1d66
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Revision_History.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ Revision History
+
+
+
+ 0-0
+ Mon Jun 25 2012
+
+
+ Initial creation of book by publican
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Runbook.ent b/docs/runbook/tmp/en-US/xml_tmp/Runbook.ent
new file mode 100644
index 00000000000..cdc00b05f62
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Runbook.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/Runbook.xml b/docs/runbook/tmp/en-US/xml_tmp/Runbook.xml
new file mode 100644
index 00000000000..11f195ca828
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/Runbook.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/config.xml b/docs/runbook/tmp/en-US/xml_tmp/config.xml
new file mode 100644
index 00000000000..90c34957fb1
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/config.xml
@@ -0,0 +1,177 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ Configuration
+
+ As we noted before we will be using security groups to provide isolation
+ and by default that implies that we'll be using a flat layer-2 network.
+ It also means that the simplicity of our setup means that we can use the
+ quick installer.
+
+
+ UI Access
+
+ To get access to CloudStack's web interface, merely point your
+ browser to http://172.16.10.2:8080/client
+ The default username is 'admin', and the default password is 'password'.
+ You should see a splash screen that allows you to choose several options
+ for setting up CloudStack. You should choose the
+ option.
+
+
+ You should now see a prompt requiring you to change the password for
+ the admin user. Please do so.
+
+
+
+ Setting up a Zone
+
+ A zone is the largest organization entity in CloudStack - and we'll be creating one, this
+ should be the screen that you see in front of you now. And for us there are 5 pieces of
+ information that we need.
+
+
+ Name - we will set this to the ever-descriptive 'Zone1' for our cloud.
+
+
+ Public DNS 1 - we will set this to '8.8.8.8' for our cloud.
+
+
+ Public DNS 2 - we will set this to '8.8.4.4' for our cloud.
+
+
+ Internal DNS1 - we will also set this to '8.8.8.8' for our cloud.
+
+
+ Internal DNS2 - we will also set this to '8.8.8.4' for our cloud.
+
+
+
+
+ Notes about DNS settings
+
+ CloudStack distinguishes between internal and public DNS. Internal
+ DNS is assumed to be capable of resolving internal-only
+ hostnames, such as your NFS server’s DNS name. Public DNS is
+ provided to the guest VMs to resolve public IP addresses. You can
+ enter the same DNS server for both types, but if you do so, you
+ must make sure that both internal and public IP addresses can
+ route to the DNS server. In our specific case we will not use any
+ names for resources internally, and we have indeed them set to look
+ to the same external resource so as to not add a namerserver setup
+ to our list of requirements.
+
+
+
+
+ Pod Configuration
+ Now that we've added a Zone, the next step that comes up is a prompt
+ for information regading a pod. Which is looking for 4 items.
+
+
+ Name - We'll use Pod1 for our cloud.
+
+
+ Gateway - We'll use 172.16.10.1 as our gateway
+
+
+ Netmask - We'll use 255.255.255.0
+
+
+ Start/end reserved system IPs - we will use 172.16.10.10-172.16.10.20
+
+
+ Guest gateway - We'll use 172.16.10.1
+
+
+ Guest netmask - We'll use 255.255.255.0
+
+
+ Guest start/end IP - We'll use 172.16.10.30-172.16.10.200
+
+
+
+
+
+ Cluster
+ Now that we've added a Zone, we need only add a few more items for configuring the cluster.
+
+
+ Name - We'll use Cluster1
+
+
+ Hypervisor - Choose KVM
+
+
+
+ You should be prompted to add the first host to your cluster at this point. Only a few bits of information are needed.
+
+
+ Hostname - we'll use the IP address 172.16.10.2 since we didn't set up a DNS server.
+
+
+ Username - we'll use 'root'
+
+
+ Password - enter the operating system password for the root user
+
+
+
+
+ Primary Storage
+ With you cluster now setup - you should be prompted for primary storage information. Choose NFS as the storage type and then enter the following values in the fields:
+
+
+ Name - We'll use 'Primary1'
+
+
+ Server - We'll be using the IP address 172.16.10.2
+
+
+ Path - Well define /primary as the path we are using
+
+
+
+
+
+ Secondary Storage
+ If this is a new zone, you'll be prompted for secondary storage information - populate it as follows:
+
+
+ NFS server - We'll use the IP address 172.16.10.2
+
+
+ Path - We'll use /secondary
+
+
+
+ Now, click Launch and your cloud should begin setup - it may take several minutes depending on your internet connection speed for setup to finalize.
+
+
+
+
+
+
diff --git a/docs/runbook/tmp/en-US/xml_tmp/kvm.xml b/docs/runbook/tmp/en-US/xml_tmp/kvm.xml
new file mode 100644
index 00000000000..03119496a2c
--- /dev/null
+++ b/docs/runbook/tmp/en-US/xml_tmp/kvm.xml
@@ -0,0 +1,103 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ KVM Setup and installation
+
+ KVM is the hypervisor we'll be using - we will recover the initial setup
+ which has already been done on the hypervisor host and cover installation
+ of the agent software, you can use the same steps to add additional KVM
+ nodes to your CloudStack environment.
+
+
+ Prerequisites
+
+ We explicitly are using the management server as a compute node as well,
+ which means that we have already performed many of the prerequisite steps
+ when setting up the management server, but we will list them here for
+ clarity. Those steps are:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ You shouldn't need to do that for the management server, of course, but
+ any additional hosts will need for you to complete the above steps.
+
+
+
+
+ Installation
+
+ You'll need to ensure that you are in the directory that was created when
+ we extracted the the tarball.
+
+
+
+ You'll be running ./install.sh again and this time
+ choosing which will install the software necessary for
+ managing a KVM node.
+
+
+
+ KVM Configuration
+
+ KVM configuration is relatively simple at only a single item. We need to
+ edit the QEMU VNC configuration. This is done by editing
+ /etc/libvirt/qemu.conf and ensuring the following
+ line is present and uncommented.
+ vnc_listen=0.0.0.0
+
+
+ You can now just restart the libvirt daemon by issuing the following command:
+ # service libvirt restart
+
+
+ That concludes our installation and configuration of KVM, and we'll now move to using the CloudStack UI
+ for the actual configuration of our cloud.
+
+
+
+
+
diff --git a/docs/tmp/en-US/Apache_CloudStack-4.0.0-incubating-Admin_Guide-en-US.epub b/docs/tmp/en-US/Apache_CloudStack-4.0.0-incubating-Admin_Guide-en-US.epub
new file mode 100644
index 00000000000..ed4a19c798b
Binary files /dev/null and b/docs/tmp/en-US/Apache_CloudStack-4.0.0-incubating-Admin_Guide-en-US.epub differ
diff --git a/docs/tmp/en-US/epub/META-INF/container.xml b/docs/tmp/en-US/epub/META-INF/container.xml
new file mode 100644
index 00000000000..ea22bf5a33d
--- /dev/null
+++ b/docs/tmp/en-US/epub/META-INF/container.xml
@@ -0,0 +1,2 @@
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/css/common.css b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/common.css
new file mode 100644
index 00000000000..d7dc3f27be8
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/common.css
@@ -0,0 +1,1528 @@
+* {
+ widows: 2 !important;
+ orphans: 2 !important;
+}
+
+body, h1, h2, h3, h4, h5, h6, pre, li, div {
+ line-height: 1.29em;
+}
+
+body {
+ background-color: white;
+ margin:0 auto;
+ font-family: "liberation sans", "Myriad ", "Bitstream Vera Sans", "Lucida Grande", "Luxi Sans", "Trebuchet MS", helvetica, verdana, arial, sans-serif;
+ font-size:12px;
+ max-width:55em;
+ color:black;
+}
+
+body.toc_embeded {
+ /*for web hosting system only*/
+ margin-left: 300px;
+}
+
+object.toc, iframe.toc {
+ /*for web hosting system only*/
+ border-style:none;
+ position:fixed;
+ width:290px;
+ height:99.99%;
+ top:0;
+ left:0;
+ z-index: 100;
+ border-style:none;
+ border-right:1px solid #999;
+}
+
+/* Hide web menu */
+
+body.notoc {
+ margin-left: 3em;
+}
+
+iframe.notoc {
+ border-style:none;
+ border: none;
+ padding: 0em;
+ position:fixed;
+ width: 21px;
+ height: 29px;
+ top: 0px;
+ left:0;
+ overflow: hidden;
+ margin: 0em;
+ margin-left: -3px;
+}
+/* End hide web menu */
+
+/* desktop styles */
+body.desktop {
+ margin-left: 26em;
+}
+
+body.desktop .book > .toc {
+ display:block;
+ width:24em;
+ height:99%;
+ position:fixed;
+ overflow:auto;
+ top:0px;
+ left:0px;
+ padding-left:1em;
+ background-color:#EEEEEE;
+}
+
+.toc {
+ line-height:1.35em;
+}
+
+.toc .glossary,
+.toc .chapter, .toc .appendix {
+ margin-top:1em;
+}
+
+.toc .part {
+ margin-top:1em;
+ display:block;
+}
+
+span.glossary,
+span.appendix {
+ display:block;
+ margin-top:0.5em;
+}
+
+div {
+ padding-top:0px;
+}
+
+div.section {
+ padding-top:1em;
+}
+
+p, div.para, div.formalpara {
+ padding-top:0px;
+ margin-top:0.3em;
+ padding-bottom:0px;
+ margin-bottom:1em;
+}
+
+/*Links*/
+a {
+ outline: none;
+}
+
+a:link {
+ text-decoration:none;
+ border-bottom: 1px dotted ;
+ color:#3366cc;
+}
+
+a:visited {
+ text-decoration:none;
+ border-bottom: 1px dotted ;
+ color:#003366;
+}
+
+div.longdesc-link {
+ float:right;
+ color:#999;
+}
+
+.toc a, .qandaset a {
+ font-weight:normal;
+ border:none;
+}
+
+.toc a:hover, .qandaset a:hover
+{
+ border-bottom: 1px dotted;
+}
+
+/*headings*/
+h1, h2, h3, h4, h5, h6 {
+ color: #336699;
+ margin-top: 0em;
+ margin-bottom: 0em;
+ background-color: transparent;
+ page-break-inside: avoid;
+ page-break-after: avoid;
+}
+
+h1 {
+ font-size:2.0em;
+}
+
+.titlepage h1.title {
+ font-size: 3.0em;
+ padding-top: 1em;
+ text-align:left;
+}
+
+.book > .titlepage h1.title {
+ text-align:center;
+}
+
+.article > .titlepage h1.title {
+ text-align:center;
+}
+
+.set .titlepage > div > div > h1.title {
+ text-align:center;
+}
+
+.producttitle {
+ margin-top: 0em;
+ margin-bottom: 0em;
+ font-size: 3.0em;
+ font-weight: bold;
+ background: #003d6e url(../images/h1-bg.png) top left repeat-x;
+ color: white;
+ text-align: center;
+ padding: 0.7em;
+}
+
+.titlepage .corpauthor {
+ margin-top: 1em;
+ text-align: center;
+}
+
+.section h1.title {
+ font-size: 1.6em;
+ padding: 0em;
+ color: #336699;
+ text-align: left;
+ background: white;
+}
+
+h2 {
+ font-size:1.6em;
+}
+
+
+h2.subtitle, h3.subtitle {
+ margin-top: 1em;
+ margin-bottom: 1em;
+ font-size: 1.4em;
+ text-align: center;
+}
+
+.preface > div > div > div > h2.title {
+ margin-top: 1em;
+ font-size: 2.0em;
+}
+
+.appendix h2 {
+ margin-top: 1em;
+ font-size: 2.0em;
+}
+
+
+
+h3 {
+ font-size:1.3em;
+ padding-top:0em;
+ padding-bottom:0em;
+}
+h4 {
+ font-size:1.1em;
+ padding-top:0em;
+ padding-bottom:0em;
+}
+
+h5 {
+ font-size:1em;
+}
+
+h6 {
+ font-size:1em;
+}
+
+h5.formalpara {
+ font-size:1em;
+ margin-top:2em;
+ margin-bottom:.8em;
+}
+
+.abstract h6 {
+ margin-top:1em;
+ margin-bottom:.5em;
+ font-size:2em;
+}
+
+/*element rules*/
+hr {
+ border-collapse: collapse;
+ border-style:none;
+ border-top: 1px dotted #ccc;
+ width:100%;
+ margin-top: 3em;
+}
+
+/* web site rules */
+ul.languages, .languages li {
+ display:inline;
+ padding:0em;
+}
+
+.languages li a {
+ padding:0em .5em;
+ text-decoration: none;
+}
+
+.languages li p, .languages li div.para {
+ display:inline;
+}
+
+.languages li a:link, .languages li a:visited {
+ color:#444;
+}
+
+.languages li a:hover, .languages li a:focus, .languages li a:active {
+ color:black;
+}
+
+ul.languages {
+ display:block;
+ background-color:#eee;
+ padding:.5em;
+}
+
+/*supporting stylesheets*/
+
+/*unique to the webpage only*/
+.books {
+ position:relative;
+}
+
+.versions li {
+ width:100%;
+ clear:both;
+ display:block;
+}
+
+a.version {
+ font-size:2em;
+ text-decoration:none;
+ width:100%;
+ display:block;
+ padding:1em 0em .2em 0em;
+ clear:both;
+}
+
+a.version:before {
+ content:"Version";
+ font-size:smaller;
+}
+
+a.version:visited, a.version:link {
+ color:#666;
+}
+
+a.version:focus, a.version:hover {
+ color:black;
+}
+
+.books {
+ display:block;
+ position:relative;
+ clear:both;
+ width:100%;
+}
+
+.books li {
+ display:block;
+ width:200px;
+ float:left;
+ position:relative;
+ clear: none ;
+}
+
+.books .html {
+ width:170px;
+ display:block;
+}
+
+.books .pdf {
+ position:absolute;
+ left:170px;
+ top:0px;
+ font-size:smaller;
+}
+
+.books .pdf:link, .books .pdf:visited {
+ color:#555;
+}
+
+.books .pdf:hover, .books .pdf:focus {
+ color:#000;
+}
+
+.books li a {
+ text-decoration:none;
+}
+
+.books li a:hover {
+ color:black;
+}
+
+/*products*/
+.products li {
+ display: block;
+ width:300px;
+ float:left;
+}
+
+.products li a {
+ width:300px;
+ padding:.5em 0em;
+}
+
+.products ul {
+ clear:both;
+}
+
+/*revision history*/
+.revhistory {
+ display:block;
+}
+
+.revhistory table {
+ background-color:transparent;
+ border-color:#fff;
+ padding:0em;
+ margin: 0;
+ border-collapse:collapse;
+ border-style:none;
+}
+
+.revhistory td {
+ text-align :left;
+ padding:0em;
+ border: none;
+ border-top: 1px solid #fff;
+ font-weight: bold;
+}
+
+.revhistory .simplelist td {
+ font-weight: normal;
+}
+
+.revhistory .simplelist {
+ margin-bottom: 1.5em;
+ margin-left: 1em;
+}
+
+.revhistory table th {
+ display: none;
+}
+
+
+/*credits*/
+.authorgroup div {
+ clear:both;
+ text-align: center;
+}
+
+h3.author {
+ margin: 0em;
+ padding: 0em;
+ padding-top: 1em;
+}
+
+.authorgroup h4 {
+ padding: 0em;
+ margin: 0em;
+ padding-top: 1em;
+ margin-top: 1em;
+}
+
+.author,
+.editor,
+.translator,
+.othercredit,
+.contrib {
+ display: block;
+}
+
+.revhistory .author {
+ display: inline;
+}
+
+.othercredit h3 {
+ padding-top: 1em;
+}
+
+
+.othercredit {
+ margin:0em;
+ padding:0em;
+}
+
+.releaseinfo {
+ clear: both;
+}
+
+.copyright {
+ margin-top: 1em;
+}
+
+/* qanda sets */
+.answer {
+ margin-bottom:1em;
+ border-bottom:1px dotted #ccc;
+}
+
+.qandaset .toc {
+ border-bottom:1px dotted #ccc;
+}
+
+.question {
+ font-weight:bold;
+}
+
+.answer .data, .question .data {
+ padding-left: 2.6em;
+}
+
+.answer label, .question label {
+ float:left;
+ font-weight:bold;
+}
+
+/* inline syntax highlighting */
+.perl_Alert {
+ color: #0000ff;
+}
+
+.perl_BaseN {
+ color: #007f00;
+}
+
+.perl_BString {
+ color: #5C3566;
+}
+
+.perl_Char {
+ color: #ff00ff;
+}
+
+.perl_Comment {
+ color: #FF00FF;
+}
+
+
+.perl_DataType {
+ color: #0000ff;
+}
+
+
+.perl_DecVal {
+ color: #00007f;
+}
+
+
+.perl_Error {
+ color: #ff0000;
+}
+
+
+.perl_Float {
+ color: #00007f;
+}
+
+
+.perl_Function {
+ color: #007f00;
+}
+
+
+.perl_IString {
+ color: #5C3566;
+}
+
+
+.perl_Keyword {
+ color: #002F5D;
+}
+
+
+.perl_Operator {
+ color: #ffa500;
+}
+
+
+.perl_Others {
+ color: #b03060;
+}
+
+
+.perl_RegionMarker {
+ color: #96b9ff;
+}
+
+
+.perl_Reserved {
+ color: #9b30ff;
+}
+
+
+.perl_String {
+ color: #5C3566;
+}
+
+
+.perl_Variable {
+ color: #0000ff;
+}
+
+
+.perl_Warning {
+ color: #0000ff;
+}
+
+/*Lists*/
+ul {
+ padding-left:1.6em;
+ list-style-image:url(../images/dot.png);
+ list-style-type: circle;
+}
+
+ul ul {
+ list-style-image:url(../images/dot2.png);
+ list-style-type: circle;
+}
+
+ol {
+ list-style-image:none;
+ list-style-type: decimal;
+}
+
+ol ol {
+ list-style-type: lower-alpha;
+}
+
+ol.arabic {
+ list-style-type: decimal;
+}
+
+ol.loweralpha {
+ list-style-type: lower-alpha;
+}
+
+ol.lowerroman {
+ list-style-type: lower-roman;
+}
+
+ol.upperalpha {
+ list-style-type: upper-alpha;
+}
+
+ol.upperroman {
+ list-style-type: upper-roman;
+}
+
+dt {
+ font-weight:bold;
+ margin-bottom:0em;
+ padding-bottom:0em;
+}
+
+dd {
+ margin:0em;
+ margin-left:2em;
+ padding-top:0em;
+ padding-bottom: 1em;
+}
+
+li {
+ padding-top:0px;
+ margin-top:0em;
+ padding-bottom:0px;
+ margin-bottom:0.4em;
+}
+
+li p, li div.para {
+ padding-top:0px;
+ margin-top:0em;
+ padding-bottom:0px;
+ margin-bottom:0.3em;
+}
+
+/*images*/
+img {
+ display:block;
+ margin: 2em 0;
+}
+
+.inlinemediaobject, .inlinemediaobject img {
+ display:inline;
+ margin:0em;
+}
+
+.figure img {
+ display:block;
+ margin:0;
+ page-break-inside: avoid;
+}
+
+.figure .title {
+ margin:0em;
+ margin-bottom:2em;
+ padding:0px;
+}
+
+/*document modes*/
+.confidential {
+ background-color:#900;
+ color:White;
+ padding:.5em .5em;
+ text-transform:uppercase;
+ text-align:center;
+}
+
+.longdesc-link {
+ display:none;
+}
+
+.longdesc {
+ display:none;
+}
+
+.prompt {
+ padding:0em .3em;
+}
+
+/*user interface styles*/
+.screen .replaceable {
+}
+
+.guibutton, .guilabel {
+ font-family: "liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-weight: bold;
+ white-space: nowrap;
+}
+
+.example {
+ background-color: #ffffff;
+ border-left: 3px solid #aaaaaa;
+ padding-top: 1em;
+ padding-bottom: 0.1em;
+}
+
+.example h6 {
+ padding-left: 10px;
+}
+
+.example-contents {
+ padding-left: 10px;
+ background-color: #ffffff;
+}
+
+.example-contents .para {
+/* padding: 10px;*/
+}
+
+/*terminal/console text*/
+.computeroutput,
+.option {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-weight:bold;
+}
+
+.replaceable {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-style: italic;
+}
+
+.command, .filename, .keycap, .classname, .literal {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-weight:bold;
+}
+
+/* no bold in toc */
+.toc * {
+ font-weight: inherit;
+}
+
+pre {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ display:block;
+ background-color: #f5f5f5;
+ color: #000000;
+ border: 1px solid #aaaaaa;
+ margin-bottom: 0.3em;
+ padding:.5em 1em;
+ white-space: pre-wrap; /* css-3 */
+ white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
+ white-space: -pre-wrap; /* Opera 4-6 */
+ white-space: -o-pre-wrap; /* Opera 7 */
+ word-wrap: break-word; /* Internet Explorer 5.5+ */
+ font-size: 0.9em;
+}
+
+pre .replaceable,
+pre .keycap {
+}
+
+code {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+/* white-space: nowrap;*/
+ white-space: pre-wrap;
+ word-wrap: break-word;
+ font-weight:bold;
+}
+
+.parameter code {
+ display: inline;
+ white-space: pre-wrap; /* css-3 */
+ white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
+ white-space: -pre-wrap; /* Opera 4-6 */
+ white-space: -o-pre-wrap; /* Opera 7 */
+ word-wrap: break-word; /* Internet Explorer 5.5+ */
+}
+
+/*Notifications*/
+div.warning:before {
+ content:url(../images/warning.png);
+ padding-left: 5px;
+}
+
+div.note:before {
+ content:url(../images/note.png);
+ padding-left: 5px;
+}
+
+div.important:before {
+ content:url(../images/important.png);
+ padding-left: 5px;
+}
+
+div.warning, div.note, div.important {
+ color: black;
+ margin: 0em;
+ padding: 0em;
+ background: none;
+ background-color: white;
+ margin-bottom: 1em;
+ border-bottom: 1px solid #aaaaaa;
+ page-break-inside: avoid;
+}
+
+div.warning h2, div.note h2,div.important h2 {
+ margin: 0em;
+ padding: 0em;
+ color: #eeeeec;
+ padding-top: 0px;
+ padding-bottom: 0px;
+ height: 1.4em;
+ line-height: 1.4em;
+ font-size: 1.4em;
+ display:inline;
+}
+
+div.admonition_header {
+ clear: both;
+ margin: 0em;
+ padding: 0em;
+ margin-top: -3.3em;
+ padding-left: 58px;
+ line-height: 1.0em;
+ font-size: 1.0em;
+}
+
+div.warning div.admonition_header {
+ background: url(../images/red.png) top left repeat-x;
+ background-color: #590000;
+}
+
+div.note div.admonition_header {
+ background: url(../images/green.png) top right repeat-x;
+ background-color: #597800;
+}
+
+div.important div.admonition_header {
+ background: url(../images/yellow.png) top right repeat-x;
+ background-color: #a6710f;
+}
+
+div.warning p, div.warning div.para,
+div.note p, div.note div.para,
+div.important p, div.important div.para {
+ padding: 0em;
+ margin: 0em;
+}
+
+div.admonition {
+ border: none;
+ border-left: 1px solid #aaaaaa;
+ border-right: 1px solid #aaaaaa;
+ padding:0em;
+ margin:0em;
+ padding-top: 1.5em;
+ padding-bottom: 1em;
+ padding-left: 2em;
+ padding-right: 1em;
+ background-color: #eeeeec;
+ -moz-border-radius: 0px;
+ -webkit-border-radius: 0px;
+ border-radius: 0px;
+}
+
+/*Page Title*/
+#title {
+ display:block;
+ height:45px;
+ padding-bottom:1em;
+ margin:0em;
+}
+
+#title a.left{
+ display:inline;
+ border:none;
+}
+
+#title a.left img{
+ border:none;
+ float:left;
+ margin:0em;
+ margin-top:.7em;
+}
+
+#title a.right {
+ padding-bottom:1em;
+}
+
+#title a.right img {
+ border:none;
+ float:right;
+ margin:0em;
+ margin-top:.7em;
+}
+
+/*Table*/
+div.table {
+ page-break-inside: avoid;
+}
+
+table {
+ border:1px solid #6c614b;
+ width:100%;
+ border-collapse:collapse;
+}
+
+table.simplelist, .calloutlist table {
+ border-style: none;
+}
+
+table th {
+ text-align:left;
+ background-color:#6699cc;
+ padding:.3em .5em;
+ color:white;
+}
+
+table td {
+ padding:.15em .5em;
+}
+
+table tr.even td {
+ background-color:#f5f5f5;
+}
+
+table th p:first-child, table td p:first-child, table li p:first-child,
+table th div.para:first-child, table td div.para:first-child, table li div.para:first-child {
+ margin-top:0em;
+ padding-top:0em;
+ display:inline;
+}
+
+th, td {
+ border-style:none;
+ vertical-align: top;
+ border: 1px solid #000;
+}
+
+.simplelist th, .simplelist td {
+ border: none;
+}
+
+table table td {
+ border-bottom:1px dotted #aaa;
+ background-color:white;
+ padding:.6em 0em;
+}
+
+table table {
+ border:1px solid white;
+}
+
+td.remarkval {
+ color:#444;
+}
+
+td.fieldval {
+ font-weight:bold;
+}
+
+.lbname, .lbtype, .lbdescr, .lbdriver, .lbhost {
+ color:white;
+ font-weight:bold;
+ background-color:#999;
+ width:120px;
+}
+
+td.remarkval {
+ width:230px;
+}
+
+td.tname {
+ font-weight:bold;
+}
+
+th.dbfield {
+ width:120px;
+}
+
+th.dbtype {
+ width:70px;
+}
+
+th.dbdefault {
+ width:70px;
+}
+
+th.dbnul {
+ width:70px;
+}
+
+th.dbkey {
+ width:70px;
+}
+
+span.book {
+ margin-top:4em;
+ display:block;
+ font-size:11pt;
+}
+
+span.book a{
+ font-weight:bold;
+}
+span.chapter {
+ display:block;
+ margin-top:0.5em;
+}
+
+table.simplelist td, .calloutlist table td {
+ border-style: none;
+}
+
+/*Breadcrumbs*/
+#breadcrumbs ul li.first:before {
+ content:" ";
+}
+
+#breadcrumbs {
+ color:#900;
+ padding:3px;
+ margin-bottom:25px;
+}
+
+#breadcrumbs ul {
+ margin-left:0;
+ padding-left:0;
+ display:inline;
+ border:none;
+}
+
+#breadcrumbs ul li {
+ margin-left:0;
+ padding-left:2px;
+ border:none;
+ list-style:none;
+ display:inline;
+}
+
+#breadcrumbs ul li:before {
+ content:"\0020 \0020 \0020 \00BB \0020";
+ color:#333;
+}
+
+/*index*/
+.glossary h3,
+.index h3 {
+ font-size: 2em;
+ color:#aaa;
+ margin:0em;
+}
+
+.indexdiv {
+ margin-bottom:1em;
+}
+
+.glossary dt,
+.index dt {
+ color:#444;
+ padding-top:.5em;
+}
+
+.glossary dl dl dt,
+.index dl dl dt {
+ color:#777;
+ font-weight:normal;
+ padding-top:0em;
+}
+
+.index dl dl dt:before {
+ content:"- ";
+ color:#ccc;
+}
+
+/*changes*/
+.footnote {
+ font-size: .7em;
+ margin:0em;
+ color:#222;
+}
+
+table .footnote {
+}
+
+sup {
+ color:#999;
+ margin:0em;
+ padding:0em;
+ line-height: .4em;
+ font-size: 1em;
+ padding-left:0em;
+}
+
+.footnote {
+ position:relative;
+}
+
+.footnote sup {
+ color:#e3dcc0;
+ position:absolute;
+ left: .4em;
+}
+
+.footnote sup a:link,
+.footnote sup a:visited {
+ color:#92917d;
+ text-decoration:none;
+}
+
+.footnote:hover sup a {
+ text-decoration:none;
+}
+
+.footnote p,.footnote div.para {
+ padding-left:2em;
+}
+
+.footnote a:link,
+.footnote a:visited {
+ color:#00537c;
+}
+
+.footnote a:hover {
+}
+
+/**/
+div.chapter {
+ margin-top:3em;
+ page-break-inside: avoid;
+}
+
+div.preface {
+ page-break-inside: avoid;
+}
+
+div.section {
+ margin-top:1em;
+ page-break-inside: auto;
+}
+
+div.note .replaceable,
+div.important .replaceable,
+div.warning .replaceable,
+div.note .keycap,
+div.important .keycap,
+div.warning .keycap
+{
+}
+
+ul li p:last-child, ul li div.para:last-child {
+ margin-bottom:0em;
+ padding-bottom:0em;
+}
+
+/*document navigation*/
+.docnav a, .docnav strong {
+ border:none;
+ text-decoration:none;
+ font-weight:normal;
+}
+
+.docnav {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+ position:relative;
+ width:100%;
+ padding-bottom:2em;
+ padding-top:1em;
+ border-top:1px dotted #ccc;
+}
+
+.docnav li {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+ display:inline;
+ font-size:.8em;
+}
+
+.docnav li:before {
+ content:" ";
+}
+
+.docnav li.previous, .docnav li.next {
+ position:absolute;
+ top:1em;
+}
+
+.docnav li.up, .docnav li.home {
+ margin:0em 1.5em;
+}
+
+.docnav li.previous {
+ left:0px;
+ text-align:left;
+}
+
+.docnav li.next {
+ right:0px;
+ text-align:right;
+}
+
+.docnav li.previous strong, .docnav li.next strong {
+ height:22px;
+ display:block;
+}
+
+.docnav {
+ margin:0 auto;
+ text-align:center;
+}
+
+.docnav li.next a strong {
+ background: url(../images/stock-go-forward.png) top right no-repeat;
+ padding-top:3px;
+ padding-bottom:4px;
+ padding-right:28px;
+ font-size:1.2em;
+}
+
+.docnav li.previous a strong {
+ background: url(../images/stock-go-back.png) top left no-repeat;
+ padding-top:3px;
+ padding-bottom:4px;
+ padding-left:28px;
+ padding-right:0.5em;
+ font-size:1.2em;
+}
+
+.docnav li.home a strong {
+ background: url(../images/stock-home.png) top left no-repeat;
+ padding:5px;
+ padding-left:28px;
+ font-size:1.2em;
+}
+
+.docnav li.up a strong {
+ background: url(../images/stock-go-up.png) top left no-repeat;
+ padding:5px;
+ padding-left:28px;
+ font-size:1.2em;
+}
+
+.docnav a:link, .docnav a:visited {
+ color:#666;
+}
+
+.docnav a:hover, .docnav a:focus, .docnav a:active {
+ color:black;
+}
+
+.docnav a {
+ max-width: 10em;
+ overflow:hidden;
+}
+
+.docnav a:link strong {
+ text-decoration:none;
+}
+
+.docnav {
+ margin:0 auto;
+ text-align:center;
+}
+
+ul.docnav {
+ margin-bottom: 1em;
+}
+/* Reports */
+.reports ul {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+}
+
+.reports li{
+ margin:0em;
+ padding:0em;
+}
+
+.reports li.odd {
+ background-color: #eeeeee;
+ margin:0em;
+ padding:0em;
+}
+
+.reports dl {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ float:right;
+ margin-right: 17em;
+ margin-top:-1.3em;
+}
+
+.reports dt {
+ display:inline;
+ margin:0em;
+ padding:0em;
+}
+
+.reports dd {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ padding-right:.5em;
+}
+
+.reports h2, .reports h3{
+ display:inline;
+ padding-right:.5em;
+ font-size:10pt;
+ font-weight:normal;
+}
+
+.reports div.progress {
+ display:inline;
+ float:right;
+ width:16em;
+ background:#c00 url(../images/shine.png) top left repeat-x;
+ margin:0em;
+ margin-top:-1.3em;
+ padding:0em;
+ border:none;
+}
+
+/*uniform*/
+body.results, body.reports {
+ max-width:57em ;
+ padding:0em;
+}
+
+/*Progress Bar*/
+div.progress {
+ display:block;
+ float:left;
+ width:16em;
+ background:#c00 url(../images/shine.png) top left repeat-x;
+ height:1em;
+}
+
+div.progress span {
+ height:1em;
+ float:left;
+}
+
+div.progress span.translated {
+ background:#6c3 url(../images/shine.png) top left repeat-x;
+}
+
+div.progress span.fuzzy {
+ background:#ff9f00 url(../images/shine.png) top left repeat-x;
+}
+
+
+/*Results*/
+
+.results ul {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+}
+
+.results li{
+ margin:0em;
+ padding:0em;
+}
+
+.results li.odd {
+ background-color: #eeeeee;
+ margin:0em;
+ padding:0em;
+}
+
+.results dl {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ float:right;
+ margin-right: 17em;
+ margin-top:-1.3em;
+}
+
+.results dt {
+ display:inline;
+ margin:0em;
+ padding:0em;
+}
+
+.results dd {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ padding-right:.5em;
+}
+
+.results h2, .results h3 {
+ display:inline;
+ padding-right:.5em;
+ font-size:10pt;
+ font-weight:normal;
+}
+
+.results div.progress {
+ display:inline;
+ float:right;
+ width:16em;
+ background:#c00 url(../images/shine.png) top left repeat-x;
+ margin:0em;
+ margin-top:-1.3em;
+ padding:0em;
+ border:none;
+}
+
+/* Dirty EVIL Mozilla hack for round corners */
+pre {
+ -moz-border-radius:11px;
+ -webkit-border-radius:11px;
+ border-radius: 11px;
+ page-break-inside: avoid;
+}
+
+.example {
+ -moz-border-radius:0px;
+ -webkit-border-radius:0px;
+ border-radius: 0px;
+ page-break-inside: avoid;
+}
+
+.package, .citetitle {
+ font-style: italic;
+}
+
+.titlepage .edition {
+ color: #336699;
+ background-color: transparent;
+ margin-top: 1em;
+ margin-bottom: 1em;
+ font-size: 1.4em;
+ font-weight: bold;
+ text-align: center;
+}
+
+span.remark {
+ background-color: #ff00ff;
+}
+
+.draft {
+ background-image: url(../images/watermark-draft.png);
+ background-repeat: repeat-y;
+ background-position: center;
+}
+
+.foreignphrase {
+ font-style: inherit;
+}
+
+dt {
+ clear:both;
+}
+
+dt img {
+ border-style: none;
+ max-width: 112px;
+}
+
+dt object {
+ max-width: 112px;
+}
+
+dt .inlinemediaobject, dt object {
+ display: inline;
+ float: left;
+ margin-bottom: 1em;
+ padding-right: 1em;
+ width: 112px;
+}
+
+dl:after {
+ display: block;
+ clear: both;
+ content: "";
+}
+
+.toc dd {
+ padding-bottom: 0em;
+ margin-bottom: 1em;
+ padding-left: 1.3em;
+ margin-left: 0em;
+}
+
+div.toc > dl > dt {
+ padding-bottom: 0em;
+ margin-bottom: 0em;
+ margin-top: 1em;
+}
+
+
+.strikethrough {
+ text-decoration: line-through;
+}
+
+.underline {
+ text-decoration: underline;
+}
+
+.calloutlist img, .callout {
+ padding: 0em;
+ margin: 0em;
+ width: 12pt;
+ display: inline;
+ vertical-align: middle;
+}
+
+.stepalternatives {
+ list-style-image: none;
+ list-style-type: none;
+}
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/css/default.css b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/default.css
new file mode 100644
index 00000000000..bf38ebb5931
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/default.css
@@ -0,0 +1,3 @@
+@import url("common.css");
+@import url("overrides.css");
+@import url("lang.css");
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/css/lang.css b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/lang.css
new file mode 100644
index 00000000000..81c3115605a
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/lang.css
@@ -0,0 +1,2 @@
+/* place holder */
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/css/overrides.css b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/overrides.css
new file mode 100644
index 00000000000..ebd9730b690
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/overrides.css
@@ -0,0 +1,57 @@
+a:link {
+ color:#0066cc;
+}
+
+a:visited {
+ color:#6699cc;
+}
+
+h1 {
+ color:#3c6eb4;
+}
+
+.producttitle {
+ background: #3c6eb4 url(../images/h1-bg.png) top left repeat;
+}
+
+.section h1.title {
+ color:#3c6eb4;
+}
+
+
+h2,h3,h4,h5,h6 {
+ color:#3c6eb4
+}
+
+table {
+ border:1px solid #3c6eb4;
+}
+
+table th {
+ background-color:#3c6eb4;
+}
+
+table tr.even td {
+ background-color:#f5f5f5;
+}
+
+#title a {
+ height:54px;
+}
+
+.term{
+ color:#a70000;
+}
+
+.revhistory table th {
+ color:#3c6eb4;
+}
+
+.edition {
+ color: #3c6eb4;
+}
+
+span.remark{
+ background-color: #ffff00;
+}
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/css/print.css b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/print.css
new file mode 100644
index 00000000000..773d8ae1b1c
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/css/print.css
@@ -0,0 +1,16 @@
+@import url("common.css");
+@import url("overrides.css");
+@import url("lang.css");
+
+#tocframe {
+ display: none;
+}
+
+body.toc_embeded {
+ margin-left: 30px;
+}
+
+.producttitle {
+ color: #336699;
+}
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/1.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/1.png
new file mode 100644
index 00000000000..ef0beba8510
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/1.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/1.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/1.svg
new file mode 100644
index 00000000000..4c6bf579527
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/1.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/10.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/10.png
new file mode 100644
index 00000000000..05f22391ea7
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/10.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/10.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/10.svg
new file mode 100644
index 00000000000..0edda5b6fa6
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/10.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/11.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/11.png
new file mode 100644
index 00000000000..32b4a04831e
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/11.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/11.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/11.svg
new file mode 100644
index 00000000000..c95afcc14a1
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/11.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/12.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/12.png
new file mode 100644
index 00000000000..45fa4892a94
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/12.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/12.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/12.svg
new file mode 100644
index 00000000000..e3c3fd66c7d
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/12.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/13.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/13.png
new file mode 100644
index 00000000000..0b766d3f87b
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/13.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/13.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/13.svg
new file mode 100644
index 00000000000..35b4969143d
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/13.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/14.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/14.png
new file mode 100644
index 00000000000..2e1d73716c2
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/14.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/14.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/14.svg
new file mode 100644
index 00000000000..832f816799a
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/14.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/15.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/15.png
new file mode 100644
index 00000000000..7d21c66bb04
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/15.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/15.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/15.svg
new file mode 100644
index 00000000000..830d65439c6
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/15.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/16.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/16.png
new file mode 100644
index 00000000000..ff396af2fa6
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/16.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/16.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/16.svg
new file mode 100644
index 00000000000..24d1eea0458
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/16.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/17.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/17.png
new file mode 100644
index 00000000000..f1ba68a7f60
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/17.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/17.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/17.svg
new file mode 100644
index 00000000000..7796bd1d7db
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/17.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/18.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/18.png
new file mode 100644
index 00000000000..df920d02515
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/18.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/18.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/18.svg
new file mode 100644
index 00000000000..356f207eefb
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/18.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/19.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/19.png
new file mode 100644
index 00000000000..bda9a8c559d
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/19.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/19.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/19.svg
new file mode 100644
index 00000000000..385378074ed
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/19.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/2.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/2.png
new file mode 100644
index 00000000000..b95445a4e73
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/2.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/2.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/2.svg
new file mode 100644
index 00000000000..236a8dacbc4
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/2.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/20.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/20.png
new file mode 100644
index 00000000000..c30191a3653
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/20.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/20.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/20.svg
new file mode 100644
index 00000000000..d41206eec57
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/20.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/21.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/21.png
new file mode 100644
index 00000000000..fa3aa907dcf
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/21.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/21.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/21.svg
new file mode 100644
index 00000000000..b17f23a5a9a
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/21.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/22.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/22.png
new file mode 100644
index 00000000000..b724ced1311
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/22.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/22.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/22.svg
new file mode 100644
index 00000000000..22deeb3edbb
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/22.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/23.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/23.png
new file mode 100644
index 00000000000..8b69b829282
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/23.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/23.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/23.svg
new file mode 100644
index 00000000000..c0a33eeb0b0
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/23.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/24.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/24.png
new file mode 100644
index 00000000000..863ce3b6632
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/24.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/24.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/24.svg
new file mode 100644
index 00000000000..27e1d39c94f
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/24.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/25.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/25.png
new file mode 100644
index 00000000000..cc23b9b2b04
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/25.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/25.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/25.svg
new file mode 100644
index 00000000000..114e1a26ba6
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/25.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/26.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/26.png
new file mode 100644
index 00000000000..583fe34867d
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/26.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/26.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/26.svg
new file mode 100644
index 00000000000..e9b5d239b55
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/26.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/27.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/27.png
new file mode 100644
index 00000000000..d1c3dfa457a
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/27.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/27.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/27.svg
new file mode 100644
index 00000000000..4a80177b68d
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/27.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/28.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/28.png
new file mode 100644
index 00000000000..f5db74735d7
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/28.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/28.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/28.svg
new file mode 100644
index 00000000000..d453f299fa2
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/28.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/29.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/29.png
new file mode 100644
index 00000000000..9a3141ec42e
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/29.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/29.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/29.svg
new file mode 100644
index 00000000000..04b5c5034fc
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/29.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/3.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/3.png
new file mode 100644
index 00000000000..a4754f0615c
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/3.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/3.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/3.svg
new file mode 100644
index 00000000000..e2f17168da1
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/3.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/30.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/30.png
new file mode 100644
index 00000000000..9d3db242d90
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/30.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/30.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/30.svg
new file mode 100644
index 00000000000..5cdcf65e846
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/30.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/31.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/31.png
new file mode 100644
index 00000000000..9e2675da589
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/31.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/31.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/31.svg
new file mode 100644
index 00000000000..f0fdb294dd8
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/31.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/32.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/32.png
new file mode 100644
index 00000000000..20f1bb23c4b
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/32.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/32.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/32.svg
new file mode 100644
index 00000000000..93829281032
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/32.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/33.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/33.png
new file mode 100644
index 00000000000..01407e6bcce
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/33.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/33.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/33.svg
new file mode 100644
index 00000000000..f46815f7ea6
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/33.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/34.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/34.png
new file mode 100644
index 00000000000..ba443525397
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/34.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/34.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/34.svg
new file mode 100644
index 00000000000..7bbdf5b9ab2
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/34.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/35.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/35.png
new file mode 100644
index 00000000000..21d4575cf27
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/35.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/35.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/35.svg
new file mode 100644
index 00000000000..8e19553af20
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/35.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/36.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/36.png
new file mode 100644
index 00000000000..b5402b57788
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/36.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/36.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/36.svg
new file mode 100644
index 00000000000..d364dbf51bb
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/36.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/37.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/37.png
new file mode 100644
index 00000000000..9fd99d22058
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/37.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/37.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/37.svg
new file mode 100644
index 00000000000..771fa4d110b
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/37.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/38.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/38.png
new file mode 100644
index 00000000000..3ce6027f00f
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/38.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/38.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/38.svg
new file mode 100644
index 00000000000..487e0ef3051
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/38.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/39.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/39.png
new file mode 100644
index 00000000000..d6894500c24
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/39.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/39.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/39.svg
new file mode 100644
index 00000000000..cea69f715f9
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/39.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/4.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/4.png
new file mode 100644
index 00000000000..f6c113563a1
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/4.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/4.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/4.svg
new file mode 100644
index 00000000000..3b537d4a19b
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/4.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/40.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/40.png
new file mode 100644
index 00000000000..0d3532e0f3f
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/40.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/40.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/40.svg
new file mode 100644
index 00000000000..bb4e1d7b8fc
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/40.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/5.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/5.png
new file mode 100644
index 00000000000..4ced5472dfc
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/5.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/5.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/5.svg
new file mode 100644
index 00000000000..ec2715dea0b
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/5.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/6.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/6.png
new file mode 100644
index 00000000000..22fc272c050
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/6.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/6.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/6.svg
new file mode 100644
index 00000000000..b8062936898
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/6.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/7.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/7.png
new file mode 100644
index 00000000000..9b1f20a9816
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/7.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/7.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/7.svg
new file mode 100644
index 00000000000..871e0eff74f
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/7.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/8.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/8.png
new file mode 100644
index 00000000000..ac38ae5bffd
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/8.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/8.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/8.svg
new file mode 100644
index 00000000000..10e612f6eb9
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/8.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/9.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/9.png
new file mode 100644
index 00000000000..a2972dbc216
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/9.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/9.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/9.svg
new file mode 100644
index 00000000000..c488b6e4fa4
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/9.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/dot.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/dot.png
new file mode 100644
index 00000000000..079add95ded
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/dot.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/dot2.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/dot2.png
new file mode 100644
index 00000000000..8348fcd054a
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/dot2.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/green.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/green.png
new file mode 100644
index 00000000000..ebb3c247dea
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/green.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/h1-bg.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/h1-bg.png
new file mode 100644
index 00000000000..a2aad24b329
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/h1-bg.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/image_left.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/image_left.png
new file mode 100644
index 00000000000..2831477642c
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/image_left.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/image_right.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/image_right.png
new file mode 100644
index 00000000000..19a6cca5336
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/image_right.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/important.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/important.png
new file mode 100644
index 00000000000..969562b7bc7
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/important.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/important.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/important.svg
new file mode 100644
index 00000000000..064c783b538
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/important.svg
@@ -0,0 +1,30 @@
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/note.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/note.png
new file mode 100644
index 00000000000..d04775d9905
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/note.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/note.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/note.svg
new file mode 100644
index 00000000000..abe5a602468
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/note.svg
@@ -0,0 +1,28 @@
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/red.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/red.png
new file mode 100644
index 00000000000..d32d5e2e80a
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/red.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/shine.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/shine.png
new file mode 100644
index 00000000000..a18f7c4612e
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/shine.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-go-back.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-go-back.png
new file mode 100644
index 00000000000..00850b21b23
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-go-back.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-go-forward.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-go-forward.png
new file mode 100644
index 00000000000..cc2797a4686
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-go-forward.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-go-up.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-go-up.png
new file mode 100644
index 00000000000..1ebf2799c35
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-go-up.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-home.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-home.png
new file mode 100644
index 00000000000..3f0c1906343
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/stock-home.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/title_logo.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/title_logo.png
new file mode 100644
index 00000000000..58a1b56cfe8
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/title_logo.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/title_logo.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/title_logo.svg
new file mode 100644
index 00000000000..e8b3eca8d82
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/title_logo.svg
@@ -0,0 +1,335 @@
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/warning.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/warning.png
new file mode 100644
index 00000000000..94b69d1ff1f
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/warning.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/warning.svg b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/warning.svg
new file mode 100644
index 00000000000..4231e5ac041
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/warning.svg
@@ -0,0 +1,130 @@
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/watermark-draft.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/watermark-draft.png
new file mode 100644
index 00000000000..0ead5af8bb8
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/watermark-draft.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/Common_Content/images/yellow.png b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/yellow.png
new file mode 100644
index 00000000000..223865d77fa
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/Common_Content/images/yellow.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/LDAPserver-for-user-authentication.html b/docs/tmp/en-US/epub/OEBPS/LDAPserver-for-user-authentication.html
new file mode 100644
index 00000000000..7ba186388ac
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/LDAPserver-for-user-authentication.html
@@ -0,0 +1,135 @@
+
+
+3.2. Using an LDAP Server for User Authentication
3.2. Using an LDAP Server for User Authentication
+ You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate CloudStack end-users. Just map CloudStack accounts to the corresponding LDAP accounts using a query filter. The query filter is written using the query syntax of the particular LDAP server, and can include special wildcard characters provided by CloudStack for matching common values such as the user’s email address and name. CloudStack will search the external LDAP directory tree starting at a specified base directory and return the distinguished name (DN) and password of the matching user. This information along with the given password is used to authenticate the user..
+
+ To set up LDAP authentication in CloudStack, call the CloudStack API command ldapConfig and provide the following:
+
+ Hostname or IP address and listening port of the LDAP server
+
+ Base directory and query filter
+
+ Search user DN credentials, which give CloudStack permission to search on the LDAP server
+
+ SSL keystore and password, if SSL is used
+
3.2.1. Example LDAP Configuration Commands
+ To understand the examples in this section, you need to know the basic concepts behind calling the CloudStack API, which are explained in the Developer’s Guide.
+
+ The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
+
+ 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.
+
+ The next few sections explain some of the concepts you will need to know when filling out the ldapConfig parameters.
+
3.2.2. Search Base
+ An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The search base is the distinguished name (DN) of a level of the directory tree below which all users can be found. The users can be in the immediate base directory or in some subdirectory. The search base may be equivalent to the organization, group, or domain name. The syntax for writing a DN varies depending on which LDAP server you are using. A full discussion of distinguished names is outside the scope of our documentation. The following table shows some examples of search bases to find users in the testing department..
+
+
+ LDAP Server
+
+
+
+ Example Search Base DN
+
+
+
+ ApacheDS
+
+
+
+ ou=testing,o=project
+
+
+
+ Active Directory
+
+
+
+ OU=testing, DC=company
+
+
3.2.3. Query Filter
+ The query filter is used to find a mapped user in the external LDAP server. The query filter should uniquely map the CloudPlatform user to LDAP user for a meaningful authentication. For more information about query filter syntax, consult the documentation for your LDAP server.
+
+ The CloudPlatform 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 CloudPlatform user name is the same as the LDAP user ID:
+
(uid=%u)
+ If the CloudPlatform user name is the LDAP display name:
+
(displayName=%u)
+ To find a user by email address:
+
(mail=%e)
3.2.4. Search User Bind DN
+ The bind DN is the user on the external LDAP server permitted to search the LDAP directory within the defined search base. When the DN is returned, the DN and passed password are used to authenticate the CloudStack user with an LDAP bind. A full discussion of bind DNs is outside the scope of our documentation. The following table shows some examples of bind DNs.
+
+ 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/about-clusters.html b/docs/tmp/en-US/epub/OEBPS/about-clusters.html
new file mode 100644
index 00000000000..9432a4fa63f
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/about-clusters.html
@@ -0,0 +1,15 @@
+
+
+2.3. About Clusters
2.3. About Clusters
+ A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set of KVM servers, , or a VMware cluster preconfigured in vCenter. The hosts in a cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the same shared primary storage. Virtual machine instances (VMs) can be live-migrated from one host to another within the same cluster, without interrupting service to the user.
+
+ A cluster is the third-largest organizational unit within a CloudStack deployment. Clusters are contained within pods, and pods are contained within zones. Size of the cluster is limited by the underlying hypervisor, although the CloudStack recommends less in most cases; see Best Practices.
+
+ A cluster consists of one or more hosts and one or more primary storage servers.
+
+ CloudStack allows multiple clusters in a cloud deployment.
+
+ Even when local storage is used exclusively, clusters are still required organizationally, even if there is just one host per cluster.
+
+ When VMware is used, every VMware cluster is managed by a vCenter server. Administrator must register the vCenter server with CloudStack. There may be multiple vCenter servers per zone. Each vCenter server may manage multiple VMware clusters.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/about-hosts.html b/docs/tmp/en-US/epub/OEBPS/about-hosts.html
new file mode 100644
index 00000000000..1a2987e1354
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/about-hosts.html
@@ -0,0 +1,31 @@
+
+
+2.4. About Hosts
2.4. About Hosts
+ A host is a single computer. Hosts provide the computing resources that run the guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a Linux KVM-enabled server, a Citrix XenServer server, and an ESXi server are hosts.
+
+ The host is the smallest organizational unit within a CloudStack deployment. Hosts are contained within clusters, clusters are contained within pods, and pods are contained within zones.
+
+ Hosts in a CloudStack deployment:
+
+ Provide the CPU, memory, storage, and networking resources needed to host the virtual machines
+
+ Interconnect using a high bandwidth TCP/IP network and connect to the Internet
+
+ May reside in multiple data centers across different geographic locations
+
+ May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the hosts within a cluster must all be homogeneous
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs.
+
+ CloudStack automatically detects the amount of CPU and memory resources provided by the Hosts.
+
+ Hosts are not visible to the end user. An end user cannot determine which host their guest has been assigned to.
+
+ For a host to function in CloudStack, you must do the following:
+
+ Install hypervisor software on the host
+
+ Assign an IP address to the host
+
+ Ensure the host is connected to the CloudStack Management Server
+
diff --git a/docs/tmp/en-US/epub/OEBPS/about-physical-networks.html b/docs/tmp/en-US/epub/OEBPS/about-physical-networks.html
new file mode 100644
index 00000000000..79cc2d617da
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/about-physical-networks.html
@@ -0,0 +1,93 @@
+
+
+2.7. About Physical Networks
2.7. About Physical Networks
+ Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical networks can be associated with each zone. The network corresponds to a NIC on the hypervisor host. Each physical network can carry one or more types of network traffic. The choices of traffic type for each network vary depending on whether you are creating a zone with basic networking or advanced networking.
+
+ A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can:
+
+ Add/Remove/Update physical networks in a zone
+
+ Configure VLANs on the physical network
+
+ Configure a name so the network can be recognized by hypervisors
+
+ Configure the service providers (firewalls, load balancers, etc.) available on a physical network
+
+ Configure the IP addresses trunked to a physical network
+
+ Specify what type of traffic is carried on the physical network, as well as other properties like network speed
+
2.7.1. Configurable Characteristics of Physical Networks
+ CloudStack provides configuration settings you can use to set up a physical network in a zone, including:
+
+ What type of network traffic it carries (guest, public, management, storage)
+
+ VLANs
+
+ Unique name that the hypervisor can use to find that particular network
+
+ Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator sets the physical network to enabled, and it begins to be used. The administrator can later disable the network again, which prevents any new virtual networks from being created on that physical network; the existing network traffic continues even though the state is disabled.
+
+ Speed
+
+ Tags, so network offerings can be matched to physical networks
+
+ Isolation method
+
2.7.2. Basic Zone Network Traffic Types
+ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
Note
+ We strongly recommend the use of separate NICs for management traffic and guest traffic.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. CloudStack takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.
+
2.7.3. Basic Zone Guest IP Addresses
+ When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts.
+
2.7.4. Advanced Zone Network Traffic Types
+ When advanced networking is used, there can be multiple physical networks in the zone. Each physical network can carry one or more traffic types, and you need to let CloudStack know which type of network traffic you want each network to carry. The traffic types in an advanced zone are:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each CloudStack account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices.
+
2.7.5. Advanced Zone Guest IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.6. Advanced Zone Public IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.7. System Reserved IP Addresses
+ In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the CloudStack Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
+
+ The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone.
+
+ The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in.
+
+ Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. CloudStack can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
+
+ In all zones:
+
+ Provide private IPs for the system in each pod and provision them in CloudStack.
+
+ For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.
+
+ In a zone that uses advanced networking:
+
+ For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required CloudStack System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.
+
+ When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
+
+ To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:
+
+ Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than 4,000 IP addresses.
+
+ Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod has 255 IPs, this will provide 2,550 IP addresses.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/about-pods.html b/docs/tmp/en-US/epub/OEBPS/about-pods.html
new file mode 100644
index 00000000000..86e93f3b42f
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/about-pods.html
@@ -0,0 +1,11 @@
+
+
+2.2. About Pods
2.2. About Pods
+ A pod often represents a single rack. Hosts in the same pod are in the same subnet.
+
+ A pod is the second-largest organizational unit within a CloudStack deployment. Pods are contained within zones. Each zone can contain one or more pods.
+
+ Pods are not visible to the end user.
+
+ A pod consists of one or more clusters of hosts and one or more primary storage servers.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/about-primary-storage.html b/docs/tmp/en-US/epub/OEBPS/about-primary-storage.html
new file mode 100644
index 00000000000..4ecca14bf04
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/about-primary-storage.html
@@ -0,0 +1,15 @@
+
+
+2.5. About Primary Storage
2.5. About Primary Storage
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required. It is typically located close to the hosts for increased performance.
+
+ CloudStack is designed to work with all standards-compliant iSCSI and NFS servers that are supported by the underlying hypervisor, including, for example:
+
+ Dell EqualLogic™ for iSCSI
+
+ Network Appliances filers for NFS and iSCSI
+
+ Scale Computing for NFS
+
+ If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/about-secondary-storage.html b/docs/tmp/en-US/epub/OEBPS/about-secondary-storage.html
new file mode 100644
index 00000000000..3024b74cf5a
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/about-secondary-storage.html
@@ -0,0 +1,15 @@
+
+
+2.6. About Secondary Storage
2.6. About Secondary Storage
+ Secondary storage is associated with a zone, and it stores the following:
+
+ Templates — OS images that can be used to boot VMs and can include additional configuration information, such as installed applications
+
+ ISO images — disc images containing data or bootable media for operating systems
+
+ Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
+
+ The items in zone-based NFS secondary storage are available to all hosts in the zone. CloudStack manages the allocation of guest virtual disks to particular primary storage devices.
+
+ To make items in secondary storage available to all hosts throughout the cloud, you can add OpenStack Object Storage (Swift, swift.openstack.org) in addition to the zone-based NFS secondary storage. When using Swift, you configure Swift storage for the entire CloudStack, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/about-virtual-networks.html b/docs/tmp/en-US/epub/OEBPS/about-virtual-networks.html
new file mode 100644
index 00000000000..1d5ff08c3c8
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/about-virtual-networks.html
@@ -0,0 +1,27 @@
+
+
+9.2. About Virtual Networks
9.2. About Virtual Networks
+ A virtual network is a logical construct that enables multi-tenancy on a single physical network. In CloudStack a virtual network can be shared or isolated.
+
9.2.1. Isolated Networks
+ An isolated network can be accessed only by virtual machines of a single account. Isolated networks have the following properties.
+
+ Resources such as VLAN are allocated and garbage collected dynamically
+
+ There is one network offering for the entire network
+
+ The network offering can be upgraded or downgraded but it is for the entire network
+
9.2.2. Shared Networks
+ A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in CloudStack 3.0.3).
+
+ Shared Networks are created by the administrator
+
+ Shared Networks can be designated to a certain domain
+
+ Shared Network resources such as VLAN and physical network that it maps to are designated by the administrator
+
+ Shared Networks are isolated by security groups
+
+ Public Network is a shared network that is not shown to the end users
+
9.2.3. Runtime Allocation of Virtual Network Resources
+ When you define a new virtual network, all your settings for that network are stored in CloudStack. The actual network resources are activated only when the first virtual machine starts in the network. When all virtual machines have left the virtual network, the network resources are garbage collected so they can be allocated again. This helps to conserve network resources..
+
diff --git a/docs/tmp/en-US/epub/OEBPS/accept-membership-invite.html b/docs/tmp/en-US/epub/OEBPS/accept-membership-invite.html
new file mode 100644
index 00000000000..2c91280126d
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/accept-membership-invite.html
@@ -0,0 +1,17 @@
+
+
+6.5. Accepting a Membership Invitation
6.5. 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.
+
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
+ To access a VM through the CloudStack UI:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ Click Instances, then click the name of a running VM.
+
+ Click the View Console button .
+
+ To access a VM directly over the network:
+
+ The VM must have some port open to incoming traffic. For example, in a basic zone, a new VM might be assigned to a security group which allows incoming traffic. This depends on what security group you picked when creating the VM. In other cases, you can open a port by setting up a port forwarding policy. See IP Forwarding and Firewalling.
+
+ If a port is open but you can not access the VM using ssh, it’s possible that ssh is not already enabled on the VM. This will depend on whether ssh is enabled in the template you picked when creating the VM. Access the VM through the CloudStack UI and enable ssh on the machine using the commands for the VM’s operating system.
+
+ If the network has an external firewall device, you will need to create a firewall rule to allow access. See IP Forwarding and Firewalling.
+
+ 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
+
+ The 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/acquire-new-ip-address.html b/docs/tmp/en-US/epub/OEBPS/acquire-new-ip-address.html
new file mode 100644
index 00000000000..494568e630e
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/acquire-new-ip-address.html
@@ -0,0 +1,15 @@
+
+
+15.11. Acquiring a New IP Address
15.11. Acquiring a New IP Address
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click the name of the network where you want to work with.
+
+ Click View IP Addresses.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/add-members-to-projects.html b/docs/tmp/en-US/epub/OEBPS/add-members-to-projects.html
new file mode 100644
index 00000000000..bc26554a998
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/add-members-to-projects.html
@@ -0,0 +1,45 @@
+
+
+6.4. Adding Members to a Project
6.4. 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.
+
6.4.1. 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”. 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”.
+
+ 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.
+
+ 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/add-password-management-to-templates.html b/docs/tmp/en-US/epub/OEBPS/add-password-management-to-templates.html
new file mode 100644
index 00000000000..9d7964dd222
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/add-password-management-to-templates.html
@@ -0,0 +1,31 @@
+
+
+12.13. Adding Password Management to Your Templates
12.13. Adding Password Management to Your Templates
+ CloudStack provides an optional password reset feature that allows users to set a temporary admin or root password as well as reset the existing admin or root password from the CloudStack UI.
+
+ To enable the Reset Password feature, you will need to download an additional script to patch your template. When you later upload the template into CloudStack, you can specify whether reset admin/root password feature should be enabled for this template.
+
+ The password management feature works always resets the account password on instance boot. The script does an HTTP call to the virtual router to retrieve the account password that should be set. As long as the virtual router is accessible the guest will have access to the account password that should be used. When the user requests a password reset the management server generates and sends a new password to the virtual router for the account. Thus an instance reboot is necessary to effect any password changes.
+
+ If the script is unable to contact the virtual router during instance boot it will not set the password but boot will continue normally.
+
12.13.1. Linux OS Installation
+ Use the following steps to begin the Linux OS installation:
+
+ Download the script file cloud-set-guest-password:
+
+ 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
+
diff --git a/docs/tmp/en-US/epub/OEBPS/advanced-zone-physical-network-configuration.html b/docs/tmp/en-US/epub/OEBPS/advanced-zone-physical-network-configuration.html
new file mode 100644
index 00000000000..e09864b9f69
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/advanced-zone-physical-network-configuration.html
@@ -0,0 +1,33 @@
+
+
+15.5. Advanced Zone Physical Network Configuration
15.5. Advanced Zone Physical Network Configuration
+ Within a zone that uses advanced networking, you need to tell the Management Server how the physical network is set up to carry different kinds of traffic in isolation.
+
15.5.1. Configure Guest Traffic in an Advanced Zone
+ These steps assume you have already logged in to the CloudStack UI. To configure the base guest network:
+
+ In the left navigation, choose Infrastructure. On Zones, click View More, then click the zone to which you want to add a network.
+
+ Click the Network tab.
+
+ Click Add guest network.
+
+ The Add guest network window is displayed:
+
+ Provide the following information:
+
+ Name. The name of the network. This will be user-visible
+
+ Display Text: The description of the network. This will be user-visible
+
+ Zone: The zone in which you are configuring the guest network.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network
+
+ Guest Gateway: The gateway that the guests should use
+
+ Guest Netmask: The netmask in use on the subnet the guests will use
+
+ Click OK.
+
15.5.2. Configure Public Traffic in an Advanced Zone
+ In a zone that uses advanced networking, you need to configure at least one range of IP addresses for Internet traffic.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/alerts.html b/docs/tmp/en-US/epub/OEBPS/alerts.html
new file mode 100644
index 00000000000..9a90447706c
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/alerts.html
@@ -0,0 +1,5 @@
+
+
+Appendix C. Alerts
Alerts
+ The following is the list of alert type numbers. The current alerts can be found by calling listAlerts.
+
MEMORY = 0
CPU = 1
STORAGE =2
STORAGE_ALLOCATED = 3
PUBLIC_IP = 4
PRIVATE_IP = 5
HOST = 6
USERVM = 7
DOMAIN_ROUTER = 8
CONSOLE_PROXY = 9
ROUTING = 10// lost connection to default route (to the gateway)
STORAGE_MISC = 11 // lost connection to default route (to the gateway)
USAGE_SERVER = 12 // lost connection to default route (to the gateway)
MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)
DOMAIN_ROUTER_MIGRATE = 14
CONSOLE_PROXY_MIGRATE = 15
USERVM_MIGRATE = 16
VLAN = 17
SSVM = 18
USAGE_SERVER_RESULT = 19
STORAGE_DELETE = 20;
UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource count
USAGE_SANITY_RESULT = 22;
DIRECT_ATTACHED_PUBLIC_IP = 23;
LOCAL_STORAGE = 24;
RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only
+ CloudStack enables administrators to write custom allocators that will choose the Host to place a new guest and the storage host from which to allocate guest virtual disk images.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/api-overview.html b/docs/tmp/en-US/epub/OEBPS/api-overview.html
new file mode 100644
index 00000000000..eb4edeb435a
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/api-overview.html
@@ -0,0 +1,15 @@
+
+
+Chapter 20. CloudStack API
Chapter 20. 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.
+
+ 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/appe-cloudstack-Revision_History.html b/docs/tmp/en-US/epub/OEBPS/appe-cloudstack-Revision_History.html
new file mode 100644
index 00000000000..d7d2d9618ba
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/appe-cloudstack-Revision_History.html
@@ -0,0 +1,9 @@
+
+
+Appendix D. Revision History
Revision History
+
Revision History
Revision 0-0
Tue May 29 2012
JessicaTomechak
+
Initial creation of book by publican
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/basic-zone-physical-network-configuration.html b/docs/tmp/en-US/epub/OEBPS/basic-zone-physical-network-configuration.html
new file mode 100644
index 00000000000..af10395eefc
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/basic-zone-physical-network-configuration.html
@@ -0,0 +1,5 @@
+
+
+15.4. Basic Zone Physical Network Configuration
15.4. Basic Zone Physical Network Configuration
+ In a basic network, configuring the physical network is fairly straightforward. You only need to configure one guest network to carry traffic that is generated by guest VMs. When you first add a zone to CloudPlatform, you set up the guest network through the Add Zone screens.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/best-practices-templates.html b/docs/tmp/en-US/epub/OEBPS/best-practices-templates.html
new file mode 100644
index 00000000000..4c9b31a0334
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/best-practices-templates.html
@@ -0,0 +1,5 @@
+
+
+12.3. Best Practices for Templates
12.3. Best Practices for Templates
+ If you plan to use large templates (100 GB or larger), be sure you have a 10-gigabit network to support the large templates. A slower network can lead to timeouts and other errors when large templates are used.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/best-practices-vm.html b/docs/tmp/en-US/epub/OEBPS/best-practices-vm.html
new file mode 100644
index 00000000000..aec5f4b78d1
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/best-practices-vm.html
@@ -0,0 +1,5 @@
+
+
+10.2. Best Practices for Virtual Machines
10.2. Best Practices for Virtual Machines
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/change-database-config.html b/docs/tmp/en-US/epub/OEBPS/change-database-config.html
new file mode 100644
index 00000000000..a361c1f3342
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/change-database-config.html
@@ -0,0 +1,5 @@
+
+
+18.2. Changing the Database Configuration
18.2. Changing the Database Configuration
+ The CloudStack Management Server stores database configuration information (e.g., hostname, port, credentials) in the file /etc/cloud/management/db.properties. To effect a change, edit this file on each Management Server, then restart the Management Server.
+
+ 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:
+
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".
+
mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;
diff --git a/docs/tmp/en-US/epub/OEBPS/changing-service-offering-for-vm.html b/docs/tmp/en-US/epub/OEBPS/changing-service-offering-for-vm.html
new file mode 100644
index 00000000000..5a25c5bf6bc
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/changing-service-offering-for-vm.html
@@ -0,0 +1,23 @@
+
+
+10.8. Changing the Service Offering for a VM
10.8. Changing the Service Offering for a VM
+ To upgrade or downgrade the level of compute resources available to a virtual machine, you can change the VM's compute offering.
+
+ Log in to the CloudStack UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to work with.
+
+ Click the Stop button to stop the VM
+
+
+
+ Click the Change Service button
+
+ . The Change service dialog box is displayed.
+
+ Select the offering you want.
+
+ Click OK.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/changing-vm-name-os-group.html b/docs/tmp/en-US/epub/OEBPS/changing-vm-name-os-group.html
new file mode 100644
index 00000000000..c187210fee9
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/changing-vm-name-os-group.html
@@ -0,0 +1,31 @@
+
+
+10.7. Changing the VM Name, OS, or Group
10.7. Changing the VM Name, OS, or Group
+ After a VM is created, you can modify the display name, operating system, and the group it belongs to.
+
+ To access a VM through the CloudStack UI:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Select the VM that you want to modify.
+
+ Click the Stop button to stop the VM
+
+
+
+ Click Edit
+
+ .
+
+ Make the desired changes to the following:
+
+ Display name: Enter a new display name if you want to change the name of the VM.
+
+ A zone is the largest organizational unit within a CloudStack deployment. A zone typically corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter. The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required).
+
+ A zone consists of:
+
+ One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
+
+ Secondary storage, which is shared by all the pods in the zone.
+
+ Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones.
+
+ Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone.
+
+ Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels.
+
+ For each zone, the administrator must decide the following.
+
+ How many pods to place in a zone.
+
+ How many clusters to place in each pod.
+
+ How many hosts to place in each cluster.
+
+ How many primary storage servers to place in each cluster and total capacity for the storage servers.
+
+ How much secondary storage to deploy in 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/cluster-add.html b/docs/tmp/en-US/epub/OEBPS/cluster-add.html
new file mode 100644
index 00000000000..8a914d8dce3
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/cluster-add.html
@@ -0,0 +1,61 @@
+
+
+7.4. Adding a Cluster
7.4. 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.
+
7.4.1. 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.
+
7.4.2. 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.
+
+ 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 values from vCenter.
+
+ Cluster Name. Enter the name of the cluster you created in vCenter. For example, "cloud.cluster.2.2.1"
+
+ vCenter Host. Enter the hostname or IP address of the vCenter server.
+
+ vCenter Username. Enter the username that CloudStack should use to connect to vCenter. This user must have all administrative privileges.
+
+ 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".
+
+ There might be a slight delay while the cluster is provisioned. It will automatically display in the UI
+
+ CloudStack is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. CloudStack manages the network, storage, and compute nodes that make up a cloud infrastructure. Use CloudStack to deploy, manage, and configure cloud computing environments.
+
+ Typical users are service providers and enterprises. With CloudStack, you can:
+
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with CloudStack an enterprise can offer self-service virtual machines to users without involving IT departments.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/configure-vpc.html b/docs/tmp/en-US/epub/OEBPS/configure-vpc.html
new file mode 100644
index 00000000000..67499761343
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/configure-vpc.html
@@ -0,0 +1,519 @@
+
+
+15.19. Configuring a Virtual Private Cloud
15.19. Configuring a Virtual Private Cloud
15.19.1. About Virtual Private Clouds
+ CloudStack Virtual Private Cloud is a private, isolated part of CloudStack. A VPC can have its own virtual network topology that resembles a traditional physical network. You can launch VMs in the virtual network that can have private addresses in the range of your choice, for example: 10.0.0.0/16. You can define network tiers within your VPC network range, which in turn enables you to group similar kinds of instances based on IP address range.
+
+ For example, if a VPC has the private range 10.0.0.0/16, its guest networks can have the network ranges 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on.
+
Major Components of a VPC:
+ A VPC is comprised of the following network components:
+
+ VPC: A VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router.
+
+ Network Tiers: Each tier acts as an isolated network with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
+
+ Virtual Router: A virtual router is automatically created and started when you create a VPC. The virtual router connect the tiers and direct traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and DHCP services through its IP.
+
+ Public Gateway: The traffic to and from the Internet routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to the end user; therefore, static routes are not support for the public gateway.
+
+ In a VPC, the following four basic options of network architectures are present:
+
+ VPC with a public gateway only
+
+ VPC with public and private gateways
+
+ VPC with public and private gateways and site-to-site VPN access
+
+ VPC with a private gateway only and site-to-site VPN access
+
Connectivity Options for a VPC
+ You can connect your VPC to:
+
+ The Internet through the public gateway.
+
+ The corporate datacenter by using a site-to-site VPN connection through the VPN gateway.
+
+ Both the Internet and your corporate datacenter by using both the public gateway and a VPN gateway.
+
VPC Network Considerations
+ Consider the following before you create a VPC:
+
+ A VPC, by default, is created in the enabled state.
+
+ A VPC can be created in Advance zone only, and can't belong to more than one zone at a time.
+
+ The default number of VPCs an account can create is 20. However, you can change it by using the max.account.vpcs global parameter, which controls the maximum number of VPCs an account is allowed to create.
+
+ The default number of tiers an account can create within a VPC is 3. You can configure this number by using the vpc.max.networks parameter.
+
+ Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be within the VPC CIDR range.
+
+ A tier belongs to only one VPC.
+
+ All network tiers inside the VPC should belong to the same account.
+
+ When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP is released only when the VPC is removed.
+
+ A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it cannot be used for StaticNAT or port forwarding.
+
+ The instances only have a private IP address that you provision. To communicate with the Internet, enable NAT to an instance that you launch in your VPC.
+
+ Only new networks can be added to a VPC. The maximum number of networks per VPC is limited by the value you specify in the vpc.max.networks parameter. The default value is three.
+
+ The load balancing service can be supported by only one tier inside the VPC.
+
+ If an IP address is assigned to a tier:
+
+ That IP can't be used by more than one tier at a time in the VPC. For example, if you have tiers A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A or B, but not for both.
+
+ That IP can't be used for StaticNAT, load balancing, or port forwarding rules for another guest network inside the VPC.
+
+ Remote access VPN is not supported in VPC networks.
+
15.19.2. Adding a Virtual Private Cloud
+ When creating the VPC, you simply provide the zone and a set of IP addresses for the VPC network address space. You specify this set of addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ Click Add VPC. The Add VPC page is displayed as follows:
+
+ Provide the following information:
+
+ Name: A short name for the VPC that you are creating.
+
+ Description: A brief description of the VPC.
+
+ Zone: Choose the zone where you want the VPC to be available.
+
+ Super CIDR for Guest Networks: Defines the CIDR range for all the tiers (guest networks) within a VPC. When you create a tier, ensure that its CIDR is within the Super CIDR value you enter. The CIDR must be RFC1918 compliant.
+
+ DNS domain for Guest Networks: If you want to assign a special domain name, specify the DNS suffix. This parameter is applied to all the tiers within the VPC. That implies, all the tiers you create in the VPC belong to the same DNS domain. If the parameter is not specified, a DNS domain name is generated automatically.
+
15.19.3. Adding Tiers
+ Tiers are distinct locations within a VPC that act as isolated networks, which do not have access to other tiers by default. Tiers are set up on different VLANs that can communicate with each other by using a virtual router. Tiers provide inexpensive, low latency network connectivity to other tiers within the VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
Note
+ The end users can see their own VPCs, while root and domain admin can see any VPC they are authorized to see.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Add new tier dialog is displayed, as follows:
+
+ If you have already created tiers, the VPC diagram is displayed. Click Create Tier to add a new tier.
+
+ Specify the following:
+
+ All the fields are mandatory.
+
+ Name: A unique name for the tier you create.
+
+ Network Offering: The following default network offerings are listed: DefaultIsolatedNetworkOfferingForVpcNetworksNoLB, DefaultIsolatedNetworkOfferingForVpcNetworks
+
+ In a VPC, only one tier can be created by using LB-enabled network offering.
+
+ Gateway: The gateway for the tier you create. Ensure that the gateway is within the Super CIDR range that you specified while creating the VPC, and is not overlapped with the CIDR of any existing tier within the VPC.
+
+ Netmask: The netmask for the tier you create.
+
+ For example, if the VPC CIDR is 10.0.0.0/16 and the network tier CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the netmask of the tier is 255.255.255.0.
+
+ Click OK.
+
+ Continue with configuring access control list for the tier.
+
15.19.4. Configuring Access Control List
+ Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service is supported.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Network ACLs.
+
+ The Network ACLs page is displayed.
+
+ Click Add Network ACLs.
+
+ To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed in this tier.
+
+ CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or to the IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Protocol: The networking protocol that sources use to send traffic to the tier. The TCP and UDP protocols are typically used for data exchange and end-user communications. The ICMP protocol is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ Select Tier: Select the tier for which you want to add this ACL rule.
+
+ ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
+
+ Traffic Type: Select the traffic type you want to apply.
+
+ Egress: To add an egress rule, select Egress from the Traffic type drop-down box and click Add. This specifies what type of traffic is allowed to be sent out of VM instances in this tier. If no egress rules are specified, all traffic from the tier is allowed out at the VPC virtual router. Once egress rules are specified, only the traffic specified in egress rules and the responses to any traffic that has been allowed in through an ingress rule are allowed out. No egress rule is required for the VMs in a tier to communicate with each other.
+
+ Ingress: To add an ingress rule, select Ingress from the Traffic type drop-down box and click Add. This specifies what network traffic is allowed into the VM instances in this tier. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
Note
+ By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, create a new network ACL.
+
+ Click Add. The ACL rule is added.
+
+ To view the list of ACL rules you have added, click the desired tier from the Network ACLs page, then select the Network ACL tab.
+
+ You can edit the tags assigned to the ACL rules and delete the ACL rules you have created. Click the appropriate button in the Actions column.
+
15.19.5. Adding a Private Gateway to a VPC
+ A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. No gateways with duplicated VLAN and IP are allowed in the same data center.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Private Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Private Gateways.
+
+ The Gateways page is displayed.
+
+ Click Add new gateway:
+
+ Specify the following:
+
+ Physical Network: The physical network you have created in the zone.
+
+ IP Address: The IP address associated with the VPC gateway.
+
+ Gateway: The gateway through which the traffic is routed to and from the VPC.
+
+ Netmask: The netmask associated with the VPC gateway.
+
+ VLAN: The VLAN associated with the VPC gateway.
+
+ The new gateway appears in the list. You can repeat these steps to add more gateway for this VPC.
+
15.19.6. Deploying VMs to the Tier
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed.
+
+ Click the Add VM button of the tier for which you want to add a VM.
+
+ The Add Instance page is displayed.
+
+ Follow the on-screen instruction to add an instance. For information on adding an instance, see Adding Instances section in the Installation Guide.
+
15.19.7. Acquiring a New IP Address for a VPC
+ When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks within the VPC. The IPs are associated to the guest network only when the first port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP can't be associated to more than one network at a time.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding, load balancing, and static NAT rules.
+
15.19.8. Releasing an IP Address Alloted to a VPC
+ The IP address is a limited resource. If you no longer need a particular IP, you can disassociate it from its VPC and return it to the pool of available addresses. An IP address can be released from its tier, only when all the networking ( port forwarding, load balancing, or StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC whose IP you want to release.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to release.
+
+ In the Details tab, click the Release IP button
+
+
15.19.9. Enabling or Disabling Static NAT on a VPC
+ A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to allow Internet traffic to it. This section tells how to enable or disable static NAT for a particular IP address in a VPC.
+
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to work with.
+
+ In the Details tab,click the Static NAT button.
+
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+
+ If you are enabling static NAT, a dialog appears as follows:
+
+ Select the tier and the destination VM, then click Apply.
+
15.19.10. Adding Load Balancing Rules on a VPC
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Load Balancing node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
Note
+ In a VPC, the load balancing service is supported only on a single tier.
+
+ Specify the following:
+
+ Name: A name for the load balancer rule.
+
+ Public Port: The port that receives the incoming traffic to be balanced.
+
+ Private Port: The port that the VMs will use to receive the traffic.
+
+ Algorithm. Choose the load balancing algorithm you want CloudStack to use. CloudStack supports the following well-known algorithms:
+
+ Round-robin
+
+ Least connections
+
+ Source
+
+ Stickiness. (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
+
+ Add VMs: Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.
+
+ The new load balancing rule appears in the list. You can repeat these steps to add more load balancing rules for this IP address.
+
15.19.11. Adding a Port Forwarding Rule on a VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Choose an existing IP address or acquire a new IP address. Click the name of the IP address in the list.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Port Forwarding node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
+ Specify the following:
+
+ Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+
+ Private Port: The port on which the instance is listening for forwarded public traffic.
+
+ Protocol: The communication protocol in use between the two ports.
+
+ TCP
+
+ UDP
+
+ Add VM: Click Add VM. Select the name of the instance to which this rule applies, and click Apply.
+
+ You can test the rule by opening an ssh session to the instance.
+
15.19.12. Removing Tiers
+ You can remove a tier from a VPC. A removed tier cannot be revoked. When a tier is removed, only the resources of the tier are expunged. All the network rules (port forwarding, load balancing and staticNAT) and the IP addresses associated to the tier are removed. The IP address still be belonging to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Configure VPC page is displayed. Locate the tier you want to work with.
+
+ Click the Remove VPC button:
+
+ Wait for some time for the tier to be removed.
+
15.19.13. Editing, Restarting, and Removing a Virtual Private Cloud
Note
+ Ensure that all the tiers are removed before you remove a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Select the VPC you want to work with.
+
+ To remove, click the Remove VPC button
+
+
+ You can edit the name and description of a VPC. To do that, select the VPC, then click the Edit button.
+
+
+ To restart a VPC, select the VPC, then click the Restart button.
+
+
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+
+ Before CloudPlatform users start using projects, the CloudPlatform administrator must set up various systems to support them, including membership invitations, limits on project resources, and controls on who can create projects.
+
6.2.1. 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.
+
+ In the search box, type project and click the search button.
+
+
+ In the search results, you will 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
+
service cloud-management restart
6.2.2. 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
+
6.2.2.1. 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”). 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.
+
6.2.2.2. 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.
+
+
+
+ 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.
+
# service cloud-management restart
6.2.3. 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.
+
+
+
+ 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.
+
+ The Console Proxy is a type of System Virtual Machine that has a role in presenting a console view via the web UI. It connects the user’s browser to the VNC port made available via the hypervisor for the console of the guest. Both the administrator and end user web UIs offer a console connection.
+
+ Clicking on a console icon brings up a new window. The AJAX code downloaded into that window refers to the public IP address of a console proxy VM. There is exactly one public IP address allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then proxies the connection to the VNC port for the requested VM on the Host hosting the guest. .
+
Note
+ The hypervisors will have many ports assigned to VNC usage so that multiple VNC sessions can occur simultaneously.
+
+ There is never any traffic to the guest virtual IP, and there is no need to enable VNC within the guest.
+
+ The console proxy VM will periodically report its active session count to the Management Server. The default reporting interval is five seconds. This can be changed through standard Management Server configuration with the parameter consoleproxy.loadscan.interval.
+
+ Assignment of guest VM to console proxy is determined by first determining if the guest VM has a previous session associated with a console proxy. If it does, the Management Server will assign the guest VM to the target Console Proxy VM regardless of the load on the proxy VM. Failing that, the first available running Console Proxy VM that has the capacity to handle new sessions is used.
+
+ Console proxies can be restarted by administrators but this will interrupt existing console sessions for users.
+
+ The console viewing functionality uses a dynamic DNS service under the domain name realhostip.com to assist in providing SSL security to console sessions. The console proxy is assigned a public IP address. In order to avoid browser warnings for mismatched SSL certificates, the URL for the new console window is set to the form of https://aaa-bbb-ccc-ddd.realhostip.com. Customers will see this URL during console session creation. CloudStack includes the realhostip.com SSL certificate in the console proxy VM. Of course, CloudStack cannot know about DNS A records for our customers' public IPs prior to shipping the software. CloudStack therefore runs a dynamic DNS server that is authoritative for the realhostip.com domain. It maps the aaa-bbb-ccc-ddd part of the DNS name to the IP address aaa.bbb.ccc.ddd on lookups. This allows the browser to correctly connect to the console proxy's public IP, where it then expects and receives a SSL certificate for realhostip.com, and SSL is set up without browser warnings.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/content.opf b/docs/tmp/en-US/epub/OEBPS/content.opf
new file mode 100644
index 00000000000..88080bf99a8
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/content.opf
@@ -0,0 +1,2 @@
+
+4.0.0-incubating_idp705856CloudStack Administrator's GuideAdministration Guide for CloudStack.Apache CloudStacken
diff --git a/docs/tmp/en-US/epub/OEBPS/convert-hyperv-vm-to-template.html b/docs/tmp/en-US/epub/OEBPS/convert-hyperv-vm-to-template.html
new file mode 100644
index 00000000000..2db1084ed49
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/convert-hyperv-vm-to-template.html
@@ -0,0 +1,61 @@
+
+
+12.12. Converting a Hyper-V VM to a Template
12.12. Converting a Hyper-V VM to a Template
+ To convert a Hyper-V VM to a XenServer-compatible CloudStack template, you will need a standalone XenServer host with an attached NFS VHD SR. Use whatever XenServer version you are using with CloudStack, but use XenCenter 5.6 FP1 or SP2 (it is backwards compatible to 5.6). Additionally, it may help to have an attached NFS ISO SR.
+
+ For Linux VMs, you may need to do some preparation in Hyper-V before trying to get the VM to work in XenServer. Clone the VM and work on the clone if you still want to use the VM in Hyper-V. Uninstall Hyper-V Integration Components and check for any references to device names in /etc/fstab:
+
+ From the linux_ic/drivers/dist directory, run make uninstall (where "linux_ic" is the path to the copied Hyper-V Integration Components files).
+
+ Restore the original initrd from backup in /boot/ (the backup is named *.backup0).
+
+ Remove the "hdX=noprobe" entries from /boot/grub/menu.lst.
+
+ Check /etc/fstab for any partitions mounted by device name. Change those entries (if any) to mount by LABEL or UUID (get that information with the "blkid" command)..
+
+ The next step is make sure the VM is not running in Hyper-V, then get the VHD into XenServer. There are two options for doing this.
+
+ Option one:
+
+ Import the VHD using XenCenter. In XenCenter, go to Tools>Virtual Appliance Tools>Disk Image Import.
+
+ Choose the VHD, then click Next.
+
+ Name the VM, choose the NFS VHD SR under Storage, enable "Run Operating System Fixups" and choose the NFS ISO SR.
+
+ Click Next, then Finish. A VM should be created.
+
+ Option two
+
+ Run XenConvert, under From choose VHD, under To choose XenServer. Click Next.
+
+ Choose the VHD, then click Next.
+
+ Input the XenServer host info, then click Next.
+
+ Name the VM, then click Next, then Convert. A VM should be created
+
+ Once you have a VM created from the Hyper-V VHD, prepare it using the following steps:
+
+ Boot the VM, uninstall Hyper-V Integration Services, and reboot.
+
+ Either option above will create a VM in HVM mode. This is fine for Windows VMs, but Linux VMs may not perform optimally. Converting a Linux VM to PV mode will require additional steps and will vary by distribution.
+
+ Shut down the VM and copy the VHD from the NFS storage to a web server; for example, mount the NFS share on the web server and copy it, or from the XenServer host use sftp or scp to upload it to the web server.
+
+ In CloudStack, create a new template using the following values:
+
+ URL. Give the URL for the VHD
+
+ OS Type. Use the appropriate OS. For PV mode on CentOS, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServer.
+
+ Hypervisor. XenServer
+
+ Format. VHD
+
+ The template will be created, and you can create instances from it.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/create-new-projects.html b/docs/tmp/en-US/epub/OEBPS/create-new-projects.html
new file mode 100644
index 00000000000..0eccc4ddc9f
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/create-new-projects.html
@@ -0,0 +1,19 @@
+
+
+6.3. Creating a New Project
6.3. 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/create-template-from-existing-vm.html b/docs/tmp/en-US/epub/OEBPS/create-template-from-existing-vm.html
new file mode 100644
index 00000000000..e929109aff0
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/create-template-from-existing-vm.html
@@ -0,0 +1,33 @@
+
+
+12.6. Creating a Template from an Existing Virtual Machine
12.6. Creating a Template from an Existing Virtual Machine
+ Once you have at least one VM set up in the way you want, you can use it as the prototype for other VMs.
+
+ Make any desired configuration changes on the running VM, then click Stop.
+
+ Wait for the VM to stop. When the status shows Stopped, go to the next step.
+
+ Click Create Template and provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ OS Type. This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
+ If you want to boot from this template in PV mode, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServere:
+
Note
+ Note: Generally you should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates.
+
+ Click Add.
+
+ The new template will be visible in the Templates section when the template creation process has been completed. The template is then available when creating a new VM
+
diff --git a/docs/tmp/en-US/epub/OEBPS/create-template-from-snapshot.html b/docs/tmp/en-US/epub/OEBPS/create-template-from-snapshot.html
new file mode 100644
index 00000000000..fab9c8d79ed
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/create-template-from-snapshot.html
@@ -0,0 +1,5 @@
+
+
+12.7. Creating a Template from a Snapshot
diff --git a/docs/tmp/en-US/epub/OEBPS/create-windows-template.html b/docs/tmp/en-US/epub/OEBPS/create-windows-template.html
new file mode 100644
index 00000000000..8060e98903c
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/create-windows-template.html
@@ -0,0 +1,117 @@
+
+
+12.10. Creating a Windows Template
12.10. Creating a Windows Template
+ Windows templates must be prepared with Sysprep before they can be provisioned on multiple machines. Sysprep allows you to create a generic Windows template and avoid any possible SID conflicts.
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Follow the steps in Sysprep for Windows Server 2008 R2 (below) or Sysprep for Windows Server 2003 R2, depending on your version of Windows Server
+
+ The preparation steps are complete. Now you can actually create the template as described in Creating the Windows Template.
+
12.10.1. System Preparation for Windows Server 2008 R2
+ For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location:
+
+ Windows AIK should not be installed on the Windows 2008 R2 VM you just created. Windows AIK should not be part of the template you create. It is only used to create the sysprep answer file.
+
+ Copy the install.wim file in the \sources directory of the Windows 2008 R2 installation DVD to the hard disk. This is a very large file and may take a long time to copy. Windows AIK requires the WIM file to be writable.
+
+ Start the Windows System Image Manager, which is part of the Windows AIK.
+
+ In the Windows Image pane, right click “Select a Windows image or catalog file” to load the install.wim file you just copied.
+
+ Select the Windows 2008 R2 Edition
+
+ You may be prompted with a warning that the catalog file cannot be opened. Click Yes to create a new catalog file.
+
+ In the Answer File pane, right click to create a new answer file.
+
+ Generate the answer file from the Windows System Image Manager using the following steps:
+
+ The first page you need to automate is the Language and Country or Region Selection page. To automate this, expand Components in your Windows Image pane, right-click and add the Microsoft-Windows-International-Core setting to Pass 7 oobeSystem. In your Answer File pane, configure the InputLocale, SystemLocale, UILanguage, and UserLocale with the appropriate settings for your language and country or region. Should you have a question about any of these settings, you can right-click on the specific setting and select Help. This will open the appropriate CHM help file with more information, including examples on the setting you are attempting to configure.
+
+ You need to automate the Software License Terms Selection page, otherwise known as the End-User License Agreement (EULA). To do this, expand the Microsoft-Windows-Shell-Setup component. High-light the OOBE setting, and add the setting to the Pass 7 oobeSystem. In Settings, set HideEULAPage true.
+
+ Make sure the license key is properly set. If you use MAK key, you can just enter the MAK key on the Windows 2008 R2 VM. You need not input the MAK into the Windows System Image Manager. If you use KMS host for activation you need not enter the Product Key. Details of Windows Volume Activation can be found at http://technet.microsoft.com/en-us/library/bb892849.aspx
+
+ You need to automate is the Change Administrator Password page. Expand the Microsoft-Windows-Shell-Setup component (if it is not still expanded), expand UserAccounts, right-click on AdministratorPassword, and add the setting to the Pass 7 oobeSystem configuration pass of your answer file. Under Settings, specify a password next to Value.
+
+ You may read the AIK documentation and set many more options that suit your deployment. The steps above are the minimum needed to make Windows unattended setup work.
+
+ Save the answer file as unattend.xml. You can ignore the warning messages that appear in the validation window.
+
+ Copy the unattend.xml file into the c:\windows\system32\sysprep directory of the Windows 2008 R2 Virtual Machine
+
+ Once you place the unattend.xml file in c:\windows\system32\sysprep directory, you run the sysprep tool as follows:
+
cd c:\Windows\System32\sysprep
+sysprep.exe /oobe /generalize /shutdown
+
+ The Windows 2008 R2 VM will automatically shut down after sysprep is complete.
+
12.10.2. Sysprep for Windows Server 2003 R2
+ Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2.
+
+ Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM.
+
+ Run c:\sysprep\setupmgr.exe to create the sysprep.inf file.
+
+ Select Create New to create a new Answer File.
+
+ Enter “Sysprep setup” for the Type of Setup.
+
+ Select the appropriate OS version and edition.
+
+ On the License Agreement screen, select “Yes fully automate the installation”.
+
+ Provide your name and organization.
+
+ Leave display settings at default.
+
+ Set the appropriate time zone.
+
+ Provide your product key.
+
+ Select an appropriate license mode for your deployment
+
+ Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up.
+
+ Leave Network Components at “Typical Settings”.
+
+ Select the “WORKGROUP” option.
+
+ Leave Telephony options at default.
+
+ Select appropriate Regional Settings.
+
+ Select appropriate language settings.
+
+ Do not install printers.
+
+ Do not specify “Run Once commands”.
+
+ You need not specify an identification string.
+
+ Save the Answer File as c:\sysprep\sysprep.inf.
+
+ Run the following command to sysprep the image:
+
c:\sysprep\sysprep.exe -reseal -mini -activated
+ After this step the machine will automatically shut down
+
+ Virtual machines are usually created from a template. Users can also create blank virtual machines. A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and install the OS from the CD/DVD-ROM.
+
+ To create a VM from a template:
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select a template, then follow the steps in the wizard. (For more information about how the templates came to be in this list, see Working with Templates.
+
+ Be sure that the hardware you have allows starting the selected service offering.
+
+ Click Submit and your VM will be created and started.
+
Note
+ For security reason, the internal name of the VM is visible only to the root admin.
+
Note
+ Starting with v3.0.3, you can create a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A new request parameter, startVM, is introduced in the deployVm API to support this feature. For more information, see the Developer's Guide
+
+ To create a VM from an ISO:
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select ISO Boot, and follow the steps in the wizard.
+
+ Click Submit and your VM will be created and started.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/customizing-dns.html b/docs/tmp/en-US/epub/OEBPS/customizing-dns.html
new file mode 100644
index 00000000000..5a085e437e5
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/customizing-dns.html
@@ -0,0 +1,25 @@
+
+
+18.4. Customizing the Network Domain Name
18.4. 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” 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.
+
+ You can limit resource use by accounts. The default limits are set using global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account (max.account.snapshots, etc.)..
+
+ To override a default limit for a particular account, set a per-account resource limit.
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Accounts.
+
+ Select the account you want to modify. The current limits are displayed. A value of -1 shows that there is no limit in place
+
+ Click the Edit button
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/default-template.html b/docs/tmp/en-US/epub/OEBPS/default-template.html
new file mode 100644
index 00000000000..9c9791bedb0
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/default-template.html
@@ -0,0 +1,35 @@
+
+
+12.4. The Default Template
12.4. The Default Template
+ CloudStack includes a CentOS template. This template is downloaded by the Secondary Storage VM after the primary and secondary storage are configured. You can use this template in your production deployment or you can delete it and use custom templates.
+
+ The root password for the default template is "password".
+
+ A default template is provided for each of XenServer, KVM, and vSphere. The templates that are downloaded depend on the hypervisor type that is available in your cloud. Each template is approximately 2.5 GB physical size.
+
+ The default template includes the standard iptables rules, which will block most access to the template excluding ssh.
+
+ Templates may be deleted. In general, when a template spans multiple Zones, only the copy that is selected for deletion will be deleted; the same template in other Zones will not be deleted. The provided CentOS template is an exception to this. If the provided CentOS template is deleted, it will be deleted from all Zones.
+
+ When templates are deleted, the VMs instantiated from them will continue to run. However, new VMs cannot be created based on the deleted template.
+
+ Users can delete their own virtual machines. A running virtual machine will be abruptly stopped before it is deleted. Administrators can delete any virtual machines.
+
+ To delete a virtual machine:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ A CloudStack installation consists of two parts: the Management Server and the cloud infrastructure that it manages. When you set up and manage a CloudStack cloud, you provision resources such as hosts, storage devices, and IP addresses into the Management Server, and the Management Server manages those resources.
+
+ The minimum production installation consists of one machine running the CloudStack Management Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure consisting of one host running hypervisor software). In its smallest deployment, a single machine can act as both the Management Server and the hypervisor host (using the KVM hypervisor).
+
+ A more full-featured installation consists of a highly-available multi-node Management Server installation and up to tens of thousands of hosts using any of several advanced networking setups. For information about deployment options, see Choosing a Deployment Architecture.
+
1.3.1. Management Server Overview
+ The Management Server is the CloudStack software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+ The machine must meet the system requirements described in System Requirements.
+
+ The Management Server:
+
+ Provides the web user interface for the administrator and a reference user interface for end users.
+
+ Provides the APIs for CloudStack.
+
+ Manages the assignment of guest VMs to particular hosts.
+
+ Manages the assignment of public and private IP addresses to particular accounts.
+
+ Manages the allocation of storage to guests as virtual disks.
+
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+
+ Provides a single point of configuration for the cloud.
+
1.3.2. Cloud Infrastructure Overview
+ The Management Server manages one or more zones (typically, datacenters) containing host computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
+
+ Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
+
+ Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
+
+ Cluster: A cluster consists of one or more hosts and primary storage.
+
+ Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines.
+
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster.
+
+ Secondary storage is associated with a zone, and it stores templates, ISO images, and disk volume snapshots.
+
+ More Information
+
+ For more information, see documentation on cloud infrastructure concepts.
+
1.3.3. Networking Overview
+ CloudStack offers two types of networking scenario:
+
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+ For more details, see Network Setup.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/disable-enable-zones-pods-clusters.html b/docs/tmp/en-US/epub/OEBPS/disable-enable-zones-pods-clusters.html
new file mode 100644
index 00000000000..39f1873724c
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/disable-enable-zones-pods-clusters.html
@@ -0,0 +1,28 @@
+
+
+11.3. Disabling and Enabling Zones, Pods, and Clusters
11.3. 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.
+
+
+
+ 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.
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/dns-dhcp.html b/docs/tmp/en-US/epub/OEBPS/dns-dhcp.html
new file mode 100644
index 00000000000..ee0846a09ad
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/dns-dhcp.html
@@ -0,0 +1,5 @@
+
+
+15.16. DNS and DHCP
15.16. DNS and DHCP
+ The Virtual Router provides DNS and DHCP services to the guests. It proxies DNS requests to the DNS server configured on the Availability Zone.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/event-types.html b/docs/tmp/en-US/epub/OEBPS/event-types.html
new file mode 100644
index 00000000000..f972ce1f162
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/event-types.html
@@ -0,0 +1,446 @@
+
+
+Appendix B. Event Types
+ End users and Administrators may export templates from the CloudStack. Navigate to the template in the UI and choose the Download function from the Actions menu.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/external-firewalls-and-load-balancers.html b/docs/tmp/en-US/epub/OEBPS/external-firewalls-and-load-balancers.html
new file mode 100644
index 00000000000..1f0932427e4
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/external-firewalls-and-load-balancers.html
@@ -0,0 +1,5 @@
+
+
+15.8. External Firewalls and Load Balancers
15.8. External Firewalls and Load Balancers
+ CloudStack is capable of replacing its Virtual Router with an external Juniper SRX device and an optional external NetScaler or F5 load balancer for gateway and load balancing services. In this case, the VMs use the SRX as their gateway.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/feature-overview.html b/docs/tmp/en-US/epub/OEBPS/feature-overview.html
new file mode 100644
index 00000000000..1b13aed7b63
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/feature-overview.html
@@ -0,0 +1,31 @@
+
+
+1.2. What Can CloudStack Do?
1.2. What Can CloudStack Do?
+ Multiple Hypervisor Support
+
+ CloudStack works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of CloudStack supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+ Massively Scalable Infrastructure Management
+
+ CloudStack can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+ Automatic Configuration Management
+
+ CloudStack automatically configures each guest virtual machine’s networking and storage settings.
+
+ CloudStack internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+ Graphical User Interface
+
+ CloudStack offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+ API and Extensibility
+
+ CloudStack provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at Apache CloudStack Guides and Apache CloudStack API Reference respectively.
+
+ CloudStack has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the hosts, CloudStack supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/global-config.html b/docs/tmp/en-US/epub/OEBPS/global-config.html
new file mode 100644
index 00000000000..d88cefb1819
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/global-config.html
@@ -0,0 +1,19 @@
+
+
+Chapter 19. Setting Global Configuration Parameters
Chapter 19. Setting Global Configuration Parameters
+ CloudStack provides parameters that you can set to control many aspects of the cloud. When CloudStack is first installed, and periodically thereafter, you might need to modify these settings.
+
+ Log in to the UI as administrator.
+
+ In the left navigation bar, click Global Settings.
+
+ In Select View, choose one of the following:
+
+ Global Settings. This displays a list of the parameters with brief descriptions and current values.
+
+ Hypervisor Capabilities. This displays a list of hypervisor versions with the maximum number of guests supported for each.
+
+ Use the search box to narrow down the list to those you are interested in.
+
+ Click the Edit icon to modify a value. If you are viewing Hypervisor Capabilities, you must click the name of the hypervisor first to display the editing screen.
+
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+
+ The following table lists limits set in the Global Configuration:
+
+
+ Parameter Name
+
+
+
+ Definition
+
+
+
+ max.account.public.ips
+
+
+
+ Number of public IP addresses that can be owned by an account
+
+
+
+ max.account.snapshots
+
+
+
+ Number of snapshots that can exist for an account
+
+
+
+ max.account.templates
+
+
+
+ Number of templates that can exist for an account
+
+
+
+ max.account.user.vms
+
+
+
+ Number of virtual machine instances that can exist for an account
+
+
+
+ max.account.volumes
+
+
+
+ Number of disk volumes that can exist for an account
+
+
+
+ max.template.iso.size
+
+
+
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+ max.volume.size.gb
+
+
+
+ Maximum size for a volume in GB
+
+
+
+ network.throttling.rate
+
+
+
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+
+ snapshot.max.hourly
+
+
+
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+ snapshot.max.daily
+
+
+
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+
+ snapshot.max.weekly
+
+
+
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+ snapshot.max.monthly
+
+
+
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+ To modify global configuration parameters, use the global configuration screen in the CloudStack UI. See Setting Global Configuration Parameters
+
diff --git a/docs/tmp/en-US/epub/OEBPS/guest-ip-ranges.html b/docs/tmp/en-US/epub/OEBPS/guest-ip-ranges.html
new file mode 100644
index 00000000000..291c62fb73f
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/guest-ip-ranges.html
@@ -0,0 +1,5 @@
+
+
+15.10. Guest IP Ranges
15.10. Guest IP Ranges
+ The IP ranges for guest network traffic are set on a per-account basis by the user. This allows the users to configure their network in a fashion that will enable VPN linking between their guest network and their clients.
+
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/ha-for-hosts.html b/docs/tmp/en-US/epub/OEBPS/ha-for-hosts.html
new file mode 100644
index 00000000000..e400cbcef97
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/ha-for-hosts.html
@@ -0,0 +1,7 @@
+
+
+17.3. HA for Hosts
17.3. HA for Hosts
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/host-add.html b/docs/tmp/en-US/epub/OEBPS/host-add.html
new file mode 100644
index 00000000000..681a8956c90
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/host-add.html
@@ -0,0 +1,75 @@
+
+
+7.5. Adding a Host
7.5. 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.
+
+ 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/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+
+ Run the script:
+
# ./cloud-setup-bonding.sh
7.5.1.1.2. 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.
+
7.5.1.2. 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 delay while the host is provisioned. It should automatically display in the UI.
+
+ Repeat for additional hosts.
+
7.5.2. Adding a Host (vSphere)
+ For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the entire cluster to CloudStack. See Add Cluster: vSphere.
+
+ The system automatically picks the most appropriate host to run each virtual machine. End users may specify the zone in which the virtual machine will be created. End users do not have control over which host will run the virtual machine instance.
+
+ CloudStack administrators can specify that certain hosts should have a preference for particular types of guest instances. For example, an administrator could state that a host should have a preference to run Windows guests. The default host allocator will attempt to place guests of that OS type on such hosts first. If no such host is available, the allocator will place the instance wherever there is sufficient physical capacity.
+
+ Both vertical and horizontal allocation is allowed. Vertical allocation consumes all the resources of a given host before allocating any guests on a second host. This reduces power consumption in the cloud. Horizontal allocation places a guest on each host in a round-robin fashion. This may yield better performance to the guests in some cases. CloudStack also allows an element of CPU over-provisioning as configured by the administrator. Over-provisioning allows the administrator to commit more CPU cycles to the allocated guests than are actually available from the hardware.
+
+ CloudStack also provides a pluggable interface for adding new allocators. These custom allocators can provide any policy the administrator desires.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/images/1000-foot-view.png b/docs/tmp/en-US/epub/OEBPS/images/1000-foot-view.png
new file mode 100644
index 00000000000..2fe3c1658b3
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/1000-foot-view.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/add-cluster.png b/docs/tmp/en-US/epub/OEBPS/images/add-cluster.png
new file mode 100644
index 00000000000..383f375ebed
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/add-cluster.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/add-gateway.png b/docs/tmp/en-US/epub/OEBPS/images/add-gateway.png
new file mode 100644
index 00000000000..da8eed955f5
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/add-gateway.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/add-guest-network.png b/docs/tmp/en-US/epub/OEBPS/images/add-guest-network.png
new file mode 100644
index 00000000000..5740ab58d32
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/add-guest-network.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/add-new-gateway-vpc.png b/docs/tmp/en-US/epub/OEBPS/images/add-new-gateway-vpc.png
new file mode 100644
index 00000000000..f15b778e0f2
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/add-new-gateway-vpc.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/add-tier.png b/docs/tmp/en-US/epub/OEBPS/images/add-tier.png
new file mode 100644
index 00000000000..881671e2133
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/add-tier.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/add-vpc.png b/docs/tmp/en-US/epub/OEBPS/images/add-vpc.png
new file mode 100644
index 00000000000..6b9c6379d9f
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/add-vpc.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/add-vpn-customer-gateway.png b/docs/tmp/en-US/epub/OEBPS/images/add-vpn-customer-gateway.png
new file mode 100644
index 00000000000..fdc3177e9eb
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/add-vpn-customer-gateway.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/attach-disk-icon.png b/docs/tmp/en-US/epub/OEBPS/images/attach-disk-icon.png
new file mode 100644
index 00000000000..5e81d04fda2
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/attach-disk-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/autoscale-config.png b/docs/tmp/en-US/epub/OEBPS/images/autoscale-config.png
new file mode 100644
index 00000000000..735ae961f81
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/autoscale-config.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/basic-deployment.png b/docs/tmp/en-US/epub/OEBPS/images/basic-deployment.png
new file mode 100644
index 00000000000..894a05327bf
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/basic-deployment.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/change-admin-password.png b/docs/tmp/en-US/epub/OEBPS/images/change-admin-password.png
new file mode 100644
index 00000000000..938e8616a35
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/change-admin-password.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/change-password.png b/docs/tmp/en-US/epub/OEBPS/images/change-password.png
new file mode 100644
index 00000000000..fbb203a5e25
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/change-password.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/change-service-icon.png b/docs/tmp/en-US/epub/OEBPS/images/change-service-icon.png
new file mode 100644
index 00000000000..780e235f2f5
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/change-service-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/cluster-overview.png b/docs/tmp/en-US/epub/OEBPS/images/cluster-overview.png
new file mode 100644
index 00000000000..33f1a0477ef
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/cluster-overview.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/console-icon.png b/docs/tmp/en-US/epub/OEBPS/images/console-icon.png
new file mode 100644
index 00000000000..bf288869745
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/console-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/create-vpn-connection.png b/docs/tmp/en-US/epub/OEBPS/images/create-vpn-connection.png
new file mode 100644
index 00000000000..cd5515f53c7
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/create-vpn-connection.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/delete-button.png b/docs/tmp/en-US/epub/OEBPS/images/delete-button.png
new file mode 100644
index 00000000000..27145cebbc7
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/delete-button.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/destroy-instance.png b/docs/tmp/en-US/epub/OEBPS/images/destroy-instance.png
new file mode 100644
index 00000000000..aa9846cfd9b
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/destroy-instance.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/detach-disk-icon.png b/docs/tmp/en-US/epub/OEBPS/images/detach-disk-icon.png
new file mode 100644
index 00000000000..536a4f8d001
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/detach-disk-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/edit-icon.png b/docs/tmp/en-US/epub/OEBPS/images/edit-icon.png
new file mode 100644
index 00000000000..42417e278d3
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/edit-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/enable-disable-autoscale.png b/docs/tmp/en-US/epub/OEBPS/images/enable-disable-autoscale.png
new file mode 100644
index 00000000000..ee02ef21c69
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/enable-disable-autoscale.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/enable-disable.png b/docs/tmp/en-US/epub/OEBPS/images/enable-disable.png
new file mode 100644
index 00000000000..cab31ae3d59
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/enable-disable.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/guest-traffic-setup.png b/docs/tmp/en-US/epub/OEBPS/images/guest-traffic-setup.png
new file mode 100644
index 00000000000..52508194ac1
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/guest-traffic-setup.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/http-access.png b/docs/tmp/en-US/epub/OEBPS/images/http-access.png
new file mode 100644
index 00000000000..817f197985a
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/http-access.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/icon.svg b/docs/tmp/en-US/epub/OEBPS/images/icon.svg
new file mode 100644
index 00000000000..37f94c06c1b
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/images/icon.svg
@@ -0,0 +1,37 @@
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/images/infrastructure-overview.png b/docs/tmp/en-US/epub/OEBPS/images/infrastructure-overview.png
new file mode 100644
index 00000000000..24aeecfcd1e
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/infrastructure-overview.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/installation-complete.png b/docs/tmp/en-US/epub/OEBPS/images/installation-complete.png
new file mode 100644
index 00000000000..4626f86d133
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/installation-complete.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/iso-icon.png b/docs/tmp/en-US/epub/OEBPS/images/iso-icon.png
new file mode 100644
index 00000000000..8d547fb397e
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/iso-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/large-scale-redundant-setup.png b/docs/tmp/en-US/epub/OEBPS/images/large-scale-redundant-setup.png
new file mode 100644
index 00000000000..5d2581afb43
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/large-scale-redundant-setup.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/migrate-instance.png b/docs/tmp/en-US/epub/OEBPS/images/migrate-instance.png
new file mode 100644
index 00000000000..25ff57245b3
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/migrate-instance.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/multi-node-management-server.png b/docs/tmp/en-US/epub/OEBPS/images/multi-node-management-server.png
new file mode 100644
index 00000000000..5cf5ed5456f
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/multi-node-management-server.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/multi-site-deployment.png b/docs/tmp/en-US/epub/OEBPS/images/multi-site-deployment.png
new file mode 100644
index 00000000000..f3ae5bb6b5c
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/multi-site-deployment.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/multi-tier-app.png b/docs/tmp/en-US/epub/OEBPS/images/multi-tier-app.png
new file mode 100644
index 00000000000..cec11228e26
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/multi-tier-app.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/network-acl.png b/docs/tmp/en-US/epub/OEBPS/images/network-acl.png
new file mode 100644
index 00000000000..5602827f415
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/network-acl.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/network-setup-zone.png b/docs/tmp/en-US/epub/OEBPS/images/network-setup-zone.png
new file mode 100644
index 00000000000..8324ff8beaa
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/network-setup-zone.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/network-singlepod.png b/docs/tmp/en-US/epub/OEBPS/images/network-singlepod.png
new file mode 100644
index 00000000000..e1214ea7f69
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/network-singlepod.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/networking-in-a-pod.png b/docs/tmp/en-US/epub/OEBPS/images/networking-in-a-pod.png
new file mode 100644
index 00000000000..bf731712042
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/networking-in-a-pod.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/networking-in-a-zone.png b/docs/tmp/en-US/epub/OEBPS/images/networking-in-a-zone.png
new file mode 100644
index 00000000000..fb740da448e
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/networking-in-a-zone.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/nic-bonding-and-multipath-io.png b/docs/tmp/en-US/epub/OEBPS/images/nic-bonding-and-multipath-io.png
new file mode 100644
index 00000000000..0fe60b66ed6
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/nic-bonding-and-multipath-io.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/pod-overview.png b/docs/tmp/en-US/epub/OEBPS/images/pod-overview.png
new file mode 100644
index 00000000000..c180060ba48
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/pod-overview.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/provisioning-overview.png b/docs/tmp/en-US/epub/OEBPS/images/provisioning-overview.png
new file mode 100644
index 00000000000..25cc97e3557
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/provisioning-overview.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/release-ip-icon.png b/docs/tmp/en-US/epub/OEBPS/images/release-ip-icon.png
new file mode 100644
index 00000000000..aa9846cfd9b
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/release-ip-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/remove-tier.png b/docs/tmp/en-US/epub/OEBPS/images/remove-tier.png
new file mode 100644
index 00000000000..e14d08f8052
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/remove-tier.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/remove-vpc.png b/docs/tmp/en-US/epub/OEBPS/images/remove-vpc.png
new file mode 100644
index 00000000000..aa9846cfd9b
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/remove-vpc.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/remove-vpn.png b/docs/tmp/en-US/epub/OEBPS/images/remove-vpn.png
new file mode 100644
index 00000000000..27145cebbc7
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/remove-vpn.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/reset-vpn.png b/docs/tmp/en-US/epub/OEBPS/images/reset-vpn.png
new file mode 100644
index 00000000000..04655dc37ad
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/reset-vpn.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/restart-vpc.png b/docs/tmp/en-US/epub/OEBPS/images/restart-vpc.png
new file mode 100644
index 00000000000..04655dc37ad
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/restart-vpc.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/search-button.png b/docs/tmp/en-US/epub/OEBPS/images/search-button.png
new file mode 100644
index 00000000000..f329aef4a25
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/search-button.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/select-vm-staticnat-vpc.png b/docs/tmp/en-US/epub/OEBPS/images/select-vm-staticnat-vpc.png
new file mode 100644
index 00000000000..12fde26d883
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/select-vm-staticnat-vpc.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/separate-storage-network.png b/docs/tmp/en-US/epub/OEBPS/images/separate-storage-network.png
new file mode 100644
index 00000000000..24dbbefc5b4
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/separate-storage-network.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/small-scale-deployment.png b/docs/tmp/en-US/epub/OEBPS/images/small-scale-deployment.png
new file mode 100644
index 00000000000..1c88520e7b4
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/small-scale-deployment.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/software-license.png b/docs/tmp/en-US/epub/OEBPS/images/software-license.png
new file mode 100644
index 00000000000..67aa2555341
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/software-license.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/stop-instance-icon.png b/docs/tmp/en-US/epub/OEBPS/images/stop-instance-icon.png
new file mode 100644
index 00000000000..209afce5086
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/stop-instance-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/suspend-icon.png b/docs/tmp/en-US/epub/OEBPS/images/suspend-icon.png
new file mode 100644
index 00000000000..cab31ae3d59
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/suspend-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/sysmanager.png b/docs/tmp/en-US/epub/OEBPS/images/sysmanager.png
new file mode 100644
index 00000000000..5b9df347a60
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/sysmanager.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vm-lifecycle.png b/docs/tmp/en-US/epub/OEBPS/images/vm-lifecycle.png
new file mode 100644
index 00000000000..97823fc568a
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vm-lifecycle.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-increase-ports.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-increase-ports.png
new file mode 100644
index 00000000000..fe968153262
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-increase-ports.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-datastore.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-datastore.png
new file mode 100644
index 00000000000..9f6b33f01ed
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-datastore.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-general.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-general.png
new file mode 100644
index 00000000000..863602b9eb7
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-general.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-initiator-properties.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-initiator-properties.png
new file mode 100644
index 00000000000..1fab03143b1
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-initiator-properties.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-initiator.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-initiator.png
new file mode 100644
index 00000000000..a9a8301d74d
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-initiator.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-target-add.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-target-add.png
new file mode 100644
index 00000000000..f016da7956d
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-iscsi-target-add.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-mgt-network-properties.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-mgt-network-properties.png
new file mode 100644
index 00000000000..9141af9c42f
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-mgt-network-properties.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-nexus-add-cluster.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-nexus-add-cluster.png
new file mode 100644
index 00000000000..7c1dd73f775
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-nexus-add-cluster.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-nexus-port-profile.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-nexus-port-profile.png
new file mode 100644
index 00000000000..19b264f7a0a
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-nexus-port-profile.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-physical-network.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-physical-network.png
new file mode 100644
index 00000000000..a7495c77b14
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-physical-network.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vmware-vswitch-properties.png b/docs/tmp/en-US/epub/OEBPS/images/vmware-vswitch-properties.png
new file mode 100644
index 00000000000..bc247d276d6
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vmware-vswitch-properties.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vpc-setting.png b/docs/tmp/en-US/epub/OEBPS/images/vpc-setting.png
new file mode 100644
index 00000000000..782299e9f54
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vpc-setting.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vpn-icon.png b/docs/tmp/en-US/epub/OEBPS/images/vpn-icon.png
new file mode 100644
index 00000000000..2ac12f77c40
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vpn-icon.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/vsphere-client.png b/docs/tmp/en-US/epub/OEBPS/images/vsphere-client.png
new file mode 100644
index 00000000000..2acc8b802ad
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/vsphere-client.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/images/zone-overview.png b/docs/tmp/en-US/epub/OEBPS/images/zone-overview.png
new file mode 100644
index 00000000000..24aeecfcd1e
Binary files /dev/null and b/docs/tmp/en-US/epub/OEBPS/images/zone-overview.png differ
diff --git a/docs/tmp/en-US/epub/OEBPS/import-ami.html b/docs/tmp/en-US/epub/OEBPS/import-ami.html
new file mode 100644
index 00000000000..10e75395109
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/import-ami.html
@@ -0,0 +1,97 @@
+
+
+12.11. Importing Amazon Machine Images
12.11. Importing Amazon Machine Images
+ The following procedures describe how to import an Amazon Machine Image (AMI) into CloudStack when using the XenServer hypervisor.
+
+ Assume you have an AMI file and this file is called CentOS_6.2_x64. Assume further that you are working on a CentOS host. If the AMI is a Fedora image, you need to be working on a Fedora host initially.
+
+ You need to have a XenServer host with a file-based storage repository (either a local ext3 SR or an NFS SR) to convert to a VHD once the image file has been customized on the Centos/Fedora host.
+
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.
+
+ Determine the name of the PV kernel that has been installed into the image.
+
# cd /mnt/loop/centos62
+# ls lib/modules/
+2.6.16.33-xenU 2.6.16-xenU 2.6.18-164.15.1.el5xen 2.6.18-164.6.1.el5.centos.plus 2.6.18-xenU-ec2-v1.0 2.6.21.7-2.fc8xen 2.6.31-302-ec2
+# ls boot/initrd*
+boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
+# ls boot/vmlinuz*
+boot/vmlinuz-2.6.18-164.15.1.el5xen boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus boot/vmlinuz-2.6.18-xenU-ec2-v1.0 boot/vmlinuz-2.6.21-2952.fc8xen
+
+ Xen kernels/ramdisk always end with "xen". For the kernel version you choose, there has to be an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.
+
+ Based on your findings, create an entry in the grub.conf file. Below is an example entry.
+
+ Enable login via the console. The default console device in a XenServer system is xvc0. Ensure that etc/inittab and etc/securetty have the following lines respectively:
+
+ Copy the image file to your XenServer host's file-based storage repository. In the example below, the Xenserver is "xenhost". This XenServer has an NFS repository whose uuid is a9c5b8c8-536b-a193-a6dc-51af3e5ff799.
+
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
Abstract
+ Administration Guide for CloudStack.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/initialize-and-test.html b/docs/tmp/en-US/epub/OEBPS/initialize-and-test.html
new file mode 100644
index 00000000000..8f499b5513e
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/initialize-and-test.html
@@ -0,0 +1,33 @@
+
+
+7.8. Initialize and Test
7.8. Initialize and Test
+ After everything is configured, CloudStack will perform its initialization. This can take 30 minutes or more, depending on the speed of your network. When the initialization has completed successfully, the administrator's Dashboard should be displayed in the CloudStack UI.
+
+ Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS 5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do not proceed to the next step until this status is displayed.
+
+ Go to the Instances tab, and filter by My Instances.
+
+ Click Add Instance and follow the steps in the wizard.
+
+ Choose the zone you just added.
+
+ In the template selection, choose the template to use in the VM. If this is a fresh installation, likely only the provided CentOS template is available.
+
+ Select a service offering. Be sure that the hardware you have allows starting the selected service offering.
+
+ In data disk offering, if desired, add another data disk. This is a second volume that will be available to but not mounted in the guest. For example, in Linux on XenServer you will see /dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PV-enabled OS kernel in use.
+
+ In default network, choose the primary network for the guest. In a trial installation, you would have only one option here.
+
+ Optionally give your VM a name and a group. Use any descriptive text you would like.
+
+ Click Launch VM. Your VM will be created and started. It might take some time to download the template and complete the VM startup. You can watch the VM’s progress in the Instances screen.
+
+ To use the VM, click the View Console button.
+
+
+
+ Congratulations! You have successfully completed a CloudStack Installation.
+
+ If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/inter-vlan-routing.html b/docs/tmp/en-US/epub/OEBPS/inter-vlan-routing.html
new file mode 100644
index 00000000000..11e51a6fccc
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/inter-vlan-routing.html
@@ -0,0 +1,39 @@
+
+
+15.18. About Inter-VLAN Routing
15.18. About Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You provision VLANs to the tiers your create, and VMs can be deployed on different tiers. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications, such as Web, Application, or Database. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+ The major advantages are:
+
+ The administrator can deploy a set of VLANs and allow users to deploy VMs on these VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that account.
+
Note
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+
+ The administrator can allow users create their own VPC and deploy the application. In this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that account.
+
+ Both administrators and users can create multiple VPCs. The guest network NIC is plugged to the VPC virtual router when the first VM is deployed in a tier.
+
+ The administrator can create the following gateways to send to or receive traffic from the VMs:
+
+ Public Gateway: The public gateway for a VPC is added to the virtual router when the virtual router is created for VPC. The public gateway is not exposed to the end users. You are not allowed to list it, nor allowed to create any static routes.
+
+ Both administrators and users can create various possible destinations-gateway combinations. However, only one gateway of each type can be used in a deployment.
+
+ For example:
+
+ VLANs and Public Gateway: For example, an application is deployed in the cloud, and the Web application VMs communicate with the Internet.
+
+ VLANs, VPN Gateway, and Public Gateway: For example, an application is deployed in the cloud; the Web application VMs communicate with the Internet; and the database VMs communicate with the on-premise devices.
+
+ The administrator can define Access Control List (ACL) on the virtual router to filter the traffic among the VLANs or between the Internet and a VLAN. You can define ACL based on CIDR, port range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress type.
+
+ The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
+
diff --git a/docs/tmp/en-US/epub/OEBPS/ip-forwarding-firewalling.html b/docs/tmp/en-US/epub/OEBPS/ip-forwarding-firewalling.html
new file mode 100644
index 00000000000..acece5d598b
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/ip-forwarding-firewalling.html
@@ -0,0 +1,9 @@
+
+
+15.14. IP Forwarding and Firewalling
15.14. IP Forwarding and Firewalling
+ By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is translated via NAT to the public IP address and is allowed.
+
+ To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example, you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44. Then use port forwarding rules to direct traffic from individual ports within that range to specific ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public IP's port 33 to port 100 on one user VM's private IP.
+
+ For the steps to implement these rules, see Firewall Rules and Port Forwarding.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/ip-load-balancing.html b/docs/tmp/en-US/epub/OEBPS/ip-load-balancing.html
new file mode 100644
index 00000000000..bd9ebac7330
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/ip-load-balancing.html
@@ -0,0 +1,13 @@
+
+
+15.15. IP Load Balancing
15.15. IP Load Balancing
+ The user may choose to associate the same public IP for multiple guests. CloudStack implements a TCP-level load balancer with the following policies.
+
+ Round-robin
+
+ Least connection
+
+ Source IP
+
+ This is similar to port forwarding but the destination may be multiple IP addresses.
+
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudStack virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/maintain-hypervisors-on-hosts.html b/docs/tmp/en-US/epub/OEBPS/maintain-hypervisors-on-hosts.html
new file mode 100644
index 00000000000..1d47b40db4b
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/maintain-hypervisors-on-hosts.html
@@ -0,0 +1,9 @@
+
+
+11.6. Maintaining Hypervisors on Hosts
11.6. 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/manage-cloud.html b/docs/tmp/en-US/epub/OEBPS/manage-cloud.html
new file mode 100644
index 00000000000..2a43adb68fe
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/manage-cloud.html
@@ -0,0 +1,48 @@
+
+
+Chapter 18. Managing the Cloud
Chapter 18. Managing the Cloud
18.1. 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:
+
+ The following API commands have the "tags" input parameter:
+
+ listVirtualMachines
+
+ listVolumes
+
+ listSnapshots
+
+ listNetworks
+
+ listTemplates
+
+ listIsos
+
+ listFirewallRules
+
+ listPortForwardingRules
+
+ listPublicIpAddresses
+
+ listSecurityGroups
+
+ listLoadBalancerRules
+
+ listProjects
+
+ listVPCs
+
+ listNetworkACLs
+
+ listStaticRoutes
+
diff --git a/docs/tmp/en-US/epub/OEBPS/manual-live-migration.html b/docs/tmp/en-US/epub/OEBPS/manual-live-migration.html
new file mode 100644
index 00000000000..b0b4f5b4000
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/manual-live-migration.html
@@ -0,0 +1,31 @@
+
+
+10.9. Moving VMs Between Hosts (Manual Live Migration)
10.9. Moving VMs Between Hosts (Manual Live Migration)
+ The CloudPlatform administrator can move a running VM from one host to another without interrupting service to users or going into maintenance mode. This is called manual live migration, and can be done under the following conditions:
+
+ The root administrator is logged in. Domain admins and users can not perform manual live migration of VMs.
+
+ The VM is running. Stopped VMs can not be live migrated.
+
+ The destination host must be in the same cluster as the original host.
+
+ The VM must not be using local disk storage.
+
+ The destination host must have enough available capacity. If not, the VM will remain in the "migrating" state until memory becomes available.
+
+ To manually live migrate a virtual machine
+
+ Log in to the CloudPlatform UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to migrate.
+
+ Click the Migrate Instance button
+
+
+
+ From the list of hosts, choose the one to which you want to move the VM.
+
+ Click OK.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/multiple-system-vm-vmware.html b/docs/tmp/en-US/epub/OEBPS/multiple-system-vm-vmware.html
new file mode 100644
index 00000000000..3ee805b1fbb
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/multiple-system-vm-vmware.html
@@ -0,0 +1,5 @@
+
+
+16.2. Multiple System VM Support for VMware
16.2. Multiple System VM Support for VMware
+ Every CloudStack zone has single System VM for template processing tasks such as downloading templates, uploading templates, and uploading ISOs. In a zone where VMware is being used, additional System VMs can be launched to process VMware-specific tasks such as taking snapshots and creating private templates. The CloudStack management server launches additional System VMs for VMware-specific tasks as the load increases. The management server monitors and weights all commands sent to these System VMs and performs dynamic load balancing and scaling-up of more System VMs.
+
+ For the most up-to-date list of supported network services, see the CloudPlatform UI or call listNetworkServices.
+
+ A network offering is a named set of network services, such as:
+
+ DHCP
+
+ DNS
+
+ Source NAT
+
+ Static NAT
+
+ Port Forwarding
+
+ Load Balancing
+
+ Firewall
+
+ VPN
+
+ Optional) Name one of several available providers to use for a given service, such as Juniper for the firewall
+
+ (Optional) Network tag to specify which physical network to use
+
+ When creating a new VM, the user chooses one of the available network offerings, and that determines which network services the VM can use.
+
+ The CloudPlatform administrator can create any number of custom network offerings, in addition to the default network offerings provided by CloudPlatform. By creating multiple custom network offerings, you can set up your cloud to offer different classes of service on a single multi-tenant physical network. For example, while the underlying physical wiring may be the same for two tenants, tenant A may only need simple firewall protection for their website, while tenant B may be running a web server farm and require a scalable firewall solution, load balancing solution, and alternate networks for accessing the database backend.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudPlatform virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+ When creating a new virtual network, the CloudPlatform administrator chooses which network offering to enable for that network. Each virtual network is associated with one network offering. A virtual network can be upgraded or downgraded by changing its associated network offering. If you do this, be sure to reprogram the physical network to match.
+
+ CloudPlatform also has internal network offerings for use by CloudPlatform system VMs. These network offerings are not visible to users but can be modified by administrators.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/network-service-providers.html b/docs/tmp/en-US/epub/OEBPS/network-service-providers.html
new file mode 100644
index 00000000000..a1cdbfff181
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/network-service-providers.html
@@ -0,0 +1,13 @@
+
+
+9.3. Network Service Providers
9.3. Network Service Providers
Note
+ For the most up-to-date list of supported network service providers, see the CloudPlatform UI or call listNetworkServiceProviders.
+
+ A service provider (also called a network element) is hardware or virtual appliance that makes a network service possible; for example, a firewall appliance can be installed in the cloud to provide firewall service. On a single network, multiple providers can provide the same network service. For example, a firewall service may be provided by Cisco or Juniper devices in the same physical network.
+
+ You can have multiple instances of the same service provider in a network (say, more than one Juniper SRX device).
+
+ If different providers are set up to provide the same service on the network, the administrator can create network offerings so users can specify which network service provider they prefer (along with the other choices offered in network offerings). Otherwise, CloudPlatform will choose which provider to use whenever the service is called for.
+
Supported Network Service Providers
+ CloudPlatform ships with an internal list of the supported service providers, and you can choose from this list when creating a network offering.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/networking-in-a-pod.html b/docs/tmp/en-US/epub/OEBPS/networking-in-a-pod.html
new file mode 100644
index 00000000000..2e26c834abf
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/networking-in-a-pod.html
@@ -0,0 +1,15 @@
+
+
+15.2. Networking in a Pod
15.2. Networking in a Pod
+ Figure 2 illustrates network setup within a single pod. The hosts are connected to a pod-level switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
+
+ Servers are connected as follows:
+
+ Storage devices are connected to only the network that carries management traffic.
+
+ Hosts are connected to networks for both management traffic and public traffic.
+
+ Hosts are also connected to one or more networks carrying guest traffic.
+
+ We recommend the use of multiple physical Ethernet cards to implement each network interface as well as redundant switch fabric in order to maximize throughput and improve reliability.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/networking-in-a-zone.html b/docs/tmp/en-US/epub/OEBPS/networking-in-a-zone.html
new file mode 100644
index 00000000000..121f6066496
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/networking-in-a-zone.html
@@ -0,0 +1,9 @@
+
+
+15.3. Networking in a Zone
15.3. Networking in a Zone
+ Figure 3 illustrates the network setup within a single zone.
+
+ A firewall for management traffic operates in the NAT mode. The network typically is assigned IP addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses in the 192.168.*.0/24 Class C private address space.
+
+ Each zone has its own set of public IP addresses. Public IP addresses from different zones do not overlap.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/networks.html b/docs/tmp/en-US/epub/OEBPS/networks.html
new file mode 100644
index 00000000000..7e97caf7b00
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/networks.html
@@ -0,0 +1,15 @@
+
+
+Chapter 15. Managing Networks and Traffic
Chapter 15. Managing Networks and Traffic
+ In a CloudStack, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN. The CloudStack virtual router is the main component providing networking features for guest traffic.
+
15.1. Guest Traffic
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+
+ Figure 1 illustrates a typical guest traffic setup:
+
+ The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+
+ The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
+
+ Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
+
diff --git a/docs/tmp/en-US/epub/OEBPS/offerings.html b/docs/tmp/en-US/epub/OEBPS/offerings.html
new file mode 100644
index 00000000000..c1152bd95a0
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/offerings.html
@@ -0,0 +1,99 @@
+
+
+Chapter 8. Service Offerings
Chapter 8. Service Offerings
+ In this chapter we discuss compute, disk, and system service offerings. Network offerings are discussed in the section on setting up networking for users.
+
8.1. Compute and Disk Service Offerings
+ A service offering is a set of virtual hardware features such as CPU core count and speed, memory, and disk size. The CloudStack administrator can set up various offerings, and then end users choose from the available offerings when they create a new VM. A service offering includes the following elements:
+
+ CPU, memory, and network resource guarantees
+
+ How resources are metered
+
+ How the resource usage is charged
+
+ How often the charges are generated
+
+ For example, one service offering might allow users to create a virtual machine instance that is equivalent to a 1 GHz Intel® Core™ 2 CPU, with 1 GB memory at $0.20/hour, with network traffic metered at $0.10/GB. Based on the user’s selected offering, CloudStack emits usage records that can be integrated with billing systems. CloudStack separates service offerings into compute offerings and disk offerings. The computing service offering specifies:
+
+ Guest CPU
+
+ Guest RAM
+
+ Guest Networking type (virtual or direct)
+
+ Tags on the root disk
+
+ The disk offering specifies:
+
+ Disk size (optional). An offering without a disk size will allow users to pick their own
+
+ Tags on the data disk
+
8.1.1. Creating a New Compute Offering
+ To create a new compute offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Compute Offering.
+
+ Click Add Compute Offering.
+
+ In the dialog, make the following choices:
+
+ Name: Any desired name for the service offering.
+
+ Description: A short description of the offering that can be displayed to users
+
+ Storage type: The type of disk that should be allocated. Local allocates from storage attached directly to the host where the system VM is running. Shared allocates from storage accessible via NFS.
+
+ # of CPU cores: The number of cores which should be allocated to a system VM with this offering
+
+ CPU (in MHz): The CPU speed of the cores that the system VM is allocated. For example, “2000” would provide for a 2 GHz clock.
+
+ Memory (in MB): The amount of memory in megabytes that the system VM should be allocated. For example, “2048” would provide for a 2 GB RAM allocation.
+
+ Network Rate: Allowed data transfer rate in MB per second.
+
+ Offer HA: If yes, the administrator can choose to have the system VM be monitored and as highly available as possible.
+
+ Storage Tags: The tags that should be associated with the primary storage used by the system VM.
+
+ Host Tags: (Optional) Any tags that you use to organize your hosts
+
+ CPU cap: Whether to limit the level of CPU usage even if spare capacity is available.
+
+ Public: Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.2. Creating a New Disk Offering
+ To create a system service offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Disk Offering.
+
+ Click Add Disk Offering.
+
+ In the dialog, make the following choices:
+
+ Name. Any desired name for the system offering.
+
+ Description. A short description of the offering that can be displayed to users
+
+ Custom Disk Size. If checked, the user can set their own disk size. If not checked, the root administrator must define a value in Disk Size.
+
+ Disk Size. Appears only if Custom Disk Size is not selected. Define the volume size in GB.
+
+ (Optional)Storage Tags. The tags that should be associated with the primary storage for this disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue". Tags are also added on Primary Storage. CloudStack matches tags on a disk offering to tags on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation from the disk offering will fail..
+
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.3. Modifying or Deleting a Service Offering
+ Service offerings cannot be changed once created. This applies to both compute offerings and disk offerings.
+
+ A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently. If the service offering is still in use, it will remain in the database until all the virtual machines referencing it have been deleted. After deletion by the administrator, a service offering will not be available to end users that are creating new instances.
+
+ CloudStack allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of all accounts in the domain as well as all accounts in all subdomains of that domain. Limits set at the root domain level apply to the sum of resource usage by the accounts in all domains and sub-domains below that root domain.
+
+ To set a domain limit:
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Domains.
+
+ Select the domain you want to modify. The current domain limits are displayed. A value of -1 shows that there is no limit in place.
+
+ Click the Edit button
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/pod-add.html b/docs/tmp/en-US/epub/OEBPS/pod-add.html
new file mode 100644
index 00000000000..3a8ab1ed97e
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/pod-add.html
@@ -0,0 +1,25 @@
+
+
+7.3. Adding a Pod
7.3. 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.
+
+ 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.
+
+ Any standards-compliant iSCSI or NFS server that is supported by the underlying hypervisor.
+
+ The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller.
+
+ Minimum required capacity depends on your needs.
+
+ When setting up primary storage, follow these restrictions:
+
+ Primary storage cannot be added until a host has been added to the cluster.
+
+ If you do not provision shared primary storage, you must set the global configuration parameter system.vm.local.storage.required to true, or else you will not be able to start VMs.
+
7.6.2. Adding Primary Stroage
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+
+ Click the Compute tab.
+
+ In the Primary Storage node of the diagram, click View All.
+
+ Click Add Primary Storage.
+
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+
+ Pod. The pod for the storage device.
+
+ Cluster. The cluster for the storage device.
+
+ Name. The name of the storage device.
+
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS.
+
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device.
+
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+
+ Path (for NFS). In NFS this is the exported path from the server.
+
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside CloudStack.
+
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
+
+ Lun # (for iSCSI). In iSCSI this is 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.
+
+ Click OK.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/primary-storage-outage-and-data-loss.html b/docs/tmp/en-US/epub/OEBPS/primary-storage-outage-and-data-loss.html
new file mode 100644
index 00000000000..59ff847ef50
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/primary-storage-outage-and-data-loss.html
@@ -0,0 +1,5 @@
+
+
+17.4. Primary Storage Outage and Data Loss
17.4. Primary Storage Outage and Data Loss
+ When a primary storage outage occurs the hypervisor immediately stops all VMs stored on that storage device. Guests that are marked for HA will be restarted as soon as practical when the primary storage comes back on line. With NFS, the hypervisor may allow the virtual machines to continue running depending on the nature of the issue. For example, an NFS hang will cause the guest VMs to be suspended until storage connectivity is restored.Primary storage is not designed to be backed up. Individual volumes in primary storage can be backed up using snapshots.
+
+ This section gives concepts and technical details about CloudPlatform primary storage. For information about how to install and configure primary storage through the CloudPlatform UI, see the Advanced Installation Guide.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/private-public-template.html b/docs/tmp/en-US/epub/OEBPS/private-public-template.html
new file mode 100644
index 00000000000..b62d4750e09
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/private-public-template.html
@@ -0,0 +1,9 @@
+
+
+12.5. Private and Public Templates
12.5. Private and Public Templates
+ When a user creates a template, it can be designated private or public.
+
+ Private templates are only available to the user who created them. By default, an uploaded template is private.
+
+ When a user marks a template as “public,” the template becomes available to all users in all accounts in the user's domain, as well as users in any other domains that have access to the Zone where the template is stored. This depends on whether the Zone, in turn, was defined as private or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any domain. If a public template is created in a private Zone, it is available only to users in the domain assigned to that Zone. If a public template is created in a public Zone, it is available to all users in all domains.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/projects.html b/docs/tmp/en-US/epub/OEBPS/projects.html
new file mode 100644
index 00000000000..fa50e805d60
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/projects.html
@@ -0,0 +1,11 @@
+
+
+Chapter 6. Using Projects to Organize Users and Resources
Chapter 6. Using Projects to Organize Users and Resources
6.1. 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..
+
diff --git a/docs/tmp/en-US/epub/OEBPS/provisioning-steps.html b/docs/tmp/en-US/epub/OEBPS/provisioning-steps.html
new file mode 100644
index 00000000000..63ab64b3d0a
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/provisioning-steps.html
@@ -0,0 +1,27 @@
+
+
+Chapter 7. Steps to Provisioning Your Cloud Infrastructure
Chapter 7. Steps to Provisioning Your Cloud Infrastructure
+ This section tells how to add 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.
+
7.1. 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”.
+
+ To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
+
+ 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/release-ip-address.html b/docs/tmp/en-US/epub/OEBPS/release-ip-address.html
new file mode 100644
index 00000000000..68cdb14fa2a
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/release-ip-address.html
@@ -0,0 +1,17 @@
+
+
+15.12. Releasing an IP Address
15.12. Releasing an IP Address
+ Log in to the CloudPlatform UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click the name of the network where you want to work with.
+
+ Hosts can be removed from the cloud as needed. The procedure to remove a host depends on the hypervisor type.
+
11.4.1. 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:
+
+ Then you may power down the Host, re-use its IP address, re-install it, etc
+
11.4.2. 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”. 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/requirements-templates.html b/docs/tmp/en-US/epub/OEBPS/requirements-templates.html
new file mode 100644
index 00000000000..fdc7a02f9f8
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/requirements-templates.html
@@ -0,0 +1,7 @@
+
+
+12.2. Requirements for Templates
12.2. Requirements for Templates
+ For XenServer, install PV drivers / Xen tools on each template that you create. This will enable live migration and clean guest shutdown.
+
+ For vSphere, install VMware Tools on each template that you create. This will enable console view to work properly.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/scheduled-maintenance-maintenance-mode-hosts.html b/docs/tmp/en-US/epub/OEBPS/scheduled-maintenance-maintenance-mode-hosts.html
new file mode 100644
index 00000000000..3d3cffd0c9e
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/scheduled-maintenance-maintenance-mode-hosts.html
@@ -0,0 +1,5 @@
+
+
+11.2. Scheduled Maintenance and Maintenance Mode for Hosts
11.2. 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.
+
+ (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org)
+
+ 100GB minimum capacity
+
+ A secondary storage device must be located in the same zone as the guest VMs it serves.
+
+ Each Secondary Storage server must be available to all hosts in the zone.
+
7.7.2. Adding Secondary Storage
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to CloudStack before you add the local zone secondary storage servers. See Section 7.2, “Adding a Zone”.
+
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See Preparing NFS Shares in the Installation Guide.
+
+ Make sure you prepared the system VM template during Management Server installation. See Prepare the System VM Template in the Installation Guide.
+
+ Now that the secondary storage server for per-zone storage is prepared, add it to CloudStack. Secondary storage is added as part of the procedure for adding a new zone. See Section 7.2, “Adding a Zone”.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/secondary-storage-outage-and-data-loss.html b/docs/tmp/en-US/epub/OEBPS/secondary-storage-outage-and-data-loss.html
new file mode 100644
index 00000000000..c1f93cb97c8
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/secondary-storage-outage-and-data-loss.html
@@ -0,0 +1,7 @@
+
+
+17.5. Secondary Storage Outage and Data Loss
17.5. Secondary Storage Outage and Data Loss
+ For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online.
+
+ Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/secondary-storage-vm.html b/docs/tmp/en-US/epub/OEBPS/secondary-storage-vm.html
new file mode 100644
index 00000000000..71d0dc9a91b
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/secondary-storage-vm.html
@@ -0,0 +1,11 @@
+
+
+16.5. Secondary Storage VM
16.5. Secondary Storage VM
+ In addition to the hosts, CloudStack’s Secondary Storage VM mounts and writes to secondary storage.
+
+ Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols.
+
+ The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups.
+
+ The administrator can log in to the secondary storage VM if needed.
+
+ This section gives concepts and technical details about CloudStack secondary storage. For information about how to install and configure secondary storage through the CloudStack UI, see the Advanced Installation Guide.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/security-groups.html b/docs/tmp/en-US/epub/OEBPS/security-groups.html
new file mode 100644
index 00000000000..5dbe6c18de3
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/security-groups.html
@@ -0,0 +1,74 @@
+
+
+15.7. Security Groups
15.7. Security Groups
15.7.1. About Security Groups
+ Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In CloudStack 3.0.3 - 3.0.5, security groups are supported only in zones that use basic networking.
+
Note
+ In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
+
+
+ Each CloudStack account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.
+
+ Any CloudStack user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.
+
+ You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.
+
+ If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
15.7.2. Adding a Security Group
+ A user or administrator can define a new security group.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups.
+
+ Click Add Security Group.
+
+ Provide a name and description.
+
+ Click OK.
+
+ The new security group appears in the Security Groups Details tab.
+
+ To make the security group useful, continue to Adding Ingress and Egress Rules to a Security Group.
+
15.7.3. Enabling Security Groups
+ In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide.
+
15.7.4. Adding Ingress and Egress Rules to a Security Group
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups, then click the security group you want .
+
+ To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify what network traffic is allowed into VM instances in this security group. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
+ Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow incoming traffic from all VMs in another security group
+
+ Protocol. The networking protocol that sources will use to send traffic to the security group. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be accepted.
+
+ CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To accept only traffic from another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter the same name you used in step 7.
+
+ The following example allows inbound HTTP access from anywhere:
+
+ To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been allowed in through an ingress rule
+
+ Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow outgoing traffic to all VMs in another security group.
+
+ Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
+
+ CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To allow traffic to be sent to another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter its name.
+
+ Click Add.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/set-database-buffer-pool-size.html b/docs/tmp/en-US/epub/OEBPS/set-database-buffer-pool-size.html
new file mode 100644
index 00000000000..3f654edaf60
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/set-database-buffer-pool-size.html
@@ -0,0 +1,13 @@
+
+
+21.3. Set Database Buffer Pool Size
21.3. Set Database Buffer Pool Size
+ It is important to provide enough memory space for the MySQL database to cache data and indexes:
+
+ Edit the Tomcat configuration file:
+
/etc/my.cnf
+ Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM.
+
innodb_buffer_pool_size=700M
+ Restart the MySQL service.
+
# service mysqld restart
+ For more information about the buffer pool, see "The InnoDB Buffer Pool" at MySQL Reference Manual.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/set-monitor-total-vm-limits-per-host.html b/docs/tmp/en-US/epub/OEBPS/set-monitor-total-vm-limits-per-host.html
new file mode 100644
index 00000000000..2d8a593aea5
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/set-monitor-total-vm-limits-per-host.html
@@ -0,0 +1,5 @@
+
+
+21.4. Set and Monitor Total VM Limits per Host
21.4. Set and Monitor Total VM Limits per Host
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/set-up-network-for-users.html b/docs/tmp/en-US/epub/OEBPS/set-up-network-for-users.html
new file mode 100644
index 00000000000..2cd045512f9
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/set-up-network-for-users.html
@@ -0,0 +1,15 @@
+
+
+Chapter 9. Setting Up Networking for Users
Chapter 9. Setting Up Networking for Users
9.1. Overview of Setting Up Networking for Users
+ People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a CloudStack administrator, you can do the following things to set up networking for your users:
+
+ Set up physical networks in zones
+
+ Set up several different providers for the same service on a single physical network (for example, both Cisco and Juniper firewalls)
+
+ Bundle different types of network services into network offerings, so users can choose the desired network services for any given virtual machine
+
+ Add new network offerings as time goes on so end users can upgrade to a better class of service on their network
+
+ Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member
+
+ CloudStack provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis.
+
+ Aggregate limits may be set on a per-domain basis. For example, you may limit a domain and all subdomains to the creation of 100 VMs.
+
+ A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/stop-restart-management-server.html b/docs/tmp/en-US/epub/OEBPS/stop-restart-management-server.html
new file mode 100644
index 00000000000..80fe28060ef
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/stop-restart-management-server.html
@@ -0,0 +1,13 @@
+
+
+18.5. Stopping and Restarting the Management Server
18.5. 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:
+
# service cloud-management stop
+ To start the Management Server:
+
# service cloud-management start
+ To stop the Management Server:
+
# service cloud-management stop
diff --git a/docs/tmp/en-US/epub/OEBPS/stopping-and-starting-vms.html b/docs/tmp/en-US/epub/OEBPS/stopping-and-starting-vms.html
new file mode 100644
index 00000000000..1db4d64ba61
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/stopping-and-starting-vms.html
@@ -0,0 +1,5 @@
+
+
+10.6. Stopping and Starting VMs
10.6. Stopping and Starting VMs
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/storage.html b/docs/tmp/en-US/epub/OEBPS/storage.html
new file mode 100644
index 00000000000..2062b4a92ba
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/storage.html
@@ -0,0 +1,7 @@
+
+
+Chapter 13. Working With Storage
Chapter 13. Working With Storage
13.1. Storage Overview
+ CloudStack defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS.
+
+ There is no ephemeral storage in CloudStack. All volumes on all nodes are persistent.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/suspend-project.html b/docs/tmp/en-US/epub/OEBPS/suspend-project.html
new file mode 100644
index 00000000000..3671c3e4ed9
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/suspend-project.html
@@ -0,0 +1,25 @@
+
+
+6.6. Suspending or Deleting a Project
6.6. 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
+
+
+ To suspend, use
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/sys-reliability-and-ha.html b/docs/tmp/en-US/epub/OEBPS/sys-reliability-and-ha.html
new file mode 100644
index 00000000000..2929d701a03
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/sys-reliability-and-ha.html
@@ -0,0 +1,9 @@
+
+
+Chapter 17. System Reliability and High Availability
Chapter 17. System Reliability and High Availability
17.1. HA for Management Server
+ The CloudStack Management Server should be deployed in a multi-node configuration such that it is not susceptible to individual server failures. The Management Server itself (as distinct from the MySQL database) is stateless and may be placed behind a load balancer.
+
+ Normal operation of Hosts is not impacted by an outage of all Management Serves. All guest VMs will continue to work.
+
+ When the Management Server is down, no new VMs can be created, and the end user and admin UI, API, dynamic load distribution, and HA will cease to work.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/system-service-offerings.html b/docs/tmp/en-US/epub/OEBPS/system-service-offerings.html
new file mode 100644
index 00000000000..61b830afdc3
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/system-service-offerings.html
@@ -0,0 +1,7 @@
+
+
+8.2. System Service Offerings
8.2. System Service Offerings
+ System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the CloudStack root administrator. CloudStack provides default system service offerings. The CloudStack root administrator can create additional custom system service offerings.
+
+ When CloudStack creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/time-zones.html b/docs/tmp/en-US/epub/OEBPS/time-zones.html
new file mode 100644
index 00000000000..a8629143563
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/time-zones.html
@@ -0,0 +1,244 @@
+
+
+Appendix A. Time Zones
Time Zones
+ 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
+
+
+
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/toc.ncx b/docs/tmp/en-US/epub/OEBPS/toc.ncx
new file mode 100644
index 00000000000..a4af9210d58
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/toc.ncx
@@ -0,0 +1,2 @@
+
+CloudStack Administrator's GuideCloudStack Administrator's Guide1. Concepts1.1. What Is CloudStack?1.2. What Can CloudStack Do?1.3. Deployment Architecture Overview1.3.1. Management Server Overview1.3.2. Cloud Infrastructure Overview1.3.3. Networking Overview2. Cloud Infrastructure Concepts2.1. About Zones2.2. About Pods2.3. About Clusters2.4. About Hosts2.5. About Primary Storage2.6. About Secondary Storage2.7. About Physical Networks2.7.1. Configurable Characteristics of Physical Networks2.7.2. Basic Zone Network Traffic Types2.7.3. Basic Zone Guest IP Addresses2.7.4. Advanced Zone Network Traffic Types2.7.5. Advanced Zone Guest IP Addresses2.7.6. Advanced Zone Public IP Addresses2.7.7. System Reserved IP Addresses3. Accounts3.1. Accounts, Users, and Domains3.2. Using an LDAP Server for User Authentication3.2.1. Example LDAP Configuration Commands3.2.2. Search Base3.2.3. Query Filter3.2.4. Search User Bind DN3.2.5. SSL Keystore Path and Password4. User Services Overview4.1. Service Offerings, Disk Offerings, Network Offerings, and Templates5. User Interface5.1. Log In to the UI5.1.1. End User's UI Overview5.1.2. Root Administrator's UI Overview5.1.3. Logging In as the Root Administrator5.1.4. Changing the Root Password5.2. Using SSH Keys for Authentication5.2.1. Creating an Instance Template that Supports SSH Keys5.2.2. Creating the SSH Keypair5.2.3. Creating an Instance5.2.4. Logging In Using the SSH Keypair6. Using Projects to Organize Users and Resources6.1. Overview of Projects6.2. Configuring Projects6.2.1. Setting Up Invitations6.2.2. Setting Resource Limits for Projects6.2.2.1. Setting Per-Project Resource Limits6.2.2.2. Setting the Global Project Resource Limits6.2.3. Setting Project Creator Permissions6.3. Creating a New Project6.4. Adding Members to a Project6.4.1. Sending Project Membership Invitations6.4.2. Adding Project Members From the UI6.5. Accepting a Membership Invitation6.6. Suspending or Deleting a Project6.7. Using the Project View7. Steps to Provisioning Your Cloud Infrastructure7.1. Overview of Provisioning Steps7.2. Adding a Zone7.2.1. Basic Zone Configuration7.2.2. Advanced Zone Configuration7.3. Adding a Pod7.4. Adding a Cluster7.4.1. Add Cluster: KVM or XenServer7.4.2. Add Cluster: vSphere7.5. Adding a Host7.5.1. Adding a Host (XenServer or KVM)7.5.1.1. Requirements for XenServer and KVM Hosts7.5.1.1.1. XenServer Host Additional Requirements7.5.1.1.2. KVM Host Additional Requirements7.5.1.2. Adding a XenServer or KVM Host7.5.2. Adding a Host (vSphere)7.6. Add Primary Storage7.6.1. System Requirements for Primary Storage7.6.2. Adding Primary Stroage7.7. Add Secondary Storage7.7.1. System Requirements for Secondary Storage7.7.2. Adding Secondary Storage7.8. Initialize and Test8. Service Offerings8.1. Compute and Disk Service Offerings8.1.1. Creating a New Compute Offering8.1.2. Creating a New Disk Offering8.1.3. Modifying or Deleting a Service Offering8.2. System Service Offerings9. Setting Up Networking for Users9.1. Overview of Setting Up Networking for Users9.2. About Virtual Networks9.2.1. Isolated Networks9.2.2. Shared Networks9.2.3. Runtime Allocation of Virtual Network Resources9.3. Network Service Providers9.4. Network Offerings10. Working With Virtual Machines10.1. About Working with Virtual Machines10.2. Best Practices for Virtual Machines10.3. VM Lifecycle10.4. Creating VMs10.5. Accessing VMs10.6. Stopping and Starting VMs10.7. Changing the VM Name, OS, or Group10.8. Changing the Service Offering for a VM10.9. Moving VMs Between Hosts (Manual Live Migration)10.10. Deleting VMs10.11. Working with ISOs10.11.1. Adding an ISO10.11.2. Attaching an ISO to a VM11. Working With Hosts11.1. Adding Hosts11.2. Scheduled Maintenance and Maintenance Mode for Hosts11.3. Disabling and Enabling Zones, Pods, and Clusters11.4. Removing Hosts11.4.1. Removing XenServer and KVM Hosts11.4.2. Removing vSphere Hosts11.5. Re-Installing Hosts11.6. Maintaining Hypervisors on Hosts11.7. Changing Host Password11.8. Host Allocation11.9. VLAN Provisioning12. Working with Templates12.1. Creating Templates: Overview12.2. Requirements for Templates12.3. Best Practices for Templates12.4. The Default Template12.5. Private and Public Templates12.6. Creating a Template from an Existing Virtual Machine12.7. Creating a Template from a Snapshot12.8. Uploading Templates12.9. Exporting Templates12.10. Creating a Windows Template12.10.1. System Preparation for Windows Server 2008 R212.10.2. Sysprep for Windows Server 2003 R212.11. Importing Amazon Machine Images12.12. Converting a Hyper-V VM to a Template12.13. Adding Password Management to Your Templates12.13.1. Linux OS Installation12.13.2. Windows OS Installation12.14. Deleting Templates13. Working With Storage13.1. Storage Overview13.2. Primary Storage13.3. Secondary Storage13.4. Using Swift for Secondary Storage13.5. Working with Snapshots14. Working with Usage14.1. Configuring the Usage Server14.2. Setting Usage Limits14.3. Globally Configured Limits14.4. Default Account Resource Limits14.5. Per-Domain Limits15. Managing Networks and Traffic15.1. Guest Traffic15.2. Networking in a Pod15.3. Networking in a Zone15.4. Basic Zone Physical Network Configuration15.5. Advanced Zone Physical Network Configuration15.5.1. Configure Guest Traffic in an Advanced Zone15.5.2. Configure Public Traffic in an Advanced Zone15.6. Using Multiple Guest Networks15.6.1. Adding an Additional Guest Network15.6.2. Changing the Network Offering on a Guest Network15.7. Security Groups15.7.1. About Security Groups15.7.2. Adding a Security Group15.7.3. Enabling Security Groups15.7.4. Adding Ingress and Egress Rules to a Security Group15.8. External Firewalls and Load Balancers15.9. Load Balancer Rules15.10. Guest IP Ranges15.11. Acquiring a New IP Address15.12. Releasing an IP Address15.13. Static NAT15.14. IP Forwarding and Firewalling15.15. IP Load Balancing15.16. DNS and DHCP15.17. VPN15.17.1. Configuring VPN15.17.2. Using VPN with Windows15.17.3. Using VPN with Mac OS X15.17.4. Setting Up a Site-to-Site VPN Connection15.17.4.1. Creating and Updating a VPN Customer Gateway15.17.4.2. Creating a VPN gateway for the VPC15.17.4.3. Creating a VPN Connection15.17.4.4. Restarting and Removing a VPN Connection15.18. About Inter-VLAN Routing15.19. Configuring a Virtual Private Cloud15.19.1. About Virtual Private Clouds15.19.2. Adding a Virtual Private Cloud15.19.3. Adding Tiers15.19.4. Configuring Access Control List15.19.5. Adding a Private Gateway to a VPC15.19.6. Deploying VMs to the Tier15.19.7. Acquiring a New IP Address for a VPC15.19.8. Releasing an IP Address Alloted to a VPC15.19.9. Enabling or Disabling Static NAT on a VPC15.19.10. Adding Load Balancing Rules on a VPC15.19.11. Adding a Port Forwarding Rule on a VPC15.19.12. Removing Tiers15.19.13. Editing, Restarting, and Removing a Virtual Private Cloud16. Working with System Virtual Machines16.1. The System VM Template16.2. Multiple System VM Support for VMware16.3. Console Proxy16.4. Virtual Router16.5. Secondary Storage VM17. System Reliability and High Availability17.1. HA for Management Server17.2. HA-Enabled Virtual Machines17.3. HA for Hosts17.4. Primary Storage Outage and Data Loss17.5. Secondary Storage Outage and Data Loss18. Managing the Cloud18.1. Using Tags to Organize Resources in the Cloud18.2. Changing the Database Configuration18.3. Administrator Alerts18.4. Customizing the Network Domain Name18.5. Stopping and Restarting the Management Server19. Setting Global Configuration Parameters20. CloudStack API20.1. Provisioning and Authentication API20.2. Allocators20.3. User Data and Meta Data21. Tuning21.1. Performance Monitoring21.2. Increase Management Server Maximum Memory21.3. Set Database Buffer Pool Size21.4. Set and Monitor Total VM Limits per Host21.5. Configure XenServer dom0 Memory22. Troubleshooting22.1. Events22.1.1. Event Logs22.1.2. Standard Events22.1.3. Long Running Job Events22.1.4. Event Log Queries22.2. Working with Server Logs22.3. Data Loss on Exported Primary Storage22.4. Recovering a Lost Virtual Router22.5. Maintenance mode not working on vCenter22.6. Unable to deploy VMs from uploaded vSphere template22.7. Unable to power on virtual machine on VMware22.8. Load balancer rules fail after changing network offeringA. Time ZonesB. Event TypesC. AlertsD. Revision History
diff --git a/docs/tmp/en-US/epub/OEBPS/troubleshooting-dataloss-on-exported-primary-storage.html b/docs/tmp/en-US/epub/OEBPS/troubleshooting-dataloss-on-exported-primary-storage.html
new file mode 100644
index 00000000000..0afb42fc2b8
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/troubleshooting-dataloss-on-exported-primary-storage.html
@@ -0,0 +1,13 @@
+
+
+22.3. Data Loss on Exported Primary Storage
22.3. 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:
+
+ 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
+
diff --git a/docs/tmp/en-US/epub/OEBPS/troubleshooting-lb-rules-fails.html b/docs/tmp/en-US/epub/OEBPS/troubleshooting-lb-rules-fails.html
new file mode 100644
index 00000000000..28df80f66b1
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/troubleshooting-lb-rules-fails.html
@@ -0,0 +1,9 @@
+
+
+22.8. Load balancer rules fail after changing network offering
22.8. 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 CloudPlatform 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/troubleshooting-maintenance-mode-not-working-on-vCenter.html b/docs/tmp/en-US/epub/OEBPS/troubleshooting-maintenance-mode-not-working-on-vCenter.html
new file mode 100644
index 00000000000..389a08dfad1
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/troubleshooting-maintenance-mode-not-working-on-vCenter.html
@@ -0,0 +1,11 @@
+
+
+22.5. Maintenance mode not working on vCenter
22.5. Maintenance mode not working on vCenter
Symptom
+ Host was placed in maintenance mode, but still appears live in vCenter.
+
Cause
+ The CloudPlatform 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/troubleshooting-recover-lost-virtual-router.html b/docs/tmp/en-US/epub/OEBPS/troubleshooting-recover-lost-virtual-router.html
new file mode 100644
index 00000000000..665a9a8ba39
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/troubleshooting-recover-lost-virtual-router.html
@@ -0,0 +1,19 @@
+
+
+22.4. Recovering a Lost Virtual Router
22.4. 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/troubleshooting-unable-to-deploy-vms.html b/docs/tmp/en-US/epub/OEBPS/troubleshooting-unable-to-deploy-vms.html
new file mode 100644
index 00000000000..9f4a7c54d91
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/troubleshooting-unable-to-deploy-vms.html
@@ -0,0 +1,9 @@
+
+
+22.6. Unable to deploy VMs from uploaded vSphere template
22.6. 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/troubleshooting-unable-to-power-on-vm.html b/docs/tmp/en-US/epub/OEBPS/troubleshooting-unable-to-power-on-vm.html
new file mode 100644
index 00000000000..1a9a1d535e6
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/troubleshooting-unable-to-power-on-vm.html
@@ -0,0 +1,17 @@
+
+
+22.7. Unable to power on virtual machine on VMware
22.7. 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/troubleshooting-working-with-server-logs.html b/docs/tmp/en-US/epub/OEBPS/troubleshooting-working-with-server-logs.html
new file mode 100644
index 00000000000..3f08b633298
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/troubleshooting-working-with-server-logs.html
@@ -0,0 +1,19 @@
+
+
+22.2. Working with Server Logs
22.2. Working with Server Logs
+ The CloudStack Management Server logs all web site, middle tier, and database activities for diagnostics purposes in /var/log/cloud/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.
+
+ 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:
+
+ 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:
+
+ grep "job-1076)" management-server.log
+
+ The CloudStack Agent Server logs its activities in /var/log/cloud/agent/.
+
+ 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..
+
22.1.2. 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
+
22.1.3. 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
+
22.1.4. 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
+
+ This section provides tips on how to improve the performance of your cloud.
+
21.1. Performance Monitoring
+ Host and guest performance monitoring is available to end users and administrators. This allows the user to monitor their utilization of resources and determine when it is appropriate to choose a more powerful service offering or larger disk.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/ui.html b/docs/tmp/en-US/epub/OEBPS/ui.html
new file mode 100644
index 00000000000..b6bcda11940
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/ui.html
@@ -0,0 +1,62 @@
+
+
+Chapter 5. User Interface
Chapter 5. User Interface
5.1. Log In to the UI
+ CloudStack provides a web-based UI that can be used by both administrators and end users. The appropriate version of the UI is displayed depending on the credentials used to log in. The UI is available in popular browsers including IE7, IE8, IE9, Firefox 3.5+, Firefox 4, Safari 4, and Safari 5. The URL is: (substitute your own management server IP address)
+
http://<management-server-ip-address>:8080/client
+ On a fresh Management Server installation, a guided tour splash screen appears. On later visits, you’ll see a login screen where you specify the following to proceed to your Dashboard:
+
Username
+ The user ID of your account. The default username is admin.
+
Password
+ The password associated with the user ID. The password for the default username is password.
+
Domain
+ If you are a root user, leave this field blank.
+
+ If you are a user in the sub-domains, enter the full path to the domain, excluding the root domain.
+
+ For example, suppose multiple levels are created under the root domain, such as Comp1/hr. The users in the Comp1 domain should enter Comp1 in the Domain field, whereas the users in the Comp1/sales domain should enter Comp1/sales.
+
+ For more guidance about the choices that appear when you log in to this UI, see Logging In as the Root Administrator.
+
5.1.1. End User's UI Overview
+ The CloudStack UI helps users of cloud infrastructure to view and use their cloud resources, including virtual machines, templates and ISOs, data volumes and snapshots, guest networks, and IP addresses. If the user is a member or administrator of one or more CloudStack projects, the UI can provide a project-oriented view.
+
5.1.2. Root Administrator's UI Overview
+ The CloudStack UI helps the CloudStack administrator provision, view, and manage the cloud infrastructure, domains, user accounts, projects, and configuration settings. The first time you start the UI after a fresh Management Server installation, you can choose to follow a guided tour to provision your cloud infrastructure. On subsequent logins, the dashboard of the logged-in user appears. The various links in this screen and the navigation bar on the left provide access to a variety of administrative functions. The root administrator can also use the UI to perform all the same tasks that are present in the end-user’s UI.
+
5.1.3. Logging In as the Root Administrator
+ After the Management Server software is installed and running, you can run the CloudStack user interface. This UI is there to help you provision, view, and manage your cloud infrastructure.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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 can enter a user ID and password and proceed to your 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 CloudPlatform, 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”.
+
Warning
+ You are logging in as the root administrator. This account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. Please change the default password to a new, unique password.
+
5.1.4. Changing the Root Password
+ During installation and ongoing cloud administration, you will need to log in to the UI as the root administrator. The root administrator account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. When first installing CloudStack, be sure to change the default password to a new, unique value.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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.
+
+ If you are uploading a template that was created using vSphere Client, be sure the OVA file does not contain an ISO. If it does, the deployment of VMs from the template will fail.
+
+ Templates are uploaded based on a URL. HTTP is the supported access protocol. Templates are frequently large files. You can optionally gzip them to decrease upload times.
+
+ To upload a template:
+
+ In the left navigation bar, click Templates.
+
+ Click Create Template.
+
+ Provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ URL. The Management Server will download the file from the specified URL, such as http://my.web.server/filename.vhd.gz.
+
+ Zone. Choose the zone where you want the template to be available, or All Zones to make it available throughout CloudStack.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following:
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
Note
+ You should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Hypervisor
+
+ Format. The format of the template upload file, such as VHD or OVA.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates
+
+ Extractable. Choose Yes if the template is available for extraction. If this option is selected, end users can download a full image of a template.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”
+
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. The template will appear in the Featured Templates list. Only an administrator can make a template Featured.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/use-project-view.html b/docs/tmp/en-US/epub/OEBPS/use-project-view.html
new file mode 100644
index 00000000000..0627fe37e81
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/use-project-view.html
@@ -0,0 +1,15 @@
+
+
+6.7. Using the Project View
6.7. 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/user-data-and-meta-data.html b/docs/tmp/en-US/epub/OEBPS/user-data-and-meta-data.html
new file mode 100644
index 00000000000..b5a6abea71d
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/user-data-and-meta-data.html
@@ -0,0 +1,27 @@
+
+
+20.3. User Data and Meta Data
20.3. User Data and Meta Data
+ CloudStack provides API access to attach 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.
+
+ Access user data by running the following command using the result of the above command
+
# 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
+
diff --git a/docs/tmp/en-US/epub/OEBPS/user-services-overview.html b/docs/tmp/en-US/epub/OEBPS/user-services-overview.html
new file mode 100644
index 00000000000..0338a683c5c
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/user-services-overview.html
@@ -0,0 +1,17 @@
+
+
+Chapter 4. User Services Overview
Chapter 4. User Services Overview
+ In addition to the physical and logical infrastructure of your cloud, and the CloudStack software and servers, you also need a layer of user services so that people can actually make use of the cloud. This means not just a user UI, but a set of options and resources that users can choose from, such as templates for creating virtual machines, disk storage, and more. If you are running a commercial service, you will be keeping track of what services and resources users are consuming and charging them for that usage. Even if you do not charge anything for people to use your cloud – say, if the users are strictly internal to your organization, or just friends who are sharing your cloud – you can still keep track of what services they use and how much of them.
+
4.1. Service Offerings, Disk Offerings, Network Offerings, and Templates
+ A user creating a new instance can make a variety of choices about its characteristics and capabilities. CloudStack provides several ways to present users with choices when creating a new instance:
+
+ Service Offerings, defined by the CloudStack administrator, provide a choice of CPU speed, number of CPUs, RAM size, tags on the root disk, and other choices. See Creating a New Compute Offering.
+
+ Disk Offerings, defined by the CloudStack administrator, provide a choice of disk size for primary data storage. See Creating a New Disk Offering.
+
+ Network Offerings, defined by the CloudStack administrator, describe the feature set that is available to end users from the virtual router or external networking devices on a given guest network. See Network Offerings.
+
+ Templates, defined by the CloudStack administrator or by any CloudStack user, are the base OS images that the user can choose from when creating a new instance. For example, CloudStack includes CentOS as a template. See Working with Templates.
+
+ In addition to these choices that are provided for users, there is another type of service offering which is available only to the CloudStack root administrator, and is used for configuring virtual infrastructure resources. For more information, see Upgrading a Virtual Router with System Service Offerings.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/using-multiple-guest-networks.html b/docs/tmp/en-US/epub/OEBPS/using-multiple-guest-networks.html
new file mode 100644
index 00000000000..aa5e3bade05
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/using-multiple-guest-networks.html
@@ -0,0 +1,51 @@
+
+
+15.6. Using Multiple Guest Networks
15.6. Using Multiple Guest Networks
+ In zones that use advanced networking, additional networks for guest traffic may be added at any time after the initial installation. You can also customize the domain name associated with the network by specifying a DNS suffix for each network.
+
+ A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has been created, although the user can go into the guest and remove the IP address from the NIC on a particular network.
+
+ Each VM has just one default network. The virtual router's DHCP reply will set the guest's default gateway as that for the default network. Multiple non-default networks may be added to a guest in addition to the single, required default network. The administrator can control which networks are available as the default network.
+
+ Additional networks can either be available to all accounts or be assigned to a specific account. Networks that are available to all accounts are zone-wide. Any user with access to the zone can create a VM with access to that network. These zone-wide networks provide little or no isolation between guests.Networks that are assigned to a specific account provide strong isolation.
+
15.6.1. Adding an Additional Guest Network
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click Add guest network. Provide the following information:
+
+ Name: The name of the network. This will be user-visible.
+
+ Display Text: The description of the network. This will be user-visible.
+
+ Zone. The name of the zone this network applies to. Each zone is a broadcast domain, and therefore each zone has a different IP range for the guest network. The administrator must configure the IP range for each zone.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network.
+
+ Guest Gateway: The gateway that the guests should use.
+
+ Guest Netmask: The netmask in use on the subnet the guests will use.
+
+ Click Create.
+
15.6.2. Changing the Network Offering on a Guest Network
+ A user or administrator can change the network offering that is associated with an existing guest network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ If you are changing from a network offering that uses the CloudStack virtual router to one that uses external devices as network service providers, you must first stop all the VMs on the network. See Stopping and Starting VMs. Then return here and continue to the next step
+
+ In the left navigation, choose Network
+
+ Click the name of the network you want to modify
+
+ .
+
+ In Network Offering, choose the new network offering, then click Apply.
+
+ A prompt appears asking whether you want to keep the existing CIDR. This is to let you know that if you change the network offering, the CIDR will be affected. Choose No to proceed with the change.
+
+ Wait for the update to complete. Don’t try to restart VMs until after the network change is complete.
+
+ If you stopped any VMs in step 2, restart them.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/using-sshkeys.html b/docs/tmp/en-US/epub/OEBPS/using-sshkeys.html
new file mode 100644
index 00000000000..a38bbd5e60d
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/using-sshkeys.html
@@ -0,0 +1,74 @@
+
+
+5.2. Using SSH Keys for Authentication
5.2. Using SSH Keys for Authentication
+ In addition to the username and password authentication, CloudStack supports using SSH keys to log in to the cloud infrastructure for additional security. You can use the createSSHKeyPair API to generate the SSH keys.
+
+ Because each cloud user has their own SSH key, one cloud user cannot log in to another cloud user's instances unless they share their SSH key files. Using a single SSH key pair, you can manage multiple instances.
+
5.2.1. Creating an Instance Template that Supports SSH Keys
+ Create a instance template that supports SSH Keys.
+
+ Create a new instance by using the template provided by cloudstack.
+
+ For more information on creating a new instance, see
+
+ Download the cloudstack script from The SSH Key Gen Scriptto the instance you have created.
+
+ Run the script while starting up the operating system:
+
chkconfig --add cloud-set-guest-sshkey.in
+ Stop the instance.
+
5.2.2. Creating the SSH Keypair
+ You must make a call to the createSSHKeyPair api method. You can either use the CloudStack Python API library or the curl commands to make the call to the cloudstack api.
+
+ For example, make a call from the cloudstack server to create a SSH keypair called "keypair-doc" for the admin account in the root domain:
+
Note
+ Ensure that you adjust these values to meet your needs. If you are making the API call from a different server, your URL/PORT will be different, and you will need to use the API keys.
+
+ Substitute the template, service offering and security group IDs (if you are using the security group feature) that are in your cloud environment.
+
5.2.4. Logging In Using the SSH Keypair
+ To test your SSH key generation is successful, check whether you can log in to the cloud setup.
+
+ For exaple, from a Linux OS, run:
+
ssh -i ~/.ssh/keypair-doc <ip address>
+ The -i parameter tells the ssh client to use a ssh key found at ~/.ssh/keypair-doc.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/virtual-machines.html b/docs/tmp/en-US/epub/OEBPS/virtual-machines.html
new file mode 100644
index 00000000000..62a92ce8217
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/virtual-machines.html
@@ -0,0 +1,21 @@
+
+
+Chapter 10. Working With Virtual Machines
Chapter 10. Working With Virtual Machines
10.1. About Working with Virtual Machines
+ CloudStack provides administrators with complete control over the lifecycle of all guest VMs executing in the cloud. CloudStack provides several guest management operations for end users and administrators. VMs may be stopped, started, rebooted, and destroyed.
+
+ Guest VMs have a name and group. VM names and groups are opaque to CloudStack and are available for end users to organize their VMs. Each VM can have three names for use in different contexts. Only two of these names can be controlled by the user:
+
+ Instance name – a unique, immutable ID that is generated by CloudStack and can not be modified by the user. This name conforms to the requirements in IETF RFC 1123.
+
+ Display name – the name displayed in the CloudStack web UI. Can be set by the user. Defaults to instance name.
+
+ Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to instance name
+
+ Guest VMs can be configured to be Highly Available (HA). An HA-enabled VM is monitored by the system. If the system detects that the VM is down, it will attempt to restart the VM, possibly on a different host. For more information, see HA-Enabled Virtual Machines on
+
+ Each new VM is allocated one public IP address. When the VM is started, CloudStack automatically creates a static NAT between this public IP address and the private IP address of the VM.
+
+ If elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new VM is not marked as elastic. The user must replace the automatically configured IP with a specifically acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s private IP. The VM’s original IP address is then released and returned to the pool of available public IPs.
+
+ CloudStack cannot distinguish a guest VM that was shut down by the user (such as with the “shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut down from inside the VM, CloudStack will restart it. To shut down an HA-enabled VM, you must go through the CloudStack UI or API.
+
+ The virtual router is a type of System Virtual Machine. The virtual router is one of the most frequently used service providers in CloudStack. The end user has no direct access to the virtual router. Users can ping the virtual router and take actions that affect it (such as setting up port forwarding), but users do not have SSH access into the virtual router.
+
+ There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be restarted by administrators, but this will interrupt public network access and other services for end users. A basic test in debugging networking issues is to attempt to ping the virtual router from a guest VM. Some of the characteristics of the virtual router are determined by its associated system service offering.
+
+ 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.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/vm-lifecycle.html b/docs/tmp/en-US/epub/OEBPS/vm-lifecycle.html
new file mode 100644
index 00000000000..f8ee057f8c0
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/vm-lifecycle.html
@@ -0,0 +1,21 @@
+
+
+10.3. VM Lifecycle
10.3. VM Lifecycle
+ Virtual machines can be in the following states:
+
+ Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual machine will be reclaimed by the system. This includes the virtual machine’s IP address.
+
+ A stop will attempt to gracefully shut down the operating system, which typically involves terminating all the running applications. If the operation system cannot be stopped, it will be forcefully terminated. This has the same effect as pulling the power cord to a physical machine.
+
+ A reboot is a stop followed by a start.
+
+ CloudPlatform preserves the state of the virtual machine hard disk until the machine is destroyed.
+
+ A running virtual machine may fail because of hardware or network issues. A failed virtual machine is in the down state.
+
+ The system places the virtual machine into the down state if it does not receive the heartbeat from the hypervisor for three minutes.
+
+ The user can manually restart the virtual machine from the down state.
+
+ The system will start the virtual machine from the down state automatically if the virtual machine is marked as HA-enabled.
+
+ CloudStack account owners can create virtual private networks (VPN) to access their virtual machines. If the guest network is instantiated from a network offering that offers the Remote Access VPN service, the virtual router (based on the System VM) is used to provide the service. CloudStack provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN. CloudStack does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.
+
Note
+ Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
+
+ Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
+
+ Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.
+
15.17.1. Configuring VPN
+ To set up VPN for the cloud:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, click Global Settings.
+
+ Set the following global configuration parameters.
+
+ remote.access.vpn.client.ip.range – The range of IP addressess to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
+
+ remote.access.vpn.psk.length – Length of the IPSec key.
+
+ remote.access.vpn.user.limit – Maximum number of VPN users per account.
+
+ To enable VPN for a particular network:
+
+ Log in as a user or administrator to the CloudStack UI.
+
+ In the left navigation, click Network.
+
+ Click the name of the network you want to work with.
+
+ Click View IP Addresses.
+
+ Click one of the displayed IP address names.
+
+ Click the Enable VPN button
+
+ .
+
+ The IPsec key is displayed in a popup window.
+
15.17.2. Using VPN with Windows
+ The procedure to use VPN varies by Windows version. Generally, the user must edit the VPN properties and make sure that the default route is not the VPN. The following steps are for Windows L2TP clients on Windows Vista. The commands should be similar for other Windows versions.
+
+ Log in to the CloudStack UI and click on the source NAT IP for the account. The VPN tab should display the IPsec preshared key. Make a note of this and the source NAT IP. The UI also lists one or more users and their passwords. Choose one of these users, or, if none exists, add a user and password.
+
+ On the Windows box, go to Control Panel, then select Network and Sharing center. Click Setup a connection or network.
+
+ In the next dialog, select No, create a new connection.
+
+ In the next dialog, select Use my Internet Connection (VPN).
+
+ In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check Don't connect now.
+
+ In the next dialog, enter the user name and password selected in step 1.
+
+ Click Create.
+
+ Go back to the Control Panel and click Network Connections to see the new connection. The connection is not active yet.
+
+ Right-click the new connection and select Properties. In the Properties dialog, select the Networking tab.
+
+ In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key. Enter the preshared key from Step 1.
+
+ The connection is ready for activation. Go back to Control Panel -> Network Connections and double-click the created connection.
+
+ Enter the user name and password from Step 1.
+
15.17.3. Using VPN with Mac OS X
+ In Mac OS X, in Network Preferences - Advanced, make sure Send all traffic over VPN connection is not checked.
+
15.17.4. Setting Up a Site-to-Site VPN Connection
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+
+ Cisco ISR with IOS 12.4 or later
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
Note
+ In addition to the specific Cisco and Juniper devices listed above, the expectation is that any Cisco or Juniper device running on the supported operating systems are able to establish VPN connections.
+
+ To set up a Site-to-Site VPN connection, perform the following:
+
+ Create a VPN gateway for the VPC that you created.
+
+ Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
+
15.17.4.1. Creating and Updating a VPN Customer Gateway
Note
+ A VPN customer gateway can be connected to only one VPN gateway at a time.
+
+ To add a VPN Customer Gateway:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Click Add site-to-site VPN.
+
+ Provide the following information:
+
+ Name: A unique name for the VPN customer gateway you create.
+
+ Gateway: The IP address for the remote gateway.
+
+ CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be RFC1918-compliant.
+
+ IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share a secret key. This key value is used to authenticate the customer gateway and the VPC VPN gateway to each other.
+
Note
+ The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.
+
+ IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is accomplished through the Preshared Keys.
+
Note
+ The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.
+
+ IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.
+
+ IKE DH: A public-key cryptography protocol which allows two parties to establish a shared secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).
+
+ ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192, AES256, and 3DES.
+
Note
+ The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.
+
+ ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash algorithms are SHA1 and MD5.
+
+ Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised. This property enforces a new Diffie-Hellman key exchange. It provides the keying material that has greater key material life and thereby greater resistance to cryptographic attacks. The available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key exchanges increase as the DH groups grow larger, as does the time of the exchanges.
+
Note
+ When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.
+
+ IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is 86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.
+
+ ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a new IPsec encryption and authentication session keys.
+
+ Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual router to query the liveliness of its IKE peer at regular intervals. It’s recommended to have the same configuration of DPD on both side of VPN connection.
+
+ Click OK.
+
Updating and Removing a VPN Customer Gateway
+ You can update a customer gateway either with no VPN connection, or related VPN connection is in error state.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Select the VPN customer gateway you want to work with.
+
+ To modify the required parameters, click the Edit VPN Customer Gateway button
+
+
+ To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
+
+
+ Click OK.
+
15.17.4.2. Creating a VPN gateway for the VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Site-to-Site VPN.
+
+ If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN prompts you to create a VPN gateway.
+
+ In the confirmation dialog, click Yes to confirm.
+
+ Within a few moments, the VPN gateway is created. You will be prompted to view the details of the VPN gateway you have created. Click Yes to confirm.
+
+ The following details are displayed in the VPN Gateway page:
+
+ IP Address
+
+ Account
+
+ Domain
+
15.17.4.3. Creating a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you create for the account are listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ Click Create VPN Connection.
+
+ The Create VPN Connection dialog is displayed:
+
+ Select the desired customer gateway, then click OK to confirm.
+
+ Within a few moments, the VPN Connection is displayed.
+
+ The following information on the VPN connection is displayed:
+
+ IP Address
+
+ Gateway
+
+ State
+
+ IPSec Preshared Key
+
+ IKE Policy
+
+ ESP Policy
+
15.17.4.4. Restarting and Removing a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ All the VPN connections you created are displayed.
+
+ Select the VPN connection you want to work with.
+
+ The Details tab is displayed.
+
+ To remove a VPN connection, click the Delete VPN connection button
+
+
+ To restart a VPN connection, click the Reset VPN connection button present in the Details tab.
+
+
diff --git a/docs/tmp/en-US/epub/OEBPS/work-with-usage.html b/docs/tmp/en-US/epub/OEBPS/work-with-usage.html
new file mode 100644
index 00000000000..3cf7dcdbad8
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/work-with-usage.html
@@ -0,0 +1,129 @@
+
+
+Chapter 14. Working with Usage
Chapter 14. Working with Usage
+ The Usage Server is an optional, separately-installed part of CloudStack that provides aggregated usage records which you can use to create billing integration for CloudStack. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances.
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day.
+
14.1. Configuring the Usage Server
+ To configure the usage server:
+
+ Be sure the Usage Server has been installed. This requires extra steps beyond just installing the CloudStack software. See Installing the Usage Server (Optional) in the Advanced Installation Guide.
+
+ Log in to the CloudStack UI as administrator.
+
+ Click Global Settings.
+
+ In Search, type usage. Find the configuration parameter that controls the behavior you want to set. See the table below for a description of the available parameters.
+
+ In Actions, click the Edit icon.
+
+ Type the desired value and click the Save icon.
+
+ Restart the Management Server (as usual with any global configuration change) and also the Usage Server:
+
# service cloud-management restart
+# service cloud-usage restart
+
+ The following table shows the global configuration settings that control the behavior of the Usage Server.
+
+
+ Parameter Name
+
+
+
+ Description
+
+
+
+ enable.usage.server
+
+
+
+ Whether the Usage Server is active.
+
+
+
+ usage.aggregation.timezone
+
+
+
+ Time zone of usage records. Set this if the usage records and daily job execution are in different time zones. For example, with the following settings, the usage job will run at PST 00:15 and generate usage records for the 24 hours from 00:00:00 GMT to 23:59:59 GMT:
+
+ The time zone of usage.stats.job.exec.time. Valid values for the time zone are specified in Appendix A, Time Zones
+
+
+ Default: The time zone of the management server.
+
+
+
+
+ usage.sanity.check.interval
+
+
+
+ The number of days between sanity checks. Set this in order to periodically search for records with erroneous data before issuing customer invoices. For example, this checks for VM usage records created after the VM was destroyed, and similar checks for templates, volumes, and so on. It also checks for usage times longer than the aggregation range. If any issue is found, the alert ALERT_TYPE_USAGE_SANITY_RESULT = 21 is sent.
+
+
+
+ usage.stats.job.aggregation.range
+
+
+
+ The time period in minutes between Usage Server processing jobs. For example, if you set it to 1440, the Usage Server will run once per day. If you set it to 600, it will run every ten hours. In general, when a Usage Server job runs, it processes all events generated since usage was last run.
+
+
+ There is special handling for the case of 1440 (once per day). In this case the Usage Server does not necessarily process all records since Usage was last run. CloudStack assumes that you require processing once per day for the previous, complete day’s records. For example, if the current day is October 7, then it is assumed you would like to process records for October 6, from midnight to midnight. CloudStack assumes this "midnight to midnight" is relative to the usage.execution.timezone.
+
+
+ Default: 1440
+
+
+
+
+ usage.stats.job.exec.time
+
+
+
+ The time when the Usage Server processing will start. It is specified in 24-hour format (HH:MM) in the time zone of the server, which should be GMT. For example, to start the Usage job at 10:30 GMT, enter "10:30".
+
+
+ If usage.stats.job.aggregation.range is also set, and its value is not 1440, then its value will be added to usage.stats.job.exec.time to get the time to run the Usage Server job again. This is repeated until 24 hours have elapsed, and the next day's processing begins again at usage.stats.job.exec.time.
+
+
+ Default: 00:15.
+
+
+
+ For example, suppose that your server is in GMT, your user population is predominantly in the East Coast of the United States, and you would like to process usage records every night at 2 AM local (EST) time. Choose these settings:
+
+ enable.usage.server = true
+
+ usage.execution.timezone = America/New_York
+
+ usage.stats.job.exec.time = 07:00. This will run the Usage job at 2:00 AM EST. Note that this will shift by an hour as the East Coast of the U.S. enters and exits Daylight Savings Time.
+
+ usage.stats.job.aggregation.range = 1440
+
+ With this configuration, the Usage job will run every night at 2 AM EST and will process records for the previous day’s midnight-midnight as defined by the EST (America/New_York) time zone.
+
Note
+ Because the special value 1440 has been used for usage.stats.job.aggregation.range, the Usage Server will ignore the data between midnight and 2 AM. That data will be included in the next day's run
+
diff --git a/docs/tmp/en-US/epub/OEBPS/working-with-hosts.html b/docs/tmp/en-US/epub/OEBPS/working-with-hosts.html
new file mode 100644
index 00000000000..7bef93014e0
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/working-with-hosts.html
@@ -0,0 +1,5 @@
+
+
+Chapter 11. Working With Hosts
Chapter 11. Working With Hosts
11.1. Adding Hosts
+ Additional hosts can be added at any time to provide more capacity for guest VMs. For requirements and instructions, see Section 7.5, “Adding a Host”.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/working-with-iso.html b/docs/tmp/en-US/epub/OEBPS/working-with-iso.html
new file mode 100644
index 00000000000..3fec19ff440
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/working-with-iso.html
@@ -0,0 +1,125 @@
+
+
+10.11. Working with ISOs
10.11. Working with ISOs
+ CloudStack supports ISOs and their attachment to guest VMs. An ISO is a read-only file that has an ISO/CD-ROM style file system. Users can upload their own ISOs and mount them on their guest VMs.
+
+ ISOs are uploaded based on a URL. HTTP is the supported protocol. Once the ISO is available via HTTP specify an upload URL such as http://my.web.server/filename.iso.
+
+ ISOs may be public or private, like templates.ISOs are not hypervisor-specific. That is, a guest on vSphere can mount the exact same image that a guest on KVM can mount.
+
+ ISO images may be stored in the system and made available with a privacy level similar to templates. ISO images are classified as either bootable or not bootable. A bootable ISO image is one that contains an OS image. CloudStack allows a user to boot a guest VM off of an ISO image. Users can also attach ISO images to guest VMs. For example, this enables installing PV drivers into Windows. ISO images are not hypervisor-specific.
+
10.11.1. Adding an ISO
+ To make additional operating system or other software available for use with guest VMs, you can add an ISO. The ISO is typically thought of as an operating system image, but you can also add ISOs for other types of software, such as desktop applications that you want to be installed as part of a template.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation bar, click Templates.
+
+ In Select View, choose ISOs.
+
+ Click Add ISO.
+
+ In the Add ISO screen, provide the following:
+
+ Name: Short name for the ISO image. For example, CentOS 6.2 64-bit.
+
+ Description: Display test for the ISO image. For example, CentOS 6.2 64-bit.
+
+ URL: The URL that hosts the ISO image. The Management Server must be able to access this location via HTTP. If needed you can place the ISO image directly on the Management Server
+
+ Zone: Choose the zone where you want the ISO to be available, or All Zones to make it available throughout CloudStack.
+
+ Bootable: Whether or not a guest could boot off this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not bootable.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of your desired ISO image is listed, choose it.
+
+ If the OS Type of the ISO is not listed or if the ISO is not bootable, choose Other.
+
+ (XenServer only) If you want to boot from this ISO in PV mode, choose Other PV (32-bit) or Other PV (64-bit)
+
+ (KVM only) If you choose an OS that is PV-enabled, the VMs created from this ISO will have a SCSI (virtio) root disk. If the OS is not PV-enabled, the VMs will have an IDE root disk. The PV-enabled types are:
+
+
+ Fedora 13
+
+
+
+ Fedora 12
+
+
+
+ Fedora 11
+
+
+
+ Fedora 10
+
+
+
+ Fedora 9
+
+
+
+ Other PV
+
+
+
+ Debian GNU/Linux
+
+
+
+ CentOS 5.3
+
+
+
+ CentOS 5.4
+
+
+
+ CentOS 5.5
+
+
+
+ Red Hat Enterprise Linux 5.3
+
+
+
+ Red Hat Enterprise Linux 5.4
+
+
+
+ Red Hat Enterprise Linux 5.5
+
+
+
+ Red Hat Enterprise Linux 6
+
+
+
Note
+ It is not recommended to choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not work. In these cases, choose Other.
+
+ Extractable: Choose Yes if the ISO should be available for extraction.
+
+ Public: Choose Yes if this ISO should be available to other users.
+
+ Featured: Choose Yes if you would like this ISO to be more prominent for users to select. The ISO will appear in the Featured ISOs list. Only an administrator can make an ISO Featured.
+
+ Click OK.
+
+ The Management Server will download the ISO. Depending on the size of the ISO, this may take a long time. The ISO status column will display Ready once it has been successfully downloaded into secondary storage. Clicking Refresh updates the download percentage.
+
+ Important: Wait for the ISO to finish downloading. If you move on to the next task and try to use the ISO right away, it will appear to fail. The entire ISO must be available before CloudStack can work with it.
+
10.11.2. Attaching an ISO to a VM
+ In the left navigation, click Instances.
+
+ Choose the virtual machine you want to work with.
+
+ Click the Attach ISO button
+
+
+ In the Attach ISO dialog box, select the desired ISO.
+
+ Click OK
+
diff --git a/docs/tmp/en-US/epub/OEBPS/working-with-snapshots.html b/docs/tmp/en-US/epub/OEBPS/working-with-snapshots.html
new file mode 100644
index 00000000000..ca18466d990
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/working-with-snapshots.html
@@ -0,0 +1,13 @@
+
+
+13.5. Working with Snapshots
13.5. Working with Snapshots
+ (Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)
+
+ CloudStack supports snapshots of disk volumes. Snapshots are a point-in-time capture of virtual machine disks. Memory and CPU states are not captured.
+
+ Snapshots may be taken for volumes, including both root and data disks. The administrator places a limit on the number of stored snapshots per user. Users can create new volumes from the snapshot for recovery of particular files and they can create templates from snapshots to boot from a restored disk.
+
+ Users can create snapshots manually or by setting up automatic recurring snapshot policies. Users can also create disk volumes from snapshots, which may be attached to a VM like any other disk volume. Snapshots of both root disks and data disks are supported. However, CloudStack does not currently support booting a VM from a recovered root disk. A disk recovered from snapshot of a root disk is treated as a regular data disk; the data on recovered disk can be accessed by attaching the disk to a VM.
+
+ A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/working-with-system-vm.html b/docs/tmp/en-US/epub/OEBPS/working-with-system-vm.html
new file mode 100644
index 00000000000..baec6ff68ac
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/working-with-system-vm.html
@@ -0,0 +1,21 @@
+
+
+Chapter 16. Working with System Virtual Machines
Chapter 16. Working with System Virtual Machines
+ CloudStack uses several types of system virtual machines to perform tasks in the cloud. In general CloudStack manages these system VMs and creates, starts, and stops them as needed based on scale and immediate needs. However, the administrator should be aware of them and their roles to assist in debugging issues.
+
16.1. The System VM Template
+ The System VMs come from a single template. The System VM has the following characteristics:
+
+ Debian 6.0 ("Squeeze"), 2.6.32 kernel with the latest security patches from the Debian security APT repository
+
+ Has a minimal set of packages installed thereby reducing the attack surface
+
+ 32-bit for enhanced performance on Xen/VMWare
+
+ pvops kernel with Xen PV drivers, KVM virtio drivers, and VMware tools for optimum performance on all hypervisors
+
+ Latest versions of HAProxy, iptables, IPsec, and Apache from debian repository ensures improved security and speed
+
+ Latest version of JRE from Sun/Oracle ensures improved security and speed
+
diff --git a/docs/tmp/en-US/epub/OEBPS/working-with-templates.html b/docs/tmp/en-US/epub/OEBPS/working-with-templates.html
new file mode 100644
index 00000000000..d112271526d
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/working-with-templates.html
@@ -0,0 +1,21 @@
+
+
+Chapter 12. Working with Templates
Chapter 12. Working with Templates
+ A template is a reusable configuration for virtual machines. When users launch VMs, they can choose from a list of templates in CloudStack.
+
+ Specifically, a template is a virtual disk image that includes one of a variety of operating systems, optional additional software such as office applications, and settings such as access control to determine who can use the template. Each template is associated with a particular type of hypervisor, which is specified when the template is added to CloudStack.
+
+ CloudStack ships with a default template. In order to present more choices to users, CloudStack administrators and users can create templates and add them to CloudStack.
+
12.1. Creating Templates: Overview
+ CloudStack ships with a default template for the CentOS operating system. There are a variety of ways to add more templates. Administrators and end users can add templates. The typical sequence of events is:
+
+ Launch a VM instance that has the operating system you want. Make any other desired configuration changes to the VM.
+
+ Stop the VM.
+
+ Convert the volume into a template.
+
+ There are other ways to add templates to CloudStack. For example, you can take a snapshot of the VM's volume and create a template from the snapshot, or import a VHD from another system into CloudStack
+
+ The various techniques for creating templates are described in the next few sections.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/working-with-volumes.html b/docs/tmp/en-US/epub/OEBPS/working-with-volumes.html
new file mode 100644
index 00000000000..378cf536d39
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/working-with-volumes.html
@@ -0,0 +1,9 @@
+
+
+13.4. Using Swift for Secondary Storage
13.4. Using Swift for Secondary Storage
+ A volume provides storage to a guest VM. The volume can provide for a root disk or an additional data disk. CloudStack supports additional volumes for guest VMs.
+
+ Volumes are created for a specific hypervisor type. A volume that has been attached to guest using one hypervisor type (e.g, XenServer) may not be attached to a guest that is using another hypervisor type (e.g. vSphere, KVM). This is because the different hypervisors use different disk image formats.
+
+ CloudStack defines a volume as a unit of storage available to a guest VM. Volumes are either root disks or data disks. The root disk has "/" in the file system and is usually the boot device. Data disks provide for additional storage (e.g. As "/opt" or "D:"). Every guest VM has a root disk, and VMs can also optionally have a data disk. End users can mount multiple data disks to guest VMs. Users choose data disks from the disk offerings created by administrators. The user can create a template from a volume as well; this is the standard procedure for private template creation. Volumes are hypervisor-specific: a volume from one hypervisor type may not be used on a guest of another hypervisor type.
+
diff --git a/docs/tmp/en-US/epub/OEBPS/zone-add.html b/docs/tmp/en-US/epub/OEBPS/zone-add.html
new file mode 100644
index 00000000000..057e11ee734
--- /dev/null
+++ b/docs/tmp/en-US/epub/OEBPS/zone-add.html
@@ -0,0 +1,379 @@
+
+
+7.2. Adding a Zone
+ (Optional) If you are going to use Swift for cloud-wide secondary storage, you need to add it before you add zones.
+
+ Log in to the CloudStack UI as administrator.
+
+ If this is your first time visiting the UI, you will see the guided tour splash screen. Choose “Experienced user.” The Dashboard appears.
+
+ In the left navigation bar, click Global Settings.
+
+ In the search box, type swift.enable and click the search button.
+
+ Click the edit button and set swift.enable to true.
+
+
+
+ Restart the Management Server.
+
# service cloud-management restart
+ Refresh the CloudStack UI browser tab and log back in.
+
+ In the left navigation, choose Infrastructure.
+
+ On Zones, click View More.
+
+ (Optional) If you are using Swift storage, click Enable Swift. Provide the following:
+
+ URL. The Swift URL.
+
+ Account. The Swift account.
+
+ Username. The Swift account’s username.
+
+ Key. The Swift key.
+
+ 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.
+
+ For more information about the network types, see Network Setup.
+
+ The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you:
+
+ 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.
+
+ 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.
+
+ (Introduced in version 3.0.1) 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.2, “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, CloudPlatform 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.
+
7.2.2. 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.7.4, “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.
+
+ 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.2, “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.7.7, “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.3, “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.4, “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.5, “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.6, “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 :
+
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+ CloudStack is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. CloudStack manages the network, storage, and compute nodes that make up a cloud infrastructure. Use CloudStack to deploy, manage, and configure cloud computing environments.
+
+ Typical users are service providers and enterprises. With CloudStack, you can:
+
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with CloudStack an enterprise can offer self-service virtual machines to users without involving IT departments.
+
1.2. What Can CloudStack Do?
+ Multiple Hypervisor Support
+
+ CloudStack works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of CloudStack supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+ Massively Scalable Infrastructure Management
+
+ CloudStack can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+ Automatic Configuration Management
+
+ CloudStack automatically configures each guest virtual machine’s networking and storage settings.
+
+ CloudStack internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+ Graphical User Interface
+
+ CloudStack offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+ API and Extensibility
+
+ CloudStack provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at Apache CloudStack Guides and Apache CloudStack API Reference respectively.
+
+ CloudStack has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the hosts, CloudStack supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+
1.3. Deployment Architecture Overview
+ A CloudStack installation consists of two parts: the Management Server and the cloud infrastructure that it manages. When you set up and manage a CloudStack cloud, you provision resources such as hosts, storage devices, and IP addresses into the Management Server, and the Management Server manages those resources.
+
+ The minimum production installation consists of one machine running the CloudStack Management Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure consisting of one host running hypervisor software). In its smallest deployment, a single machine can act as both the Management Server and the hypervisor host (using the KVM hypervisor).
+
+ A more full-featured installation consists of a highly-available multi-node Management Server installation and up to tens of thousands of hosts using any of several advanced networking setups. For information about deployment options, see Choosing a Deployment Architecture.
+
1.3.1. Management Server Overview
+ The Management Server is the CloudStack software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+ The machine must meet the system requirements described in System Requirements.
+
+ The Management Server:
+
+ Provides the web user interface for the administrator and a reference user interface for end users.
+
+ Provides the APIs for CloudStack.
+
+ Manages the assignment of guest VMs to particular hosts.
+
+ Manages the assignment of public and private IP addresses to particular accounts.
+
+ Manages the allocation of storage to guests as virtual disks.
+
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+
+ Provides a single point of configuration for the cloud.
+
1.3.2. Cloud Infrastructure Overview
+ The Management Server manages one or more zones (typically, datacenters) containing host computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
+
+ Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
+
+ Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
+
+ Cluster: A cluster consists of one or more hosts and primary storage.
+
+ Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines.
+
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster.
+
+ Secondary storage is associated with a zone, and it stores templates, ISO images, and disk volume snapshots.
+
+ More Information
+
+ For more information, see documentation on cloud infrastructure concepts.
+
1.3.3. Networking Overview
+ CloudStack offers two types of networking scenario:
+
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+ A zone is the largest organizational unit within a CloudStack deployment. A zone typically corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter. The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required).
+
+ A zone consists of:
+
+ One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
+
+ Secondary storage, which is shared by all the pods in the zone.
+
+ Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones.
+
+ Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone.
+
+ Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels.
+
+ For each zone, the administrator must decide the following.
+
+ How many pods to place in a zone.
+
+ How many clusters to place in each pod.
+
+ How many hosts to place in each cluster.
+
+ How many primary storage servers to place in each cluster and total capacity for the storage servers.
+
+ How much secondary storage to deploy in 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.
+
2.2. About Pods
+ A pod often represents a single rack. Hosts in the same pod are in the same subnet.
+
+ A pod is the second-largest organizational unit within a CloudStack deployment. Pods are contained within zones. Each zone can contain one or more pods.
+
+ Pods are not visible to the end user.
+
+ A pod consists of one or more clusters of hosts and one or more primary storage servers.
+
2.3. About Clusters
+ A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set of KVM servers, , or a VMware cluster preconfigured in vCenter. The hosts in a cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the same shared primary storage. Virtual machine instances (VMs) can be live-migrated from one host to another within the same cluster, without interrupting service to the user.
+
+ A cluster is the third-largest organizational unit within a CloudStack deployment. Clusters are contained within pods, and pods are contained within zones. Size of the cluster is limited by the underlying hypervisor, although the CloudStack recommends less in most cases; see Best Practices.
+
+ A cluster consists of one or more hosts and one or more primary storage servers.
+
+ CloudStack allows multiple clusters in a cloud deployment.
+
+ Even when local storage is used exclusively, clusters are still required organizationally, even if there is just one host per cluster.
+
+ When VMware is used, every VMware cluster is managed by a vCenter server. Administrator must register the vCenter server with CloudStack. There may be multiple vCenter servers per zone. Each vCenter server may manage multiple VMware clusters.
+
2.4. About Hosts
+ A host is a single computer. Hosts provide the computing resources that run the guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a Linux KVM-enabled server, a Citrix XenServer server, and an ESXi server are hosts.
+
+ The host is the smallest organizational unit within a CloudStack deployment. Hosts are contained within clusters, clusters are contained within pods, and pods are contained within zones.
+
+ Hosts in a CloudStack deployment:
+
+ Provide the CPU, memory, storage, and networking resources needed to host the virtual machines
+
+ Interconnect using a high bandwidth TCP/IP network and connect to the Internet
+
+ May reside in multiple data centers across different geographic locations
+
+ May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the hosts within a cluster must all be homogeneous
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs.
+
+ CloudStack automatically detects the amount of CPU and memory resources provided by the Hosts.
+
+ Hosts are not visible to the end user. An end user cannot determine which host their guest has been assigned to.
+
+ For a host to function in CloudStack, you must do the following:
+
+ Install hypervisor software on the host
+
+ Assign an IP address to the host
+
+ Ensure the host is connected to the CloudStack Management Server
+
2.5. About Primary Storage
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required. It is typically located close to the hosts for increased performance.
+
+ CloudStack is designed to work with all standards-compliant iSCSI and NFS servers that are supported by the underlying hypervisor, including, for example:
+
+ Dell EqualLogic™ for iSCSI
+
+ Network Appliances filers for NFS and iSCSI
+
+ Scale Computing for NFS
+
+ If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.
+
2.6. About Secondary Storage
+ Secondary storage is associated with a zone, and it stores the following:
+
+ Templates — OS images that can be used to boot VMs and can include additional configuration information, such as installed applications
+
+ ISO images — disc images containing data or bootable media for operating systems
+
+ Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
+
+ The items in zone-based NFS secondary storage are available to all hosts in the zone. CloudStack manages the allocation of guest virtual disks to particular primary storage devices.
+
+ To make items in secondary storage available to all hosts throughout the cloud, you can add OpenStack Object Storage (Swift, swift.openstack.org) in addition to the zone-based NFS secondary storage. When using Swift, you configure Swift storage for the entire CloudStack, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere.
+
2.7. About Physical Networks
+ Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical networks can be associated with each zone. The network corresponds to a NIC on the hypervisor host. Each physical network can carry one or more types of network traffic. The choices of traffic type for each network vary depending on whether you are creating a zone with basic networking or advanced networking.
+
+ A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can:
+
+ Add/Remove/Update physical networks in a zone
+
+ Configure VLANs on the physical network
+
+ Configure a name so the network can be recognized by hypervisors
+
+ Configure the service providers (firewalls, load balancers, etc.) available on a physical network
+
+ Configure the IP addresses trunked to a physical network
+
+ Specify what type of traffic is carried on the physical network, as well as other properties like network speed
+
2.7.1. Configurable Characteristics of Physical Networks
+ CloudStack provides configuration settings you can use to set up a physical network in a zone, including:
+
+ What type of network traffic it carries (guest, public, management, storage)
+
+ VLANs
+
+ Unique name that the hypervisor can use to find that particular network
+
+ Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator sets the physical network to enabled, and it begins to be used. The administrator can later disable the network again, which prevents any new virtual networks from being created on that physical network; the existing network traffic continues even though the state is disabled.
+
+ Speed
+
+ Tags, so network offerings can be matched to physical networks
+
+ Isolation method
+
2.7.2. Basic Zone Network Traffic Types
+ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
Note
+ We strongly recommend the use of separate NICs for management traffic and guest traffic.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. CloudStack takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.
+
2.7.3. Basic Zone Guest IP Addresses
+ When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts.
+
2.7.4. Advanced Zone Network Traffic Types
+ When advanced networking is used, there can be multiple physical networks in the zone. Each physical network can carry one or more traffic types, and you need to let CloudStack know which type of network traffic you want each network to carry. The traffic types in an advanced zone are:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each CloudStack account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices.
+
2.7.5. Advanced Zone Guest IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.6. Advanced Zone Public IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.7. System Reserved IP Addresses
+ In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the CloudStack Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
+
+ The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone.
+
+ The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in.
+
+ Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. CloudStack can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
+
+ In all zones:
+
+ Provide private IPs for the system in each pod and provision them in CloudStack.
+
+ For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.
+
+ In a zone that uses advanced networking:
+
+ For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required CloudStack System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.
+
+ When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
+
+ To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:
+
+ Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than 4,000 IP addresses.
+
+ Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod has 255 IPs, this will provide 2,550 IP addresses.
+
+ 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
+
+ The 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.
+
3.2. Using an LDAP Server for User Authentication
+ You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate CloudStack end-users. Just map CloudStack accounts to the corresponding LDAP accounts using a query filter. The query filter is written using the query syntax of the particular LDAP server, and can include special wildcard characters provided by CloudStack for matching common values such as the user’s email address and name. CloudStack will search the external LDAP directory tree starting at a specified base directory and return the distinguished name (DN) and password of the matching user. This information along with the given password is used to authenticate the user..
+
+ To set up LDAP authentication in CloudStack, call the CloudStack API command ldapConfig and provide the following:
+
+ Hostname or IP address and listening port of the LDAP server
+
+ Base directory and query filter
+
+ Search user DN credentials, which give CloudStack permission to search on the LDAP server
+
+ SSL keystore and password, if SSL is used
+
3.2.1. Example LDAP Configuration Commands
+ To understand the examples in this section, you need to know the basic concepts behind calling the CloudStack API, which are explained in the Developer’s Guide.
+
+ The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
+
+ 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.
+
+ The next few sections explain some of the concepts you will need to know when filling out the ldapConfig parameters.
+
3.2.2. Search Base
+ An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The search base is the distinguished name (DN) of a level of the directory tree below which all users can be found. The users can be in the immediate base directory or in some subdirectory. The search base may be equivalent to the organization, group, or domain name. The syntax for writing a DN varies depending on which LDAP server you are using. A full discussion of distinguished names is outside the scope of our documentation. The following table shows some examples of search bases to find users in the testing department..
+
+
+ LDAP Server
+
+
+
+ Example Search Base DN
+
+
+
+ ApacheDS
+
+
+
+ ou=testing,o=project
+
+
+
+ Active Directory
+
+
+
+ OU=testing, DC=company
+
+
3.2.3. Query Filter
+ The query filter is used to find a mapped user in the external LDAP server. The query filter should uniquely map the CloudPlatform user to LDAP user for a meaningful authentication. For more information about query filter syntax, consult the documentation for your LDAP server.
+
+ The CloudPlatform 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 CloudPlatform user name is the same as the LDAP user ID:
+
(uid=%u)
+ If the CloudPlatform user name is the LDAP display name:
+
(displayName=%u)
+ To find a user by email address:
+
(mail=%e)
3.2.4. Search User Bind DN
+ The bind DN is the user on the external LDAP server permitted to search the LDAP directory within the defined search base. When the DN is returned, the DN and passed password are used to authenticate the CloudStack user with an LDAP bind. A full discussion of bind DNs is outside the scope of our documentation. The following table shows some examples of bind DNs.
+
+ 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.
+
+ In addition to the physical and logical infrastructure of your cloud, and the CloudStack software and servers, you also need a layer of user services so that people can actually make use of the cloud. This means not just a user UI, but a set of options and resources that users can choose from, such as templates for creating virtual machines, disk storage, and more. If you are running a commercial service, you will be keeping track of what services and resources users are consuming and charging them for that usage. Even if you do not charge anything for people to use your cloud – say, if the users are strictly internal to your organization, or just friends who are sharing your cloud – you can still keep track of what services they use and how much of them.
+
4.1. Service Offerings, Disk Offerings, Network Offerings, and Templates
+ A user creating a new instance can make a variety of choices about its characteristics and capabilities. CloudStack provides several ways to present users with choices when creating a new instance:
+
+ Service Offerings, defined by the CloudStack administrator, provide a choice of CPU speed, number of CPUs, RAM size, tags on the root disk, and other choices. See Creating a New Compute Offering.
+
+ Disk Offerings, defined by the CloudStack administrator, provide a choice of disk size for primary data storage. See Creating a New Disk Offering.
+
+ Network Offerings, defined by the CloudStack administrator, describe the feature set that is available to end users from the virtual router or external networking devices on a given guest network. See Network Offerings.
+
+ Templates, defined by the CloudStack administrator or by any CloudStack user, are the base OS images that the user can choose from when creating a new instance. For example, CloudStack includes CentOS as a template. See Working with Templates.
+
+ In addition to these choices that are provided for users, there is another type of service offering which is available only to the CloudStack root administrator, and is used for configuring virtual infrastructure resources. For more information, see Upgrading a Virtual Router with System Service Offerings.
+
+ 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)
+
http://<management-server-ip-address>:8080/client
+ On a fresh Management Server installation, a guided tour splash screen appears. On later visits, you’ll see a login screen where you specify the following to proceed to your Dashboard:
+
Username
+ The user ID of your account. The default username is admin.
+
Password
+ The password associated with the user ID. The password for the default username is password.
+
Domain
+ If you are a root user, leave this field blank.
+
+ If you are a user in the sub-domains, enter the full path to the domain, excluding the root domain.
+
+ For example, suppose multiple levels are created under the root domain, such as Comp1/hr. The users in the Comp1 domain should enter Comp1 in the Domain field, whereas the users in the Comp1/sales domain should enter Comp1/sales.
+
+ For more guidance about the choices that appear when you log in to this UI, see Logging In as the Root Administrator.
+
5.1.1. End User's UI Overview
+ The CloudStack UI helps users of cloud infrastructure to view and use their cloud resources, including virtual machines, templates and ISOs, data volumes and snapshots, guest networks, and IP addresses. If the user is a member or administrator of one or more CloudStack projects, the UI can provide a project-oriented view.
+
5.1.2. Root Administrator's UI Overview
+ The CloudStack UI helps the CloudStack administrator provision, view, and manage the cloud infrastructure, domains, user accounts, projects, and configuration settings. The first time you start the UI after a fresh Management Server installation, you can choose to follow a guided tour to provision your cloud infrastructure. On subsequent logins, the dashboard of the logged-in user appears. The various links in this screen and the navigation bar on the left provide access to a variety of administrative functions. The root administrator can also use the UI to perform all the same tasks that are present in the end-user’s UI.
+
5.1.3. Logging In as the Root Administrator
+ After the Management Server software is installed and running, you can run the CloudStack user interface. This UI is there to help you provision, view, and manage your cloud infrastructure.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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 can enter a user ID and password and proceed to your 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 CloudPlatform, 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”.
+
Warning
+ You are logging in as the root administrator. This account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. Please change the default password to a new, unique password.
+
5.1.4. Changing the Root Password
+ During installation and ongoing cloud administration, you will need to log in to the UI as the root administrator. The root administrator account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. When first installing CloudStack, be sure to change the default password to a new, unique value.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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.
+
+
+ Type the new password, and click OK.
+
5.2. Using SSH Keys for Authentication
+ In addition to the username and password authentication, CloudStack supports using SSH keys to log in to the cloud infrastructure for additional security. You can use the createSSHKeyPair API to generate the SSH keys.
+
+ Because each cloud user has their own SSH key, one cloud user cannot log in to another cloud user's instances unless they share their SSH key files. Using a single SSH key pair, you can manage multiple instances.
+
5.2.1. Creating an Instance Template that Supports SSH Keys
+ Create a instance template that supports SSH Keys.
+
+ Create a new instance by using the template provided by cloudstack.
+
+ For more information on creating a new instance, see
+
+ Download the cloudstack script from The SSH Key Gen Scriptto the instance you have created.
+
+ Run the script while starting up the operating system:
+
chkconfig --add cloud-set-guest-sshkey.in
+ Stop the instance.
+
5.2.2. Creating the SSH Keypair
+ You must make a call to the createSSHKeyPair api method. You can either use the CloudStack Python API library or the curl commands to make the call to the cloudstack api.
+
+ For example, make a call from the cloudstack server to create a SSH keypair called "keypair-doc" for the admin account in the root domain:
+
Note
+ Ensure that you adjust these values to meet your needs. If you are making the API call from a different server, your URL/PORT will be different, and you will need to use the API keys.
+
+ 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..
+
6.2. Configuring Projects
+ Before CloudPlatform users start using projects, the CloudPlatform administrator must set up various systems to support them, including membership invitations, limits on project resources, and controls on who can create projects.
+
6.2.1. 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.
+
+ In the search box, type project and click the search button.
+
+
+ In the search results, you will 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
+
service cloud-management restart
6.2.2. 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
+
6.2.2.1. 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”). 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.
+
6.2.2.2. 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.
+
+
+
+ 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.
+
# service cloud-management restart
6.2.3. 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.
+
+
+
+ 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.
+
# service cloud-management restart
6.3. 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.
+
6.4. 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.
+
6.4.1. 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”. 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”.
+
+ 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.
+
+ 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.
+
6.5. 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.
+
6.6. 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
+
+
+ To suspend, use
+
+
6.7. 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.
+
Chapter 7. Steps to Provisioning Your Cloud Infrastructure
+ This section tells how to add 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.
+
7.1. 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”.
+
+ To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
+
+ (Optional) If you are going to use Swift for cloud-wide secondary storage, you need to add it before you add zones.
+
+ Log in to the CloudStack UI as administrator.
+
+ If this is your first time visiting the UI, you will see the guided tour splash screen. Choose “Experienced user.” The Dashboard appears.
+
+ In the left navigation bar, click Global Settings.
+
+ In the search box, type swift.enable and click the search button.
+
+ Click the edit button and set swift.enable to true.
+
+
+
+ Restart the Management Server.
+
# service cloud-management restart
+ Refresh the CloudStack UI browser tab and log back in.
+
+ In the left navigation, choose Infrastructure.
+
+ On Zones, click View More.
+
+ (Optional) If you are using Swift storage, click Enable Swift. Provide the following:
+
+ URL. The Swift URL.
+
+ Account. The Swift account.
+
+ Username. The Swift account’s username.
+
+ Key. The Swift key.
+
+ 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.
+
+ For more information about the network types, see Network Setup.
+
+ The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you:
+
+ 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.
+
+ 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.
+
+ (Introduced in version 3.0.1) 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.2, “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, CloudPlatform 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.
+
7.2.2. 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.7.4, “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.
+
+ 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.2, “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.7.7, “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.3, “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.4, “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.5, “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.6, “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.
+
+ Path. The exported path from the server.
+
+ Click Launch.
+
7.3. 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.
+
+ 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.
+
7.4. 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.
+
7.4.1. 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.
+
7.4.2. 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.
+
+ 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 values from vCenter.
+
+ Cluster Name. Enter the name of the cluster you created in vCenter. For example, "cloud.cluster.2.2.1"
+
+ vCenter Host. Enter the hostname or IP address of the vCenter server.
+
+ vCenter Username. Enter the username that CloudStack should use to connect to vCenter. This user must have all administrative privileges.
+
+ 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".
+
+ There might be a slight delay while the cluster is provisioned. It will automatically display in the UI
+
7.5. 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.
+
+ 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/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+
+ Run the script:
+
# ./cloud-setup-bonding.sh
7.5.1.1.2. 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.
+
7.5.1.2. 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 delay while the host is provisioned. It should automatically display in the UI.
+
+ Repeat for additional hosts.
+
7.5.2. Adding a Host (vSphere)
+ For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the entire cluster to CloudStack. See Add Cluster: vSphere.
+
7.6. Add Primary Storage
7.6.1. System Requirements for Primary Storage
+ Hardware requirements:
+
+ Any standards-compliant iSCSI or NFS server that is supported by the underlying hypervisor.
+
+ The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller.
+
+ Minimum required capacity depends on your needs.
+
+ When setting up primary storage, follow these restrictions:
+
+ Primary storage cannot be added until a host has been added to the cluster.
+
+ If you do not provision shared primary storage, you must set the global configuration parameter system.vm.local.storage.required to true, or else you will not be able to start VMs.
+
7.6.2. Adding Primary Stroage
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+
+ Click the Compute tab.
+
+ In the Primary Storage node of the diagram, click View All.
+
+ Click Add Primary Storage.
+
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+
+ Pod. The pod for the storage device.
+
+ Cluster. The cluster for the storage device.
+
+ Name. The name of the storage device.
+
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS.
+
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device.
+
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+
+ Path (for NFS). In NFS this is the exported path from the server.
+
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside CloudStack.
+
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
+
+ Lun # (for iSCSI). In iSCSI this is 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.
+
+ Click OK.
+
7.7. Add Secondary Storage
7.7.1. System Requirements for Secondary Storage
+ NFS storage appliance or Linux NFS server
+
+ (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org)
+
+ 100GB minimum capacity
+
+ A secondary storage device must be located in the same zone as the guest VMs it serves.
+
+ Each Secondary Storage server must be available to all hosts in the zone.
+
7.7.2. Adding Secondary Storage
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to CloudStack before you add the local zone secondary storage servers. See Section 7.2, “Adding a Zone”.
+
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See Preparing NFS Shares in the Installation Guide.
+
+ Make sure you prepared the system VM template during Management Server installation. See Prepare the System VM Template in the Installation Guide.
+
+ Now that the secondary storage server for per-zone storage is prepared, add it to CloudStack. Secondary storage is added as part of the procedure for adding a new zone. See Section 7.2, “Adding a Zone”.
+
7.8. Initialize and Test
+ After everything is configured, CloudStack will perform its initialization. This can take 30 minutes or more, depending on the speed of your network. When the initialization has completed successfully, the administrator's Dashboard should be displayed in the CloudStack UI.
+
+ Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS 5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do not proceed to the next step until this status is displayed.
+
+ Go to the Instances tab, and filter by My Instances.
+
+ Click Add Instance and follow the steps in the wizard.
+
+ Choose the zone you just added.
+
+ In the template selection, choose the template to use in the VM. If this is a fresh installation, likely only the provided CentOS template is available.
+
+ Select a service offering. Be sure that the hardware you have allows starting the selected service offering.
+
+ In data disk offering, if desired, add another data disk. This is a second volume that will be available to but not mounted in the guest. For example, in Linux on XenServer you will see /dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PV-enabled OS kernel in use.
+
+ In default network, choose the primary network for the guest. In a trial installation, you would have only one option here.
+
+ Optionally give your VM a name and a group. Use any descriptive text you would like.
+
+ Click Launch VM. Your VM will be created and started. It might take some time to download the template and complete the VM startup. You can watch the VM’s progress in the Instances screen.
+
+ To use the VM, click the View Console button.
+
+
+
+ Congratulations! You have successfully completed a CloudStack Installation.
+
+ If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
+
+ In this chapter we discuss compute, disk, and system service offerings. Network offerings are discussed in the section on setting up networking for users.
+
8.1. Compute and Disk Service Offerings
+ A service offering is a set of virtual hardware features such as CPU core count and speed, memory, and disk size. The CloudStack administrator can set up various offerings, and then end users choose from the available offerings when they create a new VM. A service offering includes the following elements:
+
+ CPU, memory, and network resource guarantees
+
+ How resources are metered
+
+ How the resource usage is charged
+
+ How often the charges are generated
+
+ For example, one service offering might allow users to create a virtual machine instance that is equivalent to a 1 GHz Intel® Core™ 2 CPU, with 1 GB memory at $0.20/hour, with network traffic metered at $0.10/GB. Based on the user’s selected offering, CloudStack emits usage records that can be integrated with billing systems. CloudStack separates service offerings into compute offerings and disk offerings. The computing service offering specifies:
+
+ Guest CPU
+
+ Guest RAM
+
+ Guest Networking type (virtual or direct)
+
+ Tags on the root disk
+
+ The disk offering specifies:
+
+ Disk size (optional). An offering without a disk size will allow users to pick their own
+
+ Tags on the data disk
+
8.1.1. Creating a New Compute Offering
+ To create a new compute offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Compute Offering.
+
+ Click Add Compute Offering.
+
+ In the dialog, make the following choices:
+
+ Name: Any desired name for the service offering.
+
+ Description: A short description of the offering that can be displayed to users
+
+ Storage type: The type of disk that should be allocated. Local allocates from storage attached directly to the host where the system VM is running. Shared allocates from storage accessible via NFS.
+
+ # of CPU cores: The number of cores which should be allocated to a system VM with this offering
+
+ CPU (in MHz): The CPU speed of the cores that the system VM is allocated. For example, “2000” would provide for a 2 GHz clock.
+
+ Memory (in MB): The amount of memory in megabytes that the system VM should be allocated. For example, “2048” would provide for a 2 GB RAM allocation.
+
+ Network Rate: Allowed data transfer rate in MB per second.
+
+ Offer HA: If yes, the administrator can choose to have the system VM be monitored and as highly available as possible.
+
+ Storage Tags: The tags that should be associated with the primary storage used by the system VM.
+
+ Host Tags: (Optional) Any tags that you use to organize your hosts
+
+ CPU cap: Whether to limit the level of CPU usage even if spare capacity is available.
+
+ Public: Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.2. Creating a New Disk Offering
+ To create a system service offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Disk Offering.
+
+ Click Add Disk Offering.
+
+ In the dialog, make the following choices:
+
+ Name. Any desired name for the system offering.
+
+ Description. A short description of the offering that can be displayed to users
+
+ Custom Disk Size. If checked, the user can set their own disk size. If not checked, the root administrator must define a value in Disk Size.
+
+ Disk Size. Appears only if Custom Disk Size is not selected. Define the volume size in GB.
+
+ (Optional)Storage Tags. The tags that should be associated with the primary storage for this disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue". Tags are also added on Primary Storage. CloudStack matches tags on a disk offering to tags on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation from the disk offering will fail..
+
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.3. Modifying or Deleting a Service Offering
+ Service offerings cannot be changed once created. This applies to both compute offerings and disk offerings.
+
+ A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently. If the service offering is still in use, it will remain in the database until all the virtual machines referencing it have been deleted. After deletion by the administrator, a service offering will not be available to end users that are creating new instances.
+
8.2. System Service Offerings
+ System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the CloudStack root administrator. CloudStack provides default system service offerings. The CloudStack root administrator can create additional custom system service offerings.
+
+ When CloudStack creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering.
+
+ People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a CloudStack administrator, you can do the following things to set up networking for your users:
+
+ Set up physical networks in zones
+
+ Set up several different providers for the same service on a single physical network (for example, both Cisco and Juniper firewalls)
+
+ Bundle different types of network services into network offerings, so users can choose the desired network services for any given virtual machine
+
+ Add new network offerings as time goes on so end users can upgrade to a better class of service on their network
+
+ Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member
+
9.2. About Virtual Networks
+ A virtual network is a logical construct that enables multi-tenancy on a single physical network. In CloudStack a virtual network can be shared or isolated.
+
9.2.1. Isolated Networks
+ An isolated network can be accessed only by virtual machines of a single account. Isolated networks have the following properties.
+
+ Resources such as VLAN are allocated and garbage collected dynamically
+
+ There is one network offering for the entire network
+
+ The network offering can be upgraded or downgraded but it is for the entire network
+
9.2.2. Shared Networks
+ A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in CloudStack 3.0.3).
+
+ Shared Networks are created by the administrator
+
+ Shared Networks can be designated to a certain domain
+
+ Shared Network resources such as VLAN and physical network that it maps to are designated by the administrator
+
+ Shared Networks are isolated by security groups
+
+ Public Network is a shared network that is not shown to the end users
+
9.2.3. Runtime Allocation of Virtual Network Resources
+ When you define a new virtual network, all your settings for that network are stored in CloudStack. The actual network resources are activated only when the first virtual machine starts in the network. When all virtual machines have left the virtual network, the network resources are garbage collected so they can be allocated again. This helps to conserve network resources..
+
9.3. Network Service Providers
Note
+ For the most up-to-date list of supported network service providers, see the CloudPlatform UI or call listNetworkServiceProviders.
+
+ A service provider (also called a network element) is hardware or virtual appliance that makes a network service possible; for example, a firewall appliance can be installed in the cloud to provide firewall service. On a single network, multiple providers can provide the same network service. For example, a firewall service may be provided by Cisco or Juniper devices in the same physical network.
+
+ You can have multiple instances of the same service provider in a network (say, more than one Juniper SRX device).
+
+ If different providers are set up to provide the same service on the network, the administrator can create network offerings so users can specify which network service provider they prefer (along with the other choices offered in network offerings). Otherwise, CloudPlatform will choose which provider to use whenever the service is called for.
+
Supported Network Service Providers
+ CloudPlatform ships with an internal list of the supported service providers, and you can choose from this list when creating a network offering.
+
9.4. Network Offerings
Note
+ For the most up-to-date list of supported network services, see the CloudPlatform UI or call listNetworkServices.
+
+ A network offering is a named set of network services, such as:
+
+ DHCP
+
+ DNS
+
+ Source NAT
+
+ Static NAT
+
+ Port Forwarding
+
+ Load Balancing
+
+ Firewall
+
+ VPN
+
+ Optional) Name one of several available providers to use for a given service, such as Juniper for the firewall
+
+ (Optional) Network tag to specify which physical network to use
+
+ When creating a new VM, the user chooses one of the available network offerings, and that determines which network services the VM can use.
+
+ The CloudPlatform administrator can create any number of custom network offerings, in addition to the default network offerings provided by CloudPlatform. By creating multiple custom network offerings, you can set up your cloud to offer different classes of service on a single multi-tenant physical network. For example, while the underlying physical wiring may be the same for two tenants, tenant A may only need simple firewall protection for their website, while tenant B may be running a web server farm and require a scalable firewall solution, load balancing solution, and alternate networks for accessing the database backend.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudPlatform virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+ When creating a new virtual network, the CloudPlatform administrator chooses which network offering to enable for that network. Each virtual network is associated with one network offering. A virtual network can be upgraded or downgraded by changing its associated network offering. If you do this, be sure to reprogram the physical network to match.
+
+ CloudPlatform also has internal network offerings for use by CloudPlatform system VMs. These network offerings are not visible to users but can be modified by administrators.
+
+ CloudStack provides administrators with complete control over the lifecycle of all guest VMs executing in the cloud. CloudStack provides several guest management operations for end users and administrators. VMs may be stopped, started, rebooted, and destroyed.
+
+ Guest VMs have a name and group. VM names and groups are opaque to CloudStack and are available for end users to organize their VMs. Each VM can have three names for use in different contexts. Only two of these names can be controlled by the user:
+
+ Instance name – a unique, immutable ID that is generated by CloudStack and can not be modified by the user. This name conforms to the requirements in IETF RFC 1123.
+
+ Display name – the name displayed in the CloudStack web UI. Can be set by the user. Defaults to instance name.
+
+ Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to instance name
+
+ Guest VMs can be configured to be Highly Available (HA). An HA-enabled VM is monitored by the system. If the system detects that the VM is down, it will attempt to restart the VM, possibly on a different host. For more information, see HA-Enabled Virtual Machines on
+
+ Each new VM is allocated one public IP address. When the VM is started, CloudStack automatically creates a static NAT between this public IP address and the private IP address of the VM.
+
+ If elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new VM is not marked as elastic. The user must replace the automatically configured IP with a specifically acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s private IP. The VM’s original IP address is then released and returned to the pool of available public IPs.
+
+ CloudStack cannot distinguish a guest VM that was shut down by the user (such as with the “shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut down from inside the VM, CloudStack will restart it. To shut down an HA-enabled VM, you must go through the CloudStack UI or API.
+
10.2. Best Practices for Virtual Machines
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
10.3. VM Lifecycle
+ Virtual machines can be in the following states:
+
+ Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual machine will be reclaimed by the system. This includes the virtual machine’s IP address.
+
+ A stop will attempt to gracefully shut down the operating system, which typically involves terminating all the running applications. If the operation system cannot be stopped, it will be forcefully terminated. This has the same effect as pulling the power cord to a physical machine.
+
+ A reboot is a stop followed by a start.
+
+ CloudPlatform preserves the state of the virtual machine hard disk until the machine is destroyed.
+
+ A running virtual machine may fail because of hardware or network issues. A failed virtual machine is in the down state.
+
+ The system places the virtual machine into the down state if it does not receive the heartbeat from the hypervisor for three minutes.
+
+ The user can manually restart the virtual machine from the down state.
+
+ The system will start the virtual machine from the down state automatically if the virtual machine is marked as HA-enabled.
+
10.4. Creating VMs
+ Virtual machines are usually created from a template. Users can also create blank virtual machines. A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and install the OS from the CD/DVD-ROM.
+
+ To create a VM from a template:
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select a template, then follow the steps in the wizard. (For more information about how the templates came to be in this list, see Working with Templates.
+
+ Be sure that the hardware you have allows starting the selected service offering.
+
+ Click Submit and your VM will be created and started.
+
Note
+ For security reason, the internal name of the VM is visible only to the root admin.
+
Note
+ Starting with v3.0.3, you can create a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A new request parameter, startVM, is introduced in the deployVm API to support this feature. For more information, see the Developer's Guide
+
+ To create a VM from an ISO:
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select ISO Boot, and follow the steps in the wizard.
+
+ Click Submit and your VM will be created and started.
+
10.5. Accessing VMs
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
+ To access a VM through the CloudStack UI:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ Click Instances, then click the name of a running VM.
+
+ Click the View Console button .
+
+ To access a VM directly over the network:
+
+ The VM must have some port open to incoming traffic. For example, in a basic zone, a new VM might be assigned to a security group which allows incoming traffic. This depends on what security group you picked when creating the VM. In other cases, you can open a port by setting up a port forwarding policy. See IP Forwarding and Firewalling.
+
+ If a port is open but you can not access the VM using ssh, it’s possible that ssh is not already enabled on the VM. This will depend on whether ssh is enabled in the template you picked when creating the VM. Access the VM through the CloudStack UI and enable ssh on the machine using the commands for the VM’s operating system.
+
+ If the network has an external firewall device, you will need to create a firewall rule to allow access. See IP Forwarding and Firewalling.
+
10.6. Stopping and Starting VMs
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
10.7. Changing the VM Name, OS, or Group
+ After a VM is created, you can modify the display name, operating system, and the group it belongs to.
+
+ To access a VM through the CloudStack UI:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Select the VM that you want to modify.
+
+ Click the Stop button to stop the VM
+
+
+
+ Click Edit
+
+ .
+
+ Make the desired changes to the following:
+
+ Display name: Enter a new display name if you want to change the name of the VM.
+
+ OS Type: Select the desired operating system.
+
+ Group: Enter the group name for the VM.
+
+ Click Apply.
+
10.8. Changing the Service Offering for a VM
+ To upgrade or downgrade the level of compute resources available to a virtual machine, you can change the VM's compute offering.
+
+ Log in to the CloudStack UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to work with.
+
+ Click the Stop button to stop the VM
+
+
+
+ Click the Change Service button
+
+ . The Change service dialog box is displayed.
+
+ Select the offering you want.
+
+ Click OK.
+
10.9. Moving VMs Between Hosts (Manual Live Migration)
+ The CloudPlatform administrator can move a running VM from one host to another without interrupting service to users or going into maintenance mode. This is called manual live migration, and can be done under the following conditions:
+
+ The root administrator is logged in. Domain admins and users can not perform manual live migration of VMs.
+
+ The VM is running. Stopped VMs can not be live migrated.
+
+ The destination host must be in the same cluster as the original host.
+
+ The VM must not be using local disk storage.
+
+ The destination host must have enough available capacity. If not, the VM will remain in the "migrating" state until memory becomes available.
+
+ To manually live migrate a virtual machine
+
+ Log in to the CloudPlatform UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to migrate.
+
+ Click the Migrate Instance button
+
+
+
+ From the list of hosts, choose the one to which you want to move the VM.
+
+ Click OK.
+
10.10. Deleting VMs
+ Users can delete their own virtual machines. A running virtual machine will be abruptly stopped before it is deleted. Administrators can delete any virtual machines.
+
+ To delete a virtual machine:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to delete.
+
+ Click the Destroy Instance button
+
+
+
10.11. Working with ISOs
+ CloudStack supports ISOs and their attachment to guest VMs. An ISO is a read-only file that has an ISO/CD-ROM style file system. Users can upload their own ISOs and mount them on their guest VMs.
+
+ ISOs are uploaded based on a URL. HTTP is the supported protocol. Once the ISO is available via HTTP specify an upload URL such as http://my.web.server/filename.iso.
+
+ ISOs may be public or private, like templates.ISOs are not hypervisor-specific. That is, a guest on vSphere can mount the exact same image that a guest on KVM can mount.
+
+ ISO images may be stored in the system and made available with a privacy level similar to templates. ISO images are classified as either bootable or not bootable. A bootable ISO image is one that contains an OS image. CloudStack allows a user to boot a guest VM off of an ISO image. Users can also attach ISO images to guest VMs. For example, this enables installing PV drivers into Windows. ISO images are not hypervisor-specific.
+
10.11.1. Adding an ISO
+ To make additional operating system or other software available for use with guest VMs, you can add an ISO. The ISO is typically thought of as an operating system image, but you can also add ISOs for other types of software, such as desktop applications that you want to be installed as part of a template.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation bar, click Templates.
+
+ In Select View, choose ISOs.
+
+ Click Add ISO.
+
+ In the Add ISO screen, provide the following:
+
+ Name: Short name for the ISO image. For example, CentOS 6.2 64-bit.
+
+ Description: Display test for the ISO image. For example, CentOS 6.2 64-bit.
+
+ URL: The URL that hosts the ISO image. The Management Server must be able to access this location via HTTP. If needed you can place the ISO image directly on the Management Server
+
+ Zone: Choose the zone where you want the ISO to be available, or All Zones to make it available throughout CloudStack.
+
+ Bootable: Whether or not a guest could boot off this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not bootable.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of your desired ISO image is listed, choose it.
+
+ If the OS Type of the ISO is not listed or if the ISO is not bootable, choose Other.
+
+ (XenServer only) If you want to boot from this ISO in PV mode, choose Other PV (32-bit) or Other PV (64-bit)
+
+ (KVM only) If you choose an OS that is PV-enabled, the VMs created from this ISO will have a SCSI (virtio) root disk. If the OS is not PV-enabled, the VMs will have an IDE root disk. The PV-enabled types are:
+
+
+ Fedora 13
+
+
+
+ Fedora 12
+
+
+
+ Fedora 11
+
+
+
+ Fedora 10
+
+
+
+ Fedora 9
+
+
+
+ Other PV
+
+
+
+ Debian GNU/Linux
+
+
+
+ CentOS 5.3
+
+
+
+ CentOS 5.4
+
+
+
+ CentOS 5.5
+
+
+
+ Red Hat Enterprise Linux 5.3
+
+
+
+ Red Hat Enterprise Linux 5.4
+
+
+
+ Red Hat Enterprise Linux 5.5
+
+
+
+ Red Hat Enterprise Linux 6
+
+
+
Note
+ It is not recommended to choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not work. In these cases, choose Other.
+
+ Extractable: Choose Yes if the ISO should be available for extraction.
+
+ Public: Choose Yes if this ISO should be available to other users.
+
+ Featured: Choose Yes if you would like this ISO to be more prominent for users to select. The ISO will appear in the Featured ISOs list. Only an administrator can make an ISO Featured.
+
+ Click OK.
+
+ The Management Server will download the ISO. Depending on the size of the ISO, this may take a long time. The ISO status column will display Ready once it has been successfully downloaded into secondary storage. Clicking Refresh updates the download percentage.
+
+ Important: Wait for the ISO to finish downloading. If you move on to the next task and try to use the ISO right away, it will appear to fail. The entire ISO must be available before CloudStack can work with it.
+
10.11.2. Attaching an ISO to a VM
+ In the left navigation, click Instances.
+
+ Choose the virtual machine you want to work with.
+
+ Click the Attach ISO button
+
+
+ In the Attach ISO dialog box, select the desired ISO.
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs. For requirements and instructions, see Section 7.5, “Adding a Host”.
+
11.2. 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.
+
11.3. 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.
+
+
+
+ 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.
+
+
11.4. Removing Hosts
+ Hosts can be removed from the cloud as needed. The procedure to remove a host depends on the hypervisor type.
+
11.4.1. 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:
+
+ Then you may power down the Host, re-use its IP address, re-install it, etc
+
11.4.2. 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”. 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.
+
11.5. 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.
+
11.6. 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.
+
+ 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:
+
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".
+
mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;
11.8. Host Allocation
+ The system automatically picks the most appropriate host to run each virtual machine. End users may specify the zone in which the virtual machine will be created. End users do not have control over which host will run the virtual machine instance.
+
+ CloudStack administrators can specify that certain hosts should have a preference for particular types of guest instances. For example, an administrator could state that a host should have a preference to run Windows guests. The default host allocator will attempt to place guests of that OS type on such hosts first. If no such host is available, the allocator will place the instance wherever there is sufficient physical capacity.
+
+ Both vertical and horizontal allocation is allowed. Vertical allocation consumes all the resources of a given host before allocating any guests on a second host. This reduces power consumption in the cloud. Horizontal allocation places a guest on each host in a round-robin fashion. This may yield better performance to the guests in some cases. CloudStack also allows an element of CPU over-provisioning as configured by the administrator. Over-provisioning allows the administrator to commit more CPU cycles to the allocated guests than are actually available from the hardware.
+
+ CloudStack also provides a pluggable interface for adding new allocators. These custom allocators can provide any policy the administrator desires.
+
11.9. 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.
+
+ A template is a reusable configuration for virtual machines. When users launch VMs, they can choose from a list of templates in CloudStack.
+
+ Specifically, a template is a virtual disk image that includes one of a variety of operating systems, optional additional software such as office applications, and settings such as access control to determine who can use the template. Each template is associated with a particular type of hypervisor, which is specified when the template is added to CloudStack.
+
+ CloudStack ships with a default template. In order to present more choices to users, CloudStack administrators and users can create templates and add them to CloudStack.
+
12.1. Creating Templates: Overview
+ CloudStack ships with a default template for the CentOS operating system. There are a variety of ways to add more templates. Administrators and end users can add templates. The typical sequence of events is:
+
+ Launch a VM instance that has the operating system you want. Make any other desired configuration changes to the VM.
+
+ Stop the VM.
+
+ Convert the volume into a template.
+
+ There are other ways to add templates to CloudStack. For example, you can take a snapshot of the VM's volume and create a template from the snapshot, or import a VHD from another system into CloudStack
+
+ The various techniques for creating templates are described in the next few sections.
+
12.2. Requirements for Templates
+ For XenServer, install PV drivers / Xen tools on each template that you create. This will enable live migration and clean guest shutdown.
+
+ For vSphere, install VMware Tools on each template that you create. This will enable console view to work properly.
+
12.3. Best Practices for Templates
+ If you plan to use large templates (100 GB or larger), be sure you have a 10-gigabit network to support the large templates. A slower network can lead to timeouts and other errors when large templates are used.
+
12.4. The Default Template
+ CloudStack includes a CentOS template. This template is downloaded by the Secondary Storage VM after the primary and secondary storage are configured. You can use this template in your production deployment or you can delete it and use custom templates.
+
+ The root password for the default template is "password".
+
+ A default template is provided for each of XenServer, KVM, and vSphere. The templates that are downloaded depend on the hypervisor type that is available in your cloud. Each template is approximately 2.5 GB physical size.
+
+ The default template includes the standard iptables rules, which will block most access to the template excluding ssh.
+
+ When a user creates a template, it can be designated private or public.
+
+ Private templates are only available to the user who created them. By default, an uploaded template is private.
+
+ When a user marks a template as “public,” the template becomes available to all users in all accounts in the user's domain, as well as users in any other domains that have access to the Zone where the template is stored. This depends on whether the Zone, in turn, was defined as private or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any domain. If a public template is created in a private Zone, it is available only to users in the domain assigned to that Zone. If a public template is created in a public Zone, it is available to all users in all domains.
+
12.6. Creating a Template from an Existing Virtual Machine
+ Once you have at least one VM set up in the way you want, you can use it as the prototype for other VMs.
+
+ Make any desired configuration changes on the running VM, then click Stop.
+
+ Wait for the VM to stop. When the status shows Stopped, go to the next step.
+
+ Click Create Template and provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ OS Type. This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
+ If you want to boot from this template in PV mode, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServere:
+
Note
+ Note: Generally you should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates.
+
+ Click Add.
+
+ The new template will be visible in the Templates section when the template creation process has been completed. The template is then available when creating a new VM
+
+ If you are uploading a template that was created using vSphere Client, be sure the OVA file does not contain an ISO. If it does, the deployment of VMs from the template will fail.
+
+ Templates are uploaded based on a URL. HTTP is the supported access protocol. Templates are frequently large files. You can optionally gzip them to decrease upload times.
+
+ To upload a template:
+
+ In the left navigation bar, click Templates.
+
+ Click Create Template.
+
+ Provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ URL. The Management Server will download the file from the specified URL, such as http://my.web.server/filename.vhd.gz.
+
+ Zone. Choose the zone where you want the template to be available, or All Zones to make it available throughout CloudStack.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following:
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
Note
+ You should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Hypervisor
+
+ Format. The format of the template upload file, such as VHD or OVA.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates
+
+ Extractable. Choose Yes if the template is available for extraction. If this option is selected, end users can download a full image of a template.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”
+
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. The template will appear in the Featured Templates list. Only an administrator can make a template Featured.
+
12.9. Exporting Templates
+ End users and Administrators may export templates from the CloudStack. Navigate to the template in the UI and choose the Download function from the Actions menu.
+
12.10. Creating a Windows Template
+ Windows templates must be prepared with Sysprep before they can be provisioned on multiple machines. Sysprep allows you to create a generic Windows template and avoid any possible SID conflicts.
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Follow the steps in Sysprep for Windows Server 2008 R2 (below) or Sysprep for Windows Server 2003 R2, depending on your version of Windows Server
+
+ The preparation steps are complete. Now you can actually create the template as described in Creating the Windows Template.
+
12.10.1. System Preparation for Windows Server 2008 R2
+ For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location:
+
+ Windows AIK should not be installed on the Windows 2008 R2 VM you just created. Windows AIK should not be part of the template you create. It is only used to create the sysprep answer file.
+
+ Copy the install.wim file in the \sources directory of the Windows 2008 R2 installation DVD to the hard disk. This is a very large file and may take a long time to copy. Windows AIK requires the WIM file to be writable.
+
+ Start the Windows System Image Manager, which is part of the Windows AIK.
+
+ In the Windows Image pane, right click “Select a Windows image or catalog file” to load the install.wim file you just copied.
+
+ Select the Windows 2008 R2 Edition
+
+ You may be prompted with a warning that the catalog file cannot be opened. Click Yes to create a new catalog file.
+
+ In the Answer File pane, right click to create a new answer file.
+
+ Generate the answer file from the Windows System Image Manager using the following steps:
+
+ The first page you need to automate is the Language and Country or Region Selection page. To automate this, expand Components in your Windows Image pane, right-click and add the Microsoft-Windows-International-Core setting to Pass 7 oobeSystem. In your Answer File pane, configure the InputLocale, SystemLocale, UILanguage, and UserLocale with the appropriate settings for your language and country or region. Should you have a question about any of these settings, you can right-click on the specific setting and select Help. This will open the appropriate CHM help file with more information, including examples on the setting you are attempting to configure.
+
+ You need to automate the Software License Terms Selection page, otherwise known as the End-User License Agreement (EULA). To do this, expand the Microsoft-Windows-Shell-Setup component. High-light the OOBE setting, and add the setting to the Pass 7 oobeSystem. In Settings, set HideEULAPage true.
+
+ Make sure the license key is properly set. If you use MAK key, you can just enter the MAK key on the Windows 2008 R2 VM. You need not input the MAK into the Windows System Image Manager. If you use KMS host for activation you need not enter the Product Key. Details of Windows Volume Activation can be found at http://technet.microsoft.com/en-us/library/bb892849.aspx
+
+ You need to automate is the Change Administrator Password page. Expand the Microsoft-Windows-Shell-Setup component (if it is not still expanded), expand UserAccounts, right-click on AdministratorPassword, and add the setting to the Pass 7 oobeSystem configuration pass of your answer file. Under Settings, specify a password next to Value.
+
+ You may read the AIK documentation and set many more options that suit your deployment. The steps above are the minimum needed to make Windows unattended setup work.
+
+ Save the answer file as unattend.xml. You can ignore the warning messages that appear in the validation window.
+
+ Copy the unattend.xml file into the c:\windows\system32\sysprep directory of the Windows 2008 R2 Virtual Machine
+
+ Once you place the unattend.xml file in c:\windows\system32\sysprep directory, you run the sysprep tool as follows:
+
cd c:\Windows\System32\sysprep
+sysprep.exe /oobe /generalize /shutdown
+
+ The Windows 2008 R2 VM will automatically shut down after sysprep is complete.
+
12.10.2. Sysprep for Windows Server 2003 R2
+ Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2.
+
+ Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM.
+
+ Run c:\sysprep\setupmgr.exe to create the sysprep.inf file.
+
+ Select Create New to create a new Answer File.
+
+ Enter “Sysprep setup” for the Type of Setup.
+
+ Select the appropriate OS version and edition.
+
+ On the License Agreement screen, select “Yes fully automate the installation”.
+
+ Provide your name and organization.
+
+ Leave display settings at default.
+
+ Set the appropriate time zone.
+
+ Provide your product key.
+
+ Select an appropriate license mode for your deployment
+
+ Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up.
+
+ Leave Network Components at “Typical Settings”.
+
+ Select the “WORKGROUP” option.
+
+ Leave Telephony options at default.
+
+ Select appropriate Regional Settings.
+
+ Select appropriate language settings.
+
+ Do not install printers.
+
+ Do not specify “Run Once commands”.
+
+ You need not specify an identification string.
+
+ Save the Answer File as c:\sysprep\sysprep.inf.
+
+ Run the following command to sysprep the image:
+
c:\sysprep\sysprep.exe -reseal -mini -activated
+ After this step the machine will automatically shut down
+
12.11. Importing Amazon Machine Images
+ The following procedures describe how to import an Amazon Machine Image (AMI) into CloudStack when using the XenServer hypervisor.
+
+ Assume you have an AMI file and this file is called CentOS_6.2_x64. Assume further that you are working on a CentOS host. If the AMI is a Fedora image, you need to be working on a Fedora host initially.
+
+ You need to have a XenServer host with a file-based storage repository (either a local ext3 SR or an NFS SR) to convert to a VHD once the image file has been customized on the Centos/Fedora host.
+
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.
+
+ Determine the name of the PV kernel that has been installed into the image.
+
# cd /mnt/loop/centos62
+# ls lib/modules/
+2.6.16.33-xenU 2.6.16-xenU 2.6.18-164.15.1.el5xen 2.6.18-164.6.1.el5.centos.plus 2.6.18-xenU-ec2-v1.0 2.6.21.7-2.fc8xen 2.6.31-302-ec2
+# ls boot/initrd*
+boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
+# ls boot/vmlinuz*
+boot/vmlinuz-2.6.18-164.15.1.el5xen boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus boot/vmlinuz-2.6.18-xenU-ec2-v1.0 boot/vmlinuz-2.6.21-2952.fc8xen
+
+ Xen kernels/ramdisk always end with "xen". For the kernel version you choose, there has to be an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.
+
+ Based on your findings, create an entry in the grub.conf file. Below is an example entry.
+
+ Enable login via the console. The default console device in a XenServer system is xvc0. Ensure that etc/inittab and etc/securetty have the following lines respectively:
+
+ Copy the image file to your XenServer host's file-based storage repository. In the example below, the Xenserver is "xenhost". This XenServer has an NFS repository whose uuid is a9c5b8c8-536b-a193-a6dc-51af3e5ff799.
+
+ To convert a Hyper-V VM to a XenServer-compatible CloudStack template, you will need a standalone XenServer host with an attached NFS VHD SR. Use whatever XenServer version you are using with CloudStack, but use XenCenter 5.6 FP1 or SP2 (it is backwards compatible to 5.6). Additionally, it may help to have an attached NFS ISO SR.
+
+ For Linux VMs, you may need to do some preparation in Hyper-V before trying to get the VM to work in XenServer. Clone the VM and work on the clone if you still want to use the VM in Hyper-V. Uninstall Hyper-V Integration Components and check for any references to device names in /etc/fstab:
+
+ From the linux_ic/drivers/dist directory, run make uninstall (where "linux_ic" is the path to the copied Hyper-V Integration Components files).
+
+ Restore the original initrd from backup in /boot/ (the backup is named *.backup0).
+
+ Remove the "hdX=noprobe" entries from /boot/grub/menu.lst.
+
+ Check /etc/fstab for any partitions mounted by device name. Change those entries (if any) to mount by LABEL or UUID (get that information with the "blkid" command)..
+
+ The next step is make sure the VM is not running in Hyper-V, then get the VHD into XenServer. There are two options for doing this.
+
+ Option one:
+
+ Import the VHD using XenCenter. In XenCenter, go to Tools>Virtual Appliance Tools>Disk Image Import.
+
+ Choose the VHD, then click Next.
+
+ Name the VM, choose the NFS VHD SR under Storage, enable "Run Operating System Fixups" and choose the NFS ISO SR.
+
+ Click Next, then Finish. A VM should be created.
+
+ Option two
+
+ Run XenConvert, under From choose VHD, under To choose XenServer. Click Next.
+
+ Choose the VHD, then click Next.
+
+ Input the XenServer host info, then click Next.
+
+ Name the VM, then click Next, then Convert. A VM should be created
+
+ Once you have a VM created from the Hyper-V VHD, prepare it using the following steps:
+
+ Boot the VM, uninstall Hyper-V Integration Services, and reboot.
+
+ Either option above will create a VM in HVM mode. This is fine for Windows VMs, but Linux VMs may not perform optimally. Converting a Linux VM to PV mode will require additional steps and will vary by distribution.
+
+ Shut down the VM and copy the VHD from the NFS storage to a web server; for example, mount the NFS share on the web server and copy it, or from the XenServer host use sftp or scp to upload it to the web server.
+
+ In CloudStack, create a new template using the following values:
+
+ URL. Give the URL for the VHD
+
+ OS Type. Use the appropriate OS. For PV mode on CentOS, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServer.
+
+ Hypervisor. XenServer
+
+ Format. VHD
+
+ The template will be created, and you can create instances from it.
+
12.13. Adding Password Management to Your Templates
+ CloudStack provides an optional password reset feature that allows users to set a temporary admin or root password as well as reset the existing admin or root password from the CloudStack UI.
+
+ To enable the Reset Password feature, you will need to download an additional script to patch your template. When you later upload the template into CloudStack, you can specify whether reset admin/root password feature should be enabled for this template.
+
+ The password management feature works always resets the account password on instance boot. The script does an HTTP call to the virtual router to retrieve the account password that should be set. As long as the virtual router is accessible the guest will have access to the account password that should be used. When the user requests a password reset the management server generates and sends a new password to the virtual router for the account. Thus an instance reboot is necessary to effect any password changes.
+
+ If the script is unable to contact the virtual router during instance boot it will not set the password but boot will continue normally.
+
12.13.1. Linux OS Installation
+ Use the following steps to begin the Linux OS installation:
+
+ Download the script file cloud-set-guest-password:
+
+ On some Linux distributions, copy the file to /etc/rc.d/init.d.
+
+ Run the following command to make the script executable:
+
chmod +x /etc/init.d/cloud-set-guest-password
+ Depending on the Linux distribution, continue with the appropriate step.
+
+ On Fedora, CentOS/RHEL, and Debian, run:
+
chkconfig --add cloud-set-guest-password
12.13.2. Windows OS Installation
+ Download the installer, CloudInstanceManager.msi, from Download page and run the installer in the newly created Windows VM.
+
12.14. Deleting Templates
+ Templates may be deleted. In general, when a template spans multiple Zones, only the copy that is selected for deletion will be deleted; the same template in other Zones will not be deleted. The provided CentOS template is an exception to this. If the provided CentOS template is deleted, it will be deleted from all Zones.
+
+ When templates are deleted, the VMs instantiated from them will continue to run. However, new VMs cannot be created based on the deleted template.
+
+ CloudStack defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS.
+
+ There is no ephemeral storage in CloudStack. All volumes on all nodes are persistent.
+
13.2. Primary Storage
+ This section gives concepts and technical details about CloudPlatform primary storage. For information about how to install and configure primary storage through the CloudPlatform UI, see the Advanced Installation Guide.
+
13.3. Secondary Storage
+ This section gives concepts and technical details about CloudStack secondary storage. For information about how to install and configure secondary storage through the CloudStack UI, see the Advanced Installation Guide.
+
13.4. Using Swift for Secondary Storage
+ A volume provides storage to a guest VM. The volume can provide for a root disk or an additional data disk. CloudStack supports additional volumes for guest VMs.
+
+ Volumes are created for a specific hypervisor type. A volume that has been attached to guest using one hypervisor type (e.g, XenServer) may not be attached to a guest that is using another hypervisor type (e.g. vSphere, KVM). This is because the different hypervisors use different disk image formats.
+
+ CloudStack defines a volume as a unit of storage available to a guest VM. Volumes are either root disks or data disks. The root disk has "/" in the file system and is usually the boot device. Data disks provide for additional storage (e.g. As "/opt" or "D:"). Every guest VM has a root disk, and VMs can also optionally have a data disk. End users can mount multiple data disks to guest VMs. Users choose data disks from the disk offerings created by administrators. The user can create a template from a volume as well; this is the standard procedure for private template creation. Volumes are hypervisor-specific: a volume from one hypervisor type may not be used on a guest of another hypervisor type.
+
13.5. Working with Snapshots
+ (Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)
+
+ CloudStack supports snapshots of disk volumes. Snapshots are a point-in-time capture of virtual machine disks. Memory and CPU states are not captured.
+
+ Snapshots may be taken for volumes, including both root and data disks. The administrator places a limit on the number of stored snapshots per user. Users can create new volumes from the snapshot for recovery of particular files and they can create templates from snapshots to boot from a restored disk.
+
+ Users can create snapshots manually or by setting up automatic recurring snapshot policies. Users can also create disk volumes from snapshots, which may be attached to a VM like any other disk volume. Snapshots of both root disks and data disks are supported. However, CloudStack does not currently support booting a VM from a recovered root disk. A disk recovered from snapshot of a root disk is treated as a regular data disk; the data on recovered disk can be accessed by attaching the disk to a VM.
+
+ A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot.
+
+ The Usage Server is an optional, separately-installed part of CloudStack that provides aggregated usage records which you can use to create billing integration for CloudStack. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances.
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day.
+
14.1. Configuring the Usage Server
+ To configure the usage server:
+
+ Be sure the Usage Server has been installed. This requires extra steps beyond just installing the CloudStack software. See Installing the Usage Server (Optional) in the Advanced Installation Guide.
+
+ Log in to the CloudStack UI as administrator.
+
+ Click Global Settings.
+
+ In Search, type usage. Find the configuration parameter that controls the behavior you want to set. See the table below for a description of the available parameters.
+
+ In Actions, click the Edit icon.
+
+ Type the desired value and click the Save icon.
+
+ Restart the Management Server (as usual with any global configuration change) and also the Usage Server:
+
# service cloud-management restart
+# service cloud-usage restart
+
+ The following table shows the global configuration settings that control the behavior of the Usage Server.
+
+
+ Parameter Name
+
+
+
+ Description
+
+
+
+ enable.usage.server
+
+
+
+ Whether the Usage Server is active.
+
+
+
+ usage.aggregation.timezone
+
+
+
+ Time zone of usage records. Set this if the usage records and daily job execution are in different time zones. For example, with the following settings, the usage job will run at PST 00:15 and generate usage records for the 24 hours from 00:00:00 GMT to 23:59:59 GMT:
+
+ The time zone of usage.stats.job.exec.time. Valid values for the time zone are specified in Appendix A, Time Zones
+
+
+ Default: The time zone of the management server.
+
+
+
+
+ usage.sanity.check.interval
+
+
+
+ The number of days between sanity checks. Set this in order to periodically search for records with erroneous data before issuing customer invoices. For example, this checks for VM usage records created after the VM was destroyed, and similar checks for templates, volumes, and so on. It also checks for usage times longer than the aggregation range. If any issue is found, the alert ALERT_TYPE_USAGE_SANITY_RESULT = 21 is sent.
+
+
+
+ usage.stats.job.aggregation.range
+
+
+
+ The time period in minutes between Usage Server processing jobs. For example, if you set it to 1440, the Usage Server will run once per day. If you set it to 600, it will run every ten hours. In general, when a Usage Server job runs, it processes all events generated since usage was last run.
+
+
+ There is special handling for the case of 1440 (once per day). In this case the Usage Server does not necessarily process all records since Usage was last run. CloudStack assumes that you require processing once per day for the previous, complete day’s records. For example, if the current day is October 7, then it is assumed you would like to process records for October 6, from midnight to midnight. CloudStack assumes this "midnight to midnight" is relative to the usage.execution.timezone.
+
+
+ Default: 1440
+
+
+
+
+ usage.stats.job.exec.time
+
+
+
+ The time when the Usage Server processing will start. It is specified in 24-hour format (HH:MM) in the time zone of the server, which should be GMT. For example, to start the Usage job at 10:30 GMT, enter "10:30".
+
+
+ If usage.stats.job.aggregation.range is also set, and its value is not 1440, then its value will be added to usage.stats.job.exec.time to get the time to run the Usage Server job again. This is repeated until 24 hours have elapsed, and the next day's processing begins again at usage.stats.job.exec.time.
+
+
+ Default: 00:15.
+
+
+
+ For example, suppose that your server is in GMT, your user population is predominantly in the East Coast of the United States, and you would like to process usage records every night at 2 AM local (EST) time. Choose these settings:
+
+ enable.usage.server = true
+
+ usage.execution.timezone = America/New_York
+
+ usage.stats.job.exec.time = 07:00. This will run the Usage job at 2:00 AM EST. Note that this will shift by an hour as the East Coast of the U.S. enters and exits Daylight Savings Time.
+
+ usage.stats.job.aggregation.range = 1440
+
+ With this configuration, the Usage job will run every night at 2 AM EST and will process records for the previous day’s midnight-midnight as defined by the EST (America/New_York) time zone.
+
Note
+ Because the special value 1440 has been used for usage.stats.job.aggregation.range, the Usage Server will ignore the data between midnight and 2 AM. That data will be included in the next day's run
+
14.2. Setting Usage Limits
+ CloudStack provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis.
+
+ Aggregate limits may be set on a per-domain basis. For example, you may limit a domain and all subdomains to the creation of 100 VMs.
+
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+
+ The following table lists limits set in the Global Configuration:
+
+
+ Parameter Name
+
+
+
+ Definition
+
+
+
+ max.account.public.ips
+
+
+
+ Number of public IP addresses that can be owned by an account
+
+
+
+ max.account.snapshots
+
+
+
+ Number of snapshots that can exist for an account
+
+
+
+ max.account.templates
+
+
+
+ Number of templates that can exist for an account
+
+
+
+ max.account.user.vms
+
+
+
+ Number of virtual machine instances that can exist for an account
+
+
+
+ max.account.volumes
+
+
+
+ Number of disk volumes that can exist for an account
+
+
+
+ max.template.iso.size
+
+
+
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+ max.volume.size.gb
+
+
+
+ Maximum size for a volume in GB
+
+
+
+ network.throttling.rate
+
+
+
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+
+ snapshot.max.hourly
+
+
+
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+ snapshot.max.daily
+
+
+
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+
+ snapshot.max.weekly
+
+
+
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+ snapshot.max.monthly
+
+
+
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+ To modify global configuration parameters, use the global configuration screen in the CloudStack UI. See Setting Global Configuration Parameters
+
14.4. Default Account Resource Limits
+ You can limit resource use by accounts. The default limits are set using global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account (max.account.snapshots, etc.)..
+
+ To override a default limit for a particular account, set a per-account resource limit.
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Accounts.
+
+ Select the account you want to modify. The current limits are displayed. A value of -1 shows that there is no limit in place
+
+ Click the Edit button
+
+
14.5. Per-Domain Limits
+ CloudStack allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of all accounts in the domain as well as all accounts in all subdomains of that domain. Limits set at the root domain level apply to the sum of resource usage by the accounts in all domains and sub-domains below that root domain.
+
+ To set a domain limit:
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Domains.
+
+ Select the domain you want to modify. The current domain limits are displayed. A value of -1 shows that there is no limit in place.
+
+ In a CloudStack, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN. The CloudStack virtual router is the main component providing networking features for guest traffic.
+
15.1. Guest Traffic
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+
+ Figure 1 illustrates a typical guest traffic setup:
+
+ The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+
+ The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
+
+ Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
+
15.2. Networking in a Pod
+ Figure 2 illustrates network setup within a single pod. The hosts are connected to a pod-level switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
+
+ Servers are connected as follows:
+
+ Storage devices are connected to only the network that carries management traffic.
+
+ Hosts are connected to networks for both management traffic and public traffic.
+
+ Hosts are also connected to one or more networks carrying guest traffic.
+
+ We recommend the use of multiple physical Ethernet cards to implement each network interface as well as redundant switch fabric in order to maximize throughput and improve reliability.
+
15.3. Networking in a Zone
+ Figure 3 illustrates the network setup within a single zone.
+
+ A firewall for management traffic operates in the NAT mode. The network typically is assigned IP addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses in the 192.168.*.0/24 Class C private address space.
+
+ Each zone has its own set of public IP addresses. Public IP addresses from different zones do not overlap.
+
15.4. Basic Zone Physical Network Configuration
+ In a basic network, configuring the physical network is fairly straightforward. You only need to configure one guest network to carry traffic that is generated by guest VMs. When you first add a zone to CloudPlatform, you set up the guest network through the Add Zone screens.
+
15.5. Advanced Zone Physical Network Configuration
+ Within a zone that uses advanced networking, you need to tell the Management Server how the physical network is set up to carry different kinds of traffic in isolation.
+
15.5.1. Configure Guest Traffic in an Advanced Zone
+ These steps assume you have already logged in to the CloudStack UI. To configure the base guest network:
+
+ In the left navigation, choose Infrastructure. On Zones, click View More, then click the zone to which you want to add a network.
+
+ Click the Network tab.
+
+ Click Add guest network.
+
+ The Add guest network window is displayed:
+
+ Provide the following information:
+
+ Name. The name of the network. This will be user-visible
+
+ Display Text: The description of the network. This will be user-visible
+
+ Zone: The zone in which you are configuring the guest network.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network
+
+ Guest Gateway: The gateway that the guests should use
+
+ Guest Netmask: The netmask in use on the subnet the guests will use
+
+ Click OK.
+
15.5.2. Configure Public Traffic in an Advanced Zone
+ In a zone that uses advanced networking, you need to configure at least one range of IP addresses for Internet traffic.
+
15.6. Using Multiple Guest Networks
+ In zones that use advanced networking, additional networks for guest traffic may be added at any time after the initial installation. You can also customize the domain name associated with the network by specifying a DNS suffix for each network.
+
+ A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has been created, although the user can go into the guest and remove the IP address from the NIC on a particular network.
+
+ Each VM has just one default network. The virtual router's DHCP reply will set the guest's default gateway as that for the default network. Multiple non-default networks may be added to a guest in addition to the single, required default network. The administrator can control which networks are available as the default network.
+
+ Additional networks can either be available to all accounts or be assigned to a specific account. Networks that are available to all accounts are zone-wide. Any user with access to the zone can create a VM with access to that network. These zone-wide networks provide little or no isolation between guests.Networks that are assigned to a specific account provide strong isolation.
+
15.6.1. Adding an Additional Guest Network
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click Add guest network. Provide the following information:
+
+ Name: The name of the network. This will be user-visible.
+
+ Display Text: The description of the network. This will be user-visible.
+
+ Zone. The name of the zone this network applies to. Each zone is a broadcast domain, and therefore each zone has a different IP range for the guest network. The administrator must configure the IP range for each zone.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network.
+
+ Guest Gateway: The gateway that the guests should use.
+
+ Guest Netmask: The netmask in use on the subnet the guests will use.
+
+ Click Create.
+
15.6.2. Changing the Network Offering on a Guest Network
+ A user or administrator can change the network offering that is associated with an existing guest network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ If you are changing from a network offering that uses the CloudStack virtual router to one that uses external devices as network service providers, you must first stop all the VMs on the network. See Stopping and Starting VMs. Then return here and continue to the next step
+
+ In the left navigation, choose Network
+
+ Click the name of the network you want to modify
+
+ .
+
+ In Network Offering, choose the new network offering, then click Apply.
+
+ A prompt appears asking whether you want to keep the existing CIDR. This is to let you know that if you change the network offering, the CIDR will be affected. Choose No to proceed with the change.
+
+ Wait for the update to complete. Don’t try to restart VMs until after the network change is complete.
+
+ If you stopped any VMs in step 2, restart them.
+
15.7. Security Groups
15.7.1. About Security Groups
+ Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In CloudStack 3.0.3 - 3.0.5, security groups are supported only in zones that use basic networking.
+
Note
+ In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
+
+
+ Each CloudStack account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.
+
+ Any CloudStack user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.
+
+ You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.
+
+ If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
15.7.2. Adding a Security Group
+ A user or administrator can define a new security group.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups.
+
+ Click Add Security Group.
+
+ Provide a name and description.
+
+ Click OK.
+
+ The new security group appears in the Security Groups Details tab.
+
+ To make the security group useful, continue to Adding Ingress and Egress Rules to a Security Group.
+
15.7.3. Enabling Security Groups
+ In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide.
+
15.7.4. Adding Ingress and Egress Rules to a Security Group
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups, then click the security group you want .
+
+ To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify what network traffic is allowed into VM instances in this security group. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
+ Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow incoming traffic from all VMs in another security group
+
+ Protocol. The networking protocol that sources will use to send traffic to the security group. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be accepted.
+
+ CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To accept only traffic from another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter the same name you used in step 7.
+
+ The following example allows inbound HTTP access from anywhere:
+
+ To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been allowed in through an ingress rule
+
+ Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow outgoing traffic to all VMs in another security group.
+
+ Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
+
+ CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To allow traffic to be sent to another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter its name.
+
+ Click Add.
+
15.8. External Firewalls and Load Balancers
+ CloudStack is capable of replacing its Virtual Router with an external Juniper SRX device and an optional external NetScaler or F5 load balancer for gateway and load balancing services. In this case, the VMs use the SRX as their gateway.
+
15.9. Load Balancer Rules
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudStack virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
15.10. Guest IP Ranges
+ The IP ranges for guest network traffic are set on a per-account basis by the user. This allows the users to configure their network in a fashion that will enable VPN linking between their guest network and their clients.
+
15.11. Acquiring a New IP Address
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click the name of the network where you want to work with.
+
+ Click View IP Addresses.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.
+
15.12. Releasing an IP Address
+ Log in to the CloudPlatform UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click the name of the network where you want to work with.
+
+ Click View IP Addresses.
+
+ Click the IP address you want to release.
+
+ Click the Release IP button
+
+ .
+
15.13. Static NAT
+ A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
+
15.14. IP Forwarding and Firewalling
+ By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is translated via NAT to the public IP address and is allowed.
+
+ To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example, you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44. Then use port forwarding rules to direct traffic from individual ports within that range to specific ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public IP's port 33 to port 100 on one user VM's private IP.
+
+ For the steps to implement these rules, see Firewall Rules and Port Forwarding.
+
15.15. IP Load Balancing
+ The user may choose to associate the same public IP for multiple guests. CloudStack implements a TCP-level load balancer with the following policies.
+
+ Round-robin
+
+ Least connection
+
+ Source IP
+
+ This is similar to port forwarding but the destination may be multiple IP addresses.
+
15.16. DNS and DHCP
+ The Virtual Router provides DNS and DHCP services to the guests. It proxies DNS requests to the DNS server configured on the Availability Zone.
+
15.17. VPN
+ CloudStack account owners can create virtual private networks (VPN) to access their virtual machines. If the guest network is instantiated from a network offering that offers the Remote Access VPN service, the virtual router (based on the System VM) is used to provide the service. CloudStack provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN. CloudStack does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.
+
Note
+ Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
+
+ Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
+
+ Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.
+
15.17.1. Configuring VPN
+ To set up VPN for the cloud:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, click Global Settings.
+
+ Set the following global configuration parameters.
+
+ remote.access.vpn.client.ip.range – The range of IP addressess to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
+
+ remote.access.vpn.psk.length – Length of the IPSec key.
+
+ remote.access.vpn.user.limit – Maximum number of VPN users per account.
+
+ To enable VPN for a particular network:
+
+ Log in as a user or administrator to the CloudStack UI.
+
+ In the left navigation, click Network.
+
+ Click the name of the network you want to work with.
+
+ Click View IP Addresses.
+
+ Click one of the displayed IP address names.
+
+ Click the Enable VPN button
+
+ .
+
+ The IPsec key is displayed in a popup window.
+
15.17.2. Using VPN with Windows
+ The procedure to use VPN varies by Windows version. Generally, the user must edit the VPN properties and make sure that the default route is not the VPN. The following steps are for Windows L2TP clients on Windows Vista. The commands should be similar for other Windows versions.
+
+ Log in to the CloudStack UI and click on the source NAT IP for the account. The VPN tab should display the IPsec preshared key. Make a note of this and the source NAT IP. The UI also lists one or more users and their passwords. Choose one of these users, or, if none exists, add a user and password.
+
+ On the Windows box, go to Control Panel, then select Network and Sharing center. Click Setup a connection or network.
+
+ In the next dialog, select No, create a new connection.
+
+ In the next dialog, select Use my Internet Connection (VPN).
+
+ In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check Don't connect now.
+
+ In the next dialog, enter the user name and password selected in step 1.
+
+ Click Create.
+
+ Go back to the Control Panel and click Network Connections to see the new connection. The connection is not active yet.
+
+ Right-click the new connection and select Properties. In the Properties dialog, select the Networking tab.
+
+ In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key. Enter the preshared key from Step 1.
+
+ The connection is ready for activation. Go back to Control Panel -> Network Connections and double-click the created connection.
+
+ Enter the user name and password from Step 1.
+
15.17.3. Using VPN with Mac OS X
+ In Mac OS X, in Network Preferences - Advanced, make sure Send all traffic over VPN connection is not checked.
+
15.17.4. Setting Up a Site-to-Site VPN Connection
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+
+ Cisco ISR with IOS 12.4 or later
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
Note
+ In addition to the specific Cisco and Juniper devices listed above, the expectation is that any Cisco or Juniper device running on the supported operating systems are able to establish VPN connections.
+
+ To set up a Site-to-Site VPN connection, perform the following:
+
+ Create a VPN gateway for the VPC that you created.
+
+ Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
+
15.17.4.1. Creating and Updating a VPN Customer Gateway
Note
+ A VPN customer gateway can be connected to only one VPN gateway at a time.
+
+ To add a VPN Customer Gateway:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Click Add site-to-site VPN.
+
+ Provide the following information:
+
+ Name: A unique name for the VPN customer gateway you create.
+
+ Gateway: The IP address for the remote gateway.
+
+ CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be RFC1918-compliant.
+
+ IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share a secret key. This key value is used to authenticate the customer gateway and the VPC VPN gateway to each other.
+
Note
+ The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.
+
+ IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is accomplished through the Preshared Keys.
+
Note
+ The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.
+
+ IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.
+
+ IKE DH: A public-key cryptography protocol which allows two parties to establish a shared secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).
+
+ ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192, AES256, and 3DES.
+
Note
+ The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.
+
+ ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash algorithms are SHA1 and MD5.
+
+ Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised. This property enforces a new Diffie-Hellman key exchange. It provides the keying material that has greater key material life and thereby greater resistance to cryptographic attacks. The available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key exchanges increase as the DH groups grow larger, as does the time of the exchanges.
+
Note
+ When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.
+
+ IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is 86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.
+
+ ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a new IPsec encryption and authentication session keys.
+
+ Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual router to query the liveliness of its IKE peer at regular intervals. It’s recommended to have the same configuration of DPD on both side of VPN connection.
+
+ Click OK.
+
Updating and Removing a VPN Customer Gateway
+ You can update a customer gateway either with no VPN connection, or related VPN connection is in error state.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Select the VPN customer gateway you want to work with.
+
+ To modify the required parameters, click the Edit VPN Customer Gateway button
+
+
+ To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
+
+
+ Click OK.
+
15.17.4.2. Creating a VPN gateway for the VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Site-to-Site VPN.
+
+ If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN prompts you to create a VPN gateway.
+
+ In the confirmation dialog, click Yes to confirm.
+
+ Within a few moments, the VPN gateway is created. You will be prompted to view the details of the VPN gateway you have created. Click Yes to confirm.
+
+ The following details are displayed in the VPN Gateway page:
+
+ IP Address
+
+ Account
+
+ Domain
+
15.17.4.3. Creating a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you create for the account are listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ Click Create VPN Connection.
+
+ The Create VPN Connection dialog is displayed:
+
+ Select the desired customer gateway, then click OK to confirm.
+
+ Within a few moments, the VPN Connection is displayed.
+
+ The following information on the VPN connection is displayed:
+
+ IP Address
+
+ Gateway
+
+ State
+
+ IPSec Preshared Key
+
+ IKE Policy
+
+ ESP Policy
+
15.17.4.4. Restarting and Removing a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ All the VPN connections you created are displayed.
+
+ Select the VPN connection you want to work with.
+
+ The Details tab is displayed.
+
+ To remove a VPN connection, click the Delete VPN connection button
+
+
+ To restart a VPN connection, click the Reset VPN connection button present in the Details tab.
+
+
15.18. About Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You provision VLANs to the tiers your create, and VMs can be deployed on different tiers. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications, such as Web, Application, or Database. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+ The major advantages are:
+
+ The administrator can deploy a set of VLANs and allow users to deploy VMs on these VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that account.
+
Note
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+
+ The administrator can allow users create their own VPC and deploy the application. In this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that account.
+
+ Both administrators and users can create multiple VPCs. The guest network NIC is plugged to the VPC virtual router when the first VM is deployed in a tier.
+
+ The administrator can create the following gateways to send to or receive traffic from the VMs:
+
+ Public Gateway: The public gateway for a VPC is added to the virtual router when the virtual router is created for VPC. The public gateway is not exposed to the end users. You are not allowed to list it, nor allowed to create any static routes.
+
+ Both administrators and users can create various possible destinations-gateway combinations. However, only one gateway of each type can be used in a deployment.
+
+ For example:
+
+ VLANs and Public Gateway: For example, an application is deployed in the cloud, and the Web application VMs communicate with the Internet.
+
+ VLANs, VPN Gateway, and Public Gateway: For example, an application is deployed in the cloud; the Web application VMs communicate with the Internet; and the database VMs communicate with the on-premise devices.
+
+ The administrator can define Access Control List (ACL) on the virtual router to filter the traffic among the VLANs or between the Internet and a VLAN. You can define ACL based on CIDR, port range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress type.
+
+ The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
+
+ CloudStack Virtual Private Cloud is a private, isolated part of CloudStack. A VPC can have its own virtual network topology that resembles a traditional physical network. You can launch VMs in the virtual network that can have private addresses in the range of your choice, for example: 10.0.0.0/16. You can define network tiers within your VPC network range, which in turn enables you to group similar kinds of instances based on IP address range.
+
+ For example, if a VPC has the private range 10.0.0.0/16, its guest networks can have the network ranges 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on.
+
Major Components of a VPC:
+ A VPC is comprised of the following network components:
+
+ VPC: A VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router.
+
+ Network Tiers: Each tier acts as an isolated network with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
+
+ Virtual Router: A virtual router is automatically created and started when you create a VPC. The virtual router connect the tiers and direct traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and DHCP services through its IP.
+
+ Public Gateway: The traffic to and from the Internet routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to the end user; therefore, static routes are not support for the public gateway.
+
+ In a VPC, the following four basic options of network architectures are present:
+
+ VPC with a public gateway only
+
+ VPC with public and private gateways
+
+ VPC with public and private gateways and site-to-site VPN access
+
+ VPC with a private gateway only and site-to-site VPN access
+
Connectivity Options for a VPC
+ You can connect your VPC to:
+
+ The Internet through the public gateway.
+
+ The corporate datacenter by using a site-to-site VPN connection through the VPN gateway.
+
+ Both the Internet and your corporate datacenter by using both the public gateway and a VPN gateway.
+
VPC Network Considerations
+ Consider the following before you create a VPC:
+
+ A VPC, by default, is created in the enabled state.
+
+ A VPC can be created in Advance zone only, and can't belong to more than one zone at a time.
+
+ The default number of VPCs an account can create is 20. However, you can change it by using the max.account.vpcs global parameter, which controls the maximum number of VPCs an account is allowed to create.
+
+ The default number of tiers an account can create within a VPC is 3. You can configure this number by using the vpc.max.networks parameter.
+
+ Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be within the VPC CIDR range.
+
+ A tier belongs to only one VPC.
+
+ All network tiers inside the VPC should belong to the same account.
+
+ When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP is released only when the VPC is removed.
+
+ A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it cannot be used for StaticNAT or port forwarding.
+
+ The instances only have a private IP address that you provision. To communicate with the Internet, enable NAT to an instance that you launch in your VPC.
+
+ Only new networks can be added to a VPC. The maximum number of networks per VPC is limited by the value you specify in the vpc.max.networks parameter. The default value is three.
+
+ The load balancing service can be supported by only one tier inside the VPC.
+
+ If an IP address is assigned to a tier:
+
+ That IP can't be used by more than one tier at a time in the VPC. For example, if you have tiers A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A or B, but not for both.
+
+ That IP can't be used for StaticNAT, load balancing, or port forwarding rules for another guest network inside the VPC.
+
+ Remote access VPN is not supported in VPC networks.
+
15.19.2. Adding a Virtual Private Cloud
+ When creating the VPC, you simply provide the zone and a set of IP addresses for the VPC network address space. You specify this set of addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ Click Add VPC. The Add VPC page is displayed as follows:
+
+ Provide the following information:
+
+ Name: A short name for the VPC that you are creating.
+
+ Description: A brief description of the VPC.
+
+ Zone: Choose the zone where you want the VPC to be available.
+
+ Super CIDR for Guest Networks: Defines the CIDR range for all the tiers (guest networks) within a VPC. When you create a tier, ensure that its CIDR is within the Super CIDR value you enter. The CIDR must be RFC1918 compliant.
+
+ DNS domain for Guest Networks: If you want to assign a special domain name, specify the DNS suffix. This parameter is applied to all the tiers within the VPC. That implies, all the tiers you create in the VPC belong to the same DNS domain. If the parameter is not specified, a DNS domain name is generated automatically.
+
15.19.3. Adding Tiers
+ Tiers are distinct locations within a VPC that act as isolated networks, which do not have access to other tiers by default. Tiers are set up on different VLANs that can communicate with each other by using a virtual router. Tiers provide inexpensive, low latency network connectivity to other tiers within the VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
Note
+ The end users can see their own VPCs, while root and domain admin can see any VPC they are authorized to see.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Add new tier dialog is displayed, as follows:
+
+ If you have already created tiers, the VPC diagram is displayed. Click Create Tier to add a new tier.
+
+ Specify the following:
+
+ All the fields are mandatory.
+
+ Name: A unique name for the tier you create.
+
+ Network Offering: The following default network offerings are listed: DefaultIsolatedNetworkOfferingForVpcNetworksNoLB, DefaultIsolatedNetworkOfferingForVpcNetworks
+
+ In a VPC, only one tier can be created by using LB-enabled network offering.
+
+ Gateway: The gateway for the tier you create. Ensure that the gateway is within the Super CIDR range that you specified while creating the VPC, and is not overlapped with the CIDR of any existing tier within the VPC.
+
+ Netmask: The netmask for the tier you create.
+
+ For example, if the VPC CIDR is 10.0.0.0/16 and the network tier CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the netmask of the tier is 255.255.255.0.
+
+ Click OK.
+
+ Continue with configuring access control list for the tier.
+
15.19.4. Configuring Access Control List
+ Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service is supported.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Network ACLs.
+
+ The Network ACLs page is displayed.
+
+ Click Add Network ACLs.
+
+ To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed in this tier.
+
+ CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or to the IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Protocol: The networking protocol that sources use to send traffic to the tier. The TCP and UDP protocols are typically used for data exchange and end-user communications. The ICMP protocol is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ Select Tier: Select the tier for which you want to add this ACL rule.
+
+ ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
+
+ Traffic Type: Select the traffic type you want to apply.
+
+ Egress: To add an egress rule, select Egress from the Traffic type drop-down box and click Add. This specifies what type of traffic is allowed to be sent out of VM instances in this tier. If no egress rules are specified, all traffic from the tier is allowed out at the VPC virtual router. Once egress rules are specified, only the traffic specified in egress rules and the responses to any traffic that has been allowed in through an ingress rule are allowed out. No egress rule is required for the VMs in a tier to communicate with each other.
+
+ Ingress: To add an ingress rule, select Ingress from the Traffic type drop-down box and click Add. This specifies what network traffic is allowed into the VM instances in this tier. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
Note
+ By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, create a new network ACL.
+
+ Click Add. The ACL rule is added.
+
+ To view the list of ACL rules you have added, click the desired tier from the Network ACLs page, then select the Network ACL tab.
+
+ You can edit the tags assigned to the ACL rules and delete the ACL rules you have created. Click the appropriate button in the Actions column.
+
15.19.5. Adding a Private Gateway to a VPC
+ A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. No gateways with duplicated VLAN and IP are allowed in the same data center.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Private Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Private Gateways.
+
+ The Gateways page is displayed.
+
+ Click Add new gateway:
+
+ Specify the following:
+
+ Physical Network: The physical network you have created in the zone.
+
+ IP Address: The IP address associated with the VPC gateway.
+
+ Gateway: The gateway through which the traffic is routed to and from the VPC.
+
+ Netmask: The netmask associated with the VPC gateway.
+
+ VLAN: The VLAN associated with the VPC gateway.
+
+ The new gateway appears in the list. You can repeat these steps to add more gateway for this VPC.
+
15.19.6. Deploying VMs to the Tier
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed.
+
+ Click the Add VM button of the tier for which you want to add a VM.
+
+ The Add Instance page is displayed.
+
+ Follow the on-screen instruction to add an instance. For information on adding an instance, see Adding Instances section in the Installation Guide.
+
15.19.7. Acquiring a New IP Address for a VPC
+ When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks within the VPC. The IPs are associated to the guest network only when the first port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP can't be associated to more than one network at a time.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding, load balancing, and static NAT rules.
+
15.19.8. Releasing an IP Address Alloted to a VPC
+ The IP address is a limited resource. If you no longer need a particular IP, you can disassociate it from its VPC and return it to the pool of available addresses. An IP address can be released from its tier, only when all the networking ( port forwarding, load balancing, or StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC whose IP you want to release.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to release.
+
+ In the Details tab, click the Release IP button
+
+
15.19.9. Enabling or Disabling Static NAT on a VPC
+ A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to allow Internet traffic to it. This section tells how to enable or disable static NAT for a particular IP address in a VPC.
+
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to work with.
+
+ In the Details tab,click the Static NAT button.
+
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+
+ If you are enabling static NAT, a dialog appears as follows:
+
+ Select the tier and the destination VM, then click Apply.
+
15.19.10. Adding Load Balancing Rules on a VPC
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Load Balancing node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
Note
+ In a VPC, the load balancing service is supported only on a single tier.
+
+ Specify the following:
+
+ Name: A name for the load balancer rule.
+
+ Public Port: The port that receives the incoming traffic to be balanced.
+
+ Private Port: The port that the VMs will use to receive the traffic.
+
+ Algorithm. Choose the load balancing algorithm you want CloudStack to use. CloudStack supports the following well-known algorithms:
+
+ Round-robin
+
+ Least connections
+
+ Source
+
+ Stickiness. (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
+
+ Add VMs: Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.
+
+ The new load balancing rule appears in the list. You can repeat these steps to add more load balancing rules for this IP address.
+
15.19.11. Adding a Port Forwarding Rule on a VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Choose an existing IP address or acquire a new IP address. Click the name of the IP address in the list.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Port Forwarding node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
+ Specify the following:
+
+ Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+
+ Private Port: The port on which the instance is listening for forwarded public traffic.
+
+ Protocol: The communication protocol in use between the two ports.
+
+ TCP
+
+ UDP
+
+ Add VM: Click Add VM. Select the name of the instance to which this rule applies, and click Apply.
+
+ You can test the rule by opening an ssh session to the instance.
+
15.19.12. Removing Tiers
+ You can remove a tier from a VPC. A removed tier cannot be revoked. When a tier is removed, only the resources of the tier are expunged. All the network rules (port forwarding, load balancing and staticNAT) and the IP addresses associated to the tier are removed. The IP address still be belonging to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Configure VPC page is displayed. Locate the tier you want to work with.
+
+ Click the Remove VPC button:
+
+ Wait for some time for the tier to be removed.
+
15.19.13. Editing, Restarting, and Removing a Virtual Private Cloud
Note
+ Ensure that all the tiers are removed before you remove a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Select the VPC you want to work with.
+
+ To remove, click the Remove VPC button
+
+
+ You can edit the name and description of a VPC. To do that, select the VPC, then click the Edit button.
+
+
+ To restart a VPC, select the VPC, then click the Restart button.
+
+
+ CloudStack uses several types of system virtual machines to perform tasks in the cloud. In general CloudStack manages these system VMs and creates, starts, and stops them as needed based on scale and immediate needs. However, the administrator should be aware of them and their roles to assist in debugging issues.
+
16.1. The System VM Template
+ The System VMs come from a single template. The System VM has the following characteristics:
+
+ Debian 6.0 ("Squeeze"), 2.6.32 kernel with the latest security patches from the Debian security APT repository
+
+ Has a minimal set of packages installed thereby reducing the attack surface
+
+ 32-bit for enhanced performance on Xen/VMWare
+
+ pvops kernel with Xen PV drivers, KVM virtio drivers, and VMware tools for optimum performance on all hypervisors
+
+ Latest versions of HAProxy, iptables, IPsec, and Apache from debian repository ensures improved security and speed
+
+ Latest version of JRE from Sun/Oracle ensures improved security and speed
+
16.2. Multiple System VM Support for VMware
+ Every CloudStack zone has single System VM for template processing tasks such as downloading templates, uploading templates, and uploading ISOs. In a zone where VMware is being used, additional System VMs can be launched to process VMware-specific tasks such as taking snapshots and creating private templates. The CloudStack management server launches additional System VMs for VMware-specific tasks as the load increases. The management server monitors and weights all commands sent to these System VMs and performs dynamic load balancing and scaling-up of more System VMs.
+
16.3. Console Proxy
+ The Console Proxy is a type of System Virtual Machine that has a role in presenting a console view via the web UI. It connects the user’s browser to the VNC port made available via the hypervisor for the console of the guest. Both the administrator and end user web UIs offer a console connection.
+
+ Clicking on a console icon brings up a new window. The AJAX code downloaded into that window refers to the public IP address of a console proxy VM. There is exactly one public IP address allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then proxies the connection to the VNC port for the requested VM on the Host hosting the guest. .
+
Note
+ The hypervisors will have many ports assigned to VNC usage so that multiple VNC sessions can occur simultaneously.
+
+ There is never any traffic to the guest virtual IP, and there is no need to enable VNC within the guest.
+
+ The console proxy VM will periodically report its active session count to the Management Server. The default reporting interval is five seconds. This can be changed through standard Management Server configuration with the parameter consoleproxy.loadscan.interval.
+
+ Assignment of guest VM to console proxy is determined by first determining if the guest VM has a previous session associated with a console proxy. If it does, the Management Server will assign the guest VM to the target Console Proxy VM regardless of the load on the proxy VM. Failing that, the first available running Console Proxy VM that has the capacity to handle new sessions is used.
+
+ Console proxies can be restarted by administrators but this will interrupt existing console sessions for users.
+
+ The console viewing functionality uses a dynamic DNS service under the domain name realhostip.com to assist in providing SSL security to console sessions. The console proxy is assigned a public IP address. In order to avoid browser warnings for mismatched SSL certificates, the URL for the new console window is set to the form of https://aaa-bbb-ccc-ddd.realhostip.com. Customers will see this URL during console session creation. CloudStack includes the realhostip.com SSL certificate in the console proxy VM. Of course, CloudStack cannot know about DNS A records for our customers' public IPs prior to shipping the software. CloudStack therefore runs a dynamic DNS server that is authoritative for the realhostip.com domain. It maps the aaa-bbb-ccc-ddd part of the DNS name to the IP address aaa.bbb.ccc.ddd on lookups. This allows the browser to correctly connect to the console proxy's public IP, where it then expects and receives a SSL certificate for realhostip.com, and SSL is set up without browser warnings.
+
16.4. Virtual Router
+ The virtual router is a type of System Virtual Machine. The virtual router is one of the most frequently used service providers in CloudStack. The end user has no direct access to the virtual router. Users can ping the virtual router and take actions that affect it (such as setting up port forwarding), but users do not have SSH access into the virtual router.
+
+ There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be restarted by administrators, but this will interrupt public network access and other services for end users. A basic test in debugging networking issues is to attempt to ping the virtual router from a guest VM. Some of the characteristics of the virtual router are determined by its associated system service offering.
+
16.5. Secondary Storage VM
+ In addition to the hosts, CloudStack’s Secondary Storage VM mounts and writes to secondary storage.
+
+ Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols.
+
+ The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups.
+
+ The administrator can log in to the secondary storage VM if needed.
+
Chapter 17. System Reliability and High Availability
+ The CloudStack Management Server should be deployed in a multi-node configuration such that it is not susceptible to individual server failures. The Management Server itself (as distinct from the MySQL database) is stateless and may be placed behind a load balancer.
+
+ Normal operation of Hosts is not impacted by an outage of all Management Serves. All guest VMs will continue to work.
+
+ When the Management Server is down, no new VMs can be created, and the end user and admin UI, API, dynamic load distribution, and HA will cease to work.
+
17.2. HA-Enabled Virtual Machines
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
17.3. HA for Hosts
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
17.4. Primary Storage Outage and Data Loss
+ When a primary storage outage occurs the hypervisor immediately stops all VMs stored on that storage device. Guests that are marked for HA will be restarted as soon as practical when the primary storage comes back on line. With NFS, the hypervisor may allow the virtual machines to continue running depending on the nature of the issue. For example, an NFS hang will cause the guest VMs to be suspended until storage connectivity is restored.Primary storage is not designed to be backed up. Individual volumes in primary storage can be backed up using snapshots.
+
17.5. Secondary Storage Outage and Data Loss
+ For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online.
+
+ Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system.
+
18.1. 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:
+
+ The following API commands have the "tags" input parameter:
+
+ listVirtualMachines
+
+ listVolumes
+
+ listSnapshots
+
+ listNetworks
+
+ listTemplates
+
+ listIsos
+
+ listFirewallRules
+
+ listPortForwardingRules
+
+ listPublicIpAddresses
+
+ listSecurityGroups
+
+ listLoadBalancerRules
+
+ listProjects
+
+ listVPCs
+
+ listNetworkACLs
+
+ listStaticRoutes
+
18.2. Changing the Database Configuration
+ The CloudStack Management Server stores database configuration information (e.g., hostname, port, credentials) in the file /etc/cloud/management/db.properties. To effect a change, edit this file on each Management Server, then restart the Management Server.
+
18.3. 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
+
18.4. 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” 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.
+
18.5. 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:
+
# service cloud-management stop
+ To start the Management Server:
+
# service cloud-management start
+ To stop the Management Server:
+
# service cloud-management stop
Chapter 19. Setting Global Configuration Parameters
+ CloudStack provides parameters that you can set to control many aspects of the cloud. When CloudStack is first installed, and periodically thereafter, you might need to modify these settings.
+
+ Log in to the UI as administrator.
+
+ In the left navigation bar, click Global Settings.
+
+ In Select View, choose one of the following:
+
+ Global Settings. This displays a list of the parameters with brief descriptions and current values.
+
+ Hypervisor Capabilities. This displays a list of hypervisor versions with the maximum number of guests supported for each.
+
+ Use the search box to narrow down the list to those you are interested in.
+
+ Click the Edit icon to modify a value. If you are viewing Hypervisor Capabilities, you must click the name of the hypervisor first to display the editing screen.
+
+ 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.
+
+ 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.
+
20.2. Allocators
+ CloudStack enables administrators to write custom allocators that will choose the Host to place a new guest and the storage host from which to allocate guest virtual disk images.
+
20.3. User Data and Meta Data
+ CloudStack provides API access to attach 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.
+
+ Access user data by running the following command using the result of the above command
+
# 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
+
+ This section provides tips on how to improve the performance of your cloud.
+
21.1. Performance Monitoring
+ Host and guest performance monitoring is available to end users and administrators. This allows the user to monitor their utilization of resources and determine when it is appropriate to choose a more powerful service offering or larger disk.
+
21.2. Increase Management Server Maximum Memory
+ If the Management Server is subject to high demand, the default maximum JVM memory allocation can be insufficient. To increase the memory:
+
+ Edit the Tomcat configuration file:
+
/etc/cloud/management/tomcat6.conf
+ Change the command-line parameter -XmxNNNm to a higher value of N.
+
+ For example, if the current value is -Xmx128m, change it to -Xmx1024m or higher.
+
+ To put the new setting into effect, restart the Management Server.
+
# service cloud-management restart
+ For more information about memory issues, see "FAQ: Memory" at Tomcat Wiki.
+
21.3. Set Database Buffer Pool Size
+ It is important to provide enough memory space for the MySQL database to cache data and indexes:
+
+ Edit the Tomcat configuration file:
+
/etc/my.cnf
+ Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM.
+
innodb_buffer_pool_size=700M
+ Restart the MySQL service.
+
# service mysqld restart
+ For more information about the buffer pool, see "The InnoDB Buffer Pool" at MySQL Reference Manual.
+
21.4. Set and Monitor Total VM Limits per Host
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
21.5. Configure XenServer dom0 Memory
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+
+ 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..
+
22.1.2. 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
+
22.1.3. 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
+
22.1.4. 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
+
22.2. Working with Server Logs
+ The CloudStack Management Server logs all web site, middle tier, and database activities for diagnostics purposes in /var/log/cloud/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.
+
+ 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:
+
+ 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:
+
+ grep "job-1076)" management-server.log
+
+ The CloudStack Agent Server logs its activities in /var/log/cloud/agent/.
+
22.3. 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:
+
+ 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
+
22.4. 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.
+
+ Host was placed in maintenance mode, but still appears live in vCenter.
+
Cause
+ The CloudPlatform 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.
+
22.6. 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.
+
22.7. 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.
+
22.8. 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 CloudPlatform 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.
+
Time Zones
+ 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
+
+
+
+
+
Event Types
+
+ VM.CREATE
+
+
+
+ TEMPLATE.EXTRACT
+
+
+
+ SG.REVOKE.INGRESS
+
+
+
+ VM.DESTROY
+
+
+
+ TEMPLATE.UPLOAD
+
+
+
+ HOST.RECONNECT
+
+
+
+ VM.START
+
+
+
+ TEMPLATE.CLEANUP
+
+
+
+ MAINT.CANCEL
+
+
+
+ VM.STOP
+
+
+
+ VOLUME.CREATE
+
+
+
+ MAINT.CANCEL.PS
+
+
+
+ VM.REBOOT
+
+
+
+ VOLUME.DELETE
+
+
+
+ MAINT.PREPARE
+
+
+
+ VM.UPGRADE
+
+
+
+ VOLUME.ATTACH
+
+
+
+ MAINT.PREPARE.PS
+
+
+
+ VM.RESETPASSWORD
+
+
+
+ VOLUME.DETACH
+
+
+
+ VPN.REMOTE.ACCESS.CREATE
+
+
+
+ ROUTER.CREATE
+
+
+
+ VOLUME.UPLOAD
+
+
+
+ VPN.USER.ADD
+
+
+
+ ROUTER.DESTROY
+
+
+
+ SERVICEOFFERING.CREATE
+
+
+
+ VPN.USER.REMOVE
+
+
+
+ ROUTER.START
+
+
+
+ SERVICEOFFERING.UPDATE
+
+
+
+ NETWORK.RESTART
+
+
+
+ ROUTER.STOP
+
+
+
+ SERVICEOFFERING.DELETE
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+ ROUTER.REBOOT
+
+
+
+ DOMAIN.CREATE
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+ ROUTER.HA
+
+
+
+ DOMAIN.DELETE
+
+
+
+ STATICNAT.DISABLE
+
+
+
+ PROXY.CREATE
+
+
+
+ DOMAIN.UPDATE
+
+
+
+ SSVM.CREATE
+
+
+
+ PROXY.DESTROY
+
+
+
+ SNAPSHOT.CREATE
+
+
+
+ SSVM.DESTROY
+
+
+
+ PROXY.START
+
+
+
+ SNAPSHOT.DELETE
+
+
+
+ SSVM.START
+
+
+
+ PROXY.STOP
+
+
+
+ SNAPSHOTPOLICY.CREATE
+
+
+
+ SSVM.STOP
+
+
+
+ PROXY.REBOOT
+
+
+
+ SNAPSHOTPOLICY.UPDATE
+
+
+
+ SSVM.REBOOT
+
+
+
+ PROXY.HA
+
+
+
+ SNAPSHOTPOLICY.DELETE
+
+
+
+ SSVM.H
+
+
+
+ VNC.CONNECT
+
+
+
+ VNC.DISCONNECT
+
+
+
+ NET.IPASSIGN
+
+
+
+ NET.IPRELEASE
+
+
+
+ NET.RULEADD
+
+
+
+ NET.RULEDELETE
+
+
+
+ NET.RULEMODIFY
+
+
+
+ NETWORK.CREATE
+
+
+
+ NETWORK.DELETE
+
+
+
+ LB.ASSIGN.TO.RULE
+
+
+
+ LB.REMOVE.FROM.RULE
+
+
+
+ LB.CREATE
+
+
+
+ LB.DELETE
+
+
+
+ LB.UPDATE
+
+
+
+ USER.LOGIN
+
+
+
+ USER.LOGOUT
+
+
+
+ USER.CREATE
+
+
+
+ USER.DELETE
+
+
+
+ USER.UPDATE
+
+
+
+ USER.DISABLE
+
+
+
+ TEMPLATE.CREATE
+
+
+
+ TEMPLATE.DELETE
+
+
+
+ TEMPLATE.UPDATE
+
+
+
+ TEMPLATE.COPY
+
+
+
+ TEMPLATE.DOWNLOAD.START
+
+
+
+ TEMPLATE.DOWNLOAD.SUCCESS
+
+
+
+ TEMPLATE.DOWNLOAD.FAILED
+
+
+
+ ISO.CREATE
+
+
+
+ ISO.DELETE
+
+
+
+ ISO.COPY
+
+
+
+ ISO.ATTACH
+
+
+
+ ISO.DETACH
+
+
+
+ ISO.EXTRACT
+
+
+
+ ISO.UPLOAD
+
+
+
+ SERVICE.OFFERING.CREATE
+
+
+
+ SERVICE.OFFERING.EDIT
+
+
+
+ SERVICE.OFFERING.DELETE
+
+
+
+ DISK.OFFERING.CREATE
+
+
+
+ DISK.OFFERING.EDIT
+
+
+
+ DISK.OFFERING.DELETE
+
+
+
+ NETWORK.OFFERING.CREATE
+
+
+
+ NETWORK.OFFERING.EDIT
+
+
+
+ NETWORK.OFFERING.DELETE
+
+
+
+ POD.CREATE
+
+
+
+ POD.EDIT
+
+
+
+ POD.DELETE
+
+
+
+ ZONE.CREATE
+
+
+
+ ZONE.EDIT
+
+
+
+ ZONE.DELETE
+
+
+
+ VLAN.IP.RANGE.CREATE
+
+
+
+ VLAN.IP.RANGE.DELETE
+
+
+
+ CONFIGURATION.VALUE.EDIT
+
+
+
+ SG.AUTH.INGRESS
+
+
+
+
+
Alerts
+ The following is the list of alert type numbers. The current alerts can be found by calling listAlerts.
+
MEMORY = 0
CPU = 1
STORAGE =2
STORAGE_ALLOCATED = 3
PUBLIC_IP = 4
PRIVATE_IP = 5
HOST = 6
USERVM = 7
DOMAIN_ROUTER = 8
CONSOLE_PROXY = 9
ROUTING = 10// lost connection to default route (to the gateway)
STORAGE_MISC = 11 // lost connection to default route (to the gateway)
USAGE_SERVER = 12 // lost connection to default route (to the gateway)
MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)
DOMAIN_ROUTER_MIGRATE = 14
CONSOLE_PROXY_MIGRATE = 15
USERVM_MIGRATE = 16
VLAN = 17
SSVM = 18
USAGE_SERVER_RESULT = 19
STORAGE_DELETE = 20;
UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource count
USAGE_SANITY_RESULT = 22;
DIRECT_ATTACHED_PUBLIC_IP = 23;
LOCAL_STORAGE = 24;
RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only
+ You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate CloudStack end-users. Just map CloudStack accounts to the corresponding LDAP accounts using a query filter. The query filter is written using the query syntax of the particular LDAP server, and can include special wildcard characters provided by CloudStack for matching common values such as the user’s email address and name. CloudStack will search the external LDAP directory tree starting at a specified base directory and return the distinguished name (DN) and password of the matching user. This information along with the given password is used to authenticate the user..
+
+ To set up LDAP authentication in CloudStack, call the CloudStack API command ldapConfig and provide the following:
+
+ Hostname or IP address and listening port of the LDAP server
+
+ Base directory and query filter
+
+ Search user DN credentials, which give CloudStack permission to search on the LDAP server
+
+ SSL keystore and password, if SSL is used
+
3.2.1. Example LDAP Configuration Commands
+ To understand the examples in this section, you need to know the basic concepts behind calling the CloudStack API, which are explained in the Developer’s Guide.
+
+ The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
+
+ 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.
+
+ The next few sections explain some of the concepts you will need to know when filling out the ldapConfig parameters.
+
3.2.2. Search Base
+ An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The search base is the distinguished name (DN) of a level of the directory tree below which all users can be found. The users can be in the immediate base directory or in some subdirectory. The search base may be equivalent to the organization, group, or domain name. The syntax for writing a DN varies depending on which LDAP server you are using. A full discussion of distinguished names is outside the scope of our documentation. The following table shows some examples of search bases to find users in the testing department..
+
+
+ LDAP Server
+
+
+
+ Example Search Base DN
+
+
+
+ ApacheDS
+
+
+
+ ou=testing,o=project
+
+
+
+ Active Directory
+
+
+
+ OU=testing, DC=company
+
+
3.2.3. Query Filter
+ The query filter is used to find a mapped user in the external LDAP server. The query filter should uniquely map the CloudPlatform user to LDAP user for a meaningful authentication. For more information about query filter syntax, consult the documentation for your LDAP server.
+
+ The CloudPlatform 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 CloudPlatform user name is the same as the LDAP user ID:
+
(uid=%u)
+ If the CloudPlatform user name is the LDAP display name:
+
(displayName=%u)
+ To find a user by email address:
+
(mail=%e)
3.2.4. Search User Bind DN
+ The bind DN is the user on the external LDAP server permitted to search the LDAP directory within the defined search base. When the DN is returned, the DN and passed password are used to authenticate the CloudStack user with an LDAP bind. A full discussion of bind DNs is outside the scope of our documentation. The following table shows some examples of bind DNs.
+
+ 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.
+
+ A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set of KVM servers, , or a VMware cluster preconfigured in vCenter. The hosts in a cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the same shared primary storage. Virtual machine instances (VMs) can be live-migrated from one host to another within the same cluster, without interrupting service to the user.
+
+ A cluster is the third-largest organizational unit within a CloudStack deployment. Clusters are contained within pods, and pods are contained within zones. Size of the cluster is limited by the underlying hypervisor, although the CloudStack recommends less in most cases; see Best Practices.
+
+ A cluster consists of one or more hosts and one or more primary storage servers.
+
+ CloudStack allows multiple clusters in a cloud deployment.
+
+ Even when local storage is used exclusively, clusters are still required organizationally, even if there is just one host per cluster.
+
+ When VMware is used, every VMware cluster is managed by a vCenter server. Administrator must register the vCenter server with CloudStack. There may be multiple vCenter servers per zone. Each vCenter server may manage multiple VMware clusters.
+
+ A host is a single computer. Hosts provide the computing resources that run the guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a Linux KVM-enabled server, a Citrix XenServer server, and an ESXi server are hosts.
+
+ The host is the smallest organizational unit within a CloudStack deployment. Hosts are contained within clusters, clusters are contained within pods, and pods are contained within zones.
+
+ Hosts in a CloudStack deployment:
+
+ Provide the CPU, memory, storage, and networking resources needed to host the virtual machines
+
+ Interconnect using a high bandwidth TCP/IP network and connect to the Internet
+
+ May reside in multiple data centers across different geographic locations
+
+ May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the hosts within a cluster must all be homogeneous
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs.
+
+ CloudStack automatically detects the amount of CPU and memory resources provided by the Hosts.
+
+ Hosts are not visible to the end user. An end user cannot determine which host their guest has been assigned to.
+
+ For a host to function in CloudStack, you must do the following:
+
+ Install hypervisor software on the host
+
+ Assign an IP address to the host
+
+ Ensure the host is connected to the CloudStack Management Server
+
+ Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical networks can be associated with each zone. The network corresponds to a NIC on the hypervisor host. Each physical network can carry one or more types of network traffic. The choices of traffic type for each network vary depending on whether you are creating a zone with basic networking or advanced networking.
+
+ A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can:
+
+ Add/Remove/Update physical networks in a zone
+
+ Configure VLANs on the physical network
+
+ Configure a name so the network can be recognized by hypervisors
+
+ Configure the service providers (firewalls, load balancers, etc.) available on a physical network
+
+ Configure the IP addresses trunked to a physical network
+
+ Specify what type of traffic is carried on the physical network, as well as other properties like network speed
+
2.7.1. Configurable Characteristics of Physical Networks
+ CloudStack provides configuration settings you can use to set up a physical network in a zone, including:
+
+ What type of network traffic it carries (guest, public, management, storage)
+
+ VLANs
+
+ Unique name that the hypervisor can use to find that particular network
+
+ Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator sets the physical network to enabled, and it begins to be used. The administrator can later disable the network again, which prevents any new virtual networks from being created on that physical network; the existing network traffic continues even though the state is disabled.
+
+ Speed
+
+ Tags, so network offerings can be matched to physical networks
+
+ Isolation method
+
2.7.2. Basic Zone Network Traffic Types
+ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
Note
+ We strongly recommend the use of separate NICs for management traffic and guest traffic.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. CloudStack takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.
+
2.7.3. Basic Zone Guest IP Addresses
+ When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts.
+
2.7.4. Advanced Zone Network Traffic Types
+ When advanced networking is used, there can be multiple physical networks in the zone. Each physical network can carry one or more traffic types, and you need to let CloudStack know which type of network traffic you want each network to carry. The traffic types in an advanced zone are:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each CloudStack account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network.
+
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide.
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices.
+
2.7.5. Advanced Zone Guest IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.6. Advanced Zone Public IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
2.7.7. System Reserved IP Addresses
+ In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the CloudStack Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
+
+ The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone.
+
+ The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in.
+
+ Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. CloudStack can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
+
+ In all zones:
+
+ Provide private IPs for the system in each pod and provision them in CloudStack.
+
+ For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.
+
+ In a zone that uses advanced networking:
+
+ For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required CloudStack System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.
+
+ When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
+
+ To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:
+
+ Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than 4,000 IP addresses.
+
+ Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod has 255 IPs, this will provide 2,550 IP addresses.
+
+ A pod often represents a single rack. Hosts in the same pod are in the same subnet.
+
+ A pod is the second-largest organizational unit within a CloudStack deployment. Pods are contained within zones. Each zone can contain one or more pods.
+
+ Pods are not visible to the end user.
+
+ A pod consists of one or more clusters of hosts and one or more primary storage servers.
+
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required. It is typically located close to the hosts for increased performance.
+
+ CloudStack is designed to work with all standards-compliant iSCSI and NFS servers that are supported by the underlying hypervisor, including, for example:
+
+ Dell EqualLogic™ for iSCSI
+
+ Network Appliances filers for NFS and iSCSI
+
+ Scale Computing for NFS
+
+ If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.
+
+ Secondary storage is associated with a zone, and it stores the following:
+
+ Templates — OS images that can be used to boot VMs and can include additional configuration information, such as installed applications
+
+ ISO images — disc images containing data or bootable media for operating systems
+
+ Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
+
+ The items in zone-based NFS secondary storage are available to all hosts in the zone. CloudStack manages the allocation of guest virtual disks to particular primary storage devices.
+
+ To make items in secondary storage available to all hosts throughout the cloud, you can add OpenStack Object Storage (Swift, swift.openstack.org) in addition to the zone-based NFS secondary storage. When using Swift, you configure Swift storage for the entire CloudStack, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere.
+
+ A virtual network is a logical construct that enables multi-tenancy on a single physical network. In CloudStack a virtual network can be shared or isolated.
+
9.2.1. Isolated Networks
+ An isolated network can be accessed only by virtual machines of a single account. Isolated networks have the following properties.
+
+ Resources such as VLAN are allocated and garbage collected dynamically
+
+ There is one network offering for the entire network
+
+ The network offering can be upgraded or downgraded but it is for the entire network
+
9.2.2. Shared Networks
+ A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in CloudStack 3.0.3).
+
+ Shared Networks are created by the administrator
+
+ Shared Networks can be designated to a certain domain
+
+ Shared Network resources such as VLAN and physical network that it maps to are designated by the administrator
+
+ Shared Networks are isolated by security groups
+
+ Public Network is a shared network that is not shown to the end users
+
9.2.3. Runtime Allocation of Virtual Network Resources
+ When you define a new virtual network, all your settings for that network are stored in CloudStack. The actual network resources are activated only when the first virtual machine starts in the network. When all virtual machines have left the virtual network, the network resources are garbage collected so they can be allocated again. This helps to conserve network resources..
+
+ CloudStack provides administrators with complete control over the lifecycle of all guest VMs executing in the cloud. CloudStack provides several guest management operations for end users and administrators. VMs may be stopped, started, rebooted, and destroyed.
+
+ Guest VMs have a name and group. VM names and groups are opaque to CloudStack and are available for end users to organize their VMs. Each VM can have three names for use in different contexts. Only two of these names can be controlled by the user:
+
+ Instance name – a unique, immutable ID that is generated by CloudStack and can not be modified by the user. This name conforms to the requirements in IETF RFC 1123.
+
+ Display name – the name displayed in the CloudStack web UI. Can be set by the user. Defaults to instance name.
+
+ Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to instance name
+
+ Guest VMs can be configured to be Highly Available (HA). An HA-enabled VM is monitored by the system. If the system detects that the VM is down, it will attempt to restart the VM, possibly on a different host. For more information, see HA-Enabled Virtual Machines on
+
+ Each new VM is allocated one public IP address. When the VM is started, CloudStack automatically creates a static NAT between this public IP address and the private IP address of the VM.
+
+ If elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new VM is not marked as elastic. The user must replace the automatically configured IP with a specifically acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s private IP. The VM’s original IP address is then released and returned to the pool of available public IPs.
+
+ CloudStack cannot distinguish a guest VM that was shut down by the user (such as with the “shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut down from inside the VM, CloudStack will restart it. To shut down an HA-enabled VM, you must go through the CloudStack UI or API.
+
+ A zone is the largest organizational unit within a CloudStack deployment. A zone typically corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter. The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required).
+
+ A zone consists of:
+
+ One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
+
+ Secondary storage, which is shared by all the pods in the zone.
+
+ Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones.
+
+ Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone.
+
+ Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels.
+
+ For each zone, the administrator must decide the following.
+
+ How many pods to place in a zone.
+
+ How many clusters to place in each pod.
+
+ How many hosts to place in each cluster.
+
+ How many primary storage servers to place in each cluster and total capacity for the storage servers.
+
+ How much secondary storage to deploy in 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.
+
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
+ To access a VM through the CloudStack UI:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ Click Instances, then click the name of a running VM.
+
+ Click the View Console button .
+
+ To access a VM directly over the network:
+
+ The VM must have some port open to incoming traffic. For example, in a basic zone, a new VM might be assigned to a security group which allows incoming traffic. This depends on what security group you picked when creating the VM. In other cases, you can open a port by setting up a port forwarding policy. See IP Forwarding and Firewalling.
+
+ If a port is open but you can not access the VM using ssh, it’s possible that ssh is not already enabled on the VM. This will depend on whether ssh is enabled in the template you picked when creating the VM. Access the VM through the CloudStack UI and enable ssh on the machine using the commands for the VM’s operating system.
+
+ If the network has an external firewall device, you will need to create a firewall rule to allow access. See IP Forwarding and Firewalling.
+
+ 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
+
+ The 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.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click the name of the network where you want to work with.
+
+ Click View IP Addresses.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.
+
+ 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.
+
6.4.1. 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”. 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”.
+
+ 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.
+
+ 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.
+
12.13. Adding Password Management to Your Templates
+ CloudStack provides an optional password reset feature that allows users to set a temporary admin or root password as well as reset the existing admin or root password from the CloudStack UI.
+
+ To enable the Reset Password feature, you will need to download an additional script to patch your template. When you later upload the template into CloudStack, you can specify whether reset admin/root password feature should be enabled for this template.
+
+ The password management feature works always resets the account password on instance boot. The script does an HTTP call to the virtual router to retrieve the account password that should be set. As long as the virtual router is accessible the guest will have access to the account password that should be used. When the user requests a password reset the management server generates and sends a new password to the virtual router for the account. Thus an instance reboot is necessary to effect any password changes.
+
+ If the script is unable to contact the virtual router during instance boot it will not set the password but boot will continue normally.
+
12.13.1. Linux OS Installation
+ Use the following steps to begin the Linux OS installation:
+
+ Download the script file cloud-set-guest-password:
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs. For requirements and instructions, see Section 7.5, “Adding a Host”.
+
+ 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
+
15.5. Advanced Zone Physical Network Configuration
+ Within a zone that uses advanced networking, you need to tell the Management Server how the physical network is set up to carry different kinds of traffic in isolation.
+
15.5.1. Configure Guest Traffic in an Advanced Zone
+ These steps assume you have already logged in to the CloudStack UI. To configure the base guest network:
+
+ In the left navigation, choose Infrastructure. On Zones, click View More, then click the zone to which you want to add a network.
+
+ Click the Network tab.
+
+ Click Add guest network.
+
+ The Add guest network window is displayed:
+
+ Provide the following information:
+
+ Name. The name of the network. This will be user-visible
+
+ Display Text: The description of the network. This will be user-visible
+
+ Zone: The zone in which you are configuring the guest network.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network
+
+ Guest Gateway: The gateway that the guests should use
+
+ Guest Netmask: The netmask in use on the subnet the guests will use
+
+ Click OK.
+
15.5.2. Configure Public Traffic in an Advanced Zone
+ In a zone that uses advanced networking, you need to configure at least one range of IP addresses for Internet traffic.
+
+ CloudStack enables administrators to write custom allocators that will choose the Host to place a new guest and the storage host from which to allocate guest virtual disk images.
+
+ 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.
+
+ Asynchronous commands were introduced in CloudStack 2.x. Commands are designated as asynchronous when they can potentially take a long period of time to complete such as creating a snapshot or disk volume. They differ from synchronous commands by the following:
+
+ They are identified in the API Reference by an (A).
+
+ They will immediately return a job ID to refer to the job that will be responsible in processing the command.
+
+ If executed as a "create" resource command, it will return the resource ID as well as the job ID.
+
+ You can periodically check the status of the job by making a simple API call to the command, queryAsyncJobResult and passing in the job ID.
+
4.5.1. Job Status
+ The key to using an asynchronous command is the job ID that is returned immediately once the command has been executed. With the job ID, you can periodically check the job status by making calls to queryAsyncJobResult command. The command will return three possible job status integer values:
+
+ 0 - Job is still in progress. Continue to periodically poll for any status changes.
+
+ 1 - Job has successfully completed. The job will return any successful response values associated with command that was originally executed.
+
+ 2 - Job has failed to complete. Please check the "jobresultcode" tag for failure reason code and "jobresult" for the failure reason.
+
4.5.2. Example
+ The following shows an example of using an asynchronous command. Assume the API command:
+
+ The software that provides AWS API compatibility is installed along with CloudPlatform. However, you must enable the feature and perform some setup steps.
+
+ Create a set of CloudStack service offerings with names that match the Amazon service offerings. You can do this through the CloudStack UI as described in the Administration Guide.
+
Warning
+ Be sure you have included the Amazon default service offering, m1.small.
+
+ If you did not already do so when you set the configuration parameter in step 1, restart the Management Server.
+
# service cloud-management restart
+ (Optional) The AWS API listens for requests on port 7080. If you prefer AWS API to listen on another port, you can change it as follows:
+
+ Edit the files /etc/cloud/management/server.xml, /etc/cloud/management/server-nonssl.xml, and /etc/cloud/management/server-ssl.xml.
+
+ In each file, find the tag <Service name="Catalina7080">. Under this tag, locate <Connector executor="tomcatThreadPool-internal" port= ....<.
+
+ Change the port to whatever port you want to use, then save the files.
+
+ Restart the Management Server.
+
Note
+ If you re-install CloudStack, you will have to make these changes again.
+
10.1. Amazon Web Services EC2 Compatible Interface
+ CloudStack can translate Amazon Web Services (AWS) API calls to native CloudStack API calls so that users can continue using existing AWS-compatible tools. This translation service runs as a separate web application in the same tomcat server as the management server of CloudStack, listening on the same port. This Amazon EC2-compatible API is accessible through a SOAP web service.
+
Note
+ This service was previously enabled by separate software called CloudBridge. It is now fully integrated with the CloudStack management server.
+
+ Limitations
+
+ Supported only in zones that use basic networking.
+
+ Available in fresh installations of CloudStack. Not available through upgrade of previous versions.
+
+ If you need to support features such as elastic IP, set up a Citrix NetScaler to provide this service. The commands such as ec2-associate-address will not work without EIP setup. Users running VMs in this zone will be using the NetScaler-enabled network offering (DefaultSharedNetscalerEIP and ELBNetworkOffering).
+
+ The following Amazon EC2 commands are supported by CloudStack when the AWS API compatibility feature is enabled. For a few commands, there are differences between the CloudStack and Amazon EC2 versions, and these differences are noted. The underlying SOAP call for each command is also given, for those who have built tools using those calls.
+
10.5. Using Timeouts to Ensure AWS API Command Completion
+ The Amazon EC2 command-line tools have a default connection timeout. When used with CloudStack, a longer timeout might be needed for some commands. If you find that commands are not completing due to timeouts, you can gain more time for commands to finish by overriding the default timeouts on individual commands. You can add the following optional command-line parameters to any CloudStack-supported EC2 command:
+
+
+
--connection-timeout TIMEOUT
+
+ Specifies a connection timeout (in seconds). Example:
+
--connection-timeout 30
+
+
+
+
--request-timeout TIMEOUT
+
+ Specifies a request timeout (in seconds). Example:
+
+ In general, users need not be aware that they are using a translation service provided by CloudStack. They need only send AWS API calls to CloudStack's endpoint, and it will translate the calls to the native API. Users of the Amazon EC2 compatible interface will be able to keep their existing EC2 tools and scripts and use them with their CloudStack deployment, by specifying the endpoint of the management server and using the proper user credentials. In order to do this, each user must perform the following configuration steps:
+
+
+ Generate user credentials and register with the service.
+
+ Set up the environment variables for the EC2 command-line tools.
+
+ For SOAP access, use the endpoint http://CloudStack-management-server:8080/awsapi. The CloudStack-management-server can be specified by a fully-qualified domain name or IP address.
+
+
+
10.4.1. AWS API User Registration
+ Each user must perform a one-time registration. The user follows these steps:
+
+ Obtain the following by looking in the CloudStack UI, using the API, or asking the cloud administrator:
+
+ The CloudStack server's publicly available DNS name or IP address
+
+ The user account's API key and Secret key
+
+ Generate a private key and a self-signed X.509 certificate. The user substitutes their own desired storage location for /path/to/… below.
+
+ Register the mapping from the X.509 certificate to the API/Secret keys. Download the following script from http://download.cloud.com/releases/3.0.3/cloudstack-aws-api-register and run it. Substitute the values that were obtained in step 1 in the URL below.
+
+ A user with an existing AWS certificate could choose to use the same certificate with CloudStack, but the public key would be uploaded to the CloudStack management server database.
+
10.4.2. AWS API Command-Line Tools Setup
+ To use the EC2 command-line tools, the user must perform these steps:
+
+ Set up the environment variables that will direct the tools to the server. As a best practice, you may wish to place these commands in a script that may be sourced before using the AWS API translation feature.
+
+ In a basic network, configuring the physical network is fairly straightforward. You only need to configure one guest network to carry traffic that is generated by guest VMs. When you first add a zone to CloudPlatform, you set up the guest network through the Add Zone screens.
+
+ If you plan to use large templates (100 GB or larger), be sure you have a 10-gigabit network to support the large templates. A slower network can lead to timeouts and other errors when large templates are used.
+
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
+ The CloudStack Management Server stores database configuration information (e.g., hostname, port, credentials) in the file /etc/cloud/management/db.properties. To effect a change, edit this file on each Management Server, then restart the Management Server.
+
+ 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:
+
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".
+
mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;
diff --git a/docs/tmp/en-US/html/changing-service-offering-for-vm.html b/docs/tmp/en-US/html/changing-service-offering-for-vm.html
new file mode 100644
index 00000000000..7db07ec8679
--- /dev/null
+++ b/docs/tmp/en-US/html/changing-service-offering-for-vm.html
@@ -0,0 +1,23 @@
+
+
+10.8. Changing the Service Offering for a VM
diff --git a/docs/tmp/en-US/html/changing-vm-name-os-group.html b/docs/tmp/en-US/html/changing-vm-name-os-group.html
new file mode 100644
index 00000000000..01ee1a59f8f
--- /dev/null
+++ b/docs/tmp/en-US/html/changing-vm-name-os-group.html
@@ -0,0 +1,31 @@
+
+
+10.7. Changing the VM Name, OS, or Group
+ The architecture used in a deployment will vary depending on the size and purpose of the deployment. This section contains examples of deployment architecture, including a small-scale deployment useful for test and trial deployments and a fully-redundant large-scale setup for production deployments.
+
+ If you want to use the Citrix XenServer hypervisor to run guest virtual machines, install XenServer 6.0 or XenServer 6.0.2 on the host(s) in your cloud. For an initial installation, follow the steps below. If you have previously installed XenServer and want to upgrade to another version, see Section 8.2.11, “Upgrading XenServer Versions”.
+
8.2.1. System Requirements for XenServer Hosts
+ The host must be certified as compatible with one of the following. See the Citrix Hardware Compatibility Guide: http://hcl.xensource.com
+
+ XenServer 5.6 SP2
+
+ XenServer 6.0
+
+ XenServer 6.0.2
+
+ You must re-install Citrix XenServer if you are going to re-use a host from a previous install.
+
+ Must support HVM (Intel-VT or AMD-V enabled)
+
+ 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.
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+ Must support HVM (Intel-VT or AMD-V enabled in BIOS)
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ Hardware virtualization support required
+
+ 4 GB of memory
+
+ 36 GB of local disk
+
+ At least 1 NIC
+
+ Statically allocated IP Address
+
+ When you deploy CloudStack, the hypervisor host must not have any VMs already running
+
Warning
+ The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see http://support.citrix.com/article/CTX126531. The article refers to XenServer 5.6, but the same information applies to XenServer 6.0.
+
8.2.4. Username and Password
+ All XenServers in a cluster must have the same username and password as configured in CloudStack.
+
8.2.5. Time Synchronization
+ The host must be set to use NTP. All hosts in a pod must have the same time.
+
+ Install NTP.
+
# yum install ntp
+ Edit the NTP configuration file to point to your NTP server.
+
# vi /etc/ntp.conf
+ Add one or more server lines in this file with the names of the NTP servers you want to use. For example:
+
server 0.xenserver.pool.ntp.org
+server 1.xenserver.pool.ntp.org
+server 2.xenserver.pool.ntp.org
+server 3.xenserver.pool.ntp.org
+
+ Restart the NTP client.
+
# service ntpd restart
+ Make sure NTP will start again upon reboot.
+
# chkconfig ntpd on
8.2.6. Licensing
+ Citrix XenServer Free version provides 30 days usage without a license. Following the 30 day trial, XenServer requires a free activation and license. You can choose to install a license now or skip this step. If you skip this step, you will need to install a license when you activate and license the XenServer.
+
8.2.6.1. Getting and Deploying a License
+ If you choose to install a license now you will need to use the XenCenter to activate and get a license.
+
+ In XenCenter, click Tools > License manager.
+
+ Select your XenServer and select Activate Free XenServer.
+
+ Request a license.
+
+ You can install the license with XenCenter or using the xe command line tool.
+
8.2.7. Install CloudStack XenServer Support Package (CSP)
+ (Optional)
+
+ To enable security groups, elastic load balancing, and elastic IP on XenServer, download and install the CloudStack XenServer Support Package (CSP). After installing XenServer, perform the following additional steps on each XenServer host.
+
+ Download the CSP software onto the XenServer host from one of the following links:
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
# xe-switch-network-backend bridge
+ Restart the host machine when prompted.
+
+ The XenServer host is now ready to be added to CloudStack.
+
8.2.8. Primary Storage Setup for XenServer
+ CloudStack natively supports NFS, iSCSI and local storage. If you are using one of these storage types, there is no need to create the XenServer Storage Repository ("SR").
+
+ If, however, you would like to use storage connected via some other technology, such as FiberChannel, you must set up the SR yourself. To do so, perform the following steps. If you have your hosts in a XenServer pool, perform the steps on the master node. If you are working with a single XenServer which is not part of a cluster, perform the steps on that XenServer.
+
+ Connect FiberChannel cable to all hosts in the cluster and to the FiberChannel storage host.
+
+ Rescan the SCSI bus. Either use the following command or use XenCenter to perform an HBA rescan.
+
# scsi-rescan
+ Repeat step 2 on every host.
+
+ Check to be sure you see the new SCSI disk.
+
# ls /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -l
+ The output should look like this, although the specific file name will be different (scsi-<scsiID>):
+
+ This command returns a unique ID for the SR, like the following example (your ID will be different):
+
7a143820-e893-6c6a-236e-472da6ee66bf
+ To create a human-readable description for the SR, use the following command. In uuid, use the SR ID returned by the previous command. In name-description, set whatever friendly text you prefer.
+
+ Make note of the values you will need when you add this storage to CloudStack later (see Section 6.6, “Add Primary Storage”). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the name-label you set earlier (in this example, e6849e96-86c3-4f2c-8fcc-350cc711be3d).
+
+ (Optional) If you want to enable multipath I/O on a FiberChannel SAN, refer to the documentation provided by the SAN vendor.
+
8.2.9. iSCSI Multipath Setup for XenServer (Optional)
+ When setting up the storage repository on a Citrix XenServer, you can enable multipath I/O, which uses redundant physical components to provide greater reliability in the connection between the server and the SAN. To enable multipathing, use a SAN solution that is supported for Citrix servers and follow the procedures in Citrix documentation. The following links provide a starting point:
+
+ You can also ask your SAN vendor for advice about setting up your Citrix repository for multipathing.
+
+ Make note of the values you will need when you add this storage to the CloudStack later (see Section 6.6, “Add Primary Storage”). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the same name used to create the SR.
+
+ If you encounter difficulty, address the support team for the SAN provided by your vendor. If they are not able to solve your issue, see Contacting Support.
+
8.2.10. Physical Networking Setup for XenServer
+ Once XenServer has been installed, you may need to do some additional network configuration. At this point in the installation, you should have a plan for what NICs the host will have and what traffic each NIC will carry. The NICs should be cabled as necessary to implement your plan.
+
+ If you plan on using NIC bonding, the NICs on all hosts in the cluster must be cabled exactly the same. For example, if eth0 is in the private bond on one host in a cluster, then eth0 must be in the private bond on all hosts in the cluster.
+
+ The IP address assigned for the management network interface must be static. It can be set on the host itself or obtained via static DHCP.
+
+ CloudStack configures network traffic of various types to use different NICs or bonds on the XenServer host. You can control this process and provide input to the Management Server through the use of XenServer network name labels. The name labels are placed on physical interfaces or bonds and configured in CloudStack. In some simple cases the name labels are not required.
+
8.2.10.1. Configuring Public Network with a Dedicated NIC for XenServer (Optional)
+ CloudStack supports the use of a second NIC (or bonded pair of NICs, described in Section 8.2.10.4, “NIC Bonding for XenServer (Optional)”) for the public network. If bonding is not used, the public network can be on any NIC and can be on different NICs on the hosts in a cluster. For example, the public network can be on eth0 on node A and eth1 on node B. However, the XenServer name-label for the public network must be identical across all hosts. The following examples set the network label to "cloud-public". After the management server is installed and running you must configure it with the name of the chosen network label (e.g. "cloud-public"); this is discussed in Section 4.5, “Management Server Installation”.
+
+ If you are using a single dedicated NIC to provide public network access, follow this procedure on each new host that is added to CloudStack before adding the host.
+
+ Run xe network-list and find the public network. This is usually attached to the NIC that is public. Once you find the network make note of its UUID. Call this <UUID-Public>.
+
8.2.10.2. Configuring Multiple Guest Networks for XenServer (Optional)
+ CloudStack supports the use of multiple guest networks with the XenServer hypervisor. Each network is assigned a name-label in XenServer. For example, you might have two networks with the labels "cloud-guest" and "cloud-guest2". After the management server is installed and running, you must add the networks and use these labels so that CloudStack is aware of the networks.
+
+ Follow this procedure on each new host before adding the host to CloudStack:
+
+ Run xe network-list and find one of the guest networks. Once you find the network make note of its UUID. Call this <UUID-Guest>.
+
+ Run the following command, substituting your own name-label and uuid values.
+
+ Repeat these steps for each additional guest network, using a different name-label and uuid each time.
+
8.2.10.3. Separate Storage Network for XenServer (Optional)
+ You can optionally set up a separate storage network. This should be done first on the host, before implementing the bonding steps below. This can be done using one or two available NICs. With two NICs bonding may be done as above. It is the administrator's responsibility to set up a separate storage network.
+
+ Give the storage network a different name-label than what will be given for other networks.
+
+ For the separate storage network to work correctly, it must be the only interface that can ping the primary storage device's IP address. For example, if eth0 is the management network NIC, ping -I eth0 <primary storage device IP> must fail. In all deployments, secondary storage devices must be pingable from the management network NIC or bond. If a secondary storage device has been placed on the storage network, it must also be pingable via the storage network NIC or bond on the hosts as well.
+
+ You can set up two separate storage networks as well. For example, if you intend to implement iSCSI multipath, dedicate two non-bonded NICs to multipath. Each of the two networks needs a unique name-label.
+
+ If no bonding is done, the administrator must set up and name-label the separate storage network on all hosts (masters and slaves).
+
+ Here is an example to set up eth5 to access a storage network on 172.16.0.0/24.
+
+ XenServer supports Source Level Balancing (SLB) NIC bonding. Two NICs can be bonded together to carry public, private, and guest traffic, or some combination of these. Separate storage networks are also possible. Here are some example supported configurations:
+
+ 2 NICs on private, 2 NICs on public, 2 NICs on storage
+
+ 2 NICs on private, 1 NIC on public, storage uses management network
+
+ 2 NICs on private, 2 NICs on public, storage uses management network
+
+ 1 NIC for private, public, and storage
+
+ All NIC bonding is optional.
+
+ XenServer expects all nodes in a cluster will have the same network cabling and same bonds implemented. In an installation the master will be the first host that was added to the cluster and the slave hosts will be all subsequent hosts added to the cluster. The bonds present on the master set the expectation for hosts added to the cluster later. The procedure to set up bonds on the master and slaves are different, and are described below. There are several important implications of this:
+
+ You must set bonds on the first host added to a cluster. Then you must use xe commands as below to establish the same bonds in the second and subsequent hosts added to a cluster.
+
+ Slave hosts in a cluster must be cabled exactly the same as the master. For example, if eth0 is in the private bond on the master, it must be in the management network for added slave hosts.
+
8.2.10.4.1. Management Network Bonding
+ The administrator must bond the management network NICs prior to adding the host to CloudStack.
+
8.2.10.4.2. Creating a Private Bond on the First Host in the Cluster
+ Use the following steps to create a bond in XenServer. These steps should be run on only the first host in a cluster. This example creates the cloud-private network with two physical NICs (eth0 and eth1) bonded into it.
+
+ Find the physical NICs that you want to bond together.
+
+ These command shows the eth0 and eth1 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
+
+ Create a new network for the bond. For example, a new network with name "cloud-private".
+
+ This label is important. CloudStack looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the management network.
+
# xe network-create name-label=cloud-private
+# xe bond-create network-uuid=[uuid of cloud-private created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+ Now you have a bonded pair that can be recognized by CloudStack as the management network.
+
8.2.10.4.3. Public Network Bonding
+ Bonding can be implemented on a separate, public network. The administrator is responsible for creating a bond for the public network if that network will be bonded and will be separate from the management network.
+
8.2.10.4.4. Creating a Public Bond on the First Host in the Cluster
+ These steps should be run on only the first host in a cluster. This example creates the cloud-public network with two physical NICs (eth2 and eth3) bonded into it.
+
+ Find the physical NICs that you want to bond together.
+
+ These command shows the eth2 and eth3 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
+
+ Create a new network for the bond. For example, a new network with name "cloud-public".
+
+ This label is important. CloudStack looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the public network.
+
# xe network-create name-label=cloud-public
+# xe bond-create network-uuid=[uuid of cloud-public created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+ Now you have a bonded pair that can be recognized by CloudStack as the public network.
+
8.2.10.4.5. Adding More Hosts to the Cluster
+ With the bonds (if any) established on the master, you should add additional, slave hosts. Run the following command for all additional hosts to be added to the cluster. This will cause the host to join the master in a single XenServer pool.
+
8.2.10.4.6. Complete the Bonding Setup Across the Cluster
+ With all hosts added to the pool, run the cloud-setup-bond script. This script will complete the configuration and set up of the bonds across all hosts in the cluster.
+
+ Copy the script from the Management Server in /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+
+ Run the script:
+
# ./cloud-setup-bonding.sh
+ Now the bonds are set up and configured properly across the cluster.
+
8.2.11. Upgrading XenServer Versions
+ This section tells how to upgrade XenServer software on CloudStack hosts. The actual upgrade is described in XenServer documentation, but there are some additional steps you must perform before and after the upgrade.
+
Note
+ Be sure the hardware is certified compatible with the new version of XenServer.
+
+ To upgrade XenServer:
+
+ Upgrade the database. On the Management Server node:
+
+ You might need to change the OS type settings for VMs running on the upgraded hosts.
+
+ If you upgraded from XenServer 5.6 GA to XenServer 5.6 SP2, change any VMs that have the OS type CentOS 5.5 (32-bit), Oracle Enterprise Linux 5.5 (32-bit), or Red Hat Enterprise Linux 5.5 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit).
+
+ If you upgraded from XenServer 5.6 SP2 to XenServer 6.0.2, change any VMs that have the OS type CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux 5.6 (32-bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.6 (32-bit) , or Red Hat Enterprise Linux 5.7 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit).
+
+ If you upgraded from XenServer 5.6 to XenServer 6.0.2, do all of the above.
+
+ Restart the Management Server and Usage Server. You only need to do this once for all clusters.
+
# service cloud-management start
+# service cloud-usage start
+ Disconnect the XenServer cluster from CloudStack.
+
+ Log in to the CloudStack UI as root.
+
+ Navigate to the XenServer cluster, and click Actions – Unmanage.
+
+ Watch the cluster status until it shows Unmanaged.
+
+ Log in to one of the hosts in the cluster, and run this command to clean up the VLAN:
+
# . /opt/xensource/bin/cloud-clean-vlan.sh
+ Still logged in to the host, run the upgrade preparation script:
+
# /opt/xensource/bin/cloud-prepare-upgrade.sh
+ Troubleshooting: If you see the error "can't eject CD," log in to the VM and umount the CD, then run the script again.
+
+ Upgrade the XenServer software on all hosts in the cluster. Upgrade the master first.
+
+ Live migrate all VMs on this host to other hosts. See the instructions for live migration in the Administrator's Guide.
+
+ Troubleshooting: You might see the following error when you migrate a VM:
+
[root@xenserver-qa-2-49-4 ~]# xe vm-migrate live=true host=xenserver-qa-2-49-5 vm=i-2-8-VM
+You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected.
+vm: b6cf79c8-02ee-050b-922f-49583d9f1a14 (i-2-8-VM)
+ Troubleshooting: If you see the following error message, you can safely ignore it.
+
mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory
+ Plug in the storage repositories (physical block devices) to the XenServer host:
+
# for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; done
+ Note: If you add a host to this XenServer pool, you need to migrate all VMs on this host to other hosts, and eject this host from XenServer pool.
+
+ Repeat these steps to upgrade every host in the cluster to the same version of XenServer.
+
+ Run the following command on one host in the XenServer cluster to clean up the host tags:
+
# for host in $(xe host-list | grep ^uuid | awk '{print $NF}') ; do xe host-param-clear uuid=$host param-name=tags; done;
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.
+
+ Reconnect the XenServer cluster to CloudStack.
+
+ Log in to the CloudStack UI as root.
+
+ Navigate to the XenServer cluster, and click Actions – Manage.
+
+ Watch the status to see that all the hosts come up.
+
+ After all hosts are up, run the following on one host in the 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.
+
7.4.1. 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.
+
7.4.2. 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.
+
+ 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 values from vCenter.
+
+ Cluster Name. Enter the name of the cluster you created in vCenter. For example, "cloud.cluster.2.2.1"
+
+ vCenter Host. Enter the hostname or IP address of the vCenter server.
+
+ vCenter Username. Enter the username that CloudStack should use to connect to vCenter. This user must have all administrative privileges.
+
+ 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".
+
+ There might be a slight delay while the cluster is provisioned. It will automatically display in the UI
+
+ A service offering is a set of virtual hardware features such as CPU core count and speed, memory, and disk size. The CloudStack administrator can set up various offerings, and then end users choose from the available offerings when they create a new VM. A service offering includes the following elements:
+
+ CPU, memory, and network resource guarantees
+
+ How resources are metered
+
+ How the resource usage is charged
+
+ How often the charges are generated
+
+ For example, one service offering might allow users to create a virtual machine instance that is equivalent to a 1 GHz Intel® Core™ 2 CPU, with 1 GB memory at $0.20/hour, with network traffic metered at $0.10/GB. Based on the user’s selected offering, CloudStack emits usage records that can be integrated with billing systems. CloudStack separates service offerings into compute offerings and disk offerings. The computing service offering specifies:
+
+ Guest CPU
+
+ Guest RAM
+
+ Guest Networking type (virtual or direct)
+
+ Tags on the root disk
+
+ The disk offering specifies:
+
+ Disk size (optional). An offering without a disk size will allow users to pick their own
+
+ Tags on the data disk
+
8.1.1. Creating a New Compute Offering
+ To create a new compute offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Compute Offering.
+
+ Click Add Compute Offering.
+
+ In the dialog, make the following choices:
+
+ Name: Any desired name for the service offering.
+
+ Description: A short description of the offering that can be displayed to users
+
+ Storage type: The type of disk that should be allocated. Local allocates from storage attached directly to the host where the system VM is running. Shared allocates from storage accessible via NFS.
+
+ # of CPU cores: The number of cores which should be allocated to a system VM with this offering
+
+ CPU (in MHz): The CPU speed of the cores that the system VM is allocated. For example, “2000” would provide for a 2 GHz clock.
+
+ Memory (in MB): The amount of memory in megabytes that the system VM should be allocated. For example, “2048” would provide for a 2 GB RAM allocation.
+
+ Network Rate: Allowed data transfer rate in MB per second.
+
+ Offer HA: If yes, the administrator can choose to have the system VM be monitored and as highly available as possible.
+
+ Storage Tags: The tags that should be associated with the primary storage used by the system VM.
+
+ Host Tags: (Optional) Any tags that you use to organize your hosts
+
+ CPU cap: Whether to limit the level of CPU usage even if spare capacity is available.
+
+ Public: Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.2. Creating a New Disk Offering
+ To create a system service offering:
+
+ Log in with admin privileges to the CloudStack UI.
+
+ In the left navigation bar, click Service Offerings.
+
+ In Select Offering, choose Disk Offering.
+
+ Click Add Disk Offering.
+
+ In the dialog, make the following choices:
+
+ Name. Any desired name for the system offering.
+
+ Description. A short description of the offering that can be displayed to users
+
+ Custom Disk Size. If checked, the user can set their own disk size. If not checked, the root administrator must define a value in Disk Size.
+
+ Disk Size. Appears only if Custom Disk Size is not selected. Define the volume size in GB.
+
+ (Optional)Storage Tags. The tags that should be associated with the primary storage for this disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue". Tags are also added on Primary Storage. CloudStack matches tags on a disk offering to tags on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation from the disk offering will fail..
+
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+
+ Click Add.
+
8.1.3. Modifying or Deleting a Service Offering
+ Service offerings cannot be changed once created. This applies to both compute offerings and disk offerings.
+
+ A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently. If the service offering is still in use, it will remain in the database until all the virtual machines referencing it have been deleted. After deletion by the administrator, a service offering will not be available to end users that are creating new instances.
+
+ CloudStack is only distributed from source from the official mirrors. However, members of the CloudStack community may build convenience binaries so that users can install Apache CloudStack without needing to build from source.
+
+ These repositories contain both the Management Server and KVM Hypervisor packages.
+
4.4.1. DEB package repository
+ You can add a DEB package repository to your apt sources with the following commands. Please note that currently only packages for Ubuntu 12.04 LTS (precise) are being build.
+
+ Use your preferred editor and open (or create) /etc/apt/sources.list.d/cloudstack. Add the community provided repository to the file:
+
deb http://cloudstack.apt-get.eu/ubuntu precise 4.0
+ We now have to add the public key to the trusted keys.
+
+ Your DEB package repository should now be configured and ready for use.
+
4.4.2. RPM package repository
+ If you're using an RPM-based system, you'll want to add the Yum repository so that you can install CloudStack with Yum.
+
+ Yum repository information is found under /etc/yum.repos.d. You'll see several .repo files in this directory, each one denoting a specific repository.
+
+ To add the CloudStack repository, visit the downloads page for the repository information. It will look something like this:
+
+ Be sure the Usage Server has been installed. This requires extra steps beyond just installing the CloudStack software. See Installing the Usage Server (Optional) in the Advanced Installation Guide.
+
+ Log in to the CloudStack UI as administrator.
+
+ Click Global Settings.
+
+ In Search, type usage. Find the configuration parameter that controls the behavior you want to set. See the table below for a description of the available parameters.
+
+ In Actions, click the Edit icon.
+
+ Type the desired value and click the Save icon.
+
+ Restart the Management Server (as usual with any global configuration change) and also the Usage Server:
+
# service cloud-management restart
+# service cloud-usage restart
+
+ The following table shows the global configuration settings that control the behavior of the Usage Server.
+
+
+ Parameter Name
+
+
+
+ Description
+
+
+
+ enable.usage.server
+
+
+
+ Whether the Usage Server is active.
+
+
+
+ usage.aggregation.timezone
+
+
+
+ Time zone of usage records. Set this if the usage records and daily job execution are in different time zones. For example, with the following settings, the usage job will run at PST 00:15 and generate usage records for the 24 hours from 00:00:00 GMT to 23:59:59 GMT:
+
+ The time zone of usage.stats.job.exec.time. Valid values for the time zone are specified in Appendix A, Time Zones
+
+
+ Default: The time zone of the management server.
+
+
+
+
+ usage.sanity.check.interval
+
+
+
+ The number of days between sanity checks. Set this in order to periodically search for records with erroneous data before issuing customer invoices. For example, this checks for VM usage records created after the VM was destroyed, and similar checks for templates, volumes, and so on. It also checks for usage times longer than the aggregation range. If any issue is found, the alert ALERT_TYPE_USAGE_SANITY_RESULT = 21 is sent.
+
+
+
+ usage.stats.job.aggregation.range
+
+
+
+ The time period in minutes between Usage Server processing jobs. For example, if you set it to 1440, the Usage Server will run once per day. If you set it to 600, it will run every ten hours. In general, when a Usage Server job runs, it processes all events generated since usage was last run.
+
+
+ There is special handling for the case of 1440 (once per day). In this case the Usage Server does not necessarily process all records since Usage was last run. CloudStack assumes that you require processing once per day for the previous, complete day’s records. For example, if the current day is October 7, then it is assumed you would like to process records for October 6, from midnight to midnight. CloudStack assumes this "midnight to midnight" is relative to the usage.execution.timezone.
+
+
+ Default: 1440
+
+
+
+
+ usage.stats.job.exec.time
+
+
+
+ The time when the Usage Server processing will start. It is specified in 24-hour format (HH:MM) in the time zone of the server, which should be GMT. For example, to start the Usage job at 10:30 GMT, enter "10:30".
+
+
+ If usage.stats.job.aggregation.range is also set, and its value is not 1440, then its value will be added to usage.stats.job.exec.time to get the time to run the Usage Server job again. This is repeated until 24 hours have elapsed, and the next day's processing begins again at usage.stats.job.exec.time.
+
+
+ Default: 00:15.
+
+
+
+ For example, suppose that your server is in GMT, your user population is predominantly in the East Coast of the United States, and you would like to process usage records every night at 2 AM local (EST) time. Choose these settings:
+
+ enable.usage.server = true
+
+ usage.execution.timezone = America/New_York
+
+ usage.stats.job.exec.time = 07:00. This will run the Usage job at 2:00 AM EST. Note that this will shift by an hour as the East Coast of the U.S. enters and exits Daylight Savings Time.
+
+ usage.stats.job.aggregation.range = 1440
+
+ With this configuration, the Usage job will run every night at 2 AM EST and will process records for the previous day’s midnight-midnight as defined by the EST (America/New_York) time zone.
+
Note
+ Because the special value 1440 has been used for usage.stats.job.aggregation.range, the Usage Server will ignore the data between midnight and 2 AM. That data will be included in the next day's run
+
+ CloudStack Virtual Private Cloud is a private, isolated part of CloudStack. A VPC can have its own virtual network topology that resembles a traditional physical network. You can launch VMs in the virtual network that can have private addresses in the range of your choice, for example: 10.0.0.0/16. You can define network tiers within your VPC network range, which in turn enables you to group similar kinds of instances based on IP address range.
+
+ For example, if a VPC has the private range 10.0.0.0/16, its guest networks can have the network ranges 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on.
+
Major Components of a VPC:
+ A VPC is comprised of the following network components:
+
+ VPC: A VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router.
+
+ Network Tiers: Each tier acts as an isolated network with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
+
+ Virtual Router: A virtual router is automatically created and started when you create a VPC. The virtual router connect the tiers and direct traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and DHCP services through its IP.
+
+ Public Gateway: The traffic to and from the Internet routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to the end user; therefore, static routes are not support for the public gateway.
+
+ In a VPC, the following four basic options of network architectures are present:
+
+ VPC with a public gateway only
+
+ VPC with public and private gateways
+
+ VPC with public and private gateways and site-to-site VPN access
+
+ VPC with a private gateway only and site-to-site VPN access
+
Connectivity Options for a VPC
+ You can connect your VPC to:
+
+ The Internet through the public gateway.
+
+ The corporate datacenter by using a site-to-site VPN connection through the VPN gateway.
+
+ Both the Internet and your corporate datacenter by using both the public gateway and a VPN gateway.
+
VPC Network Considerations
+ Consider the following before you create a VPC:
+
+ A VPC, by default, is created in the enabled state.
+
+ A VPC can be created in Advance zone only, and can't belong to more than one zone at a time.
+
+ The default number of VPCs an account can create is 20. However, you can change it by using the max.account.vpcs global parameter, which controls the maximum number of VPCs an account is allowed to create.
+
+ The default number of tiers an account can create within a VPC is 3. You can configure this number by using the vpc.max.networks parameter.
+
+ Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be within the VPC CIDR range.
+
+ A tier belongs to only one VPC.
+
+ All network tiers inside the VPC should belong to the same account.
+
+ When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP is released only when the VPC is removed.
+
+ A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it cannot be used for StaticNAT or port forwarding.
+
+ The instances only have a private IP address that you provision. To communicate with the Internet, enable NAT to an instance that you launch in your VPC.
+
+ Only new networks can be added to a VPC. The maximum number of networks per VPC is limited by the value you specify in the vpc.max.networks parameter. The default value is three.
+
+ The load balancing service can be supported by only one tier inside the VPC.
+
+ If an IP address is assigned to a tier:
+
+ That IP can't be used by more than one tier at a time in the VPC. For example, if you have tiers A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A or B, but not for both.
+
+ That IP can't be used for StaticNAT, load balancing, or port forwarding rules for another guest network inside the VPC.
+
+ Remote access VPN is not supported in VPC networks.
+
15.19.2. Adding a Virtual Private Cloud
+ When creating the VPC, you simply provide the zone and a set of IP addresses for the VPC network address space. You specify this set of addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ Click Add VPC. The Add VPC page is displayed as follows:
+
+ Provide the following information:
+
+ Name: A short name for the VPC that you are creating.
+
+ Description: A brief description of the VPC.
+
+ Zone: Choose the zone where you want the VPC to be available.
+
+ Super CIDR for Guest Networks: Defines the CIDR range for all the tiers (guest networks) within a VPC. When you create a tier, ensure that its CIDR is within the Super CIDR value you enter. The CIDR must be RFC1918 compliant.
+
+ DNS domain for Guest Networks: If you want to assign a special domain name, specify the DNS suffix. This parameter is applied to all the tiers within the VPC. That implies, all the tiers you create in the VPC belong to the same DNS domain. If the parameter is not specified, a DNS domain name is generated automatically.
+
15.19.3. Adding Tiers
+ Tiers are distinct locations within a VPC that act as isolated networks, which do not have access to other tiers by default. Tiers are set up on different VLANs that can communicate with each other by using a virtual router. Tiers provide inexpensive, low latency network connectivity to other tiers within the VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
Note
+ The end users can see their own VPCs, while root and domain admin can see any VPC they are authorized to see.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Add new tier dialog is displayed, as follows:
+
+ If you have already created tiers, the VPC diagram is displayed. Click Create Tier to add a new tier.
+
+ Specify the following:
+
+ All the fields are mandatory.
+
+ Name: A unique name for the tier you create.
+
+ Network Offering: The following default network offerings are listed: DefaultIsolatedNetworkOfferingForVpcNetworksNoLB, DefaultIsolatedNetworkOfferingForVpcNetworks
+
+ In a VPC, only one tier can be created by using LB-enabled network offering.
+
+ Gateway: The gateway for the tier you create. Ensure that the gateway is within the Super CIDR range that you specified while creating the VPC, and is not overlapped with the CIDR of any existing tier within the VPC.
+
+ Netmask: The netmask for the tier you create.
+
+ For example, if the VPC CIDR is 10.0.0.0/16 and the network tier CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the netmask of the tier is 255.255.255.0.
+
+ Click OK.
+
+ Continue with configuring access control list for the tier.
+
15.19.4. Configuring Access Control List
+ Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service is supported.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Network ACLs.
+
+ The Network ACLs page is displayed.
+
+ Click Add Network ACLs.
+
+ To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed in this tier.
+
+ CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or to the IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Protocol: The networking protocol that sources use to send traffic to the tier. The TCP and UDP protocols are typically used for data exchange and end-user communications. The ICMP protocol is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ Select Tier: Select the tier for which you want to add this ACL rule.
+
+ ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
+
+ Traffic Type: Select the traffic type you want to apply.
+
+ Egress: To add an egress rule, select Egress from the Traffic type drop-down box and click Add. This specifies what type of traffic is allowed to be sent out of VM instances in this tier. If no egress rules are specified, all traffic from the tier is allowed out at the VPC virtual router. Once egress rules are specified, only the traffic specified in egress rules and the responses to any traffic that has been allowed in through an ingress rule are allowed out. No egress rule is required for the VMs in a tier to communicate with each other.
+
+ Ingress: To add an ingress rule, select Ingress from the Traffic type drop-down box and click Add. This specifies what network traffic is allowed into the VM instances in this tier. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
Note
+ By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, create a new network ACL.
+
+ Click Add. The ACL rule is added.
+
+ To view the list of ACL rules you have added, click the desired tier from the Network ACLs page, then select the Network ACL tab.
+
+ You can edit the tags assigned to the ACL rules and delete the ACL rules you have created. Click the appropriate button in the Actions column.
+
15.19.5. Adding a Private Gateway to a VPC
+ A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. No gateways with duplicated VLAN and IP are allowed in the same data center.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Private Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Private Gateways.
+
+ The Gateways page is displayed.
+
+ Click Add new gateway:
+
+ Specify the following:
+
+ Physical Network: The physical network you have created in the zone.
+
+ IP Address: The IP address associated with the VPC gateway.
+
+ Gateway: The gateway through which the traffic is routed to and from the VPC.
+
+ Netmask: The netmask associated with the VPC gateway.
+
+ VLAN: The VLAN associated with the VPC gateway.
+
+ The new gateway appears in the list. You can repeat these steps to add more gateway for this VPC.
+
15.19.6. Deploying VMs to the Tier
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed.
+
+ Click the Add VM button of the tier for which you want to add a VM.
+
+ The Add Instance page is displayed.
+
+ Follow the on-screen instruction to add an instance. For information on adding an instance, see Adding Instances section in the Installation Guide.
+
15.19.7. Acquiring a New IP Address for a VPC
+ When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks within the VPC. The IPs are associated to the guest network only when the first port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP can't be associated to more than one network at a time.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding, load balancing, and static NAT rules.
+
15.19.8. Releasing an IP Address Alloted to a VPC
+ The IP address is a limited resource. If you no longer need a particular IP, you can disassociate it from its VPC and return it to the pool of available addresses. An IP address can be released from its tier, only when all the networking ( port forwarding, load balancing, or StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC whose IP you want to release.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to release.
+
+ In the Details tab, click the Release IP button
+
+
15.19.9. Enabling or Disabling Static NAT on a VPC
+ A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to allow Internet traffic to it. This section tells how to enable or disable static NAT for a particular IP address in a VPC.
+
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP you want to work with.
+
+ In the Details tab,click the Static NAT button.
+
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+
+ If you are enabling static NAT, a dialog appears as follows:
+
+ Select the tier and the destination VM, then click Apply.
+
15.19.10. Adding Load Balancing Rules on a VPC
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Load Balancing node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
Note
+ In a VPC, the load balancing service is supported only on a single tier.
+
+ Specify the following:
+
+ Name: A name for the load balancer rule.
+
+ Public Port: The port that receives the incoming traffic to be balanced.
+
+ Private Port: The port that the VMs will use to receive the traffic.
+
+ Algorithm. Choose the load balancing algorithm you want CloudStack to use. CloudStack supports the following well-known algorithms:
+
+ Round-robin
+
+ Least connections
+
+ Source
+
+ Stickiness. (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
+
+ Add VMs: Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.
+
+ The new load balancing rule appears in the list. You can repeat these steps to add more load balancing rules for this IP address.
+
15.19.11. Adding a Port Forwarding Rule on a VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Choose an existing IP address or acquire a new IP address. Click the name of the IP address in the list.
+
+ The IP Addresses page is displayed.
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+ In the Port Forwarding node of the diagram, click View All.
+
+ Select the tier to which you want to apply the rule.
+
+ Specify the following:
+
+ Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+
+ Private Port: The port on which the instance is listening for forwarded public traffic.
+
+ Protocol: The communication protocol in use between the two ports.
+
+ TCP
+
+ UDP
+
+ Add VM: Click Add VM. Select the name of the instance to which this rule applies, and click Apply.
+
+ You can test the rule by opening an ssh session to the instance.
+
15.19.12. Removing Tiers
+ You can remove a tier from a VPC. A removed tier cannot be revoked. When a tier is removed, only the resources of the tier are expunged. All the network rules (port forwarding, load balancing and staticNAT) and the IP addresses associated to the tier are removed. The IP address still be belonging to the same VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Configure VPC page is displayed. Locate the tier you want to work with.
+
+ Click the Remove VPC button:
+
+ Wait for some time for the tier to be removed.
+
15.19.13. Editing, Restarting, and Removing a Virtual Private Cloud
Note
+ Ensure that all the tiers are removed before you remove a VPC.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Select the VPC you want to work with.
+
+ To remove, click the Remove VPC button
+
+
+ You can edit the name and description of a VPC. To do that, select the VPC, then click the Edit button.
+
+
+ To restart a VPC, select the VPC, then click the Restart button.
+
+
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+
+ Before CloudPlatform users start using projects, the CloudPlatform administrator must set up various systems to support them, including membership invitations, limits on project resources, and controls on who can create projects.
+
6.2.1. 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.
+
+ In the search box, type project and click the search button.
+
+
+ In the search results, you will 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
+
service cloud-management restart
6.2.2. 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
+
6.2.2.1. 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”). 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.
+
6.2.2.2. 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.
+
+
+
+ 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.
+
# service cloud-management restart
6.2.3. 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.
+
+
+
+ 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.
+
+ The Console Proxy is a type of System Virtual Machine that has a role in presenting a console view via the web UI. It connects the user’s browser to the VNC port made available via the hypervisor for the console of the guest. Both the administrator and end user web UIs offer a console connection.
+
+ Clicking on a console icon brings up a new window. The AJAX code downloaded into that window refers to the public IP address of a console proxy VM. There is exactly one public IP address allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then proxies the connection to the VNC port for the requested VM on the Host hosting the guest. .
+
Note
+ The hypervisors will have many ports assigned to VNC usage so that multiple VNC sessions can occur simultaneously.
+
+ There is never any traffic to the guest virtual IP, and there is no need to enable VNC within the guest.
+
+ The console proxy VM will periodically report its active session count to the Management Server. The default reporting interval is five seconds. This can be changed through standard Management Server configuration with the parameter consoleproxy.loadscan.interval.
+
+ Assignment of guest VM to console proxy is determined by first determining if the guest VM has a previous session associated with a console proxy. If it does, the Management Server will assign the guest VM to the target Console Proxy VM regardless of the load on the proxy VM. Failing that, the first available running Console Proxy VM that has the capacity to handle new sessions is used.
+
+ Console proxies can be restarted by administrators but this will interrupt existing console sessions for users.
+
+ The console viewing functionality uses a dynamic DNS service under the domain name realhostip.com to assist in providing SSL security to console sessions. The console proxy is assigned a public IP address. In order to avoid browser warnings for mismatched SSL certificates, the URL for the new console window is set to the form of https://aaa-bbb-ccc-ddd.realhostip.com. Customers will see this URL during console session creation. CloudStack includes the realhostip.com SSL certificate in the console proxy VM. Of course, CloudStack cannot know about DNS A records for our customers' public IPs prior to shipping the software. CloudStack therefore runs a dynamic DNS server that is authoritative for the realhostip.com domain. It maps the aaa-bbb-ccc-ddd part of the DNS name to the IP address aaa.bbb.ccc.ddd on lookups. This allows the browser to correctly connect to the console proxy's public IP, where it then expects and receives a SSL certificate for realhostip.com, and SSL is set up without browser warnings.
+
diff --git a/docs/tmp/en-US/html/convert-hyperv-vm-to-template.html b/docs/tmp/en-US/html/convert-hyperv-vm-to-template.html
new file mode 100644
index 00000000000..6afcc879c15
--- /dev/null
+++ b/docs/tmp/en-US/html/convert-hyperv-vm-to-template.html
@@ -0,0 +1,61 @@
+
+
+12.12. Converting a Hyper-V VM to a Template
+ To convert a Hyper-V VM to a XenServer-compatible CloudStack template, you will need a standalone XenServer host with an attached NFS VHD SR. Use whatever XenServer version you are using with CloudStack, but use XenCenter 5.6 FP1 or SP2 (it is backwards compatible to 5.6). Additionally, it may help to have an attached NFS ISO SR.
+
+ For Linux VMs, you may need to do some preparation in Hyper-V before trying to get the VM to work in XenServer. Clone the VM and work on the clone if you still want to use the VM in Hyper-V. Uninstall Hyper-V Integration Components and check for any references to device names in /etc/fstab:
+
+ From the linux_ic/drivers/dist directory, run make uninstall (where "linux_ic" is the path to the copied Hyper-V Integration Components files).
+
+ Restore the original initrd from backup in /boot/ (the backup is named *.backup0).
+
+ Remove the "hdX=noprobe" entries from /boot/grub/menu.lst.
+
+ Check /etc/fstab for any partitions mounted by device name. Change those entries (if any) to mount by LABEL or UUID (get that information with the "blkid" command)..
+
+ The next step is make sure the VM is not running in Hyper-V, then get the VHD into XenServer. There are two options for doing this.
+
+ Option one:
+
+ Import the VHD using XenCenter. In XenCenter, go to Tools>Virtual Appliance Tools>Disk Image Import.
+
+ Choose the VHD, then click Next.
+
+ Name the VM, choose the NFS VHD SR under Storage, enable "Run Operating System Fixups" and choose the NFS ISO SR.
+
+ Click Next, then Finish. A VM should be created.
+
+ Option two
+
+ Run XenConvert, under From choose VHD, under To choose XenServer. Click Next.
+
+ Choose the VHD, then click Next.
+
+ Input the XenServer host info, then click Next.
+
+ Name the VM, then click Next, then Convert. A VM should be created
+
+ Once you have a VM created from the Hyper-V VHD, prepare it using the following steps:
+
+ Boot the VM, uninstall Hyper-V Integration Services, and reboot.
+
+ Either option above will create a VM in HVM mode. This is fine for Windows VMs, but Linux VMs may not perform optimally. Converting a Linux VM to PV mode will require additional steps and will vary by distribution.
+
+ Shut down the VM and copy the VHD from the NFS storage to a web server; for example, mount the NFS share on the web server and copy it, or from the XenServer host use sftp or scp to upload it to the web server.
+
+ In CloudStack, create a new template using the following values:
+
+ URL. Give the URL for the VHD
+
+ OS Type. Use the appropriate OS. For PV mode on CentOS, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServer.
+
+ Hypervisor. XenServer
+
+ Format. VHD
+
+ The template will be created, and you can create instances from it.
+
+ 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.
+
+ Make any desired configuration changes on the running VM, then click Stop.
+
+ Wait for the VM to stop. When the status shows Stopped, go to the next step.
+
+ Click Create Template and provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ OS Type. This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
+ If you want to boot from this template in PV mode, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServere:
+
Note
+ Note: Generally you should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates.
+
+ Click Add.
+
+ The new template will be visible in the Templates section when the template creation process has been completed. The template is then available when creating a new VM
+
+ CloudStack ships with a default template for the CentOS operating system. There are a variety of ways to add more templates. Administrators and end users can add templates. The typical sequence of events is:
+
+ Launch a VM instance that has the operating system you want. Make any other desired configuration changes to the VM.
+
+ Stop the VM.
+
+ Convert the volume into a template.
+
+ There are other ways to add templates to CloudStack. For example, you can take a snapshot of the VM's volume and create a template from the snapshot, or import a VHD from another system into CloudStack
+
+ The various techniques for creating templates are described in the next few sections.
+
+ Windows templates must be prepared with Sysprep before they can be provisioned on multiple machines. Sysprep allows you to create a generic Windows template and avoid any possible SID conflicts.
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Follow the steps in Sysprep for Windows Server 2008 R2 (below) or Sysprep for Windows Server 2003 R2, depending on your version of Windows Server
+
+ The preparation steps are complete. Now you can actually create the template as described in Creating the Windows Template.
+
12.10.1. System Preparation for Windows Server 2008 R2
+ For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location:
+
+ Windows AIK should not be installed on the Windows 2008 R2 VM you just created. Windows AIK should not be part of the template you create. It is only used to create the sysprep answer file.
+
+ Copy the install.wim file in the \sources directory of the Windows 2008 R2 installation DVD to the hard disk. This is a very large file and may take a long time to copy. Windows AIK requires the WIM file to be writable.
+
+ Start the Windows System Image Manager, which is part of the Windows AIK.
+
+ In the Windows Image pane, right click “Select a Windows image or catalog file” to load the install.wim file you just copied.
+
+ Select the Windows 2008 R2 Edition
+
+ You may be prompted with a warning that the catalog file cannot be opened. Click Yes to create a new catalog file.
+
+ In the Answer File pane, right click to create a new answer file.
+
+ Generate the answer file from the Windows System Image Manager using the following steps:
+
+ The first page you need to automate is the Language and Country or Region Selection page. To automate this, expand Components in your Windows Image pane, right-click and add the Microsoft-Windows-International-Core setting to Pass 7 oobeSystem. In your Answer File pane, configure the InputLocale, SystemLocale, UILanguage, and UserLocale with the appropriate settings for your language and country or region. Should you have a question about any of these settings, you can right-click on the specific setting and select Help. This will open the appropriate CHM help file with more information, including examples on the setting you are attempting to configure.
+
+ You need to automate the Software License Terms Selection page, otherwise known as the End-User License Agreement (EULA). To do this, expand the Microsoft-Windows-Shell-Setup component. High-light the OOBE setting, and add the setting to the Pass 7 oobeSystem. In Settings, set HideEULAPage true.
+
+ Make sure the license key is properly set. If you use MAK key, you can just enter the MAK key on the Windows 2008 R2 VM. You need not input the MAK into the Windows System Image Manager. If you use KMS host for activation you need not enter the Product Key. Details of Windows Volume Activation can be found at http://technet.microsoft.com/en-us/library/bb892849.aspx
+
+ You need to automate is the Change Administrator Password page. Expand the Microsoft-Windows-Shell-Setup component (if it is not still expanded), expand UserAccounts, right-click on AdministratorPassword, and add the setting to the Pass 7 oobeSystem configuration pass of your answer file. Under Settings, specify a password next to Value.
+
+ You may read the AIK documentation and set many more options that suit your deployment. The steps above are the minimum needed to make Windows unattended setup work.
+
+ Save the answer file as unattend.xml. You can ignore the warning messages that appear in the validation window.
+
+ Copy the unattend.xml file into the c:\windows\system32\sysprep directory of the Windows 2008 R2 Virtual Machine
+
+ Once you place the unattend.xml file in c:\windows\system32\sysprep directory, you run the sysprep tool as follows:
+
cd c:\Windows\System32\sysprep
+sysprep.exe /oobe /generalize /shutdown
+
+ The Windows 2008 R2 VM will automatically shut down after sysprep is complete.
+
12.10.2. Sysprep for Windows Server 2003 R2
+ Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2.
+
+ Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM.
+
+ Run c:\sysprep\setupmgr.exe to create the sysprep.inf file.
+
+ Select Create New to create a new Answer File.
+
+ Enter “Sysprep setup” for the Type of Setup.
+
+ Select the appropriate OS version and edition.
+
+ On the License Agreement screen, select “Yes fully automate the installation”.
+
+ Provide your name and organization.
+
+ Leave display settings at default.
+
+ Set the appropriate time zone.
+
+ Provide your product key.
+
+ Select an appropriate license mode for your deployment
+
+ Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up.
+
+ Leave Network Components at “Typical Settings”.
+
+ Select the “WORKGROUP” option.
+
+ Leave Telephony options at default.
+
+ Select appropriate Regional Settings.
+
+ Select appropriate language settings.
+
+ Do not install printers.
+
+ Do not specify “Run Once commands”.
+
+ You need not specify an identification string.
+
+ Save the Answer File as c:\sysprep\sysprep.inf.
+
+ Run the following command to sysprep the image:
+
c:\sysprep\sysprep.exe -reseal -mini -activated
+ After this step the machine will automatically shut down
+
+ Virtual machines are usually created from a template. Users can also create blank virtual machines. A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and install the OS from the CD/DVD-ROM.
+
+ To create a VM from a template:
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select a template, then follow the steps in the wizard. (For more information about how the templates came to be in this list, see Working with Templates.
+
+ Be sure that the hardware you have allows starting the selected service offering.
+
+ Click Submit and your VM will be created and started.
+
Note
+ For security reason, the internal name of the VM is visible only to the root admin.
+
Note
+ Starting with v3.0.3, you can create a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A new request parameter, startVM, is introduced in the deployVm API to support this feature. For more information, see the Developer's Guide
+
+ To create a VM from an ISO:
+
Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Log in to the CloudStack UI as an administrator or user.
+
+ In the left navigation bar, click Instances.
+
+ Click Add Instance.
+
+ Select ISO Boot, and follow the steps in the wizard.
+
+ Click Submit and your VM will be created and started.
+
+ 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” 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.
+
+ Usage records include a start date and an end date. These dates define the period of time for which the raw usage number was calculated. If daily aggregation is used, the start date is midnight on the day in question and the end date is 23:59:59 on the day in question (with one exception; see below). A virtual machine could have been deployed at noon on that day, stopped at 6pm on that day, then started up again at 11pm. When usage is calculated on that day, there will be 7 hours of running VM usage (usage type 1) and 12 hours of allocated VM usage (usage type 2). If the same virtual machine runs for the entire next day, there will 24 hours of both running VM usage (type 1) and allocated VM usage (type 2).
+
+ Note: The start date is not the time a virtual machine was started, and the end date is not the time when a virtual machine was stopped. The start and end dates give the time range within which usage was calculated.
+
+ For network usage, the start date and end date again define the range in which the number of bytes transferred was calculated. If a user downloads 10 MB and uploads 1 MB in one day, there will be two records, one showing the 10 megabytes received and one showing the 1 megabyte sent.
+
+ There is one case where the start date and end date do not correspond to midnight and 11:59:59pm when daily aggregation is used. This occurs only for network usage records. When the usage server has more than one day's worth of unprocessed data, the old data will be included in the aggregation period. The start date in the usage record will show the date and time of the earliest event. For other types of usage, such as IP addresses and VMs, the old unprocessed data is not included in daily aggregation.
+
+ You can limit resource use by accounts. The default limits are set using global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account (max.account.snapshots, etc.)..
+
+ To override a default limit for a particular account, set a per-account resource limit.
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Accounts.
+
+ Select the account you want to modify. The current limits are displayed. A value of -1 shows that there is no limit in place
+
+ CloudStack includes a CentOS template. This template is downloaded by the Secondary Storage VM after the primary and secondary storage are configured. You can use this template in your production deployment or you can delete it and use custom templates.
+
+ The root password for the default template is "password".
+
+ A default template is provided for each of XenServer, KVM, and vSphere. The templates that are downloaded depend on the hypervisor type that is available in your cloud. Each template is approximately 2.5 GB physical size.
+
+ The default template includes the standard iptables rules, which will block most access to the template excluding ssh.
+
+ Templates may be deleted. In general, when a template spans multiple Zones, only the copy that is selected for deletion will be deleted; the same template in other Zones will not be deleted. The provided CentOS template is an exception to this. If the provided CentOS template is deleted, it will be deleted from all Zones.
+
+ When templates are deleted, the VMs instantiated from them will continue to run. However, new VMs cannot be created based on the deleted template.
+
+ Users can delete their own virtual machines. A running virtual machine will be abruptly stopped before it is deleted. Administrators can delete any virtual machines.
+
+ To delete a virtual machine:
+
+ Log in to the CloudStack UI as a user or admin.
+
+ A CloudStack installation consists of two parts: the Management Server and the cloud infrastructure that it manages. When you set up and manage a CloudStack cloud, you provision resources such as hosts, storage devices, and IP addresses into the Management Server, and the Management Server manages those resources.
+
+ The minimum production installation consists of one machine running the CloudStack Management Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure consisting of one host running hypervisor software). In its smallest deployment, a single machine can act as both the Management Server and the hypervisor host (using the KVM hypervisor).
+
+ A more full-featured installation consists of a highly-available multi-node Management Server installation and up to tens of thousands of hosts using any of several advanced networking setups. For information about deployment options, see Choosing a Deployment Architecture.
+
1.3.1. Management Server Overview
+ The Management Server is the CloudStack software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+ The machine must meet the system requirements described in System Requirements.
+
+ The Management Server:
+
+ Provides the web user interface for the administrator and a reference user interface for end users.
+
+ Provides the APIs for CloudStack.
+
+ Manages the assignment of guest VMs to particular hosts.
+
+ Manages the assignment of public and private IP addresses to particular accounts.
+
+ Manages the allocation of storage to guests as virtual disks.
+
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+
+ Provides a single point of configuration for the cloud.
+
1.3.2. Cloud Infrastructure Overview
+ The Management Server manages one or more zones (typically, datacenters) containing host computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
+
+ Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
+
+ Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
+
+ Cluster: A cluster consists of one or more hosts and primary storage.
+
+ Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines.
+
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster.
+
+ Secondary storage is associated with a zone, and it stores templates, ISO images, and disk volume snapshots.
+
+ More Information
+
+ For more information, see documentation on cloud infrastructure concepts.
+
1.3.3. Networking Overview
+ CloudStack offers two types of networking scenario:
+
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
11.3. 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.
+
+
+
+ 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.
+
+ You can set an expiry timestamp on API calls to prevent replay attacks over non-secure channels, such as HTTP. The server tracks the expiry timestamp you have specified and rejects all the subsequent API requests that come in after this validity period.
+
+ To enable this feature, add the following parameters to the API request:
+
+ signatureVersion=3: If the signatureVersion parameter is missing or is not equal to 3, the expires parameter is ignored in the API request.
+
+ expires=YYYY-MM-DDThh:mm:ssZ: Specifies the date and time at which the signature included in the request is expired. The timestamp is expressed in the YYYY-MM-DDThh:mm:ssZ format, as specified in the ISO 8601 standard.
+
+ For example:
+
expires=2011-10-10T12:00:00+0530
+ A sample API request with expiration is given below:
+
+ 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..
+
22.1.2. 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
+
22.1.3. 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
+
22.1.4. 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
+
+ All CloudStack API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+
+ End users and Administrators may export templates from the CloudStack. Navigate to the template in the UI and choose the Download function from the Actions menu.
+
+ CloudStack is capable of replacing its Virtual Router with an external Juniper SRX device and an optional external NetScaler or F5 load balancer for gateway and load balancing services. In this case, the VMs use the SRX as their gateway.
+
+ CloudStack works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of CloudStack supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+ Massively Scalable Infrastructure Management
+
+ CloudStack can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+ Automatic Configuration Management
+
+ CloudStack automatically configures each guest virtual machine’s networking and storage settings.
+
+ CloudStack internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+ Graphical User Interface
+
+ CloudStack offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+ API and Extensibility
+
+ CloudStack provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at Apache CloudStack Guides and Apache CloudStack API Reference respectively.
+
+ CloudStack has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the hosts, CloudStack supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+
Chapter 19. Setting Global Configuration Parameters
+ CloudStack provides parameters that you can set to control many aspects of the cloud. When CloudStack is first installed, and periodically thereafter, you might need to modify these settings.
+
+ Log in to the UI as administrator.
+
+ In the left navigation bar, click Global Settings.
+
+ In Select View, choose one of the following:
+
+ Global Settings. This displays a list of the parameters with brief descriptions and current values.
+
+ Hypervisor Capabilities. This displays a list of hypervisor versions with the maximum number of guests supported for each.
+
+ Use the search box to narrow down the list to those you are interested in.
+
+ Click the Edit icon to modify a value. If you are viewing Hypervisor Capabilities, you must click the name of the hypervisor first to display the editing screen.
+
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+
+ The following table lists limits set in the Global Configuration:
+
+
+ Parameter Name
+
+
+
+ Definition
+
+
+
+ max.account.public.ips
+
+
+
+ Number of public IP addresses that can be owned by an account
+
+
+
+ max.account.snapshots
+
+
+
+ Number of snapshots that can exist for an account
+
+
+
+ max.account.templates
+
+
+
+ Number of templates that can exist for an account
+
+
+
+ max.account.user.vms
+
+
+
+ Number of virtual machine instances that can exist for an account
+
+
+
+ max.account.volumes
+
+
+
+ Number of disk volumes that can exist for an account
+
+
+
+ max.template.iso.size
+
+
+
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+ max.volume.size.gb
+
+
+
+ Maximum size for a volume in GB
+
+
+
+ network.throttling.rate
+
+
+
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+
+ snapshot.max.hourly
+
+
+
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+ snapshot.max.daily
+
+
+
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+
+ snapshot.max.weekly
+
+
+
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+ snapshot.max.monthly
+
+
+
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+ To modify global configuration parameters, use the global configuration screen in the CloudStack UI. See Setting Global Configuration Parameters
+
+ The IP ranges for guest network traffic are set on a per-account basis by the user. This allows the users to configure their network in a fashion that will enable VPN linking between their guest network and their clients.
+
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+
+ Figure 1 illustrates a typical guest traffic setup:
+
+ The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+
+ The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
+
+ Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
+
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
diff --git a/docs/tmp/en-US/html/ha-management-server.html b/docs/tmp/en-US/html/ha-management-server.html
new file mode 100644
index 00000000000..123339274ef
--- /dev/null
+++ b/docs/tmp/en-US/html/ha-management-server.html
@@ -0,0 +1,9 @@
+
+
+17.1. HA for Management Server
+ The CloudStack Management Server should be deployed in a multi-node configuration such that it is not susceptible to individual server failures. The Management Server itself (as distinct from the MySQL database) is stateless and may be placed behind a load balancer.
+
+ Normal operation of Hosts is not impacted by an outage of all Management Serves. All guest VMs will continue to work.
+
+ When the Management Server is down, no new VMs can be created, and the end user and admin UI, API, dynamic load distribution, and HA will cease to work.
+
+ 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.
+
+ 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/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+
+ Run the script:
+
# ./cloud-setup-bonding.sh
7.5.1.1.2. 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.
+
7.5.1.2. 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 delay while the host is provisioned. It should automatically display in the UI.
+
+ Repeat for additional hosts.
+
7.5.2. Adding a Host (vSphere)
+ For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the entire cluster to CloudStack. See Add Cluster: vSphere.
+
+ The system automatically picks the most appropriate host to run each virtual machine. End users may specify the zone in which the virtual machine will be created. End users do not have control over which host will run the virtual machine instance.
+
+ CloudStack administrators can specify that certain hosts should have a preference for particular types of guest instances. For example, an administrator could state that a host should have a preference to run Windows guests. The default host allocator will attempt to place guests of that OS type on such hosts first. If no such host is available, the allocator will place the instance wherever there is sufficient physical capacity.
+
+ Both vertical and horizontal allocation is allowed. Vertical allocation consumes all the resources of a given host before allocating any guests on a second host. This reduces power consumption in the cloud. Horizontal allocation places a guest on each host in a round-robin fashion. This may yield better performance to the guests in some cases. CloudStack also allows an element of CPU over-provisioning as configured by the administrator. Over-provisioning allows the administrator to commit more CPU cycles to the allocated guests than are actually available from the hardware.
+
+ CloudStack also provides a pluggable interface for adding new allocators. These custom allocators can provide any policy the administrator desires.
+
8.1.1. System Requirements for KVM Hypervisor Hosts
+ KVM is included with a variety of Linux-based operating systems. Although you are not required to run these distributions, the following are recommended:
+
+ CentOS / RHEL: 6.3
+
+ Ubuntu: 12.04(.1)
+
+ The main requirement for KVM hypervisors is the libvirt and Qemu version. No matter what Linux distribution you are using, make sure the following requirements are met:
+
+ libvirt: 0.9.4 or higher
+
+ Qemu/KVM: 1.0 or higher
+
+ In addition, the following hardware requirements apply:
+
+ Within a single cluster, the hosts must be of the same distribution version.
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+ Must support HVM (Intel-VT or AMD-V enabled)
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ 4 GB of memory
+
+ At least 1 NIC
+
+ When you deploy CloudStack, the hypervisor host must not have any VMs already running
+
8.1.2. KVM Installation Overview
+ If you want to use the Linux Kernel Virtual Machine (KVM) hypervisor to run guest virtual machines, install KVM on the host(s) in your cloud. The material in this section doesn't duplicate KVM installation docs. It provides the CloudStack-specific steps that are needed to prepare a KVM host to work with CloudStack.
+
Warning
+ Before continuing, make sure that you have applied the latest updates to your host.
+
Warning
+ It is NOT recommended to run services on this host not controlled by CloudStack.
+
+ The procedure for installing a KVM Hypervisor Host is:
+
+ Prepare the Operating System
+
+ Install and configure libvirt
+
+ Configure Security Policies (AppArmor and SELinux)
+
+ Install and configure the Agent
+
8.1.3. Prepare the Operating System
+ The OS of the Host must be prepared to host the CloudStack Agent and run KVM instances.
+
+ Log in to your OS as root.
+
+ Check for a fully qualified hostname.
+
$ hostname --fqdn
+ This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+ Make sure that the machine can reach the Internet.
+
$ ping www.cloudstack.org
+ Turn on NTP for time synchronization.
+
Note
+ NTP is required to synchronize the clocks of the servers in your cloud. Unsynchronized clocks can cause unexpected problems.
+
+ Install NTP
+
$ yum install ntp
$ apt-get install openntpd
+ Repeat all of these steps on every hypervisor host.
+
8.1.4. Install and configure the Agent
+ To manage KVM instances on the host CloudStack uses a Agent. This Agent communicates with the Management server and controls all the instances on the host.
+
+ First we start by installing the agent:
+
+ In RHEL or CentOS:
+
$ yum install cloud-agent
+ In Ubuntu:
+
$ apt-get install cloud-agent
+ The host is now ready to be added to a cluster. This is covered in a later section, see Section 6.5, “Adding a Host”. It is recommended that you continue to read the documentation before adding the host!
+
8.1.5. Install and Configure libvirt
+ CloudStack uses libvirt for managing virtual machines. Therefore it is vital that libvirt is configured correctly. Libvirt is a dependency of cloud-agent and should already be installed.
+
+ In order to have live migration working libvirt has to listen for unsecured TCP connections. We also need to turn off libvirts attempt to use Multicast DNS advertising. Both of these settings are in /etc/libvirt/libvirtd.conf
+
+ Set the following paramaters:
+
listen_tls = 0
listen_tcp = 1
tcp_port = 16059
auth_tcp = "none"
mdns_adv = 0
+ Turning on "listen_tcp" in libvirtd.conf is not enough, we have to change the parameters as well:
+
+ On RHEL or CentOS modify /etc/sysconfig/libvirtd:
+
+ Uncomment the following line:
+
#LIBVIRTD_ARGS="--listen"
+ On Ubuntu: modify /etc/init/libvirt-bin.conf
+
+ Change the following line (at the end of the file):
+
exec /usr/sbin/libvirtd -d
+ to (just add -l)
+
exec /usr/sbin/libvirtd -d -l
+ Restart libvirt
+
+ In RHEL or CentOS:
+
$ service libvirtd restart
+ In Ubuntu:
+
$ service libvirt-bin restart
8.1.6. Configure the Security Policies
+ CloudStack does various things which can be blocked by security mechanisms like AppArmor and SELinux. These have to be disabled to ensure the Agent has all the required permissions.
+
+ Configure SELinux (RHEL and CentOS)
+
+ Check to see whether SELinux is installed on your machine. If not, you can skip this section.
+
+ In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
+
$ rpm -qa |grep selinux
+ Set the SELINUX variable in /etc/selinux/config to "permissive". This ensures that the permissive setting will be maintained after a system reboot.
+
+ In RHEL or CentOS:
+
vi /etc/selinux/config
+ Change the following line
+
SELINUX=enforcing
+ to this
+
SELINUX=permissive
+ Then set SELinux to permissive starting immediately, without requiring a system reboot.
+
$ setenforce permissive
+ Configure Apparmor (Ubuntu)
+
+ Check to see whether AppArmor is installed on your machine. If not, you can skip this section.
+
+ In Ubuntu AppArmor is installed and enabled by default. You can verify this with:
+
+ This is a very important section, please make sure you read this thoroughly.
+
+ In order to forward traffic to your instances you will need at least two bridges: public and private.
+
+ By default these bridges are called cloudbr0 and cloudbr1, but you do have to make sure they are available on each hypervisor.
+
+ The most important factor is that you keep the configuration consistent on all your hypervisors.
+
8.1.7.1. Network example
+ There are many ways to configure your network. In the Basic networking mode you should have two (V)LAN's, one for your private network and one for the public network.
+
+ We assume that the hypervisor has one NIC (eth0) with three tagged VLAN's:
+
+ VLAN 100 for management of the hypervisor
+
+ VLAN 200 for public network of the instances (cloudbr0)
+
+ VLAN 300 for private network of the instances (cloudbr1)
+
+ On VLAN 100 we give the Hypervisor the IP-Address 192.168.42.11/24 with the gateway 192.168.42.1
+
Note
+ The Hypervisor and Management server don't have to be in the same subnet!
+
8.1.7.2. Configuring the network bridges
+ It depends on the distribution you are using how to configure these, below you'll find examples for RHEL/CentOS and Ubuntu.
+
Note
+ The goal is to have two bridges called 'cloudbr0' and 'cloudbr1' after this section. This should be used as a guideline only. The exact configuration will depend on your network layout.
+
8.1.7.2.1. Configure in RHEL or CentOS
+ The required packages were installed when libvirt was installed, we can proceed to configuring the network.
+
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+
Warning
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+
8.1.7.2.2. Configure in Ubuntu
+ All the required packages were installed when you installed libvirt, so we only have to configure the network.
+
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+
Warning
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+
8.1.8. Configuring the firewall
+ The hypervisor needs to be able to communicate with other hypervisors and the management server needs to be able to reach the hypervisor.
+
+ In order to do so we have to open the following TCP ports (if you are using a firewall):
+
+ 22 (SSH)
+
+ 1798
+
+ 16509 (libvirt)
+
+ 5900 - 6100 (VNC consoles)
+
+ 49152 - 49216 (libvirt live migration)
+
+ It depends on the firewall you are using how to open these ports. Below you'll find examples how to open these ports in RHEL/CentOS and Ubuntu.
+
8.1.8.1. Open ports in RHEL/CentOS
+ RHEL and CentOS use iptables for firewalling the system, you can open extra ports by executing the following iptable commands:
+
+ These iptable settings are not persistent accross reboots, we have to save them first.
+
$ iptables-save > /etc/sysconfig/iptables
8.1.8.2. Open ports in Ubuntu
+ The default firewall under Ubuntu is UFW (Uncomplicated FireWall), which is a Python wrapper around iptables.
+
+ To open the required ports, execute the following commands:
+
$ ufw allow proto tcp from any to any port 22
$ ufw allow proto tcp from any to any port 1798
$ ufw allow proto tcp from any to any port 16509
$ ufw allow proto tcp from any to any port 5900:6100
$ ufw allow proto tcp from any to any port 49152:49216
Note
+ By default UFW is not enabled on Ubuntu. Executing these commands with the firewall disabled does not enable the firewall.
+
8.1.9. Add the host to CloudStack
+ The host is now ready to be added to a cluster. This is covered in a later section, see Section 6.5, “Adding a Host”. It is recommended that you continue to read the documentation before adding the host!
+
+ The following procedures describe how to import an Amazon Machine Image (AMI) into CloudStack when using the XenServer hypervisor.
+
+ Assume you have an AMI file and this file is called CentOS_6.2_x64. Assume further that you are working on a CentOS host. If the AMI is a Fedora image, you need to be working on a Fedora host initially.
+
+ You need to have a XenServer host with a file-based storage repository (either a local ext3 SR or an NFS SR) to convert to a VHD once the image file has been customized on the Centos/Fedora host.
+
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.
+
+ Determine the name of the PV kernel that has been installed into the image.
+
# cd /mnt/loop/centos62
+# ls lib/modules/
+2.6.16.33-xenU 2.6.16-xenU 2.6.18-164.15.1.el5xen 2.6.18-164.6.1.el5.centos.plus 2.6.18-xenU-ec2-v1.0 2.6.21.7-2.fc8xen 2.6.31-302-ec2
+# ls boot/initrd*
+boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
+# ls boot/vmlinuz*
+boot/vmlinuz-2.6.18-164.15.1.el5xen boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus boot/vmlinuz-2.6.18-xenU-ec2-v1.0 boot/vmlinuz-2.6.21-2952.fc8xen
+
+ Xen kernels/ramdisk always end with "xen". For the kernel version you choose, there has to be an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.
+
+ Based on your findings, create an entry in the grub.conf file. Below is an example entry.
+
+ Enable login via the console. The default console device in a XenServer system is xvc0. Ensure that etc/inittab and etc/securetty have the following lines respectively:
+
+ Copy the image file to your XenServer host's file-based storage repository. In the example below, the Xenserver is "xenhost". This XenServer has an NFS repository whose uuid is a9c5b8c8-536b-a193-a6dc-51af3e5ff799.
+
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
Abstract
+ Release notes for the Apache CloudStack 4.0.0-incubating release.
+
+ After everything is configured, CloudStack will perform its initialization. This can take 30 minutes or more, depending on the speed of your network. When the initialization has completed successfully, the administrator's Dashboard should be displayed in the CloudStack UI.
+
+ Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS 5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do not proceed to the next step until this status is displayed.
+
+ Go to the Instances tab, and filter by My Instances.
+
+ Click Add Instance and follow the steps in the wizard.
+
+ Choose the zone you just added.
+
+ In the template selection, choose the template to use in the VM. If this is a fresh installation, likely only the provided CentOS template is available.
+
+ Select a service offering. Be sure that the hardware you have allows starting the selected service offering.
+
+ In data disk offering, if desired, add another data disk. This is a second volume that will be available to but not mounted in the guest. For example, in Linux on XenServer you will see /dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PV-enabled OS kernel in use.
+
+ In default network, choose the primary network for the guest. In a trial installation, you would have only one option here.
+
+ Optionally give your VM a name and a group. Use any descriptive text you would like.
+
+ Click Launch VM. Your VM will be created and started. It might take some time to download the template and complete the VM startup. You can watch the VM’s progress in the Instances screen.
+
+ To use the VM, click the View Console button.
+
+
+
+ Congratulations! You have successfully completed a CloudStack Installation.
+
+ If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
+
+ For anything more than a simple trial installation, you will need guidance for a variety of configuration choices. It is strongly recommended that you read the following:
+
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You provision VLANs to the tiers your create, and VMs can be deployed on different tiers. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications, such as Web, Application, or Database. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+ The major advantages are:
+
+ The administrator can deploy a set of VLANs and allow users to deploy VMs on these VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that account.
+
Note
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+
+ The administrator can allow users create their own VPC and deploy the application. In this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that account.
+
+ Both administrators and users can create multiple VPCs. The guest network NIC is plugged to the VPC virtual router when the first VM is deployed in a tier.
+
+ The administrator can create the following gateways to send to or receive traffic from the VMs:
+
+ Public Gateway: The public gateway for a VPC is added to the virtual router when the virtual router is created for VPC. The public gateway is not exposed to the end users. You are not allowed to list it, nor allowed to create any static routes.
+
+ Both administrators and users can create various possible destinations-gateway combinations. However, only one gateway of each type can be used in a deployment.
+
+ For example:
+
+ VLANs and Public Gateway: For example, an application is deployed in the cloud, and the Web application VMs communicate with the Internet.
+
+ VLANs, VPN Gateway, and Public Gateway: For example, an application is deployed in the cloud; the Web application VMs communicate with the Internet; and the database VMs communicate with the on-premise devices.
+
+ The administrator can define Access Control List (ACL) on the virtual router to filter the traffic among the VLANs or between the Internet and a VLAN. You can define ACL based on CIDR, port range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress type.
+
+ The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
+
+ By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is translated via NAT to the public IP address and is allowed.
+
+ To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example, you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44. Then use port forwarding rules to direct traffic from individual ports within that range to specific ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public IP's port 33 to port 100 on one user VM's private IP.
+
+ For the steps to implement these rules, see Firewall Rules and Port Forwarding.
+
+ The user may choose to associate the same public IP for multiple guests. CloudStack implements a TCP-level load balancer with the following policies.
+
+ Round-robin
+
+ Least connection
+
+ Source IP
+
+ This is similar to port forwarding but the destination may be multiple IP addresses.
+
+ This diagram illustrates the network architecture of a large-scale CloudStack deployment.
+
+ A layer-3 switching layer is at the core of the data center. A router redundancy protocol like VRRP should be deployed. Typically high-end core switches also include firewall modules. Separate firewall appliances may also be used if the layer-3 switch does not have integrated firewall capabilities. The firewalls are configured in NAT mode. The firewalls provide the following functions:
+
+ Forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+
+ When the cloud spans multiple zones, the firewalls should enable site-to-site VPN such that servers in different zones can directly reach each other.
+
+ A layer-2 access switch layer is established for each pod. Multiple switches can be stacked to increase port count. In either case, redundant pairs of layer-2 switches should be deployed.
+
+ The Management Server cluster (including front-end load balancers, Management Server nodes, and the MySQL database) is connected to the management network through a pair of load balancers.
+
+ Secondary storage servers are connected to the management network.
+
+ Each pod contains storage and computing servers. Each storage and computing server should have redundant NICs connected to separate layer-2 access switches.
+
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudStack virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+ 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)
+
http://<management-server-ip-address>:8080/client
+ On a fresh Management Server installation, a guided tour splash screen appears. On later visits, you’ll see a login screen where you specify the following to proceed to your Dashboard:
+
Username
+ The user ID of your account. The default username is admin.
+
Password
+ The password associated with the user ID. The password for the default username is password.
+
Domain
+ If you are a root user, leave this field blank.
+
+ If you are a user in the sub-domains, enter the full path to the domain, excluding the root domain.
+
+ For example, suppose multiple levels are created under the root domain, such as Comp1/hr. The users in the Comp1 domain should enter Comp1 in the Domain field, whereas the users in the Comp1/sales domain should enter Comp1/sales.
+
+ For more guidance about the choices that appear when you log in to this UI, see Logging In as the Root Administrator.
+
5.1.1. End User's UI Overview
+ The CloudStack UI helps users of cloud infrastructure to view and use their cloud resources, including virtual machines, templates and ISOs, data volumes and snapshots, guest networks, and IP addresses. If the user is a member or administrator of one or more CloudStack projects, the UI can provide a project-oriented view.
+
5.1.2. Root Administrator's UI Overview
+ The CloudStack UI helps the CloudStack administrator provision, view, and manage the cloud infrastructure, domains, user accounts, projects, and configuration settings. The first time you start the UI after a fresh Management Server installation, you can choose to follow a guided tour to provision your cloud infrastructure. On subsequent logins, the dashboard of the logged-in user appears. The various links in this screen and the navigation bar on the left provide access to a variety of administrative functions. The root administrator can also use the UI to perform all the same tasks that are present in the end-user’s UI.
+
5.1.3. Logging In as the Root Administrator
+ After the Management Server software is installed and running, you can run the CloudStack user interface. This UI is there to help you provision, view, and manage your cloud infrastructure.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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 CloudPlatform, 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”.
+
Warning
+ You are logging in as the root administrator. This account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. Please change the default password to a new, unique password.
+
5.1.4. Changing the Root Password
+ During installation and ongoing cloud administration, you will need to log in to the UI as the root administrator. The root administrator account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. When first installing CloudStack, be sure to change the default password to a new, unique value.
+
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+
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.
+
+ 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.
+
+ All CloudStack API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+
+ CloudStack API URL: This is the web services API entry point(for example, http://www.cloud.com:8080/client/api)
+
+ Command: The web services command you wish to execute, such as start a virtual machine or create a disk volume
+
+ Parameters: Any additional required or optional parameters for the command
+
+ A sample API GET request looks like the following:
+
+ The first line is the CloudStack API URL. This is the Cloud instance you wish to interact with.
+
+ The second line refers to the command you wish to execute. In our example, we are attempting to deploy a fresh new virtual machine. It is preceded by a (?) to separate itself from the CloudStack API URL.
+
+ Lines 3-6 are the parameters for this given command. To see the command and its request parameters, please refer to the appropriate section in the CloudStack API documentation. Each parameter field-value pair (field=value) is preceded by an ampersand character (&).
+
+ Line 7 is the user API Key that uniquely identifies the account. See Signing API Requests on page 7.
+
+ Line 8 is the signature hash created to authenticate the user account executing the API command. See Signing API Requests on page 7.
+
+ This section describes installing the Management Server. There are two slightly different installation flows, depending on how many Management Server nodes will be in your cloud:
+
+ A single Management Server node, with MySQL on the same node.
+
+ Multiple Management Server nodes, with MySQL on a node separate from the Management Servers.
+
+ In either case, each machine must meet the system requirements described in System Requirements.
+
Warning
+ For the sake of security, be sure the public Internet can not access port 8096 or port 8250 on the Management Server.
+
+ The procedure for installing the Management Server is:
+
+ Prepare the Operating System
+
+ Download and install vhd-util.
+
+ Install the First Management Server
+
+ Install and Configure the MySQL database
+
+ Prepare NFS Shares
+
+ Prepare and Start Additional Management Servers (optional)
+
+ Prepare the System VM Template
+
4.5.2. Prepare the Operating System
+ The OS must be prepared to host the Management Server using the following steps. These steps must be performed on each Management Server node.
+
+ Log in to your OS as root.
+
+ Check for a fully qualified hostname.
+
hostname --fqdn
+ This should return a fully qualified hostname such as "managament1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+ Make sure that the machine can reach the Internet.
+
ping www.cloudstack.org
+ Turn on NTP for time synchronization.
+
Note
+ NTP is required to synchronize the clocks of the servers in your cloud.
+
+ Install NTP.
+
yum install ntp
apt-get install openntpd
+ Repeat all of these steps on every host where the Management Server will be installed.
+
4.5.3. Install the Management Server on the First Host
+ The first step in installation, whether you are installing the Management Server on one host or many, is to install the software on a single node.
+
Note
+ If you are planning to install the Management Server on multiple nodes for high availability, do not proceed to the additional nodes yet. That step will come later.
+
+ The CloudStack Management server can be installed using either RPM or DEB packages. These packages will depend on everything you need to run the Management server.
+
4.5.3.1. Downloading vhd-util
+ Before setting up the Management Server, download vhd-util from vhd-util
+
+ If the Management Server is RHEL or CentOS, copy vhd-util to /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver.
+
+ If the Management Server is Ubuntu, copy vhd-util to /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util.
+
4.5.3.2. Install on CentOS/RHEL
+ We start by installing the required packages:
+
yum install cloud-client
4.5.3.3. Install on Ubuntu
apt-get install cloud-client
4.5.4. Install the database server
+ The CloudStack management server uses a MySQL database server to store it's data. When you are installing the management server on a single node you can install the MySQL server locally. When using a multi-node installation the MySQL database has to run on an external node.
+
+ CloudStack has been tested with MySQL 5.1 and 5.5, both should work fine. These versions are included in RHEL/CentOS and Ubuntu.
+
4.5.4.1. Install the Database on the Management Server Node
+ This section describes how to install MySQL on the same machine with the Management Server. This technique is intended for a simple deployment that has a single Management Server node. If you have a multi-node Management Server deployment, you will typically use a separate node for MySQL. See Section 4.5.4.2, “Install the Database on a Separate Node”.
+
+ Install MySQL from the package repository from your distribution:
+
yum install mysql-server
apt-get install mysql-server
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes one Management Server.
+
Note
+ On Ubuntu you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add these directives there. Don't forget to add [mysqld] on the first line of the file.
+
+ On RHEL/CentOS MySQL doesn't start after installation, start it manually.
+
service mysqld start
Warning
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password. This step is not required on Ubuntu as it asks for a root password during installation.
+
+ Run this command to secure your installation. Since we are running MySQL locally you can answer "Y" to all questions.
+
mysql_secure_installation
+ Set up the database. The following command creates the "cloud" user on the database.
+
+ In dbpassword, specify the password to be assigned to the "cloud" user. You can choose to provide no password although that is not recommended.
+
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the "cloud" user.
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
4.5.4.2. Install the Database on a Separate Node
+ This section describes how to install MySQL on a standalone machine, separate from the Management Server. This technique is intended for a deployment that includes several Management Server nodes. If you have a single-node Management Server deployment, you will typically use the same node for MySQL. See Section 4.5.4.1, “Install the Database on the Management Server Node”.
+
Note
+ The management server doesn't require a specific distribution for the MySQL node. You can use a distribution or Operating System of your choice. Using the same distribution as the management server is recommended, but not required. See Section 4.3.1, “Management Server, Database, and Storage System Requirements”.
+
+ Install MySQL from the package repository from your distribution:
+
yum install mysql-server
apt-get install mysql-server
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes two Management Servers.
+
Note
+ On Ubuntu you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add these directives there. Don't forget to add [mysqld] on the first line of the file.
+
+ On RHEL/CentOS MySQL doesn't start after installation, start it manually.
+
service mysqld start
Warning
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password. This step is not required on Ubuntu as it asks for a root password during installation.
+
+ Run this command to secure your installation. You can answer "Y" to all questions except to "Disallow root login remotely?". This is required to set up the databases.
+
mysql_secure_installation
+ If a firewall is present on the system, open TCP port 3306 so external MySQL connections can be established.
+
+ On RHEL/CentOS:
+
+ Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the INPUT chain.
+
-A INPUT -p tcp --dport 3306 -j ACCEPT
+ Now reload the iptables rules.
+
service iptables restart
+ On Ubuntu:
+
+ UFW is the default firewall on Ubuntu, open the port with this command:
+
ufw allow mysql
+ Set up the database. The following command creates the cloud user on the database.
+
Note
+ This command should be run on the first Management server node!
+
+ In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password.
+
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
4.5.5. Prepare NFS Shares
+ CloudStack needs a place to keep primary and secondary storage (see Cloud Infrastructure Overview). Both of these can be NFS shares. This section tells how to set up the NFS shares before adding the storage to CloudStack.
+
+ For primary storage, you can use iSCSI instead.
+
+ The requirements for primary and secondary storage are described in:
+
+ This section tells how to set up NFS shares for secondary and (optionally) primary storage on an NFS server running on a separate node from the Management Server.
+
+ The exact commands for the following steps may vary depending on your operating system version.
+
Warning
+ (KVM only) Ensure that no volume is already mounted at your NFS mount point.
+
+ On the storage server, create an NFS share for secondary storage and, if you are using NFS for primary storage as well, create a second NFS share. For example:
+
+ To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s) with rw,async,no_root_squash. For example:
+
# vi /etc/exports
+ Insert the following line.
+
/export *(rw,async,no_root_squash)
+ Export the /export directory.
+
# exportfs -a
+ On the management server, create a mount point for secondary storage. For example:
+
# mkdir -p /mnt/secondary
+ Mount the secondary storage on your Management Server. Replace the example NFS server name and NFS share paths below with your own.
+
# mount -t nfs nfsservername:/nfs/share/secondary /mnt/secondary
4.5.5.2. Using the Management Server As the NFS Server
+ This section tells how to set up NFS shares for primary and secondary storage on the same node with the Management Server. This is more typical of a trial installation, but is technically possible in a larger deployment. It is assumed that you will have less than 16TB of storage on the host.
+
+ The exact commands for the following steps may vary depending on your operating system version.
+
+ On the Management Server host, create two directories that you will use for primary and secondary storage. For example:
+
+ Add the following lines at the beginning of the INPUT chain where <NETWORK> is the network that you'll be using:
+
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 32769 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 662 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 662 -j ACCEPT
+
+ Run the following commands:
+
+# service iptables restart
+# service iptables save
+
+ If NFS v4 communication is used between client and server, add your domain to /etc/idmapd.conf on both the hypervisor host and Management Server.
+
# vi /etc/idmapd.conf
+ Remove the character # from the beginning of the Domain line in idmapd.conf and replace the value in the file with your own domain. In the example below, the domain is company.com.
+
Domain = company.com
+ Reboot the Management Server host.
+
+ Two NFS shares called /export/primary and /export/secondary are now set up.
+
+ It is recommended that you test to be sure the previous steps have been successful.
+
+ Log in to the hypervisor host.
+
+ Be sure NFS and rpcbind are running. The commands might be different depending on your OS. For example:
+
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+# reboot
+
+ Log back in to the hypervisor host and try to mount the /export directories. For example (substitute your own management server name):
+
4.5.6. Prepare and Start Additional Management Servers
+ For your second and subsequent Management Servers, you will install the Management Server software, connect it to the database, and set up the OS for the Management Server.
+
+ Configure the OS and start the Management Server:
+
#cloud-setup-management
+ The Management Server on this node should now be running.
+
+ Repeat these steps on each additional Management Server.
+
+ Be sure to configure a load balancer for the Management Servers. See Management Server Load Balancing.
+
4.5.7. Prepare the System VM Template
+ Secondary storage must be seeded with a template that is used for CloudStack system VMs.
+
Note
+ When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text.
+
+ On the Management Server, run one or more of the following cloud-install-sys-tmplt commands to retrieve and decompress the system VM template. Run the command for each hypervisor type that you expect end users to run in this Zone.
+
+ If your secondary storage mount point is not named /mnt/secondary, substitute your own mount point name.
+
+ If you set the CloudStack database encryption type to "web" when you set up the database, you must now add the parameter -s <management-server-secret-key>. See About Password and Key Encryption.
+
+ This process will require approximately 5 GB of free space on the local file system and up to 30 minutes each time it runs.
+
+ If you are using a separate NFS server, perform this step. If you are using the Management Server as the NFS server, you MUST NOT perform this step.
+
+ When the script has finished, unmount secondary storage and remove the created directory.
+
# umount /mnt/secondary
+# rmdir /mnt/secondary
+ Repeat these steps for each secondary storage server.
+
4.5.8. Installation Complete! Next Steps
+ Congratulations! You have now installed CloudStack Management Server and the database it uses to persist system data.
+
+ What should you do next?
+
+ Even without adding any cloud infrastructure, you can run the UI to get a feel for what's offered and how you will interact with CloudStack on an ongoing basis. See Log In to the UI.
+
+ When you're ready, add the cloud infrastructure and try running some virtual machines on it, so you can watch how CloudStack manages the infrastructure. See Provision Your Cloud Infrastructure.
+
10.9. Moving VMs Between Hosts (Manual Live Migration)
+ The CloudPlatform administrator can move a running VM from one host to another without interrupting service to users or going into maintenance mode. This is called manual live migration, and can be done under the following conditions:
+
+ The root administrator is logged in. Domain admins and users can not perform manual live migration of VMs.
+
+ The VM is running. Stopped VMs can not be live migrated.
+
+ The destination host must be in the same cluster as the original host.
+
+ The VM must not be using local disk storage.
+
+ The destination host must have enough available capacity. If not, the VM will remain in the "migrating" state until memory becomes available.
+
+ To manually live migrate a virtual machine
+
+ Log in to the CloudPlatform UI as a user or admin.
+
+ In the left navigation, click Instances.
+
+ Choose the VM that you want to migrate.
+
+ Click the Migrate Instance button
+
+
+
+ From the list of hosts, choose the one to which you want to move the VM.
+
4.3.1. Management Server, Database, and Storage System Requirements
+ The machines that will run the Management Server and MySQL database must meet the following requirements. The same machines can also be used to provide primary and secondary storage, such as via localdisk or NFS. The Management Server may be placed on a virtual machine.
+
+ Operating system:
+
+ Preferred: CentOS/RHEL 6.3+ or Ubuntu 12.04(.1)
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ 4 GB of memory
+
+ 50 GB of local disk (When running secondary storage on the management server 500GB is recommended)
+
+ At least 1 NIC
+
+ Statically allocated IP address
+
+ Fully qualified domain name as returned by the hostname command
+
4.3.2. Host/Hypervisor System Requirements
+ The host is where the cloud services run in the form of guest virtual machines. Each host is one machine that meets the following requirements:
+
+ Must support HVM (Intel-VT or AMD-V enabled).
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ Hardware virtualization support required
+
+ 4 GB of memory
+
+ 36 GB of local disk
+
+ At least 1 NIC
+
Note
+ If DHCP is used for hosts, ensure that no conflict occurs between DHCP server used for these hosts and the DHCP router created by CloudStack.
+
+ Latest hotfixes applied to hypervisor software
+
+ When you deploy CloudStack, the hypervisor host must not have any VMs already running
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+ Hosts have additional requirements depending on the hypervisor. See the requirements listed at the top of the Installation section for your chosen hypervisor:
+
Warning
+ Be sure you fulfill the additional hypervisor requirements and installation steps provided in this Guide. Hypervisor hosts must be properly prepared to work with CloudStack. For example, the requirements for XenServer are listed under Citrix XenServer Installation.
+
+ The CloudStack Management Server is deployed on one or more front-end servers connected to a single MySQL database. Optionally a pair of hardware load balancers distributes requests from the web. A backup management server set may be deployed using MySQL replication at a remote site to add DR capabilities.
+
+ The administrator must decide the following.
+
+ Whether or not load balancers will be used.
+
+ How many Management Servers will be deployed.
+
+ Whether MySQL replication will be deployed to enable disaster recovery.
+
+ The CloudStack platform scales well into multiple sites through the use of zones. The following diagram shows an example of a multi-site deployment.
+
+ Data Center 1 houses the primary Management Server as well as zone 1. The MySQL database is replicated in real time to the secondary Management Server installation in Data Center 2.
+
+ This diagram illustrates a setup with a separate storage network. Each server has four NICs, two connected to pod-level network switches and two connected to storage network switches.
+
+ There are two ways to configure the storage network:
+
+ Bonded NIC and redundant switches can be deployed for NFS. In NFS deployments, redundant switches and bonded NICs still result in one network (one CIDR block+ default gateway address).
+
+ iSCSI can take advantage of two separate storage networks (two CIDR blocks each with its own default gateway). Multipath iSCSI client can failover and load balance between separate storage networks.
+
+ This diagram illustrates the differences between NIC bonding and Multipath I/O (MPIO). NIC bonding configuration involves only one network. MPIO involves two separate networks.
+
diff --git a/docs/tmp/en-US/html/multiple-system-vm-vmware.html b/docs/tmp/en-US/html/multiple-system-vm-vmware.html
new file mode 100644
index 00000000000..90e2609ddeb
--- /dev/null
+++ b/docs/tmp/en-US/html/multiple-system-vm-vmware.html
@@ -0,0 +1,5 @@
+
+
+16.2. Multiple System VM Support for VMware
+ Every CloudStack zone has single System VM for template processing tasks such as downloading templates, uploading templates, and uploading ISOs. In a zone where VMware is being used, additional System VMs can be launched to process VMware-specific tasks such as taking snapshots and creating private templates. The CloudStack management server launches additional System VMs for VMware-specific tasks as the load increases. The management server monitors and weights all commands sent to these System VMs and performs dynamic load balancing and scaling-up of more System VMs.
+
+ For the most up-to-date list of supported network services, see the CloudPlatform UI or call listNetworkServices.
+
+ A network offering is a named set of network services, such as:
+
+ DHCP
+
+ DNS
+
+ Source NAT
+
+ Static NAT
+
+ Port Forwarding
+
+ Load Balancing
+
+ Firewall
+
+ VPN
+
+ Optional) Name one of several available providers to use for a given service, such as Juniper for the firewall
+
+ (Optional) Network tag to specify which physical network to use
+
+ When creating a new VM, the user chooses one of the available network offerings, and that determines which network services the VM can use.
+
+ The CloudPlatform administrator can create any number of custom network offerings, in addition to the default network offerings provided by CloudPlatform. By creating multiple custom network offerings, you can set up your cloud to offer different classes of service on a single multi-tenant physical network. For example, while the underlying physical wiring may be the same for two tenants, tenant A may only need simple firewall protection for their website, while tenant B may be running a web server farm and require a scalable firewall solution, load balancing solution, and alternate networks for accessing the database backend.
+
Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudPlatform virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+ When creating a new virtual network, the CloudPlatform administrator chooses which network offering to enable for that network. Each virtual network is associated with one network offering. A virtual network can be upgraded or downgraded by changing its associated network offering. If you do this, be sure to reprogram the physical network to match.
+
+ CloudPlatform also has internal network offerings for use by CloudPlatform system VMs. These network offerings are not visible to users but can be modified by administrators.
+
+ For the most up-to-date list of supported network service providers, see the CloudPlatform UI or call listNetworkServiceProviders.
+
+ A service provider (also called a network element) is hardware or virtual appliance that makes a network service possible; for example, a firewall appliance can be installed in the cloud to provide firewall service. On a single network, multiple providers can provide the same network service. For example, a firewall service may be provided by Cisco or Juniper devices in the same physical network.
+
+ You can have multiple instances of the same service provider in a network (say, more than one Juniper SRX device).
+
+ If different providers are set up to provide the same service on the network, the administrator can create network offerings so users can specify which network service provider they prefer (along with the other choices offered in network offerings). Otherwise, CloudPlatform will choose which provider to use whenever the service is called for.
+
Supported Network Service Providers
+ CloudPlatform ships with an internal list of the supported service providers, and you can choose from this list when creating a network offering.
+
diff --git a/docs/tmp/en-US/html/networking-in-a-pod.html b/docs/tmp/en-US/html/networking-in-a-pod.html
new file mode 100644
index 00000000000..726d5ba4fa6
--- /dev/null
+++ b/docs/tmp/en-US/html/networking-in-a-pod.html
@@ -0,0 +1,15 @@
+
+
+15.2. Networking in a Pod
+ Figure 2 illustrates network setup within a single pod. The hosts are connected to a pod-level switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
+
+ Servers are connected as follows:
+
+ Storage devices are connected to only the network that carries management traffic.
+
+ Hosts are connected to networks for both management traffic and public traffic.
+
+ Hosts are also connected to one or more networks carrying guest traffic.
+
+ We recommend the use of multiple physical Ethernet cards to implement each network interface as well as redundant switch fabric in order to maximize throughput and improve reliability.
+
diff --git a/docs/tmp/en-US/html/networking-in-a-zone.html b/docs/tmp/en-US/html/networking-in-a-zone.html
new file mode 100644
index 00000000000..cf10850d593
--- /dev/null
+++ b/docs/tmp/en-US/html/networking-in-a-zone.html
@@ -0,0 +1,9 @@
+
+
+15.3. Networking in a Zone
+ Figure 3 illustrates the network setup within a single zone.
+
+ A firewall for management traffic operates in the NAT mode. The network typically is assigned IP addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses in the 192.168.*.0/24 Class C private address space.
+
+ Each zone has its own set of public IP addresses. Public IP addresses from different zones do not overlap.
+
+ People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a CloudStack administrator, you can do the following things to set up networking for your users:
+
+ Set up physical networks in zones
+
+ Set up several different providers for the same service on a single physical network (for example, both Cisco and Juniper firewalls)
+
+ Bundle different types of network services into network offerings, so users can choose the desired network services for any given virtual machine
+
+ Add new network offerings as time goes on so end users can upgrade to a better class of service on their network
+
+ Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member
+
+ In a CloudStack, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN. The CloudStack virtual router is the main component providing networking features for guest traffic.
+
4.1. Service Offerings, Disk Offerings, Network Offerings, and Templates
+ A user creating a new instance can make a variety of choices about its characteristics and capabilities. CloudStack provides several ways to present users with choices when creating a new instance:
+
+ Service Offerings, defined by the CloudStack administrator, provide a choice of CPU speed, number of CPUs, RAM size, tags on the root disk, and other choices. See Creating a New Compute Offering.
+
+ Disk Offerings, defined by the CloudStack administrator, provide a choice of disk size for primary data storage. See Creating a New Disk Offering.
+
+ Network Offerings, defined by the CloudStack administrator, describe the feature set that is available to end users from the virtual router or external networking devices on a given guest network. See Network Offerings.
+
+ Templates, defined by the CloudStack administrator or by any CloudStack user, are the base OS images that the user can choose from when creating a new instance. For example, CloudStack includes CentOS as a template. See Working with Templates.
+
+ In addition to these choices that are provided for users, there is another type of service offering which is available only to the CloudStack root administrator, and is used for configuring virtual infrastructure resources. For more information, see Upgrading a Virtual Router with System Service Offerings.
+
+ In this chapter we discuss compute, disk, and system service offerings. Network offerings are discussed in the section on setting up networking for users.
+
+ CloudStack allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of all accounts in the domain as well as all accounts in all subdomains of that domain. Limits set at the root domain level apply to the sum of resource usage by the accounts in all domains and sub-domains below that root domain.
+
+ To set a domain limit:
+
+ Log in to the CloudStack UI.
+
+ In the left navigation tree, click Domains.
+
+ Select the domain you want to modify. The current domain limits are displayed. A value of -1 shows that there is no limit in place.
+
+ Host and guest performance monitoring is available to end users and administrators. This allows the user to monitor their utilization of resources and determine when it is appropriate to choose a more powerful service offering or larger disk.
+
+ 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.
+
+ Any standards-compliant iSCSI or NFS server that is supported by the underlying hypervisor.
+
+ The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller.
+
+ Minimum required capacity depends on your needs.
+
+ When setting up primary storage, follow these restrictions:
+
+ Primary storage cannot be added until a host has been added to the cluster.
+
+ If you do not provision shared primary storage, you must set the global configuration parameter system.vm.local.storage.required to true, or else you will not be able to start VMs.
+
7.6.2. Adding Primary Stroage
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+
+ Click the Compute tab.
+
+ In the Primary Storage node of the diagram, click View All.
+
+ Click Add Primary Storage.
+
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+
+ Pod. The pod for the storage device.
+
+ Cluster. The cluster for the storage device.
+
+ Name. The name of the storage device.
+
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS.
+
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device.
+
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+
+ Path (for NFS). In NFS this is the exported path from the server.
+
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside CloudStack.
+
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
+
+ Lun # (for iSCSI). In iSCSI this is 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.
+
+ When a primary storage outage occurs the hypervisor immediately stops all VMs stored on that storage device. Guests that are marked for HA will be restarted as soon as practical when the primary storage comes back on line. With NFS, the hypervisor may allow the virtual machines to continue running depending on the nature of the issue. For example, an NFS hang will cause the guest VMs to be suspended until storage connectivity is restored.Primary storage is not designed to be backed up. Individual volumes in primary storage can be backed up using snapshots.
+
+ This section gives concepts and technical details about CloudPlatform primary storage. For information about how to install and configure primary storage through the CloudPlatform UI, see the Advanced Installation Guide.
+
13.2.1. Best Practices for Primary Storage
+ The speed of primary storage will impact guest performance. If possible, choose smaller, higher RPM drives for primary storage.
+
+ Ensure that nothing is stored on the server. Adding the server to CloudPlatform will destroy any existing data
+
13.2.2. Runtime Behavior of Primary Storage
+ Root volumes are created automatically when a virtual machine is created. Root volumes are deleted when the VM is destroyed. Data volumes can be created and dynamically attached to VMs. Data volumes are not deleted when VMs are destroyed.
+
+ Administrators should monitor the capacity of primary storage devices and add additional primary storage as needed. See the Advanced Installation Guide.
+
+ Administrators add primary storage to the system by creating a CloudStack storage pool. Each storage pool is associated with a cluster.
+
13.2.3. Hypervisor Support for Primary Storage
+ The following table shows storage options and parameters for different hypervisors.
+
+
+
+ VMware vSphere
+
+
+
+ Citrix XenServer
+
+
+
+ KVM
+
+
+
+ Format for Disks, Templates, and Snapshots
+
+
+
+ VMDK
+
+
+
+ VHD
+
+
+
+ QCOW2
+
+
+
+ iSCSI support
+
+
+
+ VMFS
+
+
+
+ Clustered LVM
+
+
+
+ Yes, via Shared Mountpoint
+
+
+
+ Fiber Channel support
+
+
+
+ VMFS
+
+
+
+ Yes, via Existing SR
+
+
+
+ Yes, via Shared Mountpoint
+
+
+
+ NFS support
+
+
+
+ Y
+
+
+
+ Y
+
+
+
+ Y
+
+
+
+ Local storage support
+
+
+
+ Y
+
+
+
+ Y
+
+
+
+ Y
+
+
+
+ Storage over-provisioning
+
+
+
+ NFS and iSCSI
+
+
+
+ NFS
+
+
+
+ NFS
+
+
+ XenServer uses a clustered LVM system to store VM images on iSCSI and Fiber Channel volumes and does not support over-provisioning in the hypervisor. The storage server itself, however, can support thin-provisioning. As a result the CloudStack can still support storage over-provisioning by running on thin-provisioned storage volumes.
+
+ KVM supports "Shared Mountpoint" storage. A shared mountpoint is a file system path local to each server in a given cluster. The path must be the same across all Hosts in the cluster, for example /mnt/primary1. This shared mountpoint is assumed to be a clustered filesystem such as OCFS2. In this case the CloudStack does not attempt to mount or unmount the storage as is done with NFS. The CloudStack requires that the administrator insure that the storage is available
+
+ With NFS storage, CloudStack manages the overprovisioning. In this case the global configuration parameter storage.overprovisioning.factor controls the degree of overprovisioning. This is independent of hypervisor type.
+
+ Local storage is an option for primary storage for vSphere, XenServer, and KVM. When the local disk option is enabled, a local disk storage pool is automatically created on each host. To use local storage for the System Virtual Machines (such as the Virtual Router), set system.vm.use.local.storage to true in global configuration.
+
+ CloudStack supports multiple primary storage pools in a Cluster. For example, you could provision 2 NFS servers in primary storage. Or you could provision 1 iSCSI LUN initially and then add a second iSCSI LUN when the first approaches capacity.
+
13.2.4. Storage Tags
+ Storage may be "tagged". A tag is a text string attribute associated with primary storage, a Disk Offering, or a Service Offering. Tags allow administrators to provide additional information about the storage. For example, that is a "SSD" or it is "slow". Tags are not interpreted by CloudStack. They are matched against tags placed on service and disk offerings. CloudStack requires all tags on service and disk offerings to exist on the primary storage before it allocates root or data disks on the primary storage. Service and disk offering tags are used to identify the requirements of the storage that those offerings have. For example, the high end service offering may require "fast" for its root disk volume.
+
+ The interaction between tags, allocation, and volume copying across clusters and pods can be complex. To simplify the situation, use the same set of tags on the primary storage for all clusters in a pod. Even if different devices are used to present those tags, the set of exposed tags can be the same.
+
13.2.5. Maintenance Mode for Primary Storage
+ Primary storage may be placed into maintenance mode. This is useful, for example, to replace faulty RAM in a storage device. Maintenance mode for a storage device will first stop any new guests from being provisioned on the storage device. Then it will stop all guests that have any volume on that storage device. When all such guests are stopped the storage device is in maintenance mode and may be shut down. When the storage device is online again you may cancel maintenance mode for the device. The CloudStack will bring the device back online and attempt to start all guests that were running at the time of the entry into maintenance mode.
+
+ When a user creates a template, it can be designated private or public.
+
+ Private templates are only available to the user who created them. By default, an uploaded template is private.
+
+ When a user marks a template as “public,” the template becomes available to all users in all accounts in the user's domain, as well as users in any other domains that have access to the Zone where the template is stored. This depends on whether the Zone, in turn, was defined as private or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any domain. If a public template is created in a private Zone, it is available only to users in the domain assigned to that Zone. If a public template is created in a public Zone, it is available to all users in all domains.
+
+ 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..
+
diff --git a/docs/tmp/en-US/html/projects.html b/docs/tmp/en-US/html/projects.html
new file mode 100644
index 00000000000..ec5ecba28ca
--- /dev/null
+++ b/docs/tmp/en-US/html/projects.html
@@ -0,0 +1,3 @@
+
+
+Chapter 6. Using Projects to Organize Users and Resources
+ 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.
+
+ 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”.
+
+ To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
+
+ This section tells how to add 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.
+
+ 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.
+
+ Hosts can be removed from the cloud as needed. The procedure to remove a host depends on the hypervisor type.
+
11.4.1. 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:
+
+ Then you may power down the Host, re-use its IP address, re-install it, etc
+
11.4.2. 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”. 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.
+
+ CloudStack supports two formats as the response to an API call. The default response is XML. If you would like the response to be in JSON, add &response=json to the Command String.
+
+ For each cloud, there is a default upper limit on the number of results that any API command will return in a single page. This is to help prevent overloading the cloud servers and prevent DOS attacks. For example, if the page size limit is 500 and a command returns 10,000 results, the command will return 20 pages.
+
+ The default page size limit can be different for each cloud. It is set in the global configuration parameter default.page.size. If your cloud has many users with lots of VMs, you might need to increase the value of this parameter. At the same time, be careful not to set it so high that your site can be taken down by an enormous return from an API call. For more information about how to set global configuration parameters, see "Describe Your Deployment" in the Installation Guide.
+
+ To decrease the page size limit for an individual API command, override the global setting with the page and pagesize parameters, which are available in any list* command (listCapabilities, listDiskOfferings, etc.).
+
+ Both parameters must be specified together.
+
+ The value of the pagesize parameter must be smaller than the value of default.page.size. That is, you can not increase the number of possible items in a result page, only decrease it.
+
+ For syntax information on the list* commands, see the API Reference.
+
4.4.3. Error Handling
+ If an error occurs while processing an API request, the appropriate response in the format specified is returned. Each error response consists of an error code and an error text describing what possibly can go wrong. For an example error response, see page 12.
+
+ An HTTP error code of 401 is always returned if API request was rejected due to bad signatures, missing API Keys, or the user simply did not have the permissions to execute the command.
+
11.2. 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.
+
+ (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org)
+
+ 100GB minimum capacity
+
+ A secondary storage device must be located in the same zone as the guest VMs it serves.
+
+ Each Secondary Storage server must be available to all hosts in the zone.
+
7.7.2. Adding Secondary Storage
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+
Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to CloudStack before you add the local zone secondary storage servers. See Section 7.2, “Adding a Zone”.
+
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See Preparing NFS Shares in the Installation Guide.
+
+ Make sure you prepared the system VM template during Management Server installation. See Prepare the System VM Template in the Installation Guide.
+
+ Now that the secondary storage server for per-zone storage is prepared, add it to CloudStack. Secondary storage is added as part of the procedure for adding a new zone. See Section 7.2, “Adding a Zone”.
+
+ For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online.
+
+ Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system.
+
+ In addition to the hosts, CloudStack’s Secondary Storage VM mounts and writes to secondary storage.
+
+ Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols.
+
+ The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups.
+
+ The administrator can log in to the secondary storage VM if needed.
+
+ This section gives concepts and technical details about CloudStack secondary storage. For information about how to install and configure secondary storage through the CloudStack UI, see the Advanced Installation Guide.
+
+ In addition to the bootstrap dependencies, you'll also need to install several other dependencies. Note that we recommend using Maven 3, which is not currently available in 12.04.1 LTS. So, you'll also need to add a PPA repository that includes Maven 3. After running the command add-apt-repository, you will be prompted to continue and a GPG key will be added.
+
+ While we have defined, and you have presumably already installed the bootstrap prerequisites, there are a number of build time prerequisites that need to be resolved. CloudStack uses maven for dependency resolution. You can resolve the buildtime depdencies for CloudStack by running:
+
$ mvn3 -P deps
+ Now that we have resolved the dependencies we can move on to building CloudStack and packaging them into DEBs by issuing the following command.
+
+$ dpkg-buildpackge -uc -us
+ This command will build 16 Debian packages. You should have all of the following:
+
+ After you've created the packages, you'll want to copy them to a system where you can serve the packages over HTTP. You'll create a directory for the packages and then use dpkg-scanpackages to create Packages.gz, which holds information about the archive structure. Finally, you'll add the repository to your system(s) so you can install the packages using APT.
+
+ The first step is to make sure that you have the dpkg-dev package installed. This should have been installed when you pulled in the debhelper application previously, but if you're generating Packages.gz on a different system, be sure that it's installed there as well.
+
$ sudo apt-get install dpkg-dev
+ The next step is to copy the DEBs to the directory where they can be served over HTTP. We'll use /var/www/cloudstack/repo in the examples, but change the directory to whatever works for you.
+
+ You can safely ignore the warning about a missing override file.
+
+ Now you should have all of the DEB packages and Packages.gz in the binary directory and available over HTTP. (You may want to use wget or curl to test this before moving on to the next step.)
+
3.5.2. Configuring your machines to use the APT repository
+ Now that we have created the repository, you need to configure your machine to make use of the APT repository. You can do this by adding a repository file under /etc/apt/sources.list.d. Use your preferred editor to create /etc/apt/sources.list.d/cloudstack.list with this line:
+
deb http://server.url/cloudstack/repo binary/
+ Now that you have the repository info in place, you'll want to run another update so that APT knows where to find the CloudStack packages.
+
$ sudo apt-get update
+ You can now move on to the instructions under Install on Ubuntu.
+
+ While we have defined, and you have presumably already installed the bootstrap prerequisites, there are a number of build time prerequisites that need to be resolved. CloudStack uses maven for dependency resolution. You can resolve the buildtime depdencies for CloudStack by running the following command:
+
$mvn -P deps
+
+
+ Now that we have resolved the dependencies we can move on to building CloudStack and packaging them into RPMs by issuing the following command.
+
$./waf rpm
+
+
+ Once this completes, you should find assembled RPMs in artifacts/rpmbuild/RPMS/x86_64
+
3.6.1. Creating a yum repo
+ While RPMs is an ideal packaging format - it's most easily consumed from yum repositories over a network. We'll move into the directory with the newly created RPMs by issuing the following command:
+
$cd artifacts/rpmbuild/RPMS/x86_64
+
+
+ Next we'll issue a command to create the repository metadata by issuing the following command:
+
$createrepo ./
+
+
+ The files and directories within our current working directory can now be uploaded to a web server and serve as a yum repository
+
3.6.2. Configuring your systems to use your new yum repository
+ Now that your yum repository is populated with RPMs and metadata we need to configure our machines that need to install CloudStack. We will create a file at /etc/yum.repos.d/cloudstack.repo with the following content:
+
+ There are a number of prerequisites needed to build CloudStack. This document assumes compilation on a Linux system that uses RPMs or DEBs for package management.
+
+ The minimum bootstrapped prerequisites for building CloudStack includes the following:
+
+ If the signature is valid you will see a line of output that contains 'Good signature'.
+
3.2.3. MD5
+ In addition to the cryptographic signature, the CloudStack provides a number of cryptographic hashes to aid in assurance of validity of the downloaded release. You can verify this hash by executing the following command:
+
+ If this successfully completes you should see no output. If there is any output from them, then there is a difference between the hash you generated locally and the hash that has been pulled from the server.
+
3.2.4. SHA512
+ In addition to the MD5 hash, the CloudStack project provides a SHA512 cryptographic hash to aid in assurance of the validity of the downloaded release. You can verify this hash by executing the following command:
+
+ If this command successfully completes you should see no output. If there is any output from them, then there is a difference between the hash you generated locally and the hash that has been pulled from the server.
+
+ The official CloudStack release is always in source code form. While there may exist convenience binaries in various forms from a number of places, the source is the canonical release will be source. In this document we'll cover acquiring the source release, building that into binary, deployable packages.
+
+ While building and deploying directly from source is certainly possible, the reality of Infrastructure-as-a-Service cloud computing implies a need to deploy packages on a potentially large number of systems, which RPMs and DEBs fill nicely.
+
+ Building and deploying directly from source is thus outside the scope of this document, but is documented in the INSTALL.md file in the release.
+
+ Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In CloudStack 3.0.3 - 3.0.5, security groups are supported only in zones that use basic networking.
+
Note
+ In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
+
+
+ Each CloudStack account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.
+
+ Any CloudStack user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.
+
+ You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.
+
+ If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
15.7.2. Adding a Security Group
+ A user or administrator can define a new security group.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups.
+
+ Click Add Security Group.
+
+ Provide a name and description.
+
+ Click OK.
+
+ The new security group appears in the Security Groups Details tab.
+
+ To make the security group useful, continue to Adding Ingress and Egress Rules to a Security Group.
+
15.7.3. Enabling Security Groups
+ In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide.
+
15.7.4. Adding Ingress and Egress Rules to a Security Group
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network
+
+ In Select view, choose Security Groups, then click the security group you want .
+
+ To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify what network traffic is allowed into VM instances in this security group. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
+ Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow incoming traffic from all VMs in another security group
+
+ Protocol. The networking protocol that sources will use to send traffic to the security group. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be accepted.
+
+ CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To accept only traffic from another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter the same name you used in step 7.
+
+ The following example allows inbound HTTP access from anywhere:
+
+ To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been allowed in through an ingress rule
+
+ Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow outgoing traffic to all VMs in another security group.
+
+ Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
+
+ CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+ Account, Security Group. (Add by Account only) To allow traffic to be sent to another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter its name.
+
+ In the large-scale redundant setup described in the previous section, storage traffic can overload the management network. A separate storage network is optional for deployments. Storage protocols such as iSCSI are sensitive to network delays. A separate storage network ensures guest network traffic contention does not impact storage performance.
+
+ It is important to provide enough memory space for the MySQL database to cache data and indexes:
+
+ Edit the Tomcat configuration file:
+
/etc/my.cnf
+ Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM.
+
innodb_buffer_pool_size=700M
+ Restart the MySQL service.
+
# service mysqld restart
+ For more information about the buffer pool, see "The InnoDB Buffer Pool" at MySQL Reference Manual.
+
diff --git a/docs/tmp/en-US/html/set-monitor-total-vm-limits-per-host.html b/docs/tmp/en-US/html/set-monitor-total-vm-limits-per-host.html
new file mode 100644
index 00000000000..de4bd7c9007
--- /dev/null
+++ b/docs/tmp/en-US/html/set-monitor-total-vm-limits-per-host.html
@@ -0,0 +1,5 @@
+
+
+21.4. Set and Monitor Total VM Limits per Host
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+
+ CloudStack provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis.
+
+ Aggregate limits may be set on a per-domain basis. For example, you may limit a domain and all subdomains to the creation of 100 VMs.
+
+ Whether you access the CloudStack API with HTTP or HTTPS, it must still be signed so that CloudStack can verify the caller has been authenticated and authorized to execute the command. Make sure that you have both the API Key and Secret Key provided by the CloudStack administrator for your account before proceeding with the signing process.
+
+ To show how to sign a request, we will re-use the previous example.
+
+ Signature: This is the hashed signature of the Base URL that is generated using a combination of the user’s Secret Key and the HMAC SHA-1 hashing algorithm.
+
+ &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+ Every API request has the format Base URL+API Path+Command String+Signature.
+
+ To generate the signature.
+
+ For each field-value pair (as separated by a '&') in the Command String, URL encode each value so that it can be safely sent via HTTP GET.
+
Note
+ Make sure all spaces are encoded as "%20" rather than "+".
+
+ Lower case the entire Command String and sort it alphabetically via the field for each field-value pair. The result of this step would look like the following.
+
+ Take the sorted Command String and run it through the HMAC SHA-1 hashing algorithm (most programming languages offer a utility method to do this) with the user’s Secret Key. Base64 encode the resulting byte array in UTF-8 so that it can be safely transmitted via HTTP. The final string produced after Base64 encoding should be "Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D".
+
+ By reconstructing the final URL in the format Base URL+API Path+Command String+Signature, the final URL should look like:
+
+ This diagram illustrates the network architecture of a small-scale CloudStack deployment.
+
+ A firewall provides a connection to the Internet. The firewall is configured in NAT mode. The firewall forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+
+ A layer-2 switch connects all physical servers and storage.
+
+ A single NFS server functions as both the primary and secondary storage.
+
+ The Management Server is connected to the management network.
+
+ A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
+
18.5. 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:
+
+ CloudStack defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS.
+
+ There is no ephemeral storage in CloudStack. All volumes on all nodes are persistent.
+
+ The Apache CloudStack project has mailing lists for users and developers. These are the official channels of communication for the project and are the best way to get answers about using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users mailing list if you've deployed or are deploying CloudStack into production, and even for test deployments.
+
+ The CloudStack developer's mailing list (cloudstack-dev) is for discussions about CloudStack development, and is the best list for discussing possible bugs in CloudStack. Anyone contributing to CloudStack should be on this mailing list.
+
+ 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.
+
+ System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the CloudStack root administrator. CloudStack provides default system service offerings. The CloudStack root administrator can create additional custom system service offerings.
+
+ When CloudStack creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering.
+
diff --git a/docs/tmp/en-US/html/system-vm-template.html b/docs/tmp/en-US/html/system-vm-template.html
new file mode 100644
index 00000000000..0b7ee24bcfd
--- /dev/null
+++ b/docs/tmp/en-US/html/system-vm-template.html
@@ -0,0 +1,19 @@
+
+
+16.1. The System VM Template
diff --git a/docs/tmp/en-US/html/tagging-resources.html b/docs/tmp/en-US/html/tagging-resources.html
new file mode 100644
index 00000000000..f73dc204eda
--- /dev/null
+++ b/docs/tmp/en-US/html/tagging-resources.html
@@ -0,0 +1,48 @@
+
+
+18.1. Using Tags to Organize Resources in the Cloud
18.1. 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:
+
diff --git a/docs/tmp/en-US/html/time-zones.html b/docs/tmp/en-US/html/time-zones.html
new file mode 100644
index 00000000000..e44c958b66c
--- /dev/null
+++ b/docs/tmp/en-US/html/time-zones.html
@@ -0,0 +1,244 @@
+
+
+Appendix C. Time Zones
+ 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.
+
+ 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:
+
22.8. 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 CloudPlatform 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.
+
+ Host was placed in maintenance mode, but still appears live in vCenter.
+
Cause
+ The CloudPlatform 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.
+
+ 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.
+
22.6. 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.
+
diff --git a/docs/tmp/en-US/html/troubleshooting-unable-to-power-on-vm.html b/docs/tmp/en-US/html/troubleshooting-unable-to-power-on-vm.html
new file mode 100644
index 00000000000..f5ad17c4d41
--- /dev/null
+++ b/docs/tmp/en-US/html/troubleshooting-unable-to-power-on-vm.html
@@ -0,0 +1,17 @@
+
+
+22.7. Unable to power on virtual machine on VMware
22.7. 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.
+
diff --git a/docs/tmp/en-US/html/troubleshooting-working-with-server-logs.html b/docs/tmp/en-US/html/troubleshooting-working-with-server-logs.html
new file mode 100644
index 00000000000..6d7582cfe29
--- /dev/null
+++ b/docs/tmp/en-US/html/troubleshooting-working-with-server-logs.html
@@ -0,0 +1,19 @@
+
+
+22.2. Working with Server Logs
+ The CloudStack Management Server logs all web site, middle tier, and database activities for diagnostics purposes in /var/log/cloud/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.
+
+ 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:
+
+ 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:
+
+ grep "job-1076)" management-server.log
+
+ The CloudStack Agent Server logs its activities in /var/log/cloud/agent/.
+
+ Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note that some of the steps here are only required if you're using a specific hypervisor. The steps that are hypervisor-specific are called out with a note.
+
+ Ensure that you query your IP address usage records and process them or make a backup. During the upgrade you will lose the old IP address usage records.
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading, any existing IP address usage records in the old format will no longer be available.
+
Note
+ The following upgrade instructions apply only if you're using VMware hosts. If you're not using VMware hosts, skip this step and move on to step 3: stopping all usage servers.
+
+ In each zone that includes VMware hosts, you need to add a new system VM template.
+
+ While running the existing 3.0.2 system, log in to the UI as root administrator.
+
+ In the left navigation bar, click Templates.
+
+ In Select view, click Templates.
+
+ Click Register template.
+
+ The Register template dialog box is displayed.
+
+ In the Register template dialog box, specify the following values (do not change these):
+
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful.
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+
# service cloud-usage stop
+ Stop the Management Servers. Run this on all Management Server hosts.
+
# service cloud-management stop
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+ 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.
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
+
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
+
#yum update cloud-*
+
+
#apt-get update
+#apt-get upgrade cloud-*
+
+
+ You will, of course, have to agree to the changes suggested by Yum or APT.
+
Note
+ If the upgrade output includes a message similar to the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+
warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+ Instructions follow in the next step.
+
+ If you have made changes to your copy of /etc/cloud/management/components.xml the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+ Make a backup copy of /etc/cloud/management/components.xml. For example:
+
+ Merge your changes from the backup file into the new components.xml.
+
# vi /etc/cloud/management/components.xml
Note
+ If you have more than one management server node, repeat the upgrade steps on each node.
+
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+
# service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. After confirmation, start the other Management Servers one at a time by running the same command on each node.
+
Note
+ Failing to restart the Management Server indicates a problem in the upgrade. Having the Management Server restarted without any issues indicates that the upgrade is successfully completed.
+
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
+ # service cloud-usage start
+
Note
+ Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+
+ Configure a yum or apt respository containing the CloudStack packages as outlined in the Installation Guide.
+
+ Stop the running agent.
+
+ # service cloud-agent stop
+
+ Update the agent software with one of the following command sets as appropriate for your environment.
+
+ # yum update cloud-*
+
+ # apt-get update
+
+ # apt-get upgrade cloud-*
+
+ Start the agent.
+
# service cloud-agent start
+ Edit /etc/cloud/agent/agent.properties to change the resource parameter from "com.cloud.agent.resource.computing.LibvirtComputingResource" to "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
+
+ Start the cloud agent and cloud management services.
+
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+
+ Log in to the CloudStack UI as administrator, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
Note
+ Troubleshooting: If login fails, clear your browser cache and reload the page.
+
+
+ Do not proceed to the next step until the hosts show in Up state.
+
+ If you are upgrading from 3.0.2, perform the following:
+
+ Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter.
+
+ This port is used by the cloud-sysvmadm script at the end of the upgrade procedure. For information about how to set this parameter, see "Setting Global Configuration Parameters" in the Installation Guide.
+
+ Restart the Management Server.
+
Note
+ If you don't want the admin port to remain open, you can set it to null after the upgrade is done and restart the management server.
+
+ Run the cloud-sysvmadm script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the -c and -r arguments. For example:
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+
+ Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+
+ Disconnect the XenServer cluster from CloudStack.
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+
+ To clean up the VLAN, log in to one XenServer host and run:
+
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+ Now prepare the upgrade by running the following on one XenServer host:
+
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+
+ If you see a message like "can't eject CD", log in to the VM and unmount the CD, then run this script again.
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /tmp.
+
+ On the Xen pool master, upload the hotfix with this command:
+
+ xe patch-upload file-name=XS602E003.xsupdate
+
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+
Note
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
+ # xe vm-list
+
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+ Apply the hotfix. First, get the UUID of this host:
+
# xe host-list
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
# xe-switch-network-backend bridge
+ Reboot this XenServer host.
+
+ Run the following:
+
/opt/xensource/bin/setupxenserver.sh
Note
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+
+ Run the following:
+
for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+
Troubleshooting Tip
+ If passwords which you know to be valid appear not to work after upgrade, or other UI issues are seen, try clearing your browser cache and reloading the UI page.
+
2.2. Upgrade from 2.2.14 to 4.0.0-incubating
+ Ensure that you query your IPaddress usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading to 4.0.0-incubating, any existing IP address usage records in the old format will no longer be available.
+
+ If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the instructions in the 2.2.14 Release Notes.
+
KVM Hosts
+ If KVM hypervisor is used in your cloud, be sure you completed the step to insert a valid username and password into the host_details table on each KVM node as described in the 2.2.14 Release Notes. This step is critical, as the database will be encrypted after the upgrade to 4.0.0-incubating.
+
+ While running the 2.2.14 system, log in to the UI as root administrator.
+
+ Using the UI, add a new System VM template for each hypervisor type that is used in your cloud. In each zone, add a system VM template for each hypervisor used in that zone
+
+ In the left navigation bar, click Templates.
+
+ In Select view, click Templates.
+
+ Click Register template.
+
+ The Register template dialog box is displayed.
+
+ In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: VMware
+
+
+ Format: OVA
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful
+
+ WARNING: If you use more than one type of hypervisor in your cloud, be sure you have repeated these steps to download the system VM template for each hypervisor type. Otherwise, the upgrade will fail.
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+
# service cloud-usage stop
+ Stop the Management Servers. Run this on all Management Server hosts.
+
# service cloud-management stop
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+ 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.
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
+
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
+
#yum update cloud-*
+
+
#apt-get update
+#apt-get upgrade cloud-*
+
+
+ You will, of course, have to agree to the changes suggested by Yum or APT.
+
+ If you have made changes to your existing copy of the file components.xml in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
Note
+ How will you know whether you need to do this? If the upgrade output in the previous step included a message like the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+
warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+ Make a backup copy of your /etc/cloud/management/components.xml file. For example:
+
+ Merge your changes from the backup file into the new components.xml file.
+
#vi/etc/cloud/management/components.xml
+
+ If you have made changes to your existing copy of the /etc/cloud/management/db.properties file in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+ Make a backup copy of your file /etc/cloud/management/db.properties. For example:
+
+ Merge your changes from the backup file into the new db.properties file.
+
#vi/etc/cloud/management/db.properties
+ On the management server node, run the following command. It is recommended that you use the command-line flags to provide your own encryption keys. See Password and Key Encryption in the Installation Guide.
+
+ When used without arguments, as in the following example, the default encryption type and keys will be used:
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file.
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the properties file. Default: password. It is highly recommended that you replace this with a more secure value
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value.
+
+ Repeat steps 10 - 14 on every management server node. If you provided your own encryption key in step 14, use the same key on all other management servers.
+
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+
# service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. You should see a message like "Complete! Done." After confirmation, start the other Management Servers one at a time by running the same command on each node.
+
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
# service cloud-usage start
+ (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+
+ Configure your CloudStack package repositories as outlined in the Installation Guide
+
+ Stop the running agent.
+
# service cloud-agent stop
+ Update the agent software with one of the following command sets as appropriate.
+
#yum update cloud-*
+ #apt-get update
+#apt-get upgrade cloud-*
+
+ Start the agent.
+
# service cloud-agent start
+ Copy the contents of the agent.properties file to the new agent.properties file by using the following command
+
sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.properties
+ Start the cloud agent and cloud management services.
+
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+
+ Log in to the CloudStack UI as admin, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
+ Do not proceed to the next step until the hosts show in the Up state. If the hosts do not come to the Up state, contact support.
+
+ Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers.
+
+ Run the command once on one management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the "-c" and "-r" arguments. For example:
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+
+ After the script terminates, check the log to verify correct execution:
+
#tail -f sysvm.log
+ The content should be like the following:
+
+Stopping and starting 1 secondary storage vm(s)...
+Done stopping and starting secondary storage vm(s)
+Stopping and starting 1 console proxy vm(s)...
+Done stopping and starting console proxy vm(s).
+Stopping and starting 4 running routing vm(s)...
+Done restarting router(s).
+
+ If you would like additional confirmation that the new system VM templates were correctly applied when these system VMs were rebooted, SSH into the System VM and check the version.
+
+ Use one of the following techniques, depending on the hypervisor.
+
XenServer or KVM:
+ SSH in by using the link local IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own link local IP.
+
+ Run the following commands on the XenServer or KVM host on which the system VM is present:
+
Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
ESXi
+ SSH in using the private IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own private IP.
+
+ Run the following commands on the Management Server:
+
Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+
+ Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+
+ Disconnect the XenServer cluster from CloudStack.
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+
+ To clean up the VLAN, log in to one XenServer host and run:
+
/opt/xensource/bin/cloud-clean-vlan.sh
+ Prepare the upgrade by running the following on one XenServer host:
+
/opt/xensource/bin/cloud-prepare-upgrade.sh
+ If you see a message like "can't eject CD", log in to the VM and umount the CD, then run this script again.
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /root or /tmp.
+
+ On the Xen pool master, upload the hotfix with this command:
+
xe patch-upload file-name=XS602E003.xsupdate
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+
Note
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
# xe vm-list
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+ Apply the hotfix. First, get the UUID of this host:
+
+ # xe host-list
+
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+ If you are uploading a template that was created using vSphere Client, be sure the OVA file does not contain an ISO. If it does, the deployment of VMs from the template will fail.
+
+ Templates are uploaded based on a URL. HTTP is the supported access protocol. Templates are frequently large files. You can optionally gzip them to decrease upload times.
+
+ To upload a template:
+
+ In the left navigation bar, click Templates.
+
+ Click Create Template.
+
+ Provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+ URL. The Management Server will download the file from the specified URL, such as http://my.web.server/filename.vhd.gz.
+
+ Zone. Choose the zone where you want the template to be available, or All Zones to make it available throughout CloudStack.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following:
+
+ If the operating system of the stopped VM is listed, choose it.
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
Note
+ You should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+ Hypervisor
+
+ Format. The format of the template upload file, such as VHD or OVA.
+
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates
+
+ Extractable. Choose Yes if the template is available for extraction. If this option is selected, end users can download a full image of a template.
+
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”
+
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. The template will appear in the Featured Templates list. Only an administrator can make a template Featured.
+
+ For running and allocated virtual machine usage, the following fields exist in a usage record:
+
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for VM running time)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ virtualMachineId – The ID of the virtual machine
+
+ name – The name of the virtual machine
+
+ offeringid – The ID of the service offering
+
+ templateid – The ID of the template or the ID of the parent template. The parent template value is present when the current template was created from a volume.
+
+ usageid – Virtual machine
+
+ type – Hypervisor
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.2. Network Usage Record Format
+ For network usage (bytes sent/received), the following fields exist in a usage record.
+
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – Device ID (virtual router ID or external device ID)
+
+ type – Device type (domain router, external load balancer, etc.)
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.3. IP Address Usage Record Format
+ For IP address usage the following fields exist in a usage record.
+
+ account - name of the account
+
+ accountid - ID of the account
+
+ domainid - ID of the domain in which this account resides
+
+ zoneid - Zone where the usage occurred
+
+ description - A string describing what the usage record is tracking
+
+ usage - String representation of the usage, including the units of usage
+
+ usagetype - A number representing the usage type (see Usage Types)
+
+ rawusage - A number representing the actual usage in hours
+
+ usageid - IP address ID
+
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+ issourcenat - Whether source NAT is enabled for the IP address
+
+ iselastic - True if the IP address is elastic.
+
5.1.4. Disk Volume Usage Record Format
+ For disk volumes, the following fields exist in a usage record.
+
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – The volume ID
+
+ offeringid – The ID of the disk offering
+
+ type – Hypervisor
+
+ templateid – ROOT template ID
+
+ size – The amount of storage allocated
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.5. Template, ISO, and Snapshot Usage Record Format
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – The ID of the the template, ISO, or snapshot
+
+ offeringid – The ID of the disk offering
+
+ templateid – – Included only for templates (usage type 7). Source template ID.
+
+ size – Size of the template, ISO, or snapshot
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.6. Load Balancer Policy or Port Forwarding Rule Usage Record Format
+ account - name of the account
+
+ accountid - ID of the account
+
+ domainid - ID of the domain in which this account resides
+
+ zoneid - Zone where the usage occurred
+
+ description - A string describing what the usage record is tracking
+
+ usage - String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype - A number representing the usage type (see Usage Types)
+
+ rawusage - A number representing the actual usage in hours
+
+ usageid - ID of the load balancer policy or port forwarding rule
+
+ usagetype - A number representing the usage type (see Usage Types)
+
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.7. Network Offering Usage Record Format
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – ID of the network offering
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ offeringid – Network offering ID
+
+ virtualMachineId – The ID of the virtual machine
+
+ virtualMachineId – The ID of the virtual machine
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
5.1.8. VPN User Usage Record Format
+ account – name of the account
+
+ accountid – ID of the account
+
+ domainid – ID of the domain in which this account resides
+
+ zoneid – Zone where the usage occurred
+
+ description – A string describing what the usage record is tracking
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ rawusage – A number representing the actual usage in hours
+
+ usageid – VPN user ID
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+ Tracks the total running time of a VM per usage record period. If the VM is upgraded during the usage period, you will get a separate Usage Record for the new upgraded VM.
+
+
+ 2
+
+
+
+ ALLOCATED_VM
+
+
+
+ Tracks the total time the VM has been created to the time when it has been destroyed. This usage type is also useful in determining usage for specific templates such as Windows-based templates.
+
+
+
+ 3
+
+
+
+ IP_ADDRESS
+
+
+
+ Tracks the public IP address owned by the account.
+
+
+
+ 4
+
+
+
+ NETWORK_BYTES_SENT
+
+
+
+ Tracks the total number of bytes sent by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+
+ 5
+
+
+
+ NETWORK_BYTES_RECEIVED
+
+
+
+ Tracks the total number of bytes received by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+
+ 6
+
+
+
+ VOLUME
+
+
+
+ Tracks the total time a disk volume has been created to the time when it has been destroyed.
+
+
+
+ 7
+
+
+
+ TEMPLATE
+
+
+
+ Tracks the total time a template (either created from a snapshot or uploaded to the cloud) has been created to the time it has been destroyed. The size of the template is also returned.
+
+
+
+ 8
+
+
+
+ ISO
+
+
+
+ Tracks the total time an ISO has been uploaded to the time it has been removed from the cloud. The size of the ISO is also returned.
+
+
+
+ 9
+
+
+
+ SNAPSHOT
+
+
+
+ Tracks the total time from when a snapshot has been created to the time it have been destroyed.
+
+
+
+ 11
+
+
+
+ LOAD_BALANCER_POLICY
+
+
+
+ Tracks the total time a load balancer policy has been created to the time it has been removed. Cloud.com does not track whether a VM has been assigned to a policy.
+
+
+
+ 12
+
+
+
+ PORT_FORWARDING_RULE
+
+
+
+ Tracks the time from when a port forwarding rule was created until the time it was removed.
+
+
+
+ 13
+
+
+
+ NETWORK_OFFERING
+
+
+
+ The time from when a network offering was assigned to a VM until it is removed.
+
+
+
+ 14
+
+
+
+ VPN_USERS
+
+
+
+ The time from when a VPN user is created until it is removed.
+
+ 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.
+
diff --git a/docs/tmp/en-US/html/user-data-and-meta-data.html b/docs/tmp/en-US/html/user-data-and-meta-data.html
new file mode 100644
index 00000000000..afc7933560c
--- /dev/null
+++ b/docs/tmp/en-US/html/user-data-and-meta-data.html
@@ -0,0 +1,27 @@
+
+
+20.3. User Data and Meta Data
+ CloudStack provides API access to attach 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.
+
+ Access user data by running the following command using the result of the above command
+
# 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
+
+ In addition to the physical and logical infrastructure of your cloud, and the CloudStack software and servers, you also need a layer of user services so that people can actually make use of the cloud. This means not just a user UI, but a set of options and resources that users can choose from, such as templates for creating virtual machines, disk storage, and more. If you are running a commercial service, you will be keeping track of what services and resources users are consuming and charging them for that usage. Even if you do not charge anything for people to use your cloud – say, if the users are strictly internal to your organization, or just friends who are sharing your cloud – you can still keep track of what services they use and how much of them.
+
+ In zones that use advanced networking, additional networks for guest traffic may be added at any time after the initial installation. You can also customize the domain name associated with the network by specifying a DNS suffix for each network.
+
+ A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has been created, although the user can go into the guest and remove the IP address from the NIC on a particular network.
+
+ Each VM has just one default network. The virtual router's DHCP reply will set the guest's default gateway as that for the default network. Multiple non-default networks may be added to a guest in addition to the single, required default network. The administrator can control which networks are available as the default network.
+
+ Additional networks can either be available to all accounts or be assigned to a specific account. Networks that are available to all accounts are zone-wide. Any user with access to the zone can create a VM with access to that network. These zone-wide networks provide little or no isolation between guests.Networks that are assigned to a specific account provide strong isolation.
+
15.6.1. Adding an Additional Guest Network
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ Click Add guest network. Provide the following information:
+
+ Name: The name of the network. This will be user-visible.
+
+ Display Text: The description of the network. This will be user-visible.
+
+ Zone. The name of the zone this network applies to. Each zone is a broadcast domain, and therefore each zone has a different IP range for the guest network. The administrator must configure the IP range for each zone.
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network.
+
+ Guest Gateway: The gateway that the guests should use.
+
+ Guest Netmask: The netmask in use on the subnet the guests will use.
+
+ Click Create.
+
15.6.2. Changing the Network Offering on a Guest Network
+ A user or administrator can change the network offering that is associated with an existing guest network.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ If you are changing from a network offering that uses the CloudStack virtual router to one that uses external devices as network service providers, you must first stop all the VMs on the network. See Stopping and Starting VMs. Then return here and continue to the next step
+
+ In the left navigation, choose Network
+
+ Click the name of the network you want to modify
+
+ .
+
+ In Network Offering, choose the new network offering, then click Apply.
+
+ A prompt appears asking whether you want to keep the existing CIDR. This is to let you know that if you change the network offering, the CIDR will be affected. Choose No to proceed with the change.
+
+ Wait for the update to complete. Don’t try to restart VMs until after the network change is complete.
+
+ If you stopped any VMs in step 2, restart them.
+
+ In addition to the username and password authentication, CloudStack supports using SSH keys to log in to the cloud infrastructure for additional security. You can use the createSSHKeyPair API to generate the SSH keys.
+
+ Because each cloud user has their own SSH key, one cloud user cannot log in to another cloud user's instances unless they share their SSH key files. Using a single SSH key pair, you can manage multiple instances.
+
5.2.1. Creating an Instance Template that Supports SSH Keys
+ Create a instance template that supports SSH Keys.
+
+ Create a new instance by using the template provided by cloudstack.
+
+ For more information on creating a new instance, see
+
+ Download the cloudstack script from The SSH Key Gen Scriptto the instance you have created.
+
+ Run the script while starting up the operating system:
+
chkconfig --add cloud-set-guest-sshkey.in
+ Stop the instance.
+
5.2.2. Creating the SSH Keypair
+ You must make a call to the createSSHKeyPair api method. You can either use the CloudStack Python API library or the curl commands to make the call to the cloudstack api.
+
+ For example, make a call from the cloudstack server to create a SSH keypair called "keypair-doc" for the admin account in the root domain:
+
Note
+ Ensure that you adjust these values to meet your needs. If you are making the API call from a different server, your URL/PORT will be different, and you will need to use the API keys.
+
+ Apache CloudStack 4.0.0-incubating includes the following new features:
+
3.1.1. Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You can provision VLANs to the tiers your create, and VMs can be deployed on different tiers, such as Web, Application, or Database. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+
3.1.2. Site-to-Site VPN
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+
+ Cisco ISR with IOS 12.4 or later
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
3.1.3. Local Storage Support for Data Volumes
+ You can now create data volumes on local storage. The data volume is placed on the same XenServer host as the VM instance that is attached to the data volume. These local data volumes can be attached to virtual machines, detached, re-attached, and deleted just as with the other types of data volume. In earlier releases of CloudStack, only the root disk could be placed in local storage.
+
+ Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some of the benefits include reduced disk I/O latency and cost reduction from using inexpensive local disks.
+
+ In order for local volumes to be used, the feature must be enabled for the zone.
+
+ You can create a data disk offering for local storage. When a user creates a new VM, they can select this disk offering in order to cause the data disk volume to be placed in local storage.
+
+ You can not migrate a VM that has a volume in local storage to a different host, nor migrate the volume itself away to a different host. If you want to put a host into maintenance mode, you must first stop any VMs with local data volumes on that host.
+
+ Local storage support for volumes is available for XenServer, KVM, and VMware hypervisors.
+
3.1.4. Tags
+ 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 new 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.
+
+ A new optional input parameter, "tags," has been added to 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:
+
+ The following API commands have the new "tags" input parameter:
+
+ listVirtualMachines
+
+ listVolumes
+
+ listSnapshots
+
+ listNetworks
+
+ listTemplates
+
+ listIsos
+
+ listFirewallRules
+
+ listPortForwardingRules
+
+ listPublicIpAddresses
+
+ listSecurityGroups
+
+ listLoadBalancerRules
+
+ listProjects
+
+ listVPCs
+
+ listNetworkACLs
+
+ listStaticRoutes
+
3.1.5. AWS API Changes for Tags
+ Some changes have been made to the Amazon Web Services API compatibility support in order to accommodate the new tagging feature.
+
+ New APIs:
+
+
+ New API
+
+
+
+
+ Description
+
+
+
+
+ ec2-create-tags
+
+
+
+
+ Add tags to one or more resources.
+
+
+
+
+ ec2-delete-tags
+
+
+
+
+ Remove tags from one or more resources.
+
+
+
+ ec2-describe-tags
+
+
+ Show currently defined tags.
+
+
+
+ Changed APIs:
+
+
+ Changed API
+
+
+
+
+ Description
+
+
+
+ ec2-describe-images
+
+
+ Output now shows tags defined for each image.
+
+
+
+
+ ec2-describe-instances
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+ ec2-describe-snapshots
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+ ec2-describe-volumes
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
3.1.6. Secure Console Access on XenServer
+ With the addition of Secure Console feature, users can now securely access the VM consoles on the XenServer hypervisor. You can either SSH or use the View Console option in the Management Server to securely connect to the VMs on the XenServer host. The Management Server uses the xapi API to stream the VM consoles. However, there is no change in the way you can access the console of a VM. This feature is supported on XenServer 5.6 and 6.0 versions.
+
3.1.7. Stopped VM
+ This release supports creating VMs without starting them on the backend. You can determine whether the VM needs to be started as part of the VM deployment. A VM can be deployed in two ways: create and start a VM (the default method); create a VM and leave it in the stopped state.
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. The possible values are:
+
+ true - The VM starts as a part of the VM deployment
+
+ false - The VM is left in stopped state at the end of the VM deployment
+
3.1.8. Uploading an Existing Volume to a Virtual Machine
+ Existing data can now be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs. The upload is performed by using HTTP. The uploaded volume is placed in the zone's secondary storage.
+
+ This functionality is supported for the following hypervisors:
+
+ Hypervisor : Disk Image Format
+
+ XenServer : VHD
+
+ VMware : OVA
+
+ KVM : QCOW2
+
3.1.9. Dedicated High-Availability Hosts
+ One or more hosts can now be designated for use only by high-availability (HA) enabled VMs that are restarted due to a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HA-enabled VMs make it easier to determine which VMs are restarted as part of the high-availability function. You can designate a host as a dedicated-HA restart node only if the Dedicated HA Hosts feature is enabled by setting the appropriate global configuration parameter.
+
3.1.10. Support for Amazon Web Services API
+ This release supports Amazon Web Services APIs, including Elastic Compute Cloud (EC2) API. Fidelity with the EC2 API and the installation experience for this functionality are both enhanced. In prior releases, users were required to install a separate component called CloudBridge, in addition to installing the Management Server. For new installations of CloudStack 4.0.0-incubating, this software is installed automatically along with CloudStack and runs in a more closely integrated fashion. The feature is disabled by default, but can be easily enabled by setting the appropriate global configuration parameter and performing a few setup steps.
+
3.1.11. The Nicira NVP Plugin
+ The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating this plug-in supports the Connectivity service. This service is responsible for creating Layer 2 networks supporting the networks created by guests. When a tenant creates a new network, instead of a traditional VLAN, a logical network will be created by sending the appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira NVP versions 2.1.0, 2.2.0 and 2.2.1.
+
3.1.12. Support for CAStor Cluster
+ CloudStack 4.0.0-incubating supports using a CAStor cluster as the back-end storage system for a CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends the existing storage classes and allows the storage configuration attribute to point to a CAStor cluster. This feature makes use of the CloudStack server's local disk to spool files before writing them to CAStor when handling the PUT operations. However, a file must be successfully written into the CAStor cluster prior to the return of a success code to the S3 client to ensure that the transaction outcome is correctly reported.
+
+ The S3 multipart file upload is not supported in this release. You are prompted with proper error message if a multipart upload is attempted.
+
3.1.13. Clustered Logical Volume Manager Support for KVM
+ This release adds Clustered Logical Volume Manager (CLVM) storage support for KVM hosts. With this support, you can use CLVM as primary storage.
+
+ The CLVM support for KVM allows root and data disks (primary storage) to reside on Linux logical volumes. The administrators are required to configure CLVM on the KVM hosts independent of CloudStack. When the volume groups are available, an administrator can simply add primary storage of type CLVM, providing the volume group name. Then CloudStack creates and manages logical volumes as needed.
+
+ CLVM also supports Snapshots. CloudStack creates an LVM snapshot, copy the applicable logical volume to the secondary storage in the qcow2 format, and then delete the LVM snapshot.
+
3.1.14. Rados Block Device Support for KVM
+ You can now use Rados Block Device (RBD) to run instances on Apache CloudStack 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least 0.10 with RBD enabled on the KVM host
+
+ Create a disk offering for RBD so that you can ensure that StoragePoolAllocator chooses the RBD pool to deploy instances.
+
3.2. Issues Fixed in 4.0.0-incubating
+ Many bugs include a defect number that reflects the bug number that was held in the bug tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira to manage its bugs, so some of the bugs that are referenced here may not be available to view. However, we are still including them for completeness.
+
+
+ Defect
+
+
+
+
+ Description
+
+
+
+
+ Many
+
+
+
+ vSphere 5.0 now has GA support. Formerly only Beta support was provided.
+
+
+
+ CS-16135
+
+
+
+ Creating volumes after upgrading from snapshot taken in 2.2.14 no longer deletes the snapshot physically from the secondary storage.
+
+
+
+ CS-16122
+
+
+
+ In a site-to-site VPN setup, alerts are generated when the VPC virtual router is rebooted with multiple vpn connections.
+
+
+
+ CS-16022
+
+
+
+ If host connection fails due to a database error, host now disconnects and the Managerment Server id is removed.
+
+
+
+ CS-16011
+
+
+
+ Name of network offering is no longer truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+ CS-15978
+
+
+
+ When the virtual router and its host go down, the high availability mechanism now works for the virtual router.
+
+
+
+
+ CS-15921
+
+
+
+ The 2.2.x security group script now accounts for the VMs created in the version 2.1 timeframe.
+
+
+
+
+ CS-15919
+
+
+
+ A level parameter is added to the listVolumes command; therefore queries return the response more quickly.
+
+
+
+ CS-15904
+
+
+
+ Upgrade from version 2.2.14 to CloudStack-3.0.5-0.2944-rhel5 works as expected. The upgrade script, /usr/share/cloud/setup/db/schema-2214to30-cleanup.sql, works as expected.
+
+
+
+ CS-15879
+
+
+
+ The database upgrade from version 3.0.4 to 3.0.5 works as expected.
+
+
+
+
+ CS-15807
+
+
+
+ Network label for OVM now available in UI.
+
+
+
+
+ CS-15779
+
+
+
+ When the thumbnail is requested, the console session will not be terminated.
+
+
+
+
+ CS-15778
+
+
+
+ Fetching a VM thumbnail now gets a thumbnail of appropriate visual dimensions.
+
+
+
+
+ CS-15734
+
+
+
+ KVM Snapshots no longer shows incorrect disk usage.
+
+
+
+ CS-15733
+
+
+
+ The domainId parameter for the listNetworks command now lists the resources belonging to the domain specified.
+
+
+
+ CS-15676
+
+
+
+ Stopping the router no longer fails with the null pointer exception.
+
+
+
+
+ CS-15648
+
+
+
+ If creating a volume from a snapshot fails, the error is reported on the UI but the volume is stuck in the creating state.
+
+
+
+
+ CS-15646
+
+
+
+ createFirewallRule API no longer causes null pointer exception.
+
+
+
+ CS-15628
+
+
+
+ In a KVM host, the high availability mechanism no longer takes a long time to migrate VMs to another KVM host if there are multiple storage pools.
+
+
+
+ CS-15627
+
+
+
+ Metadata instance-id and vm-id for existing VMs stays the same after upgrade.
+
+
+
+ CS-15621
+
+
+
+ Solved difficulty with allocating disk volumes when running multiple VM deployment in parallel.
+
+
+
+ CS-15603
+
+
+
+ CloudStack now stop the VMs when destroyVM command is called.
+
+
+
+ CS-15586
+
+
+
+ Public Vlan for an account no longer fails if multiple physical networks are present.
+
+
+
+ CS-15582
+
+
+
+ The dns-name filter is now supported for ec2-describe-instances in the Amazon Web Services API compatibility commands. The filter maps to the name of a user VM.
+
+
+
+ CS-15503
+
+
+
+ An IP address which has static NAT rules can now be released. Subsequently, restarting this network after it was shutdown can succeed.
+
+
+
+ CS-15464
+
+
+
+ Can now delete static route whose state is set to Revoke.
+
+
+
+ CS-15443
+
+
+
+ Creating a firewall rule no longer fails with an internal server error.
+
+
+
+ CS-15398
+
+
+
+ Corrected technique for programming DNS on the user VMs.
+
+
+
+ CS-15356
+
+
+
+ Internal DNS 2 entry now correctly shown in UI.
+
+
+
+ CS-15335
+
+
+
+ The CloudBridge S3 Engine now connects to the database by using the deciphered password in the db.properties file.
+
+
+
+ CS-15318
+
+
+
+ UI now correctly prevents the user from stopping a VM that is in the Starting state.
+
+
+
+ CS-15307
+
+
+
+ Fixed Japanese localization of instance statuses in the Instances menu.
+
+
+
+ CS-15278
+
+
+
+ The deployment planner no longer takes long time to locate a suitable host to deploy VMs when large number of clusters are present.
+
+
+
+ CS-15274
+
+
+
+ Creating a VLAN range using Zone ID without network ID now succeeds.
+
+
+
+ CS-15243
+
+
+
+ Now check to be sure source NAT and VPN have same provider.
+
+
+
+ CS-15232
+
+
+
+ Ensure that networks using external load balancer/firewall in 2.2.14 or earlier can properly upgrade.
+
+
+
+ CS-15200
+
+
+
+ No exception when trying to attach the same volume while attaching the first volume is in progress.
+
+
+
+ CS-15173
+
+
+
+ Additional cluster can no longer be added with same VSM IP address as another cluster.
+
+
+
+ CS-15167
+
+
+
+ AWS API calls now honor the admin account's ability to view or act on the resources owned by the regular users.
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+ CS-15157
+
+
+
+ Can now add/enable service providers for multiple physical networks through the UI.
+
+
+
+ CS-15145
+
+
+
+ AWS API call ec2-register has better error handling for negative cases.
+
+
+
+ CS-15122
+
+
+
+ Filters now supported for AWS API call ec2-describe-availability-zones.
+
+
+
+ CS-15120
+
+
+
+ Actions column in UI of Volume page now shows action links.
+
+
+
+ CS-15099
+
+
+
+ Buttons no longer overlap text on Account Deletion confirmation page in UI.
+
+
+
+ CS-15095
+
+
+
+ Ensures you can not create a VM with a CPU frequency greater than the host CPU frequency.
+
+
+
+ CS-15094
+
+
+
+ CPU cap now set properly in VMware.
+
+
+
+ CS-15077
+
+
+
+ NullPointerException is no longer observed while executing the command to list the public IP in a basic zone created with the default shared NetScaler EIP and ELB network offering.
+
+
+
+ CS-15044
+
+
+
+ UI now provides option to view the list of instances which are part of the guest network.
+
+
+
+ CS-15026
+
+
+
+ UI in Deploy VM dialog now lists only templates or ISOs depending on which is selected in previous dialog.
+
+
+
+ CS-14989
+
+
+
+ In KVM, the Create Instance wizard now shows only templates from the current (KVM) zone.
+
+
+
+ CS-14986, CS-14985
+
+
+
+ Listing filters works as expected in the ec2-describe-volumes and ec2-describe-snapshots commands.
+
+
+
+ CS-14964
+
+
+
+ Automatically starting the Console Proxy no longer fails due to its missing volume on the primary storage
+
+
+
+ CS-14907
+
+
+
+ User is now correctly prevented from trying to download an uploaded volume which has not yet been moved to primary storage.
+
+
+
+ CS-14879
+
+
+
+ When a user VM is stopped or terminated, the static NAT associated with this VM is now disabled. This public IP address is no longer owned by this account and can be associated to any other user VM.
+
+
+
+ CS-14854
+
+
+
+ Only the admin user can change the template permission to Public, so this option is removed from the UI for domain Admins and regular Users.
+
+
+
+ CS-14817
+
+
+
+ While checking if network has any external provider, CloudStack will consider all providers in the network.
+
+
+
+ CS-14796
+
+
+
+ When deploying a VM with ec2-run-instances, userdata is now encoded.
+
+
+
+ CS-14770
+
+
+
+ The API returns the keypair information when a VM is deployed with sshkey. This affects the API commands related to virtual machines (deployVirtualMachine, listVirtualMachines, ... *VirtualMachine), as well as the corresponding AWS APIs.
+
+
+
+ CS-14724
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+ CS-14345
+
+
+
+ Logout API returns XML header.
+
+
+
+ CS-14724
+
+
+
+ Host IPs now associated with appropriate IPs according to traffic type.
+
+
+
+ CS-14253
+
+
+
+ Can now delete and re-create port forwarding rule on same firewall.
+
+
+
+ CS-14724
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+ CS-14452
+
+
+
+ Data disk volumes are now automatically copied from one cluster to another.
+
+
+
+ CS-13539
+
+
+
+ Windows VM can get IP after reboot.
+
+
+
+ CS-13537
+
+
+
+ When user tries to delete a domain that contains sub-domains, an error message is now sent to convey the reason for the delete failure.
+
+
+
+ CS-13153
+
+
+
+ System VMs support HTTP proxy.
+
+
+
+ CS-12642
+
+
+
+ Added Close button to Select Project list view popup in UI.
+
+
+
+ CS-12510
+
+
+
+ Deleting and reinserting host_details no longer causes deadlocks.
+
+
+
+ CS-12407
+
+
+
+ F5 and Netscaler - when dedicated is selected, capacity field is disabled.
+
+
+
+ CS-12111
+
+
+
+ Email validation for edit user form.
+
+
+
+ CS-10928
+
+
+
+ Network read/write values now always positive numbers.
+
+
+
+ CS-15376, CS-15373
+
+
+
+ The AWS APIs (EC2 and S3) now listen on the 7080 port and send request to CloudStack on the 8080 port just as any other clients of CloudStack.
+
+
+
+ CS-13944
+
+
+
+ The CloudStack 2.2.x to 3.0.x database upgrade for multiple physical networks is now supported.
+
+
+
+ CS-15300
+
+
+
+ The admin accounts of a domain now honour the limits imposed on that domain just like the regular accounts do. A domain admin now is not allowed to create an unlimited number of instances, volumes, snapshots, and so on.
+
+
+
+ CS-15396
+
+
+
+ The CloudStack database now contain the UUD information after the 2.2.14 to 3.0.4 upgrade.
+
+
+
+ CS-15450
+
+
+
+ Upgrade from 2.2.14 to 3.0.4 no longer fails on a VMware host.
+
+
+
+ CS-15449
+
+
+
+ Running cloudstack-aws-api-register no longer fails with the "User registration failed with error: [Errno 113] No route to host" error.
+
+
+
+ CS-15455
+
+
+
+ The iptable rules are configured to open the awsapi port (7080) as part of the installation.
+
+
+
+ CS-15429
+
+
+
+ While creating an instance with data volume, disk offering also is considered while checking the account limit on volume resources.
+
+
+
+ CS-15414
+
+
+
+ After the 2.2.14 to 3.0.4 upgrade, the value of the global parameter xen.guest.network.device is now decrypted before setting the traffic label.
+
+
+
+ CS-15382
+
+
+
+ During 2.2.14 to 3.0.4 upgrade, the hosts no longer go to the Alert state if destroyed networks existed with non-existent tags prior to upgrade.
+
+
+
+ CS-15323
+
+
+
+ CloudStack supports the following Citrix XenServer hotfixes: XS602E003, XS602E004, and XS602E005.
+
+
+
+ CS-15430
+
+
+
+ Create snapshot now fails if creating a snapshot exceeds the snapshot resource limit for a domain admin or a user account.
+
+
+
+ CS-14256
+
+
+
+ Virtual Router no longer remains in starting state for subdomain or user on a KVM 3.0.1 prerlease host on RHEL 6.2.
+
+
+
+ CS-7495
+
+
+
+ Implemented a variety of Xen management host improvements.
+
+
+
+ CS-8105
+
+
+
+ NFS v4 for primary storage now works as expected on KVM hosts.
+
+
+
+ CS-9989
+
+
+
+ The error messages returned during VM deployment failure will have much more details than before.
+
+
+
+ CS-12584
+
+
+
+ You can no longer add security groups not supported by the hypervisor in use.
+
+
+
+ CS-12705
+
+
+
+ When creating a Network offering by using SRX as the service provider for SourceNAT servcies, an option is given in the CloudStack UI now to set the source_nat type to "per Zone"/"per account".
+
+
+
+ CS-12782
+
+
+
+ Assigning a VM from Basic to Advanced zone no longer ignores the network ID. A warning message is displayed for VM movements across zones.
+
+
+
+ CS-12591
+
+
+
+ Broadcast Address on the Second Public IP NIC is now corrected.
+
+
+
+ CS-13272
+
+
+
+ When a user is deleted, all the associated properties, such as IPs and virtual routers, are now deleted.
+
+
+
+ CS-13377
+
+
+
+ Creating template from a root disk of a stopped instance now provides an option to make it a "Featured template".
+
+
+
+ CS-13500
+
+
+
+ Reaching the first guest VM by using its public IP from the second guest VM no longer fails.
+
+
+
+ CS-13853
+
+
+
+ The default gateway can no longer be 0.0.0.0 in the Secondary Storage VM (SSVM).
+
+
+
+ CS-13863
+
+
+
+ The queryAsyncJobResult command in XML format now returns the correct UUIDs.
+
+
+
+ CS-13867
+
+
+
+ Corrected CSP xenserver-cloud-supp.tgz for XenServer 5.6 and 6.0.
+
+
+
+ CS-13904
+
+
+
+ Labels and values for the service offerings CPU and memory are now consistent.
+
+
+
+ CS-13998
+
+
+
+ The SSVM kernel panic issue is fixed on XenServer.
+
+
+
+ CS-14090
+
+
+
+ The issue is fixed where running the VMware snapshots randomly fails with the ArrayIndexOutOfBoundsException error.
+
+
+
+ CS-14021
+
+
+
+ The java.lang.OutOfMemoryError is fixed on the Management Server.
+
+
+
+ CS-14025
+
+
+
+ The Python Eggs are provided to easily package the test client for each branch of CloudStack.
+
+
+
+ CS-14068
+
+
+
+ Resetting the VM password through the CloudStack UI no longer causes any error.
+
+
+
+ CS-14156
+
+
+
+ The pod which has the administrator's virtual router is no longer selected while creating the virtual routers for guests.
+
+
+
+ CS-14182
+
+
+
+ The users can now delete their ISOs as normal users.
+
+
+
+ CS-14185
+
+
+
+ The listOSTypes API now filters out the types of operating system by using the keywords.
+
+
+
+ CS-14204
+
+
+
+ The cloud-setup-bonding.sh command no longer generates the "command not found" error.
+
+
+
+ CS-14214
+
+
+
+ The Specify VLAN option cannot be enabled now for an isolated Network offering with SourceNAT enabled.
+
+
+
+ CS-14234
+
+
+
+ Sending project invite email to an account now requires SMTP configured in CloudStack.
+
+
+
+ CS-14237
+
+
+
+ The garbage collector of the primary storage no longer fails when the first host in the cluster is not up.
+
+
+
+ CS-14241
+
+
+
+ Custom Volume Disk Offering is now matching the Global configuration value.
+
+
+
+ CS-14270
+
+
+
+ The listNetworks API no longer assumes that the broadcast type is always VLAN.
+
+
+
+ CS-14319
+
+
+
+ The internal name of the VM is no longer present in the error message that is displayed to a domain administrator.
+
+
+
+ CS-14321
+
+
+
+ The listVolumes API call now returns a valid value for the isExtractable parameter for the ISO-derived disk and data disk volumes.
+
+
+
+ CS-14323
+
+
+
+ Invalid API calls will now give valid response in json/xml format.
+
+
+
+ CS-14339
+
+
+
+ Custom Disk Size will now allow values larger than 100GB.
+
+
+
+ CS-14357
+
+
+
+ The ConsoleProxyLoadReportCommand is no longer fired continuously.
+
+
+
+ CS-14421
+
+
+
+ Fixed the issue of virtual router deployments. The DHCP entries can now be assigned to the router.
+
+
+
+ CS-14555
+
+
+
+ Unzipped downloaded template MD5SUM will no longer override the zipped template MD5SUM in the database.
+
+
+
+ CS-14598
+
+
+
+ The complete screen of the running VM is now displayed in the console proxy.
+
+
+
+ CS-14600
+
+
+
+ Windows or Linux based consoles are no longer lost upon rebooting VMs.
+
+
+
+ CS-14784
+
+
+
+ Multiple subnets with the same VLAN now work as expected.
+
+
+
+ CS-13303, 14874, 13897, 13944, 14088, 14190
+
+
+
+ A variety of upgrade issues have been fixed in release 3.0.3.
+
+
+
+ CS-15080
+
+
+
+ Setting a private network on a VLAN for VMWare environment is now supported.
+
+
+
+ CS-15168
+
+
+
+ The console proxy now works as expected and no exception is shown in the log after upgrading from version 2.2.14 to 3.0.2.
+
+
+
+ CS-15172
+
+
+
+ Version 3.0.2 now accepts the valid public key.
+
+
3.3. Known Issues in 4.0.0-incubating
+
+ Issue ID
+
+
+
+
+ Description
+
+
+
+
+ CLOUDSTACK-301
+
+
+
+ Nexus 1000v DVS integration is not functional
+
+
+ This source code release includes some partial functionality to support the Cisco Nexus 1000v Distributed Virtual Switch within a VMware hypervisor environment. The functionality is not complete at this time.
+
+
+
+
+ CLOUDSTACK-368
+
+
+
+ OVM - cannot create guest VM
+
+
+ This source code release has regressed from the CloudStack 2.2.x code and is unable to support Oracle VM (OVM).
+
+
+
+
+ CLOUDSTACK-279
+
+
+
+ Deleting a project fails when executed by the regular user. This works as expected for root/domain admin. To workaround, perform either of the following:
+
+
+ Use the account cleanup thread which will eventually complete the project deletion.
+
+ Execute the call as the root/domain admin on behalf of the regular user.
+
+
+
+
+ CS-16067
+
+
+
+ The command=listTags&key=city command does not work as expected. The command does not return tags for the resources of the account with the tag, city
+
+
+
+
+ CS-16063
+
+
+
+ The current values of volumes and snapshots are incorrect when using KVM as a host. To fix this, the database upgrade codes, volumes.size and snapshots.size, should be changed to show the virtual sizes.
+
+
+
+
+ CS-16058
+
+
+
+ Null pointer Exception while deleting the host after moving the host to maintenance state.
+
+
+
+
+ CS-16045
+
+
+
+ Only the root administrator can handle the API keys. The domain administrators are not allowed to create, delete, or retrieve API keys for the users in their domain.
+
+
+
+
+ CS-16019
+
+
+
+ CIDR list in the Add VPN Customer Gateway dialog does not prompt the user that they can provide a comma separated CIDRs if multiple CIDRs have to be supplied.
+
+
+
+
+ CS-16015
+
+
+
+ Deleting a network is not supported when its network providers are disabled.
+
+
+
+
+ CS-16012
+
+
+
+ Unable to delete a zone in the UI because the necessary cleanup cannot be completed. When the hosts are removed, the expunge process fails to delete the volumes as no hosts are present to send the commands to. Therefore, the storage pool removal fails, and zone can't be cleaned and deleted.
+
+
+
+
+ CS-16011
+
+
+
+ Name of network offering might be truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+ CS-15789
+
+
+
+ Invalid global setting prevents management server to restart. For example, if you configure the "project.invite.timeout" parameter to "300" and attempt to restart management server, it fails without throwing a warning or setting the value to the default.
+
+
+
+
+ CS-15749
+
+
+
+ Restarting VPC is resulting in intermittent connection loss to the port forwarding and StaticNAT rules.
+
+
+
+
+ CS-15690
+
+
+
+ The IpAssoc command failed as a part of starting the virtual router, but the final start result is reported as succes.
+
+
+
+
+ CS-15672, CS-15635
+
+
+
+ The FQDN of the VM is not configured if it is deployed as a part of default shared network and isolated guest network (DefaultIsolatedNetworkOfferingWithSourceNatService).
+
+
+
+
+ CS-15634
+
+
+
+ The FQDN of a VM that is deployed as a part of both a shared network and default isolated guest network has the suffix of the shared network instead of the default isolated guest network.
+
+
+
+
+ CS-15576
+
+
+
+ Stopping a VM on XenServer creates a backlog of API commands. For example, the Attach volume calls become delayed while waiting for the stopVirtualMachine command to be executed.
+
+
+
+
+ CS-15569
+
+
+
+ Misleading error message in the exception when creating a StaticNAT rule fails in a VPC.
+
+
+
+
+ CS-15566
+
+
+
+ External device such as Netscaler is not supported in VPC.
+
+
+
+ CS-15557
+
+
+
+ Intermittent traffic loss in the VPN connection if Juniper is the remote router and the life time is 300 seconds.
+
+
+
+
+ CS-15361
+
+
+
+ Egress rules are not working in NetScaler loadbalancer.
+
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+ CS-15105
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+ CS-15092
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+ CS-15037
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+ CS-15009
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+ CS-14939
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+ CS-14780
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+ CS-14756
+
+
+
+ Installing KVM on RHEL 6.2 will result in unreliable network performance. Workaround: blacklist vhost-net. Edit /etc/modprobe.d/blacklist-kvm.conf and include vhost-net.
+
+
+
+ CS-14346
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+ CS-14303 (was 14537)
+
+
+
+ The IP addresses for a shared network are still being consumed even if no services are defined for that network.
+
+
+
+ CS-14296 (was 14530)
+
+
+
+ OVM: Network traffic labels are not supported.
+
+
+
+ CS-14291 (was 14523)
+
+
+
+ The EIP/ELB network offering for basic zones does not support multiple NetScalers.
+
+
+
+ CS-14275 (was 14506)
+
+
+
+ F5: Unable to properly remove a F5 device.
+
+
+
+ CS-14201 (was 14430)
+
+
+
+ VMWare: Template sizes are being reported different depending on whether the primary storage is using ISCSI or NFS.
+
+
+
+ CS-13758 (was 13963)
+
+
+
+ vSphere: template download from templates created off of the root volume does not work properly.
+
+
+
+ CS-13733 (was 13935)
+
+
+
+ vSphere: detaching an ISO from a restored VM instance fails.
+
+
+
+ CS-13682 (was 13883)
+
+
+
+ Multiple NetScalers are not supported in Basic Networking.
+
+
+
+ CS-13599 (was 13359)
+
+
+
+ Programming F5/NetScaler rules can be better optimized.
+
+
+
+ CS-13337 (was 13518)
+
+
+
+ Security Groups are not supported in Advanced Networking
+
+
+
+ CS-13173 (was 13336)
+
+
+
+ vSphere: cross cluster volume migration does not work properly.
+
+
+
+ CS-12714 (was 12840)
+
+
+
+ Capacity view is not available for pods or clusters.
+
+
+
+ CS-12624 (was 12741)
+
+
+
+ vSphere: maintenance mode will not live migrate system VM to another host.
+
+
+
+ CS-15476
+
+
+
+
+ The 2.2.14 to 4.0.0-incubating upgrade fails if multiple untagged physical networks exist before the upgrade.
+
+
+
+
+ CS-15407
+
+
+
+
+ After the 2.2.14 to 4.0.0-incubating upgrade, VLAN allocation on multiple physical networks does not happen as expected.
+
+
+ To workaround this issue, follow the instructions given below:
+
+
+ Revert to your 2.2.14 setup.
+
+ Stop all the VMs with the isolated virtual networks in your cloud setup.
+
+ Run following query to find if any networks still have the NICs allocated:
+
+ Check if any virtual guest networks have the NICs allocated:
+
#SELECT DISTINCT op.id from `cloud`.`op_networks` op JOIN `cloud`.`networks` n on op.id=n.id WHERE nics_count != 0 AND guest_type = 'Virtual';
+ If this returns any network IDs, then ensure the following:
+
+ All the VMs are stopped.
+
+ No new VM is started.
+
+ Shutdown the Management Server.
+
+ Remove the NICs count for the virtual network IDs returned in step (a), and set the NIC count to 0:
+
UPDATE `cloud`.`op_networks` SET nics_count = 0 WHERE id = enter id of virtual network
+ Restart the Management Server, and wait for all the networks to shut down.
+
Note
+ Networks shutdown is determined by the network.gc.interval and network.gc.wait parameters.
+
+ Ensure that all the networks are shut down and all the guest VNETs are free.
+
+ Run the upgrade script.
+
+ This allocates all your guest VNET ranges to the first physical network.
+
+ By using the updatePhysicalNetwork API, reconfigure the VNET ranges for each physical network as desired.
+
+ Start all the VMs.
+
+
+
+
+ CS-14680
+
+
+
+
+ CloudStack and LDAP user validation cannot happen simultaneously because the user password is hashed and stored in the database, and LDAP requires the passwords in plain text.
+
+
+ To work with the LDAP user, the MD5 hash should be disabled in the login process by commenting the following variable in sharedFunctions.js file available at /usr/share/cloud/management/webapps/client/scripts, and restart the cloud-management service.
+
+
+
var md5HashedLogin = false;
+
+ However, if md5HashedLogin is set to false, the end user can login with the LDAP credentials but not with the CloudStack user credentials.
+
+
+
+
+ CS-14346
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+ CS-15130
+
+
+
+ Data disk volumes are not automatically copied from one cluster to another.
+
+
+
+ CS-14780
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+ CS-14939
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+ CS-15009
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+ CS-15037
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+ CS-15092
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+ CS-15105
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+ The virtual router is a type of System Virtual Machine. The virtual router is one of the most frequently used service providers in CloudStack. The end user has no direct access to the virtual router. Users can ping the virtual router and take actions that affect it (such as setting up port forwarding), but users do not have SSH access into the virtual router.
+
+ There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be restarted by administrators, but this will interrupt public network access and other services for end users. A basic test in debugging networking issues is to attempt to ping the virtual router from a guest VM. Some of the characteristics of the virtual router are determined by its associated system service offering.
+
+ 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.
+
+ Virtual machines can be in the following states:
+
+ Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual machine will be reclaimed by the system. This includes the virtual machine’s IP address.
+
+ A stop will attempt to gracefully shut down the operating system, which typically involves terminating all the running applications. If the operation system cannot be stopped, it will be forcefully terminated. This has the same effect as pulling the power cord to a physical machine.
+
+ A reboot is a stop followed by a start.
+
+ CloudPlatform preserves the state of the virtual machine hard disk until the machine is destroyed.
+
+ A running virtual machine may fail because of hardware or network issues. A failed virtual machine is in the down state.
+
+ The system places the virtual machine into the down state if it does not receive the heartbeat from the hypervisor for three minutes.
+
+ The user can manually restart the virtual machine from the down state.
+
+ The system will start the virtual machine from the down state automatically if the virtual machine is marked as HA-enabled.
+
8.3. VMware vSphere Installation and Configuration
+ If you want to use the VMware vSphere hypervisor to run guest virtual machines, install vSphere on the host(s) in your cloud.
+
8.3.1. System Requirements for vSphere Hosts
8.3.1.1. Software requirements:
+ vSphere and vCenter, both version 4.1 or 5.0.
+
+ vSphere Standard is recommended. Note however that customers need to consider the CPU constraints in place with vSphere licensing. See http://www.vmware.com/files/pdf/vsphere_pricing.pdf and discuss with your VMware sales representative.
+
+ vCenter Server Standard is recommended.
+
+ 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.
+
Apply All Necessary Hotfixes
+ The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled).
+
+ All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+ Hardware virtualization support required
+
+ 4 GB of memory
+
+ 36 GB of local disk
+
+ At least 1 NIC
+
+ Statically allocated IP Address
+
8.3.1.3. vCenter Server requirements:
+ Processor - 2 CPUs 2.0GHz or higher Intel or AMD x86 processors. Processor requirements may be higher if the database runs on the same machine.
+
+ Memory - 3GB RAM. RAM requirements may be higher if your database runs on the same machine.
+
+ Disk storage - 2GB. Disk requirements may be higher if your database runs on the same machine.
+
+ Microsoft SQL Server 2005 Express disk requirements. The bundled database requires up to 2GB free disk space to decompress the installation archive.
+
+ VMware vCenter Standard Edition 4.1 or 5.0 must be installed and available to manage the vSphere hosts.
+
+ vCenter must be configured to use the standard port 443 so that it can communicate with the CloudStack Management Server.
+
+ You must re-install VMware ESXi if you are going to re-use a host from a previous install.
+
+ CloudStack requires VMware vSphere 4.1 or 5.0. VMware vSphere 4.0 is not supported.
+
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled). All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+
+ The CloudStack management network must not be configured as a separate virtual network. The CloudStack management network is the same as the vCenter management network, and will inherit its configuration. See Section 8.3.5.2, “Configure vCenter Management Network”.
+
+ CloudStack requires ESXi. ESX is not supported.
+
+ All resources used for CloudStack must be used for CloudStack only. CloudStack cannot share instance of ESXi or storage with other management consoles. Do not share the same storage volumes that will be used by CloudStack with a different set of ESXi servers that are not managed by CloudStack.
+
+ Put all target ESXi hypervisors in a cluster in a separate Datacenter in vCenter.
+
+ The cluster that will be managed by CloudStack should not contain any VMs. Do not run the management server, vCenter or any other VMs on the cluster that is designated for CloudStack use. Create a separate cluster for use of CloudStack and make sure that they are no VMs in this cluster.
+
+ All the required VLANS must be trunked into all network switches that are connected to the ESXi hypervisor hosts. These would include the VLANS for Management, Storage, vMotion, and guest VLANs. The guest VLAN (used in Advanced Networking; see Network Setup) is a contiguous range of VLANs that will be managed by CloudStack.
+
8.3.2. Preparation Checklist for VMware
+ For a smoother installation, gather the following information before you start:
+
+ You will need the following information about vCenter.
+
+
+ vCenter Requirement
+
+
+
+ Value
+
+
+
+ Notes
+
+
+
+ vCenter User
+
+
+
+
+
+
+ This user must have admin privileges.
+
+
+
+ vCenter User Password
+
+
+
+
+
+
+ Password for the above user.
+
+
+
+ vCenter Datacenter Name
+
+
+
+
+
+
+ Name of the datacenter.
+
+
+
+ vCenter Cluster Name
+
+
+
+
+
+
+ Name of the cluster.
+
+
8.3.2.2. Networking Checklist for VMware
+ You will need the following information about VLAN.
+
+
+ VLAN Information
+
+
+
+ Value
+
+
+
+ Notes
+
+
+
+ ESXi VLAN
+
+
+
+
+
+
+ VLAN on which all your ESXi hypervisors reside.
+
+
+
+ ESXI VLAN IP Address
+
+
+
+
+
+
+ IP Address Range in the ESXi VLAN. One address per Virtual Router is used from this range.
+
+
+
+ ESXi VLAN IP Gateway
+
+
+
+
+
+
+
+
+
+ ESXi VLAN Netmask
+
+
+
+
+
+
+
+
+
+ Management Server VLAN
+
+
+
+
+
+
+ VLAN on which the CloudStack Management server is installed.
+
+
+
+ Public VLAN
+
+
+
+
+
+
+ VLAN for the Public Network.
+
+
+
+ Public VLAN Gateway
+
+
+
+
+
+
+
+
+
+ Public VLAN Netmask
+
+
+
+
+
+
+
+
+
+ Public VLAN IP Address Range
+
+
+
+
+
+
+ Range of Public IP Addresses available for CloudStack use. These addresses will be used for virtual router on CloudStack to route private traffic to external networks.
+
+
+
+ VLAN Range for Customer use
+
+
+
+
+
+
+ A contiguous range of non-routable VLANs. One VLAN will be assigned for each customer.
+
+ Following installation, perform the following configuration, which are described in the next few sections:
+
+
+ Required
+
+
+
+ Optional
+
+
+
+ ESXi host setup
+
+
+
+ NIC bonding
+
+
+
+ Configure host physical networking, virtual switch, vCenter Management Network, and extended port range
+
+
+
+ Multipath storage
+
+
+
+ Prepare storage for iSCSI
+
+
+
+
+
+
+ Configure clusters in vCenter and add hosts to them, or add hosts without clusters to vCenter
+
+
+
+
+
8.3.4. ESXi Host setup
+ All ESXi hosts should enable CPU hardware virtualization support in BIOS. Please note hardware virtualization support is not enabled by default on most servers.
+
8.3.5. Physical Host Networking
+ You should have a plan for cabling the vSphere hosts. Proper network configuration is required before adding a vSphere host to CloudStack. To configure an ESXi host, you can use vClient to add it as standalone host to vCenter first. Once you see the host appearing in the vCenter inventory tree, click the host node in the inventory tree, and navigate to the Configuration tab.
+
+ In the host configuration tab, click the "Hardware/Networking" link to bring up the networking configuration page as above.
+
8.3.5.1. Configure Virtual Switch
+ A default virtual switch vSwitch0 is created. CloudStack requires all ESXi hosts in the cloud to use the same set of virtual switch names. If you change the default virtual switch name, you will need to configure one or more CloudStack configuration variables as well.
+
8.3.5.1.1. Separating Traffic
+ CloudStack allows you to use vCenter to configure three separate networks per ESXi host. These networks are identified by the name of the vSwitch they are connected to. The allowed networks for configuration are public (for traffic to/from the public internet), guest (for guest-guest traffic), and private (for management and usually storage traffic). You can use the default virtual switch for all three, or create one or two other vSwitches for those traffic types.
+
+ If you want to separate traffic in this way you should first create and configure vSwitches in vCenter according to the vCenter instructions. Take note of the vSwitch names you have used for each traffic type. You will configure CloudStack to use these vSwitches.
+
8.3.5.1.2. Increasing Ports
+ By default a virtual switch on ESXi hosts is created with 56 ports. We recommend setting it to 4088, the maximum number of ports allowed. To do that, click the "Properties..." link for virtual switch (note this is not the Properties link for Networking).
+
+ In vSwitch properties dialog, select the vSwitch and click Edit. You should see the following dialog:
+
+ In this dialog, you can change the number of switch ports. After you've done that, ESXi hosts are required to reboot in order for the setting to take effect.
+
8.3.5.2. Configure vCenter Management Network
+ In the vSwitch properties dialog box, you may see a vCenter management network. This same network will also be used as the CloudStack management network. CloudStack requires the vCenter management network to be configured properly. Select the management network item in the dialog, then click Edit.
+
+ Make sure the following values are set:
+
+ VLAN ID set to the desired ID
+
+ vMotion enabled.
+
+ Management traffic enabled.
+
+ If the ESXi hosts have multiple VMKernel ports, and ESXi is not using the default value "Management Network" as the management network name, you must follow these guidelines to configure the management network port group so that CloudStack can find it:
+
+ Use one label for the management network port across all ESXi hosts.
+
+ In the CloudStack UI, go to Configuration - Global Settings and set vmware.management.portgroup to the management network label from the ESXi hosts.
+
8.3.5.3. Extend Port Range for CloudStack Console Proxy
+ (Applies only to VMware vSphere version 4.x)
+
+ You need to extend the range of firewall ports that the console proxy works with on the hosts. This is to enable the console proxy to work with VMware-based VMs. The default additional port range is 59000-60000. To extend the port range, log in to the VMware ESX service console on each host and run the following commands:
+
+ NIC bonding on vSphere hosts may be done according to the vSphere installation guide.
+
8.3.6. Storage Preparation for vSphere (iSCSI only)
+ Use of iSCSI requires preparatory work in vCenter. You must add an iSCSI target and create an iSCSI datastore.
+
+ If you are using NFS, skip this section.
+
8.3.6.1. Enable iSCSI initiator for ESXi hosts
+ In vCenter, go to hosts and Clusters/Configuration, and click Storage Adapters link. You will see:
+
+ Select iSCSI software adapter and click Properties.
+
+ Click the Configure... button.
+
+ Check Enabled to enable the initiator.
+
+ Click OK to save.
+
8.3.6.2. Add iSCSI target
+ Under the properties dialog, add the iSCSI target info:
+
+ Repeat these steps for all ESXi hosts in the cluster.
+
8.3.6.3. Create an iSCSI datastore
+ You should now create a VMFS datastore. Follow these steps to do so:
+
+ Select Home/Inventory/Datastores.
+
+ Right click on the datacenter node.
+
+ Choose Add Datastore... command.
+
+ Follow the wizard to create a iSCSI datastore.
+
+ This procedure should be done on one host in the cluster. It is not necessary to do this on all hosts.
+
8.3.6.4. Multipathing for vSphere (Optional)
+ Storage multipathing on vSphere nodes may be done according to the vSphere installation guide.
+
8.3.7. Add Hosts or Configure Clusters (vSphere)
+ Use vCenter to create a vCenter cluster and add your desired hosts to the cluster. You will later add the entire cluster to CloudStack. (see Section 6.4.2, “Add Cluster: vSphere”).
+
+ CloudStack account owners can create virtual private networks (VPN) to access their virtual machines. If the guest network is instantiated from a network offering that offers the Remote Access VPN service, the virtual router (based on the System VM) is used to provide the service. CloudStack provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN. CloudStack does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.
+
Note
+ Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
+
+ Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
+
+ Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.
+
15.17.1. Configuring VPN
+ To set up VPN for the cloud:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, click Global Settings.
+
+ Set the following global configuration parameters.
+
+ remote.access.vpn.client.ip.range – The range of IP addressess to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
+
+ remote.access.vpn.psk.length – Length of the IPSec key.
+
+ remote.access.vpn.user.limit – Maximum number of VPN users per account.
+
+ To enable VPN for a particular network:
+
+ Log in as a user or administrator to the CloudStack UI.
+
+ In the left navigation, click Network.
+
+ Click the name of the network you want to work with.
+
+ Click View IP Addresses.
+
+ Click one of the displayed IP address names.
+
+ Click the Enable VPN button
+
+ .
+
+ The IPsec key is displayed in a popup window.
+
15.17.2. Using VPN with Windows
+ The procedure to use VPN varies by Windows version. Generally, the user must edit the VPN properties and make sure that the default route is not the VPN. The following steps are for Windows L2TP clients on Windows Vista. The commands should be similar for other Windows versions.
+
+ Log in to the CloudStack UI and click on the source NAT IP for the account. The VPN tab should display the IPsec preshared key. Make a note of this and the source NAT IP. The UI also lists one or more users and their passwords. Choose one of these users, or, if none exists, add a user and password.
+
+ On the Windows box, go to Control Panel, then select Network and Sharing center. Click Setup a connection or network.
+
+ In the next dialog, select No, create a new connection.
+
+ In the next dialog, select Use my Internet Connection (VPN).
+
+ In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check Don't connect now.
+
+ In the next dialog, enter the user name and password selected in step 1.
+
+ Click Create.
+
+ Go back to the Control Panel and click Network Connections to see the new connection. The connection is not active yet.
+
+ Right-click the new connection and select Properties. In the Properties dialog, select the Networking tab.
+
+ In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key. Enter the preshared key from Step 1.
+
+ The connection is ready for activation. Go back to Control Panel -> Network Connections and double-click the created connection.
+
+ Enter the user name and password from Step 1.
+
15.17.3. Using VPN with Mac OS X
+ In Mac OS X, in Network Preferences - Advanced, make sure Send all traffic over VPN connection is not checked.
+
15.17.4. Setting Up a Site-to-Site VPN Connection
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+
+ Cisco ISR with IOS 12.4 or later
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
Note
+ In addition to the specific Cisco and Juniper devices listed above, the expectation is that any Cisco or Juniper device running on the supported operating systems are able to establish VPN connections.
+
+ To set up a Site-to-Site VPN connection, perform the following:
+
+ Create a VPN gateway for the VPC that you created.
+
+ Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
+
15.17.4.1. Creating and Updating a VPN Customer Gateway
Note
+ A VPN customer gateway can be connected to only one VPN gateway at a time.
+
+ To add a VPN Customer Gateway:
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Click Add site-to-site VPN.
+
+ Provide the following information:
+
+ Name: A unique name for the VPN customer gateway you create.
+
+ Gateway: The IP address for the remote gateway.
+
+ CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be RFC1918-compliant.
+
+ IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share a secret key. This key value is used to authenticate the customer gateway and the VPC VPN gateway to each other.
+
Note
+ The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.
+
+ IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is accomplished through the Preshared Keys.
+
Note
+ The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.
+
+ IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.
+
+ IKE DH: A public-key cryptography protocol which allows two parties to establish a shared secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).
+
+ ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192, AES256, and 3DES.
+
Note
+ The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.
+
+ ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash algorithms are SHA1 and MD5.
+
+ Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised. This property enforces a new Diffie-Hellman key exchange. It provides the keying material that has greater key material life and thereby greater resistance to cryptographic attacks. The available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key exchanges increase as the DH groups grow larger, as does the time of the exchanges.
+
Note
+ When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.
+
+ IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is 86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.
+
+ ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a new IPsec encryption and authentication session keys.
+
+ Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual router to query the liveliness of its IKE peer at regular intervals. It’s recommended to have the same configuration of DPD on both side of VPN connection.
+
+ Click OK.
+
Updating and Removing a VPN Customer Gateway
+ You can update a customer gateway either with no VPN connection, or related VPN connection is in error state.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPN Customer Gateway.
+
+ Select the VPN customer gateway you want to work with.
+
+ To modify the required parameters, click the Edit VPN Customer Gateway button
+
+
+ To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
+
+
+ Click OK.
+
15.17.4.2. Creating a VPN gateway for the VPC
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ACLs
+
+ Select Site-to-Site VPN.
+
+ If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN prompts you to create a VPN gateway.
+
+ In the confirmation dialog, click Yes to confirm.
+
+ Within a few moments, the VPN gateway is created. You will be prompted to view the details of the VPN gateway you have created. Click Yes to confirm.
+
+ The following details are displayed in the VPN Gateway page:
+
+ IP Address
+
+ Account
+
+ Domain
+
15.17.4.3. Creating a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you create for the account are listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ Click Create VPN Connection.
+
+ The Create VPN Connection dialog is displayed:
+
+ Select the desired customer gateway, then click OK to confirm.
+
+ Within a few moments, the VPN Connection is displayed.
+
+ The following information on the VPN connection is displayed:
+
+ IP Address
+
+ Gateway
+
+ State
+
+ IPSec Preshared Key
+
+ IKE Policy
+
+ ESP Policy
+
15.17.4.4. Restarting and Removing a VPN Connection
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation, choose Network.
+
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+ Click the Settings icon.
+
+ The following options are displayed.
+
+ IP Addresses
+
+ Gateways
+
+ Site-to-Site VPN
+
+ Network ASLs
+
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ All the VPN connections you created are displayed.
+
+ Select the VPN connection you want to work with.
+
+ The Details tab is displayed.
+
+ To remove a VPN connection, click the Delete VPN connection button
+
+
+ To restart a VPN connection, click the Reset VPN connection button present in the Details tab.
+
+
+ CloudStack is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. CloudStack manages the network, storage, and compute nodes that make up a cloud infrastructure. Use CloudStack to deploy, manage, and configure cloud computing environments.
+
+ Typical users are service providers and enterprises. With CloudStack, you can:
+
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with CloudStack an enterprise can offer self-service virtual machines to users without involving IT departments.
+
diff --git a/docs/tmp/en-US/html/whats-new-in-api-3.0.html b/docs/tmp/en-US/html/whats-new-in-api-3.0.html
new file mode 100644
index 00000000000..e9819bd4738
--- /dev/null
+++ b/docs/tmp/en-US/html/whats-new-in-api-3.0.html
@@ -0,0 +1,628 @@
+
+
+3.2. What's New in the API for 3.0
+ Port 8096, which allows API calls without authentication, is closed and disabled by default on any fresh 3.0.1 installations. You can enable 8096 (or another port) for this purpose as follows:
+
+ Ensure that the first Management Server is installed and running.
+
+ Set the global configuration parameter integration.api.port to the desired port.
+
+ Restart the Management Server.
+
+ On the Management Server host machine, create an iptables rule allowing access to that port.
+
3.2.2. Stopped VM
+ CloudStack now supports creating a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A VM can now be deployed in two ways: create and start a VM (the default method); or create a VM and leave it in the stopped state.
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature.
+
+ The possible values are:
+
+ true - The VM starts as a part of the VM deployment.
+
+ false - The VM is left in the stopped state at the end of the VM deployment.
+
+ The default value is true.
+
3.2.3. Change to Behavior of List Commands
+ There was a major change in how our List* API commands work in CloudStack 3.0 compared to 2.2.x. The rules below apply only for managed resources – those that belong to an account, domain, or project. They are irrelevant for the List* commands displaying unmanaged (system) resources, such as hosts, clusters, and external network resources.
+
+ When no parameters are passed in to the call, the caller sees only resources owned by the caller (even when the caller is the administrator). Previously, the administrator saw everyone else's resources by default.
+
+ When accountName and domainId are passed in:
+
+ The caller sees the resources dedicated to the account specified.
+
+ If the call is executed by a regular user, the user is authorized to specify only the user's own account and domainId.
+
+ If the caller is a domain administrator, CloudStack performs an authorization check to see whether the caller is permitted to view resources for the given account and domainId.
+
+ When projectId is passed in, only resources belonging to that project are listed.
+
+ When domainId is passed in, the call returns only resources belonging to the domain specified. To see the resources of subdomains, use the parameter isRecursive=true. Again, the regular user can see only resources owned by that user, the root administrator can list anything, and a domain administrator is authorized to see only resources of the administrator's own domain and subdomains.
+
+ To see all resources the caller is authorized to see, except for Project resources, use the parameter listAll=true.
+
+ To see all Project resources the caller is authorized to see, use the parameter projectId=-1.
+
+ There is one API command that doesn't fall under the rules above completely: the listTemplates command. This command has its own flags defining the list rules:
+
+
+ listTemplates Flag
+
+
+
+ Description
+
+
+
+ featured
+
+
+
+ Returns templates that have been marked as featured and public.
+
+
+
+ self
+
+
+
+ Returns templates that have been registered or created by the calling user.
+
+
+
+ selfexecutable
+
+
+
+ Same as self, but only returns templates that are ready to be deployed with.
+
+
+
+ sharedexecutable
+
+
+
+ Ready templates that have been granted to the calling user by another user.
+
+
+
+ executable
+
+
+
+ Templates that are owned by the calling user, or public templates, that can be used to deploy a new VM.
+
+
+
+ community
+
+
+
+ Returns templates that have been marked as public but not featured.
+
+
+
+ all
+
+
+
+ Returns all templates (only usable by admins).
+
+
+ The CloudStack UI on a general view will display all resources that the logged-in user is authorized to see, except for project resources. To see the project resources, select the project view.
+
+ Changes the service offering for a system VM (console proxy or secondary storage). The system VM must be in a "Stopped" state for this command to take effect.
+
3.2.5.2. Added in 3.0.1
+ changeServiceForSystemVm
+
+ Changes the service offering for a system VM (console proxy or secondary storage). The system VM must be in a "Stopped" state for this command to take effect.
+
3.2.5.3. Added in 3.0.0
+
+ assignVirtualMachine (Move a user VM to another user under same domain.)
+
+
+
+ restoreVirtualMachine (Restore a VM to original template or specific snapshot)
+
+
+
+ createLBStickinessPolicy (Creates a Load Balancer stickiness policy )
+
+
+
+ deleteLBStickinessPolicy (Deletes a LB stickiness policy.)
+
+ listNetscalerLoadBalancerNetworks (lists network that are using a netscaler load balancer device)
+
+
+
+ createVirtualRouterElement (Create a virtual router element.)
+
+
+
+ configureVirtualRouterElement (Configures a virtual router element.)
+
+
+
+ listVirtualRouterElements (Lists all available virtual router elements.)
+
+
+
+
+
+
+
+
3.2.6. Added CloudStack Error Codes
+ You can now find the CloudStack-specific error code in the exception response for each type of exception. The following list of error codes is added to the new class named CSExceptionErrorCode. These codes are applicable in CloudStack 3.0.3 and later versions.
+
diff --git a/docs/tmp/en-US/html/whats-new-in-api-4.0.html b/docs/tmp/en-US/html/whats-new-in-api-4.0.html
new file mode 100644
index 00000000000..09e4ebdc73b
--- /dev/null
+++ b/docs/tmp/en-US/html/whats-new-in-api-4.0.html
@@ -0,0 +1,538 @@
+
+
+3.1. What's New in the API for 4.0
diff --git a/docs/tmp/en-US/html/who-should-read-installation.html b/docs/tmp/en-US/html/who-should-read-installation.html
new file mode 100644
index 00000000000..65dffee2120
--- /dev/null
+++ b/docs/tmp/en-US/html/who-should-read-installation.html
@@ -0,0 +1,5 @@
+
+
+4.1. Who Should Read This
+ For those who have already gone through a design phase and planned a more sophisticated deployment, or those who are ready to start scaling up a trial installation. With the following procedures, you can start using the more powerful features of CloudStack, such as advanced VLAN networking, high availability, additional network elements such as load balancers and firewalls, and support for multiple hypervisors including Citrix XenServer, KVM, and VMware vSphere.
+
+ The Usage Server is an optional, separately-installed part of CloudStack that provides aggregated usage records which you can use to create billing integration for CloudStack. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances.
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day.
+
+ CloudStack supports ISOs and their attachment to guest VMs. An ISO is a read-only file that has an ISO/CD-ROM style file system. Users can upload their own ISOs and mount them on their guest VMs.
+
+ ISOs are uploaded based on a URL. HTTP is the supported protocol. Once the ISO is available via HTTP specify an upload URL such as http://my.web.server/filename.iso.
+
+ ISOs may be public or private, like templates.ISOs are not hypervisor-specific. That is, a guest on vSphere can mount the exact same image that a guest on KVM can mount.
+
+ ISO images may be stored in the system and made available with a privacy level similar to templates. ISO images are classified as either bootable or not bootable. A bootable ISO image is one that contains an OS image. CloudStack allows a user to boot a guest VM off of an ISO image. Users can also attach ISO images to guest VMs. For example, this enables installing PV drivers into Windows. ISO images are not hypervisor-specific.
+
10.11.1. Adding an ISO
+ To make additional operating system or other software available for use with guest VMs, you can add an ISO. The ISO is typically thought of as an operating system image, but you can also add ISOs for other types of software, such as desktop applications that you want to be installed as part of a template.
+
+ Log in to the CloudStack UI as an administrator or end user.
+
+ In the left navigation bar, click Templates.
+
+ In Select View, choose ISOs.
+
+ Click Add ISO.
+
+ In the Add ISO screen, provide the following:
+
+ Name: Short name for the ISO image. For example, CentOS 6.2 64-bit.
+
+ Description: Display test for the ISO image. For example, CentOS 6.2 64-bit.
+
+ URL: The URL that hosts the ISO image. The Management Server must be able to access this location via HTTP. If needed you can place the ISO image directly on the Management Server
+
+ Zone: Choose the zone where you want the ISO to be available, or All Zones to make it available throughout CloudStack.
+
+ Bootable: Whether or not a guest could boot off this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not bootable.
+
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of your desired ISO image is listed, choose it.
+
+ If the OS Type of the ISO is not listed or if the ISO is not bootable, choose Other.
+
+ (XenServer only) If you want to boot from this ISO in PV mode, choose Other PV (32-bit) or Other PV (64-bit)
+
+ (KVM only) If you choose an OS that is PV-enabled, the VMs created from this ISO will have a SCSI (virtio) root disk. If the OS is not PV-enabled, the VMs will have an IDE root disk. The PV-enabled types are:
+
+
+ Fedora 13
+
+
+
+ Fedora 12
+
+
+
+ Fedora 11
+
+
+
+ Fedora 10
+
+
+
+ Fedora 9
+
+
+
+ Other PV
+
+
+
+ Debian GNU/Linux
+
+
+
+ CentOS 5.3
+
+
+
+ CentOS 5.4
+
+
+
+ CentOS 5.5
+
+
+
+ Red Hat Enterprise Linux 5.3
+
+
+
+ Red Hat Enterprise Linux 5.4
+
+
+
+ Red Hat Enterprise Linux 5.5
+
+
+
+ Red Hat Enterprise Linux 6
+
+
+
Note
+ It is not recommended to choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not work. In these cases, choose Other.
+
+ Extractable: Choose Yes if the ISO should be available for extraction.
+
+ Public: Choose Yes if this ISO should be available to other users.
+
+ Featured: Choose Yes if you would like this ISO to be more prominent for users to select. The ISO will appear in the Featured ISOs list. Only an administrator can make an ISO Featured.
+
+ Click OK.
+
+ The Management Server will download the ISO. Depending on the size of the ISO, this may take a long time. The ISO status column will display Ready once it has been successfully downloaded into secondary storage. Clicking Refresh updates the download percentage.
+
+ Important: Wait for the ISO to finish downloading. If you move on to the next task and try to use the ISO right away, it will appear to fail. The entire ISO must be available before CloudStack can work with it.
+
10.11.2. Attaching an ISO to a VM
+ In the left navigation, click Instances.
+
+ Choose the virtual machine you want to work with.
+
+ Click the Attach ISO button
+
+
+ In the Attach ISO dialog box, select the desired ISO.
+
+ (Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)
+
+ CloudStack supports snapshots of disk volumes. Snapshots are a point-in-time capture of virtual machine disks. Memory and CPU states are not captured.
+
+ Snapshots may be taken for volumes, including both root and data disks. The administrator places a limit on the number of stored snapshots per user. Users can create new volumes from the snapshot for recovery of particular files and they can create templates from snapshots to boot from a restored disk.
+
+ Users can create snapshots manually or by setting up automatic recurring snapshot policies. Users can also create disk volumes from snapshots, which may be attached to a VM like any other disk volume. Snapshots of both root disks and data disks are supported. However, CloudStack does not currently support booting a VM from a recovered root disk. A disk recovered from snapshot of a root disk is treated as a regular data disk; the data on recovered disk can be accessed by attaching the disk to a VM.
+
+ A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot.
+
+ CloudStack uses several types of system virtual machines to perform tasks in the cloud. In general CloudStack manages these system VMs and creates, starts, and stops them as needed based on scale and immediate needs. However, the administrator should be aware of them and their roles to assist in debugging issues.
+
+ A template is a reusable configuration for virtual machines. When users launch VMs, they can choose from a list of templates in CloudStack.
+
+ Specifically, a template is a virtual disk image that includes one of a variety of operating systems, optional additional software such as office applications, and settings such as access control to determine who can use the template. Each template is associated with a particular type of hypervisor, which is specified when the template is added to CloudStack.
+
+ CloudStack ships with a default template. In order to present more choices to users, CloudStack administrators and users can create templates and add them to CloudStack.
+
+ The Usage Server provides aggregated usage records which you can use to create billing integration for the CloudStack platform. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances. In the special case of bare metal instances, no template storage resources are consumed, but records showing zero usage are still included in the Usage Server's output.
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day. Its behavior is controlled by configuration settings as described in the CloudStack Administration Guide.
+
+ A volume provides storage to a guest VM. The volume can provide for a root disk or an additional data disk. CloudStack supports additional volumes for guest VMs.
+
+ Volumes are created for a specific hypervisor type. A volume that has been attached to guest using one hypervisor type (e.g, XenServer) may not be attached to a guest that is using another hypervisor type (e.g. vSphere, KVM). This is because the different hypervisors use different disk image formats.
+
+ CloudStack defines a volume as a unit of storage available to a guest VM. Volumes are either root disks or data disks. The root disk has "/" in the file system and is usually the boot device. Data disks provide for additional storage (e.g. As "/opt" or "D:"). Every guest VM has a root disk, and VMs can also optionally have a data disk. End users can mount multiple data disks to guest VMs. Users choose data disks from the disk offerings created by administrators. The user can create a template from a volume as well; this is the standard procedure for private template creation. Volumes are hypervisor-specific: a volume from one hypervisor type may not be used on a guest of another hypervisor type.
+
+ (Optional) If you are going to use Swift for cloud-wide secondary storage, you need to add it before you add zones.
+
+ Log in to the CloudStack UI as administrator.
+
+ If this is your first time visiting the UI, you will see the guided tour splash screen. Choose “Experienced user.” The Dashboard appears.
+
+ In the left navigation bar, click Global Settings.
+
+ In the search box, type swift.enable and click the search button.
+
+ Click the edit button and set swift.enable to true.
+
+
+
+ Restart the Management Server.
+
# service cloud-management restart
+ Refresh the CloudStack UI browser tab and log back in.
+
+ In the left navigation, choose Infrastructure.
+
+ On Zones, click View More.
+
+ (Optional) If you are using Swift storage, click Enable Swift. Provide the following:
+
+ URL. The Swift URL.
+
+ Account. The Swift account.
+
+ Username. The Swift account’s username.
+
+ Key. The Swift key.
+
+ 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.
+
+ For more information about the network types, see Network Setup.
+
+ The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you:
+
+ 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.
+
+ 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.
+
+ (Introduced in version 3.0.1) 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.2, “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, CloudPlatform 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.
+
7.2.2. 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.7.4, “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.
+
+ 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.2, “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.7.7, “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.3, “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.4, “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.5, “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.6, “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 :
+
diff --git a/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-API_Developers_Guide-en-US.pdf b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-API_Developers_Guide-en-US.pdf
new file mode 100644
index 00000000000..c4e90e663dc
Binary files /dev/null and b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-API_Developers_Guide-en-US.pdf differ
diff --git a/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-Admin_Guide-en-US.pdf b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-Admin_Guide-en-US.pdf
new file mode 100644
index 00000000000..6d4d06b634a
Binary files /dev/null and b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-Admin_Guide-en-US.pdf differ
diff --git a/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-Installation_Guide-en-US.pdf b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-Installation_Guide-en-US.pdf
new file mode 100644
index 00000000000..a0f762bbd17
Binary files /dev/null and b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-Installation_Guide-en-US.pdf differ
diff --git a/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-Release_Notes-en-US.pdf b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-Release_Notes-en-US.pdf
new file mode 100644
index 00000000000..82b5c89487d
Binary files /dev/null and b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-Release_Notes-en-US.pdf differ
diff --git a/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-release-notes-en-US.pdf b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-release-notes-en-US.pdf
new file mode 100644
index 00000000000..87edf84ed74
Binary files /dev/null and b/docs/tmp/en-US/pdf/Apache_CloudStack-4.0.0-incubating-release-notes-en-US.pdf differ
diff --git a/docs/tmp/en-US/xml/API_Developers_Guide.ent b/docs/tmp/en-US/xml/API_Developers_Guide.ent
new file mode 100644
index 00000000000..47a2b6757f8
--- /dev/null
+++ b/docs/tmp/en-US/xml/API_Developers_Guide.ent
@@ -0,0 +1,21 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml/API_Developers_Guide.fo b/docs/tmp/en-US/xml/API_Developers_Guide.fo
new file mode 100644
index 00000000000..be22005ebb8
--- /dev/null
+++ b/docs/tmp/en-US/xml/API_Developers_Guide.fo
@@ -0,0 +1,2620 @@
+
+CloudStack API Developer's GuideDocBook XSL Stylesheets with Apache FOPCloudStack API Developer's GuideTable of ContentsChapter 1. Concepts1.1. What Is CloudStack?1.2. What Can CloudStack Do?1.3. Deployment Architecture Overview1.3.1. Management Server Overview1.3.2. Cloud Infrastructure Overview1.3.3. Networking OverviewChapter 2. Introduction for Developers2.1. Roles2.2. API Reference Documentation2.3. Getting StartedChapter 3. What's New in the API?3.1. What's New in the API for 4.03.1.1. Changed API Commands in 4.0.0-incubating3.1.2. Added API Commands in 4.0.0-incubating3.2. What's New in the API for 3.03.2.1. Enabling Port 80963.2.2. Stopped VM3.2.3. Change to Behavior of List Commands3.2.4. Removed API commands3.2.5. Added API commands in 3.03.2.5.1. Added in 3.0.23.2.5.2. Added in 3.0.13.2.5.3. Added in 3.0.03.2.6. Added CloudStack Error CodesChapter 4. Calling the CloudStack API4.1. Making API Requests4.2. Enabling API Call Expiration4.3. Signing API Requests4.4. Responses4.4.1. Response Formats: XML and JSON4.4.2. Maximum Result Pages Returned4.4.3. Error Handling4.5. Asynchronous Commands4.5.1. Job Status4.5.2. ExampleChapter 5. Working With Usage Data5.1. Usage Record Format5.1.1. Virtual Machine Usage Record Format5.1.2. Network Usage Record Format5.1.3. IP Address Usage Record Format5.1.4. Disk Volume Usage Record Format5.1.5. Template, ISO, and Snapshot Usage Record Format5.1.6. Load Balancer Policy or Port Forwarding Rule Usage Record Format5.1.7. Network Offering Usage Record Format5.1.8. VPN User Usage Record Format5.2. Usage Types5.3. Example response from listUsageRecords5.4. Dates in the Usage RecordAppendix A. Event TypesAppendix B. AlertsAppendix C. Time ZonesAppendix D. Revision HistoryCloudStack API Developer's GuideApache CloudStack 4.0.0-incubatingCloudStack API Developer's Guide
+
+
+ Apache CloudStackApache CloudStack 4.0.0-incubating CloudStack API Developer's GuideAuthorApache CloudStack
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+ How to integrate with CloudStack using the CloudStack API.
+ CloudStack API Developer's Guide1. Concepts1.1. What Is CloudStack?1.2. What Can CloudStack Do?1.3. Deployment Architecture Overview1.3.1. Management Server Overview1.3.2. Cloud Infrastructure Overview1.3.3. Networking Overview2. Introduction for Developers2.1. Roles2.2. API Reference Documentation2.3. Getting Started3. What's New in the API?3.1. What's New in the API for 4.03.1.1. Changed API Commands in 4.0.0-incubating3.1.2. Added API Commands in 4.0.0-incubating3.2. What's New in the API for 3.03.2.1. Enabling Port 80963.2.2. Stopped VM3.2.3. Change to Behavior of List Commands3.2.4. Removed API commands3.2.5. Added API commands in 3.03.2.6. Added CloudStack Error Codes4. Calling the CloudStack API4.1. Making API Requests4.2. Enabling API Call Expiration4.3. Signing API Requests4.4. Responses4.4.1. Response Formats: XML and JSON4.4.2. Maximum Result Pages Returned4.4.3. Error Handling4.5. Asynchronous Commands4.5.1. Job Status4.5.2. Example5. Working With Usage Data5.1. Usage Record Format5.1.1. Virtual Machine Usage Record Format5.1.2. Network Usage Record Format5.1.3. IP Address Usage Record Format5.1.4. Disk Volume Usage Record Format5.1.5. Template, ISO, and Snapshot Usage Record Format5.1.6. Load Balancer Policy or Port Forwarding Rule Usage Record Format5.1.7. Network Offering Usage Record Format5.1.8. VPN User Usage Record Format5.2. Usage Types5.3. Example response from listUsageRecords5.4. Dates in the Usage RecordA. Event TypesB. AlertsC. Time ZonesD. Revision HistoryChapter 1.Chapter 1. ConceptsConceptsWhat Is CloudStack?1.1. What Is CloudStack?
+ CloudStack is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. CloudStack manages the network, storage, and compute nodes that make up a cloud infrastructure. Use CloudStack to deploy, manage, and configure cloud computing environments.
+
+ Typical users are service providers and enterprises. With CloudStack, you can:
+ •
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+ •
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with CloudStack an enterprise can offer self-service virtual machines to users without involving IT departments.
+ What Can CloudStack Do?1.2. What Can CloudStack Do?
+ Multiple Hypervisor Support
+
+ CloudStack works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of CloudStack supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+ Massively Scalable Infrastructure Management
+
+ CloudStack can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+ Automatic Configuration Management
+
+ CloudStack automatically configures each guest virtual machine’s networking and storage settings.
+
+ CloudStack internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+ Graphical User Interface
+
+ CloudStack offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+ API and Extensibility
+
+ CloudStack provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at Apache CloudStack Guides11http://incubator.apache.org/cloudstack/docs and Apache CloudStack API Reference22http://incubator.apache.org/cloudstack/docs/api respectively.
+
+ The CloudStack pluggable allocation architecture allows the creation of new types of allocators for the selection of storage and Hosts. See the Allocator Implementation Guide (http://docs.cloudstack.org/CloudStack_Documentation/Allocator_Implementation_Guide).
+
+ High Availability
+
+ CloudStack has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the hosts, CloudStack supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+ Deployment Architecture Overview1.3. Deployment Architecture Overview
+ A CloudStack installation consists of two parts: the Management Server and the cloud infrastructure that it manages. When you set up and manage a CloudStack cloud, you provision resources such as hosts, storage devices, and IP addresses into the Management Server, and the Management Server manages those resources.
+
+ The minimum production installation consists of one machine running the CloudStack Management Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure consisting of one host running hypervisor software). In its smallest deployment, a single machine can act as both the Management Server and the hypervisor host (using the KVM hypervisor).
+
+ A more full-featured installation consists of a highly-available multi-node Management Server installation and up to tens of thousands of hosts using any of several advanced networking setups. For information about deployment options, see Choosing a Deployment Architecture.
+ Management Server Overview1.3.1. Management Server Overview
+ The Management Server is the CloudStack software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+ The machine must meet the system requirements described in System Requirements.
+
+ The Management Server:
+ •
+ Provides the web user interface for the administrator and a reference user interface for end users.
+ •
+ Provides the APIs for CloudStack.
+ •
+ Manages the assignment of guest VMs to particular hosts.
+ •
+ Manages the assignment of public and private IP addresses to particular accounts.
+ •
+ Manages the allocation of storage to guests as virtual disks.
+ •
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+ •
+ Provides a single point of configuration for the cloud.
+ Cloud Infrastructure Overview1.3.2. Cloud Infrastructure Overview
+ The Management Server manages one or more zones (typically, datacenters) containing host computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
+ •
+ Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
+ •
+ Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
+ •
+ Cluster: A cluster consists of one or more hosts and primary storage.
+ •
+ Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines.
+ •
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster.
+ •
+ Secondary storage is associated with a zone, and it stores templates, ISO images, and disk volume snapshots.
+
+ More Information
+
+ For more information, see documentation on cloud infrastructure concepts.
+ Networking Overview1.3.3. Networking Overview
+ CloudStack offers two types of networking scenario:
+ •
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+ •
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+ For more details, see Network Setup.
+ Chapter 2.Chapter 2. Introduction for DevelopersIntroduction for DevelopersRoles2.1. Roles
+ The CloudPlatform API supports three access roles:
+ 1.
+ Root Admin. Access to all features of the cloud, including both virtual and physical resource management.
+ 2.
+ Domain Admin. Access to only the virtual resources of the clouds that belong to the administrator’s domain.
+ 3.
+ User. Access to only the features that allow management of the user’s virtual instances, storage, and network.
+ API Reference Documentation2.2. API Reference Documentation
+ 2.2 API Reference:
+
+ http://download.cloud.com/support/downloads.html/
+
+ 3.0 API Reference:
+
+ http://download.cloud.com/releases/3.0.0/api_3.0.0/TOC_Root_Admin.html/
+ Getting Started2.3. Getting Started
+ To get started using the CloudStack API, you should have the following:
+ •
+ URL of the CloudStack server you wish to integrate with.
+ •
+ Both the API Key and Secret Key for an account. This should have been generated by the administrator of the cloud instance and given to you.
+ •
+ Familiarity with HTTP GET/POST and query strings.
+ •
+ Knowledge of either XML or JSON.
+ •
+ Knowledge of a programming language that can generate HTTP requests; for example, Java or PHP.
+ Chapter 3.Chapter 3. What's New in the API?What's New in the API?
+ The following describes any new major features of each CloudStack version as it applies to API usage.
+ What's New in the API for 4.03.1. What's New in the API for 4.0Changed API Commands in 4.0.0-incubating3.1.1. Changed API Commands in 4.0.0-incubating
+
+ API Commands
+
+
+
+ Description
+
+
+
+ copyTemplate
+
+
+ prepareTemplate
+
+
+ registerTemplate
+
+
+ updateTemplate
+
+
+ createProject
+
+
+ activateProject
+
+
+ suspendProject
+
+
+ updateProject
+
+
+ listProjectAccounts
+
+
+ createVolume
+
+
+ migrateVolume
+
+
+ attachVolume
+
+
+ detachVolume
+
+
+ uploadVolume
+
+
+ createSecurityGroup
+
+
+ registerIso
+
+
+ copyIso
+
+
+ updateIso
+
+
+ createIpForwardingRule
+
+
+ listIpForwardingRules
+
+
+ createLoadBalancerRule
+
+
+ updateLoadBalancerRule
+
+
+ createSnapshot
+
+
+
+
+ The commands in this list have a single new response parameter, and no other changes.
+
+
+ New response parameter: tags(*)
+
+ Note
+ Many other commands also have the new tags(*) parameter in addition to other changes; those commands are listed separately.
+
+
+
+ rebootVirtualMachine
+
+
+ attachIso
+
+
+ detachIso
+
+
+ listLoadBalancerRuleInstances
+
+
+ resetPasswordForVirtualMachine
+
+
+ changeServiceForVirtualMachine
+
+
+ recoverVirtualMachine
+
+
+ startVirtualMachine
+
+
+ migrateVirtualMachine
+
+
+ deployVirtualMachine
+
+
+ assignVirtualMachine
+
+
+ updateVirtualMachine
+
+
+ restoreVirtualMachine
+
+
+ stopVirtualMachine
+
+
+ destroyVirtualMachine
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+ listSecurityGroups
+
+
+ listFirewallRules
+
+
+ listPortForwardingRules
+
+
+ listSnapshots
+
+
+ listIsos
+
+
+ listProjects
+
+
+ listTemplates
+
+
+ listLoadBalancerRules
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: tags (optional)
+
+
+ New response parameter: tags(*)
+
+
+
+
+ listF5LoadBalancerNetworks
+
+
+ listNetscalerLoadBalancerNetworks
+
+
+ listSrxFirewallNetworks
+
+
+ updateNetwork
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ createZone
+
+
+ updateZone
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: localstorageenabled (optional)
+
+
+ New response parameter: localstorageenabled
+
+
+
+
+ listZones
+
+
+
+ New response parameter: localstorageenabled
+
+
+
+ rebootRouter
+
+
+ changeServiceForRouter
+
+
+ startRouter
+
+
+ destroyRouter
+
+
+ stopRouter
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+ updateAccount
+
+
+ disableAccount
+
+
+ listAccounts
+
+
+ markDefaultZoneForAccount
+
+
+ enableAccount
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: vpcavailable, vpclimit, vpctotal
+
+
+
+ listRouters
+
+
+
+ New request parameters: forvpc (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+
+ listNetworkOfferings
+
+
+
+ New request parameters: forvpc (optional)
+
+
+ New response parameters: forvpc
+
+
+
+
+ listVolumes
+
+
+
+ New request parameters: details (optional), tags (optional)
+
+
+ New response parameters: tags(*)
+
+
+
+
+ addTrafficMonitor
+
+
+
+ New request parameters: excludezones (optional), includezones (optional)
+
+
+
+
+ createNetwork
+
+
+
+ New request parameters: vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ listPublicIpAddresses
+
+
+
+ New request parameters: tags (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+ listNetworks
+
+
+
+ New request parameters: canusefordeploy (optional), forvpc (optional), tags (optional), vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ restartNetwork
+
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+ enableStaticNat
+
+
+
+ New request parameter: networkid (optional)
+
+
+
+
+ createDiskOffering
+
+
+
+ New request parameter: storagetype (optional)
+
+
+ New response parameter: storagetype
+
+
+
+
+ listDiskOfferings
+
+
+
+ New response parameter: storagetype
+
+
+
+
+ updateDiskOffering
+
+
+
+ New response parameter: storagetype
+
+
+
+
+ createFirewallRule
+
+
+
+ Changed request parameters: ipaddressid (old version - optional, new version - required)
+
+
+ New response parameter: tags(*)
+
+
+
+
+ listVirtualMachines
+
+
+
+ New request parameters: isoid (optional), tags (optional), templateid (optional)
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+ updateStorageNetworkIpRange
+
+
+
+ New response parameters: id, endip, gateway, netmask, networkid, podid, startip, vlan, zoneid
+
+
+ Added API Commands in 4.0.0-incubating3.1.2. Added API Commands in 4.0.0-incubating•
+ createCounter (Adds metric counter)
+ •
+ deleteCounter (Deletes a counter)
+ •
+ listCounters (List the counters)
+ •
+ createCondition (Creates a condition)
+ •
+ deleteCondition (Removes a condition)
+ •
+ listConditions (List Conditions for the specific user)
+ •
+ createTags. Add tags to one or more resources. Example:
+command=createTags
+&resourceIds=1,10,12
+&resourceType=userVm
+&tags[0].key=region
+&tags[0].value=canada
+&tags[1].key=city
+&tags[1].value=Toronto
+ •
+ deleteTags. Remove tags from one or more resources. Example:
+command=deleteTags
+&resourceIds=1,12
+&resourceType=Snapshot
+&tags[0].key=city
+ •
+ listTags (Show currently defined resource tags)
+ •
+ createVPC (Creates a VPC)
+ •
+ listVPCs (Lists VPCs)
+ •
+ deleteVPC (Deletes a VPC)
+ •
+ updateVPC (Updates a VPC)
+ •
+ restartVPC (Restarts a VPC)
+ •
+ createVPCOffering (Creates VPC offering)
+ •
+ updateVPCOffering (Updates VPC offering)
+ •
+ deleteVPCOffering (Deletes VPC offering)
+ •
+ listVPCOfferings (Lists VPC offerings)
+ •
+ createPrivateGateway (Creates a private gateway)
+ •
+ listPrivateGateways (List private gateways)
+ •
+ deletePrivateGateway (Deletes a Private gateway)
+ •
+ createNetworkACL (Creates a ACL rule the given network (the network has to belong to VPC))
+ •
+ deleteNetworkACL (Deletes a Network ACL)
+ •
+ listNetworkACLs (Lists all network ACLs)
+ •
+ createStaticRoute (Creates a static route)
+ •
+ deleteStaticRoute (Deletes a static route)
+ •
+ listStaticRoutes (Lists all static routes)
+ •
+ createVpnCustomerGateway (Creates site to site vpn customer gateway)
+ •
+ createVpnGateway (Creates site to site vpn local gateway)
+ •
+ createVpnConnection (Create site to site vpn connection)
+ •
+ deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
+ •
+ deleteVpnGateway (Delete site to site vpn gateway)
+ •
+ deleteVpnConnection (Delete site to site vpn connection)
+ •
+ updateVpnCustomerGateway (Update site to site vpn customer gateway)
+ •
+ resetVpnConnection (Reset site to site vpn connection)
+ •
+ listVpnCustomerGateways (Lists site to site vpn customer gateways)
+ •
+ listVpnGateways (Lists site 2 site vpn gateways)
+ •
+ listVpnConnections (Lists site to site vpn connection gateways)
+ •
+ enableCiscoNexusVSM (Enables Nexus 1000v dvSwitch in CloudStack.)
+ •
+ disableCiscoNexusVSM (Disables Nexus 1000v dvSwitch in CloudStack.)
+ •
+ deleteCiscoNexusVSM (Deletes Nexus 1000v dvSwitch in CloudStack.)
+ •
+ listCiscoNexusVSMs (Lists the control VLAN ID, packet VLAN ID, and data VLAN ID, as well as the IP address of the Nexus 1000v dvSwitch.)
+ What's New in the API for 3.03.2. What's New in the API for 3.0Enabling Port 80963.2.1. Enabling Port 8096
+ Port 8096, which allows API calls without authentication, is closed and disabled by default on any fresh 3.0.1 installations. You can enable 8096 (or another port) for this purpose as follows:
+ 1.
+ Ensure that the first Management Server is installed and running.
+ 2.
+ Set the global configuration parameter integration.api.port to the desired port.
+ 3.
+ Restart the Management Server.
+ 4.
+ On the Management Server host machine, create an iptables rule allowing access to that port.
+ Stopped VM3.2.2. Stopped VM
+ CloudStack now supports creating a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A VM can now be deployed in two ways: create and start a VM (the default method); or create a VM and leave it in the stopped state.
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature.
+
+ The possible values are:
+ •
+ true - The VM starts as a part of the VM deployment.
+ •
+ false - The VM is left in the stopped state at the end of the VM deployment.
+
+ The default value is true.
+ Change to Behavior of List Commands3.2.3. Change to Behavior of List Commands
+ There was a major change in how our List* API commands work in CloudStack 3.0 compared to 2.2.x. The rules below apply only for managed resources – those that belong to an account, domain, or project. They are irrelevant for the List* commands displaying unmanaged (system) resources, such as hosts, clusters, and external network resources.
+
+ When no parameters are passed in to the call, the caller sees only resources owned by the caller (even when the caller is the administrator). Previously, the administrator saw everyone else's resources by default.
+
+ When accountName and domainId are passed in:
+ •
+ The caller sees the resources dedicated to the account specified.
+ •
+ If the call is executed by a regular user, the user is authorized to specify only the user's own account and domainId.
+ •
+ If the caller is a domain administrator, CloudStack performs an authorization check to see whether the caller is permitted to view resources for the given account and domainId.
+
+ When projectId is passed in, only resources belonging to that project are listed.
+
+ When domainId is passed in, the call returns only resources belonging to the domain specified. To see the resources of subdomains, use the parameter isRecursive=true. Again, the regular user can see only resources owned by that user, the root administrator can list anything, and a domain administrator is authorized to see only resources of the administrator's own domain and subdomains.
+
+ To see all resources the caller is authorized to see, except for Project resources, use the parameter listAll=true.
+
+ To see all Project resources the caller is authorized to see, use the parameter projectId=-1.
+
+ There is one API command that doesn't fall under the rules above completely: the listTemplates command. This command has its own flags defining the list rules:
+
+
+ listTemplates Flag
+
+
+
+ Description
+
+
+
+ featured
+
+
+
+ Returns templates that have been marked as featured and public.
+
+
+
+ self
+
+
+
+ Returns templates that have been registered or created by the calling user.
+
+
+
+ selfexecutable
+
+
+
+ Same as self, but only returns templates that are ready to be deployed with.
+
+
+
+ sharedexecutable
+
+
+
+ Ready templates that have been granted to the calling user by another user.
+
+
+
+ executable
+
+
+
+ Templates that are owned by the calling user, or public templates, that can be used to deploy a new VM.
+
+
+
+ community
+
+
+
+ Returns templates that have been marked as public but not featured.
+
+
+
+ all
+
+
+
+ Returns all templates (only usable by admins).
+
+
+ The CloudStack UI on a general view will display all resources that the logged-in user is authorized to see, except for project resources. To see the project resources, select the project view.
+ Removed API commands3.2.4. Removed API commands•
+ createConfiguration (Adds configuration value)
+ •
+ configureSimulator (Configures simulator)
+ Added API commands in 3.03.2.5. Added API commands in 3.03.2.5.1. Added in 3.0.2•
+ changeServiceForSystemVm
+
+ Changes the service offering for a system VM (console proxy or secondary storage). The system VM must be in a "Stopped" state for this command to take effect.
+ 3.2.5.2. Added in 3.0.1•
+ changeServiceForSystemVm
+
+ Changes the service offering for a system VM (console proxy or secondary storage). The system VM must be in a "Stopped" state for this command to take effect.
+ 3.2.5.3. Added in 3.0.0
+
+ assignVirtualMachine (Move a user VM to another user under same domain.)
+
+
+
+ restoreVirtualMachine (Restore a VM to original template or specific snapshot)
+
+
+
+ createLBStickinessPolicy (Creates a Load Balancer stickiness policy )
+
+
+
+ deleteLBStickinessPolicy (Deletes a LB stickiness policy.)
+
+
+
+ listLBStickinessPolicies (Lists LBStickiness policies.)
+
+
+
+ ldapConfig (Configure the LDAP context for this site.)
+
+
+
+ addSwift (Adds Swift.)
+
+
+
+ listSwifts (List Swift.)
+
+
+
+ migrateVolume (Migrate volume)
+
+
+
+ updateStoragePool (Updates a storage pool.)
+
+
+
+ authorizeSecurityGroupEgress (Authorizes a particular egress rule for this security group)
+
+
+
+ revokeSecurityGroupEgress (Deletes a particular egress rule from this security group)
+
+
+
+ createNetworkOffering (Creates a network offering.)
+
+
+
+ deleteNetworkOffering (Deletes a network offering.)
+
+
+
+ createProject (Creates a project)
+
+
+
+ deleteProject (Deletes a project)
+
+
+
+ updateProject (Updates a project)
+
+
+
+ activateProject (Activates a project)
+
+
+
+ suspendProject (Suspends a project)
+
+
+
+ listProjects (Lists projects and provides detailed information for listed projects)
+
+
+
+ addAccountToProject (Adds acoount to a project)
+
+
+
+ deleteAccountFromProject (Deletes account from the project)
+
+
+
+ listProjectAccounts (Lists project's accounts)
+
+
+
+ listProjectInvitations (Lists an account's invitations to join projects)
+
+
+
+ updateProjectInvitation (Accepts or declines project invitation)
+
+
+
+ deleteProjectInvitation (Deletes a project invitation)
+
+
+
+ updateHypervisorCapabilities (Updates a hypervisor capabilities.)
+
+
+
+ listHypervisorCapabilities (Lists all hypervisor capabilities.)
+
+
+
+ createPhysicalNetwork (Creates a physical network)
+
+
+
+ deletePhysicalNetwork (Deletes a Physical Network.)
+
+
+
+ listPhysicalNetworks (Lists physical networks)
+
+
+
+ updatePhysicalNetwork (Updates a physical network)
+
+
+
+ listSupportedNetworkServices (Lists all network services provided by CloudStack or for the given Provider.)
+
+
+
+ addNetworkServiceProvider (Adds a network serviceProvider to a physical network)
+
+
+
+ deleteNetworkServiceProvider (Deletes a Network Service Provider.)
+
+
+
+ listNetworkServiceProviders (Lists network serviceproviders for a given physical network.)
+
+
+
+ updateNetworkServiceProvider (Updates a network serviceProvider of a physical network)
+
+
+
+ addTrafficType (Adds traffic type to a physical network)
+
+
+
+ deleteTrafficType (Deletes traffic type of a physical network)
+
+
+
+ listTrafficTypes (Lists traffic types of a given physical network.)
+
+
+
+ updateTrafficType (Updates traffic type of a physical network)
+
+
+
+ listTrafficTypeImplementors (Lists implementors of implementor of a network traffic type or implementors of all network traffic types)
+
+
+
+ createStorageNetworkIpRange (Creates a Storage network IP range.)
+
+
+
+ deleteStorageNetworkIpRange (Deletes a storage network IP Range.)
+
+
+
+ listStorageNetworkIpRange (List a storage network IP range.)
+
+
+
+ updateStorageNetworkIpRange (Update a Storage network IP range, only allowed when no IPs in this range have been allocated.)
+
+
+
+ listUsageTypes (List Usage Types)
+
+
+
+ addF5LoadBalancer (Adds a F5 BigIP load balancer device)
+
+
+
+ configureF5LoadBalancer (configures a F5 load balancer device)
+
+
+
+ deleteF5LoadBalancer ( delete a F5 load balancer device)
+
+
+
+ listF5LoadBalancers (lists F5 load balancer devices)
+
+
+
+ listF5LoadBalancerNetworks (lists network that are using a F5 load balancer device)
+
+
+
+ addSrxFirewall (Adds a SRX firewall device)
+
+
+
+ deleteSrxFirewall ( delete a SRX firewall device)
+
+
+
+ listSrxFirewalls (lists SRX firewall devices in a physical network)
+
+
+
+ listSrxFirewallNetworks (lists network that are using SRX firewall device)
+
+
+
+ addNetscalerLoadBalancer (Adds a netscaler load balancer device)
+
+
+
+ deleteNetscalerLoadBalancer ( delete a netscaler load balancer device)
+
+
+
+ configureNetscalerLoadBalancer (configures a netscaler load balancer device)
+
+
+
+ listNetscalerLoadBalancers (lists netscaler load balancer devices)
+
+
+
+ listNetscalerLoadBalancerNetworks (lists network that are using a netscaler load balancer device)
+
+
+
+ createVirtualRouterElement (Create a virtual router element.)
+
+
+
+ configureVirtualRouterElement (Configures a virtual router element.)
+
+
+
+ listVirtualRouterElements (Lists all available virtual router elements.)
+
+
+
+
+
+
+
+ Added CloudStack Error Codes3.2.6. Added CloudStack Error Codes
+ You can now find the CloudStack-specific error code in the exception response for each type of exception. The following list of error codes is added to the new class named CSExceptionErrorCode. These codes are applicable in CloudStack 3.0.3 and later versions.
+
+
+ 4250 : "com.cloud.utils.exception.CloudRuntimeException"
+
+
+
+ 4255 : "com.cloud.utils.exception.ExceptionUtil"
+
+
+
+ 4260 : "com.cloud.utils.exception.ExecutionException"
+
+
+
+ 4265 : "com.cloud.utils.exception.HypervisorVersionChangedException"
+
+
+
+ 4270 : "com.cloud.utils.exception.RuntimeCloudException"
+
+
+
+ 4275 : "com.cloud.exception.CloudException"
+
+
+
+ 4280 : "com.cloud.exception.AccountLimitException"
+
+
+
+ 4285 : "com.cloud.exception.AgentUnavailableException"
+
+
+
+ 4290 : "com.cloud.exception.CloudAuthenticationException"
+
+
+
+ 4295 : "com.cloud.exception.CloudExecutionException"
+
+
+
+ 4300 : "com.cloud.exception.ConcurrentOperationException"
+
+
+
+ 4305 : "com.cloud.exception.ConflictingNetworkSettingsException"
+
+
+
+ 4310 : "com.cloud.exception.DiscoveredWithErrorException"
+
+
+
+ 4315 : "com.cloud.exception.HAStateException"
+
+
+
+ 4320 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+
+ 4325 : "com.cloud.exception.InsufficientCapacityException"
+
+
+
+ 4330 : "com.cloud.exception.InsufficientNetworkCapacityException"
+
+
+
+ 4335 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+
+ 4340 : "com.cloud.exception.InsufficientStorageCapacityException"
+
+
+
+ 4345 : "com.cloud.exception.InternalErrorException"
+
+
+
+ 4350 : "com.cloud.exception.InvalidParameterValueException"
+
+
+
+ 4355 : "com.cloud.exception.ManagementServerException"
+
+
+
+ 4360 : "com.cloud.exception.NetworkRuleConflictException"
+
+
+
+ 4365 : "com.cloud.exception.PermissionDeniedException"
+
+
+
+ 4370 : "com.cloud.exception.ResourceAllocationException"
+
+
+
+ 4375 : "com.cloud.exception.ResourceInUseException"
+
+
+
+ 4380 : "com.cloud.exception.ResourceUnavailableException"
+
+
+
+ 4385 : "com.cloud.exception.StorageUnavailableException"
+
+
+
+ 4390 : "com.cloud.exception.UnsupportedServiceException"
+
+
+
+ 4395 : "com.cloud.exception.VirtualMachineMigrationException"
+
+
+
+ 4400 : "com.cloud.exception.AccountLimitException"
+
+
+
+ 4405 : "com.cloud.exception.AgentUnavailableException"
+
+
+
+ 4410 : "com.cloud.exception.CloudAuthenticationException"
+
+
+
+ 4415 : "com.cloud.exception.CloudException"
+
+
+
+ 4420 : "com.cloud.exception.CloudExecutionException"
+
+
+
+ 4425 : "com.cloud.exception.ConcurrentOperationException"
+
+
+
+ 4430 : "com.cloud.exception.ConflictingNetworkSettingsException"
+
+
+
+ 4435 : "com.cloud.exception.ConnectionException"
+
+
+
+ 4440 : "com.cloud.exception.DiscoveredWithErrorException"
+
+
+
+ 4445 : "com.cloud.exception.DiscoveryException"
+
+
+
+ 4450 : "com.cloud.exception.HAStateException"
+
+
+
+ 4455 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+
+ 4460 : "com.cloud.exception.InsufficientCapacityException"
+
+
+
+ 4465 : "com.cloud.exception.InsufficientNetworkCapacityException"
+
+
+
+ 4470 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+
+ 4475 : "com.cloud.exception.InsufficientStorageCapacityException"
+
+
+
+ 4480 : "com.cloud.exception.InsufficientVirtualNetworkCapcityException"
+
+
+
+ 4485 : "com.cloud.exception.InternalErrorException"
+
+
+
+ 4490 : "com.cloud.exception.InvalidParameterValueException"
+
+
+
+ 4495 : "com.cloud.exception.ManagementServerException"
+
+
+
+ 4500 : "com.cloud.exception.NetworkRuleConflictException"
+
+
+
+ 4505 : "com.cloud.exception.PermissionDeniedException"
+
+
+
+ 4510 : "com.cloud.exception.ResourceAllocationException"
+
+
+
+ 4515 : "com.cloud.exception.ResourceInUseException"
+
+
+
+ 4520 : "com.cloud.exception.ResourceUnavailableException"
+
+
+
+ 4525 : "com.cloud.exception.StorageUnavailableException"
+
+
+
+ 4530 : "com.cloud.exception.UnsupportedServiceException"
+
+
+
+ 4535 : "com.cloud.exception.VirtualMachineMigrationException"
+
+
+
+ 9999 : "com.cloud.api.ServerApiException"
+
+
+
+
+ Chapter 4.Chapter 4. Calling the CloudStack APICalling the CloudStack APIMaking API Requests4.1. Making API Requests
+ All CloudStack API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+ •
+ CloudStack API URL: This is the web services API entry point(for example, http://www.cloud.com:8080/client/api)
+ •
+ Command: The web services command you wish to execute, such as start a virtual machine or create a disk volume
+ •
+ Parameters: Any additional required or optional parameters for the command
+
+ A sample API GET request looks like the following:
+ http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+ Or in a more readable format:
+
+1. http://localhost:8080/client/api
+2. ?command=deployVirtualMachine
+3. &serviceOfferingId=1
+4. &diskOfferingId=1
+5. &templateId=2
+6. &zoneId=4
+7. &apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ
+8. &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+ The first line is the CloudStack API URL. This is the Cloud instance you wish to interact with.
+
+ The second line refers to the command you wish to execute. In our example, we are attempting to deploy a fresh new virtual machine. It is preceded by a (?) to separate itself from the CloudStack API URL.
+
+ Lines 3-6 are the parameters for this given command. To see the command and its request parameters, please refer to the appropriate section in the CloudStack API documentation. Each parameter field-value pair (field=value) is preceded by an ampersand character (&).
+
+ Line 7 is the user API Key that uniquely identifies the account. See Signing API Requests on page 7.
+
+ Line 8 is the signature hash created to authenticate the user account executing the API command. See Signing API Requests on page 7.
+ Enabling API Call Expiration4.2. Enabling API Call Expiration
+ You can set an expiry timestamp on API calls to prevent replay attacks over non-secure channels, such as HTTP. The server tracks the expiry timestamp you have specified and rejects all the subsequent API requests that come in after this validity period.
+
+ To enable this feature, add the following parameters to the API request:
+ •
+ signatureVersion=3: If the signatureVersion parameter is missing or is not equal to 3, the expires parameter is ignored in the API request.
+ •
+ expires=YYYY-MM-DDThh:mm:ssZ: Specifies the date and time at which the signature included in the request is expired. The timestamp is expressed in the YYYY-MM-DDThh:mm:ssZ format, as specified in the ISO 8601 standard.
+
+ For example:
+ expires=2011-10-10T12:00:00+0530
+ A sample API request with expiration is given below:
+ http://<IPAddress>:8080/client/api?command=listZones&signatureVersion=3&expires=2011-10-10T12:00:00+0530&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3DSigning API Requests4.3. Signing API Requests
+ Whether you access the CloudStack API with HTTP or HTTPS, it must still be signed so that CloudStack can verify the caller has been authenticated and authorized to execute the command. Make sure that you have both the API Key and Secret Key provided by the CloudStack administrator for your account before proceeding with the signing process.
+
+ To show how to sign a request, we will re-use the previous example.
+ http://http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+ Breaking this down, we have several distinct parts to this URL.
+ •
+ Base URL: This is the base URL to the CloudStack Management Server.
+ http://localhost:8080•
+ API Path: This is the path to the API Servlet that processes the incoming requests.
+ /client/api?•
+ Command String: This part of the query string comprises of the command, its parameters, and the API Key that identifies the account.
+ Note
+ As with all query string parameters of field-value pairs, the "field" component is case insensitive while all "value" values are case sensitive.
+ command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ•
+ Signature: This is the hashed signature of the Base URL that is generated using a combination of the user’s Secret Key and the HMAC SHA-1 hashing algorithm.
+
+ &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+ Every API request has the format Base URL+API Path+Command String+Signature.
+
+ To generate the signature.
+ 1.
+ For each field-value pair (as separated by a '&') in the Command String, URL encode each value so that it can be safely sent via HTTP GET.
+ Note
+ Make sure all spaces are encoded as "%20" rather than "+".
+ 2.
+ Lower case the entire Command String and sort it alphabetically via the field for each field-value pair. The result of this step would look like the following.
+ apikey=mivr6x7u6bn_sdahobpjnejpgest35exq-jb8cg20yi3yaxxcgpyuairmfi_ejtvwz0nukkjbpmy3y2bcikwfq&command=deployvirtualmachine&diskofferingid=1&serviceofferingid=1&templateid=2&zoneid=43.
+ Take the sorted Command String and run it through the HMAC SHA-1 hashing algorithm (most programming languages offer a utility method to do this) with the user’s Secret Key. Base64 encode the resulting byte array in UTF-8 so that it can be safely transmitted via HTTP. The final string produced after Base64 encoding should be "Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D".
+
+ By reconstructing the final URL in the format Base URL+API Path+Command String+Signature, the final URL should look like:
+ http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3DResponses4.4. ResponsesResponse Formats: XML and JSON4.4.1. Response Formats: XML and JSON
+ CloudStack supports two formats as the response to an API call. The default response is XML. If you would like the response to be in JSON, add &response=json to the Command String.
+
+ Sample XML Response:
+
+ <listipaddressesresponse>
+ <allocatedipaddress>
+ <ipaddress>192.168.10.141</ipaddress>
+ <allocated>2009-09-18T13:16:10-0700</allocated>
+ <zoneid>4</zoneid>
+ <zonename>WC</zonename>
+ <issourcenat>true</issourcenat>
+ </allocatedipaddress>
+ </listipaddressesresponse>
+
+ Sample JSON Response:
+
+ { "listipaddressesresponse" :
+ { "allocatedipaddress" :
+ [
+ {
+ "ipaddress" : "192.168.10.141",
+ "allocated" : "2009-09-18T13:16:10-0700",
+ "zoneid" : "4",
+ "zonename" : "WC",
+ "issourcenat" : "true"
+ }
+ ]
+ }
+ }
+Maximum Result Pages Returned4.4.2. Maximum Result Pages Returned
+ For each cloud, there is a default upper limit on the number of results that any API command will return in a single page. This is to help prevent overloading the cloud servers and prevent DOS attacks. For example, if the page size limit is 500 and a command returns 10,000 results, the command will return 20 pages.
+
+ The default page size limit can be different for each cloud. It is set in the global configuration parameter default.page.size. If your cloud has many users with lots of VMs, you might need to increase the value of this parameter. At the same time, be careful not to set it so high that your site can be taken down by an enormous return from an API call. For more information about how to set global configuration parameters, see "Describe Your Deployment" in the Installation Guide.
+
+ To decrease the page size limit for an individual API command, override the global setting with the page and pagesize parameters, which are available in any list* command (listCapabilities, listDiskOfferings, etc.).
+ •
+ Both parameters must be specified together.
+ •
+ The value of the pagesize parameter must be smaller than the value of default.page.size. That is, you can not increase the number of possible items in a result page, only decrease it.
+
+ For syntax information on the list* commands, see the API Reference.
+ Error Handling4.4.3. Error Handling
+ If an error occurs while processing an API request, the appropriate response in the format specified is returned. Each error response consists of an error code and an error text describing what possibly can go wrong. For an example error response, see page 12.
+
+ An HTTP error code of 401 is always returned if API request was rejected due to bad signatures, missing API Keys, or the user simply did not have the permissions to execute the command.
+ Asynchronous Commands4.5. Asynchronous Commands
+ Asynchronous commands were introduced in CloudStack 2.x. Commands are designated as asynchronous when they can potentially take a long period of time to complete such as creating a snapshot or disk volume. They differ from synchronous commands by the following:
+ •
+ They are identified in the API Reference by an (A).
+ •
+ They will immediately return a job ID to refer to the job that will be responsible in processing the command.
+ •
+ If executed as a "create" resource command, it will return the resource ID as well as the job ID.
+
+ You can periodically check the status of the job by making a simple API call to the command, queryAsyncJobResult and passing in the job ID.
+ Job Status4.5.1. Job Status
+ The key to using an asynchronous command is the job ID that is returned immediately once the command has been executed. With the job ID, you can periodically check the job status by making calls to queryAsyncJobResult command. The command will return three possible job status integer values:
+ •
+ 0 - Job is still in progress. Continue to periodically poll for any status changes.
+ •
+ 1 - Job has successfully completed. The job will return any successful response values associated with command that was originally executed.
+ •
+ 2 - Job has failed to complete. Please check the "jobresultcode" tag for failure reason code and "jobresult" for the failure reason.
+ Example4.5.2. Example
+ The following shows an example of using an asynchronous command. Assume the API command:
+ command=deployVirtualMachine&zoneId=1&serviceOfferingId=1&diskOfferingId=1&templateId=1
+
+ CloudStack will immediately return a job ID and any other additional data.
+
+ <deployvirtualmachineresponse>
+ <jobid>1</jobid>
+ <id>100</id>
+ </deployvirtualmachineresponse>
+
+ Using the job ID, you can periodically poll for the results by using the queryAsyncJobResult command.
+ command=queryAsyncJobResult&jobId=1
+ Three possible results could come from this query.
+
+ Job is still pending:
+
+ <queryasyncjobresult>
+ <jobid>1</jobid>
+ <jobstatus>0</jobstatus>
+ <jobprocstatus>1</jobprocstatus>
+ </queryasyncjobresult>
+
+ Job has succeeded:
+
+ <queryasyncjobresultresponse cloud-stack-version="3.0.1.6">
+ <jobid>1</jobid>
+ <jobstatus>1</jobstatus>
+ <jobprocstatus>0</jobprocstatus>
+ <jobresultcode>0</jobresultcode>
+ <jobresulttype>object</jobresulttype>
+ <jobresult>
+ <virtualmachine>
+ <id>450</id>
+ <name>i-2-450-VM</name>
+ <displayname>i-2-450-VM</displayname>
+ <account>admin</account>
+ <domainid>1</domainid>
+ <domain>ROOT</domain>
+ <created>2011-03-10T18:20:25-0800</created>
+ <state>Running</state>
+ <haenable>false</haenable>
+ <zoneid>1</zoneid>
+ <zonename>San Jose 1</zonename>
+ <hostid>2</hostid>
+ <hostname>905-13.sjc.lab.vmops.com</hostname>
+ <templateid>1</templateid>
+ <templatename>CentOS 5.3 64bit LAMP</templatename>
+ <templatedisplaytext>CentOS 5.3 64bit LAMP</templatedisplaytext>
+ <passwordenabled>false</passwordenabled>
+ <serviceofferingid>1</serviceofferingid>
+ <serviceofferingname>Small Instance</serviceofferingname>
+ <cpunumber>1</cpunumber>
+ <cpuspeed>500</cpuspeed>
+ <memory>512</memory>
+ <guestosid>12</guestosid>
+ <rootdeviceid>0</rootdeviceid>
+ <rootdevicetype>NetworkFilesystem</rootdevicetype>
+ <nic>
+ <id>561</id>
+ <networkid>205</networkid>
+ <netmask>255.255.255.0</netmask>
+ <gateway>10.1.1.1</gateway>
+ <ipaddress>10.1.1.225</ipaddress>
+ <isolationuri>vlan://295</isolationuri>
+ <broadcasturi>vlan://295</broadcasturi>
+ <traffictype>Guest</traffictype>
+ <type>Virtual</type>
+ <isdefault>true</isdefault>
+ </nic>
+ <hypervisor>XenServer</hypervisor>
+ </virtualmachine>
+ </jobresult>
+ </queryasyncjobresultresponse>
+
+ Job has failed:
+
+ <queryasyncjobresult>
+ <jobid>1</jobid>
+ <jobstatus>2</jobstatus>
+ <jobprocstatus>0</jobprocstatus>
+ <jobresultcode>551</jobresultcode>
+ <jobresulttype>text</jobresulttype>
+ <jobresult>Unable to deploy virtual machine id = 100 due to not enough capacity</jobresult>
+ </queryasyncjobresult>
+Chapter 5.Chapter 5. Working With Usage DataWorking With Usage Data
+ The Usage Server provides aggregated usage records which you can use to create billing integration for the CloudStack platform. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances. In the special case of bare metal instances, no template storage resources are consumed, but records showing zero usage are still included in the Usage Server's output.
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day. Its behavior is controlled by configuration settings as described in the CloudStack Administration Guide.
+ Usage Record Format5.1. Usage Record FormatVirtual Machine Usage Record Format5.1.1. Virtual Machine Usage Record Format
+ For running and allocated virtual machine usage, the following fields exist in a usage record:
+ •
+ account – name of the account
+ •
+ accountid – ID of the account
+ •
+ domainid – ID of the domain in which this account resides
+ •
+ zoneid – Zone where the usage occurred
+ •
+ description – A string describing what the usage record is tracking
+ •
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for VM running time)
+ •
+ usagetype – A number representing the usage type (see Usage Types)
+ •
+ rawusage – A number representing the actual usage in hours
+ •
+ virtualMachineId – The ID of the virtual machine
+ •
+ name – The name of the virtual machine
+ •
+ offeringid – The ID of the service offering
+ •
+ templateid – The ID of the template or the ID of the parent template. The parent template value is present when the current template was created from a volume.
+ •
+ usageid – Virtual machine
+ •
+ type – Hypervisor
+ •
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+ Network Usage Record Format5.1.2. Network Usage Record Format
+ For network usage (bytes sent/received), the following fields exist in a usage record.
+ •
+ account – name of the account
+ •
+ accountid – ID of the account
+ •
+ domainid – ID of the domain in which this account resides
+ •
+ zoneid – Zone where the usage occurred
+ •
+ description – A string describing what the usage record is tracking
+ •
+ usagetype – A number representing the usage type (see Usage Types)
+ •
+ rawusage – A number representing the actual usage in hours
+ •
+ usageid – Device ID (virtual router ID or external device ID)
+ •
+ type – Device type (domain router, external load balancer, etc.)
+ •
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+ IP Address Usage Record Format5.1.3. IP Address Usage Record Format
+ For IP address usage the following fields exist in a usage record.
+ •
+ account - name of the account
+ •
+ accountid - ID of the account
+ •
+ domainid - ID of the domain in which this account resides
+ •
+ zoneid - Zone where the usage occurred
+ •
+ description - A string describing what the usage record is tracking
+ •
+ usage - String representation of the usage, including the units of usage
+ •
+ usagetype - A number representing the usage type (see Usage Types)
+ •
+ rawusage - A number representing the actual usage in hours
+ •
+ usageid - IP address ID
+ •
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+ •
+ issourcenat - Whether source NAT is enabled for the IP address
+ •
+ iselastic - True if the IP address is elastic.
+ Disk Volume Usage Record Format5.1.4. Disk Volume Usage Record Format
+ For disk volumes, the following fields exist in a usage record.
+ •
+ account – name of the account
+ •
+ accountid – ID of the account
+ •
+ domainid – ID of the domain in which this account resides
+ •
+ zoneid – Zone where the usage occurred
+ •
+ description – A string describing what the usage record is tracking
+ •
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ •
+ usagetype – A number representing the usage type (see Usage Types)
+ •
+ rawusage – A number representing the actual usage in hours
+ •
+ usageid – The volume ID
+ •
+ offeringid – The ID of the disk offering
+ •
+ type – Hypervisor
+ •
+ templateid – ROOT template ID
+ •
+ size – The amount of storage allocated
+ •
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+ Template, ISO, and Snapshot Usage Record Format5.1.5. Template, ISO, and Snapshot Usage Record Format•
+ account – name of the account
+ •
+ accountid – ID of the account
+ •
+ domainid – ID of the domain in which this account resides
+ •
+ zoneid – Zone where the usage occurred
+ •
+ description – A string describing what the usage record is tracking
+ •
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ •
+ usagetype – A number representing the usage type (see Usage Types)
+ •
+ rawusage – A number representing the actual usage in hours
+ •
+ usageid – The ID of the the template, ISO, or snapshot
+ •
+ offeringid – The ID of the disk offering
+ •
+ templateid – – Included only for templates (usage type 7). Source template ID.
+ •
+ size – Size of the template, ISO, or snapshot
+ •
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+ Load Balancer Policy or Port Forwarding Rule Usage Record Format5.1.6. Load Balancer Policy or Port Forwarding Rule Usage Record Format•
+ account - name of the account
+ •
+ accountid - ID of the account
+ •
+ domainid - ID of the domain in which this account resides
+ •
+ zoneid - Zone where the usage occurred
+ •
+ description - A string describing what the usage record is tracking
+ •
+ usage - String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ •
+ usagetype - A number representing the usage type (see Usage Types)
+ •
+ rawusage - A number representing the actual usage in hours
+ •
+ usageid - ID of the load balancer policy or port forwarding rule
+ •
+ usagetype - A number representing the usage type (see Usage Types)
+ •
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+ Network Offering Usage Record Format5.1.7. Network Offering Usage Record Format•
+ account – name of the account
+ •
+ accountid – ID of the account
+ •
+ domainid – ID of the domain in which this account resides
+ •
+ zoneid – Zone where the usage occurred
+ •
+ description – A string describing what the usage record is tracking
+ •
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ •
+ usagetype – A number representing the usage type (see Usage Types)
+ •
+ rawusage – A number representing the actual usage in hours
+ •
+ usageid – ID of the network offering
+ •
+ usagetype – A number representing the usage type (see Usage Types)
+ •
+ offeringid – Network offering ID
+ •
+ virtualMachineId – The ID of the virtual machine
+ •
+ virtualMachineId – The ID of the virtual machine
+ •
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+ VPN User Usage Record Format5.1.8. VPN User Usage Record Format•
+ account – name of the account
+ •
+ accountid – ID of the account
+ •
+ domainid – ID of the domain in which this account resides
+ •
+ zoneid – Zone where the usage occurred
+ •
+ description – A string describing what the usage record is tracking
+ •
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ •
+ usagetype – A number representing the usage type (see Usage Types)
+ •
+ rawusage – A number representing the actual usage in hours
+ •
+ usageid – VPN user ID
+ •
+ usagetype – A number representing the usage type (see Usage Types)
+ •
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+ Usage Types5.2. Usage Types
+ The following table shows all usage types.
+
+ Type ID
+
+ Type Name
+
+ Description
+
+ 1
+
+ RUNNING_VM
+
+ Tracks the total running time of a VM per usage record period. If the VM is upgraded during the usage period, you will get a separate Usage Record for the new upgraded VM.
+
+
+ 2
+
+
+
+ ALLOCATED_VM
+
+
+
+ Tracks the total time the VM has been created to the time when it has been destroyed. This usage type is also useful in determining usage for specific templates such as Windows-based templates.
+
+
+
+ 3
+
+
+
+ IP_ADDRESS
+
+
+
+ Tracks the public IP address owned by the account.
+
+
+
+ 4
+
+
+
+ NETWORK_BYTES_SENT
+
+
+
+ Tracks the total number of bytes sent by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+
+ 5
+
+
+
+ NETWORK_BYTES_RECEIVED
+
+
+
+ Tracks the total number of bytes received by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+
+ 6
+
+
+
+ VOLUME
+
+
+
+ Tracks the total time a disk volume has been created to the time when it has been destroyed.
+
+
+
+ 7
+
+
+
+ TEMPLATE
+
+
+
+ Tracks the total time a template (either created from a snapshot or uploaded to the cloud) has been created to the time it has been destroyed. The size of the template is also returned.
+
+
+
+ 8
+
+
+
+ ISO
+
+
+
+ Tracks the total time an ISO has been uploaded to the time it has been removed from the cloud. The size of the ISO is also returned.
+
+
+
+ 9
+
+
+
+ SNAPSHOT
+
+
+
+ Tracks the total time from when a snapshot has been created to the time it have been destroyed.
+
+
+
+ 11
+
+
+
+ LOAD_BALANCER_POLICY
+
+
+
+ Tracks the total time a load balancer policy has been created to the time it has been removed. Cloud.com does not track whether a VM has been assigned to a policy.
+
+
+
+ 12
+
+
+
+ PORT_FORWARDING_RULE
+
+
+
+ Tracks the time from when a port forwarding rule was created until the time it was removed.
+
+
+
+ 13
+
+
+
+ NETWORK_OFFERING
+
+
+
+ The time from when a network offering was assigned to a VM until it is removed.
+
+
+
+ 14
+
+
+
+ VPN_USERS
+
+
+
+ The time from when a VPN user is created until it is removed.
+
+ Example response from listUsageRecords5.3. Example response from listUsageRecords
+ All CloudStack API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+
+ <listusagerecordsresponse>
+ <count>1816</count>
+ <usagerecord>
+ <account>user5</account>
+ <accountid>10004</accountid>
+ <domainid>1</domainid>
+ <zoneid>1</zoneid>
+ <description>i-3-4-WC running time (ServiceOffering: 1) (Template: 3)</description>
+ <usage>2.95288 Hrs</usage>
+ <usagetype>1</usagetype>
+ <rawusage>2.95288</rawusage>
+ <virtualmachineid>4</virtualmachineid>
+ <name>i-3-4-WC</name>
+ <offeringid>1</offeringid>
+ <templateid>3</templateid>
+ <usageid>245554</usageid>
+ <type>XenServer</type>
+ <startdate>2009-09-15T00:00:00-0700</startdate>
+ <enddate>2009-09-18T16:14:26-0700</enddate>
+ </usagerecord>
+
+ … (1,815 more usage records)
+ </listusagerecordsresponse>
+Dates in the Usage Record5.4. Dates in the Usage Record
+ Usage records include a start date and an end date. These dates define the period of time for which the raw usage number was calculated. If daily aggregation is used, the start date is midnight on the day in question and the end date is 23:59:59 on the day in question (with one exception; see below). A virtual machine could have been deployed at noon on that day, stopped at 6pm on that day, then started up again at 11pm. When usage is calculated on that day, there will be 7 hours of running VM usage (usage type 1) and 12 hours of allocated VM usage (usage type 2). If the same virtual machine runs for the entire next day, there will 24 hours of both running VM usage (type 1) and allocated VM usage (type 2).
+
+ Note: The start date is not the time a virtual machine was started, and the end date is not the time when a virtual machine was stopped. The start and end dates give the time range within which usage was calculated.
+
+ For network usage, the start date and end date again define the range in which the number of bytes transferred was calculated. If a user downloads 10 MB and uploads 1 MB in one day, there will be two records, one showing the 10 megabytes received and one showing the 1 megabyte sent.
+
+ There is one case where the start date and end date do not correspond to midnight and 11:59:59pm when daily aggregation is used. This occurs only for network usage records. When the usage server has more than one day's worth of unprocessed data, the old data will be included in the aggregation period. The start date in the usage record will show the date and time of the earliest event. For other types of usage, such as IP addresses and VMs, the old unprocessed data is not included in daily aggregation.
+ Appendix A. Event TypesAppendix A. Event Types
+
+ VM.CREATE
+
+
+
+ TEMPLATE.EXTRACT
+
+
+
+ SG.REVOKE.INGRESS
+
+
+
+ VM.DESTROY
+
+
+
+ TEMPLATE.UPLOAD
+
+
+
+ HOST.RECONNECT
+
+
+
+ VM.START
+
+
+
+ TEMPLATE.CLEANUP
+
+
+
+ MAINT.CANCEL
+
+
+
+ VM.STOP
+
+
+
+ VOLUME.CREATE
+
+
+
+ MAINT.CANCEL.PS
+
+
+
+ VM.REBOOT
+
+
+
+ VOLUME.DELETE
+
+
+
+ MAINT.PREPARE
+
+
+
+ VM.UPGRADE
+
+
+
+ VOLUME.ATTACH
+
+
+
+ MAINT.PREPARE.PS
+
+
+
+ VM.RESETPASSWORD
+
+
+
+ VOLUME.DETACH
+
+
+
+ VPN.REMOTE.ACCESS.CREATE
+
+
+
+ ROUTER.CREATE
+
+
+
+ VOLUME.UPLOAD
+
+
+
+ VPN.USER.ADD
+
+
+
+ ROUTER.DESTROY
+
+
+
+ SERVICEOFFERING.CREATE
+
+
+
+ VPN.USER.REMOVE
+
+
+
+ ROUTER.START
+
+
+
+ SERVICEOFFERING.UPDATE
+
+
+
+ NETWORK.RESTART
+
+
+
+ ROUTER.STOP
+
+
+
+ SERVICEOFFERING.DELETE
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+ ROUTER.REBOOT
+
+
+
+ DOMAIN.CREATE
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+ ROUTER.HA
+
+
+
+ DOMAIN.DELETE
+
+
+
+ STATICNAT.DISABLE
+
+
+
+ PROXY.CREATE
+
+
+
+ DOMAIN.UPDATE
+
+
+
+ SSVM.CREATE
+
+
+
+ PROXY.DESTROY
+
+
+
+ SNAPSHOT.CREATE
+
+
+
+ SSVM.DESTROY
+
+
+
+ PROXY.START
+
+
+
+ SNAPSHOT.DELETE
+
+
+
+ SSVM.START
+
+
+
+ PROXY.STOP
+
+
+
+ SNAPSHOTPOLICY.CREATE
+
+
+
+ SSVM.STOP
+
+
+
+ PROXY.REBOOT
+
+
+
+ SNAPSHOTPOLICY.UPDATE
+
+
+
+ SSVM.REBOOT
+
+
+
+ PROXY.HA
+
+
+
+ SNAPSHOTPOLICY.DELETE
+
+
+
+ SSVM.H
+
+
+
+ VNC.CONNECT
+
+
+
+ VNC.DISCONNECT
+
+
+
+ NET.IPASSIGN
+
+
+
+ NET.IPRELEASE
+
+
+
+ NET.RULEADD
+
+
+
+ NET.RULEDELETE
+
+
+
+ NET.RULEMODIFY
+
+
+
+ NETWORK.CREATE
+
+
+
+ NETWORK.DELETE
+
+
+
+ LB.ASSIGN.TO.RULE
+
+
+
+ LB.REMOVE.FROM.RULE
+
+
+
+ LB.CREATE
+
+
+
+ LB.DELETE
+
+
+
+ LB.UPDATE
+
+
+
+ USER.LOGIN
+
+
+
+ USER.LOGOUT
+
+
+
+ USER.CREATE
+
+
+
+ USER.DELETE
+
+
+
+ USER.UPDATE
+
+
+
+ USER.DISABLE
+
+
+
+ TEMPLATE.CREATE
+
+
+
+ TEMPLATE.DELETE
+
+
+
+ TEMPLATE.UPDATE
+
+
+
+ TEMPLATE.COPY
+
+
+
+ TEMPLATE.DOWNLOAD.START
+
+
+
+ TEMPLATE.DOWNLOAD.SUCCESS
+
+
+
+ TEMPLATE.DOWNLOAD.FAILED
+
+
+
+ ISO.CREATE
+
+
+
+ ISO.DELETE
+
+
+
+ ISO.COPY
+
+
+
+ ISO.ATTACH
+
+
+
+ ISO.DETACH
+
+
+
+ ISO.EXTRACT
+
+
+
+ ISO.UPLOAD
+
+
+
+ SERVICE.OFFERING.CREATE
+
+
+
+ SERVICE.OFFERING.EDIT
+
+
+
+ SERVICE.OFFERING.DELETE
+
+
+
+ DISK.OFFERING.CREATE
+
+
+
+ DISK.OFFERING.EDIT
+
+
+
+ DISK.OFFERING.DELETE
+
+
+
+ NETWORK.OFFERING.CREATE
+
+
+
+ NETWORK.OFFERING.EDIT
+
+
+
+ NETWORK.OFFERING.DELETE
+
+
+
+ POD.CREATE
+
+
+
+ POD.EDIT
+
+
+
+ POD.DELETE
+
+
+
+ ZONE.CREATE
+
+
+
+ ZONE.EDIT
+
+
+
+ ZONE.DELETE
+
+
+
+ VLAN.IP.RANGE.CREATE
+
+
+
+ VLAN.IP.RANGE.DELETE
+
+
+
+ CONFIGURATION.VALUE.EDIT
+
+
+
+ SG.AUTH.INGRESS
+
+
+
+
+ Appendix B. AlertsAppendix B. Alerts
+ The following is the list of alert type numbers. The current alerts can be found by calling listAlerts.
+ MEMORY = 0CPU = 1STORAGE =2STORAGE_ALLOCATED = 3PUBLIC_IP = 4PRIVATE_IP = 5HOST = 6USERVM = 7DOMAIN_ROUTER = 8CONSOLE_PROXY = 9ROUTING = 10// lost connection to default route (to the gateway)STORAGE_MISC = 11 // lost connection to default route (to the gateway)USAGE_SERVER = 12 // lost connection to default route (to the gateway)MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)DOMAIN_ROUTER_MIGRATE = 14CONSOLE_PROXY_MIGRATE = 15USERVM_MIGRATE = 16VLAN = 17SSVM = 18USAGE_SERVER_RESULT = 19STORAGE_DELETE = 20;UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource countUSAGE_SANITY_RESULT = 22;DIRECT_ATTACHED_PUBLIC_IP = 23;LOCAL_STORAGE = 24;RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots onlyAppendix C. Time ZonesAppendix C. Time Zones
+ 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
+
+
+
+
+ Appendix D. Revision HistoryAppendix D. Revision History
+ Revision 0-0Tue May 29 2012Jessica Tomechak
+ Initial creation of book by publican
+
+
+
+
diff --git a/docs/tmp/en-US/xml/API_Developers_Guide.xml b/docs/tmp/en-US/xml/API_Developers_Guide.xml
new file mode 100644
index 00000000000..150824c2b81
--- /dev/null
+++ b/docs/tmp/en-US/xml/API_Developers_Guide.xml
@@ -0,0 +1,58 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ &PRODUCT; API Developer's Guide
+ Apache CloudStack
+ 4.0.0-incubating
+
+
+
+
+ How to integrate with &PRODUCT; using the &PRODUCT; API.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Admin_Guide.ent b/docs/tmp/en-US/xml/Admin_Guide.ent
new file mode 100644
index 00000000000..abb18851bcf
--- /dev/null
+++ b/docs/tmp/en-US/xml/Admin_Guide.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Admin_Guide.fo b/docs/tmp/en-US/xml/Admin_Guide.fo
new file mode 100644
index 00000000000..c959329b712
--- /dev/null
+++ b/docs/tmp/en-US/xml/Admin_Guide.fo
@@ -0,0 +1,5116 @@
+
+CloudStack Administrator's GuideDocBook XSL Stylesheets with Apache FOPCloudStack Administrator's GuideTable of ContentsChapter 1. Concepts1.1. What Is CloudStack?1.2. What Can CloudStack Do?1.3. Deployment Architecture Overview1.3.1. Management Server Overview1.3.2. Cloud Infrastructure Overview1.3.3. Networking OverviewChapter 2. Cloud Infrastructure Concepts2.1. About Zones2.2. About Pods2.3. About Clusters2.4. About Hosts2.5. About Primary Storage2.6. About Secondary Storage2.7. About Physical Networks2.7.1. Configurable Characteristics of Physical Networks2.7.2. Basic Zone Network Traffic Types2.7.3. Basic Zone Guest IP Addresses2.7.4. Advanced Zone Network Traffic Types2.7.5. Advanced Zone Guest IP Addresses2.7.6. Advanced Zone Public IP Addresses2.7.7. System Reserved IP AddressesChapter 3. Accounts3.1. Accounts, Users, and Domains3.2. Using an LDAP Server for User Authentication3.2.1. Example LDAP Configuration Commands3.2.2. Search Base3.2.3. Query Filter3.2.4. Search User Bind DN3.2.5. SSL Keystore Path and PasswordChapter 4. User Services Overview4.1. Service Offerings, Disk Offerings, Network Offerings, and TemplatesChapter 5. User Interface5.1. Log In to the UI5.1.1. End User's UI Overview5.1.2. Root Administrator's UI Overview5.1.3. Logging In as the Root Administrator5.1.4. Changing the Root Password5.2. Using SSH Keys for Authentication5.2.1. Creating an Instance Template that Supports SSH Keys5.2.2. Creating the SSH Keypair5.2.3. Creating an Instance5.2.4. Logging In Using the SSH KeypairChapter 6. Using Projects to Organize Users and Resources6.1. Overview of Projects6.2. Configuring Projects6.2.1. Setting Up Invitations6.2.2. Setting Resource Limits for Projects6.2.2.1. Setting Per-Project Resource Limits6.2.2.2. Setting the Global Project Resource Limits6.2.3. Setting Project Creator Permissions6.3. Creating a New Project6.4. Adding Members to a Project6.4.1. Sending Project Membership Invitations6.4.2. Adding Project Members From the UI6.5. Accepting a Membership Invitation6.6. Suspending or Deleting a Project6.7. Using the Project ViewChapter 7. Steps to Provisioning Your Cloud Infrastructure7.1. Overview of Provisioning Steps7.2. Adding a Zone7.2.1. Basic Zone Configuration7.2.2. Advanced Zone Configuration7.3. Adding a Pod7.4. Adding a Cluster7.4.1. Add Cluster: KVM or XenServer7.4.2. Add Cluster: vSphere7.5. Adding a Host7.5.1. Adding a Host (XenServer or KVM)7.5.1.1. Requirements for XenServer and KVM Hosts7.5.1.1.1. XenServer Host Additional Requirements7.5.1.1.2. KVM Host Additional Requirements7.5.1.2. Adding a XenServer or KVM Host7.5.2. Adding a Host (vSphere)7.6. Add Primary Storage7.6.1. System Requirements for Primary Storage7.6.2. Adding Primary Stroage7.7. Add Secondary Storage7.7.1. System Requirements for Secondary Storage7.7.2. Adding Secondary Storage7.8. Initialize and TestChapter 8. Service Offerings8.1. Compute and Disk Service Offerings8.1.1. Creating a New Compute Offering8.1.2. Creating a New Disk Offering8.1.3. Modifying or Deleting a Service Offering8.2. System Service OfferingsChapter 9. Setting Up Networking for Users9.1. Overview of Setting Up Networking for Users9.2. About Virtual Networks9.2.1. Isolated Networks9.2.2. Shared Networks9.2.3. Runtime Allocation of Virtual Network Resources9.3. Network Service Providers9.4. Network OfferingsChapter 10. Working With Virtual Machines10.1. About Working with Virtual Machines10.2. Best Practices for Virtual Machines10.3. VM Lifecycle10.4. Creating VMs10.5. Accessing VMs10.6. Stopping and Starting VMs10.7. Changing the VM Name, OS, or Group10.8. Changing the Service Offering for a VM10.9. Moving VMs Between Hosts (Manual Live Migration)10.10. Deleting VMs10.11. Working with ISOs10.11.1. Adding an ISO10.11.2. Attaching an ISO to a VMChapter 11. Working With Hosts11.1. Adding Hosts11.2. Scheduled Maintenance and Maintenance Mode for Hosts11.3. Disabling and Enabling Zones, Pods, and Clusters11.4. Removing Hosts11.4.1. Removing XenServer and KVM Hosts11.4.2. Removing vSphere Hosts11.5. Re-Installing Hosts11.6. Maintaining Hypervisors on Hosts11.7. Changing Host Password11.8. Host Allocation11.9. VLAN ProvisioningChapter 12. Working with Templates12.1. Creating Templates: Overview12.2. Requirements for Templates12.3. Best Practices for Templates12.4. The Default Template12.5. Private and Public Templates12.6. Creating a Template from an Existing Virtual Machine12.7. Creating a Template from a Snapshot12.8. Uploading Templates12.9. Exporting Templates12.10. Creating a Windows Template12.10.1. System Preparation for Windows Server 2008 R212.10.2. Sysprep for Windows Server 2003 R212.11. Importing Amazon Machine Images12.12. Converting a Hyper-V VM to a Template12.13. Adding Password Management to Your Templates12.13.1. Linux OS Installation12.13.2. Windows OS Installation12.14. Deleting TemplatesChapter 13. Working With Storage13.1. Storage Overview13.2. Primary Storage13.2.1. Best Practices for Primary Storage13.2.2. Runtime Behavior of Primary Storage13.2.3. Hypervisor Support for Primary Storage13.2.4. Storage Tags13.2.5. Maintenance Mode for Primary Storage13.3. Secondary Storage13.4. Using Swift for Secondary Storage13.5. Working with SnapshotsChapter 14. Working with Usage14.1. Configuring the Usage Server14.2. Setting Usage Limits14.3. Globally Configured Limits14.4. Default Account Resource Limits14.5. Per-Domain LimitsChapter 15. Managing Networks and Traffic15.1. Guest Traffic15.2. Networking in a Pod15.3. Networking in a Zone15.4. Basic Zone Physical Network Configuration15.5. Advanced Zone Physical Network Configuration15.5.1. Configure Guest Traffic in an Advanced Zone15.5.2. Configure Public Traffic in an Advanced Zone15.6. Using Multiple Guest Networks15.6.1. Adding an Additional Guest Network15.6.2. Changing the Network Offering on a Guest Network15.7. Security Groups15.7.1. About Security Groups15.7.2. Adding a Security Group15.7.3. Enabling Security Groups15.7.4. Adding Ingress and Egress Rules to a Security Group15.8. External Firewalls and Load Balancers15.9. Load Balancer Rules15.10. Guest IP Ranges15.11. Acquiring a New IP Address15.12. Releasing an IP Address15.13. Static NAT15.14. IP Forwarding and Firewalling15.15. IP Load Balancing15.16. DNS and DHCP15.17. VPN15.17.1. Configuring VPN15.17.2. Using VPN with Windows15.17.3. Using VPN with Mac OS X15.17.4. Setting Up a Site-to-Site VPN Connection15.17.4.1. Creating and Updating a VPN Customer Gateway15.17.4.2. Creating a VPN gateway for the VPC15.17.4.3. Creating a VPN Connection15.17.4.4. Restarting and Removing a VPN Connection15.18. About Inter-VLAN Routing15.19. Configuring a Virtual Private Cloud15.19.1. About Virtual Private Clouds15.19.2. Adding a Virtual Private Cloud15.19.3. Adding Tiers15.19.4. Configuring Access Control List15.19.5. Adding a Private Gateway to a VPC15.19.6. Deploying VMs to the Tier15.19.7. Acquiring a New IP Address for a VPC15.19.8. Releasing an IP Address Alloted to a VPC15.19.9. Enabling or Disabling Static NAT on a VPC15.19.10. Adding Load Balancing Rules on a VPC15.19.11. Adding a Port Forwarding Rule on a VPC15.19.12. Removing Tiers15.19.13. Editing, Restarting, and Removing a Virtual Private CloudChapter 16. Working with System Virtual Machines16.1. The System VM Template16.2. Multiple System VM Support for VMware16.3. Console Proxy16.4. Virtual Router16.5. Secondary Storage VMChapter 17. System Reliability and High Availability17.1. HA for Management Server17.2. HA-Enabled Virtual Machines17.3. HA for Hosts17.4. Primary Storage Outage and Data Loss17.5. Secondary Storage Outage and Data LossChapter 18. Managing the Cloud18.1. Using Tags to Organize Resources in the Cloud18.2. Changing the Database Configuration18.3. Administrator Alerts18.4. Customizing the Network Domain Name18.5. Stopping and Restarting the Management ServerChapter 19. Setting Global Configuration ParametersChapter 20. CloudStack API20.1. Provisioning and Authentication API20.2. Allocators20.3. User Data and Meta DataChapter 21. Tuning21.1. Performance Monitoring21.2. Increase Management Server Maximum Memory21.3. Set Database Buffer Pool Size21.4. Set and Monitor Total VM Limits per Host21.5. Configure XenServer dom0 MemoryChapter 22. Troubleshooting22.1. Events22.1.1. Event Logs22.1.2. Standard Events22.1.3. Long Running Job Events22.1.4. Event Log Queries22.2. Working with Server Logs22.3. Data Loss on Exported Primary Storage22.4. Recovering a Lost Virtual Router22.5. Maintenance mode not working on vCenter22.6. Unable to deploy VMs from uploaded vSphere template22.7. Unable to power on virtual machine on VMware22.8. Load balancer rules fail after changing network offeringAppendix A. Time ZonesAppendix B. Event TypesAppendix C. AlertsAppendix D. Revision HistoryCloudStack Administrator's GuideApache CloudStack 4.0.0-incubatingCloudStack Administrator's Guide
+
+
+ Apache CloudStackApache CloudStack 4.0.0-incubating CloudStack Administrator's GuideAuthorApache CloudStack
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+ Administration Guide for CloudStack.
+ CloudStack Administrator's Guide1. Concepts1.1. What Is CloudStack?1.2. What Can CloudStack Do?1.3. Deployment Architecture Overview1.3.1. Management Server Overview1.3.2. Cloud Infrastructure Overview1.3.3. Networking Overview2. Cloud Infrastructure Concepts2.1. About Zones2.2. About Pods2.3. About Clusters2.4. About Hosts2.5. About Primary Storage2.6. About Secondary Storage2.7. About Physical Networks2.7.1. Configurable Characteristics of Physical Networks2.7.2. Basic Zone Network Traffic Types2.7.3. Basic Zone Guest IP Addresses2.7.4. Advanced Zone Network Traffic Types2.7.5. Advanced Zone Guest IP Addresses2.7.6. Advanced Zone Public IP Addresses2.7.7. System Reserved IP Addresses3. Accounts3.1. Accounts, Users, and Domains3.2. Using an LDAP Server for User Authentication3.2.1. Example LDAP Configuration Commands3.2.2. Search Base3.2.3. Query Filter3.2.4. Search User Bind DN3.2.5. SSL Keystore Path and Password4. User Services Overview4.1. Service Offerings, Disk Offerings, Network Offerings, and Templates5. User Interface5.1. Log In to the UI5.1.1. End User's UI Overview5.1.2. Root Administrator's UI Overview5.1.3. Logging In as the Root Administrator5.1.4. Changing the Root Password5.2. Using SSH Keys for Authentication5.2.1. Creating an Instance Template that Supports SSH Keys5.2.2. Creating the SSH Keypair5.2.3. Creating an Instance5.2.4. Logging In Using the SSH Keypair6. Using Projects to Organize Users and Resources6.1. Overview of Projects6.2. Configuring Projects6.2.1. Setting Up Invitations6.2.2. Setting Resource Limits for Projects6.2.3. Setting Project Creator Permissions6.3. Creating a New Project6.4. Adding Members to a Project6.4.1. Sending Project Membership Invitations6.4.2. Adding Project Members From the UI6.5. Accepting a Membership Invitation6.6. Suspending or Deleting a Project6.7. Using the Project View7. Steps to Provisioning Your Cloud Infrastructure7.1. Overview of Provisioning Steps7.2. Adding a Zone7.2.1. Basic Zone Configuration7.2.2. Advanced Zone Configuration7.3. Adding a Pod7.4. Adding a Cluster7.4.1. Add Cluster: KVM or XenServer7.4.2. Add Cluster: vSphere7.5. Adding a Host7.5.1. Adding a Host (XenServer or KVM)7.5.2. Adding a Host (vSphere)7.6. Add Primary Storage7.6.1. System Requirements for Primary Storage7.6.2. Adding Primary Stroage7.7. Add Secondary Storage7.7.1. System Requirements for Secondary Storage7.7.2. Adding Secondary Storage7.8. Initialize and Test8. Service Offerings8.1. Compute and Disk Service Offerings8.1.1. Creating a New Compute Offering8.1.2. Creating a New Disk Offering8.1.3. Modifying or Deleting a Service Offering8.2. System Service Offerings9. Setting Up Networking for Users9.1. Overview of Setting Up Networking for Users9.2. About Virtual Networks9.2.1. Isolated Networks9.2.2. Shared Networks9.2.3. Runtime Allocation of Virtual Network Resources9.3. Network Service Providers9.4. Network Offerings10. Working With Virtual Machines10.1. About Working with Virtual Machines10.2. Best Practices for Virtual Machines10.3. VM Lifecycle10.4. Creating VMs10.5. Accessing VMs10.6. Stopping and Starting VMs10.7. Changing the VM Name, OS, or Group10.8. Changing the Service Offering for a VM10.9. Moving VMs Between Hosts (Manual Live Migration)10.10. Deleting VMs10.11. Working with ISOs10.11.1. Adding an ISO10.11.2. Attaching an ISO to a VM11. Working With Hosts11.1. Adding Hosts11.2. Scheduled Maintenance and Maintenance Mode for Hosts11.3. Disabling and Enabling Zones, Pods, and Clusters11.4. Removing Hosts11.4.1. Removing XenServer and KVM Hosts11.4.2. Removing vSphere Hosts11.5. Re-Installing Hosts11.6. Maintaining Hypervisors on Hosts11.7. Changing Host Password11.8. Host Allocation11.9. VLAN Provisioning12. Working with Templates12.1. Creating Templates: Overview12.2. Requirements for Templates12.3. Best Practices for Templates12.4. The Default Template12.5. Private and Public Templates12.6. Creating a Template from an Existing Virtual Machine12.7. Creating a Template from a Snapshot12.8. Uploading Templates12.9. Exporting Templates12.10. Creating a Windows Template12.10.1. System Preparation for Windows Server 2008 R212.10.2. Sysprep for Windows Server 2003 R212.11. Importing Amazon Machine Images12.12. Converting a Hyper-V VM to a Template12.13. Adding Password Management to Your Templates12.13.1. Linux OS Installation12.13.2. Windows OS Installation12.14. Deleting Templates13. Working With Storage13.1. Storage Overview13.2. Primary Storage13.2.1. Best Practices for Primary Storage13.2.2. Runtime Behavior of Primary Storage13.2.3. Hypervisor Support for Primary Storage13.2.4. Storage Tags13.2.5. Maintenance Mode for Primary Storage13.3. Secondary Storage13.4. Using Swift for Secondary Storage13.5. Working with Snapshots14. Working with Usage14.1. Configuring the Usage Server14.2. Setting Usage Limits14.3. Globally Configured Limits14.4. Default Account Resource Limits14.5. Per-Domain Limits15. Managing Networks and Traffic15.1. Guest Traffic15.2. Networking in a Pod15.3. Networking in a Zone15.4. Basic Zone Physical Network Configuration15.5. Advanced Zone Physical Network Configuration15.5.1. Configure Guest Traffic in an Advanced Zone15.5.2. Configure Public Traffic in an Advanced Zone15.6. Using Multiple Guest Networks15.6.1. Adding an Additional Guest Network15.6.2. Changing the Network Offering on a Guest Network15.7. Security Groups15.7.1. About Security Groups15.7.2. Adding a Security Group15.7.3. Enabling Security Groups15.7.4. Adding Ingress and Egress Rules to a Security Group15.8. External Firewalls and Load Balancers15.9. Load Balancer Rules15.10. Guest IP Ranges15.11. Acquiring a New IP Address15.12. Releasing an IP Address15.13. Static NAT15.14. IP Forwarding and Firewalling15.15. IP Load Balancing15.16. DNS and DHCP15.17. VPN15.17.1. Configuring VPN15.17.2. Using VPN with Windows15.17.3. Using VPN with Mac OS X15.17.4. Setting Up a Site-to-Site VPN Connection15.18. About Inter-VLAN Routing15.19. Configuring a Virtual Private Cloud15.19.1. About Virtual Private Clouds15.19.2. Adding a Virtual Private Cloud15.19.3. Adding Tiers15.19.4. Configuring Access Control List15.19.5. Adding a Private Gateway to a VPC15.19.6. Deploying VMs to the Tier15.19.7. Acquiring a New IP Address for a VPC15.19.8. Releasing an IP Address Alloted to a VPC15.19.9. Enabling or Disabling Static NAT on a VPC15.19.10. Adding Load Balancing Rules on a VPC15.19.11. Adding a Port Forwarding Rule on a VPC15.19.12. Removing Tiers15.19.13. Editing, Restarting, and Removing a Virtual Private Cloud16. Working with System Virtual Machines16.1. The System VM Template16.2. Multiple System VM Support for VMware16.3. Console Proxy16.4. Virtual Router16.5. Secondary Storage VM17. System Reliability and High Availability17.1. HA for Management Server17.2. HA-Enabled Virtual Machines17.3. HA for Hosts17.4. Primary Storage Outage and Data Loss17.5. Secondary Storage Outage and Data Loss18. Managing the Cloud18.1. Using Tags to Organize Resources in the Cloud18.2. Changing the Database Configuration18.3. Administrator Alerts18.4. Customizing the Network Domain Name18.5. Stopping and Restarting the Management Server19. Setting Global Configuration Parameters20. CloudStack API20.1. Provisioning and Authentication API20.2. Allocators20.3. User Data and Meta Data21. Tuning21.1. Performance Monitoring21.2. Increase Management Server Maximum Memory21.3. Set Database Buffer Pool Size21.4. Set and Monitor Total VM Limits per Host21.5. Configure XenServer dom0 Memory22. Troubleshooting22.1. Events22.1.1. Event Logs22.1.2. Standard Events22.1.3. Long Running Job Events22.1.4. Event Log Queries22.2. Working with Server Logs22.3. Data Loss on Exported Primary Storage22.4. Recovering a Lost Virtual Router 22.5. Maintenance mode not working on vCenter22.6. Unable to deploy VMs from uploaded vSphere template22.7. Unable to power on virtual machine on VMware22.8. Load balancer rules fail after changing network offeringA. Time ZonesB. Event TypesC. AlertsD. Revision HistoryChapter 1.Chapter 1. ConceptsConceptsWhat Is CloudStack?1.1. What Is CloudStack?
+ CloudStack is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. CloudStack manages the network, storage, and compute nodes that make up a cloud infrastructure. Use CloudStack to deploy, manage, and configure cloud computing environments.
+
+ Typical users are service providers and enterprises. With CloudStack, you can:
+ •
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+ •
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with CloudStack an enterprise can offer self-service virtual machines to users without involving IT departments.
+ What Can CloudStack Do?1.2. What Can CloudStack Do?
+ Multiple Hypervisor Support
+
+ CloudStack works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of CloudStack supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+ Massively Scalable Infrastructure Management
+
+ CloudStack can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+ Automatic Configuration Management
+
+ CloudStack automatically configures each guest virtual machine’s networking and storage settings.
+
+ CloudStack internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+ Graphical User Interface
+
+ CloudStack offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+ API and Extensibility
+
+ CloudStack provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at Apache CloudStack Guides11http://incubator.apache.org/cloudstack/docs and Apache CloudStack API Reference22http://incubator.apache.org/cloudstack/docs/api respectively.
+
+ The CloudStack pluggable allocation architecture allows the creation of new types of allocators for the selection of storage and Hosts. See the Allocator Implementation Guide (http://docs.cloudstack.org/CloudStack_Documentation/Allocator_Implementation_Guide).
+
+ High Availability
+
+ CloudStack has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the hosts, CloudStack supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+ Deployment Architecture Overview1.3. Deployment Architecture Overview
+ A CloudStack installation consists of two parts: the Management Server and the cloud infrastructure that it manages. When you set up and manage a CloudStack cloud, you provision resources such as hosts, storage devices, and IP addresses into the Management Server, and the Management Server manages those resources.
+
+ The minimum production installation consists of one machine running the CloudStack Management Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure consisting of one host running hypervisor software). In its smallest deployment, a single machine can act as both the Management Server and the hypervisor host (using the KVM hypervisor).
+
+ A more full-featured installation consists of a highly-available multi-node Management Server installation and up to tens of thousands of hosts using any of several advanced networking setups. For information about deployment options, see Choosing a Deployment Architecture.
+ Management Server Overview1.3.1. Management Server Overview
+ The Management Server is the CloudStack software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+ The machine must meet the system requirements described in System Requirements.
+
+ The Management Server:
+ •
+ Provides the web user interface for the administrator and a reference user interface for end users.
+ •
+ Provides the APIs for CloudStack.
+ •
+ Manages the assignment of guest VMs to particular hosts.
+ •
+ Manages the assignment of public and private IP addresses to particular accounts.
+ •
+ Manages the allocation of storage to guests as virtual disks.
+ •
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+ •
+ Provides a single point of configuration for the cloud.
+ Cloud Infrastructure Overview1.3.2. Cloud Infrastructure Overview
+ The Management Server manages one or more zones (typically, datacenters) containing host computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
+ •
+ Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
+ •
+ Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
+ •
+ Cluster: A cluster consists of one or more hosts and primary storage.
+ •
+ Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines.
+ •
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster.
+ •
+ Secondary storage is associated with a zone, and it stores templates, ISO images, and disk volume snapshots.
+
+ More Information
+
+ For more information, see documentation on cloud infrastructure concepts.
+ Networking Overview1.3.3. Networking Overview
+ CloudStack offers two types of networking scenario:
+ •
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+ •
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+ For more details, see Network Setup.
+ Chapter 2.Chapter 2. Cloud Infrastructure ConceptsCloud Infrastructure ConceptsAbout Zones2.1. About Zones
+ A zone is the largest organizational unit within a CloudStack deployment. A zone typically corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter. The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required).
+
+ A zone consists of:
+ •
+ One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
+ •
+ Secondary storage, which is shared by all the pods in the zone.
+
+ Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones.
+
+ Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone.
+
+ Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels.
+
+ For each zone, the administrator must decide the following.
+ •
+ How many pods to place in a zone.
+ •
+ How many clusters to place in each pod.
+ •
+ How many hosts to place in each cluster.
+ •
+ How many primary storage servers to place in each cluster and total capacity for the storage servers.
+ •
+ How much secondary storage to deploy in 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.
+ About Pods2.2. About Pods
+ A pod often represents a single rack. Hosts in the same pod are in the same subnet.
+
+ A pod is the second-largest organizational unit within a CloudStack deployment. Pods are contained within zones. Each zone can contain one or more pods.
+
+ Pods are not visible to the end user.
+
+ A pod consists of one or more clusters of hosts and one or more primary storage servers.
+ About Clusters2.3. About Clusters
+ A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set of KVM servers, , or a VMware cluster preconfigured in vCenter. The hosts in a cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the same shared primary storage. Virtual machine instances (VMs) can be live-migrated from one host to another within the same cluster, without interrupting service to the user.
+
+ A cluster is the third-largest organizational unit within a CloudStack deployment. Clusters are contained within pods, and pods are contained within zones. Size of the cluster is limited by the underlying hypervisor, although the CloudStack recommends less in most cases; see Best Practices.
+
+ A cluster consists of one or more hosts and one or more primary storage servers.
+
+ CloudStack allows multiple clusters in a cloud deployment.
+
+ Even when local storage is used exclusively, clusters are still required organizationally, even if there is just one host per cluster.
+
+ When VMware is used, every VMware cluster is managed by a vCenter server. Administrator must register the vCenter server with CloudStack. There may be multiple vCenter servers per zone. Each vCenter server may manage multiple VMware clusters.
+ About Hosts2.4. About Hosts
+ A host is a single computer. Hosts provide the computing resources that run the guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a Linux KVM-enabled server, a Citrix XenServer server, and an ESXi server are hosts.
+
+ The host is the smallest organizational unit within a CloudStack deployment. Hosts are contained within clusters, clusters are contained within pods, and pods are contained within zones.
+
+ Hosts in a CloudStack deployment:
+ •
+ Provide the CPU, memory, storage, and networking resources needed to host the virtual machines
+ •
+ Interconnect using a high bandwidth TCP/IP network and connect to the Internet
+ •
+ May reside in multiple data centers across different geographic locations
+ •
+ May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the hosts within a cluster must all be homogeneous
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs.
+
+ CloudStack automatically detects the amount of CPU and memory resources provided by the Hosts.
+
+ Hosts are not visible to the end user. An end user cannot determine which host their guest has been assigned to.
+
+ For a host to function in CloudStack, you must do the following:
+ •
+ Install hypervisor software on the host
+ •
+ Assign an IP address to the host
+ •
+ Ensure the host is connected to the CloudStack Management Server
+ About Primary Storage2.5. About Primary Storage
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required. It is typically located close to the hosts for increased performance.
+
+ CloudStack is designed to work with all standards-compliant iSCSI and NFS servers that are supported by the underlying hypervisor, including, for example:
+ •
+ Dell EqualLogic™ for iSCSI
+ •
+ Network Appliances filers for NFS and iSCSI
+ •
+ Scale Computing for NFS
+
+ If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.
+ About Secondary Storage2.6. About Secondary Storage
+ Secondary storage is associated with a zone, and it stores the following:
+ •
+ Templates — OS images that can be used to boot VMs and can include additional configuration information, such as installed applications
+ •
+ ISO images — disc images containing data or bootable media for operating systems
+ •
+ Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
+
+ The items in zone-based NFS secondary storage are available to all hosts in the zone. CloudStack manages the allocation of guest virtual disks to particular primary storage devices.
+
+ To make items in secondary storage available to all hosts throughout the cloud, you can add OpenStack Object Storage (Swift, swift.openstack.org11http://swift.openstack.org) in addition to the zone-based NFS secondary storage. When using Swift, you configure Swift storage for the entire CloudStack, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere.
+ About Physical Networks2.7. About Physical Networks
+ Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical networks can be associated with each zone. The network corresponds to a NIC on the hypervisor host. Each physical network can carry one or more types of network traffic. The choices of traffic type for each network vary depending on whether you are creating a zone with basic networking or advanced networking.
+
+ A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can:
+ •
+ Add/Remove/Update physical networks in a zone
+ •
+ Configure VLANs on the physical network
+ •
+ Configure a name so the network can be recognized by hypervisors
+ •
+ Configure the service providers (firewalls, load balancers, etc.) available on a physical network
+ •
+ Configure the IP addresses trunked to a physical network
+ •
+ Specify what type of traffic is carried on the physical network, as well as other properties like network speed
+ Configurable Characteristics of Physical Networks2.7.1. Configurable Characteristics of Physical Networks
+ CloudStack provides configuration settings you can use to set up a physical network in a zone, including:
+ •
+ What type of network traffic it carries (guest, public, management, storage)
+ •
+ VLANs
+ •
+ Unique name that the hypervisor can use to find that particular network
+ •
+ Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator sets the physical network to enabled, and it begins to be used. The administrator can later disable the network again, which prevents any new virtual networks from being created on that physical network; the existing network traffic continues even though the state is disabled.
+ •
+ Speed
+ •
+ Tags, so network offerings can be matched to physical networks
+ •
+ Isolation method
+ Basic Zone Network Traffic Types2.7.2. Basic Zone Network Traffic Types
+ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types:
+ •
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod.
+ •
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+ Note
+ We strongly recommend the use of separate NICs for management traffic and guest traffic.
+ •
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address.
+ •
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. CloudStack takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.
+ Basic Zone Guest IP Addresses2.7.3. Basic Zone Guest IP Addresses
+ When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts.
+ Advanced Zone Network Traffic Types2.7.4. Advanced Zone Network Traffic Types
+ When advanced networking is used, there can be multiple physical networks in the zone. Each physical network can carry one or more traffic types, and you need to let CloudStack know which type of network traffic you want each network to carry. The traffic types in an advanced zone are:
+ •
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each CloudStack account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network.
+ •
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+ •
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide.
+ •
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices.
+ Advanced Zone Guest IP Addresses2.7.5. Advanced Zone Guest IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+ Advanced Zone Public IP Addresses2.7.6. Advanced Zone Public IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+ System Reserved IP Addresses2.7.7. System Reserved IP Addresses
+ In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the CloudStack Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
+
+ The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone.
+
+ The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in.
+
+ Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. CloudStack can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
+
+ In all zones:
+
+ Provide private IPs for the system in each pod and provision them in CloudStack.
+
+ For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.
+
+ In a zone that uses advanced networking:
+
+ For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required CloudStack System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.
+
+ When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
+
+ To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:
+ •
+ Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than 4,000 IP addresses.
+ •
+ Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod has 255 IPs, this will provide 2,550 IP addresses.
+ Chapter 3.Chapter 3. AccountsAccountsAccounts, Users, and Domains3.1. Accounts, Users, and DomainsAccounts
+ 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
+
+ The 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.
+ Using an LDAP Server for User Authentication3.2. Using an LDAP Server for User Authentication
+ You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate CloudStack end-users. Just map CloudStack accounts to the corresponding LDAP accounts using a query filter. The query filter is written using the query syntax of the particular LDAP server, and can include special wildcard characters provided by CloudStack for matching common values such as the user’s email address and name. CloudStack will search the external LDAP directory tree starting at a specified base directory and return the distinguished name (DN) and password of the matching user. This information along with the given password is used to authenticate the user..
+
+ To set up LDAP authentication in CloudStack, call the CloudStack API command ldapConfig and provide the following:
+ •
+ Hostname or IP address and listening port of the LDAP server
+ •
+ Base directory and query filter
+ •
+ Search user DN credentials, which give CloudStack permission to search on the LDAP server
+ •
+ SSL keystore and password, if SSL is used
+ Example LDAP Configuration Commands3.2.1. Example LDAP Configuration Commands
+ To understand the examples in this section, you need to know the basic concepts behind calling the CloudStack API, which are explained in the Developer’s Guide.
+
+ The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
+ 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:
+ 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.
+ 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 Base3.2.2. Search Base
+ An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The search base is the distinguished name (DN) of a level of the directory tree below which all users can be found. The users can be in the immediate base directory or in some subdirectory. The search base may be equivalent to the organization, group, or domain name. The syntax for writing a DN varies depending on which LDAP server you are using. A full discussion of distinguished names is outside the scope of our documentation. The following table shows some examples of search bases to find users in the testing department..
+
+
+ LDAP Server
+
+
+
+ Example Search Base DN
+
+
+
+ ApacheDS
+
+
+
+ ou=testing,o=project
+
+
+
+ Active Directory
+
+
+
+ OU=testing, DC=company
+
+ Query Filter3.2.3. Query Filter
+ The query filter is used to find a mapped user in the external LDAP server. The query filter should uniquely map the CloudPlatform user to LDAP user for a meaningful authentication. For more information about query filter syntax, consult the documentation for your LDAP server.
+
+ The CloudPlatform 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 CloudPlatform user name is the same as the LDAP user ID:
+ (uid=%u)
+ If the CloudPlatform user name is the LDAP display name:
+ (displayName=%u)
+ To find a user by email address:
+ (mail=%e)Search User Bind DN3.2.4. Search User Bind DN
+ The bind DN is the user on the external LDAP server permitted to search the LDAP directory within the defined search base. When the DN is returned, the DN and passed password are used to authenticate the CloudStack user with an LDAP bind. A full discussion of bind DNs is outside the scope of our documentation. The following table shows some examples of bind DNs.
+
+
+ LDAP Server
+
+
+
+ Example Bind DN
+
+
+
+ ApacheDS
+
+
+
+ cn=Administrator,dc=testing,ou=project,ou=org
+
+
+
+ Active Directory
+
+
+
+ CN=Administrator, OU=testing, DC=company, DC=com
+
+ SSL Keystore Path and Password3.2.5. SSL Keystore Path and Password
+ If the LDAP server requires SSL, you need to enable it in the ldapConfig command by setting the parameters ssl, truststore, and truststorepass. Before enabling SSL for ldapConfig, you need to get the certificate which the LDAP server is using and add it to a trusted keystore. You will need to know the path to the keystore and the password.
+ Chapter 4.Chapter 4. User Services OverviewUser Services Overview
+ In addition to the physical and logical infrastructure of your cloud, and the CloudStack software and servers, you also need a layer of user services so that people can actually make use of the cloud. This means not just a user UI, but a set of options and resources that users can choose from, such as templates for creating virtual machines, disk storage, and more. If you are running a commercial service, you will be keeping track of what services and resources users are consuming and charging them for that usage. Even if you do not charge anything for people to use your cloud – say, if the users are strictly internal to your organization, or just friends who are sharing your cloud – you can still keep track of what services they use and how much of them.
+ Service Offerings, Disk Offerings, Network Offerings, and Templates4.1. Service Offerings, Disk Offerings, Network Offerings, and Templates
+ A user creating a new instance can make a variety of choices about its characteristics and capabilities. CloudStack provides several ways to present users with choices when creating a new instance:
+ •
+ Service Offerings, defined by the CloudStack administrator, provide a choice of CPU speed, number of CPUs, RAM size, tags on the root disk, and other choices. See Creating a New Compute Offering.
+ •
+ Disk Offerings, defined by the CloudStack administrator, provide a choice of disk size for primary data storage. See Creating a New Disk Offering.
+ •
+ Network Offerings, defined by the CloudStack administrator, describe the feature set that is available to end users from the virtual router or external networking devices on a given guest network. See Network Offerings.
+ •
+ Templates, defined by the CloudStack administrator or by any CloudStack user, are the base OS images that the user can choose from when creating a new instance. For example, CloudStack includes CentOS as a template. See Working with Templates.
+
+ In addition to these choices that are provided for users, there is another type of service offering which is available only to the CloudStack root administrator, and is used for configuring virtual infrastructure resources. For more information, see Upgrading a Virtual Router with System Service Offerings.
+ Chapter 5.Chapter 5. User InterfaceUser InterfaceLog In to the UI5.1. Log In to the UI
+ CloudStack provides a web-based UI that can be used by both administrators and end users. The appropriate version of the UI is displayed depending on the credentials used to log in. The UI is available in popular browsers including IE7, IE8, IE9, Firefox 3.5+, Firefox 4, Safari 4, and Safari 5. The URL is: (substitute your own management server IP address)
+ 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 Overview5.1.1. End User's UI Overview
+ The CloudStack UI helps users of cloud infrastructure to view and use their cloud resources, including virtual machines, templates and ISOs, data volumes and snapshots, guest networks, and IP addresses. If the user is a member or administrator of one or more CloudStack projects, the UI can provide a project-oriented view.
+ Root Administrator's UI Overview5.1.2. Root Administrator's UI Overview
+ The CloudStack UI helps the CloudStack administrator provision, view, and manage the cloud infrastructure, domains, user accounts, projects, and configuration settings. The first time you start the UI after a fresh Management Server installation, you can choose to follow a guided tour to provision your cloud infrastructure. On subsequent logins, the dashboard of the logged-in user appears. The various links in this screen and the navigation bar on the left provide access to a variety of administrative functions. The root administrator can also use the UI to perform all the same tasks that are present in the end-user’s UI.
+ Logging In as the Root Administrator5.1.3. Logging In as the Root Administrator
+ After the Management Server software is installed and running, you can run the CloudStack user interface. This UI is there to help you provision, view, and manage your cloud infrastructure.
+ 1.
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+ 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.
+ 2.
+ 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 CloudPlatform, 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.
+ 3.
+ 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”.
+ 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 Password5.1.4. Changing the Root Password
+ During installation and ongoing cloud administration, you will need to log in to the UI as the root administrator. The root administrator account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. When first installing CloudStack, be sure to change the default password to a new, unique value.
+ 1.
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+ http://<management-server-ip-address>:8080/client2.
+ Log in to the UI using the current root user ID and password. The default is admin, password.
+ 3.
+ Click Accounts.
+ 4.
+ Click the admin account name.
+ 5.
+ Click View Users.
+ 6.
+ Click the admin user name.
+ 7.
+ Click the Change Password button.
+
+ 8.
+ Type the new password, and click OK.
+ Using SSH Keys for Authentication5.2. Using SSH Keys for Authentication
+ In addition to the username and password authentication, CloudStack supports using SSH keys to log in to the cloud infrastructure for additional security. You can use the createSSHKeyPair API to generate the SSH keys.
+
+ Because each cloud user has their own SSH key, one cloud user cannot log in to another cloud user's instances unless they share their SSH key files. Using a single SSH key pair, you can manage multiple instances.
+ Creating an Instance Template that Supports SSH Keys5.2.1. Creating an Instance Template that Supports SSH Keys
+ Create a instance template that supports SSH Keys.
+ 1.
+ Create a new instance by using the template provided by cloudstack.
+
+ For more information on creating a new instance, see
+ 2.
+ Download the cloudstack script from The SSH Key Gen Script11http://sourceforge.net/projects/cloudstack/files/SSH%20Key%20Gen%20Script/to the instance you have created.
+ 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=iweb3.
+ Copy the file to /etc/init.d.
+ cp cloud-set-guest-sshkey.in /etc/init.d/4.
+ Give the necessary permissions on the script:
+ chmod +x /etc/init.d/cloud-set-guest-sshkey.in5.
+ Run the script while starting up the operating system:
+ chkconfig --add cloud-set-guest-sshkey.in6.
+ Stop the instance.
+ Creating the SSH Keypair5.2.2. Creating the SSH Keypair
+ You must make a call to the createSSHKeyPair api method. You can either use the CloudStack Python API library or the curl commands to make the call to the cloudstack api.
+
+ For example, make a call from the cloudstack server to create a SSH keypair called "keypair-doc" for the admin account in the root domain:
+ Note
+ Ensure that you adjust these values to meet your needs. If you are making the API call from a different server, your URL/PORT will be different, and you will need to use the API keys.
+ 1.
+ Run the following curl command:
+ 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:
+ <?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>2.
+ Copy the key data into a file. The file looks like this:
+ -----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-----3.
+ Save the file.
+ Creating an Instance5.2.3. Creating an Instance
+ After you save the SSH keypair file, you must create an instance by using the template that you created at Section 5.2.1, “ Creating an Instance Template that Supports SSH Keys”. Ensure that you use the same SSH key name that you created at Section 5.2.2, “Creating the 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:
+ curl --globoff http://localhost:<port numbet>/?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 Keypair5.2.4. Logging In Using the SSH Keypair
+ To test your SSH key generation is successful, check whether you can log in to the cloud setup.
+
+ For exaple, from a Linux OS, run:
+ ssh -i ~/.ssh/keypair-doc <ip address>
+ The -i parameter tells the ssh client to use a ssh key found at ~/.ssh/keypair-doc.
+ Chapter 6.Chapter 6. Using Projects to Organize Users and ResourcesUsing Projects to Organize Users and ResourcesOverview of Projects6.1. 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 Projects6.2. Configuring Projects
+ Before CloudPlatform users start using projects, the CloudPlatform 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 Invitations6.2.1. 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.
+ •
+ In the search box, type project and click the search button.
+
+ •
+ In the search results, you will 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
+ service cloud-management restartSetting Resource Limits for Projects6.2.2. 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
+ 6.2.2.1. 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”). 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.
+ 1.
+ Log in as administrator to the CloudStack UI.
+ 2.
+ In the left navigation, click Projects.
+ 3.
+ In Select View, choose Projects.
+ 4.
+ Click the name of the project you want to work with.
+ 5.
+ Click the Resources tab. This tab lists the current maximum amount that the project is allowed to own for each type of resource.
+ 6.
+ Type new values for one or more resources.
+ 7.
+ Click Apply.
+ 6.2.2.2. Setting the Global Project Resource Limits1.
+ Log in as administrator to the CloudStack UI.
+ 2.
+ In the left navigation, click Global Settings.
+ 3.
+ In the search box, type max.projects and click the search button.
+ 4.
+ 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.
+
+
+
+ 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.
+
+ 5.
+ Restart the Management Server.
+ # service cloud-management restartSetting Project Creator Permissions6.2.3. 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.
+ 1.
+ Log in as administrator to the CloudStack UI.
+ 2.
+ In the left navigation, click Global Settings.
+ 3.
+ In the search box, type allow.user.create.projects.
+ 4.
+ Click the edit button to set the parameter.
+
+
+
+ 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.
+
+ 5.
+ Restart the Management Server.
+ # service cloud-management restartCreating a New Project6.3. 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.
+ 1.
+ Log in as administrator to the CloudStack UI.
+ 2.
+ In the left navigation, click Projects.
+ 3.
+ In Select view, click Projects.
+ 4.
+ Click New Project.
+ 5.
+ Give the project a name and description for display to users, then click Create Project.
+ 6.
+ 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.
+ 7.
+ Click Save.
+ Adding Members to a Project6.4. 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 Invitations6.4.1. 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”. If the invitations feature is not turned on, use the procedure in Adding Project Members From the UI.
+ 1.
+ Log in to the CloudStack UI.
+ 2.
+ In the left navigation, click Projects.
+ 3.
+ In Select View, choose Projects.
+ 4.
+ Click the name of the project you want to work with.
+ 5.
+ Click the Invitations tab.
+ 6.
+ In Add by, select one of the following:
+ a.
+ Account – The invitation will appear in the user’s Invitations tab in the Project View. See Using the Project View.
+ b.
+ 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”.
+ 7.
+ 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.
+ 8.
+ 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 UI6.4.2. 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”, use the procedure in Section 6.4.1, “Sending Project Membership Invitations”.
+ 1.
+ Log in to the CloudStack UI.
+ 2.
+ In the left navigation, click Projects.
+ 3.
+ In Select View, choose Projects.
+ 4.
+ Click the name of the project you want to work with.
+ 5.
+ Click the Accounts tab. The current members of the project are listed.
+ 6.
+ 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 Invitation6.5. 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:
+ 1.
+ Log in to the CloudStack UI.
+ 2.
+ In the left navigation, click Projects.
+ 3.
+ In Select View, choose Invitations.
+ 4.
+ If you see the invitation listed onscreen, click the Accept button.
+
+ Invitations listed on screen were sent to you using your CloudStack account name.
+ 5.
+ 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 Project6.6. 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.
+ 1.
+ Log in to the CloudStack UI.
+ 2.
+ In the left navigation, click Projects.
+ 3.
+ In Select View, choose Projects.
+ 4.
+ Click the name of the project.
+ 5.
+ Click one of the buttons:
+
+ To delete, use
+
+
+ To suspend, use
+
+ Using the Project View6.7. 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.
+ 1.
+ Log in to the CloudStack UI.
+ 2.
+ Click Project View.
+ 3.
+ 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.
+ Chapter 7.Chapter 7. Steps to Provisioning Your Cloud InfrastructureSteps to Provisioning Your Cloud Infrastructure
+ This section tells how to add 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.
+ Overview of Provisioning Steps7.1. 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”.
+
+ To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
+ 1.
+ Change the root password. See Section 5.1.4, “Changing the Root Password”.
+ 2.
+ Add a zone. See Section 7.2, “Adding a Zone”.
+ 3.
+ Add more pods (optional). See Section 7.3, “Adding a Pod”.
+ 4.
+ Add more clusters (optional). See Section 7.4, “Adding a Cluster”.
+ 5.
+ Add more hosts (optional). See Section 7.5, “Adding a Host”.
+ 6.
+ Add primary storage. See Section 7.6, “Add Primary Storage”.
+ 7.
+ Add secondary storage. See Section 7.7, “Add Secondary Storage”.
+ 8.
+ Initialize and test the new cloud. See Section 7.8, “Initialize and Test”.
+
+ When you have finished these steps, you will have a deployment with the following basic structure:
+ Adding a Zone7.2. Adding a Zone
+ These steps assume you have already logged in to the CloudStack UI. See Section 5.1, “Log In to the UI”.
+ 1.
+ (Optional) If you are going to use Swift for cloud-wide secondary storage, you need to add it before you add zones.
+ a.
+ Log in to the CloudStack UI as administrator.
+ b.
+ If this is your first time visiting the UI, you will see the guided tour splash screen. Choose “Experienced user.” The Dashboard appears.
+ c.
+ In the left navigation bar, click Global Settings.
+ d.
+ In the search box, type swift.enable and click the search button.
+ e.
+ Click the edit button and set swift.enable to true.
+
+
+ f.
+ Restart the Management Server.
+ # service cloud-management restartg.
+ Refresh the CloudStack UI browser tab and log back in.
+ 2.
+ In the left navigation, choose Infrastructure.
+ 3.
+ On Zones, click View More.
+ 4.
+ (Optional) If you are using Swift storage, click Enable Swift. Provide the following:
+ •
+ URL. The Swift URL.
+ •
+ Account. The Swift account.
+ •
+ Username. The Swift account’s username.
+ •
+ Key. The Swift key.
+ 5.
+ Click Add Zone. The zone creation wizard will appear.
+ 6.
+ 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.
+
+ For more information about the network types, see Network Setup.
+ 7.
+ The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you:
+ •
+ Section 7.2.1, “Basic Zone Configuration”
+ •
+ Section 7.2.2, “Advanced Zone Configuration”
+ Basic Zone Configuration7.2.1. Basic Zone Configuration1.
+ 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.
+ 2.
+ 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.
+ 3.
+ (Introduced in version 3.0.1) 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.
+ 4.
+ Click Next.
+ 5.
+ (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.
+ 6.
+ (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.
+ 7.
+ 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.2, “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.
+ 8.
+ 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.
+ 9.
+ 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.
+ 10.
+ 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.
+ 11.
+ In a new cluster, CloudPlatform 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 Configuration7.2.2. Advanced Zone Configuration1.
+ 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.
+ 2.
+ 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.7.4, “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.
+ 3.
+ (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.
+ 4.
+ Click Next.
+ 5.
+ 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.
+ 6.
+ 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.2, “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.7.7, “System Reserved IP Addresses”.
+ 7.
+ Specify a range of VLAN IDs to carry guest traffic for each physical network (see VLAN Allocation Example ), then click Next.
+ 8.
+ 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.3, “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.
+ 9.
+ 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.4, “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.
+ 10.
+ 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.5, “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.
+
+
+ 11.
+ In a new zone, CloudStack adds the first secondary storage server for you. For an overview of what secondary storage is, see Section 2.6, “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.
+ •
+ Path. The exported path from the server.
+ 12.
+ Click Launch.
+ Adding a Pod7.3. 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.
+ 1.
+ Log in to the CloudStack UI. See Section 5.1, “Log In to the UI”.
+ 2.
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone to which you want to add a pod.
+ 3.
+ Click the Compute and Storage tab. In the Pods node of the diagram, click View All.
+ 4.
+ Click Add Pod.
+ 5.
+ 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.
+ 6.
+ Click OK.
+ Adding a Cluster7.4. 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 XenServer7.4.1. Add Cluster: KVM or XenServer
+ These steps assume you have already installed the hypervisor on the hosts and logged in to the CloudStack UI.
+ 1.
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the cluster.
+ 2.
+ Click the Compute tab.
+ 3.
+ In the Clusters node of the diagram, click View All.
+ 4.
+ Click Add Cluster.
+ 5.
+ Choose the hypervisor type for this cluster.
+ 6.
+ Choose the pod in which you want to create the cluster.
+ 7.
+ Enter a name for the cluster. This can be text of your choosing and is not used by CloudStack.
+ 8.
+ Click OK.
+ Add Cluster: vSphere7.4.2. 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:
+ 1.
+ 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.
+ 2.
+ Log in to the UI.
+ 3.
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the cluster.
+ 4.
+ Click the Compute tab, and click View All on Pods. Choose the pod to which you want to add the cluster.
+ 5.
+ Click View Clusters.
+ 6.
+ Click Add Cluster.
+ 7.
+ In Hypervisor, choose VMware.
+ 8.
+ Provide the following information in the dialog. The fields below make reference to values from vCenter.
+ •
+ Cluster Name. Enter the name of the cluster you created in vCenter. For example, "cloud.cluster.2.2.1"
+ •
+ vCenter Host. Enter the hostname or IP address of the vCenter server.
+ •
+ vCenter Username. Enter the username that CloudStack should use to connect to vCenter. This user must have all administrative privileges.
+ •
+ 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".
+ •
+ There might be a slight delay while the cluster is provisioned. It will automatically display in the UI
+ Adding a Host7.5. Adding a Host1.
+ 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.
+ 2.
+ Now add the hypervisor host to CloudStack. The technique to use varies depending on the hypervisor.
+ •
+ Section 7.5.1, “Adding a Host (XenServer or KVM)”
+ •
+ Section 7.5.2, “Adding a Host (vSphere)”
+ Adding a Host (XenServer or KVM)7.5.1. Adding a Host (XenServer or KVM)
+ XenServer and KVM hosts can be added to a cluster at any time.
+ 7.5.1.1. Requirements for XenServer and KVM HostsWarning
+ 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.
+ 7.5.1.1.1. 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.
+ # 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.
+ 1.
+ Copy the script from the Management Server in /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+ 2.
+ Run the script:
+ # ./cloud-setup-bonding.sh7.5.1.1.2. 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.
+ 7.5.1.2. 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 delay while the host is provisioned. It should automatically display in the UI.
+ •
+ Repeat for additional hosts.
+ Adding a Host (vSphere)7.5.2. Adding a Host (vSphere)
+ For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the entire cluster to CloudStack. See Add Cluster: vSphere.
+ Add Primary Storage7.6. Add Primary StorageSystem Requirements for Primary Storage7.6.1. System Requirements for Primary Storage
+ Hardware requirements:
+ •
+ Any standards-compliant iSCSI or NFS server that is supported by the underlying hypervisor.
+ •
+ The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller.
+ •
+ Minimum required capacity depends on your needs.
+
+ When setting up primary storage, follow these restrictions:
+ •
+ Primary storage cannot be added until a host has been added to the cluster.
+ •
+ If you do not provision shared primary storage, you must set the global configuration parameter system.vm.local.storage.required to true, or else you will not be able to start VMs.
+ Adding Primary Stroage7.6.2. Adding Primary Stroage
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+ Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+ 1.
+ Log in to the CloudStack UI (see Section 5.1, “Log In to the UI”).
+ 2.
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+ 3.
+ Click the Compute tab.
+ 4.
+ In the Primary Storage node of the diagram, click View All.
+ 5.
+ Click Add Primary Storage.
+ 6.
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+ •
+ Pod. The pod for the storage device.
+ •
+ Cluster. The cluster for the storage device.
+ •
+ Name. The name of the storage device.
+ •
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS.
+ •
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device.
+ •
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+ •
+ Path (for NFS). In NFS this is the exported path from the server.
+ •
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+ •
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+ •
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside CloudStack.
+ •
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
+ •
+ Lun # (for iSCSI). In iSCSI this is 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.
+ 7.
+ Click OK.
+ Add Secondary Storage7.7. Add Secondary StorageSystem Requirements for Secondary Storage7.7.1. System Requirements for Secondary Storage•
+ NFS storage appliance or Linux NFS server
+ •
+ (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org)
+ •
+ 100GB minimum capacity
+ •
+ A secondary storage device must be located in the same zone as the guest VMs it serves.
+ •
+ Each Secondary Storage server must be available to all hosts in the zone.
+ Adding Secondary Storage7.7.2. Adding Secondary Storage
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+ Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+ 1.
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to CloudStack before you add the local zone secondary storage servers. See Section 7.2, “Adding a Zone”.
+ 2.
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See Preparing NFS Shares in the Installation Guide.
+ 3.
+ Make sure you prepared the system VM template during Management Server installation. See Prepare the System VM Template in the Installation Guide.
+ 4.
+ Now that the secondary storage server for per-zone storage is prepared, add it to CloudStack. Secondary storage is added as part of the procedure for adding a new zone. See Section 7.2, “Adding a Zone”.
+ Initialize and Test7.8. Initialize and Test
+ After everything is configured, CloudStack will perform its initialization. This can take 30 minutes or more, depending on the speed of your network. When the initialization has completed successfully, the administrator's Dashboard should be displayed in the CloudStack UI.
+ 1.
+ Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS 5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do not proceed to the next step until this status is displayed.
+ 2.
+ Go to the Instances tab, and filter by My Instances.
+ 3.
+ Click Add Instance and follow the steps in the wizard.
+ a.
+ Choose the zone you just added.
+ b.
+ In the template selection, choose the template to use in the VM. If this is a fresh installation, likely only the provided CentOS template is available.
+ c.
+ Select a service offering. Be sure that the hardware you have allows starting the selected service offering.
+ d.
+ In data disk offering, if desired, add another data disk. This is a second volume that will be available to but not mounted in the guest. For example, in Linux on XenServer you will see /dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PV-enabled OS kernel in use.
+ e.
+ In default network, choose the primary network for the guest. In a trial installation, you would have only one option here.
+ f.
+ Optionally give your VM a name and a group. Use any descriptive text you would like.
+ g.
+ Click Launch VM. Your VM will be created and started. It might take some time to download the template and complete the VM startup. You can watch the VM’s progress in the Instances screen.
+ 4.
+ To use the VM, click the View Console button.
+
+
+
+ Congratulations! You have successfully completed a CloudStack Installation.
+
+ If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
+ Chapter 8.Chapter 8. Service OfferingsService Offerings
+ In this chapter we discuss compute, disk, and system service offerings. Network offerings are discussed in the section on setting up networking for users.
+ Compute and Disk Service Offerings8.1. Compute and Disk Service Offerings
+ A service offering is a set of virtual hardware features such as CPU core count and speed, memory, and disk size. The CloudStack administrator can set up various offerings, and then end users choose from the available offerings when they create a new VM. A service offering includes the following elements:
+ •
+ CPU, memory, and network resource guarantees
+ •
+ How resources are metered
+ •
+ How the resource usage is charged
+ •
+ How often the charges are generated
+
+ For example, one service offering might allow users to create a virtual machine instance that is equivalent to a 1 GHz Intel® Core™ 2 CPU, with 1 GB memory at $0.20/hour, with network traffic metered at $0.10/GB. Based on the user’s selected offering, CloudStack emits usage records that can be integrated with billing systems. CloudStack separates service offerings into compute offerings and disk offerings. The computing service offering specifies:
+ •
+ Guest CPU
+ •
+ Guest RAM
+ •
+ Guest Networking type (virtual or direct)
+ •
+ Tags on the root disk
+
+ The disk offering specifies:
+ •
+ Disk size (optional). An offering without a disk size will allow users to pick their own
+ •
+ Tags on the data disk
+ Creating a New Compute Offering8.1.1. Creating a New Compute Offering
+ To create a new compute offering:
+ 1.
+ Log in with admin privileges to the CloudStack UI.
+ 2.
+ In the left navigation bar, click Service Offerings.
+ 3.
+ In Select Offering, choose Compute Offering.
+ 4.
+ Click Add Compute Offering.
+ 5.
+ In the dialog, make the following choices:
+ •
+ Name: Any desired name for the service offering.
+ •
+ Description: A short description of the offering that can be displayed to users
+ •
+ Storage type: The type of disk that should be allocated. Local allocates from storage attached directly to the host where the system VM is running. Shared allocates from storage accessible via NFS.
+ •
+ # of CPU cores: The number of cores which should be allocated to a system VM with this offering
+ •
+ CPU (in MHz): The CPU speed of the cores that the system VM is allocated. For example, “2000” would provide for a 2 GHz clock.
+ •
+ Memory (in MB): The amount of memory in megabytes that the system VM should be allocated. For example, “2048” would provide for a 2 GB RAM allocation.
+ •
+ Network Rate: Allowed data transfer rate in MB per second.
+ •
+ Offer HA: If yes, the administrator can choose to have the system VM be monitored and as highly available as possible.
+ •
+ Storage Tags: The tags that should be associated with the primary storage used by the system VM.
+ •
+ Host Tags: (Optional) Any tags that you use to organize your hosts
+ •
+ CPU cap: Whether to limit the level of CPU usage even if spare capacity is available.
+ •
+ Public: Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+ 6.
+ Click Add.
+ Creating a New Disk Offering8.1.2. Creating a New Disk Offering
+ To create a system service offering:
+ 1.
+ Log in with admin privileges to the CloudStack UI.
+ 2.
+ In the left navigation bar, click Service Offerings.
+ 3.
+ In Select Offering, choose Disk Offering.
+ 4.
+ Click Add Disk Offering.
+ 5.
+ In the dialog, make the following choices:
+ •
+ Name. Any desired name for the system offering.
+ •
+ Description. A short description of the offering that can be displayed to users
+ •
+ Custom Disk Size. If checked, the user can set their own disk size. If not checked, the root administrator must define a value in Disk Size.
+ •
+ Disk Size. Appears only if Custom Disk Size is not selected. Define the volume size in GB.
+ •
+ (Optional)Storage Tags. The tags that should be associated with the primary storage for this disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue". Tags are also added on Primary Storage. CloudStack matches tags on a disk offering to tags on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation from the disk offering will fail..
+ •
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; CloudStack will then prompt for the subdomain's name.
+ 6.
+ Click Add.
+ Modifying or Deleting a Service Offering8.1.3. Modifying or Deleting a Service Offering
+ Service offerings cannot be changed once created. This applies to both compute offerings and disk offerings.
+
+ A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently. If the service offering is still in use, it will remain in the database until all the virtual machines referencing it have been deleted. After deletion by the administrator, a service offering will not be available to end users that are creating new instances.
+ System Service Offerings8.2. System Service Offerings
+ System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the CloudStack root administrator. CloudStack provides default system service offerings. The CloudStack root administrator can create additional custom system service offerings.
+
+ When CloudStack creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering.
+ Chapter 9.Chapter 9. Setting Up Networking for UsersSetting Up Networking for UsersOverview of Setting Up Networking for Users9.1. Overview of Setting Up Networking for Users
+ People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a CloudStack administrator, you can do the following things to set up networking for your users:
+ •
+ Set up physical networks in zones
+ •
+ Set up several different providers for the same service on a single physical network (for example, both Cisco and Juniper firewalls)
+ •
+ Bundle different types of network services into network offerings, so users can choose the desired network services for any given virtual machine
+ •
+ Add new network offerings as time goes on so end users can upgrade to a better class of service on their network
+ •
+ Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member
+ About Virtual Networks9.2. About Virtual Networks
+ A virtual network is a logical construct that enables multi-tenancy on a single physical network. In CloudStack a virtual network can be shared or isolated.
+ Isolated Networks9.2.1. Isolated Networks
+ An isolated network can be accessed only by virtual machines of a single account. Isolated networks have the following properties.
+ •
+ Resources such as VLAN are allocated and garbage collected dynamically
+ •
+ There is one network offering for the entire network
+ •
+ The network offering can be upgraded or downgraded but it is for the entire network
+ Shared Networks9.2.2. Shared Networks
+ A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in CloudStack 3.0.3).
+ •
+ Shared Networks are created by the administrator
+ •
+ Shared Networks can be designated to a certain domain
+ •
+ Shared Network resources such as VLAN and physical network that it maps to are designated by the administrator
+ •
+ Shared Networks are isolated by security groups
+ •
+ Public Network is a shared network that is not shown to the end users
+ Runtime Allocation of Virtual Network Resources9.2.3. Runtime Allocation of Virtual Network Resources
+ When you define a new virtual network, all your settings for that network are stored in CloudStack. The actual network resources are activated only when the first virtual machine starts in the network. When all virtual machines have left the virtual network, the network resources are garbage collected so they can be allocated again. This helps to conserve network resources..
+ Network Service Providers9.3. Network Service ProvidersNote
+ For the most up-to-date list of supported network service providers, see the CloudPlatform UI or call listNetworkServiceProviders.
+
+ A service provider (also called a network element) is hardware or virtual appliance that makes a network service possible; for example, a firewall appliance can be installed in the cloud to provide firewall service. On a single network, multiple providers can provide the same network service. For example, a firewall service may be provided by Cisco or Juniper devices in the same physical network.
+
+ You can have multiple instances of the same service provider in a network (say, more than one Juniper SRX device).
+
+ If different providers are set up to provide the same service on the network, the administrator can create network offerings so users can specify which network service provider they prefer (along with the other choices offered in network offerings). Otherwise, CloudPlatform will choose which provider to use whenever the service is called for.
+ Supported Network Service Providers
+ CloudPlatform ships with an internal list of the supported service providers, and you can choose from this list when creating a network offering.
+ Network Offerings9.4. Network OfferingsNote
+ For the most up-to-date list of supported network services, see the CloudPlatform UI or call listNetworkServices.
+
+ A network offering is a named set of network services, such as:
+ •
+ DHCP
+ •
+ DNS
+ •
+ Source NAT
+ •
+ Static NAT
+ •
+ Port Forwarding
+ •
+ Load Balancing
+ •
+ Firewall
+ •
+ VPN
+ •
+ Optional) Name one of several available providers to use for a given service, such as Juniper for the firewall
+ •
+ (Optional) Network tag to specify which physical network to use
+
+ When creating a new VM, the user chooses one of the available network offerings, and that determines which network services the VM can use.
+
+ The CloudPlatform administrator can create any number of custom network offerings, in addition to the default network offerings provided by CloudPlatform. By creating multiple custom network offerings, you can set up your cloud to offer different classes of service on a single multi-tenant physical network. For example, while the underlying physical wiring may be the same for two tenants, tenant A may only need simple firewall protection for their website, while tenant B may be running a web server farm and require a scalable firewall solution, load balancing solution, and alternate networks for accessing the database backend.
+ Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudPlatform virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+ When creating a new virtual network, the CloudPlatform administrator chooses which network offering to enable for that network. Each virtual network is associated with one network offering. A virtual network can be upgraded or downgraded by changing its associated network offering. If you do this, be sure to reprogram the physical network to match.
+
+ CloudPlatform also has internal network offerings for use by CloudPlatform system VMs. These network offerings are not visible to users but can be modified by administrators.
+ Chapter 10.Chapter 10. Working With Virtual MachinesWorking With Virtual MachinesAbout Working with Virtual Machines10.1. About Working with Virtual Machines
+ CloudStack provides administrators with complete control over the lifecycle of all guest VMs executing in the cloud. CloudStack provides several guest management operations for end users and administrators. VMs may be stopped, started, rebooted, and destroyed.
+
+ Guest VMs have a name and group. VM names and groups are opaque to CloudStack and are available for end users to organize their VMs. Each VM can have three names for use in different contexts. Only two of these names can be controlled by the user:
+ •
+ Instance name – a unique, immutable ID that is generated by CloudStack and can not be modified by the user. This name conforms to the requirements in IETF RFC 1123.
+ •
+ Display name – the name displayed in the CloudStack web UI. Can be set by the user. Defaults to instance name.
+ •
+ Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to instance name
+
+ Guest VMs can be configured to be Highly Available (HA). An HA-enabled VM is monitored by the system. If the system detects that the VM is down, it will attempt to restart the VM, possibly on a different host. For more information, see HA-Enabled Virtual Machines on
+
+ Each new VM is allocated one public IP address. When the VM is started, CloudStack automatically creates a static NAT between this public IP address and the private IP address of the VM.
+
+ If elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new VM is not marked as elastic. The user must replace the automatically configured IP with a specifically acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s private IP. The VM’s original IP address is then released and returned to the pool of available public IPs.
+
+ CloudStack cannot distinguish a guest VM that was shut down by the user (such as with the “shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut down from inside the VM, CloudStack will restart it. To shut down an HA-enabled VM, you must go through the CloudStack UI or API.
+ Best Practices for Virtual Machines10.2. Best Practices for Virtual Machines
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+ VM Lifecycle10.3. VM Lifecycle
+ Virtual machines can be in the following states:
+
+ Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual machine will be reclaimed by the system. This includes the virtual machine’s IP address.
+
+ A stop will attempt to gracefully shut down the operating system, which typically involves terminating all the running applications. If the operation system cannot be stopped, it will be forcefully terminated. This has the same effect as pulling the power cord to a physical machine.
+
+ A reboot is a stop followed by a start.
+
+ CloudPlatform preserves the state of the virtual machine hard disk until the machine is destroyed.
+
+ A running virtual machine may fail because of hardware or network issues. A failed virtual machine is in the down state.
+
+ The system places the virtual machine into the down state if it does not receive the heartbeat from the hypervisor for three minutes.
+
+ The user can manually restart the virtual machine from the down state.
+
+ The system will start the virtual machine from the down state automatically if the virtual machine is marked as HA-enabled.
+ Creating VMs10.4. Creating VMs
+ Virtual machines are usually created from a template. Users can also create blank virtual machines. A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and install the OS from the CD/DVD-ROM.
+
+ To create a VM from a template:
+ 1.
+ Log in to the CloudStack UI as an administrator or user.
+ 2.
+ In the left navigation bar, click Instances.
+ 3.
+ Click Add Instance.
+ 4.
+ Select a template, then follow the steps in the wizard. (For more information about how the templates came to be in this list, see Working with Templates.
+ 5.
+ Be sure that the hardware you have allows starting the selected service offering.
+ 6.
+ Click Submit and your VM will be created and started.
+ Note
+ For security reason, the internal name of the VM is visible only to the root admin.
+ Note
+ Starting with v3.0.3, you can create a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A new request parameter, startVM, is introduced in the deployVm API to support this feature. For more information, see the Developer's Guide
+
+ To create a VM from an ISO:
+ Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+ 1.
+ Log in to the CloudStack UI as an administrator or user.
+ 2.
+ In the left navigation bar, click Instances.
+ 3.
+ Click Add Instance.
+ 4.
+ Select ISO Boot, and follow the steps in the wizard.
+ 5.
+ Click Submit and your VM will be created and started.
+ Accessing VMs10.5. Accessing VMs
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
+ To access a VM through the CloudStack UI:
+ 1.
+ Log in to the CloudStack UI as a user or admin.
+ 2.
+ Click Instances, then click the name of a running VM.
+ 3.
+ Click the View Console button .
+
+ To access a VM directly over the network:
+ 1.
+ The VM must have some port open to incoming traffic. For example, in a basic zone, a new VM might be assigned to a security group which allows incoming traffic. This depends on what security group you picked when creating the VM. In other cases, you can open a port by setting up a port forwarding policy. See IP Forwarding and Firewalling.
+ 2.
+ If a port is open but you can not access the VM using ssh, it’s possible that ssh is not already enabled on the VM. This will depend on whether ssh is enabled in the template you picked when creating the VM. Access the VM through the CloudStack UI and enable ssh on the machine using the commands for the VM’s operating system.
+ 3.
+ If the network has an external firewall device, you will need to create a firewall rule to allow access. See IP Forwarding and Firewalling.
+ Stopping and Starting VMs10.6. Stopping and Starting VMs
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+ Changing the VM Name, OS, or Group10.7. Changing the VM Name, OS, or Group
+ After a VM is created, you can modify the display name, operating system, and the group it belongs to.
+
+ To access a VM through the CloudStack UI:
+ 1.
+ Log in to the CloudStack UI as a user or admin.
+ 2.
+ In the left navigation, click Instances.
+ 3.
+ Select the VM that you want to modify.
+ 4.
+ Click the Stop button to stop the VM
+
+
+ 5.
+ Click Edit
+
+ .
+ 6.
+ Make the desired changes to the following:
+ 7.
+ Display name: Enter a new display name if you want to change the name of the VM.
+ 8.
+ OS Type: Select the desired operating system.
+ 9.
+ Group: Enter the group name for the VM.
+ 10.
+ Click Apply.
+ Changing the Service Offering for a VM10.8. Changing the Service Offering for a VM
+ To upgrade or downgrade the level of compute resources available to a virtual machine, you can change the VM's compute offering.
+ 1.
+ Log in to the CloudStack UI as a user or admin.
+ 2.
+ In the left navigation, click Instances.
+ 3.
+ Choose the VM that you want to work with.
+ 4.
+ Click the Stop button to stop the VM
+
+
+ 5.
+ Click the Change Service button
+
+ . The Change service dialog box is displayed.
+ 6.
+ Select the offering you want.
+ 7.
+ Click OK.
+ Moving VMs Between Hosts (Manual Live Migration)10.9. Moving VMs Between Hosts (Manual Live Migration)
+ The CloudPlatform administrator can move a running VM from one host to another without interrupting service to users or going into maintenance mode. This is called manual live migration, and can be done under the following conditions:
+ •
+ The root administrator is logged in. Domain admins and users can not perform manual live migration of VMs.
+ •
+ The VM is running. Stopped VMs can not be live migrated.
+ •
+ The destination host must be in the same cluster as the original host.
+ •
+ The VM must not be using local disk storage.
+ •
+ The destination host must have enough available capacity. If not, the VM will remain in the "migrating" state until memory becomes available.
+
+ To manually live migrate a virtual machine
+ 1.
+ Log in to the CloudPlatform UI as a user or admin.
+ 2.
+ In the left navigation, click Instances.
+ 3.
+ Choose the VM that you want to migrate.
+ 4.
+ Click the Migrate Instance button
+
+
+ 5.
+ From the list of hosts, choose the one to which you want to move the VM.
+ 6.
+ Click OK.
+ Deleting VMs10.10. Deleting VMs
+ Users can delete their own virtual machines. A running virtual machine will be abruptly stopped before it is deleted. Administrators can delete any virtual machines.
+
+ To delete a virtual machine:
+ 1.
+ Log in to the CloudStack UI as a user or admin.
+ 2.
+ In the left navigation, click Instances.
+ 3.
+ Choose the VM that you want to delete.
+ 4.
+ Click the Destroy Instance button
+
+
+ Working with ISOs10.11. Working with ISOs
+ CloudStack supports ISOs and their attachment to guest VMs. An ISO is a read-only file that has an ISO/CD-ROM style file system. Users can upload their own ISOs and mount them on their guest VMs.
+
+ ISOs are uploaded based on a URL. HTTP is the supported protocol. Once the ISO is available via HTTP specify an upload URL such as http://my.web.server/filename.iso.
+
+ ISOs may be public or private, like templates.ISOs are not hypervisor-specific. That is, a guest on vSphere can mount the exact same image that a guest on KVM can mount.
+
+ ISO images may be stored in the system and made available with a privacy level similar to templates. ISO images are classified as either bootable or not bootable. A bootable ISO image is one that contains an OS image. CloudStack allows a user to boot a guest VM off of an ISO image. Users can also attach ISO images to guest VMs. For example, this enables installing PV drivers into Windows. ISO images are not hypervisor-specific.
+ Adding an ISO10.11.1. Adding an ISO
+ To make additional operating system or other software available for use with guest VMs, you can add an ISO. The ISO is typically thought of as an operating system image, but you can also add ISOs for other types of software, such as desktop applications that you want to be installed as part of a template.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation bar, click Templates.
+ 3.
+ In Select View, choose ISOs.
+ 4.
+ Click Add ISO.
+ 5.
+ In the Add ISO screen, provide the following:
+ •
+ Name: Short name for the ISO image. For example, CentOS 6.2 64-bit.
+ •
+ Description: Display test for the ISO image. For example, CentOS 6.2 64-bit.
+ •
+ URL: The URL that hosts the ISO image. The Management Server must be able to access this location via HTTP. If needed you can place the ISO image directly on the Management Server
+ •
+ Zone: Choose the zone where you want the ISO to be available, or All Zones to make it available throughout CloudStack.
+ •
+ Bootable: Whether or not a guest could boot off this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not bootable.
+ •
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+ •
+ If the operating system of your desired ISO image is listed, choose it.
+ •
+ If the OS Type of the ISO is not listed or if the ISO is not bootable, choose Other.
+ •
+ (XenServer only) If you want to boot from this ISO in PV mode, choose Other PV (32-bit) or Other PV (64-bit)
+ •
+ (KVM only) If you choose an OS that is PV-enabled, the VMs created from this ISO will have a SCSI (virtio) root disk. If the OS is not PV-enabled, the VMs will have an IDE root disk. The PV-enabled types are:
+
+
+ Fedora 13
+
+
+
+ Fedora 12
+
+
+
+ Fedora 11
+
+
+
+ Fedora 10
+
+
+
+ Fedora 9
+
+
+
+ Other PV
+
+
+
+ Debian GNU/Linux
+
+
+
+ CentOS 5.3
+
+
+
+ CentOS 5.4
+
+
+
+ CentOS 5.5
+
+
+
+ Red Hat Enterprise Linux 5.3
+
+
+
+ Red Hat Enterprise Linux 5.4
+
+
+
+ Red Hat Enterprise Linux 5.5
+
+
+
+ Red Hat Enterprise Linux 6
+
+
+ Note
+ It is not recommended to choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not work. In these cases, choose Other.
+ •
+ Extractable: Choose Yes if the ISO should be available for extraction.
+ •
+ Public: Choose Yes if this ISO should be available to other users.
+ •
+ Featured: Choose Yes if you would like this ISO to be more prominent for users to select. The ISO will appear in the Featured ISOs list. Only an administrator can make an ISO Featured.
+ 6.
+ Click OK.
+
+ The Management Server will download the ISO. Depending on the size of the ISO, this may take a long time. The ISO status column will display Ready once it has been successfully downloaded into secondary storage. Clicking Refresh updates the download percentage.
+ 7.
+ Important: Wait for the ISO to finish downloading. If you move on to the next task and try to use the ISO right away, it will appear to fail. The entire ISO must be available before CloudStack can work with it.
+ Attaching an ISO to a VM10.11.2. Attaching an ISO to a VM1.
+ In the left navigation, click Instances.
+ 2.
+ Choose the virtual machine you want to work with.
+ 3.
+ Click the Attach ISO button
+
+ 4.
+ In the Attach ISO dialog box, select the desired ISO.
+ 5.
+ Click OK
+ Chapter 11.Chapter 11. Working With HostsWorking With HostsAdding Hosts11.1. Adding Hosts
+ Additional hosts can be added at any time to provide more capacity for guest VMs. For requirements and instructions, see Section 7.5, “Adding a Host”.
+ Scheduled Maintenance and Maintenance Mode for Hosts11.2. 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.
+ Disabling and Enabling Zones, Pods, and Clusters11.3. 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:
+ 1.
+ Log in to the CloudStack UI as administrator
+ 2.
+ In the left navigation bar, click Infrastructure.
+ 3.
+ In Zones, click View More.
+ 4.
+ If you are disabling or enabling a zone, find the name of the zone in the list, and click the Enable/Disable button.
+
+
+ 5.
+ If you are disabling or enabling a pod or cluster, click the name of the zone that contains the pod or cluster.
+ 6.
+ Click the Compute tab.
+ 7.
+ In the Pods or Clusters node of the diagram, click View All.
+ 8.
+ Click the pod or cluster name in the list.
+ 9.
+ Click the Enable/Disable button.
+
+ Removing Hosts11.4. 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 Hosts11.4.1. 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:
+ 1.
+ Place the node in maintenance mode.
+
+ See Section 11.2, “Scheduled Maintenance and Maintenance Mode for Hosts”.
+ 2.
+ For KVM, stop the cloud-agent service.
+ 3.
+ 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 Hosts11.4.2. 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”. 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 Hosts11.5. 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 Hosts11.6. 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 Base11http://docs.cloudstack.org/Knowledge_Base/Possible_VM_corruption_if_XenServer_Hotfix_is_not_Applied/Highly_Recommended_Hotfixes_for_XenServer_5.6_SP2
+ Changing Host Password11.7. 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:
+ 1.
+ Identify all hosts in the cluster.
+ 2.
+ 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.
+ 3.
+ 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:
+ mysql> select id from cloud.host where name like '%h%';4.
+ This should return a single ID. Record the set of such IDs for these hosts.
+ 5.
+ 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".
+ mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;Host Allocation11.8. Host Allocation
+ The system automatically picks the most appropriate host to run each virtual machine. End users may specify the zone in which the virtual machine will be created. End users do not have control over which host will run the virtual machine instance.
+
+ CloudStack administrators can specify that certain hosts should have a preference for particular types of guest instances. For example, an administrator could state that a host should have a preference to run Windows guests. The default host allocator will attempt to place guests of that OS type on such hosts first. If no such host is available, the allocator will place the instance wherever there is sufficient physical capacity.
+
+ Both vertical and horizontal allocation is allowed. Vertical allocation consumes all the resources of a given host before allocating any guests on a second host. This reduces power consumption in the cloud. Horizontal allocation places a guest on each host in a round-robin fashion. This may yield better performance to the guests in some cases. CloudStack also allows an element of CPU over-provisioning as configured by the administrator. Over-provisioning allows the administrator to commit more CPU cycles to the allocated guests than are actually available from the hardware.
+
+ CloudStack also provides a pluggable interface for adding new allocators. These custom allocators can provide any policy the administrator desires.
+ VLAN Provisioning11.9. 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.
+ Chapter 12.Chapter 12. Working with TemplatesWorking with Templates
+ A template is a reusable configuration for virtual machines. When users launch VMs, they can choose from a list of templates in CloudStack.
+
+ Specifically, a template is a virtual disk image that includes one of a variety of operating systems, optional additional software such as office applications, and settings such as access control to determine who can use the template. Each template is associated with a particular type of hypervisor, which is specified when the template is added to CloudStack.
+
+ CloudStack ships with a default template. In order to present more choices to users, CloudStack administrators and users can create templates and add them to CloudStack.
+ Creating Templates: Overview12.1. Creating Templates: Overview
+ CloudStack ships with a default template for the CentOS operating system. There are a variety of ways to add more templates. Administrators and end users can add templates. The typical sequence of events is:
+ 1.
+ Launch a VM instance that has the operating system you want. Make any other desired configuration changes to the VM.
+ 2.
+ Stop the VM.
+ 3.
+ Convert the volume into a template.
+
+ There are other ways to add templates to CloudStack. For example, you can take a snapshot of the VM's volume and create a template from the snapshot, or import a VHD from another system into CloudStack
+
+ The various techniques for creating templates are described in the next few sections.
+ Requirements for Templates12.2. Requirements for Templates•
+ For XenServer, install PV drivers / Xen tools on each template that you create. This will enable live migration and clean guest shutdown.
+ •
+ For vSphere, install VMware Tools on each template that you create. This will enable console view to work properly.
+ Best Practices for Templates12.3. Best Practices for Templates
+ If you plan to use large templates (100 GB or larger), be sure you have a 10-gigabit network to support the large templates. A slower network can lead to timeouts and other errors when large templates are used.
+ The Default Template12.4. The Default Template
+ CloudStack includes a CentOS template. This template is downloaded by the Secondary Storage VM after the primary and secondary storage are configured. You can use this template in your production deployment or you can delete it and use custom templates.
+
+ The root password for the default template is "password".
+
+ A default template is provided for each of XenServer, KVM, and vSphere. The templates that are downloaded depend on the hypervisor type that is available in your cloud. Each template is approximately 2.5 GB physical size.
+
+ The default template includes the standard iptables rules, which will block most access to the template excluding ssh.
+ # iptables --list
+Chain INPUT (policy ACCEPT)
+target prot opt source destination
+RH-Firewall-1-INPUT all -- anywhere anywhere
+
+Chain FORWARD (policy ACCEPT)
+target prot opt source destination
+RH-Firewall-1-INPUT all -- anywhere anywhere
+
+Chain OUTPUT (policy ACCEPT)
+target prot opt source destination
+
+Chain RH-Firewall-1-INPUT (2 references)
+target prot opt source destination
+ACCEPT all -- anywhere anywhere
+ACCEPT icmp -- anywhere anywhere icmp any
+ACCEPT esp -- anywhere anywhere
+ACCEPT ah -- anywhere anywhere
+ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
+ACCEPT udp -- anywhere anywhere udp dpt:ipp
+ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
+ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
+ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
+REJECT all -- anywhere anywhere reject-with icmp-host-
+Private and Public Templates12.5. Private and Public Templates
+ When a user creates a template, it can be designated private or public.
+
+ Private templates are only available to the user who created them. By default, an uploaded template is private.
+
+ When a user marks a template as “public,” the template becomes available to all users in all accounts in the user's domain, as well as users in any other domains that have access to the Zone where the template is stored. This depends on whether the Zone, in turn, was defined as private or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any domain. If a public template is created in a private Zone, it is available only to users in the domain assigned to that Zone. If a public template is created in a public Zone, it is available to all users in all domains.
+ Creating a Template from an Existing Virtual Machine12.6. Creating a Template from an Existing Virtual Machine
+ Once you have at least one VM set up in the way you want, you can use it as the prototype for other VMs.
+ 1.
+ Create and start a virtual machine using any of the techniques given in Section 10.4, “Creating VMs”.
+ 2.
+ Make any desired configuration changes on the running VM, then click Stop.
+ 3.
+ Wait for the VM to stop. When the status shows Stopped, go to the next step.
+ 4.
+ Click Create Template and provide the following:
+ •
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+ •
+ OS Type. This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+ •
+ If the operating system of the stopped VM is listed, choose it.
+ •
+ If the OS type of the stopped VM is not listed, choose Other.
+ •
+ If you want to boot from this template in PV mode, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServere:
+ Note
+ Note: Generally you should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+ •
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”.
+ •
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates.
+ 5.
+ Click Add.
+
+ The new template will be visible in the Templates section when the template creation process has been completed. The template is then available when creating a new VM
+ Creating a Template from a Snapshot12.7. Creating a Template from a Snapshot
+ If you do not want to stop the VM in order to use the Create Template menu item (as described in Section 12.6, “Creating a Template from an Existing Virtual Machine”), you can create a template directly from any snapshot through the CloudStack UI.
+ Uploading Templates12.8. Uploading TemplatesvSphere Templates and ISOs
+ If you are uploading a template that was created using vSphere Client, be sure the OVA file does not contain an ISO. If it does, the deployment of VMs from the template will fail.
+
+ Templates are uploaded based on a URL. HTTP is the supported access protocol. Templates are frequently large files. You can optionally gzip them to decrease upload times.
+
+ To upload a template:
+ 1.
+ In the left navigation bar, click Templates.
+ 2.
+ Click Create Template.
+ 3.
+ Provide the following:
+ •
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+ •
+ URL. The Management Server will download the file from the specified URL, such as http://my.web.server/filename.vhd.gz.
+ •
+ Zone. Choose the zone where you want the template to be available, or All Zones to make it available throughout CloudStack.
+ •
+ OS Type: This helps CloudStack and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following:
+ •
+ If the operating system of the stopped VM is listed, choose it.
+ •
+ If the OS type of the stopped VM is not listed, choose Other.
+ Note
+ You should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+ •
+ Hypervisor
+ •
+ Format. The format of the template upload file, such as VHD or OVA.
+ •
+ Password Enabled. Choose Yes if your template has the CloudStack password change script installed. See Adding Password Management to Your Templates
+ •
+ Extractable. Choose Yes if the template is available for extraction. If this option is selected, end users can download a full image of a template.
+ •
+ Public. Choose Yes to make this template accessible to all users of this CloudStack installation. The template will appear in the Community Templates list. See Section 12.5, “Private and Public Templates”
+ •
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. The template will appear in the Featured Templates list. Only an administrator can make a template Featured.
+ Exporting Templates12.9. Exporting Templates
+ End users and Administrators may export templates from the CloudStack. Navigate to the template in the UI and choose the Download function from the Actions menu.
+ Creating a Windows Template12.10. Creating a Windows Template
+ Windows templates must be prepared with Sysprep before they can be provisioned on multiple machines. Sysprep allows you to create a generic Windows template and avoid any possible SID conflicts.
+ Note
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ An overview of the procedure is as follows:
+ 1.
+ Upload your Windows ISO.
+
+ For more information, see Section 10.11.1, “Adding an ISO”
+ 2.
+ Create a VM Instance with this ISO.
+
+ For more information, see Section 10.4, “Creating VMs”
+ 3.
+ Follow the steps in Sysprep for Windows Server 2008 R2 (below) or Sysprep for Windows Server 2003 R2, depending on your version of Windows Server
+ 4.
+ The preparation steps are complete. Now you can actually create the template as described in Creating the Windows Template.
+ System Preparation for Windows Server 2008 R212.10.1. System Preparation for Windows Server 2008 R2
+ For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location:
+
+ http://www.microsoft.com/en-us/download/details.aspx?id=9085Microsoft Download Center.
+
+ Use the following steps to run sysprep for Windows 2008 R2:
+ Note
+ The steps outlined here are derived from the excellent guide by Charity Shelbourne, originally published at http://blogs.technet.com/askcore/archive/2008/10/31/automating-the-oobe-process-during-windows-server-2008-sysprep-mini-setup.aspxWindows Server 2008 Sysprep Mini-Setup
+ 1.
+ Download and install the Windows AIK
+ Note
+ Windows AIK should not be installed on the Windows 2008 R2 VM you just created. Windows AIK should not be part of the template you create. It is only used to create the sysprep answer file.
+ 2.
+ Copy the install.wim file in the \sources directory of the Windows 2008 R2 installation DVD to the hard disk. This is a very large file and may take a long time to copy. Windows AIK requires the WIM file to be writable.
+ 3.
+ Start the Windows System Image Manager, which is part of the Windows AIK.
+ 4.
+ In the Windows Image pane, right click “Select a Windows image or catalog file” to load the install.wim file you just copied.
+ 5.
+ Select the Windows 2008 R2 Edition
+
+ You may be prompted with a warning that the catalog file cannot be opened. Click Yes to create a new catalog file.
+ 6.
+ In the Answer File pane, right click to create a new answer file.
+ 7.
+ Generate the answer file from the Windows System Image Manager using the following steps:
+ a.
+ The first page you need to automate is the Language and Country or Region Selection page. To automate this, expand Components in your Windows Image pane, right-click and add the Microsoft-Windows-International-Core setting to Pass 7 oobeSystem. In your Answer File pane, configure the InputLocale, SystemLocale, UILanguage, and UserLocale with the appropriate settings for your language and country or region. Should you have a question about any of these settings, you can right-click on the specific setting and select Help. This will open the appropriate CHM help file with more information, including examples on the setting you are attempting to configure.
+ b.
+ You need to automate the Software License Terms Selection page, otherwise known as the End-User License Agreement (EULA). To do this, expand the Microsoft-Windows-Shell-Setup component. High-light the OOBE setting, and add the setting to the Pass 7 oobeSystem. In Settings, set HideEULAPage true.
+ c.
+ Make sure the license key is properly set. If you use MAK key, you can just enter the MAK key on the Windows 2008 R2 VM. You need not input the MAK into the Windows System Image Manager. If you use KMS host for activation you need not enter the Product Key. Details of Windows Volume Activation can be found at http://technet.microsoft.com/en-us/library/bb892849.aspx
+ d.
+ You need to automate is the Change Administrator Password page. Expand the Microsoft-Windows-Shell-Setup component (if it is not still expanded), expand UserAccounts, right-click on AdministratorPassword, and add the setting to the Pass 7 oobeSystem configuration pass of your answer file. Under Settings, specify a password next to Value.
+
+ You may read the AIK documentation and set many more options that suit your deployment. The steps above are the minimum needed to make Windows unattended setup work.
+ 8.
+ Save the answer file as unattend.xml. You can ignore the warning messages that appear in the validation window.
+ 9.
+ Copy the unattend.xml file into the c:\windows\system32\sysprep directory of the Windows 2008 R2 Virtual Machine
+ 10.
+ Once you place the unattend.xml file in c:\windows\system32\sysprep directory, you run the sysprep tool as follows:
+ cd c:\Windows\System32\sysprep
+sysprep.exe /oobe /generalize /shutdown
+
+ The Windows 2008 R2 VM will automatically shut down after sysprep is complete.
+ Sysprep for Windows Server 2003 R212.10.2. Sysprep for Windows Server 2003 R2
+ Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2.
+ 1.
+ Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM.
+ 2.
+ Run c:\sysprep\setupmgr.exe to create the sysprep.inf file.
+ a.
+ Select Create New to create a new Answer File.
+ b.
+ Enter “Sysprep setup” for the Type of Setup.
+ c.
+ Select the appropriate OS version and edition.
+ d.
+ On the License Agreement screen, select “Yes fully automate the installation”.
+ e.
+ Provide your name and organization.
+ f.
+ Leave display settings at default.
+ g.
+ Set the appropriate time zone.
+ h.
+ Provide your product key.
+ i.
+ Select an appropriate license mode for your deployment
+ j.
+ Select “Automatically generate computer name”.
+ k.
+ Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up.
+ l.
+ Leave Network Components at “Typical Settings”.
+ m.
+ Select the “WORKGROUP” option.
+ n.
+ Leave Telephony options at default.
+ o.
+ Select appropriate Regional Settings.
+ p.
+ Select appropriate language settings.
+ q.
+ Do not install printers.
+ r.
+ Do not specify “Run Once commands”.
+ s.
+ You need not specify an identification string.
+ t.
+ Save the Answer File as c:\sysprep\sysprep.inf.
+ 3.
+ Run the following command to sysprep the image:
+ c:\sysprep\sysprep.exe -reseal -mini -activated
+ After this step the machine will automatically shut down
+ Importing Amazon Machine Images12.11. Importing Amazon Machine Images
+ The following procedures describe how to import an Amazon Machine Image (AMI) into CloudStack when using the XenServer hypervisor.
+
+ Assume you have an AMI file and this file is called CentOS_6.2_x64. Assume further that you are working on a CentOS host. If the AMI is a Fedora image, you need to be working on a Fedora host initially.
+
+ You need to have a XenServer host with a file-based storage repository (either a local ext3 SR or an NFS SR) to convert to a VHD once the image file has been customized on the Centos/Fedora host.
+ 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.
+ 1.
+ Set up loopback on image file:
+ # mkdir -p /mnt/loop/centos62
+# mount -o loop CentOS_6.2_x64 /mnt/loop/centos54
+2.
+ Install the kernel-xen package into the image. This downloads the PV kernel and ramdisk to the image.
+ # yum -c /mnt/loop/centos54/etc/yum.conf --installroot=/mnt/loop/centos62/ -y install kernel-xen3.
+ Create a grub entry in /boot/grub/grub.conf.
+ # mkdir -p /mnt/loop/centos62/boot/grub
+# touch /mnt/loop/centos62/boot/grub/grub.conf
+# echo "" > /mnt/loop/centos62/boot/grub/grub.conf
+4.
+ Determine the name of the PV kernel that has been installed into the image.
+ # cd /mnt/loop/centos62
+# ls lib/modules/
+2.6.16.33-xenU 2.6.16-xenU 2.6.18-164.15.1.el5xen 2.6.18-164.6.1.el5.centos.plus 2.6.18-xenU-ec2-v1.0 2.6.21.7-2.fc8xen 2.6.31-302-ec2
+# ls boot/initrd*
+boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
+# ls boot/vmlinuz*
+boot/vmlinuz-2.6.18-164.15.1.el5xen boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus boot/vmlinuz-2.6.18-xenU-ec2-v1.0 boot/vmlinuz-2.6.21-2952.fc8xen
+
+ Xen kernels/ramdisk always end with "xen". For the kernel version you choose, there has to be an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.
+ 5.
+ Based on your findings, create an entry in the grub.conf file. Below is an example entry.
+ default=0
+timeout=5
+hiddenmenu
+title CentOS (2.6.18-164.15.1.el5xen)
+ root (hd0,0)
+ kernel /boot/vmlinuz-2.6.18-164.15.1.el5xen ro root=/dev/xvda
+ initrd /boot/initrd-2.6.18-164.15.1.el5xen.img
+6.
+ Edit etc/fstab, changing “sda1” to “xvda” and changing “sdb” to “xvdb”.
+ # cat etc/fstab
+/dev/xvda / ext3 defaults 1 1
+/dev/xvdb /mnt ext3 defaults 0 0
+none /dev/pts devpts gid=5,mode=620 0 0
+none /proc proc defaults 0 0
+none /sys sysfs defaults 0 0
+7.
+ Enable login via the console. The default console device in a XenServer system is xvc0. Ensure that etc/inittab and etc/securetty have the following lines respectively:
+ # grep xvc0 etc/inittab
+co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
+# grep xvc0 etc/securetty
+xvc0
+8.
+ Ensure the ramdisk supports PV disk and PV network. Customize this for the kernel version you have determined above.
+ # chroot /mnt/loop/centos54
+# cd /boot/
+# mv initrd-2.6.18-164.15.1.el5xen.img initrd-2.6.18-164.15.1.el5xen.img.bak
+# mkinitrd -f /boot/initrd-2.6.18-164.15.1.el5xen.img --with=xennet --preload=xenblk --omit-scsi-modules 2.6.18-164.15.1.el5xen
+9.
+ Change the password.
+ # passwd
+Changing password for user root.
+New UNIX password:
+Retype new UNIX password:
+passwd: all authentication tokens updated successfully.
+10.
+ Exit out of chroot.
+ # exit11.
+ Check etc/ssh/sshd_config for lines allowing ssh login using a password.
+ # egrep "PermitRootLogin|PasswordAuthentication" /mnt/loop/centos54/etc/ssh/sshd_config
+PermitRootLogin yes
+PasswordAuthentication yes
+12.
+ If you need the template to be enabled to reset passwords from the CloudStack UI or API, install the password change script into the image at this point. See Section 12.13, “Adding Password Management to Your Templates”.
+ 13.
+ Unmount and delete loopback mount.
+ # umount /mnt/loop/centos54
+# losetup -d /dev/loop0
+14.
+ Copy the image file to your XenServer host's file-based storage repository. In the example below, the Xenserver is "xenhost". This XenServer has an NFS repository whose uuid is a9c5b8c8-536b-a193-a6dc-51af3e5ff799.
+ # scp CentOS_6.2_x64 xenhost:/var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799/15.
+ Log in to the Xenserver and create a VDI the same size as the image.
+ [root@xenhost ~]# cd /var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# ls -lh CentOS_6.2_x64
+-rw-r--r-- 1 root root 10G Mar 16 16:49 CentOS_6.2_x64
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-create virtual-size=10GiB sr-uuid=a9c5b8c8-536b-a193-a6dc-51af3e5ff799 type=user name-label="Centos 6.2 x86_64"
+cad7317c-258b-4ef7-b207-cdf0283a7923
+16.
+ Import the image file into the VDI. This may take 10–20 minutes.
+ [root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-import filename=CentOS_6.2_x64 uuid=cad7317c-258b-4ef7-b207-cdf0283a792317.
+ Locate a the VHD file. This is the file with the VDI’s UUID as its name. Compress it and upload it to your web server.
+ [root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# bzip2 -c cad7317c-258b-4ef7-b207-cdf0283a7923.vhd > CentOS_6.2_x64.vhd.bz2
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# scp CentOS_6.2_x64.vhd.bz2 webserver:/var/www/html/templates/
+Converting a Hyper-V VM to a Template12.12. Converting a Hyper-V VM to a Template
+ To convert a Hyper-V VM to a XenServer-compatible CloudStack template, you will need a standalone XenServer host with an attached NFS VHD SR. Use whatever XenServer version you are using with CloudStack, but use XenCenter 5.6 FP1 or SP2 (it is backwards compatible to 5.6). Additionally, it may help to have an attached NFS ISO SR.
+
+ For Linux VMs, you may need to do some preparation in Hyper-V before trying to get the VM to work in XenServer. Clone the VM and work on the clone if you still want to use the VM in Hyper-V. Uninstall Hyper-V Integration Components and check for any references to device names in /etc/fstab:
+ 1.
+ From the linux_ic/drivers/dist directory, run make uninstall (where "linux_ic" is the path to the copied Hyper-V Integration Components files).
+ 2.
+ Restore the original initrd from backup in /boot/ (the backup is named *.backup0).
+ 3.
+ Remove the "hdX=noprobe" entries from /boot/grub/menu.lst.
+ 4.
+ Check /etc/fstab for any partitions mounted by device name. Change those entries (if any) to mount by LABEL or UUID (get that information with the "blkid" command)..
+
+ The next step is make sure the VM is not running in Hyper-V, then get the VHD into XenServer. There are two options for doing this.
+
+ Option one:
+ 1.
+ Import the VHD using XenCenter. In XenCenter, go to Tools>Virtual Appliance Tools>Disk Image Import.
+ 2.
+ Choose the VHD, then click Next.
+ 3.
+ Name the VM, choose the NFS VHD SR under Storage, enable "Run Operating System Fixups" and choose the NFS ISO SR.
+ 4.
+ Click Next, then Finish. A VM should be created.
+
+ Option two
+ 1.
+ Run XenConvert, under From choose VHD, under To choose XenServer. Click Next.
+ 2.
+ Choose the VHD, then click Next.
+ 3.
+ Input the XenServer host info, then click Next.
+ 4.
+ Name the VM, then click Next, then Convert. A VM should be created
+
+ Once you have a VM created from the Hyper-V VHD, prepare it using the following steps:
+ 1.
+ Boot the VM, uninstall Hyper-V Integration Services, and reboot.
+ 2.
+ Install XenServer Tools, then reboot.
+ 3.
+ Prepare the VM as desired. For example, run sysprep on Windows VMs. See Section 12.10, “Creating a Windows Template”
+
+ Either option above will create a VM in HVM mode. This is fine for Windows VMs, but Linux VMs may not perform optimally. Converting a Linux VM to PV mode will require additional steps and will vary by distribution.
+ 1.
+ Shut down the VM and copy the VHD from the NFS storage to a web server; for example, mount the NFS share on the web server and copy it, or from the XenServer host use sftp or scp to upload it to the web server.
+ 2.
+ In CloudStack, create a new template using the following values:
+ •
+ URL. Give the URL for the VHD
+ •
+ OS Type. Use the appropriate OS. For PV mode on CentOS, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServer.
+ •
+ Hypervisor. XenServer
+ •
+ Format. VHD
+
+ The template will be created, and you can create instances from it.
+ Adding Password Management to Your Templates12.13. Adding Password Management to Your Templates
+ CloudStack provides an optional password reset feature that allows users to set a temporary admin or root password as well as reset the existing admin or root password from the CloudStack UI.
+
+ To enable the Reset Password feature, you will need to download an additional script to patch your template. When you later upload the template into CloudStack, you can specify whether reset admin/root password feature should be enabled for this template.
+
+ The password management feature works always resets the account password on instance boot. The script does an HTTP call to the virtual router to retrieve the account password that should be set. As long as the virtual router is accessible the guest will have access to the account password that should be used. When the user requests a password reset the management server generates and sends a new password to the virtual router for the account. Thus an instance reboot is necessary to effect any password changes.
+
+ If the script is unable to contact the virtual router during instance boot it will not set the password but boot will continue normally.
+ Linux OS Installation12.13.1. Linux OS Installation
+ Use the following steps to begin the Linux OS installation:
+ 1.
+ Download the script file cloud-set-guest-password:
+ •
+ Linux: http://cloudstack.org/dl/cloud-set-guest-password
+ •
+ Windows: http://sourceforge.net/projects/cloudstack/files/Password%20Management%20Scripts/CloudInstanceManager.msi/download
+ 2.
+ Copy this file to /etc/init.d.
+
+ On some Linux distributions, copy the file to /etc/rc.d/init.d.
+ 3.
+ Run the following command to make the script executable:
+ chmod +x /etc/init.d/cloud-set-guest-password4.
+ Depending on the Linux distribution, continue with the appropriate step.
+
+ On Fedora, CentOS/RHEL, and Debian, run:
+ chkconfig --add cloud-set-guest-passwordWindows OS Installation12.13.2. Windows OS Installation
+ Download the installer, CloudInstanceManager.msi, from Download page11http://cloudstack.org/download.html and run the installer in the newly created Windows VM.
+ Deleting Templates12.14. Deleting Templates
+ Templates may be deleted. In general, when a template spans multiple Zones, only the copy that is selected for deletion will be deleted; the same template in other Zones will not be deleted. The provided CentOS template is an exception to this. If the provided CentOS template is deleted, it will be deleted from all Zones.
+
+ When templates are deleted, the VMs instantiated from them will continue to run. However, new VMs cannot be created based on the deleted template.
+ Chapter 13.Chapter 13. Working With StorageWorking With StorageStorage Overview13.1. Storage Overview
+ CloudStack defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS.
+
+ There is no ephemeral storage in CloudStack. All volumes on all nodes are persistent.
+ Primary Storage13.2. Primary Storage
+ This section gives concepts and technical details about CloudPlatform primary storage. For information about how to install and configure primary storage through the CloudPlatform UI, see the Advanced Installation Guide.
+ Best Practices for Primary Storage13.2.1. Best Practices for Primary Storage•
+ The speed of primary storage will impact guest performance. If possible, choose smaller, higher RPM drives for primary storage.
+ •
+ Ensure that nothing is stored on the server. Adding the server to CloudPlatform will destroy any existing data
+ Runtime Behavior of Primary Storage13.2.2. Runtime Behavior of Primary Storage
+ Root volumes are created automatically when a virtual machine is created. Root volumes are deleted when the VM is destroyed. Data volumes can be created and dynamically attached to VMs. Data volumes are not deleted when VMs are destroyed.
+
+ Administrators should monitor the capacity of primary storage devices and add additional primary storage as needed. See the Advanced Installation Guide.
+
+ Administrators add primary storage to the system by creating a CloudStack storage pool. Each storage pool is associated with a cluster.
+ Hypervisor Support for Primary Storage13.2.3. Hypervisor Support for Primary Storage
+ The following table shows storage options and parameters for different hypervisors.
+
+
+
+ VMware vSphere
+
+
+
+ Citrix XenServer
+
+
+
+ KVM
+
+
+
+ Format for Disks, Templates, and Snapshots
+
+
+
+ VMDK
+
+
+
+ VHD
+
+
+
+ QCOW2
+
+
+
+ iSCSI support
+
+
+
+ VMFS
+
+
+
+ Clustered LVM
+
+
+
+ Yes, via Shared Mountpoint
+
+
+
+ Fiber Channel support
+
+
+
+ VMFS
+
+
+
+ Yes, via Existing SR
+
+
+
+ Yes, via Shared Mountpoint
+
+
+
+ NFS support
+
+
+
+ Y
+
+
+
+ Y
+
+
+
+ Y
+
+
+
+ Local storage support
+
+
+
+ Y
+
+
+
+ Y
+
+
+
+ Y
+
+
+
+ Storage over-provisioning
+
+
+
+ NFS and iSCSI
+
+
+
+ NFS
+
+
+
+ NFS
+
+
+ XenServer uses a clustered LVM system to store VM images on iSCSI and Fiber Channel volumes and does not support over-provisioning in the hypervisor. The storage server itself, however, can support thin-provisioning. As a result the CloudStack can still support storage over-provisioning by running on thin-provisioned storage volumes.
+
+ KVM supports "Shared Mountpoint" storage. A shared mountpoint is a file system path local to each server in a given cluster. The path must be the same across all Hosts in the cluster, for example /mnt/primary1. This shared mountpoint is assumed to be a clustered filesystem such as OCFS2. In this case the CloudStack does not attempt to mount or unmount the storage as is done with NFS. The CloudStack requires that the administrator insure that the storage is available
+
+ With NFS storage, CloudStack manages the overprovisioning. In this case the global configuration parameter storage.overprovisioning.factor controls the degree of overprovisioning. This is independent of hypervisor type.
+
+ Local storage is an option for primary storage for vSphere, XenServer, and KVM. When the local disk option is enabled, a local disk storage pool is automatically created on each host. To use local storage for the System Virtual Machines (such as the Virtual Router), set system.vm.use.local.storage to true in global configuration.
+
+ CloudStack supports multiple primary storage pools in a Cluster. For example, you could provision 2 NFS servers in primary storage. Or you could provision 1 iSCSI LUN initially and then add a second iSCSI LUN when the first approaches capacity.
+ Storage Tags13.2.4. Storage Tags
+ Storage may be "tagged". A tag is a text string attribute associated with primary storage, a Disk Offering, or a Service Offering. Tags allow administrators to provide additional information about the storage. For example, that is a "SSD" or it is "slow". Tags are not interpreted by CloudStack. They are matched against tags placed on service and disk offerings. CloudStack requires all tags on service and disk offerings to exist on the primary storage before it allocates root or data disks on the primary storage. Service and disk offering tags are used to identify the requirements of the storage that those offerings have. For example, the high end service offering may require "fast" for its root disk volume.
+
+ The interaction between tags, allocation, and volume copying across clusters and pods can be complex. To simplify the situation, use the same set of tags on the primary storage for all clusters in a pod. Even if different devices are used to present those tags, the set of exposed tags can be the same.
+ Maintenance Mode for Primary Storage13.2.5. Maintenance Mode for Primary Storage
+ Primary storage may be placed into maintenance mode. This is useful, for example, to replace faulty RAM in a storage device. Maintenance mode for a storage device will first stop any new guests from being provisioned on the storage device. Then it will stop all guests that have any volume on that storage device. When all such guests are stopped the storage device is in maintenance mode and may be shut down. When the storage device is online again you may cancel maintenance mode for the device. The CloudStack will bring the device back online and attempt to start all guests that were running at the time of the entry into maintenance mode.
+ Secondary Storage13.3. Secondary Storage
+ This section gives concepts and technical details about CloudStack secondary storage. For information about how to install and configure secondary storage through the CloudStack UI, see the Advanced Installation Guide.
+ Using Swift for Secondary Storage13.4. Using Swift for Secondary Storage
+ A volume provides storage to a guest VM. The volume can provide for a root disk or an additional data disk. CloudStack supports additional volumes for guest VMs.
+
+ Volumes are created for a specific hypervisor type. A volume that has been attached to guest using one hypervisor type (e.g, XenServer) may not be attached to a guest that is using another hypervisor type (e.g. vSphere, KVM). This is because the different hypervisors use different disk image formats.
+
+ CloudStack defines a volume as a unit of storage available to a guest VM. Volumes are either root disks or data disks. The root disk has "/" in the file system and is usually the boot device. Data disks provide for additional storage (e.g. As "/opt" or "D:"). Every guest VM has a root disk, and VMs can also optionally have a data disk. End users can mount multiple data disks to guest VMs. Users choose data disks from the disk offerings created by administrators. The user can create a template from a volume as well; this is the standard procedure for private template creation. Volumes are hypervisor-specific: a volume from one hypervisor type may not be used on a guest of another hypervisor type.
+ Working with Snapshots13.5. Working with Snapshots
+ (Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)
+
+ CloudStack supports snapshots of disk volumes. Snapshots are a point-in-time capture of virtual machine disks. Memory and CPU states are not captured.
+
+ Snapshots may be taken for volumes, including both root and data disks. The administrator places a limit on the number of stored snapshots per user. Users can create new volumes from the snapshot for recovery of particular files and they can create templates from snapshots to boot from a restored disk.
+
+ Users can create snapshots manually or by setting up automatic recurring snapshot policies. Users can also create disk volumes from snapshots, which may be attached to a VM like any other disk volume. Snapshots of both root disks and data disks are supported. However, CloudStack does not currently support booting a VM from a recovered root disk. A disk recovered from snapshot of a root disk is treated as a regular data disk; the data on recovered disk can be accessed by attaching the disk to a VM.
+
+ A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot.
+ Chapter 14.Chapter 14. Working with UsageWorking with Usage
+ The Usage Server is an optional, separately-installed part of CloudStack that provides aggregated usage records which you can use to create billing integration for CloudStack. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances.
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day.
+ Configuring the Usage Server14.1. Configuring the Usage Server
+ To configure the usage server:
+ 1.
+ Be sure the Usage Server has been installed. This requires extra steps beyond just installing the CloudStack software. See Installing the Usage Server (Optional) in the Advanced Installation Guide.
+ 2.
+ Log in to the CloudStack UI as administrator.
+ 3.
+ Click Global Settings.
+ 4.
+ In Search, type usage. Find the configuration parameter that controls the behavior you want to set. See the table below for a description of the available parameters.
+ 5.
+ In Actions, click the Edit icon.
+ 6.
+ Type the desired value and click the Save icon.
+ 7.
+ Restart the Management Server (as usual with any global configuration change) and also the Usage Server:
+ # service cloud-management restart
+# service cloud-usage restart
+
+ The following table shows the global configuration settings that control the behavior of the Usage Server.
+
+
+ Parameter Name
+
+
+
+ Description
+
+
+
+ enable.usage.server
+
+
+
+ Whether the Usage Server is active.
+
+
+
+ usage.aggregation.timezone
+
+
+
+ Time zone of usage records. Set this if the usage records and daily job execution are in different time zones. For example, with the following settings, the usage job will run at PST 00:15 and generate usage records for the 24 hours from 00:00:00 GMT to 23:59:59 GMT:
+
+
+usage.stats.job.exec.time = 00:15
+usage.execution.timezone = PST
+usage.aggregation.timezone = GMT
+
+
+ Valid values for the time zone are specified in Appendix A, Time Zones
+
+
+ Default: GMT
+
+
+
+
+ usage.execution.timezone
+
+
+
+ The time zone of usage.stats.job.exec.time. Valid values for the time zone are specified in Appendix A, Time Zones
+
+
+ Default: The time zone of the management server.
+
+
+
+
+ usage.sanity.check.interval
+
+
+
+ The number of days between sanity checks. Set this in order to periodically search for records with erroneous data before issuing customer invoices. For example, this checks for VM usage records created after the VM was destroyed, and similar checks for templates, volumes, and so on. It also checks for usage times longer than the aggregation range. If any issue is found, the alert ALERT_TYPE_USAGE_SANITY_RESULT = 21 is sent.
+
+
+
+ usage.stats.job.aggregation.range
+
+
+
+ The time period in minutes between Usage Server processing jobs. For example, if you set it to 1440, the Usage Server will run once per day. If you set it to 600, it will run every ten hours. In general, when a Usage Server job runs, it processes all events generated since usage was last run.
+
+
+ There is special handling for the case of 1440 (once per day). In this case the Usage Server does not necessarily process all records since Usage was last run. CloudStack assumes that you require processing once per day for the previous, complete day’s records. For example, if the current day is October 7, then it is assumed you would like to process records for October 6, from midnight to midnight. CloudStack assumes this "midnight to midnight" is relative to the usage.execution.timezone.
+
+
+ Default: 1440
+
+
+
+
+ usage.stats.job.exec.time
+
+
+
+ The time when the Usage Server processing will start. It is specified in 24-hour format (HH:MM) in the time zone of the server, which should be GMT. For example, to start the Usage job at 10:30 GMT, enter "10:30".
+
+
+ If usage.stats.job.aggregation.range is also set, and its value is not 1440, then its value will be added to usage.stats.job.exec.time to get the time to run the Usage Server job again. This is repeated until 24 hours have elapsed, and the next day's processing begins again at usage.stats.job.exec.time.
+
+
+ Default: 00:15.
+
+
+
+ For example, suppose that your server is in GMT, your user population is predominantly in the East Coast of the United States, and you would like to process usage records every night at 2 AM local (EST) time. Choose these settings:
+ •
+ enable.usage.server = true
+ •
+ usage.execution.timezone = America/New_York
+ •
+ usage.stats.job.exec.time = 07:00. This will run the Usage job at 2:00 AM EST. Note that this will shift by an hour as the East Coast of the U.S. enters and exits Daylight Savings Time.
+ •
+ usage.stats.job.aggregation.range = 1440
+
+ With this configuration, the Usage job will run every night at 2 AM EST and will process records for the previous day’s midnight-midnight as defined by the EST (America/New_York) time zone.
+ Note
+ Because the special value 1440 has been used for usage.stats.job.aggregation.range, the Usage Server will ignore the data between midnight and 2 AM. That data will be included in the next day's run
+ Setting Usage Limits14.2. Setting Usage Limits
+ CloudStack provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis.
+
+ Aggregate limits may be set on a per-domain basis. For example, you may limit a domain and all subdomains to the creation of 100 VMs.
+
+ This section covers the following topics:
+
+ Section 14.3, “Globally Configured Limits”Globally Configured Limits
+
+ Section 14.4, “Default Account Resource Limits”Default Account Resource Limits
+
+ Section 14.5, “Per-Domain Limits”Per Domain Limits
+ Globally Configured Limits14.3. Globally Configured Limits
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+
+ The following table lists limits set in the Global Configuration:
+
+
+ Parameter Name
+
+
+
+ Definition
+
+
+
+ max.account.public.ips
+
+
+
+ Number of public IP addresses that can be owned by an account
+
+
+
+ max.account.snapshots
+
+
+
+ Number of snapshots that can exist for an account
+
+
+
+ max.account.templates
+
+
+
+ Number of templates that can exist for an account
+
+
+
+ max.account.user.vms
+
+
+
+ Number of virtual machine instances that can exist for an account
+
+
+
+ max.account.volumes
+
+
+
+ Number of disk volumes that can exist for an account
+
+
+
+ max.template.iso.size
+
+
+
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+ max.volume.size.gb
+
+
+
+ Maximum size for a volume in GB
+
+
+
+ network.throttling.rate
+
+
+
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+
+ snapshot.max.hourly
+
+
+
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+ snapshot.max.daily
+
+
+
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+
+ snapshot.max.weekly
+
+
+
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+ snapshot.max.monthly
+
+
+
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+ To modify global configuration parameters, use the global configuration screen in the CloudStack UI. See Setting Global Configuration Parameters
+ Default Account Resource Limits14.4. Default Account Resource Limits
+ You can limit resource use by accounts. The default limits are set using global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account (max.account.snapshots, etc.)..
+
+ To override a default limit for a particular account, set a per-account resource limit.
+ 1.
+ Log in to the CloudStack UI.
+ 2.
+ In the left navigation tree, click Accounts.
+ 3.
+ Select the account you want to modify. The current limits are displayed. A value of -1 shows that there is no limit in place
+ 4.
+ Click the Edit button
+
+ Per-Domain Limits14.5. Per-Domain Limits
+ CloudStack allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of all accounts in the domain as well as all accounts in all subdomains of that domain. Limits set at the root domain level apply to the sum of resource usage by the accounts in all domains and sub-domains below that root domain.
+
+ To set a domain limit:
+ 1.
+ Log in to the CloudStack UI.
+ 2.
+ In the left navigation tree, click Domains.
+ 3.
+ Select the domain you want to modify. The current domain limits are displayed. A value of -1 shows that there is no limit in place.
+ 4.
+ Click the Edit button
+
+ Chapter 15.Chapter 15. Managing Networks and TrafficManaging Networks and Traffic
+ In a CloudStack, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN. The CloudStack virtual router is the main component providing networking features for guest traffic.
+ Guest Traffic15.1. Guest Traffic
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+
+ Figure 1 illustrates a typical guest traffic setup:
+
+ The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+
+ The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
+
+ Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
+ Networking in a Pod15.2. Networking in a Pod
+ Figure 2 illustrates network setup within a single pod. The hosts are connected to a pod-level switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
+
+ Servers are connected as follows:
+ •
+ Storage devices are connected to only the network that carries management traffic.
+ •
+ Hosts are connected to networks for both management traffic and public traffic.
+ •
+ Hosts are also connected to one or more networks carrying guest traffic.
+
+ We recommend the use of multiple physical Ethernet cards to implement each network interface as well as redundant switch fabric in order to maximize throughput and improve reliability.
+ Networking in a Zone15.3. Networking in a Zone
+ Figure 3 illustrates the network setup within a single zone.
+
+ A firewall for management traffic operates in the NAT mode. The network typically is assigned IP addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses in the 192.168.*.0/24 Class C private address space.
+
+ Each zone has its own set of public IP addresses. Public IP addresses from different zones do not overlap.
+ Basic Zone Physical Network Configuration15.4. Basic Zone Physical Network Configuration
+ In a basic network, configuring the physical network is fairly straightforward. You only need to configure one guest network to carry traffic that is generated by guest VMs. When you first add a zone to CloudPlatform, you set up the guest network through the Add Zone screens.
+ Advanced Zone Physical Network Configuration15.5. Advanced Zone Physical Network Configuration
+ Within a zone that uses advanced networking, you need to tell the Management Server how the physical network is set up to carry different kinds of traffic in isolation.
+ Configure Guest Traffic in an Advanced Zone15.5.1. Configure Guest Traffic in an Advanced Zone
+ These steps assume you have already logged in to the CloudStack UI. To configure the base guest network:
+ 1.
+ In the left navigation, choose Infrastructure. On Zones, click View More, then click the zone to which you want to add a network.
+ 2.
+ Click the Network tab.
+ 3.
+ Click Add guest network.
+
+ The Add guest network window is displayed:
+ 4.
+ Provide the following information:
+ •
+ Name. The name of the network. This will be user-visible
+ •
+ Display Text: The description of the network. This will be user-visible
+ •
+ Zone: The zone in which you are configuring the guest network.
+ •
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network
+ •
+ Guest Gateway: The gateway that the guests should use
+ •
+ Guest Netmask: The netmask in use on the subnet the guests will use
+ 5.
+ Click OK.
+ Configure Public Traffic in an Advanced Zone15.5.2. Configure Public Traffic in an Advanced Zone
+ In a zone that uses advanced networking, you need to configure at least one range of IP addresses for Internet traffic.
+ Using Multiple Guest Networks15.6. Using Multiple Guest Networks
+ In zones that use advanced networking, additional networks for guest traffic may be added at any time after the initial installation. You can also customize the domain name associated with the network by specifying a DNS suffix for each network.
+
+ A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has been created, although the user can go into the guest and remove the IP address from the NIC on a particular network.
+
+ Each VM has just one default network. The virtual router's DHCP reply will set the guest's default gateway as that for the default network. Multiple non-default networks may be added to a guest in addition to the single, required default network. The administrator can control which networks are available as the default network.
+
+ Additional networks can either be available to all accounts or be assigned to a specific account. Networks that are available to all accounts are zone-wide. Any user with access to the zone can create a VM with access to that network. These zone-wide networks provide little or no isolation between guests.Networks that are assigned to a specific account provide strong isolation.
+ Adding an Additional Guest Network15.6.1. Adding an Additional Guest Network1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ Click Add guest network. Provide the following information:
+ •
+ Name: The name of the network. This will be user-visible.
+ •
+ Display Text: The description of the network. This will be user-visible.
+ •
+ Zone. The name of the zone this network applies to. Each zone is a broadcast domain, and therefore each zone has a different IP range for the guest network. The administrator must configure the IP range for each zone.
+ •
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network.
+ •
+ Guest Gateway: The gateway that the guests should use.
+ •
+ Guest Netmask: The netmask in use on the subnet the guests will use.
+ 4.
+ Click Create.
+ Changing the Network Offering on a Guest Network15.6.2. Changing the Network Offering on a Guest Network
+ A user or administrator can change the network offering that is associated with an existing guest network.
+ •
+ Log in to the CloudStack UI as an administrator or end user.
+ •
+ If you are changing from a network offering that uses the CloudStack virtual router to one that uses external devices as network service providers, you must first stop all the VMs on the network. See Stopping and Starting VMs. Then return here and continue to the next step
+ •
+ In the left navigation, choose Network
+ •
+ Click the name of the network you want to modify
+
+ .
+ •
+ In Network Offering, choose the new network offering, then click Apply.
+ •
+ A prompt appears asking whether you want to keep the existing CIDR. This is to let you know that if you change the network offering, the CIDR will be affected. Choose No to proceed with the change.
+ •
+ Wait for the update to complete. Don’t try to restart VMs until after the network change is complete.
+ •
+ If you stopped any VMs in step 2, restart them.
+ Security Groups15.7. Security GroupsAbout Security Groups15.7.1. About Security Groups
+ Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In CloudStack 3.0.3 - 3.0.5, security groups are supported only in zones that use basic networking.
+ Note
+ In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
+
+
+ Each CloudStack account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.
+
+ Any CloudStack user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.
+
+ You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.
+
+ If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+ Adding a Security Group15.7.2. Adding a Security Group
+ A user or administrator can define a new security group.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network
+ 3.
+ In Select view, choose Security Groups.
+ 4.
+ Click Add Security Group.
+ 5.
+ Provide a name and description.
+ 6.
+ Click OK.
+
+ The new security group appears in the Security Groups Details tab.
+ 7.
+ To make the security group useful, continue to Adding Ingress and Egress Rules to a Security Group.
+ Enabling Security Groups15.7.3. Enabling Security Groups
+ In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide.
+ Adding Ingress and Egress Rules to a Security Group15.7.4. Adding Ingress and Egress Rules to a Security Group1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network
+ 3.
+ In Select view, choose Security Groups, then click the security group you want .
+ 4.
+ To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify what network traffic is allowed into VM instances in this security group. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+ •
+ Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow incoming traffic from all VMs in another security group
+ •
+ Protocol. The networking protocol that sources will use to send traffic to the security group. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+ •
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+ •
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be accepted.
+ •
+ CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+ •
+ Account, Security Group. (Add by Account only) To accept only traffic from another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter the same name you used in step 7.
+
+ The following example allows inbound HTTP access from anywhere:
+ 5.
+ To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been allowed in through an ingress rule
+ •
+ Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow outgoing traffic to all VMs in another security group.
+ •
+ Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+ •
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
+ •
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
+ •
+ CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+ •
+ Account, Security Group. (Add by Account only) To allow traffic to be sent to another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter its name.
+ 6.
+ Click Add.
+ External Firewalls and Load Balancers15.8. External Firewalls and Load Balancers
+ CloudStack is capable of replacing its Virtual Router with an external Juniper SRX device and an optional external NetScaler or F5 load balancer for gateway and load balancing services. In this case, the VMs use the SRX as their gateway.
+ Load Balancer Rules15.9. Load Balancer Rules
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.
+ Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudStack virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+ Guest IP Ranges15.10. Guest IP Ranges
+ The IP ranges for guest network traffic are set on a per-account basis by the user. This allows the users to configure their network in a fashion that will enable VPN linking between their guest network and their clients.
+ Acquiring a New IP Address15.11. Acquiring a New IP Address1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ Click the name of the network where you want to work with.
+ 4.
+ Click View IP Addresses.
+ 5.
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.
+ Releasing an IP Address15.12. Releasing an IP Address1.
+ Log in to the CloudPlatform UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ Click the name of the network where you want to work with.
+ 4.
+ Click View IP Addresses.
+ 5.
+ Click the IP address you want to release.
+ 6.
+ Click the Release IP button
+
+ .
+ Static NAT15.13. Static NAT
+ A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
+ IP Forwarding and Firewalling15.14. IP Forwarding and Firewalling
+ By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is translated via NAT to the public IP address and is allowed.
+
+ To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example, you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44. Then use port forwarding rules to direct traffic from individual ports within that range to specific ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public IP's port 33 to port 100 on one user VM's private IP.
+
+ For the steps to implement these rules, see Firewall Rules and Port Forwarding.
+ IP Load Balancing15.15. IP Load Balancing
+ The user may choose to associate the same public IP for multiple guests. CloudStack implements a TCP-level load balancer with the following policies.
+ •
+ Round-robin
+ •
+ Least connection
+ •
+ Source IP
+
+ This is similar to port forwarding but the destination may be multiple IP addresses.
+ DNS and DHCP15.16. DNS and DHCP
+ The Virtual Router provides DNS and DHCP services to the guests. It proxies DNS requests to the DNS server configured on the Availability Zone.
+ VPN15.17. VPN
+ CloudStack account owners can create virtual private networks (VPN) to access their virtual machines. If the guest network is instantiated from a network offering that offers the Remote Access VPN service, the virtual router (based on the System VM) is used to provide the service. CloudStack provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN. CloudStack does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.
+ Note
+ Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
+ •
+ Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
+ •
+ Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.
+ Configuring VPN15.17.1. Configuring VPN
+ To set up VPN for the cloud:
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, click Global Settings.
+ 3.
+ Set the following global configuration parameters.
+ •
+ remote.access.vpn.client.ip.range – The range of IP addressess to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
+ •
+ remote.access.vpn.psk.length – Length of the IPSec key.
+ •
+ remote.access.vpn.user.limit – Maximum number of VPN users per account.
+
+ To enable VPN for a particular network:
+ 1.
+ Log in as a user or administrator to the CloudStack UI.
+ 2.
+ In the left navigation, click Network.
+ 3.
+ Click the name of the network you want to work with.
+ 4.
+ Click View IP Addresses.
+ 5.
+ Click one of the displayed IP address names.
+ 6.
+ Click the Enable VPN button
+
+ .
+
+ The IPsec key is displayed in a popup window.
+ Using VPN with Windows15.17.2. Using VPN with Windows
+ The procedure to use VPN varies by Windows version. Generally, the user must edit the VPN properties and make sure that the default route is not the VPN. The following steps are for Windows L2TP clients on Windows Vista. The commands should be similar for other Windows versions.
+ 1.
+ Log in to the CloudStack UI and click on the source NAT IP for the account. The VPN tab should display the IPsec preshared key. Make a note of this and the source NAT IP. The UI also lists one or more users and their passwords. Choose one of these users, or, if none exists, add a user and password.
+ 2.
+ On the Windows box, go to Control Panel, then select Network and Sharing center. Click Setup a connection or network.
+ 3.
+ In the next dialog, select No, create a new connection.
+ 4.
+ In the next dialog, select Use my Internet Connection (VPN).
+ 5.
+ In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check Don't connect now.
+ 6.
+ In the next dialog, enter the user name and password selected in step 1.
+ 7.
+ Click Create.
+ 8.
+ Go back to the Control Panel and click Network Connections to see the new connection. The connection is not active yet.
+ 9.
+ Right-click the new connection and select Properties. In the Properties dialog, select the Networking tab.
+ 10.
+ In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key. Enter the preshared key from Step 1.
+ 11.
+ The connection is ready for activation. Go back to Control Panel -> Network Connections and double-click the created connection.
+ 12.
+ Enter the user name and password from Step 1.
+ Using VPN with Mac OS X15.17.3. Using VPN with Mac OS X
+ In Mac OS X, in Network Preferences - Advanced, make sure Send all traffic over VPN connection is not checked.
+ Setting Up a Site-to-Site VPN Connection15.17.4. Setting Up a Site-to-Site VPN Connection
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+ •
+ Cisco ISR with IOS 12.4 or later
+ •
+ Juniper J-Series routers with JunOS 9.5 or later
+ Note
+ In addition to the specific Cisco and Juniper devices listed above, the expectation is that any Cisco or Juniper device running on the supported operating systems are able to establish VPN connections.
+
+ To set up a Site-to-Site VPN connection, perform the following:
+ 1.
+ Create a Virtual Private Cloud (VPC).
+
+ See Section 15.19, “Configuring a Virtual Private Cloud”.
+ 2.
+ Create a VPN Customer Gateway.
+ 3.
+ Create a VPN gateway for the VPC that you created.
+ 4.
+ Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
+ 15.17.4.1. Creating and Updating a VPN Customer GatewayNote
+ A VPN customer gateway can be connected to only one VPN gateway at a time.
+
+ To add a VPN Customer Gateway:
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPN Customer Gateway.
+ 4.
+ Click Add site-to-site VPN.
+
+ Provide the following information:
+ •
+ Name: A unique name for the VPN customer gateway you create.
+ •
+ Gateway: The IP address for the remote gateway.
+ •
+ CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be RFC1918-compliant.
+ •
+ IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share a secret key. This key value is used to authenticate the customer gateway and the VPC VPN gateway to each other.
+ Note
+ The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.
+ •
+ IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is accomplished through the Preshared Keys.
+ Note
+ The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.
+ •
+ IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.
+ •
+ IKE DH: A public-key cryptography protocol which allows two parties to establish a shared secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).
+ •
+ ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192, AES256, and 3DES.
+ Note
+ The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.
+ •
+ ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash algorithms are SHA1 and MD5.
+ •
+ Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised. This property enforces a new Diffie-Hellman key exchange. It provides the keying material that has greater key material life and thereby greater resistance to cryptographic attacks. The available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key exchanges increase as the DH groups grow larger, as does the time of the exchanges.
+ Note
+ When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.
+ •
+ IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is 86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.
+ •
+ ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a new IPsec encryption and authentication session keys.
+ •
+ Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual router to query the liveliness of its IKE peer at regular intervals. It’s recommended to have the same configuration of DPD on both side of VPN connection.
+ 5.
+ Click OK.
+ Updating and Removing a VPN Customer Gateway
+ You can update a customer gateway either with no VPN connection, or related VPN connection is in error state.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPN Customer Gateway.
+ 4.
+ Select the VPN customer gateway you want to work with.
+ 5.
+ To modify the required parameters, click the Edit VPN Customer Gateway button
+
+ 6.
+ To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
+
+ 7.
+ Click OK.
+ 15.17.4.2. Creating a VPN gateway for the VPC1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select Site-to-Site VPN.
+
+ If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN prompts you to create a VPN gateway.
+ 7.
+ In the confirmation dialog, click Yes to confirm.
+
+ Within a few moments, the VPN gateway is created. You will be prompted to view the details of the VPN gateway you have created. Click Yes to confirm.
+
+ The following details are displayed in the VPN Gateway page:
+ •
+ IP Address
+ •
+ Account
+ •
+ Domain
+ 15.17.4.3. Creating a VPN Connection1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you create for the account are listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ASLs
+ 6.
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+ 7.
+ From the Select View drop-down, ensure that VPN Connection is selected.
+ 8.
+ Click Create VPN Connection.
+
+ The Create VPN Connection dialog is displayed:
+ 9.
+ Select the desired customer gateway, then click OK to confirm.
+
+ Within a few moments, the VPN Connection is displayed.
+
+ The following information on the VPN connection is displayed:
+ •
+ IP Address
+ •
+ Gateway
+ •
+ State
+ •
+ IPSec Preshared Key
+ •
+ IKE Policy
+ •
+ ESP Policy
+ 15.17.4.4. Restarting and Removing a VPN Connection1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ASLs
+ 6.
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+ 7.
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ All the VPN connections you created are displayed.
+ 8.
+ Select the VPN connection you want to work with.
+
+ The Details tab is displayed.
+ 9.
+ To remove a VPN connection, click the Delete VPN connection button
+
+
+ To restart a VPN connection, click the Reset VPN connection button present in the Details tab.
+
+ About Inter-VLAN Routing15.18. About Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You provision VLANs to the tiers your create, and VMs can be deployed on different tiers. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications, such as Web, Application, or Database. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+ The major advantages are:
+ •
+ The administrator can deploy a set of VLANs and allow users to deploy VMs on these VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that account.
+ Note
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+ •
+ The administrator can allow users create their own VPC and deploy the application. In this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that account.
+ •
+ Both administrators and users can create multiple VPCs. The guest network NIC is plugged to the VPC virtual router when the first VM is deployed in a tier.
+ •
+ The administrator can create the following gateways to send to or receive traffic from the VMs:
+ •
+ VPN Gateway: For more information, see Section 15.17.4.2, “Creating a VPN gateway for the VPC”.
+ •
+ Public Gateway: The public gateway for a VPC is added to the virtual router when the virtual router is created for VPC. The public gateway is not exposed to the end users. You are not allowed to list it, nor allowed to create any static routes.
+ •
+ Private Gateway: For more information, see Section 15.19.5, “Adding a Private Gateway to a VPC”.
+ •
+ Both administrators and users can create various possible destinations-gateway combinations. However, only one gateway of each type can be used in a deployment.
+
+ For example:
+ •
+ VLANs and Public Gateway: For example, an application is deployed in the cloud, and the Web application VMs communicate with the Internet.
+ •
+ VLANs, VPN Gateway, and Public Gateway: For example, an application is deployed in the cloud; the Web application VMs communicate with the Internet; and the database VMs communicate with the on-premise devices.
+ •
+ The administrator can define Access Control List (ACL) on the virtual router to filter the traffic among the VLANs or between the Internet and a VLAN. You can define ACL based on CIDR, port range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress type.
+
+ The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
+
+ To set up a multi-tier Inter-VLAN deployment, see Section 15.19, “Configuring a Virtual Private Cloud”.
+ Configuring a Virtual Private Cloud15.19. Configuring a Virtual Private CloudAbout Virtual Private Clouds15.19.1. About Virtual Private Clouds
+ CloudStack Virtual Private Cloud is a private, isolated part of CloudStack. A VPC can have its own virtual network topology that resembles a traditional physical network. You can launch VMs in the virtual network that can have private addresses in the range of your choice, for example: 10.0.0.0/16. You can define network tiers within your VPC network range, which in turn enables you to group similar kinds of instances based on IP address range.
+
+ For example, if a VPC has the private range 10.0.0.0/16, its guest networks can have the network ranges 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on.
+ Major Components of a VPC:
+ A VPC is comprised of the following network components:
+ •
+ VPC: A VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router.
+ •
+ Network Tiers: Each tier acts as an isolated network with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
+ •
+ Virtual Router: A virtual router is automatically created and started when you create a VPC. The virtual router connect the tiers and direct traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and DHCP services through its IP.
+ •
+ Public Gateway: The traffic to and from the Internet routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to the end user; therefore, static routes are not support for the public gateway.
+ •
+ Private Gateway: All the traffic to and from a private network routed to the VPC through the private gateway. For more information, see Section 15.19.5, “Adding a Private Gateway to a VPC”.
+ •
+ VPN Gateway: The VPC side of a VPN connection.
+ •
+ Site-to-Site VPN Connection: A hardware-based VPN connection between your VPC and your datacenter, home network, or co-location facility. For more information, see Section 15.17.4, “Setting Up a Site-to-Site VPN Connection”.
+ •
+ Customer Gateway: The customer side of a VPN Connection. For more information, see Section 15.17.4.1, “Creating and Updating a VPN Customer Gateway”.
+ •
+ NAT Instance: An instance that provides Port Address Translation for instances to access the Internet via the public gateway. For more information, see Section 15.19.9, “Enabling or Disabling Static NAT on a VPC”.
+ Network Architecture in a VPC
+ In a VPC, the following four basic options of network architectures are present:
+ •
+ VPC with a public gateway only
+ •
+ VPC with public and private gateways
+ •
+ VPC with public and private gateways and site-to-site VPN access
+ •
+ VPC with a private gateway only and site-to-site VPN access
+ Connectivity Options for a VPC
+ You can connect your VPC to:
+ •
+ The Internet through the public gateway.
+ •
+ The corporate datacenter by using a site-to-site VPN connection through the VPN gateway.
+ •
+ Both the Internet and your corporate datacenter by using both the public gateway and a VPN gateway.
+ VPC Network Considerations
+ Consider the following before you create a VPC:
+ •
+ A VPC, by default, is created in the enabled state.
+ •
+ A VPC can be created in Advance zone only, and can't belong to more than one zone at a time.
+ •
+ The default number of VPCs an account can create is 20. However, you can change it by using the max.account.vpcs global parameter, which controls the maximum number of VPCs an account is allowed to create.
+ •
+ The default number of tiers an account can create within a VPC is 3. You can configure this number by using the vpc.max.networks parameter.
+ •
+ Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be within the VPC CIDR range.
+ •
+ A tier belongs to only one VPC.
+ •
+ All network tiers inside the VPC should belong to the same account.
+ •
+ When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP is released only when the VPC is removed.
+ •
+ A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it cannot be used for StaticNAT or port forwarding.
+ •
+ The instances only have a private IP address that you provision. To communicate with the Internet, enable NAT to an instance that you launch in your VPC.
+ •
+ Only new networks can be added to a VPC. The maximum number of networks per VPC is limited by the value you specify in the vpc.max.networks parameter. The default value is three.
+ •
+ The load balancing service can be supported by only one tier inside the VPC.
+ •
+ If an IP address is assigned to a tier:
+ •
+ That IP can't be used by more than one tier at a time in the VPC. For example, if you have tiers A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A or B, but not for both.
+ •
+ That IP can't be used for StaticNAT, load balancing, or port forwarding rules for another guest network inside the VPC.
+ •
+ Remote access VPN is not supported in VPC networks.
+ Adding a Virtual Private Cloud15.19.2. Adding a Virtual Private Cloud
+ When creating the VPC, you simply provide the zone and a set of IP addresses for the VPC network address space. You specify this set of addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+ 4.
+ Click Add VPC. The Add VPC page is displayed as follows:
+
+ Provide the following information:
+ •
+ Name: A short name for the VPC that you are creating.
+ •
+ Description: A brief description of the VPC.
+ •
+ Zone: Choose the zone where you want the VPC to be available.
+ •
+ Super CIDR for Guest Networks: Defines the CIDR range for all the tiers (guest networks) within a VPC. When you create a tier, ensure that its CIDR is within the Super CIDR value you enter. The CIDR must be RFC1918 compliant.
+ •
+ DNS domain for Guest Networks: If you want to assign a special domain name, specify the DNS suffix. This parameter is applied to all the tiers within the VPC. That implies, all the tiers you create in the VPC belong to the same DNS domain. If the parameter is not specified, a DNS domain name is generated automatically.
+ Adding Tiers15.19.3. Adding Tiers
+ Tiers are distinct locations within a VPC that act as isolated networks, which do not have access to other tiers by default. Tiers are set up on different VLANs that can communicate with each other by using a virtual router. Tiers provide inexpensive, low latency network connectivity to other tiers within the VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+ Note
+ The end users can see their own VPCs, while root and domain admin can see any VPC they are authorized to see.
+ 4.
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Add new tier dialog is displayed, as follows:
+
+ If you have already created tiers, the VPC diagram is displayed. Click Create Tier to add a new tier.
+ 5.
+ Specify the following:
+
+ All the fields are mandatory.
+ •
+ Name: A unique name for the tier you create.
+ •
+ Network Offering: The following default network offerings are listed: DefaultIsolatedNetworkOfferingForVpcNetworksNoLB, DefaultIsolatedNetworkOfferingForVpcNetworks
+
+ In a VPC, only one tier can be created by using LB-enabled network offering.
+ •
+ Gateway: The gateway for the tier you create. Ensure that the gateway is within the Super CIDR range that you specified while creating the VPC, and is not overlapped with the CIDR of any existing tier within the VPC.
+ •
+ Netmask: The netmask for the tier you create.
+
+ For example, if the VPC CIDR is 10.0.0.0/16 and the network tier CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the netmask of the tier is 255.255.255.0.
+ 6.
+ Click OK.
+ 7.
+ Continue with configuring access control list for the tier.
+ Configuring Access Control List15.19.4. Configuring Access Control List
+ Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service is supported.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 5.
+ Select Network ACLs.
+
+ The Network ACLs page is displayed.
+ 6.
+ Click Add Network ACLs.
+
+ To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed in this tier.
+ •
+ CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or to the IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+ •
+ Protocol: The networking protocol that sources use to send traffic to the tier. The TCP and UDP protocols are typically used for data exchange and end-user communications. The ICMP protocol is typically used to send error messages or network monitoring data.
+ •
+ Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+ •
+ Select Tier: Select the tier for which you want to add this ACL rule.
+ •
+ ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
+ •
+ Traffic Type: Select the traffic type you want to apply.
+ •
+ Egress: To add an egress rule, select Egress from the Traffic type drop-down box and click Add. This specifies what type of traffic is allowed to be sent out of VM instances in this tier. If no egress rules are specified, all traffic from the tier is allowed out at the VPC virtual router. Once egress rules are specified, only the traffic specified in egress rules and the responses to any traffic that has been allowed in through an ingress rule are allowed out. No egress rule is required for the VMs in a tier to communicate with each other.
+ •
+ Ingress: To add an ingress rule, select Ingress from the Traffic type drop-down box and click Add. This specifies what network traffic is allowed into the VM instances in this tier. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+ Note
+ By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, create a new network ACL.
+ 7.
+ Click Add. The ACL rule is added.
+
+ To view the list of ACL rules you have added, click the desired tier from the Network ACLs page, then select the Network ACL tab.
+
+ You can edit the tags assigned to the ACL rules and delete the ACL rules you have created. Click the appropriate button in the Actions column.
+ Adding a Private Gateway to a VPC15.19.5. Adding a Private Gateway to a VPC
+ A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. No gateways with duplicated VLAN and IP are allowed in the same data center.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Private Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select Private Gateways.
+
+ The Gateways page is displayed.
+ 7.
+ Click Add new gateway:
+ 8.
+ Specify the following:
+ •
+ Physical Network: The physical network you have created in the zone.
+ •
+ IP Address: The IP address associated with the VPC gateway.
+ •
+ Gateway: The gateway through which the traffic is routed to and from the VPC.
+ •
+ Netmask: The netmask associated with the VPC gateway.
+ •
+ VLAN: The VLAN associated with the VPC gateway.
+
+ The new gateway appears in the list. You can repeat these steps to add more gateway for this VPC.
+ Deploying VMs to the Tier15.19.6. Deploying VMs to the Tier1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed.
+ 5.
+ Click the Add VM button of the tier for which you want to add a VM.
+
+ The Add Instance page is displayed.
+
+ Follow the on-screen instruction to add an instance. For information on adding an instance, see Adding Instances section in the Installation Guide.
+ Acquiring a New IP Address for a VPC15.19.7. Acquiring a New IP Address for a VPC
+ When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks within the VPC. The IPs are associated to the guest network only when the first port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP can't be associated to more than one network at a time.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding, load balancing, and static NAT rules.
+ Releasing an IP Address Alloted to a VPC15.19.8. Releasing an IP Address Alloted to a VPC
+ The IP address is a limited resource. If you no longer need a particular IP, you can disassociate it from its VPC and return it to the pool of available addresses. An IP address can be released from its tier, only when all the networking ( port forwarding, load balancing, or StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to the same VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC whose IP you want to release.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click the IP you want to release.
+ 8.
+ In the Details tab, click the Release IP button
+
+ Enabling or Disabling Static NAT on a VPC15.19.9. Enabling or Disabling Static NAT on a VPC
+ A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to allow Internet traffic to it. This section tells how to enable or disable static NAT for a particular IP address in a VPC.
+
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click the IP you want to work with.
+ 8.
+ In the Details tab,click the Static NAT button.
+
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+ 9.
+ If you are enabling static NAT, a dialog appears as follows:
+ 10.
+ Select the tier and the destination VM, then click Apply.
+ Adding Load Balancing Rules on a VPC15.19.10. Adding Load Balancing Rules on a VPC
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+ 8.
+ In the Load Balancing node of the diagram, click View All.
+ 9.
+ Select the tier to which you want to apply the rule.
+ Note
+ In a VPC, the load balancing service is supported only on a single tier.
+ 10.
+ Specify the following:
+ •
+ Name: A name for the load balancer rule.
+ •
+ Public Port: The port that receives the incoming traffic to be balanced.
+ •
+ Private Port: The port that the VMs will use to receive the traffic.
+ •
+ Algorithm. Choose the load balancing algorithm you want CloudStack to use. CloudStack supports the following well-known algorithms:
+ •
+ Round-robin
+ •
+ Least connections
+ •
+ Source
+ •
+ Stickiness. (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
+ •
+ Add VMs: Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.
+
+ The new load balancing rule appears in the list. You can repeat these steps to add more load balancing rules for this IP address.
+ Adding a Port Forwarding Rule on a VPC15.19.11. Adding a Port Forwarding Rule on a VPC1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Choose an existing IP address or acquire a new IP address. Click the name of the IP address in the list.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+ 8.
+ In the Port Forwarding node of the diagram, click View All.
+ 9.
+ Select the tier to which you want to apply the rule.
+ 10.
+ Specify the following:
+ •
+ Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+ •
+ Private Port: The port on which the instance is listening for forwarded public traffic.
+ •
+ Protocol: The communication protocol in use between the two ports.
+ •
+ TCP
+ •
+ UDP
+ •
+ Add VM: Click Add VM. Select the name of the instance to which this rule applies, and click Apply.
+
+ You can test the rule by opening an ssh session to the instance.
+ Removing Tiers15.19.12. Removing Tiers
+ You can remove a tier from a VPC. A removed tier cannot be revoked. When a tier is removed, only the resources of the tier are expunged. All the network rules (port forwarding, load balancing and staticNAT) and the IP addresses associated to the tier are removed. The IP address still be belonging to the same VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Configure VPC page is displayed. Locate the tier you want to work with.
+ 5.
+ Click the Remove VPC button:
+
+ Wait for some time for the tier to be removed.
+ Editing, Restarting, and Removing a Virtual Private Cloud15.19.13. Editing, Restarting, and Removing a Virtual Private CloudNote
+ Ensure that all the tiers are removed before you remove a VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Select the VPC you want to work with.
+ 5.
+ To remove, click the Remove VPC button
+
+
+ You can edit the name and description of a VPC. To do that, select the VPC, then click the Edit button.
+
+
+ To restart a VPC, select the VPC, then click the Restart button.
+
+ Chapter 16.Chapter 16. Working with System Virtual MachinesWorking with System Virtual Machines
+ CloudStack uses several types of system virtual machines to perform tasks in the cloud. In general CloudStack manages these system VMs and creates, starts, and stops them as needed based on scale and immediate needs. However, the administrator should be aware of them and their roles to assist in debugging issues.
+ The System VM Template16.1. The System VM Template
+ The System VMs come from a single template. The System VM has the following characteristics:
+ •
+ Debian 6.0 ("Squeeze"), 2.6.32 kernel with the latest security patches from the Debian security APT repository
+ •
+ Has a minimal set of packages installed thereby reducing the attack surface
+ •
+ 32-bit for enhanced performance on Xen/VMWare
+ •
+ pvops kernel with Xen PV drivers, KVM virtio drivers, and VMware tools for optimum performance on all hypervisors
+ •
+ Xen tools inclusion allows performance monitoring
+ •
+ Latest versions of HAProxy, iptables, IPsec, and Apache from debian repository ensures improved security and speed
+ •
+ Latest version of JRE from Sun/Oracle ensures improved security and speed
+ Multiple System VM Support for VMware16.2. Multiple System VM Support for VMware
+ Every CloudStack zone has single System VM for template processing tasks such as downloading templates, uploading templates, and uploading ISOs. In a zone where VMware is being used, additional System VMs can be launched to process VMware-specific tasks such as taking snapshots and creating private templates. The CloudStack management server launches additional System VMs for VMware-specific tasks as the load increases. The management server monitors and weights all commands sent to these System VMs and performs dynamic load balancing and scaling-up of more System VMs.
+ Console Proxy16.3. Console Proxy
+ The Console Proxy is a type of System Virtual Machine that has a role in presenting a console view via the web UI. It connects the user’s browser to the VNC port made available via the hypervisor for the console of the guest. Both the administrator and end user web UIs offer a console connection.
+
+ Clicking on a console icon brings up a new window. The AJAX code downloaded into that window refers to the public IP address of a console proxy VM. There is exactly one public IP address allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then proxies the connection to the VNC port for the requested VM on the Host hosting the guest. .
+ Note
+ The hypervisors will have many ports assigned to VNC usage so that multiple VNC sessions can occur simultaneously.
+
+ There is never any traffic to the guest virtual IP, and there is no need to enable VNC within the guest.
+
+ The console proxy VM will periodically report its active session count to the Management Server. The default reporting interval is five seconds. This can be changed through standard Management Server configuration with the parameter consoleproxy.loadscan.interval.
+
+ Assignment of guest VM to console proxy is determined by first determining if the guest VM has a previous session associated with a console proxy. If it does, the Management Server will assign the guest VM to the target Console Proxy VM regardless of the load on the proxy VM. Failing that, the first available running Console Proxy VM that has the capacity to handle new sessions is used.
+
+ Console proxies can be restarted by administrators but this will interrupt existing console sessions for users.
+
+ The console viewing functionality uses a dynamic DNS service under the domain name realhostip.com to assist in providing SSL security to console sessions. The console proxy is assigned a public IP address. In order to avoid browser warnings for mismatched SSL certificates, the URL for the new console window is set to the form of https://aaa-bbb-ccc-ddd.realhostip.com. Customers will see this URL during console session creation. CloudStack includes the realhostip.com SSL certificate in the console proxy VM. Of course, CloudStack cannot know about DNS A records for our customers' public IPs prior to shipping the software. CloudStack therefore runs a dynamic DNS server that is authoritative for the realhostip.com domain. It maps the aaa-bbb-ccc-ddd part of the DNS name to the IP address aaa.bbb.ccc.ddd on lookups. This allows the browser to correctly connect to the console proxy's public IP, where it then expects and receives a SSL certificate for realhostip.com, and SSL is set up without browser warnings.
+ Virtual Router16.4. Virtual Router
+ The virtual router is a type of System Virtual Machine. The virtual router is one of the most frequently used service providers in CloudStack. The end user has no direct access to the virtual router. Users can ping the virtual router and take actions that affect it (such as setting up port forwarding), but users do not have SSH access into the virtual router.
+
+ There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be restarted by administrators, but this will interrupt public network access and other services for end users. A basic test in debugging networking issues is to attempt to ping the virtual router from a guest VM. Some of the characteristics of the virtual router are determined by its associated system service offering.
+ Secondary Storage VM16.5. Secondary Storage VM
+ In addition to the hosts, CloudStack’s Secondary Storage VM mounts and writes to secondary storage.
+
+ Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols.
+
+ The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups.
+
+ The administrator can log in to the secondary storage VM if needed.
+ Chapter 17.Chapter 17. System Reliability and High AvailabilitySystem Reliability and High AvailabilityHA for Management Server17.1. HA for Management Server
+ The CloudStack Management Server should be deployed in a multi-node configuration such that it is not susceptible to individual server failures. The Management Server itself (as distinct from the MySQL database) is stateless and may be placed behind a load balancer.
+
+ Normal operation of Hosts is not impacted by an outage of all Management Serves. All guest VMs will continue to work.
+
+ When the Management Server is down, no new VMs can be created, and the end user and admin UI, API, dynamic load distribution, and HA will cease to work.
+ HA-Enabled Virtual Machines17.2. HA-Enabled Virtual Machines
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+ HA for Hosts17.3. HA for Hosts
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. CloudStack has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+ Primary Storage Outage and Data Loss17.4. Primary Storage Outage and Data Loss
+ When a primary storage outage occurs the hypervisor immediately stops all VMs stored on that storage device. Guests that are marked for HA will be restarted as soon as practical when the primary storage comes back on line. With NFS, the hypervisor may allow the virtual machines to continue running depending on the nature of the issue. For example, an NFS hang will cause the guest VMs to be suspended until storage connectivity is restored.Primary storage is not designed to be backed up. Individual volumes in primary storage can be backed up using snapshots.
+ Secondary Storage Outage and Data Loss17.5. Secondary Storage Outage and Data Loss
+ For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online.
+
+ Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system.
+ Chapter 18.Chapter 18. Managing the CloudManaging the CloudUsing Tags to Organize Resources in the Cloud18.1. 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:
+ 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 Configuration18.2. Changing the Database Configuration
+ The CloudStack Management Server stores database configuration information (e.g., hostname, port, credentials) in the file /etc/cloud/management/db.properties. To effect a change, edit this file on each Management Server, then restart the Management Server.
+ Administrator Alerts18.3. 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
+ Customizing the Network Domain Name18.4. 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.
+ 1.
+ 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” 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.
+ 2.
+ 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 Server18.5. 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:
+ # service cloud-management stop
+ To start the Management Server:
+ # service cloud-management start
+ To stop the Management Server:
+ # service cloud-management stopChapter 19.Chapter 19. Setting Global Configuration ParametersSetting Global Configuration Parameters
+ CloudStack provides parameters that you can set to control many aspects of the cloud. When CloudStack is first installed, and periodically thereafter, you might need to modify these settings.
+ 1.
+ Log in to the UI as administrator.
+ 2.
+ In the left navigation bar, click Global Settings.
+ 3.
+ In Select View, choose one of the following:
+ •
+ Global Settings. This displays a list of the parameters with brief descriptions and current values.
+ •
+ Hypervisor Capabilities. This displays a list of hypervisor versions with the maximum number of guests supported for each.
+ 4.
+ Use the search box to narrow down the list to those you are interested in.
+ 5.
+ Click the Edit icon to modify a value. If you are viewing Hypervisor Capabilities, you must click the name of the hypervisor first to display the editing screen.
+ Chapter 20.Chapter 20. CloudStack APICloudStack 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 Guide11http://docs.cloudstack.org/CloudStack_Documentation/Developer's_Guide%3A_CloudStack and the API Reference22http://docs.cloudstack.org/CloudStack_Documentation/API_Reference%3A_CloudStack.
+ Provisioning and Authentication API20.1. 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.
+ Allocators20.2. Allocators
+ CloudStack enables administrators to write custom allocators that will choose the Host to place a new guest and the storage host from which to allocate guest virtual disk images.
+ User Data and Meta Data20.3. User Data and Meta Data
+ CloudStack provides API access to attach 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:
+ 1.
+ Run the following command to find the virtual router.
+ # cat /var/lib/dhclient/dhclient-eth0.leases | grep dhcp-server-identifier | tail -12.
+ Access user data by running the following command using the result of the above command
+ # 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
+ Chapter 21.Chapter 21. TuningTuning
+ This section provides tips on how to improve the performance of your cloud.
+ Performance Monitoring21.1. Performance Monitoring
+ Host and guest performance monitoring is available to end users and administrators. This allows the user to monitor their utilization of resources and determine when it is appropriate to choose a more powerful service offering or larger disk.
+ Increase Management Server Maximum Memory21.2. Increase Management Server Maximum Memory
+ If the Management Server is subject to high demand, the default maximum JVM memory allocation can be insufficient. To increase the memory:
+ 1.
+ Edit the Tomcat configuration file:
+ /etc/cloud/management/tomcat6.conf2.
+ Change the command-line parameter -XmxNNNm to a higher value of N.
+
+ For example, if the current value is -Xmx128m, change it to -Xmx1024m or higher.
+ 3.
+ To put the new setting into effect, restart the Management Server.
+ # service cloud-management restart
+ For more information about memory issues, see "FAQ: Memory" at Tomcat Wiki.11http://wiki.apache.org/tomcat/FAQ/Memory
+ Set Database Buffer Pool Size21.3. Set Database Buffer Pool Size
+ It is important to provide enough memory space for the MySQL database to cache data and indexes:
+ 1.
+ Edit the Tomcat configuration file:
+ /etc/my.cnf2.
+ Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM.
+ innodb_buffer_pool_size=700M3.
+ Restart the MySQL service.
+ # service mysqld restart
+ For more information about the buffer pool, see "The InnoDB Buffer Pool" at MySQL Reference Manual22http://dev.mysql.com/doc/refman/5.5/en/innodb-buffer-pool.html.
+ Set and Monitor Total VM Limits per Host21.4. Set and Monitor Total VM Limits per Host
+ The CloudStack administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use CloudStack global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
+ Configure XenServer dom0 Memory21.5. Configure XenServer dom0 Memory
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article33http://support.citrix.com/article/CTX126531.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+ Chapter 22.Chapter 22. TroubleshootingTroubleshootingEvents22.1. EventsEvent Logs22.1.1. 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..
+ Standard Events22.1.2. 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 Events22.1.3. 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 Queries22.1.4. 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
+ Working with Server Logs22.2. Working with Server Logs
+ The CloudStack Management Server logs all web site, middle tier, and database activities for diagnostics purposes in /var/log/cloud/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.
+
+ grep -i -E 'exception|unable|fail|invalid|leak|warn|error' /var/log/cloud/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:
+
+ 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:
+
+ grep "job-1076)" management-server.log
+
+ The CloudStack Agent Server logs its activities in /var/log/cloud/agent/.
+ Data Loss on Exported Primary Storage22.3. Data Loss on Exported Primary StorageSymptom
+ 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:
+ echo “/export 192.168.1.0/24(rw,async,no_root_squash)” > /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 22.4. 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_CloudStackAPI Reference.
+ Maintenance mode not working on vCenter22.5. Maintenance mode not working on vCenterSymptom
+ Host was placed in maintenance mode, but still appears live in vCenter.
+ Cause
+ The CloudPlatform 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”
+ Unable to deploy VMs from uploaded vSphere template22.6. Unable to deploy VMs from uploaded vSphere templateSymptom
+ 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 VMware22.7. Unable to power on virtual machine on VMwareSymptom
+ 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 Article11http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051/
+ Load balancer rules fail after changing network offering22.8. Load balancer rules fail after changing network offeringSymptom
+ 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 CloudPlatform 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.
+ Appendix A. Time ZonesAppendix A. Time Zones
+ 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
+
+
+
+
+ Appendix B. Event TypesAppendix B. Event Types
+
+ VM.CREATE
+
+
+
+ TEMPLATE.EXTRACT
+
+
+
+ SG.REVOKE.INGRESS
+
+
+
+ VM.DESTROY
+
+
+
+ TEMPLATE.UPLOAD
+
+
+
+ HOST.RECONNECT
+
+
+
+ VM.START
+
+
+
+ TEMPLATE.CLEANUP
+
+
+
+ MAINT.CANCEL
+
+
+
+ VM.STOP
+
+
+
+ VOLUME.CREATE
+
+
+
+ MAINT.CANCEL.PS
+
+
+
+ VM.REBOOT
+
+
+
+ VOLUME.DELETE
+
+
+
+ MAINT.PREPARE
+
+
+
+ VM.UPGRADE
+
+
+
+ VOLUME.ATTACH
+
+
+
+ MAINT.PREPARE.PS
+
+
+
+ VM.RESETPASSWORD
+
+
+
+ VOLUME.DETACH
+
+
+
+ VPN.REMOTE.ACCESS.CREATE
+
+
+
+ ROUTER.CREATE
+
+
+
+ VOLUME.UPLOAD
+
+
+
+ VPN.USER.ADD
+
+
+
+ ROUTER.DESTROY
+
+
+
+ SERVICEOFFERING.CREATE
+
+
+
+ VPN.USER.REMOVE
+
+
+
+ ROUTER.START
+
+
+
+ SERVICEOFFERING.UPDATE
+
+
+
+ NETWORK.RESTART
+
+
+
+ ROUTER.STOP
+
+
+
+ SERVICEOFFERING.DELETE
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+ ROUTER.REBOOT
+
+
+
+ DOMAIN.CREATE
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+ ROUTER.HA
+
+
+
+ DOMAIN.DELETE
+
+
+
+ STATICNAT.DISABLE
+
+
+
+ PROXY.CREATE
+
+
+
+ DOMAIN.UPDATE
+
+
+
+ SSVM.CREATE
+
+
+
+ PROXY.DESTROY
+
+
+
+ SNAPSHOT.CREATE
+
+
+
+ SSVM.DESTROY
+
+
+
+ PROXY.START
+
+
+
+ SNAPSHOT.DELETE
+
+
+
+ SSVM.START
+
+
+
+ PROXY.STOP
+
+
+
+ SNAPSHOTPOLICY.CREATE
+
+
+
+ SSVM.STOP
+
+
+
+ PROXY.REBOOT
+
+
+
+ SNAPSHOTPOLICY.UPDATE
+
+
+
+ SSVM.REBOOT
+
+
+
+ PROXY.HA
+
+
+
+ SNAPSHOTPOLICY.DELETE
+
+
+
+ SSVM.H
+
+
+
+ VNC.CONNECT
+
+
+
+ VNC.DISCONNECT
+
+
+
+ NET.IPASSIGN
+
+
+
+ NET.IPRELEASE
+
+
+
+ NET.RULEADD
+
+
+
+ NET.RULEDELETE
+
+
+
+ NET.RULEMODIFY
+
+
+
+ NETWORK.CREATE
+
+
+
+ NETWORK.DELETE
+
+
+
+ LB.ASSIGN.TO.RULE
+
+
+
+ LB.REMOVE.FROM.RULE
+
+
+
+ LB.CREATE
+
+
+
+ LB.DELETE
+
+
+
+ LB.UPDATE
+
+
+
+ USER.LOGIN
+
+
+
+ USER.LOGOUT
+
+
+
+ USER.CREATE
+
+
+
+ USER.DELETE
+
+
+
+ USER.UPDATE
+
+
+
+ USER.DISABLE
+
+
+
+ TEMPLATE.CREATE
+
+
+
+ TEMPLATE.DELETE
+
+
+
+ TEMPLATE.UPDATE
+
+
+
+ TEMPLATE.COPY
+
+
+
+ TEMPLATE.DOWNLOAD.START
+
+
+
+ TEMPLATE.DOWNLOAD.SUCCESS
+
+
+
+ TEMPLATE.DOWNLOAD.FAILED
+
+
+
+ ISO.CREATE
+
+
+
+ ISO.DELETE
+
+
+
+ ISO.COPY
+
+
+
+ ISO.ATTACH
+
+
+
+ ISO.DETACH
+
+
+
+ ISO.EXTRACT
+
+
+
+ ISO.UPLOAD
+
+
+
+ SERVICE.OFFERING.CREATE
+
+
+
+ SERVICE.OFFERING.EDIT
+
+
+
+ SERVICE.OFFERING.DELETE
+
+
+
+ DISK.OFFERING.CREATE
+
+
+
+ DISK.OFFERING.EDIT
+
+
+
+ DISK.OFFERING.DELETE
+
+
+
+ NETWORK.OFFERING.CREATE
+
+
+
+ NETWORK.OFFERING.EDIT
+
+
+
+ NETWORK.OFFERING.DELETE
+
+
+
+ POD.CREATE
+
+
+
+ POD.EDIT
+
+
+
+ POD.DELETE
+
+
+
+ ZONE.CREATE
+
+
+
+ ZONE.EDIT
+
+
+
+ ZONE.DELETE
+
+
+
+ VLAN.IP.RANGE.CREATE
+
+
+
+ VLAN.IP.RANGE.DELETE
+
+
+
+ CONFIGURATION.VALUE.EDIT
+
+
+
+ SG.AUTH.INGRESS
+
+
+
+
+ Appendix C. AlertsAppendix C. Alerts
+ The following is the list of alert type numbers. The current alerts can be found by calling listAlerts.
+ MEMORY = 0CPU = 1STORAGE =2STORAGE_ALLOCATED = 3PUBLIC_IP = 4PRIVATE_IP = 5HOST = 6USERVM = 7DOMAIN_ROUTER = 8CONSOLE_PROXY = 9ROUTING = 10// lost connection to default route (to the gateway)STORAGE_MISC = 11 // lost connection to default route (to the gateway)USAGE_SERVER = 12 // lost connection to default route (to the gateway)MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)DOMAIN_ROUTER_MIGRATE = 14CONSOLE_PROXY_MIGRATE = 15USERVM_MIGRATE = 16VLAN = 17SSVM = 18USAGE_SERVER_RESULT = 19STORAGE_DELETE = 20;UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource countUSAGE_SANITY_RESULT = 22;DIRECT_ATTACHED_PUBLIC_IP = 23;LOCAL_STORAGE = 24;RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots onlyAppendix D. Revision HistoryAppendix D. Revision History
+ Revision 0-0Tue May 29 2012Jessica Tomechak
+ Initial creation of book by publican
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Admin_Guide.xml b/docs/tmp/en-US/xml/Admin_Guide.xml
new file mode 100644
index 00000000000..4f9d62a23b3
--- /dev/null
+++ b/docs/tmp/en-US/xml/Admin_Guide.xml
@@ -0,0 +1,75 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ &PRODUCT; Administrator's Guide
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Administration Guide for &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Author_Group.xml b/docs/tmp/en-US/xml/Author_Group.xml
new file mode 100644
index 00000000000..3952f3e134a
--- /dev/null
+++ b/docs/tmp/en-US/xml/Author_Group.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Apache
+ CloudStack
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Book_Info.xml b/docs/tmp/en-US/xml/Book_Info.xml
new file mode 100644
index 00000000000..034e7e7c6bf
--- /dev/null
+++ b/docs/tmp/en-US/xml/Book_Info.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ &PRODUCT; Guide
+ Revised August 9, 2012 10:48 pm Pacific
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Complete technical documentation of &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Book_Info_Release_Notes_4.0.xml b/docs/tmp/en-US/xml/Book_Info_Release_Notes_4.0.xml
new file mode 100644
index 00000000000..ad2ceae3fe3
--- /dev/null
+++ b/docs/tmp/en-US/xml/Book_Info_Release_Notes_4.0.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Version 4.0.0-incubating Release Notes
+ Revised October 17, 2012 19:49 UTC
+ Apache CloudStack
+
+
+
+
+ Release notes for the Apache CloudStack 4.0.0-incubating release.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/CloudStack_Nicira_NVP_Guide.xml b/docs/tmp/en-US/xml/CloudStack_Nicira_NVP_Guide.xml
new file mode 100644
index 00000000000..1b79485e9f5
--- /dev/null
+++ b/docs/tmp/en-US/xml/CloudStack_Nicira_NVP_Guide.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ &PRODUCT; Plugin Guide for the Nicira NVP Plugin
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Plugin Guide for the Nicira NVP Plugin.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/Conventions.xml b/docs/tmp/en-US/xml/Common_Content/Conventions.xml
new file mode 100644
index 00000000000..797d884a975
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/Conventions.xml
@@ -0,0 +1,178 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Document Conventions
+
+ This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.
+
+
+ In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default.
+
+
+ Typographic Conventions
+
+ Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.
+
+
+ Mono-spaced Bold
+
+
+ Used to highlight system input, including shell commands, file names and paths. Also used to highlight keycaps and key combinations. For example:
+
+
+
+ To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.
+
+
+
+
+ The above includes a file name, a shell command and a keycap, all presented in mono-spaced bold and all distinguishable thanks to context.
+
+
+ Key combinations can be distinguished from keycaps by the hyphen connecting each part of a key combination. For example:
+
+
+
+ Press Enter to execute the command.
+
+
+ Press CtrlAltF2 to switch to the first virtual terminal. Press CtrlAltF1 to return to your X-Windows session.
+
+
+
+
+ The first paragraph highlights the particular keycap to press. The second highlights two key combinations (each a set of three keycaps with each set pressed simultaneously).
+
+
+ If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:
+
+
+
+ File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.
+
+
+
+
+ Proportional Bold
+
+
+ This denotes words or phrases encountered on a system, including application names; dialog box text; labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:
+
+
+
+ Choose SystemPreferencesMouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
+
+
+ To insert a special character into a gedit file, choose ApplicationsAccessoriesCharacter Map from the main menu bar. Next, choose SearchFind… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose EditPaste from the gedit menu bar.
+
+
+
+
+ The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context.
+
+
+ Mono-spaced Bold Italic or Proportional Bold Italic
+
+
+ Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
+
+
+
+ To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.
+
+
+ The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.
+
+
+ To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.
+
+
+
+
+ Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
+
+
+ Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
+
+
+
+ Publican is a DocBook publishing system.
+
+
+
+
+
+
+
+ Pull-quote Conventions
+
+ Terminal output and source code listings are set off visually from the surrounding text.
+
+
+ Output sent to a terminal is set in mono-spaced roman and presented thus:
+
+
+books Desktop documentation drafts mss photos stuff svn
+books_tests Desktop1 downloads images notes scripts svgs
+
+ Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:
+
+
+package org.jboss.book.jca.ex1;
+
+import javax.naming.InitialContext;
+
+public class ExClient
+{
+ public static void main(String args[])
+ throws Exception
+ {
+ InitialContext iniCtx = new InitialContext();
+ Object ref = iniCtx.lookup("EchoBean");
+ EchoHome home = (EchoHome) ref;
+ Echo echo = home.create();
+
+ System.out.println("Created Echo");
+
+ System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
+ }
+}
+
+
+
+
+ Notes and Warnings
+
+ Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.
+
+
+ Note
+
+ Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.
+
+
+
+
+ Important
+
+ Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled 'Important' will not cause data loss but may cause irritation and frustration.
+
+
+
+
+ Warning
+
+ Warnings should not be ignored. Ignoring warnings will most likely cause data loss.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/Feedback.xml b/docs/tmp/en-US/xml/Common_Content/Feedback.xml
new file mode 100644
index 00000000000..1eb12a843f2
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/Feedback.xml
@@ -0,0 +1,22 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ We Need Feedback!
+
+ feedback1
+ contact information for this brand
+
+
+
+ If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a bug: http://bugs.cloudstack.org against the component Doc
+
+
+ If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/Legal_Notice.xml b/docs/tmp/en-US/xml/Common_Content/Legal_Notice.xml
new file mode 100644
index 00000000000..f703a3e1b68
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/Legal_Notice.xml
@@ -0,0 +1,23 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/css/common.css b/docs/tmp/en-US/xml/Common_Content/css/common.css
new file mode 100644
index 00000000000..d7dc3f27be8
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/css/common.css
@@ -0,0 +1,1528 @@
+* {
+ widows: 2 !important;
+ orphans: 2 !important;
+}
+
+body, h1, h2, h3, h4, h5, h6, pre, li, div {
+ line-height: 1.29em;
+}
+
+body {
+ background-color: white;
+ margin:0 auto;
+ font-family: "liberation sans", "Myriad ", "Bitstream Vera Sans", "Lucida Grande", "Luxi Sans", "Trebuchet MS", helvetica, verdana, arial, sans-serif;
+ font-size:12px;
+ max-width:55em;
+ color:black;
+}
+
+body.toc_embeded {
+ /*for web hosting system only*/
+ margin-left: 300px;
+}
+
+object.toc, iframe.toc {
+ /*for web hosting system only*/
+ border-style:none;
+ position:fixed;
+ width:290px;
+ height:99.99%;
+ top:0;
+ left:0;
+ z-index: 100;
+ border-style:none;
+ border-right:1px solid #999;
+}
+
+/* Hide web menu */
+
+body.notoc {
+ margin-left: 3em;
+}
+
+iframe.notoc {
+ border-style:none;
+ border: none;
+ padding: 0em;
+ position:fixed;
+ width: 21px;
+ height: 29px;
+ top: 0px;
+ left:0;
+ overflow: hidden;
+ margin: 0em;
+ margin-left: -3px;
+}
+/* End hide web menu */
+
+/* desktop styles */
+body.desktop {
+ margin-left: 26em;
+}
+
+body.desktop .book > .toc {
+ display:block;
+ width:24em;
+ height:99%;
+ position:fixed;
+ overflow:auto;
+ top:0px;
+ left:0px;
+ padding-left:1em;
+ background-color:#EEEEEE;
+}
+
+.toc {
+ line-height:1.35em;
+}
+
+.toc .glossary,
+.toc .chapter, .toc .appendix {
+ margin-top:1em;
+}
+
+.toc .part {
+ margin-top:1em;
+ display:block;
+}
+
+span.glossary,
+span.appendix {
+ display:block;
+ margin-top:0.5em;
+}
+
+div {
+ padding-top:0px;
+}
+
+div.section {
+ padding-top:1em;
+}
+
+p, div.para, div.formalpara {
+ padding-top:0px;
+ margin-top:0.3em;
+ padding-bottom:0px;
+ margin-bottom:1em;
+}
+
+/*Links*/
+a {
+ outline: none;
+}
+
+a:link {
+ text-decoration:none;
+ border-bottom: 1px dotted ;
+ color:#3366cc;
+}
+
+a:visited {
+ text-decoration:none;
+ border-bottom: 1px dotted ;
+ color:#003366;
+}
+
+div.longdesc-link {
+ float:right;
+ color:#999;
+}
+
+.toc a, .qandaset a {
+ font-weight:normal;
+ border:none;
+}
+
+.toc a:hover, .qandaset a:hover
+{
+ border-bottom: 1px dotted;
+}
+
+/*headings*/
+h1, h2, h3, h4, h5, h6 {
+ color: #336699;
+ margin-top: 0em;
+ margin-bottom: 0em;
+ background-color: transparent;
+ page-break-inside: avoid;
+ page-break-after: avoid;
+}
+
+h1 {
+ font-size:2.0em;
+}
+
+.titlepage h1.title {
+ font-size: 3.0em;
+ padding-top: 1em;
+ text-align:left;
+}
+
+.book > .titlepage h1.title {
+ text-align:center;
+}
+
+.article > .titlepage h1.title {
+ text-align:center;
+}
+
+.set .titlepage > div > div > h1.title {
+ text-align:center;
+}
+
+.producttitle {
+ margin-top: 0em;
+ margin-bottom: 0em;
+ font-size: 3.0em;
+ font-weight: bold;
+ background: #003d6e url(../images/h1-bg.png) top left repeat-x;
+ color: white;
+ text-align: center;
+ padding: 0.7em;
+}
+
+.titlepage .corpauthor {
+ margin-top: 1em;
+ text-align: center;
+}
+
+.section h1.title {
+ font-size: 1.6em;
+ padding: 0em;
+ color: #336699;
+ text-align: left;
+ background: white;
+}
+
+h2 {
+ font-size:1.6em;
+}
+
+
+h2.subtitle, h3.subtitle {
+ margin-top: 1em;
+ margin-bottom: 1em;
+ font-size: 1.4em;
+ text-align: center;
+}
+
+.preface > div > div > div > h2.title {
+ margin-top: 1em;
+ font-size: 2.0em;
+}
+
+.appendix h2 {
+ margin-top: 1em;
+ font-size: 2.0em;
+}
+
+
+
+h3 {
+ font-size:1.3em;
+ padding-top:0em;
+ padding-bottom:0em;
+}
+h4 {
+ font-size:1.1em;
+ padding-top:0em;
+ padding-bottom:0em;
+}
+
+h5 {
+ font-size:1em;
+}
+
+h6 {
+ font-size:1em;
+}
+
+h5.formalpara {
+ font-size:1em;
+ margin-top:2em;
+ margin-bottom:.8em;
+}
+
+.abstract h6 {
+ margin-top:1em;
+ margin-bottom:.5em;
+ font-size:2em;
+}
+
+/*element rules*/
+hr {
+ border-collapse: collapse;
+ border-style:none;
+ border-top: 1px dotted #ccc;
+ width:100%;
+ margin-top: 3em;
+}
+
+/* web site rules */
+ul.languages, .languages li {
+ display:inline;
+ padding:0em;
+}
+
+.languages li a {
+ padding:0em .5em;
+ text-decoration: none;
+}
+
+.languages li p, .languages li div.para {
+ display:inline;
+}
+
+.languages li a:link, .languages li a:visited {
+ color:#444;
+}
+
+.languages li a:hover, .languages li a:focus, .languages li a:active {
+ color:black;
+}
+
+ul.languages {
+ display:block;
+ background-color:#eee;
+ padding:.5em;
+}
+
+/*supporting stylesheets*/
+
+/*unique to the webpage only*/
+.books {
+ position:relative;
+}
+
+.versions li {
+ width:100%;
+ clear:both;
+ display:block;
+}
+
+a.version {
+ font-size:2em;
+ text-decoration:none;
+ width:100%;
+ display:block;
+ padding:1em 0em .2em 0em;
+ clear:both;
+}
+
+a.version:before {
+ content:"Version";
+ font-size:smaller;
+}
+
+a.version:visited, a.version:link {
+ color:#666;
+}
+
+a.version:focus, a.version:hover {
+ color:black;
+}
+
+.books {
+ display:block;
+ position:relative;
+ clear:both;
+ width:100%;
+}
+
+.books li {
+ display:block;
+ width:200px;
+ float:left;
+ position:relative;
+ clear: none ;
+}
+
+.books .html {
+ width:170px;
+ display:block;
+}
+
+.books .pdf {
+ position:absolute;
+ left:170px;
+ top:0px;
+ font-size:smaller;
+}
+
+.books .pdf:link, .books .pdf:visited {
+ color:#555;
+}
+
+.books .pdf:hover, .books .pdf:focus {
+ color:#000;
+}
+
+.books li a {
+ text-decoration:none;
+}
+
+.books li a:hover {
+ color:black;
+}
+
+/*products*/
+.products li {
+ display: block;
+ width:300px;
+ float:left;
+}
+
+.products li a {
+ width:300px;
+ padding:.5em 0em;
+}
+
+.products ul {
+ clear:both;
+}
+
+/*revision history*/
+.revhistory {
+ display:block;
+}
+
+.revhistory table {
+ background-color:transparent;
+ border-color:#fff;
+ padding:0em;
+ margin: 0;
+ border-collapse:collapse;
+ border-style:none;
+}
+
+.revhistory td {
+ text-align :left;
+ padding:0em;
+ border: none;
+ border-top: 1px solid #fff;
+ font-weight: bold;
+}
+
+.revhistory .simplelist td {
+ font-weight: normal;
+}
+
+.revhistory .simplelist {
+ margin-bottom: 1.5em;
+ margin-left: 1em;
+}
+
+.revhistory table th {
+ display: none;
+}
+
+
+/*credits*/
+.authorgroup div {
+ clear:both;
+ text-align: center;
+}
+
+h3.author {
+ margin: 0em;
+ padding: 0em;
+ padding-top: 1em;
+}
+
+.authorgroup h4 {
+ padding: 0em;
+ margin: 0em;
+ padding-top: 1em;
+ margin-top: 1em;
+}
+
+.author,
+.editor,
+.translator,
+.othercredit,
+.contrib {
+ display: block;
+}
+
+.revhistory .author {
+ display: inline;
+}
+
+.othercredit h3 {
+ padding-top: 1em;
+}
+
+
+.othercredit {
+ margin:0em;
+ padding:0em;
+}
+
+.releaseinfo {
+ clear: both;
+}
+
+.copyright {
+ margin-top: 1em;
+}
+
+/* qanda sets */
+.answer {
+ margin-bottom:1em;
+ border-bottom:1px dotted #ccc;
+}
+
+.qandaset .toc {
+ border-bottom:1px dotted #ccc;
+}
+
+.question {
+ font-weight:bold;
+}
+
+.answer .data, .question .data {
+ padding-left: 2.6em;
+}
+
+.answer label, .question label {
+ float:left;
+ font-weight:bold;
+}
+
+/* inline syntax highlighting */
+.perl_Alert {
+ color: #0000ff;
+}
+
+.perl_BaseN {
+ color: #007f00;
+}
+
+.perl_BString {
+ color: #5C3566;
+}
+
+.perl_Char {
+ color: #ff00ff;
+}
+
+.perl_Comment {
+ color: #FF00FF;
+}
+
+
+.perl_DataType {
+ color: #0000ff;
+}
+
+
+.perl_DecVal {
+ color: #00007f;
+}
+
+
+.perl_Error {
+ color: #ff0000;
+}
+
+
+.perl_Float {
+ color: #00007f;
+}
+
+
+.perl_Function {
+ color: #007f00;
+}
+
+
+.perl_IString {
+ color: #5C3566;
+}
+
+
+.perl_Keyword {
+ color: #002F5D;
+}
+
+
+.perl_Operator {
+ color: #ffa500;
+}
+
+
+.perl_Others {
+ color: #b03060;
+}
+
+
+.perl_RegionMarker {
+ color: #96b9ff;
+}
+
+
+.perl_Reserved {
+ color: #9b30ff;
+}
+
+
+.perl_String {
+ color: #5C3566;
+}
+
+
+.perl_Variable {
+ color: #0000ff;
+}
+
+
+.perl_Warning {
+ color: #0000ff;
+}
+
+/*Lists*/
+ul {
+ padding-left:1.6em;
+ list-style-image:url(../images/dot.png);
+ list-style-type: circle;
+}
+
+ul ul {
+ list-style-image:url(../images/dot2.png);
+ list-style-type: circle;
+}
+
+ol {
+ list-style-image:none;
+ list-style-type: decimal;
+}
+
+ol ol {
+ list-style-type: lower-alpha;
+}
+
+ol.arabic {
+ list-style-type: decimal;
+}
+
+ol.loweralpha {
+ list-style-type: lower-alpha;
+}
+
+ol.lowerroman {
+ list-style-type: lower-roman;
+}
+
+ol.upperalpha {
+ list-style-type: upper-alpha;
+}
+
+ol.upperroman {
+ list-style-type: upper-roman;
+}
+
+dt {
+ font-weight:bold;
+ margin-bottom:0em;
+ padding-bottom:0em;
+}
+
+dd {
+ margin:0em;
+ margin-left:2em;
+ padding-top:0em;
+ padding-bottom: 1em;
+}
+
+li {
+ padding-top:0px;
+ margin-top:0em;
+ padding-bottom:0px;
+ margin-bottom:0.4em;
+}
+
+li p, li div.para {
+ padding-top:0px;
+ margin-top:0em;
+ padding-bottom:0px;
+ margin-bottom:0.3em;
+}
+
+/*images*/
+img {
+ display:block;
+ margin: 2em 0;
+}
+
+.inlinemediaobject, .inlinemediaobject img {
+ display:inline;
+ margin:0em;
+}
+
+.figure img {
+ display:block;
+ margin:0;
+ page-break-inside: avoid;
+}
+
+.figure .title {
+ margin:0em;
+ margin-bottom:2em;
+ padding:0px;
+}
+
+/*document modes*/
+.confidential {
+ background-color:#900;
+ color:White;
+ padding:.5em .5em;
+ text-transform:uppercase;
+ text-align:center;
+}
+
+.longdesc-link {
+ display:none;
+}
+
+.longdesc {
+ display:none;
+}
+
+.prompt {
+ padding:0em .3em;
+}
+
+/*user interface styles*/
+.screen .replaceable {
+}
+
+.guibutton, .guilabel {
+ font-family: "liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-weight: bold;
+ white-space: nowrap;
+}
+
+.example {
+ background-color: #ffffff;
+ border-left: 3px solid #aaaaaa;
+ padding-top: 1em;
+ padding-bottom: 0.1em;
+}
+
+.example h6 {
+ padding-left: 10px;
+}
+
+.example-contents {
+ padding-left: 10px;
+ background-color: #ffffff;
+}
+
+.example-contents .para {
+/* padding: 10px;*/
+}
+
+/*terminal/console text*/
+.computeroutput,
+.option {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-weight:bold;
+}
+
+.replaceable {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-style: italic;
+}
+
+.command, .filename, .keycap, .classname, .literal {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ font-weight:bold;
+}
+
+/* no bold in toc */
+.toc * {
+ font-weight: inherit;
+}
+
+pre {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+ display:block;
+ background-color: #f5f5f5;
+ color: #000000;
+ border: 1px solid #aaaaaa;
+ margin-bottom: 0.3em;
+ padding:.5em 1em;
+ white-space: pre-wrap; /* css-3 */
+ white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
+ white-space: -pre-wrap; /* Opera 4-6 */
+ white-space: -o-pre-wrap; /* Opera 7 */
+ word-wrap: break-word; /* Internet Explorer 5.5+ */
+ font-size: 0.9em;
+}
+
+pre .replaceable,
+pre .keycap {
+}
+
+code {
+ font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
+/* white-space: nowrap;*/
+ white-space: pre-wrap;
+ word-wrap: break-word;
+ font-weight:bold;
+}
+
+.parameter code {
+ display: inline;
+ white-space: pre-wrap; /* css-3 */
+ white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
+ white-space: -pre-wrap; /* Opera 4-6 */
+ white-space: -o-pre-wrap; /* Opera 7 */
+ word-wrap: break-word; /* Internet Explorer 5.5+ */
+}
+
+/*Notifications*/
+div.warning:before {
+ content:url(../images/warning.png);
+ padding-left: 5px;
+}
+
+div.note:before {
+ content:url(../images/note.png);
+ padding-left: 5px;
+}
+
+div.important:before {
+ content:url(../images/important.png);
+ padding-left: 5px;
+}
+
+div.warning, div.note, div.important {
+ color: black;
+ margin: 0em;
+ padding: 0em;
+ background: none;
+ background-color: white;
+ margin-bottom: 1em;
+ border-bottom: 1px solid #aaaaaa;
+ page-break-inside: avoid;
+}
+
+div.warning h2, div.note h2,div.important h2 {
+ margin: 0em;
+ padding: 0em;
+ color: #eeeeec;
+ padding-top: 0px;
+ padding-bottom: 0px;
+ height: 1.4em;
+ line-height: 1.4em;
+ font-size: 1.4em;
+ display:inline;
+}
+
+div.admonition_header {
+ clear: both;
+ margin: 0em;
+ padding: 0em;
+ margin-top: -3.3em;
+ padding-left: 58px;
+ line-height: 1.0em;
+ font-size: 1.0em;
+}
+
+div.warning div.admonition_header {
+ background: url(../images/red.png) top left repeat-x;
+ background-color: #590000;
+}
+
+div.note div.admonition_header {
+ background: url(../images/green.png) top right repeat-x;
+ background-color: #597800;
+}
+
+div.important div.admonition_header {
+ background: url(../images/yellow.png) top right repeat-x;
+ background-color: #a6710f;
+}
+
+div.warning p, div.warning div.para,
+div.note p, div.note div.para,
+div.important p, div.important div.para {
+ padding: 0em;
+ margin: 0em;
+}
+
+div.admonition {
+ border: none;
+ border-left: 1px solid #aaaaaa;
+ border-right: 1px solid #aaaaaa;
+ padding:0em;
+ margin:0em;
+ padding-top: 1.5em;
+ padding-bottom: 1em;
+ padding-left: 2em;
+ padding-right: 1em;
+ background-color: #eeeeec;
+ -moz-border-radius: 0px;
+ -webkit-border-radius: 0px;
+ border-radius: 0px;
+}
+
+/*Page Title*/
+#title {
+ display:block;
+ height:45px;
+ padding-bottom:1em;
+ margin:0em;
+}
+
+#title a.left{
+ display:inline;
+ border:none;
+}
+
+#title a.left img{
+ border:none;
+ float:left;
+ margin:0em;
+ margin-top:.7em;
+}
+
+#title a.right {
+ padding-bottom:1em;
+}
+
+#title a.right img {
+ border:none;
+ float:right;
+ margin:0em;
+ margin-top:.7em;
+}
+
+/*Table*/
+div.table {
+ page-break-inside: avoid;
+}
+
+table {
+ border:1px solid #6c614b;
+ width:100%;
+ border-collapse:collapse;
+}
+
+table.simplelist, .calloutlist table {
+ border-style: none;
+}
+
+table th {
+ text-align:left;
+ background-color:#6699cc;
+ padding:.3em .5em;
+ color:white;
+}
+
+table td {
+ padding:.15em .5em;
+}
+
+table tr.even td {
+ background-color:#f5f5f5;
+}
+
+table th p:first-child, table td p:first-child, table li p:first-child,
+table th div.para:first-child, table td div.para:first-child, table li div.para:first-child {
+ margin-top:0em;
+ padding-top:0em;
+ display:inline;
+}
+
+th, td {
+ border-style:none;
+ vertical-align: top;
+ border: 1px solid #000;
+}
+
+.simplelist th, .simplelist td {
+ border: none;
+}
+
+table table td {
+ border-bottom:1px dotted #aaa;
+ background-color:white;
+ padding:.6em 0em;
+}
+
+table table {
+ border:1px solid white;
+}
+
+td.remarkval {
+ color:#444;
+}
+
+td.fieldval {
+ font-weight:bold;
+}
+
+.lbname, .lbtype, .lbdescr, .lbdriver, .lbhost {
+ color:white;
+ font-weight:bold;
+ background-color:#999;
+ width:120px;
+}
+
+td.remarkval {
+ width:230px;
+}
+
+td.tname {
+ font-weight:bold;
+}
+
+th.dbfield {
+ width:120px;
+}
+
+th.dbtype {
+ width:70px;
+}
+
+th.dbdefault {
+ width:70px;
+}
+
+th.dbnul {
+ width:70px;
+}
+
+th.dbkey {
+ width:70px;
+}
+
+span.book {
+ margin-top:4em;
+ display:block;
+ font-size:11pt;
+}
+
+span.book a{
+ font-weight:bold;
+}
+span.chapter {
+ display:block;
+ margin-top:0.5em;
+}
+
+table.simplelist td, .calloutlist table td {
+ border-style: none;
+}
+
+/*Breadcrumbs*/
+#breadcrumbs ul li.first:before {
+ content:" ";
+}
+
+#breadcrumbs {
+ color:#900;
+ padding:3px;
+ margin-bottom:25px;
+}
+
+#breadcrumbs ul {
+ margin-left:0;
+ padding-left:0;
+ display:inline;
+ border:none;
+}
+
+#breadcrumbs ul li {
+ margin-left:0;
+ padding-left:2px;
+ border:none;
+ list-style:none;
+ display:inline;
+}
+
+#breadcrumbs ul li:before {
+ content:"\0020 \0020 \0020 \00BB \0020";
+ color:#333;
+}
+
+/*index*/
+.glossary h3,
+.index h3 {
+ font-size: 2em;
+ color:#aaa;
+ margin:0em;
+}
+
+.indexdiv {
+ margin-bottom:1em;
+}
+
+.glossary dt,
+.index dt {
+ color:#444;
+ padding-top:.5em;
+}
+
+.glossary dl dl dt,
+.index dl dl dt {
+ color:#777;
+ font-weight:normal;
+ padding-top:0em;
+}
+
+.index dl dl dt:before {
+ content:"- ";
+ color:#ccc;
+}
+
+/*changes*/
+.footnote {
+ font-size: .7em;
+ margin:0em;
+ color:#222;
+}
+
+table .footnote {
+}
+
+sup {
+ color:#999;
+ margin:0em;
+ padding:0em;
+ line-height: .4em;
+ font-size: 1em;
+ padding-left:0em;
+}
+
+.footnote {
+ position:relative;
+}
+
+.footnote sup {
+ color:#e3dcc0;
+ position:absolute;
+ left: .4em;
+}
+
+.footnote sup a:link,
+.footnote sup a:visited {
+ color:#92917d;
+ text-decoration:none;
+}
+
+.footnote:hover sup a {
+ text-decoration:none;
+}
+
+.footnote p,.footnote div.para {
+ padding-left:2em;
+}
+
+.footnote a:link,
+.footnote a:visited {
+ color:#00537c;
+}
+
+.footnote a:hover {
+}
+
+/**/
+div.chapter {
+ margin-top:3em;
+ page-break-inside: avoid;
+}
+
+div.preface {
+ page-break-inside: avoid;
+}
+
+div.section {
+ margin-top:1em;
+ page-break-inside: auto;
+}
+
+div.note .replaceable,
+div.important .replaceable,
+div.warning .replaceable,
+div.note .keycap,
+div.important .keycap,
+div.warning .keycap
+{
+}
+
+ul li p:last-child, ul li div.para:last-child {
+ margin-bottom:0em;
+ padding-bottom:0em;
+}
+
+/*document navigation*/
+.docnav a, .docnav strong {
+ border:none;
+ text-decoration:none;
+ font-weight:normal;
+}
+
+.docnav {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+ position:relative;
+ width:100%;
+ padding-bottom:2em;
+ padding-top:1em;
+ border-top:1px dotted #ccc;
+}
+
+.docnav li {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+ display:inline;
+ font-size:.8em;
+}
+
+.docnav li:before {
+ content:" ";
+}
+
+.docnav li.previous, .docnav li.next {
+ position:absolute;
+ top:1em;
+}
+
+.docnav li.up, .docnav li.home {
+ margin:0em 1.5em;
+}
+
+.docnav li.previous {
+ left:0px;
+ text-align:left;
+}
+
+.docnav li.next {
+ right:0px;
+ text-align:right;
+}
+
+.docnav li.previous strong, .docnav li.next strong {
+ height:22px;
+ display:block;
+}
+
+.docnav {
+ margin:0 auto;
+ text-align:center;
+}
+
+.docnav li.next a strong {
+ background: url(../images/stock-go-forward.png) top right no-repeat;
+ padding-top:3px;
+ padding-bottom:4px;
+ padding-right:28px;
+ font-size:1.2em;
+}
+
+.docnav li.previous a strong {
+ background: url(../images/stock-go-back.png) top left no-repeat;
+ padding-top:3px;
+ padding-bottom:4px;
+ padding-left:28px;
+ padding-right:0.5em;
+ font-size:1.2em;
+}
+
+.docnav li.home a strong {
+ background: url(../images/stock-home.png) top left no-repeat;
+ padding:5px;
+ padding-left:28px;
+ font-size:1.2em;
+}
+
+.docnav li.up a strong {
+ background: url(../images/stock-go-up.png) top left no-repeat;
+ padding:5px;
+ padding-left:28px;
+ font-size:1.2em;
+}
+
+.docnav a:link, .docnav a:visited {
+ color:#666;
+}
+
+.docnav a:hover, .docnav a:focus, .docnav a:active {
+ color:black;
+}
+
+.docnav a {
+ max-width: 10em;
+ overflow:hidden;
+}
+
+.docnav a:link strong {
+ text-decoration:none;
+}
+
+.docnav {
+ margin:0 auto;
+ text-align:center;
+}
+
+ul.docnav {
+ margin-bottom: 1em;
+}
+/* Reports */
+.reports ul {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+}
+
+.reports li{
+ margin:0em;
+ padding:0em;
+}
+
+.reports li.odd {
+ background-color: #eeeeee;
+ margin:0em;
+ padding:0em;
+}
+
+.reports dl {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ float:right;
+ margin-right: 17em;
+ margin-top:-1.3em;
+}
+
+.reports dt {
+ display:inline;
+ margin:0em;
+ padding:0em;
+}
+
+.reports dd {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ padding-right:.5em;
+}
+
+.reports h2, .reports h3{
+ display:inline;
+ padding-right:.5em;
+ font-size:10pt;
+ font-weight:normal;
+}
+
+.reports div.progress {
+ display:inline;
+ float:right;
+ width:16em;
+ background:#c00 url(../images/shine.png) top left repeat-x;
+ margin:0em;
+ margin-top:-1.3em;
+ padding:0em;
+ border:none;
+}
+
+/*uniform*/
+body.results, body.reports {
+ max-width:57em ;
+ padding:0em;
+}
+
+/*Progress Bar*/
+div.progress {
+ display:block;
+ float:left;
+ width:16em;
+ background:#c00 url(../images/shine.png) top left repeat-x;
+ height:1em;
+}
+
+div.progress span {
+ height:1em;
+ float:left;
+}
+
+div.progress span.translated {
+ background:#6c3 url(../images/shine.png) top left repeat-x;
+}
+
+div.progress span.fuzzy {
+ background:#ff9f00 url(../images/shine.png) top left repeat-x;
+}
+
+
+/*Results*/
+
+.results ul {
+ list-style:none;
+ margin:0em;
+ padding:0em;
+}
+
+.results li{
+ margin:0em;
+ padding:0em;
+}
+
+.results li.odd {
+ background-color: #eeeeee;
+ margin:0em;
+ padding:0em;
+}
+
+.results dl {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ float:right;
+ margin-right: 17em;
+ margin-top:-1.3em;
+}
+
+.results dt {
+ display:inline;
+ margin:0em;
+ padding:0em;
+}
+
+.results dd {
+ display:inline;
+ margin:0em;
+ padding:0em;
+ padding-right:.5em;
+}
+
+.results h2, .results h3 {
+ display:inline;
+ padding-right:.5em;
+ font-size:10pt;
+ font-weight:normal;
+}
+
+.results div.progress {
+ display:inline;
+ float:right;
+ width:16em;
+ background:#c00 url(../images/shine.png) top left repeat-x;
+ margin:0em;
+ margin-top:-1.3em;
+ padding:0em;
+ border:none;
+}
+
+/* Dirty EVIL Mozilla hack for round corners */
+pre {
+ -moz-border-radius:11px;
+ -webkit-border-radius:11px;
+ border-radius: 11px;
+ page-break-inside: avoid;
+}
+
+.example {
+ -moz-border-radius:0px;
+ -webkit-border-radius:0px;
+ border-radius: 0px;
+ page-break-inside: avoid;
+}
+
+.package, .citetitle {
+ font-style: italic;
+}
+
+.titlepage .edition {
+ color: #336699;
+ background-color: transparent;
+ margin-top: 1em;
+ margin-bottom: 1em;
+ font-size: 1.4em;
+ font-weight: bold;
+ text-align: center;
+}
+
+span.remark {
+ background-color: #ff00ff;
+}
+
+.draft {
+ background-image: url(../images/watermark-draft.png);
+ background-repeat: repeat-y;
+ background-position: center;
+}
+
+.foreignphrase {
+ font-style: inherit;
+}
+
+dt {
+ clear:both;
+}
+
+dt img {
+ border-style: none;
+ max-width: 112px;
+}
+
+dt object {
+ max-width: 112px;
+}
+
+dt .inlinemediaobject, dt object {
+ display: inline;
+ float: left;
+ margin-bottom: 1em;
+ padding-right: 1em;
+ width: 112px;
+}
+
+dl:after {
+ display: block;
+ clear: both;
+ content: "";
+}
+
+.toc dd {
+ padding-bottom: 0em;
+ margin-bottom: 1em;
+ padding-left: 1.3em;
+ margin-left: 0em;
+}
+
+div.toc > dl > dt {
+ padding-bottom: 0em;
+ margin-bottom: 0em;
+ margin-top: 1em;
+}
+
+
+.strikethrough {
+ text-decoration: line-through;
+}
+
+.underline {
+ text-decoration: underline;
+}
+
+.calloutlist img, .callout {
+ padding: 0em;
+ margin: 0em;
+ width: 12pt;
+ display: inline;
+ vertical-align: middle;
+}
+
+.stepalternatives {
+ list-style-image: none;
+ list-style-type: none;
+}
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/css/default.css b/docs/tmp/en-US/xml/Common_Content/css/default.css
new file mode 100644
index 00000000000..bf38ebb5931
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/css/default.css
@@ -0,0 +1,3 @@
+@import url("common.css");
+@import url("overrides.css");
+@import url("lang.css");
diff --git a/docs/tmp/en-US/xml/Common_Content/css/lang.css b/docs/tmp/en-US/xml/Common_Content/css/lang.css
new file mode 100644
index 00000000000..81c3115605a
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/css/lang.css
@@ -0,0 +1,2 @@
+/* place holder */
+
diff --git a/docs/tmp/en-US/xml/Common_Content/css/overrides.css b/docs/tmp/en-US/xml/Common_Content/css/overrides.css
new file mode 100644
index 00000000000..ebd9730b690
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/css/overrides.css
@@ -0,0 +1,57 @@
+a:link {
+ color:#0066cc;
+}
+
+a:visited {
+ color:#6699cc;
+}
+
+h1 {
+ color:#3c6eb4;
+}
+
+.producttitle {
+ background: #3c6eb4 url(../images/h1-bg.png) top left repeat;
+}
+
+.section h1.title {
+ color:#3c6eb4;
+}
+
+
+h2,h3,h4,h5,h6 {
+ color:#3c6eb4
+}
+
+table {
+ border:1px solid #3c6eb4;
+}
+
+table th {
+ background-color:#3c6eb4;
+}
+
+table tr.even td {
+ background-color:#f5f5f5;
+}
+
+#title a {
+ height:54px;
+}
+
+.term{
+ color:#a70000;
+}
+
+.revhistory table th {
+ color:#3c6eb4;
+}
+
+.edition {
+ color: #3c6eb4;
+}
+
+span.remark{
+ background-color: #ffff00;
+}
+
diff --git a/docs/tmp/en-US/xml/Common_Content/css/print.css b/docs/tmp/en-US/xml/Common_Content/css/print.css
new file mode 100644
index 00000000000..773d8ae1b1c
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/css/print.css
@@ -0,0 +1,16 @@
+@import url("common.css");
+@import url("overrides.css");
+@import url("lang.css");
+
+#tocframe {
+ display: none;
+}
+
+body.toc_embeded {
+ margin-left: 30px;
+}
+
+.producttitle {
+ color: #336699;
+}
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/1.png b/docs/tmp/en-US/xml/Common_Content/images/1.png
new file mode 100644
index 00000000000..ef0beba8510
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/1.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/1.svg b/docs/tmp/en-US/xml/Common_Content/images/1.svg
new file mode 100644
index 00000000000..4c6bf579527
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/1.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/10.png b/docs/tmp/en-US/xml/Common_Content/images/10.png
new file mode 100644
index 00000000000..05f22391ea7
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/10.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/10.svg b/docs/tmp/en-US/xml/Common_Content/images/10.svg
new file mode 100644
index 00000000000..0edda5b6fa6
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/10.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/11.png b/docs/tmp/en-US/xml/Common_Content/images/11.png
new file mode 100644
index 00000000000..32b4a04831e
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/11.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/11.svg b/docs/tmp/en-US/xml/Common_Content/images/11.svg
new file mode 100644
index 00000000000..c95afcc14a1
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/11.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/12.png b/docs/tmp/en-US/xml/Common_Content/images/12.png
new file mode 100644
index 00000000000..45fa4892a94
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/12.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/12.svg b/docs/tmp/en-US/xml/Common_Content/images/12.svg
new file mode 100644
index 00000000000..e3c3fd66c7d
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/12.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/13.png b/docs/tmp/en-US/xml/Common_Content/images/13.png
new file mode 100644
index 00000000000..0b766d3f87b
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/13.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/13.svg b/docs/tmp/en-US/xml/Common_Content/images/13.svg
new file mode 100644
index 00000000000..35b4969143d
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/13.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/14.png b/docs/tmp/en-US/xml/Common_Content/images/14.png
new file mode 100644
index 00000000000..2e1d73716c2
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/14.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/14.svg b/docs/tmp/en-US/xml/Common_Content/images/14.svg
new file mode 100644
index 00000000000..832f816799a
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/14.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/15.png b/docs/tmp/en-US/xml/Common_Content/images/15.png
new file mode 100644
index 00000000000..7d21c66bb04
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/15.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/15.svg b/docs/tmp/en-US/xml/Common_Content/images/15.svg
new file mode 100644
index 00000000000..830d65439c6
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/15.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/16.png b/docs/tmp/en-US/xml/Common_Content/images/16.png
new file mode 100644
index 00000000000..ff396af2fa6
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/16.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/16.svg b/docs/tmp/en-US/xml/Common_Content/images/16.svg
new file mode 100644
index 00000000000..24d1eea0458
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/16.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/17.png b/docs/tmp/en-US/xml/Common_Content/images/17.png
new file mode 100644
index 00000000000..f1ba68a7f60
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/17.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/17.svg b/docs/tmp/en-US/xml/Common_Content/images/17.svg
new file mode 100644
index 00000000000..7796bd1d7db
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/17.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/18.png b/docs/tmp/en-US/xml/Common_Content/images/18.png
new file mode 100644
index 00000000000..df920d02515
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/18.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/18.svg b/docs/tmp/en-US/xml/Common_Content/images/18.svg
new file mode 100644
index 00000000000..356f207eefb
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/18.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/19.png b/docs/tmp/en-US/xml/Common_Content/images/19.png
new file mode 100644
index 00000000000..bda9a8c559d
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/19.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/19.svg b/docs/tmp/en-US/xml/Common_Content/images/19.svg
new file mode 100644
index 00000000000..385378074ed
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/19.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/2.png b/docs/tmp/en-US/xml/Common_Content/images/2.png
new file mode 100644
index 00000000000..b95445a4e73
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/2.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/2.svg b/docs/tmp/en-US/xml/Common_Content/images/2.svg
new file mode 100644
index 00000000000..236a8dacbc4
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/2.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/20.png b/docs/tmp/en-US/xml/Common_Content/images/20.png
new file mode 100644
index 00000000000..c30191a3653
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/20.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/20.svg b/docs/tmp/en-US/xml/Common_Content/images/20.svg
new file mode 100644
index 00000000000..d41206eec57
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/20.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/21.png b/docs/tmp/en-US/xml/Common_Content/images/21.png
new file mode 100644
index 00000000000..fa3aa907dcf
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/21.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/21.svg b/docs/tmp/en-US/xml/Common_Content/images/21.svg
new file mode 100644
index 00000000000..b17f23a5a9a
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/21.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/22.png b/docs/tmp/en-US/xml/Common_Content/images/22.png
new file mode 100644
index 00000000000..b724ced1311
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/22.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/22.svg b/docs/tmp/en-US/xml/Common_Content/images/22.svg
new file mode 100644
index 00000000000..22deeb3edbb
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/22.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/23.png b/docs/tmp/en-US/xml/Common_Content/images/23.png
new file mode 100644
index 00000000000..8b69b829282
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/23.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/23.svg b/docs/tmp/en-US/xml/Common_Content/images/23.svg
new file mode 100644
index 00000000000..c0a33eeb0b0
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/23.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/24.png b/docs/tmp/en-US/xml/Common_Content/images/24.png
new file mode 100644
index 00000000000..863ce3b6632
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/24.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/24.svg b/docs/tmp/en-US/xml/Common_Content/images/24.svg
new file mode 100644
index 00000000000..27e1d39c94f
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/24.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/25.png b/docs/tmp/en-US/xml/Common_Content/images/25.png
new file mode 100644
index 00000000000..cc23b9b2b04
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/25.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/25.svg b/docs/tmp/en-US/xml/Common_Content/images/25.svg
new file mode 100644
index 00000000000..114e1a26ba6
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/25.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/26.png b/docs/tmp/en-US/xml/Common_Content/images/26.png
new file mode 100644
index 00000000000..583fe34867d
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/26.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/26.svg b/docs/tmp/en-US/xml/Common_Content/images/26.svg
new file mode 100644
index 00000000000..e9b5d239b55
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/26.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/27.png b/docs/tmp/en-US/xml/Common_Content/images/27.png
new file mode 100644
index 00000000000..d1c3dfa457a
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/27.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/27.svg b/docs/tmp/en-US/xml/Common_Content/images/27.svg
new file mode 100644
index 00000000000..4a80177b68d
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/27.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/28.png b/docs/tmp/en-US/xml/Common_Content/images/28.png
new file mode 100644
index 00000000000..f5db74735d7
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/28.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/28.svg b/docs/tmp/en-US/xml/Common_Content/images/28.svg
new file mode 100644
index 00000000000..d453f299fa2
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/28.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/29.png b/docs/tmp/en-US/xml/Common_Content/images/29.png
new file mode 100644
index 00000000000..9a3141ec42e
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/29.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/29.svg b/docs/tmp/en-US/xml/Common_Content/images/29.svg
new file mode 100644
index 00000000000..04b5c5034fc
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/29.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/3.png b/docs/tmp/en-US/xml/Common_Content/images/3.png
new file mode 100644
index 00000000000..a4754f0615c
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/3.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/3.svg b/docs/tmp/en-US/xml/Common_Content/images/3.svg
new file mode 100644
index 00000000000..e2f17168da1
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/3.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/30.png b/docs/tmp/en-US/xml/Common_Content/images/30.png
new file mode 100644
index 00000000000..9d3db242d90
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/30.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/30.svg b/docs/tmp/en-US/xml/Common_Content/images/30.svg
new file mode 100644
index 00000000000..5cdcf65e846
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/30.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/31.png b/docs/tmp/en-US/xml/Common_Content/images/31.png
new file mode 100644
index 00000000000..9e2675da589
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/31.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/31.svg b/docs/tmp/en-US/xml/Common_Content/images/31.svg
new file mode 100644
index 00000000000..f0fdb294dd8
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/31.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/32.png b/docs/tmp/en-US/xml/Common_Content/images/32.png
new file mode 100644
index 00000000000..20f1bb23c4b
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/32.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/32.svg b/docs/tmp/en-US/xml/Common_Content/images/32.svg
new file mode 100644
index 00000000000..93829281032
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/32.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/33.png b/docs/tmp/en-US/xml/Common_Content/images/33.png
new file mode 100644
index 00000000000..01407e6bcce
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/33.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/33.svg b/docs/tmp/en-US/xml/Common_Content/images/33.svg
new file mode 100644
index 00000000000..f46815f7ea6
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/33.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/34.png b/docs/tmp/en-US/xml/Common_Content/images/34.png
new file mode 100644
index 00000000000..ba443525397
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/34.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/34.svg b/docs/tmp/en-US/xml/Common_Content/images/34.svg
new file mode 100644
index 00000000000..7bbdf5b9ab2
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/34.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/35.png b/docs/tmp/en-US/xml/Common_Content/images/35.png
new file mode 100644
index 00000000000..21d4575cf27
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/35.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/35.svg b/docs/tmp/en-US/xml/Common_Content/images/35.svg
new file mode 100644
index 00000000000..8e19553af20
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/35.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/36.png b/docs/tmp/en-US/xml/Common_Content/images/36.png
new file mode 100644
index 00000000000..b5402b57788
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/36.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/36.svg b/docs/tmp/en-US/xml/Common_Content/images/36.svg
new file mode 100644
index 00000000000..d364dbf51bb
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/36.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/37.png b/docs/tmp/en-US/xml/Common_Content/images/37.png
new file mode 100644
index 00000000000..9fd99d22058
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/37.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/37.svg b/docs/tmp/en-US/xml/Common_Content/images/37.svg
new file mode 100644
index 00000000000..771fa4d110b
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/37.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/38.png b/docs/tmp/en-US/xml/Common_Content/images/38.png
new file mode 100644
index 00000000000..3ce6027f00f
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/38.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/38.svg b/docs/tmp/en-US/xml/Common_Content/images/38.svg
new file mode 100644
index 00000000000..487e0ef3051
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/38.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/39.png b/docs/tmp/en-US/xml/Common_Content/images/39.png
new file mode 100644
index 00000000000..d6894500c24
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/39.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/39.svg b/docs/tmp/en-US/xml/Common_Content/images/39.svg
new file mode 100644
index 00000000000..cea69f715f9
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/39.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/4.png b/docs/tmp/en-US/xml/Common_Content/images/4.png
new file mode 100644
index 00000000000..f6c113563a1
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/4.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/4.svg b/docs/tmp/en-US/xml/Common_Content/images/4.svg
new file mode 100644
index 00000000000..3b537d4a19b
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/4.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/40.png b/docs/tmp/en-US/xml/Common_Content/images/40.png
new file mode 100644
index 00000000000..0d3532e0f3f
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/40.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/40.svg b/docs/tmp/en-US/xml/Common_Content/images/40.svg
new file mode 100644
index 00000000000..bb4e1d7b8fc
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/40.svg
@@ -0,0 +1,31 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/5.png b/docs/tmp/en-US/xml/Common_Content/images/5.png
new file mode 100644
index 00000000000..4ced5472dfc
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/5.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/5.svg b/docs/tmp/en-US/xml/Common_Content/images/5.svg
new file mode 100644
index 00000000000..ec2715dea0b
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/5.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/6.png b/docs/tmp/en-US/xml/Common_Content/images/6.png
new file mode 100644
index 00000000000..22fc272c050
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/6.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/6.svg b/docs/tmp/en-US/xml/Common_Content/images/6.svg
new file mode 100644
index 00000000000..b8062936898
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/6.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/7.png b/docs/tmp/en-US/xml/Common_Content/images/7.png
new file mode 100644
index 00000000000..9b1f20a9816
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/7.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/7.svg b/docs/tmp/en-US/xml/Common_Content/images/7.svg
new file mode 100644
index 00000000000..871e0eff74f
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/7.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/8.png b/docs/tmp/en-US/xml/Common_Content/images/8.png
new file mode 100644
index 00000000000..ac38ae5bffd
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/8.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/8.svg b/docs/tmp/en-US/xml/Common_Content/images/8.svg
new file mode 100644
index 00000000000..10e612f6eb9
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/8.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/9.png b/docs/tmp/en-US/xml/Common_Content/images/9.png
new file mode 100644
index 00000000000..a2972dbc216
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/9.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/9.svg b/docs/tmp/en-US/xml/Common_Content/images/9.svg
new file mode 100644
index 00000000000..c488b6e4fa4
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/9.svg
@@ -0,0 +1,27 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/dot.png b/docs/tmp/en-US/xml/Common_Content/images/dot.png
new file mode 100644
index 00000000000..079add95ded
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/dot.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/dot2.png b/docs/tmp/en-US/xml/Common_Content/images/dot2.png
new file mode 100644
index 00000000000..8348fcd054a
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/dot2.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/green.png b/docs/tmp/en-US/xml/Common_Content/images/green.png
new file mode 100644
index 00000000000..ebb3c247dea
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/green.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/h1-bg.png b/docs/tmp/en-US/xml/Common_Content/images/h1-bg.png
new file mode 100644
index 00000000000..a2aad24b329
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/h1-bg.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/image_left.png b/docs/tmp/en-US/xml/Common_Content/images/image_left.png
new file mode 100644
index 00000000000..2831477642c
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/image_left.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/image_right.png b/docs/tmp/en-US/xml/Common_Content/images/image_right.png
new file mode 100644
index 00000000000..19a6cca5336
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/image_right.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/important.png b/docs/tmp/en-US/xml/Common_Content/images/important.png
new file mode 100644
index 00000000000..969562b7bc7
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/important.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/important.svg b/docs/tmp/en-US/xml/Common_Content/images/important.svg
new file mode 100644
index 00000000000..064c783b538
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/important.svg
@@ -0,0 +1,30 @@
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/note.png b/docs/tmp/en-US/xml/Common_Content/images/note.png
new file mode 100644
index 00000000000..d04775d9905
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/note.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/note.svg b/docs/tmp/en-US/xml/Common_Content/images/note.svg
new file mode 100644
index 00000000000..abe5a602468
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/note.svg
@@ -0,0 +1,28 @@
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/red.png b/docs/tmp/en-US/xml/Common_Content/images/red.png
new file mode 100644
index 00000000000..d32d5e2e80a
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/red.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/shine.png b/docs/tmp/en-US/xml/Common_Content/images/shine.png
new file mode 100644
index 00000000000..a18f7c4612e
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/shine.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/stock-go-back.png b/docs/tmp/en-US/xml/Common_Content/images/stock-go-back.png
new file mode 100644
index 00000000000..00850b21b23
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/stock-go-back.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/stock-go-forward.png b/docs/tmp/en-US/xml/Common_Content/images/stock-go-forward.png
new file mode 100644
index 00000000000..cc2797a4686
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/stock-go-forward.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/stock-go-up.png b/docs/tmp/en-US/xml/Common_Content/images/stock-go-up.png
new file mode 100644
index 00000000000..1ebf2799c35
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/stock-go-up.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/stock-home.png b/docs/tmp/en-US/xml/Common_Content/images/stock-home.png
new file mode 100644
index 00000000000..3f0c1906343
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/stock-home.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/title_logo.png b/docs/tmp/en-US/xml/Common_Content/images/title_logo.png
new file mode 100644
index 00000000000..58a1b56cfe8
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/title_logo.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/title_logo.svg b/docs/tmp/en-US/xml/Common_Content/images/title_logo.svg
new file mode 100644
index 00000000000..e8b3eca8d82
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/title_logo.svg
@@ -0,0 +1,335 @@
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml/Common_Content/images/warning.png b/docs/tmp/en-US/xml/Common_Content/images/warning.png
new file mode 100644
index 00000000000..94b69d1ff1f
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/warning.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/warning.svg b/docs/tmp/en-US/xml/Common_Content/images/warning.svg
new file mode 100644
index 00000000000..4231e5ac041
--- /dev/null
+++ b/docs/tmp/en-US/xml/Common_Content/images/warning.svg
@@ -0,0 +1,130 @@
+
+
+
diff --git a/docs/tmp/en-US/xml/Common_Content/images/watermark-draft.png b/docs/tmp/en-US/xml/Common_Content/images/watermark-draft.png
new file mode 100644
index 00000000000..0ead5af8bb8
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/watermark-draft.png differ
diff --git a/docs/tmp/en-US/xml/Common_Content/images/yellow.png b/docs/tmp/en-US/xml/Common_Content/images/yellow.png
new file mode 100644
index 00000000000..223865d77fa
Binary files /dev/null and b/docs/tmp/en-US/xml/Common_Content/images/yellow.png differ
diff --git a/docs/tmp/en-US/xml/Installation_Guide.ent b/docs/tmp/en-US/xml/Installation_Guide.ent
new file mode 100644
index 00000000000..abb18851bcf
--- /dev/null
+++ b/docs/tmp/en-US/xml/Installation_Guide.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Installation_Guide.fo b/docs/tmp/en-US/xml/Installation_Guide.fo
new file mode 100644
index 00000000000..2ec326cd421
--- /dev/null
+++ b/docs/tmp/en-US/xml/Installation_Guide.fo
@@ -0,0 +1,4280 @@
+
+CloudStack Installation GuideDocBook XSL Stylesheets with Apache FOPCloudStack Installation GuideTable of ContentsChapter 1. Concepts1.1. What Is CloudStack?1.2. What Can CloudStack Do?1.3. Deployment Architecture Overview1.3.1. Management Server Overview1.3.2. Cloud Infrastructure Overview1.3.3. Networking OverviewChapter 2. Cloud Infrastructure Concepts2.1. About Zones2.2. About Pods2.3. About Clusters2.4. About Hosts2.5. About Primary Storage2.6. About Secondary Storage2.7. About Physical Networks2.7.1. Configurable Characteristics of Physical Networks2.7.2. Basic Zone Network Traffic Types2.7.3. Basic Zone Guest IP Addresses2.7.4. Advanced Zone Network Traffic Types2.7.5. Advanced Zone Guest IP Addresses2.7.6. Advanced Zone Public IP Addresses2.7.7. System Reserved IP AddressesChapter 3. Building from Source3.1. Getting the release3.2. Verifying the downloaded release3.2.1. Getting the KEYS3.2.2. GPG3.2.3. MD53.2.4. SHA5123.3. Prerequisites for building Apache CloudStack3.4. Extracting source3.5. Building DEB packages3.5.1. Setting up an APT repo3.5.2. Configuring your machines to use the APT repository3.6. Building RPMs3.6.1. Creating a yum repo3.6.2. Configuring your systems to use your new yum repositoryChapter 4. Installation4.1. Who Should Read This4.2. Overview of Installation Steps4.3. Minimum System Requirements4.3.1. Management Server, Database, and Storage System Requirements4.3.2. Host/Hypervisor System Requirements4.4. Configure package repository4.4.1. DEB package repository4.4.2. RPM package repository4.5. Management Server Installation4.5.1. Management Server Installation Overview4.5.2. Prepare the Operating System4.5.3. Install the Management Server on the First Host4.5.3.1. Downloading vhd-util4.5.3.2. Install on CentOS/RHEL4.5.3.3. Install on Ubuntu4.5.4. Install the database server4.5.4.1. Install the Database on the Management Server Node4.5.4.2. Install the Database on a Separate Node4.5.5. Prepare NFS Shares4.5.5.1. Using a Separate NFS Server4.5.5.2. Using the Management Server As the NFS Server4.5.6. Prepare and Start Additional Management Servers4.5.7. Prepare the System VM Template4.5.8. Installation Complete! Next StepsChapter 5. User Interface5.1. Log In to the UI5.1.1. End User's UI Overview5.1.2. Root Administrator's UI Overview5.1.3. Logging In as the Root Administrator5.1.4. Changing the Root Password5.2. Using SSH Keys for Authentication5.2.1. Creating an Instance Template that Supports SSH Keys5.2.2. Creating the SSH Keypair5.2.3. Creating an Instance5.2.4. Logging In Using the SSH KeypairChapter 6. Steps to Provisioning Your Cloud Infrastructure6.1. Overview of Provisioning Steps6.2. Adding a Zone6.2.1. Basic Zone Configuration6.2.2. Advanced Zone Configuration6.3. Adding a Pod6.4. Adding a Cluster6.4.1. Add Cluster: KVM or XenServer6.4.2. Add Cluster: vSphere6.5. Adding a Host6.5.1. Adding a Host (XenServer or KVM)6.5.1.1. Requirements for XenServer and KVM Hosts6.5.1.1.1. XenServer Host Additional Requirements6.5.1.1.2. KVM Host Additional Requirements6.5.1.2. Adding a XenServer or KVM Host6.5.2. Adding a Host (vSphere)6.6. Add Primary Storage6.6.1. System Requirements for Primary Storage6.6.2. Adding Primary Stroage6.7. Add Secondary Storage6.7.1. System Requirements for Secondary Storage6.7.2. Adding Secondary Storage6.8. Initialize and TestChapter 7. Setting Global Configuration ParametersChapter 8. Hypervisor Installation8.1. KVM Hypervisor Host Installation8.1.1. System Requirements for KVM Hypervisor Hosts8.1.2. KVM Installation Overview8.1.3. Prepare the Operating System8.1.4. Install and configure the Agent8.1.5. Install and Configure libvirt8.1.6. Configure the Security Policies8.1.7. Configure the network bridges8.1.7.1. Network example8.1.7.2. Configuring the network bridges8.1.7.2.1. Configure in RHEL or CentOS8.1.7.2.2. Configure in Ubuntu8.1.8. Configuring the firewall8.1.8.1. Open ports in RHEL/CentOS8.1.8.2. Open ports in Ubuntu8.1.9. Add the host to CloudStack8.2. Citrix XenServer Installation for CloudStack8.2.1. System Requirements for XenServer Hosts8.2.2. XenServer Installation Steps8.2.3. Configure XenServer dom0 Memory8.2.4. Username and Password8.2.5. Time Synchronization8.2.6. Licensing8.2.6.1. Getting and Deploying a License8.2.7. Install CloudStack XenServer Support Package (CSP)8.2.8. Primary Storage Setup for XenServer8.2.9. iSCSI Multipath Setup for XenServer (Optional)8.2.10. Physical Networking Setup for XenServer8.2.10.1. Configuring Public Network with a Dedicated NIC for XenServer (Optional)8.2.10.2. Configuring Multiple Guest Networks for XenServer (Optional)8.2.10.3. Separate Storage Network for XenServer (Optional)8.2.10.4. NIC Bonding for XenServer (Optional)8.2.10.4.1. Management Network Bonding8.2.10.4.2. Creating a Private Bond on the First Host in the Cluster8.2.10.4.3. Public Network Bonding8.2.10.4.4. Creating a Public Bond on the First Host in the Cluster8.2.10.4.5. Adding More Hosts to the Cluster8.2.10.4.6. Complete the Bonding Setup Across the Cluster8.2.11. Upgrading XenServer Versions8.3. VMware vSphere Installation and Configuration8.3.1. System Requirements for vSphere Hosts8.3.1.1. Software requirements:8.3.1.2. Hardware requirements:8.3.1.3. vCenter Server requirements:8.3.1.4. Other requirements:8.3.2. Preparation Checklist for VMware8.3.2.1. vCenter Checklist8.3.2.2. Networking Checklist for VMware8.3.3. vSphere Installation Steps8.3.4. ESXi Host setup8.3.5. Physical Host Networking8.3.5.1. Configure Virtual Switch8.3.5.1.1. Separating Traffic8.3.5.1.2. Increasing Ports8.3.5.2. Configure vCenter Management Network8.3.5.3. Extend Port Range for CloudStack Console Proxy8.3.5.4. Configure NIC Bonding for vSphere8.3.6. Storage Preparation for vSphere (iSCSI only)8.3.6.1. Enable iSCSI initiator for ESXi hosts8.3.6.2. Add iSCSI target8.3.6.3. Create an iSCSI datastore8.3.6.4. Multipathing for vSphere (Optional)8.3.7. Add Hosts or Configure Clusters (vSphere)Chapter 9. Choosing a Deployment Architecture9.1. Small-Scale Deployment9.2. Large-Scale Redundant Setup9.3. Separate Storage Network9.4. Multi-Node Management Server9.5. Multi-Site DeploymentChapter 10. Amazon Web Service Interface Compatibility10.1. Amazon Web Services EC2 Compatible Interface10.2. System Requirements10.3. Enabling the AWS API Compatible Interface10.4. AWS API User Setup Steps10.4.1. AWS API User Registration10.4.2. AWS API Command-Line Tools Setup10.5. Using Timeouts to Ensure AWS API Command Completion10.6. Supported AWS API CallsChapter 11. Managing Networks and Traffic11.1. Guest Traffic11.2. Networking in a Pod11.3. Networking in a Zone11.4. Basic Zone Physical Network Configuration11.5. Advanced Zone Physical Network Configuration11.5.1. Configure Guest Traffic in an Advanced Zone11.5.2. Configure Public Traffic in an Advanced Zone11.6. Using Multiple Guest Networks11.6.1. Adding an Additional Guest Network11.6.2. Changing the Network Offering on a Guest Network11.7. Security Groups11.7.1. About Security Groups11.7.2. Adding a Security Group11.7.3. Enabling Security Groups11.7.4. Adding Ingress and Egress Rules to a Security Group11.8. External Firewalls and Load Balancers11.9. Load Balancer Rules11.10. Guest IP Ranges11.11. Acquiring a New IP Address11.12. Releasing an IP Address11.13. Static NAT11.14. IP Forwarding and Firewalling11.15. IP Load Balancing11.16. DNS and DHCP11.17. VPN11.17.1. Configuring VPN11.17.2. Using VPN with Windows11.17.3. Using VPN with Mac OS X11.17.4. Setting Up a Site-to-Site VPN Connection11.17.4.1. Creating and Updating a VPN Customer Gateway11.17.4.2. Creating a VPN gateway for the VPC11.17.4.3. Creating a VPN Connection11.17.4.4. Restarting and Removing a VPN Connection11.18. About Inter-VLAN Routing11.19. Configuring a Virtual Private Cloud11.19.1. About Virtual Private Clouds11.19.2. Adding a Virtual Private Cloud11.19.3. Adding Tiers11.19.4. Configuring Access Control List11.19.5. Adding a Private Gateway to a VPC11.19.6. Deploying VMs to the Tier11.19.7. Acquiring a New IP Address for a VPC11.19.8. Releasing an IP Address Alloted to a VPC11.19.9. Enabling or Disabling Static NAT on a VPC11.19.10. Adding Load Balancing Rules on a VPC11.19.11. Adding a Port Forwarding Rule on a VPC11.19.12. Removing Tiers11.19.13. Editing, Restarting, and Removing a Virtual Private CloudAppendix A. Revision HistoryCloudStack Installation GuideApache CloudStack 4.0.0-incubatingCloudStack Installation Guide
+
+
+ Apache CloudStackApache CloudStack 4.0.0-incubating CloudStack Installation GuideAuthorApache CloudStack
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+ Installation Guide for CloudStack.
+ CloudStack Installation Guide1. Concepts1.1. What Is CloudStack?1.2. What Can CloudStack Do?1.3. Deployment Architecture Overview1.3.1. Management Server Overview1.3.2. Cloud Infrastructure Overview1.3.3. Networking Overview2. Cloud Infrastructure Concepts2.1. About Zones2.2. About Pods2.3. About Clusters2.4. About Hosts2.5. About Primary Storage2.6. About Secondary Storage2.7. About Physical Networks2.7.1. Configurable Characteristics of Physical Networks2.7.2. Basic Zone Network Traffic Types2.7.3. Basic Zone Guest IP Addresses2.7.4. Advanced Zone Network Traffic Types2.7.5. Advanced Zone Guest IP Addresses2.7.6. Advanced Zone Public IP Addresses2.7.7. System Reserved IP Addresses3. Building from Source3.1. Getting the release3.2. Verifying the downloaded release3.2.1. Getting the KEYS3.2.2. GPG3.2.3. MD53.2.4. SHA5123.3. Prerequisites for building Apache CloudStack3.4. Extracting source3.5. Building DEB packages3.5.1. Setting up an APT repo3.5.2. Configuring your machines to use the APT repository3.6. Building RPMs3.6.1. Creating a yum repo3.6.2. Configuring your systems to use your new yum repository4. Installation4.1. Who Should Read This4.2. Overview of Installation Steps4.3. Minimum System Requirements4.3.1. Management Server, Database, and Storage System Requirements4.3.2. Host/Hypervisor System Requirements4.4. Configure package repository4.4.1. DEB package repository4.4.2. RPM package repository4.5. Management Server Installation4.5.1. Management Server Installation Overview4.5.2. Prepare the Operating System4.5.3. Install the Management Server on the First Host4.5.4. Install the database server4.5.5. Prepare NFS Shares4.5.6. Prepare and Start Additional Management Servers4.5.7. Prepare the System VM Template4.5.8. Installation Complete! Next Steps5. User Interface5.1. Log In to the UI5.1.1. End User's UI Overview5.1.2. Root Administrator's UI Overview5.1.3. Logging In as the Root Administrator5.1.4. Changing the Root Password5.2. Using SSH Keys for Authentication5.2.1. Creating an Instance Template that Supports SSH Keys5.2.2. Creating the SSH Keypair5.2.3. Creating an Instance5.2.4. Logging In Using the SSH Keypair6. Steps to Provisioning Your Cloud Infrastructure6.1. Overview of Provisioning Steps6.2. Adding a Zone6.2.1. Basic Zone Configuration6.2.2. Advanced Zone Configuration6.3. Adding a Pod6.4. Adding a Cluster6.4.1. Add Cluster: KVM or XenServer6.4.2. Add Cluster: vSphere6.5. Adding a Host6.5.1. Adding a Host (XenServer or KVM)6.5.2. Adding a Host (vSphere)6.6. Add Primary Storage6.6.1. System Requirements for Primary Storage6.6.2. Adding Primary Stroage6.7. Add Secondary Storage6.7.1. System Requirements for Secondary Storage6.7.2. Adding Secondary Storage6.8. Initialize and Test7. Setting Global Configuration Parameters8. Hypervisor Installation8.1. KVM Hypervisor Host Installation8.1.1. System Requirements for KVM Hypervisor Hosts8.1.2. KVM Installation Overview8.1.3. Prepare the Operating System8.1.4. Install and configure the Agent8.1.5. Install and Configure libvirt8.1.6. Configure the Security Policies8.1.7. Configure the network bridges8.1.8. Configuring the firewall8.1.9. Add the host to CloudStack8.2. Citrix XenServer Installation for CloudStack8.2.1. System Requirements for XenServer Hosts8.2.2. XenServer Installation Steps8.2.3. Configure XenServer dom0 Memory8.2.4. Username and Password8.2.5. Time Synchronization8.2.6. Licensing8.2.7. Install CloudStack XenServer Support Package (CSP)8.2.8. Primary Storage Setup for XenServer8.2.9. iSCSI Multipath Setup for XenServer (Optional)8.2.10. Physical Networking Setup for XenServer8.2.11. Upgrading XenServer Versions8.3. VMware vSphere Installation and Configuration8.3.1. System Requirements for vSphere Hosts8.3.2. Preparation Checklist for VMware8.3.3. vSphere Installation Steps8.3.4. ESXi Host setup8.3.5. Physical Host Networking8.3.6. Storage Preparation for vSphere (iSCSI only)8.3.7. Add Hosts or Configure Clusters (vSphere)9. Choosing a Deployment Architecture9.1. Small-Scale Deployment9.2. Large-Scale Redundant Setup9.3. Separate Storage Network9.4. Multi-Node Management Server9.5. Multi-Site Deployment10. Amazon Web Service Interface Compatibility10.1. Amazon Web Services EC2 Compatible Interface10.2. System Requirements10.3. Enabling the AWS API Compatible Interface10.4. AWS API User Setup Steps10.4.1. AWS API User Registration10.4.2. AWS API Command-Line Tools Setup10.5. Using Timeouts to Ensure AWS API Command Completion10.6. Supported AWS API Calls11. Managing Networks and Traffic11.1. Guest Traffic11.2. Networking in a Pod11.3. Networking in a Zone11.4. Basic Zone Physical Network Configuration11.5. Advanced Zone Physical Network Configuration11.5.1. Configure Guest Traffic in an Advanced Zone11.5.2. Configure Public Traffic in an Advanced Zone11.6. Using Multiple Guest Networks11.6.1. Adding an Additional Guest Network11.6.2. Changing the Network Offering on a Guest Network11.7. Security Groups11.7.1. About Security Groups11.7.2. Adding a Security Group11.7.3. Enabling Security Groups11.7.4. Adding Ingress and Egress Rules to a Security Group11.8. External Firewalls and Load Balancers11.9. Load Balancer Rules11.10. Guest IP Ranges11.11. Acquiring a New IP Address11.12. Releasing an IP Address11.13. Static NAT11.14. IP Forwarding and Firewalling11.15. IP Load Balancing11.16. DNS and DHCP11.17. VPN11.17.1. Configuring VPN11.17.2. Using VPN with Windows11.17.3. Using VPN with Mac OS X11.17.4. Setting Up a Site-to-Site VPN Connection11.18. About Inter-VLAN Routing11.19. Configuring a Virtual Private Cloud11.19.1. About Virtual Private Clouds11.19.2. Adding a Virtual Private Cloud11.19.3. Adding Tiers11.19.4. Configuring Access Control List11.19.5. Adding a Private Gateway to a VPC11.19.6. Deploying VMs to the Tier11.19.7. Acquiring a New IP Address for a VPC11.19.8. Releasing an IP Address Alloted to a VPC11.19.9. Enabling or Disabling Static NAT on a VPC11.19.10. Adding Load Balancing Rules on a VPC11.19.11. Adding a Port Forwarding Rule on a VPC11.19.12. Removing Tiers11.19.13. Editing, Restarting, and Removing a Virtual Private CloudA. Revision HistoryChapter 1.Chapter 1. ConceptsConceptsWhat Is CloudStack?1.1. What Is CloudStack?
+ CloudStack is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. CloudStack manages the network, storage, and compute nodes that make up a cloud infrastructure. Use CloudStack to deploy, manage, and configure cloud computing environments.
+
+ Typical users are service providers and enterprises. With CloudStack, you can:
+ •
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+ •
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with CloudStack an enterprise can offer self-service virtual machines to users without involving IT departments.
+ What Can CloudStack Do?1.2. What Can CloudStack Do?
+ Multiple Hypervisor Support
+
+ CloudStack works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of CloudStack supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+ Massively Scalable Infrastructure Management
+
+ CloudStack can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+ Automatic Configuration Management
+
+ CloudStack automatically configures each guest virtual machine’s networking and storage settings.
+
+ CloudStack internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+ Graphical User Interface
+
+ CloudStack offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+ API and Extensibility
+
+ CloudStack provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at Apache CloudStack Guides11http://incubator.apache.org/cloudstack/docs and Apache CloudStack API Reference22http://incubator.apache.org/cloudstack/docs/api respectively.
+
+ The CloudStack pluggable allocation architecture allows the creation of new types of allocators for the selection of storage and Hosts. See the Allocator Implementation Guide (http://docs.cloudstack.org/CloudStack_Documentation/Allocator_Implementation_Guide).
+
+ High Availability
+
+ CloudStack has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the hosts, CloudStack supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+ Deployment Architecture Overview1.3. Deployment Architecture Overview
+ A CloudStack installation consists of two parts: the Management Server and the cloud infrastructure that it manages. When you set up and manage a CloudStack cloud, you provision resources such as hosts, storage devices, and IP addresses into the Management Server, and the Management Server manages those resources.
+
+ The minimum production installation consists of one machine running the CloudStack Management Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure consisting of one host running hypervisor software). In its smallest deployment, a single machine can act as both the Management Server and the hypervisor host (using the KVM hypervisor).
+
+ A more full-featured installation consists of a highly-available multi-node Management Server installation and up to tens of thousands of hosts using any of several advanced networking setups. For information about deployment options, see Choosing a Deployment Architecture.
+ Management Server Overview1.3.1. Management Server Overview
+ The Management Server is the CloudStack software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+ The machine must meet the system requirements described in System Requirements.
+
+ The Management Server:
+ •
+ Provides the web user interface for the administrator and a reference user interface for end users.
+ •
+ Provides the APIs for CloudStack.
+ •
+ Manages the assignment of guest VMs to particular hosts.
+ •
+ Manages the assignment of public and private IP addresses to particular accounts.
+ •
+ Manages the allocation of storage to guests as virtual disks.
+ •
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+ •
+ Provides a single point of configuration for the cloud.
+ Cloud Infrastructure Overview1.3.2. Cloud Infrastructure Overview
+ The Management Server manages one or more zones (typically, datacenters) containing host computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
+ •
+ Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
+ •
+ Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
+ •
+ Cluster: A cluster consists of one or more hosts and primary storage.
+ •
+ Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines.
+ •
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster.
+ •
+ Secondary storage is associated with a zone, and it stores templates, ISO images, and disk volume snapshots.
+
+ More Information
+
+ For more information, see documentation on cloud infrastructure concepts.
+ Networking Overview1.3.3. Networking Overview
+ CloudStack offers two types of networking scenario:
+ •
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+ •
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+ For more details, see Network Setup.
+ Chapter 2.Chapter 2. Cloud Infrastructure ConceptsCloud Infrastructure ConceptsAbout Zones2.1. About Zones
+ A zone is the largest organizational unit within a CloudStack deployment. A zone typically corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter. The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required).
+
+ A zone consists of:
+ •
+ One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
+ •
+ Secondary storage, which is shared by all the pods in the zone.
+
+ Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones.
+
+ Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone.
+
+ Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels.
+
+ For each zone, the administrator must decide the following.
+ •
+ How many pods to place in a zone.
+ •
+ How many clusters to place in each pod.
+ •
+ How many hosts to place in each cluster.
+ •
+ How many primary storage servers to place in each cluster and total capacity for the storage servers.
+ •
+ How much secondary storage to deploy in 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.
+ About Pods2.2. About Pods
+ A pod often represents a single rack. Hosts in the same pod are in the same subnet.
+
+ A pod is the second-largest organizational unit within a CloudStack deployment. Pods are contained within zones. Each zone can contain one or more pods.
+
+ Pods are not visible to the end user.
+
+ A pod consists of one or more clusters of hosts and one or more primary storage servers.
+ About Clusters2.3. About Clusters
+ A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set of KVM servers, , or a VMware cluster preconfigured in vCenter. The hosts in a cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the same shared primary storage. Virtual machine instances (VMs) can be live-migrated from one host to another within the same cluster, without interrupting service to the user.
+
+ A cluster is the third-largest organizational unit within a CloudStack deployment. Clusters are contained within pods, and pods are contained within zones. Size of the cluster is limited by the underlying hypervisor, although the CloudStack recommends less in most cases; see Best Practices.
+
+ A cluster consists of one or more hosts and one or more primary storage servers.
+
+ CloudStack allows multiple clusters in a cloud deployment.
+
+ Even when local storage is used exclusively, clusters are still required organizationally, even if there is just one host per cluster.
+
+ When VMware is used, every VMware cluster is managed by a vCenter server. Administrator must register the vCenter server with CloudStack. There may be multiple vCenter servers per zone. Each vCenter server may manage multiple VMware clusters.
+ About Hosts2.4. About Hosts
+ A host is a single computer. Hosts provide the computing resources that run the guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a Linux KVM-enabled server, a Citrix XenServer server, and an ESXi server are hosts.
+
+ The host is the smallest organizational unit within a CloudStack deployment. Hosts are contained within clusters, clusters are contained within pods, and pods are contained within zones.
+
+ Hosts in a CloudStack deployment:
+ •
+ Provide the CPU, memory, storage, and networking resources needed to host the virtual machines
+ •
+ Interconnect using a high bandwidth TCP/IP network and connect to the Internet
+ •
+ May reside in multiple data centers across different geographic locations
+ •
+ May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the hosts within a cluster must all be homogeneous
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs.
+
+ CloudStack automatically detects the amount of CPU and memory resources provided by the Hosts.
+
+ Hosts are not visible to the end user. An end user cannot determine which host their guest has been assigned to.
+
+ For a host to function in CloudStack, you must do the following:
+ •
+ Install hypervisor software on the host
+ •
+ Assign an IP address to the host
+ •
+ Ensure the host is connected to the CloudStack Management Server
+ About Primary Storage2.5. About Primary Storage
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required. It is typically located close to the hosts for increased performance.
+
+ CloudStack is designed to work with all standards-compliant iSCSI and NFS servers that are supported by the underlying hypervisor, including, for example:
+ •
+ Dell EqualLogic™ for iSCSI
+ •
+ Network Appliances filers for NFS and iSCSI
+ •
+ Scale Computing for NFS
+
+ If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.
+ About Secondary Storage2.6. About Secondary Storage
+ Secondary storage is associated with a zone, and it stores the following:
+ •
+ Templates — OS images that can be used to boot VMs and can include additional configuration information, such as installed applications
+ •
+ ISO images — disc images containing data or bootable media for operating systems
+ •
+ Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
+
+ The items in zone-based NFS secondary storage are available to all hosts in the zone. CloudStack manages the allocation of guest virtual disks to particular primary storage devices.
+
+ To make items in secondary storage available to all hosts throughout the cloud, you can add OpenStack Object Storage (Swift, swift.openstack.org11http://swift.openstack.org) in addition to the zone-based NFS secondary storage. When using Swift, you configure Swift storage for the entire CloudStack, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere.
+ About Physical Networks2.7. About Physical Networks
+ Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical networks can be associated with each zone. The network corresponds to a NIC on the hypervisor host. Each physical network can carry one or more types of network traffic. The choices of traffic type for each network vary depending on whether you are creating a zone with basic networking or advanced networking.
+
+ A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can:
+ •
+ Add/Remove/Update physical networks in a zone
+ •
+ Configure VLANs on the physical network
+ •
+ Configure a name so the network can be recognized by hypervisors
+ •
+ Configure the service providers (firewalls, load balancers, etc.) available on a physical network
+ •
+ Configure the IP addresses trunked to a physical network
+ •
+ Specify what type of traffic is carried on the physical network, as well as other properties like network speed
+ Configurable Characteristics of Physical Networks2.7.1. Configurable Characteristics of Physical Networks
+ CloudStack provides configuration settings you can use to set up a physical network in a zone, including:
+ •
+ What type of network traffic it carries (guest, public, management, storage)
+ •
+ VLANs
+ •
+ Unique name that the hypervisor can use to find that particular network
+ •
+ Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator sets the physical network to enabled, and it begins to be used. The administrator can later disable the network again, which prevents any new virtual networks from being created on that physical network; the existing network traffic continues even though the state is disabled.
+ •
+ Speed
+ •
+ Tags, so network offerings can be matched to physical networks
+ •
+ Isolation method
+ Basic Zone Network Traffic Types2.7.2. Basic Zone Network Traffic Types
+ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types:
+ •
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod.
+ •
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+ Note
+ We strongly recommend the use of separate NICs for management traffic and guest traffic.
+ •
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address.
+ •
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. CloudStack takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.
+ Basic Zone Guest IP Addresses2.7.3. Basic Zone Guest IP Addresses
+ When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts.
+ Advanced Zone Network Traffic Types2.7.4. Advanced Zone Network Traffic Types
+ When advanced networking is used, there can be multiple physical networks in the zone. Each physical network can carry one or more traffic types, and you need to let CloudStack know which type of network traffic you want each network to carry. The traffic types in an advanced zone are:
+ •
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each CloudStack account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network.
+ •
+ Management. When CloudStack’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by CloudStack to perform various tasks in the cloud), and any other component that communicates directly with the CloudStack Management Server. You must configure the IP range for the system VMs to use.
+ •
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the CloudStack UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide.
+ •
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. CloudStack uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices.
+ Advanced Zone Guest IP Addresses2.7.5. Advanced Zone Guest IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+ Advanced Zone Public IP Addresses2.7.6. Advanced Zone Public IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+ System Reserved IP Addresses2.7.7. System Reserved IP Addresses
+ In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the CloudStack Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
+
+ The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone.
+
+ The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in.
+
+ Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. CloudStack can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
+
+ In all zones:
+
+ Provide private IPs for the system in each pod and provision them in CloudStack.
+
+ For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.
+
+ In a zone that uses advanced networking:
+
+ For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required CloudStack System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.
+
+ When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
+
+ To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:
+ •
+ Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than 4,000 IP addresses.
+ •
+ Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod has 255 IPs, this will provide 2,550 IP addresses.
+ Chapter 3.Chapter 3. Building from SourceBuilding from Source
+ The official CloudStack release is always in source code form. While there may exist convenience binaries in various forms from a number of places, the source is the canonical release will be source. In this document we'll cover acquiring the source release, building that into binary, deployable packages.
+
+ While building and deploying directly from source is certainly possible, the reality of Infrastructure-as-a-Service cloud computing implies a need to deploy packages on a potentially large number of systems, which RPMs and DEBs fill nicely.
+
+ Building and deploying directly from source is thus outside the scope of this document, but is documented in the INSTALL.md file in the release.
+ Getting the release3.1. Getting the release
+ You can download the latest CloudStack release from the Apache CloudStack project download page11http://incubator.apache.org/cloudstack/downloads.html.
+
+ You'll notice several links under the 'Latest release' section.
+ 1.
+ apache-cloudstack-4.0.0-incubating-src.tar.bz222http://www.apache.org/dyn/closer.cgi/dist/incubator/cloudstack/releases/4.0.0-incubating/apache-cloudstack-4.0.0-incubating-src.tar.bz2 - This is the link to the release itself.
+ 2.
+ PGP33http://www.apache.org/dist/incubator/cloudstack/releases/4.0.0-incubating/apache-cloudstack-4.0.0-incubating-src.tar.bz2.asc - This is a detached cryptographic signature that can be used to help verify the authenticity of the release.
+ 3.
+ MD544http://www.apache.org/dist/incubator/cloudstack/releases/4.0.0-incubating/apache-cloudstack-4.0.0-incubating-src.tar.bz2.md5 - An MD5 hash of the release to aid in verify the validity of the release download.
+ 4.
+ SHA51255http://www.apache.org/dist/incubator/cloudstack/releases/4.0.0-incubating/apache-cloudstack-4.0.0-incubating-src.tar.bz2.sha - A SHA512 hash of the release to aid in verify the validity of the release download.
+ Verifying the downloaded release3.2. Verifying the downloaded release
+ There are a number of mechanisms to check the authenticity and validity of a downloaded release.
+ Getting the KEYS3.2.1. Getting the KEYS
+ To enable you to verify the GPG signature, you will need to download the KEYS66http://www.apache.org/dist/dev/incubator/cloudstack/KEYS file.
+
+ You next need to import those keys, which you can do by running the following command:
+#gpg --import KEYS
+
+ GPG3.2.2. GPG
+ The CloudStack project provides a detached GPG signature of the release. To check the signature, run the following command:
+$gpg --verify apache-cloudstack-4.0.0-incubating-src.tar.bz2.asc
+
+
+ If the signature is valid you will see a line of output that contains 'Good signature'.
+ MD53.2.3. MD5
+ In addition to the cryptographic signature, the CloudStack provides a number of cryptographic hashes to aid in assurance of validity of the downloaded release. You can verify this hash by executing the following command:
+$gpg --print-md MD5 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.md5
+
+
+ If this successfully completes you should see no output. If there is any output from them, then there is a difference between the hash you generated locally and the hash that has been pulled from the server.
+ SHA5123.2.4. SHA512
+ In addition to the MD5 hash, the CloudStack project provides a SHA512 cryptographic hash to aid in assurance of the validity of the downloaded release. You can verify this hash by executing the following command:
+$gpg --print-md SHA512 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.sha
+
+
+ If this command successfully completes you should see no output. If there is any output from them, then there is a difference between the hash you generated locally and the hash that has been pulled from the server.
+ Prerequisites for building Apache CloudStack3.3. Prerequisites for building Apache CloudStack
+ There are a number of prerequisites needed to build CloudStack. This document assumes compilation on a Linux system that uses RPMs or DEBs for package management.
+
+ The minimum bootstrapped prerequisites for building CloudStack includes the following:
+ 1.
+ ant
+ 2.
+ maven (version 3)
+ 3.
+ Java (Java 6/OpenJDK 1.6)
+ 4.
+ rpmbuild or dpkg-dev
+
+
+ Extracting source3.4. Extracting source
+ Extracting the CloudStack release is relatively simple and can be done with a single command as follows:
+$tar -jxvf apache-cloudstack-4.0.0-incubating-src.tar.bz2
+
+
+ You can now move into the directory:
+$cd ./apache-cloudstack-4.0.0-incubating-src
+
+ Building DEB packages3.5. Building DEB packages
+ In addition to the bootstrap dependencies, you'll also need to install several other dependencies. Note that we recommend using Maven 3, which is not currently available in 12.04.1 LTS. So, you'll also need to add a PPA repository that includes Maven 3. After running the command add-apt-repository, you will be prompted to continue and a GPG key will be added.
+
+$ sudo apt-get update
+$ sudo apt-get install python-software-properties
+$ sudo add-apt-repository ppa:natecarlson/maven3
+$ sudo apt-get update
+$ sudo apt-get install ant debhelper openjdk-6-jdk tomcat6 libws-commons-util-java genisoimage python-mysqldb libcommons-codec-java libcommons-httpclient-java liblog4j1.2-java maven3
+ While we have defined, and you have presumably already installed the bootstrap prerequisites, there are a number of build time prerequisites that need to be resolved. CloudStack uses maven for dependency resolution. You can resolve the buildtime depdencies for CloudStack by running:
+ $ mvn3 -P deps
+ Now that we have resolved the dependencies we can move on to building CloudStack and packaging them into DEBs by issuing the following command.
+
+$ dpkg-buildpackge -uc -us
+ This command will build 16 Debian packages. You should have all of the following:
+
+cloud-agent_4.0.0-incubating_amd64.deb
+cloud-agent-deps_4.0.0-incubating_amd64.deb
+cloud-agent-libs_4.0.0-incubating_amd64.deb
+cloud-awsapi_4.0.0-incubating_amd64.deb
+cloud-cli_4.0.0-incubating_amd64.deb
+cloud-client_4.0.0-incubating_amd64.deb
+cloud-client-ui_4.0.0-incubating_amd64.deb
+cloud-core_4.0.0-incubating_amd64.deb
+cloud-deps_4.0.0-incubating_amd64.deb
+cloud-python_4.0.0-incubating_amd64.deb
+cloud-scripts_4.0.0-incubating_amd64.deb
+cloud-server_4.0.0-incubating_amd64.deb
+cloud-setup_4.0.0-incubating_amd64.deb
+cloud-system-iso_4.0.0-incubating_amd64.deb
+cloud-usage_4.0.0-incubating_amd64.deb
+cloud-utils_4.0.0-incubating_amd64.deb
+Setting up an APT repo3.5.1. Setting up an APT repo
+ After you've created the packages, you'll want to copy them to a system where you can serve the packages over HTTP. You'll create a directory for the packages and then use dpkg-scanpackages to create Packages.gz, which holds information about the archive structure. Finally, you'll add the repository to your system(s) so you can install the packages using APT.
+
+ The first step is to make sure that you have the dpkg-dev package installed. This should have been installed when you pulled in the debhelper application previously, but if you're generating Packages.gz on a different system, be sure that it's installed there as well.
+ $ sudo apt-get install dpkg-dev
+ The next step is to copy the DEBs to the directory where they can be served over HTTP. We'll use /var/www/cloudstack/repo in the examples, but change the directory to whatever works for you.
+
+sudo mkdir -p /var/www/cloudstack/repo/binary
+sudo cp *.deb /var/www/cloudstack/repo/binary
+sudo cd /var/www/cloudstack/repo/binary
+sudo dpkg-scanpackages . /dev/null | tee Packages | gzip -9 > Packages.gzNote: Override Files
+ You can safely ignore the warning about a missing override file.
+
+ Now you should have all of the DEB packages and Packages.gz in the binary directory and available over HTTP. (You may want to use wget or curl to test this before moving on to the next step.)
+ Configuring your machines to use the APT repository3.5.2. Configuring your machines to use the APT repository
+ Now that we have created the repository, you need to configure your machine to make use of the APT repository. You can do this by adding a repository file under /etc/apt/sources.list.d. Use your preferred editor to create /etc/apt/sources.list.d/cloudstack.list with this line:
+ deb http://server.url/cloudstack/repo binary/
+ Now that you have the repository info in place, you'll want to run another update so that APT knows where to find the CloudStack packages.
+ $ sudo apt-get update
+ You can now move on to the instructions under Install on Ubuntu.
+ Building RPMs3.6. Building RPMs
+ While we have defined, and you have presumably already installed the bootstrap prerequisites, there are a number of build time prerequisites that need to be resolved. CloudStack uses maven for dependency resolution. You can resolve the buildtime depdencies for CloudStack by running the following command:
+$mvn -P deps
+
+
+ Now that we have resolved the dependencies we can move on to building CloudStack and packaging them into RPMs by issuing the following command.
+$./waf rpm
+
+
+ Once this completes, you should find assembled RPMs in artifacts/rpmbuild/RPMS/x86_64
+ Creating a yum repo3.6.1. Creating a yum repo
+ While RPMs is an ideal packaging format - it's most easily consumed from yum repositories over a network. We'll move into the directory with the newly created RPMs by issuing the following command:
+$cd artifacts/rpmbuild/RPMS/x86_64
+
+
+ Next we'll issue a command to create the repository metadata by issuing the following command:
+$createrepo ./
+
+
+ The files and directories within our current working directory can now be uploaded to a web server and serve as a yum repository
+ Configuring your systems to use your new yum repository3.6.2. Configuring your systems to use your new yum repository
+ Now that your yum repository is populated with RPMs and metadata we need to configure our machines that need to install CloudStack. We will create a file at /etc/yum.repos.d/cloudstack.repo with the following content:
+
+[apache-cloudstack]
+name=Apache CloudStack
+baseurl=http://webserver.tld/path/to/repo
+enabled=1
+gpgcheck=0
+
+
+
+ Completing this step will allow you to easily install CloudStack on a number of machines across the network.
+ Chapter 4.Chapter 4. InstallationInstallationWho Should Read This4.1. Who Should Read This
+ For those who have already gone through a design phase and planned a more sophisticated deployment, or those who are ready to start scaling up a trial installation. With the following procedures, you can start using the more powerful features of CloudStack, such as advanced VLAN networking, high availability, additional network elements such as load balancers and firewalls, and support for multiple hypervisors including Citrix XenServer, KVM, and VMware vSphere.
+ Overview of Installation Steps4.2. Overview of Installation Steps
+ For anything more than a simple trial installation, you will need guidance for a variety of configuration choices. It is strongly recommended that you read the following:
+ •
+ Choosing a Deployment Architecture
+ •
+ Choosing a Hypervisor: Supported Features
+ •
+ Network Setup
+ •
+ Storage Setup
+ •
+ Best Practices
+ 1.
+ Make sure you have the required hardware ready. See Section 4.3, “Minimum System Requirements”
+ 2.
+ Install the Management Server (choose single-node or multi-node). See Section 4.5, “Management Server Installation”
+ 3.
+ Log in to the UI. See Chapter 5, User Interface
+ 4.
+ Add a zone. Includes the first pod, cluster, and host. See Section 6.2, “Adding a Zone”
+ 5.
+ Add more pods (optional). See Section 6.3, “Adding a Pod”
+ 6.
+ Add more clusters (optional). See Section 6.4, “Adding a Cluster”
+ 7.
+ Add more hosts (optional). See Section 6.5, “Adding a Host”
+ 8.
+ Add more primary storage (optional). See Section 6.6, “Add Primary Storage”
+ 9.
+ Add more secondary storage (optional). See Section 6.7, “Add Secondary Storage”
+ 10.
+ Try using the cloud. See Section 6.8, “Initialize and Test”
+ Minimum System Requirements4.3. Minimum System RequirementsManagement Server, Database, and Storage System Requirements4.3.1. Management Server, Database, and Storage System Requirements
+ The machines that will run the Management Server and MySQL database must meet the following requirements. The same machines can also be used to provide primary and secondary storage, such as via localdisk or NFS. The Management Server may be placed on a virtual machine.
+ •
+ Operating system:
+ •
+ Preferred: CentOS/RHEL 6.3+ or Ubuntu 12.04(.1)
+ •
+ 64-bit x86 CPU (more cores results in better performance)
+ •
+ 4 GB of memory
+ •
+ 50 GB of local disk (When running secondary storage on the management server 500GB is recommended)
+ •
+ At least 1 NIC
+ •
+ Statically allocated IP address
+ •
+ Fully qualified domain name as returned by the hostname command
+ Host/Hypervisor System Requirements4.3.2. Host/Hypervisor System Requirements
+ The host is where the cloud services run in the form of guest virtual machines. Each host is one machine that meets the following requirements:
+ •
+ Must support HVM (Intel-VT or AMD-V enabled).
+ •
+ 64-bit x86 CPU (more cores results in better performance)
+ •
+ Hardware virtualization support required
+ •
+ 4 GB of memory
+ •
+ 36 GB of local disk
+ •
+ At least 1 NIC
+ •Note
+ If DHCP is used for hosts, ensure that no conflict occurs between DHCP server used for these hosts and the DHCP router created by CloudStack.
+ •
+ Latest hotfixes applied to hypervisor software
+ •
+ When you deploy CloudStack, the hypervisor host must not have any VMs already running
+ •
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+ Hosts have additional requirements depending on the hypervisor. See the requirements listed at the top of the Installation section for your chosen hypervisor:
+ Warning
+ Be sure you fulfill the additional hypervisor requirements and installation steps provided in this Guide. Hypervisor hosts must be properly prepared to work with CloudStack. For example, the requirements for XenServer are listed under Citrix XenServer Installation.
+ •
+ Section 8.1.1, “System Requirements for KVM Hypervisor Hosts”
+ •
+ Section 8.2.1, “System Requirements for XenServer Hosts”
+ •
+ Section 8.3.1, “System Requirements for vSphere Hosts”
+ Configure package repository4.4. Configure package repository
+ CloudStack is only distributed from source from the official mirrors. However, members of the CloudStack community may build convenience binaries so that users can install Apache CloudStack without needing to build from source.
+
+ If you didn't follow the steps to build your own packages from source in the sections for Section 3.6, “Building RPMs” or Section 3.5, “Building DEB packages” you may find pre-built DEB and RPM packages for your convience linked from the downloads11http://incubator.apache.org/cloudstack/downloads.html page.
+ Note
+ These repositories contain both the Management Server and KVM Hypervisor packages.
+ DEB package repository4.4.1. DEB package repository
+ You can add a DEB package repository to your apt sources with the following commands. Please note that currently only packages for Ubuntu 12.04 LTS (precise) are being build.
+
+ Use your preferred editor and open (or create) /etc/apt/sources.list.d/cloudstack. Add the community provided repository to the file:
+ deb http://cloudstack.apt-get.eu/ubuntu precise 4.0
+ We now have to add the public key to the trusted keys.
+ $ wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
+ Now update your local apt cache.
+ $ apt-get update
+ Your DEB package repository should now be configured and ready for use.
+ RPM package repository4.4.2. RPM package repository
+ If you're using an RPM-based system, you'll want to add the Yum repository so that you can install CloudStack with Yum.
+
+ Yum repository information is found under /etc/yum.repos.d. You'll see several .repo files in this directory, each one denoting a specific repository.
+
+ To add the CloudStack repository, visit the downloads page22http://incubator.apache.org/cloudstack/downloads.html for the repository information. It will look something like this:
+
+[cloudstack]
+name=cloudstack
+baseurl=http://server.url/downloads/rpm/stable/
+enabled=1
+gpgcheck=1
+
+ Next you'll want to add the GPG key:
+
+$ rpm --import http://server.url/downloads/RPM-GPG-KEY.txt
+ Now you should be able to install CloudStack using Yum.
+ Management Server Installation4.5. Management Server InstallationManagement Server Installation Overview4.5.1. Management Server Installation Overview
+ This section describes installing the Management Server. There are two slightly different installation flows, depending on how many Management Server nodes will be in your cloud:
+ •
+ A single Management Server node, with MySQL on the same node.
+ •
+ Multiple Management Server nodes, with MySQL on a node separate from the Management Servers.
+
+ In either case, each machine must meet the system requirements described in System Requirements.
+ Warning
+ For the sake of security, be sure the public Internet can not access port 8096 or port 8250 on the Management Server.
+
+ The procedure for installing the Management Server is:
+ 1.
+ Prepare the Operating System
+ 2.
+ Download and install vhd-util.
+ 3.
+ Install the First Management Server
+ 4.
+ Install and Configure the MySQL database
+ 5.
+ Prepare NFS Shares
+ 6.
+ Prepare and Start Additional Management Servers (optional)
+ 7.
+ Prepare the System VM Template
+ Prepare the Operating System4.5.2. Prepare the Operating System
+ The OS must be prepared to host the Management Server using the following steps. These steps must be performed on each Management Server node.
+ 1.
+ Log in to your OS as root.
+ 2.
+ Check for a fully qualified hostname.
+ hostname --fqdn
+ This should return a fully qualified hostname such as "managament1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+ 3.
+ Make sure that the machine can reach the Internet.
+ ping www.cloudstack.org4.
+ Turn on NTP for time synchronization.
+ Note
+ NTP is required to synchronize the clocks of the servers in your cloud.
+ a.
+ Install NTP.
+ yum install ntpapt-get install openntpd5.
+ Repeat all of these steps on every host where the Management Server will be installed.
+ Install the Management Server on the First Host4.5.3. Install the Management Server on the First Host
+ The first step in installation, whether you are installing the Management Server on one host or many, is to install the software on a single node.
+ Note
+ If you are planning to install the Management Server on multiple nodes for high availability, do not proceed to the additional nodes yet. That step will come later.
+
+ The CloudStack Management server can be installed using either RPM or DEB packages. These packages will depend on everything you need to run the Management server.
+ 4.5.3.1. Downloading vhd-util
+ Before setting up the Management Server, download vhd-util from vhd-util33http://download.cloud.com.s3.amazonaws.com/tools/vhd-util
+
+ If the Management Server is RHEL or CentOS, copy vhd-util to /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver.
+
+ If the Management Server is Ubuntu, copy vhd-util to /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util.
+ 4.5.3.2. Install on CentOS/RHEL
+ We start by installing the required packages:
+ yum install cloud-client4.5.3.3. Install on Ubuntuapt-get install cloud-clientInstall the database server4.5.4. Install the database server
+ The CloudStack management server uses a MySQL database server to store it's data. When you are installing the management server on a single node you can install the MySQL server locally. When using a multi-node installation the MySQL database has to run on an external node.
+
+ CloudStack has been tested with MySQL 5.1 and 5.5, both should work fine. These versions are included in RHEL/CentOS and Ubuntu.
+ 4.5.4.1. Install the Database on the Management Server Node
+ This section describes how to install MySQL on the same machine with the Management Server. This technique is intended for a simple deployment that has a single Management Server node. If you have a multi-node Management Server deployment, you will typically use a separate node for MySQL. See Section 4.5.4.2, “Install the Database on a Separate Node”.
+ 1.
+ Install MySQL from the package repository from your distribution:
+ yum install mysql-serverapt-get install mysql-server2.
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes one Management Server.
+ Note
+ On Ubuntu you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add these directives there. Don't forget to add [mysqld] on the first line of the file.
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=350
+log-bin=mysql-bin
+binlog-format = 'ROW'
+3.
+ On RHEL/CentOS MySQL doesn't start after installation, start it manually.
+ service mysqld start4.Warning
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password. This step is not required on Ubuntu as it asks for a root password during installation.
+
+ Run this command to secure your installation. Since we are running MySQL locally you can answer "Y" to all questions.
+ mysql_secure_installation5.
+ Set up the database. The following command creates the "cloud" user on the database.
+ •
+ In dbpassword, specify the password to be assigned to the "cloud" user. You can choose to provide no password although that is not recommended.
+ •
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the "cloud" user.
+ •
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+ •
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+ •
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+ cloud-setup-databases cloud:<dbpassword>@localhost \
+ --deploy-as=root:<password> \
+ -e <encryption_type> \
+ -m <management_server_key> \
+ -k <database_key>
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+ 4.5.4.2. Install the Database on a Separate Node
+ This section describes how to install MySQL on a standalone machine, separate from the Management Server. This technique is intended for a deployment that includes several Management Server nodes. If you have a single-node Management Server deployment, you will typically use the same node for MySQL. See Section 4.5.4.1, “Install the Database on the Management Server Node”.
+ Note
+ The management server doesn't require a specific distribution for the MySQL node. You can use a distribution or Operating System of your choice. Using the same distribution as the management server is recommended, but not required. See Section 4.3.1, “Management Server, Database, and Storage System Requirements”.
+ 1.
+ Install MySQL from the package repository from your distribution:
+ yum install mysql-serverapt-get install mysql-server2.
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes two Management Servers.
+ Note
+ On Ubuntu you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add these directives there. Don't forget to add [mysqld] on the first line of the file.
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=700
+log-bin=mysql-bin
+binlog-format = 'ROW'
+bind-address = 0.0.0.0
+3.
+ On RHEL/CentOS MySQL doesn't start after installation, start it manually.
+ service mysqld start4.Warning
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password. This step is not required on Ubuntu as it asks for a root password during installation.
+
+ Run this command to secure your installation. You can answer "Y" to all questions except to "Disallow root login remotely?". This is required to set up the databases.
+ mysql_secure_installation5.
+ If a firewall is present on the system, open TCP port 3306 so external MySQL connections can be established.
+ a.
+ On RHEL/CentOS:
+ i.
+ Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the INPUT chain.
+ -A INPUT -p tcp --dport 3306 -j ACCEPTii.
+ Now reload the iptables rules.
+ service iptables restartb.
+ On Ubuntu:
+
+ UFW is the default firewall on Ubuntu, open the port with this command:
+ ufw allow mysql6.
+ Set up the database. The following command creates the cloud user on the database.
+ Note
+ This command should be run on the first Management server node!
+ •
+ In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password.
+ •
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
+ •
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+ •
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+ •
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+ cloud-setup-databases cloud:<dbpassword>@<ip address mysql server> \
+ --deploy-as=root:<password> \
+ -e <encryption_type> \
+ -m <management_server_key> \
+ -k <database_key>
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+ Prepare NFS Shares4.5.5. Prepare NFS Shares
+ CloudStack needs a place to keep primary and secondary storage (see Cloud Infrastructure Overview). Both of these can be NFS shares. This section tells how to set up the NFS shares before adding the storage to CloudStack.
+
+ For primary storage, you can use iSCSI instead.
+
+ The requirements for primary and secondary storage are described in:
+ •
+ About Primary Storage
+ •
+ About Secondary Storage
+
+ A production installation typically uses a separate NFS server. See Section 4.5.5.1, “Using a Separate NFS Server”.
+
+ You can also use the Management Server node as the NFS server. This is more typical of a trial installation, but is technically possible in a larger deployment. See Section 4.5.5.2, “Using the Management Server As the NFS Server”.
+ 4.5.5.1. Using a Separate NFS Server
+ This section tells how to set up NFS shares for secondary and (optionally) primary storage on an NFS server running on a separate node from the Management Server.
+
+ The exact commands for the following steps may vary depending on your operating system version.
+ Warning
+ (KVM only) Ensure that no volume is already mounted at your NFS mount point.
+ 1.
+ On the storage server, create an NFS share for secondary storage and, if you are using NFS for primary storage as well, create a second NFS share. For example:
+
+# mkdir -p /export/primary
+# mkdir -p /export/secondary
+2.
+ To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s) with rw,async,no_root_squash. For example:
+ # vi /etc/exports
+ Insert the following line.
+ /export *(rw,async,no_root_squash)3.
+ Export the /export directory.
+ # exportfs -a4.
+ On the management server, create a mount point for secondary storage. For example:
+ # mkdir -p /mnt/secondary5.
+ Mount the secondary storage on your Management Server. Replace the example NFS server name and NFS share paths below with your own.
+ # mount -t nfs nfsservername:/nfs/share/secondary /mnt/secondary4.5.5.2. Using the Management Server As the NFS Server
+ This section tells how to set up NFS shares for primary and secondary storage on the same node with the Management Server. This is more typical of a trial installation, but is technically possible in a larger deployment. It is assumed that you will have less than 16TB of storage on the host.
+
+ The exact commands for the following steps may vary depending on your operating system version.
+ 1.
+ On the Management Server host, create two directories that you will use for primary and secondary storage. For example:
+
+# mkdir -p /export/primary
+# mkdir -p /export/secondary
+2.
+ To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s) with rw,async,no_root_squash. For example:
+ # vi /etc/exports
+ Insert the following line.
+ /export *(rw,async,no_root_squash)3.
+ Export the /export directory.
+ # exportfs -a4.
+ Edit the /etc/sysconfig/nfs file.
+ # vi /etc/sysconfig/nfs
+ Uncomment the following lines:
+
+LOCKD_TCPPORT=32803
+LOCKD_UDPPORT=32769
+MOUNTD_PORT=892
+RQUOTAD_PORT=875
+STATD_PORT=662
+STATD_OUTGOING_PORT=2020
+5.
+ Edit the /etc/sysconfig/iptables file.
+ # vi /etc/sysconfig/iptables
+ Add the following lines at the beginning of the INPUT chain where <NETWORK> is the network that you'll be using:
+
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 32769 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 662 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 662 -j ACCEPT
+6.
+ Run the following commands:
+
+# service iptables restart
+# service iptables save
+7.
+ If NFS v4 communication is used between client and server, add your domain to /etc/idmapd.conf on both the hypervisor host and Management Server.
+ # vi /etc/idmapd.conf
+ Remove the character # from the beginning of the Domain line in idmapd.conf and replace the value in the file with your own domain. In the example below, the domain is company.com.
+ Domain = company.com8.
+ Reboot the Management Server host.
+
+ Two NFS shares called /export/primary and /export/secondary are now set up.
+ 9.
+ It is recommended that you test to be sure the previous steps have been successful.
+ a.
+ Log in to the hypervisor host.
+ b.
+ Be sure NFS and rpcbind are running. The commands might be different depending on your OS. For example:
+
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+# reboot
+c.
+ Log back in to the hypervisor host and try to mount the /export directories. For example (substitute your own management server name):
+
+# mkdir /primarymount
+# mount -t nfs <management-server-name>:/export/primary /primarymount
+# umount /primarymount
+# mkdir /secondarymount
+# mount -t nfs <management-server-name>:/export/secondary /secondarymount
+# umount /secondarymount
+Prepare and Start Additional Management Servers4.5.6. Prepare and Start Additional Management Servers
+ For your second and subsequent Management Servers, you will install the Management Server software, connect it to the database, and set up the OS for the Management Server.
+ 1.
+ Perform the steps in Section 4.5.2, “Prepare the Operating System” and Section 3.6, “Building RPMs” or Section 3.5, “Building DEB packages” as appropriate.
+ 2.
+ Download vhd-util from vhd-util44http://download.cloud.com.s3.amazonaws.com/tools/vhd-util
+
+ If the Management Server is RHEL or CentOS, copy vhd-util to /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver.
+
+ If the Management Server is Ubuntu, copy vhd-util to /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util.
+ 3.
+ Ensure that necessary services are started and set to start on boot.
+#service rpcbind start
+#service nfs start
+#chkconfig nfs on
+#chkconfig rpcbind on
+
+ 4.
+ Configure the database client. Note the absence of the --deploy-as argument in this case. (For more details about the arguments to this command, see Section 4.5.4.2, “Install the Database on a Separate Node”.)
+ #cloud-setup-databases cloud:dbpassword@dbhost -e encryption_type -m management_server_key -k database_key5.
+ Configure the OS and start the Management Server:
+ #cloud-setup-management
+ The Management Server on this node should now be running.
+ 6.
+ Repeat these steps on each additional Management Server.
+ 7.
+ Be sure to configure a load balancer for the Management Servers. See Management Server Load Balancing.
+ Prepare the System VM Template4.5.7. Prepare the System VM Template
+ Secondary storage must be seeded with a template that is used for CloudStack system VMs.
+ Note
+ When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text.
+ 1.
+ On the Management Server, run one or more of the following cloud-install-sys-tmplt commands to retrieve and decompress the system VM template. Run the command for each hypervisor type that you expect end users to run in this Zone.
+
+ If your secondary storage mount point is not named /mnt/secondary, substitute your own mount point name.
+
+ If you set the CloudStack database encryption type to "web" when you set up the database, you must now add the parameter -s <management-server-secret-key>. See About Password and Key Encryption.
+
+ This process will require approximately 5 GB of free space on the local file system and up to 30 minutes each time it runs.
+ •
+ For XenServer:
+ # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 -h xenserver -s <optional-management-server-secret-key> -F•
+ For vSphere:
+ # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova -h vmware -s <optional-management-server-secret-key> -F•
+ For KVM:
+ # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -s <optional-management-server-secret-key> -F2.
+ If you are using a separate NFS server, perform this step. If you are using the Management Server as the NFS server, you MUST NOT perform this step.
+
+ When the script has finished, unmount secondary storage and remove the created directory.
+ # umount /mnt/secondary
+# rmdir /mnt/secondary3.
+ Repeat these steps for each secondary storage server.
+ Installation Complete! Next Steps4.5.8. Installation Complete! Next Steps
+ Congratulations! You have now installed CloudStack Management Server and the database it uses to persist system data.
+
+ What should you do next?
+ •
+ Even without adding any cloud infrastructure, you can run the UI to get a feel for what's offered and how you will interact with CloudStack on an ongoing basis. See Log In to the UI.
+ •
+ When you're ready, add the cloud infrastructure and try running some virtual machines on it, so you can watch how CloudStack manages the infrastructure. See Provision Your Cloud Infrastructure.
+ Chapter 5.Chapter 5. User InterfaceUser InterfaceLog In to the UI5.1. Log In to the UI
+ CloudStack provides a web-based UI that can be used by both administrators and end users. The appropriate version of the UI is displayed depending on the credentials used to log in. The UI is available in popular browsers including IE7, IE8, IE9, Firefox 3.5+, Firefox 4, Safari 4, and Safari 5. The URL is: (substitute your own management server IP address)
+ 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 Overview5.1.1. End User's UI Overview
+ The CloudStack UI helps users of cloud infrastructure to view and use their cloud resources, including virtual machines, templates and ISOs, data volumes and snapshots, guest networks, and IP addresses. If the user is a member or administrator of one or more CloudStack projects, the UI can provide a project-oriented view.
+ Root Administrator's UI Overview5.1.2. Root Administrator's UI Overview
+ The CloudStack UI helps the CloudStack administrator provision, view, and manage the cloud infrastructure, domains, user accounts, projects, and configuration settings. The first time you start the UI after a fresh Management Server installation, you can choose to follow a guided tour to provision your cloud infrastructure. On subsequent logins, the dashboard of the logged-in user appears. The various links in this screen and the navigation bar on the left provide access to a variety of administrative functions. The root administrator can also use the UI to perform all the same tasks that are present in the end-user’s UI.
+ Logging In as the Root Administrator5.1.3. Logging In as the Root Administrator
+ After the Management Server software is installed and running, you can run the CloudStack user interface. This UI is there to help you provision, view, and manage your cloud infrastructure.
+ 1.
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+ 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 can enter a user ID and password and proceed to your Dashboard.
+ 2.
+ 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 CloudPlatform, 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.
+ 3.
+ 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”.
+ 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 Password5.1.4. Changing the Root Password
+ During installation and ongoing cloud administration, you will need to log in to the UI as the root administrator. The root administrator account manages the CloudStack deployment, including physical infrastructure. The root administrator can modify configuration settings to change basic functionality, create or delete user accounts, and take many actions that should be performed only by an authorized person. When first installing CloudStack, be sure to change the default password to a new, unique value.
+ 1.
+ Open your favorite Web browser and go to this URL. Substitute the IP address of your own Management Server:
+ http://<management-server-ip-address>:8080/client2.
+ Log in to the UI using the current root user ID and password. The default is admin, password.
+ 3.
+ Click Accounts.
+ 4.
+ Click the admin account name.
+ 5.
+ Click View Users.
+ 6.
+ Click the admin user name.
+ 7.
+ Click the Change Password button.
+
+ 8.
+ Type the new password, and click OK.
+ Using SSH Keys for Authentication5.2. Using SSH Keys for Authentication
+ In addition to the username and password authentication, CloudStack supports using SSH keys to log in to the cloud infrastructure for additional security. You can use the createSSHKeyPair API to generate the SSH keys.
+
+ Because each cloud user has their own SSH key, one cloud user cannot log in to another cloud user's instances unless they share their SSH key files. Using a single SSH key pair, you can manage multiple instances.
+ Creating an Instance Template that Supports SSH Keys5.2.1. Creating an Instance Template that Supports SSH Keys
+ Create a instance template that supports SSH Keys.
+ 1.
+ Create a new instance by using the template provided by cloudstack.
+
+ For more information on creating a new instance, see
+ 2.
+ Download the cloudstack script from The SSH Key Gen Script11http://sourceforge.net/projects/cloudstack/files/SSH%20Key%20Gen%20Script/to the instance you have created.
+ 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=iweb3.
+ Copy the file to /etc/init.d.
+ cp cloud-set-guest-sshkey.in /etc/init.d/4.
+ Give the necessary permissions on the script:
+ chmod +x /etc/init.d/cloud-set-guest-sshkey.in5.
+ Run the script while starting up the operating system:
+ chkconfig --add cloud-set-guest-sshkey.in6.
+ Stop the instance.
+ Creating the SSH Keypair5.2.2. Creating the SSH Keypair
+ You must make a call to the createSSHKeyPair api method. You can either use the CloudStack Python API library or the curl commands to make the call to the cloudstack api.
+
+ For example, make a call from the cloudstack server to create a SSH keypair called "keypair-doc" for the admin account in the root domain:
+ Note
+ Ensure that you adjust these values to meet your needs. If you are making the API call from a different server, your URL/PORT will be different, and you will need to use the API keys.
+ 1.
+ Run the following curl command:
+ 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:
+ <?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>2.
+ Copy the key data into a file. The file looks like this:
+ -----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-----3.
+ Save the file.
+ Creating an Instance5.2.3. Creating an Instance
+ After you save the SSH keypair file, you must create an instance by using the template that you created at Section 5.2.1, “ Creating an Instance Template that Supports SSH Keys”. Ensure that you use the same SSH key name that you created at Section 5.2.2, “Creating the 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:
+ curl --globoff http://localhost:<port numbet>/?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 Keypair5.2.4. Logging In Using the SSH Keypair
+ To test your SSH key generation is successful, check whether you can log in to the cloud setup.
+
+ For exaple, from a Linux OS, run:
+ ssh -i ~/.ssh/keypair-doc <ip address>
+ The -i parameter tells the ssh client to use a ssh key found at ~/.ssh/keypair-doc.
+ Chapter 6.Chapter 6. Steps to Provisioning Your Cloud InfrastructureSteps to Provisioning Your Cloud Infrastructure
+ This section tells how to add 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.
+ Overview of Provisioning Steps6.1. 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”.
+
+ To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
+ 1.
+ Change the root password. See Section 5.1.4, “Changing the Root Password”.
+ 2.
+ Add a zone. See Section 6.2, “Adding a Zone”.
+ 3.
+ Add more pods (optional). See Section 6.3, “Adding a Pod”.
+ 4.
+ Add more clusters (optional). See Section 6.4, “Adding a Cluster”.
+ 5.
+ Add more hosts (optional). See Section 6.5, “Adding a Host”.
+ 6.
+ Add primary storage. See Section 6.6, “Add Primary Storage”.
+ 7.
+ Add secondary storage. See Section 6.7, “Add Secondary Storage”.
+ 8.
+ Initialize and test the new cloud. See Section 6.8, “Initialize and Test”.
+
+ When you have finished these steps, you will have a deployment with the following basic structure:
+ Adding a Zone6.2. Adding a Zone
+ These steps assume you have already logged in to the CloudStack UI. See Section 5.1, “Log In to the UI”.
+ 1.
+ (Optional) If you are going to use Swift for cloud-wide secondary storage, you need to add it before you add zones.
+ a.
+ Log in to the CloudStack UI as administrator.
+ b.
+ If this is your first time visiting the UI, you will see the guided tour splash screen. Choose “Experienced user.” The Dashboard appears.
+ c.
+ In the left navigation bar, click Global Settings.
+ d.
+ In the search box, type swift.enable and click the search button.
+ e.
+ Click the edit button and set swift.enable to true.
+
+
+ f.
+ Restart the Management Server.
+ # service cloud-management restartg.
+ Refresh the CloudStack UI browser tab and log back in.
+ 2.
+ In the left navigation, choose Infrastructure.
+ 3.
+ On Zones, click View More.
+ 4.
+ (Optional) If you are using Swift storage, click Enable Swift. Provide the following:
+ •
+ URL. The Swift URL.
+ •
+ Account. The Swift account.
+ •
+ Username. The Swift account’s username.
+ •
+ Key. The Swift key.
+ 5.
+ Click Add Zone. The zone creation wizard will appear.
+ 6.
+ 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.
+
+ For more information about the network types, see Network Setup.
+ 7.
+ The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you:
+ •
+ Section 6.2.1, “Basic Zone Configuration”
+ •
+ Section 6.2.2, “Advanced Zone Configuration”
+ Basic Zone Configuration6.2.1. Basic Zone Configuration1.
+ 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.
+ 2.
+ 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.
+ 3.
+ (Introduced in version 3.0.1) 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.
+ 4.
+ Click Next.
+ 5.
+ (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.
+ 6.
+ (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.
+ 7.
+ 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.2, “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.
+ 8.
+ 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.
+ 9.
+ 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.
+ 10.
+ 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.
+ 11.
+ In a new cluster, CloudPlatform 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 Configuration6.2.2. Advanced Zone Configuration1.
+ 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.
+ 2.
+ 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.7.4, “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.
+ 3.
+ (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.
+ 4.
+ Click Next.
+ 5.
+ 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.
+ 6.
+ 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.2, “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.7.7, “System Reserved IP Addresses”.
+ 7.
+ Specify a range of VLAN IDs to carry guest traffic for each physical network (see VLAN Allocation Example ), then click Next.
+ 8.
+ 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.3, “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.
+ 9.
+ 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.4, “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.
+ 10.
+ 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.5, “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.
+
+
+ 11.
+ In a new zone, CloudStack adds the first secondary storage server for you. For an overview of what secondary storage is, see Section 2.6, “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.
+ •
+ Path. The exported path from the server.
+ 12.
+ Click Launch.
+ Adding a Pod6.3. 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.
+ 1.
+ Log in to the CloudStack UI. See Section 5.1, “Log In to the UI”.
+ 2.
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone to which you want to add a pod.
+ 3.
+ Click the Compute and Storage tab. In the Pods node of the diagram, click View All.
+ 4.
+ Click Add Pod.
+ 5.
+ 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.
+ 6.
+ Click OK.
+ Adding a Cluster6.4. 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 XenServer6.4.1. Add Cluster: KVM or XenServer
+ These steps assume you have already installed the hypervisor on the hosts and logged in to the CloudStack UI.
+ 1.
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the cluster.
+ 2.
+ Click the Compute tab.
+ 3.
+ In the Clusters node of the diagram, click View All.
+ 4.
+ Click Add Cluster.
+ 5.
+ Choose the hypervisor type for this cluster.
+ 6.
+ Choose the pod in which you want to create the cluster.
+ 7.
+ Enter a name for the cluster. This can be text of your choosing and is not used by CloudStack.
+ 8.
+ Click OK.
+ Add Cluster: vSphere6.4.2. 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:
+ 1.
+ 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.
+ 2.
+ Log in to the UI.
+ 3.
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the cluster.
+ 4.
+ Click the Compute tab, and click View All on Pods. Choose the pod to which you want to add the cluster.
+ 5.
+ Click View Clusters.
+ 6.
+ Click Add Cluster.
+ 7.
+ In Hypervisor, choose VMware.
+ 8.
+ Provide the following information in the dialog. The fields below make reference to values from vCenter.
+ •
+ Cluster Name. Enter the name of the cluster you created in vCenter. For example, "cloud.cluster.2.2.1"
+ •
+ vCenter Host. Enter the hostname or IP address of the vCenter server.
+ •
+ vCenter Username. Enter the username that CloudStack should use to connect to vCenter. This user must have all administrative privileges.
+ •
+ 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".
+ •
+ There might be a slight delay while the cluster is provisioned. It will automatically display in the UI
+ Adding a Host6.5. Adding a Host1.
+ 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.
+ 2.
+ Now add the hypervisor host to CloudStack. The technique to use varies depending on the hypervisor.
+ •
+ Section 6.5.1, “Adding a Host (XenServer or KVM)”
+ •
+ Section 6.5.2, “Adding a Host (vSphere)”
+ Adding a Host (XenServer or KVM)6.5.1. Adding a Host (XenServer or KVM)
+ XenServer and KVM hosts can be added to a cluster at any time.
+ 6.5.1.1. Requirements for XenServer and KVM HostsWarning
+ 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.
+ 6.5.1.1.1. 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.
+ # 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.
+ 1.
+ Copy the script from the Management Server in /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+ 2.
+ Run the script:
+ # ./cloud-setup-bonding.sh6.5.1.1.2. 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.
+ 6.5.1.2. 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 delay while the host is provisioned. It should automatically display in the UI.
+ •
+ Repeat for additional hosts.
+ Adding a Host (vSphere)6.5.2. Adding a Host (vSphere)
+ For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the entire cluster to CloudStack. See Add Cluster: vSphere.
+ Add Primary Storage6.6. Add Primary StorageSystem Requirements for Primary Storage6.6.1. System Requirements for Primary Storage
+ Hardware requirements:
+ •
+ Any standards-compliant iSCSI or NFS server that is supported by the underlying hypervisor.
+ •
+ The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller.
+ •
+ Minimum required capacity depends on your needs.
+
+ When setting up primary storage, follow these restrictions:
+ •
+ Primary storage cannot be added until a host has been added to the cluster.
+ •
+ If you do not provision shared primary storage, you must set the global configuration parameter system.vm.local.storage.required to true, or else you will not be able to start VMs.
+ Adding Primary Stroage6.6.2. Adding Primary Stroage
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+ Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+ 1.
+ Log in to the CloudStack UI (see Section 5.1, “Log In to the UI”).
+ 2.
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+ 3.
+ Click the Compute tab.
+ 4.
+ In the Primary Storage node of the diagram, click View All.
+ 5.
+ Click Add Primary Storage.
+ 6.
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+ •
+ Pod. The pod for the storage device.
+ •
+ Cluster. The cluster for the storage device.
+ •
+ Name. The name of the storage device.
+ •
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS.
+ •
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device.
+ •
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+ •
+ Path (for NFS). In NFS this is the exported path from the server.
+ •
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+ •
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+ •
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside CloudStack.
+ •
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
+ •
+ Lun # (for iSCSI). In iSCSI this is 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.
+ 7.
+ Click OK.
+ Add Secondary Storage6.7. Add Secondary StorageSystem Requirements for Secondary Storage6.7.1. System Requirements for Secondary Storage•
+ NFS storage appliance or Linux NFS server
+ •
+ (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org)
+ •
+ 100GB minimum capacity
+ •
+ A secondary storage device must be located in the same zone as the guest VMs it serves.
+ •
+ Each Secondary Storage server must be available to all hosts in the zone.
+ Adding Secondary Storage6.7.2. Adding Secondary Storage
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+ Warning
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+ 1.
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to CloudStack before you add the local zone secondary storage servers. See Section 6.2, “Adding a Zone”.
+ 2.
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See Section 4.5.5, “Prepare NFS Shares”.
+ 3.
+ Make sure you prepared the system VM template during Management Server installation. See Section 4.5.7, “Prepare the System VM Template”.
+ 4.
+ Now that the secondary storage server for per-zone storage is prepared, add it to CloudStack. Secondary storage is added as part of the procedure for adding a new zone. See Section 6.2, “Adding a Zone”.
+ Initialize and Test6.8. Initialize and Test
+ After everything is configured, CloudStack will perform its initialization. This can take 30 minutes or more, depending on the speed of your network. When the initialization has completed successfully, the administrator's Dashboard should be displayed in the CloudStack UI.
+ 1.
+ Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS 5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do not proceed to the next step until this status is displayed.
+ 2.
+ Go to the Instances tab, and filter by My Instances.
+ 3.
+ Click Add Instance and follow the steps in the wizard.
+ a.
+ Choose the zone you just added.
+ b.
+ In the template selection, choose the template to use in the VM. If this is a fresh installation, likely only the provided CentOS template is available.
+ c.
+ Select a service offering. Be sure that the hardware you have allows starting the selected service offering.
+ d.
+ In data disk offering, if desired, add another data disk. This is a second volume that will be available to but not mounted in the guest. For example, in Linux on XenServer you will see /dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PV-enabled OS kernel in use.
+ e.
+ In default network, choose the primary network for the guest. In a trial installation, you would have only one option here.
+ f.
+ Optionally give your VM a name and a group. Use any descriptive text you would like.
+ g.
+ Click Launch VM. Your VM will be created and started. It might take some time to download the template and complete the VM startup. You can watch the VM’s progress in the Instances screen.
+ 4.
+ To use the VM, click the View Console button.
+
+
+
+ Congratulations! You have successfully completed a CloudStack Installation.
+
+ If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
+ Chapter 7.Chapter 7. Setting Global Configuration ParametersSetting Global Configuration Parameters
+ CloudStack provides parameters that you can set to control many aspects of the cloud. When CloudStack is first installed, and periodically thereafter, you might need to modify these settings.
+ 1.
+ Log in to the UI as administrator.
+ 2.
+ In the left navigation bar, click Global Settings.
+ 3.
+ In Select View, choose one of the following:
+ •
+ Global Settings. This displays a list of the parameters with brief descriptions and current values.
+ •
+ Hypervisor Capabilities. This displays a list of hypervisor versions with the maximum number of guests supported for each.
+ 4.
+ Use the search box to narrow down the list to those you are interested in.
+ 5.
+ Click the Edit icon to modify a value. If you are viewing Hypervisor Capabilities, you must click the name of the hypervisor first to display the editing screen.
+ Chapter 8.Chapter 8. Hypervisor InstallationHypervisor InstallationKVM Hypervisor Host Installation8.1. KVM Hypervisor Host InstallationSystem Requirements for KVM Hypervisor Hosts8.1.1. System Requirements for KVM Hypervisor Hosts
+ KVM is included with a variety of Linux-based operating systems. Although you are not required to run these distributions, the following are recommended:
+ •
+ CentOS / RHEL: 6.3
+ •
+ Ubuntu: 12.04(.1)
+
+ The main requirement for KVM hypervisors is the libvirt and Qemu version. No matter what Linux distribution you are using, make sure the following requirements are met:
+ •
+ libvirt: 0.9.4 or higher
+ •
+ Qemu/KVM: 1.0 or higher
+
+ In addition, the following hardware requirements apply:
+ •
+ Within a single cluster, the hosts must be of the same distribution version.
+ •
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+ •
+ Must support HVM (Intel-VT or AMD-V enabled)
+ •
+ 64-bit x86 CPU (more cores results in better performance)
+ •
+ 4 GB of memory
+ •
+ At least 1 NIC
+ •
+ When you deploy CloudStack, the hypervisor host must not have any VMs already running
+ KVM Installation Overview8.1.2. KVM Installation Overview
+ If you want to use the Linux Kernel Virtual Machine (KVM) hypervisor to run guest virtual machines, install KVM on the host(s) in your cloud. The material in this section doesn't duplicate KVM installation docs. It provides the CloudStack-specific steps that are needed to prepare a KVM host to work with CloudStack.
+ Warning
+ Before continuing, make sure that you have applied the latest updates to your host.
+ Warning
+ It is NOT recommended to run services on this host not controlled by CloudStack.
+
+ The procedure for installing a KVM Hypervisor Host is:
+ 1.
+ Prepare the Operating System
+ 2.
+ Install and configure libvirt
+ 3.
+ Configure Security Policies (AppArmor and SELinux)
+ 4.
+ Install and configure the Agent
+ Prepare the Operating System8.1.3. Prepare the Operating System
+ The OS of the Host must be prepared to host the CloudStack Agent and run KVM instances.
+ 1.
+ Log in to your OS as root.
+ 2.
+ Check for a fully qualified hostname.
+ $ hostname --fqdn
+ This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+ 3.
+ Make sure that the machine can reach the Internet.
+ $ ping www.cloudstack.org4.
+ Turn on NTP for time synchronization.
+ Note
+ NTP is required to synchronize the clocks of the servers in your cloud. Unsynchronized clocks can cause unexpected problems.
+ a.
+ Install NTP
+ $ yum install ntp$ apt-get install openntpd5.
+ Repeat all of these steps on every hypervisor host.
+ Install and configure the Agent8.1.4. Install and configure the Agent
+ To manage KVM instances on the host CloudStack uses a Agent. This Agent communicates with the Management server and controls all the instances on the host.
+
+ First we start by installing the agent:
+
+ In RHEL or CentOS:
+ $ yum install cloud-agent
+ In Ubuntu:
+ $ apt-get install cloud-agent
+ The host is now ready to be added to a cluster. This is covered in a later section, see Section 6.5, “Adding a Host”. It is recommended that you continue to read the documentation before adding the host!
+ Install and Configure libvirt8.1.5. Install and Configure libvirt
+ CloudStack uses libvirt for managing virtual machines. Therefore it is vital that libvirt is configured correctly. Libvirt is a dependency of cloud-agent and should already be installed.
+ 1.
+ In order to have live migration working libvirt has to listen for unsecured TCP connections. We also need to turn off libvirts attempt to use Multicast DNS advertising. Both of these settings are in /etc/libvirt/libvirtd.conf
+
+ Set the following paramaters:
+ listen_tls = 0listen_tcp = 1tcp_port = 16059auth_tcp = "none"mdns_adv = 02.
+ Turning on "listen_tcp" in libvirtd.conf is not enough, we have to change the parameters as well:
+
+ On RHEL or CentOS modify /etc/sysconfig/libvirtd:
+
+ Uncomment the following line:
+ #LIBVIRTD_ARGS="--listen"
+ On Ubuntu: modify /etc/init/libvirt-bin.conf
+
+ Change the following line (at the end of the file):
+ exec /usr/sbin/libvirtd -d
+ to (just add -l)
+ exec /usr/sbin/libvirtd -d -l3.
+ Restart libvirt
+
+ In RHEL or CentOS:
+ $ service libvirtd restart
+ In Ubuntu:
+ $ service libvirt-bin restartConfigure the Security Policies8.1.6. Configure the Security Policies
+ CloudStack does various things which can be blocked by security mechanisms like AppArmor and SELinux. These have to be disabled to ensure the Agent has all the required permissions.
+ 1.
+ Configure SELinux (RHEL and CentOS)
+ a.
+ Check to see whether SELinux is installed on your machine. If not, you can skip this section.
+
+ In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
+ $ rpm -qa |grep selinuxb.
+ Set the SELINUX variable in /etc/selinux/config to "permissive". This ensures that the permissive setting will be maintained after a system reboot.
+
+ In RHEL or CentOS:
+ vi /etc/selinux/config
+ Change the following line
+ SELINUX=enforcing
+ to this
+ SELINUX=permissivec.
+ Then set SELinux to permissive starting immediately, without requiring a system reboot.
+ $ setenforce permissive2.
+ Configure Apparmor (Ubuntu)
+ a.
+ Check to see whether AppArmor is installed on your machine. If not, you can skip this section.
+
+ In Ubuntu AppArmor is installed and enabled by default. You can verify this with:
+ $ dpkg --list 'apparmor'b.
+ Disable the AppArmor profiles for libvirt
+ $ ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/$ ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/$ apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd$ apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helperConfigure the network bridges8.1.7. Configure the network bridgesWarning
+ This is a very important section, please make sure you read this thoroughly.
+
+ In order to forward traffic to your instances you will need at least two bridges: public and private.
+
+ By default these bridges are called cloudbr0 and cloudbr1, but you do have to make sure they are available on each hypervisor.
+
+ The most important factor is that you keep the configuration consistent on all your hypervisors.
+ 8.1.7.1. Network example
+ There are many ways to configure your network. In the Basic networking mode you should have two (V)LAN's, one for your private network and one for the public network.
+
+ We assume that the hypervisor has one NIC (eth0) with three tagged VLAN's:
+ 1.
+ VLAN 100 for management of the hypervisor
+ 2.
+ VLAN 200 for public network of the instances (cloudbr0)
+ 3.
+ VLAN 300 for private network of the instances (cloudbr1)
+
+ On VLAN 100 we give the Hypervisor the IP-Address 192.168.42.11/24 with the gateway 192.168.42.1
+ Note
+ The Hypervisor and Management server don't have to be in the same subnet!
+ 8.1.7.2. Configuring the network bridges
+ It depends on the distribution you are using how to configure these, below you'll find examples for RHEL/CentOS and Ubuntu.
+ Note
+ The goal is to have two bridges called 'cloudbr0' and 'cloudbr1' after this section. This should be used as a guideline only. The exact configuration will depend on your network layout.
+ 8.1.7.2.1. Configure in RHEL or CentOS
+ The required packages were installed when libvirt was installed, we can proceed to configuring the network.
+
+ First we configure eth0
+ vi /etc/sysconfig/network-scripts/ifcfg-eth0
+ Make sure it looks similair to:
+ DEVICE=eth0
+HWADDR=00:04:xx:xx:xx:xx
+ONBOOT=yes
+HOTPLUG=no
+BOOTPROTO=none
+TYPE=Ethernet
+ We now have to configure the three VLAN interfaces:
+ vi /etc/sysconfig/network-scripts/ifcfg-eth0.100DEVICE=eth0.100
+HWADDR=00:04:xx:xx:xx:xx
+ONBOOT=yes
+HOTPLUG=no
+BOOTPROTO=none
+TYPE=Ethernet
+VLAN=yes
+IPADDR=192.168.42.11
+GATEWAY=192.168.42.1
+NETMASK=255.255.255.0vi /etc/sysconfig/network-scripts/ifcfg-eth0.200DEVICE=eth0.200
+HWADDR=00:04:xx:xx:xx:xx
+ONBOOT=yes
+HOTPLUG=no
+BOOTPROTO=none
+TYPE=Ethernet
+VLAN=yes
+BRIDGE=cloudbr0vi /etc/sysconfig/network-scripts/ifcfg-eth0.300DEVICE=eth0.300
+HWADDR=00:04:xx:xx:xx:xx
+ONBOOT=yes
+HOTPLUG=no
+BOOTPROTO=none
+TYPE=Ethernet
+VLAN=yes
+BRIDGE=cloudbr1
+ Now we have the VLAN interfaces configured we can add the bridges on top of them.
+ vi /etc/sysconfig/network-scripts/ifcfg-cloudbr0
+ Now we just configure it is a plain bridge without an IP-Adress
+ DEVICE=cloudbr0
+TYPE=Bridge
+ONBOOT=yes
+BOOTPROTO=none
+IPV6INIT=no
+IPV6_AUTOCONF=no
+DELAY=5
+STP=yes
+ We do the same for cloudbr1
+ vi /etc/sysconfig/network-scripts/ifcfg-cloudbr1DEVICE=cloudbr1
+TYPE=Bridge
+ONBOOT=yes
+BOOTPROTO=none
+IPV6INIT=no
+IPV6_AUTOCONF=no
+DELAY=5
+STP=yes
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+ Warning
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+ 8.1.7.2.2. Configure in Ubuntu
+ All the required packages were installed when you installed libvirt, so we only have to configure the network.
+ vi /etc/network/interfaces
+ Modify the interfaces file to look like this:
+ auto lo
+iface lo inet loopback
+
+# The primary network interface
+auto eth0.100
+iface eth0.100 inet static
+ address 192.168.42.11
+ netmask 255.255.255.240
+ gateway 192.168.42.1
+ dns-nameservers 8.8.8.8 8.8.4.4
+ dns-domain lab.example.org
+
+# Public network
+auto cloudbr0
+iface cloudbr0 inet manual
+ bridge_ports eth0.200
+ bridge_fd 5
+ bridge_stp off
+ bridge_maxwait 1
+
+# Private network
+auto cloudbr1
+iface cloudbr1 inet manual
+ bridge_ports eth0.300
+ bridge_fd 5
+ bridge_stp off
+ bridge_maxwait 1
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+ Warning
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+ Configuring the firewall8.1.8. Configuring the firewall
+ The hypervisor needs to be able to communicate with other hypervisors and the management server needs to be able to reach the hypervisor.
+
+ In order to do so we have to open the following TCP ports (if you are using a firewall):
+ 1.
+ 22 (SSH)
+ 2.
+ 1798
+ 3.
+ 16509 (libvirt)
+ 4.
+ 5900 - 6100 (VNC consoles)
+ 5.
+ 49152 - 49216 (libvirt live migration)
+
+ It depends on the firewall you are using how to open these ports. Below you'll find examples how to open these ports in RHEL/CentOS and Ubuntu.
+ 8.1.8.1. Open ports in RHEL/CentOS
+ RHEL and CentOS use iptables for firewalling the system, you can open extra ports by executing the following iptable commands:
+ $ iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT$ iptables -I INPUT -p tcp -m tcp --dport 1798 -j ACCEPT$ iptables -I INPUT -p tcp -m tcp --dport 16509 -j ACCEPT$ iptables -I INPUT -p tcp -m tcp --dport 5900:6100 -j ACCEPT$ iptables -I INPUT -p tcp -m tcp --dport 49152:49216 -j ACCEPT
+ These iptable settings are not persistent accross reboots, we have to save them first.
+ $ iptables-save > /etc/sysconfig/iptables8.1.8.2. Open ports in Ubuntu
+ The default firewall under Ubuntu is UFW (Uncomplicated FireWall), which is a Python wrapper around iptables.
+
+ To open the required ports, execute the following commands:
+ $ ufw allow proto tcp from any to any port 22$ ufw allow proto tcp from any to any port 1798$ ufw allow proto tcp from any to any port 16509$ ufw allow proto tcp from any to any port 5900:6100$ ufw allow proto tcp from any to any port 49152:49216Note
+ By default UFW is not enabled on Ubuntu. Executing these commands with the firewall disabled does not enable the firewall.
+ Add the host to CloudStack8.1.9. Add the host to CloudStack
+ The host is now ready to be added to a cluster. This is covered in a later section, see Section 6.5, “Adding a Host”. It is recommended that you continue to read the documentation before adding the host!
+ Citrix XenServer Installation for CloudStack8.2. Citrix XenServer Installation for CloudStack
+ If you want to use the Citrix XenServer hypervisor to run guest virtual machines, install XenServer 6.0 or XenServer 6.0.2 on the host(s) in your cloud. For an initial installation, follow the steps below. If you have previously installed XenServer and want to upgrade to another version, see Section 8.2.11, “Upgrading XenServer Versions”.
+ System Requirements for XenServer Hosts8.2.1. System Requirements for XenServer Hosts•
+ The host must be certified as compatible with one of the following. See the Citrix Hardware Compatibility Guide: http://hcl.xensource.com
+ •
+ XenServer 5.6 SP2
+ •
+ XenServer 6.0
+ •
+ XenServer 6.0.2
+ •
+ You must re-install Citrix XenServer if you are going to re-use a host from a previous install.
+ •
+ Must support HVM (Intel-VT or AMD-V enabled)
+ •
+ 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.
+ •
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+ •
+ Must support HVM (Intel-VT or AMD-V enabled in BIOS)
+ •
+ 64-bit x86 CPU (more cores results in better performance)
+ •
+ Hardware virtualization support required
+ •
+ 4 GB of memory
+ •
+ 36 GB of local disk
+ •
+ At least 1 NIC
+ •
+ Statically allocated IP Address
+ •
+ When you deploy CloudStack, the hypervisor host must not have any VMs already running
+ Warning
+ The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+ XenServer Installation Steps8.2.2. XenServer Installation Steps1.
+ From https://www.citrix.com/English/ss/downloads/, download the appropriate version of XenServer for your CloudStack version (see Section 8.2.1, “System Requirements for XenServer Hosts”). Install it using the Citrix XenServer Installation Guide.
+ 2.
+ After installation, perform the following configuration steps, which are described in the next few sections:
+
+
+ Required
+
+
+
+ Optional
+
+
+
+ Section 8.2.3, “Configure XenServer dom0 Memory”
+
+
+
+ Section 8.2.7, “Install CloudStack XenServer Support Package (CSP)”
+
+
+
+ Section 8.2.4, “Username and Password”
+
+
+
+ Set up SR if not using NFS, iSCSI, or local disk; see Section 8.2.8, “Primary Storage Setup for XenServer”
+
+
+
+ Section 8.2.5, “Time Synchronization”
+
+
+
+ Section 8.2.9, “iSCSI Multipath Setup for XenServer (Optional)”
+
+
+
+ Section 8.2.6.1, “Getting and Deploying a License”
+
+
+
+ Section 8.2.10, “Physical Networking Setup for XenServer”
+
+ Configure XenServer dom0 Memory8.2.3. Configure XenServer dom0 Memory
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see http://support.citrix.com/article/CTX126531. The article refers to XenServer 5.6, but the same information applies to XenServer 6.0.
+ Username and Password8.2.4. Username and Password
+ All XenServers in a cluster must have the same username and password as configured in CloudStack.
+ Time Synchronization8.2.5. Time Synchronization
+ The host must be set to use NTP. All hosts in a pod must have the same time.
+ 1.
+ Install NTP.
+ # yum install ntp2.
+ Edit the NTP configuration file to point to your NTP server.
+ # vi /etc/ntp.conf
+ Add one or more server lines in this file with the names of the NTP servers you want to use. For example:
+ server 0.xenserver.pool.ntp.org
+server 1.xenserver.pool.ntp.org
+server 2.xenserver.pool.ntp.org
+server 3.xenserver.pool.ntp.org
+3.
+ Restart the NTP client.
+ # service ntpd restart4.
+ Make sure NTP will start again upon reboot.
+ # chkconfig ntpd onLicensing8.2.6. Licensing
+ Citrix XenServer Free version provides 30 days usage without a license. Following the 30 day trial, XenServer requires a free activation and license. You can choose to install a license now or skip this step. If you skip this step, you will need to install a license when you activate and license the XenServer.
+ 8.2.6.1. Getting and Deploying a License
+ If you choose to install a license now you will need to use the XenCenter to activate and get a license.
+ 1.
+ In XenCenter, click Tools > License manager.
+ 2.
+ Select your XenServer and select Activate Free XenServer.
+ 3.
+ Request a license.
+
+ You can install the license with XenCenter or using the xe command line tool.
+ Install CloudStack XenServer Support Package (CSP)8.2.7. Install CloudStack XenServer Support Package (CSP)
+ (Optional)
+
+ To enable security groups, elastic load balancing, and elastic IP on XenServer, download and install the CloudStack XenServer Support Package (CSP). After installing XenServer, perform the following additional steps on each XenServer host.
+ 1.
+ Download the CSP software onto the XenServer host from one of the following links:
+
+ For XenServer 6.0.2:
+
+ http://download.cloud.com/releases/3.0.1/XS-6.0.2/xenserver-cloud-supp.tgz
+
+ For XenServer 5.6 SP2:
+
+ http://download.cloud.com/releases/2.2.0/xenserver-cloud-supp.tgz
+
+ For XenServer 6.0:
+
+ http://download.cloud.com/releases/3.0/xenserver-cloud-supp.tgz
+ 2.
+ Extract the file:
+ # tar xf xenserver-cloud-supp.tgz3.
+ Run the following script:
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso4.
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+ # xe-switch-network-backend bridge
+ Restart the host machine when prompted.
+
+ The XenServer host is now ready to be added to CloudStack.
+ Primary Storage Setup for XenServer8.2.8. Primary Storage Setup for XenServer
+ CloudStack natively supports NFS, iSCSI and local storage. If you are using one of these storage types, there is no need to create the XenServer Storage Repository ("SR").
+
+ If, however, you would like to use storage connected via some other technology, such as FiberChannel, you must set up the SR yourself. To do so, perform the following steps. If you have your hosts in a XenServer pool, perform the steps on the master node. If you are working with a single XenServer which is not part of a cluster, perform the steps on that XenServer.
+ 1.
+ Connect FiberChannel cable to all hosts in the cluster and to the FiberChannel storage host.
+ 2.
+ Rescan the SCSI bus. Either use the following command or use XenCenter to perform an HBA rescan.
+ # scsi-rescan3.
+ Repeat step 2 on every host.
+ 4.
+ Check to be sure you see the new SCSI disk.
+ # ls /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -l
+ The output should look like this, although the specific file name will be different (scsi-<scsiID>):
+ lrwxrwxrwx 1 root root 9 Mar 16 13:47
+/dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -> ../../sdc
+5.
+ Repeat step 4 on every host.
+ 6.
+ On the storage server, run this command to get a unique ID for the new SR.
+ # uuidgen
+ The output should look like this, although the specific ID will be different:
+ e6849e96-86c3-4f2c-8fcc-350cc711be3d7.
+ Create the FiberChannel SR. In name-label, use the unique ID you just generated.
+
+# xe sr-create type=lvmohba shared=true
+device-config:SCSIid=360a98000503365344e6f6177615a516b
+name-label="e6849e96-86c3-4f2c-8fcc-350cc711be3d"
+
+ This command returns a unique ID for the SR, like the following example (your ID will be different):
+ 7a143820-e893-6c6a-236e-472da6ee66bf8.
+ To create a human-readable description for the SR, use the following command. In uuid, use the SR ID returned by the previous command. In name-description, set whatever friendly text you prefer.
+ # xe sr-param-set uuid=7a143820-e893-6c6a-236e-472da6ee66bf name-description="Fiber Channel storage repository"
+ Make note of the values you will need when you add this storage to CloudStack later (see Section 6.6, “Add Primary Storage”). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the name-label you set earlier (in this example, e6849e96-86c3-4f2c-8fcc-350cc711be3d).
+ 9.
+ (Optional) If you want to enable multipath I/O on a FiberChannel SAN, refer to the documentation provided by the SAN vendor.
+ iSCSI Multipath Setup for XenServer (Optional)8.2.9. iSCSI Multipath Setup for XenServer (Optional)
+ When setting up the storage repository on a Citrix XenServer, you can enable multipath I/O, which uses redundant physical components to provide greater reliability in the connection between the server and the SAN. To enable multipathing, use a SAN solution that is supported for Citrix servers and follow the procedures in Citrix documentation. The following links provide a starting point:
+ •
+ http://support.citrix.com/article/CTX118791
+ •
+ http://support.citrix.com/article/CTX125403
+
+ You can also ask your SAN vendor for advice about setting up your Citrix repository for multipathing.
+
+ Make note of the values you will need when you add this storage to the CloudStack later (see Section 6.6, “Add Primary Storage”). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the same name used to create the SR.
+
+ If you encounter difficulty, address the support team for the SAN provided by your vendor. If they are not able to solve your issue, see Contacting Support.
+ Physical Networking Setup for XenServer8.2.10. Physical Networking Setup for XenServer
+ Once XenServer has been installed, you may need to do some additional network configuration. At this point in the installation, you should have a plan for what NICs the host will have and what traffic each NIC will carry. The NICs should be cabled as necessary to implement your plan.
+
+ If you plan on using NIC bonding, the NICs on all hosts in the cluster must be cabled exactly the same. For example, if eth0 is in the private bond on one host in a cluster, then eth0 must be in the private bond on all hosts in the cluster.
+
+ The IP address assigned for the management network interface must be static. It can be set on the host itself or obtained via static DHCP.
+
+ CloudStack configures network traffic of various types to use different NICs or bonds on the XenServer host. You can control this process and provide input to the Management Server through the use of XenServer network name labels. The name labels are placed on physical interfaces or bonds and configured in CloudStack. In some simple cases the name labels are not required.
+ 8.2.10.1. Configuring Public Network with a Dedicated NIC for XenServer (Optional)
+ CloudStack supports the use of a second NIC (or bonded pair of NICs, described in Section 8.2.10.4, “NIC Bonding for XenServer (Optional)”) for the public network. If bonding is not used, the public network can be on any NIC and can be on different NICs on the hosts in a cluster. For example, the public network can be on eth0 on node A and eth1 on node B. However, the XenServer name-label for the public network must be identical across all hosts. The following examples set the network label to "cloud-public". After the management server is installed and running you must configure it with the name of the chosen network label (e.g. "cloud-public"); this is discussed in Section 4.5, “Management Server Installation”.
+
+ If you are using two NICs bonded together to create a public network, see Section 8.2.10.4, “NIC Bonding for XenServer (Optional)”.
+
+ If you are using a single dedicated NIC to provide public network access, follow this procedure on each new host that is added to CloudStack before adding the host.
+ 1.
+ Run xe network-list and find the public network. This is usually attached to the NIC that is public. Once you find the network make note of its UUID. Call this <UUID-Public>.
+ 2.
+ Run the following command.
+ # xe network-param-set name-label=cloud-public uuid=<UUID-Public>8.2.10.2. Configuring Multiple Guest Networks for XenServer (Optional)
+ CloudStack supports the use of multiple guest networks with the XenServer hypervisor. Each network is assigned a name-label in XenServer. For example, you might have two networks with the labels "cloud-guest" and "cloud-guest2". After the management server is installed and running, you must add the networks and use these labels so that CloudStack is aware of the networks.
+
+ Follow this procedure on each new host before adding the host to CloudStack:
+ 1.
+ Run xe network-list and find one of the guest networks. Once you find the network make note of its UUID. Call this <UUID-Guest>.
+ 2.
+ Run the following command, substituting your own name-label and uuid values.
+ # xe network-param-set name-label=<cloud-guestN> uuid=<UUID-Guest>3.
+ Repeat these steps for each additional guest network, using a different name-label and uuid each time.
+ 8.2.10.3. Separate Storage Network for XenServer (Optional)
+ You can optionally set up a separate storage network. This should be done first on the host, before implementing the bonding steps below. This can be done using one or two available NICs. With two NICs bonding may be done as above. It is the administrator's responsibility to set up a separate storage network.
+
+ Give the storage network a different name-label than what will be given for other networks.
+
+ For the separate storage network to work correctly, it must be the only interface that can ping the primary storage device's IP address. For example, if eth0 is the management network NIC, ping -I eth0 <primary storage device IP> must fail. In all deployments, secondary storage devices must be pingable from the management network NIC or bond. If a secondary storage device has been placed on the storage network, it must also be pingable via the storage network NIC or bond on the hosts as well.
+
+ You can set up two separate storage networks as well. For example, if you intend to implement iSCSI multipath, dedicate two non-bonded NICs to multipath. Each of the two networks needs a unique name-label.
+
+ If no bonding is done, the administrator must set up and name-label the separate storage network on all hosts (masters and slaves).
+
+ Here is an example to set up eth5 to access a storage network on 172.16.0.0/24.
+
+# xe pif-list host-name-label='hostname' device=eth5
+uuid(RO): ab0d3dd4-5744-8fae-9693-a022c7a3471d
+device ( RO): eth5
+#xe pif-reconfigure-ip DNS=172.16.3.3 gateway=172.16.0.1 IP=172.16.0.55 mode=static netmask=255.255.255.0 uuid=ab0d3dd4-5744-8fae-9693-a022c7a3471d8.2.10.4. NIC Bonding for XenServer (Optional)
+ XenServer supports Source Level Balancing (SLB) NIC bonding. Two NICs can be bonded together to carry public, private, and guest traffic, or some combination of these. Separate storage networks are also possible. Here are some example supported configurations:
+ •
+ 2 NICs on private, 2 NICs on public, 2 NICs on storage
+ •
+ 2 NICs on private, 1 NIC on public, storage uses management network
+ •
+ 2 NICs on private, 2 NICs on public, storage uses management network
+ •
+ 1 NIC for private, public, and storage
+
+ All NIC bonding is optional.
+
+ XenServer expects all nodes in a cluster will have the same network cabling and same bonds implemented. In an installation the master will be the first host that was added to the cluster and the slave hosts will be all subsequent hosts added to the cluster. The bonds present on the master set the expectation for hosts added to the cluster later. The procedure to set up bonds on the master and slaves are different, and are described below. There are several important implications of this:
+ •
+ You must set bonds on the first host added to a cluster. Then you must use xe commands as below to establish the same bonds in the second and subsequent hosts added to a cluster.
+ •
+ Slave hosts in a cluster must be cabled exactly the same as the master. For example, if eth0 is in the private bond on the master, it must be in the management network for added slave hosts.
+ 8.2.10.4.1. Management Network Bonding
+ The administrator must bond the management network NICs prior to adding the host to CloudStack.
+ 8.2.10.4.2. Creating a Private Bond on the First Host in the Cluster
+ Use the following steps to create a bond in XenServer. These steps should be run on only the first host in a cluster. This example creates the cloud-private network with two physical NICs (eth0 and eth1) bonded into it.
+ 1.
+ Find the physical NICs that you want to bond together.
+ # xe pif-list host-name-label='hostname' device=eth0
+# xe pif-list host-name-label='hostname' device=eth1
+ These command shows the eth0 and eth1 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
+ 2.
+ Create a new network for the bond. For example, a new network with name "cloud-private".
+
+ This label is important. CloudStack looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the management network.
+ # xe network-create name-label=cloud-private
+# xe bond-create network-uuid=[uuid of cloud-private created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+ Now you have a bonded pair that can be recognized by CloudStack as the management network.
+ 8.2.10.4.3. Public Network Bonding
+ Bonding can be implemented on a separate, public network. The administrator is responsible for creating a bond for the public network if that network will be bonded and will be separate from the management network.
+ 8.2.10.4.4. Creating a Public Bond on the First Host in the Cluster
+ These steps should be run on only the first host in a cluster. This example creates the cloud-public network with two physical NICs (eth2 and eth3) bonded into it.
+ 1.
+ Find the physical NICs that you want to bond together.
+ #xe pif-list host-name-label='hostname' device=eth2
+# xe pif-list host-name-label='hostname' device=eth3
+ These command shows the eth2 and eth3 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
+ 2.
+ Create a new network for the bond. For example, a new network with name "cloud-public".
+
+ This label is important. CloudStack looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the public network.
+ # xe network-create name-label=cloud-public
+# xe bond-create network-uuid=[uuid of cloud-public created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+ Now you have a bonded pair that can be recognized by CloudStack as the public network.
+ 8.2.10.4.5. Adding More Hosts to the Cluster
+ With the bonds (if any) established on the master, you should add additional, slave hosts. Run the following command for all additional hosts to be added to the cluster. This will cause the host to join the master in a single XenServer pool.
+ # xe pool-join master-address=[master IP] master-username=root
+master-password=[your password]8.2.10.4.6. Complete the Bonding Setup Across the Cluster
+ With all hosts added to the pool, run the cloud-setup-bond script. This script will complete the configuration and set up of the bonds across all hosts in the cluster.
+ 1.
+ Copy the script from the Management Server in /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+ 2.
+ Run the script:
+ # ./cloud-setup-bonding.sh
+ Now the bonds are set up and configured properly across the cluster.
+ Upgrading XenServer Versions8.2.11. Upgrading XenServer Versions
+ This section tells how to upgrade XenServer software on CloudStack hosts. The actual upgrade is described in XenServer documentation, but there are some additional steps you must perform before and after the upgrade.
+ Note
+ Be sure the hardware is certified compatible with the new version of XenServer.
+
+ To upgrade XenServer:
+ 1.
+ Upgrade the database. On the Management Server node:
+ a.
+ Back up the database:
+ # mysqldump --user=root --databases cloud > cloud.backup.sql
+# mysqldump --user=root --databases cloud_usage > cloud_usage.backup.sqlb.
+ You might need to change the OS type settings for VMs running on the upgraded hosts.
+ •
+ If you upgraded from XenServer 5.6 GA to XenServer 5.6 SP2, change any VMs that have the OS type CentOS 5.5 (32-bit), Oracle Enterprise Linux 5.5 (32-bit), or Red Hat Enterprise Linux 5.5 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit).
+ •
+ If you upgraded from XenServer 5.6 SP2 to XenServer 6.0.2, change any VMs that have the OS type CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux 5.6 (32-bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.6 (32-bit) , or Red Hat Enterprise Linux 5.7 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit).
+ •
+ If you upgraded from XenServer 5.6 to XenServer 6.0.2, do all of the above.
+ c.
+ Restart the Management Server and Usage Server. You only need to do this once for all clusters.
+ # service cloud-management start
+# service cloud-usage start2.
+ Disconnect the XenServer cluster from CloudStack.
+ a.
+ Log in to the CloudStack UI as root.
+ b.
+ Navigate to the XenServer cluster, and click Actions – Unmanage.
+ c.
+ Watch the cluster status until it shows Unmanaged.
+ 3.
+ Log in to one of the hosts in the cluster, and run this command to clean up the VLAN:
+ # . /opt/xensource/bin/cloud-clean-vlan.sh4.
+ Still logged in to the host, run the upgrade preparation script:
+ # /opt/xensource/bin/cloud-prepare-upgrade.sh
+ Troubleshooting: If you see the error "can't eject CD," log in to the VM and umount the CD, then run the script again.
+ 5.
+ Upgrade the XenServer software on all hosts in the cluster. Upgrade the master first.
+ a.
+ Live migrate all VMs on this host to other hosts. See the instructions for live migration in the Administrator's Guide.
+
+ Troubleshooting: You might see the following error when you migrate a VM:
+ [root@xenserver-qa-2-49-4 ~]# xe vm-migrate live=true host=xenserver-qa-2-49-5 vm=i-2-8-VM
+You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected.
+vm: b6cf79c8-02ee-050b-922f-49583d9f1a14 (i-2-8-VM)
+ To solve this issue, run the following:
+ # /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14b.
+ Reboot the host.
+ c.
+ Upgrade to the newer version of XenServer. Use the steps in XenServer documentation.
+ d.
+ After the upgrade is complete, copy the following files from the management server to this host, in the directory locations shown below:
+
+
+ Copy this Management Server file...
+
+
+
+ ...to this location on the XenServer host
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-clean-vlan.sh
+
+
+
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+ e.
+ Run the following script:
+ # /opt/xensource/bin/setupxenserver.sh
+ Troubleshooting: If you see the following error message, you can safely ignore it.
+ mv: cannot stat `/etc/cron.daily/logrotate': No such file or directoryf.
+ Plug in the storage repositories (physical block devices) to the XenServer host:
+ # for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; done
+ Note: If you add a host to this XenServer pool, you need to migrate all VMs on this host to other hosts, and eject this host from XenServer pool.
+ 6.
+ Repeat these steps to upgrade every host in the cluster to the same version of XenServer.
+ 7.
+ Run the following command on one host in the XenServer cluster to clean up the host tags:
+ # for host in $(xe host-list | grep ^uuid | awk '{print $NF}') ; do xe host-param-clear uuid=$host param-name=tags; done;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.
+ 8.
+ Reconnect the XenServer cluster to CloudStack.
+ a.
+ Log in to the CloudStack UI as root.
+ b.
+ Navigate to the XenServer cluster, and click Actions – Manage.
+ c.
+ Watch the status to see that all the hosts come up.
+ 9.
+ After all hosts are up, run the following on one host in the cluster:
+ # /opt/xensource/bin/cloud-clean-vlan.shVMware vSphere Installation and Configuration8.3. VMware vSphere Installation and Configuration
+ If you want to use the VMware vSphere hypervisor to run guest virtual machines, install vSphere on the host(s) in your cloud.
+ System Requirements for vSphere Hosts8.3.1. System Requirements for vSphere Hosts8.3.1.1. Software requirements:•
+ vSphere and vCenter, both version 4.1 or 5.0.
+
+ vSphere Standard is recommended. Note however that customers need to consider the CPU constraints in place with vSphere licensing. See http://www.vmware.com/files/pdf/vsphere_pricing.pdf and discuss with your VMware sales representative.
+
+ vCenter Server Standard is recommended.
+ •
+ 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.
+ Apply All Necessary Hotfixes
+ The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+ 8.3.1.2. Hardware requirements:•
+ The host must be certified as compatible with vSphere. See the VMware Hardware Compatibility Guide at http://www.vmware.com/resources/compatibility/search.php.
+ •
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled).
+ •
+ All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+ •
+ 64-bit x86 CPU (more cores results in better performance)
+ •
+ Hardware virtualization support required
+ •
+ 4 GB of memory
+ •
+ 36 GB of local disk
+ •
+ At least 1 NIC
+ •
+ Statically allocated IP Address
+ 8.3.1.3. vCenter Server requirements:•
+ Processor - 2 CPUs 2.0GHz or higher Intel or AMD x86 processors. Processor requirements may be higher if the database runs on the same machine.
+ •
+ Memory - 3GB RAM. RAM requirements may be higher if your database runs on the same machine.
+ •
+ Disk storage - 2GB. Disk requirements may be higher if your database runs on the same machine.
+ •
+ Microsoft SQL Server 2005 Express disk requirements. The bundled database requires up to 2GB free disk space to decompress the installation archive.
+ •
+ Networking - 1Gbit or 10Gbit.
+
+ For more information, see "vCenter Server and the vSphere Client Hardware Requirements" at http://pubs.vmware.com/vsp40/wwhelp/wwhimpl/js/html/wwhelp.htm#href=install/c_vc_hw.html.
+ 8.3.1.4. Other requirements:•
+ VMware vCenter Standard Edition 4.1 or 5.0 must be installed and available to manage the vSphere hosts.
+ •
+ vCenter must be configured to use the standard port 443 so that it can communicate with the CloudStack Management Server.
+ •
+ You must re-install VMware ESXi if you are going to re-use a host from a previous install.
+ •
+ CloudStack requires VMware vSphere 4.1 or 5.0. VMware vSphere 4.0 is not supported.
+ •
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled). All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+ •
+ The CloudStack management network must not be configured as a separate virtual network. The CloudStack management network is the same as the vCenter management network, and will inherit its configuration. See Section 8.3.5.2, “Configure vCenter Management Network”.
+ •
+ CloudStack requires ESXi. ESX is not supported.
+ •
+ All resources used for CloudStack must be used for CloudStack only. CloudStack cannot share instance of ESXi or storage with other management consoles. Do not share the same storage volumes that will be used by CloudStack with a different set of ESXi servers that are not managed by CloudStack.
+ •
+ Put all target ESXi hypervisors in a cluster in a separate Datacenter in vCenter.
+ •
+ The cluster that will be managed by CloudStack should not contain any VMs. Do not run the management server, vCenter or any other VMs on the cluster that is designated for CloudStack use. Create a separate cluster for use of CloudStack and make sure that they are no VMs in this cluster.
+ •
+ All the required VLANS must be trunked into all network switches that are connected to the ESXi hypervisor hosts. These would include the VLANS for Management, Storage, vMotion, and guest VLANs. The guest VLAN (used in Advanced Networking; see Network Setup) is a contiguous range of VLANs that will be managed by CloudStack.
+ Preparation Checklist for VMware8.3.2. Preparation Checklist for VMware
+ For a smoother installation, gather the following information before you start:
+ •
+ Information listed in Section 8.3.2.1, “vCenter Checklist”
+ •
+ Information listed in Section 8.3.2.2, “Networking Checklist for VMware”
+ 8.3.2.1. vCenter Checklist
+ You will need the following information about vCenter.
+
+
+ vCenter Requirement
+
+
+
+ Value
+
+
+
+ Notes
+
+
+
+ vCenter User
+
+
+
+
+
+
+ This user must have admin privileges.
+
+
+
+ vCenter User Password
+
+
+
+
+
+
+ Password for the above user.
+
+
+
+ vCenter Datacenter Name
+
+
+
+
+
+
+ Name of the datacenter.
+
+
+
+ vCenter Cluster Name
+
+
+
+
+
+
+ Name of the cluster.
+
+ 8.3.2.2. Networking Checklist for VMware
+ You will need the following information about VLAN.
+
+
+ VLAN Information
+
+
+
+ Value
+
+
+
+ Notes
+
+
+
+ ESXi VLAN
+
+
+
+
+
+
+ VLAN on which all your ESXi hypervisors reside.
+
+
+
+ ESXI VLAN IP Address
+
+
+
+
+
+
+ IP Address Range in the ESXi VLAN. One address per Virtual Router is used from this range.
+
+
+
+ ESXi VLAN IP Gateway
+
+
+
+
+
+
+
+
+
+ ESXi VLAN Netmask
+
+
+
+
+
+
+
+
+
+ Management Server VLAN
+
+
+
+
+
+
+ VLAN on which the CloudStack Management server is installed.
+
+
+
+ Public VLAN
+
+
+
+
+
+
+ VLAN for the Public Network.
+
+
+
+ Public VLAN Gateway
+
+
+
+
+
+
+
+
+
+ Public VLAN Netmask
+
+
+
+
+
+
+
+
+
+ Public VLAN IP Address Range
+
+
+
+
+
+
+ Range of Public IP Addresses available for CloudStack use. These addresses will be used for virtual router on CloudStack to route private traffic to external networks.
+
+
+
+ VLAN Range for Customer use
+
+
+
+
+
+
+ A contiguous range of non-routable VLANs. One VLAN will be assigned for each customer.
+
+ vSphere Installation Steps8.3.3. vSphere Installation Steps1.
+ If you haven't already, you'll need to download and purchase vSphere from the VMware Website (https://www.vmware.com/tryvmware/index.php?p=vmware-vsphere&lp=1) and install it by following the VMware vSphere Installation Guide.
+ 2.
+ Following installation, perform the following configuration, which are described in the next few sections:
+
+
+ Required
+
+
+
+ Optional
+
+
+
+ ESXi host setup
+
+
+
+ NIC bonding
+
+
+
+ Configure host physical networking, virtual switch, vCenter Management Network, and extended port range
+
+
+
+ Multipath storage
+
+
+
+ Prepare storage for iSCSI
+
+
+
+
+
+
+ Configure clusters in vCenter and add hosts to them, or add hosts without clusters to vCenter
+
+
+
+
+ ESXi Host setup8.3.4. ESXi Host setup
+ All ESXi hosts should enable CPU hardware virtualization support in BIOS. Please note hardware virtualization support is not enabled by default on most servers.
+ Physical Host Networking8.3.5. Physical Host Networking
+ You should have a plan for cabling the vSphere hosts. Proper network configuration is required before adding a vSphere host to CloudStack. To configure an ESXi host, you can use vClient to add it as standalone host to vCenter first. Once you see the host appearing in the vCenter inventory tree, click the host node in the inventory tree, and navigate to the Configuration tab.
+
+ In the host configuration tab, click the "Hardware/Networking" link to bring up the networking configuration page as above.
+ 8.3.5.1. Configure Virtual Switch
+ A default virtual switch vSwitch0 is created. CloudStack requires all ESXi hosts in the cloud to use the same set of virtual switch names. If you change the default virtual switch name, you will need to configure one or more CloudStack configuration variables as well.
+ 8.3.5.1.1. Separating Traffic
+ CloudStack allows you to use vCenter to configure three separate networks per ESXi host. These networks are identified by the name of the vSwitch they are connected to. The allowed networks for configuration are public (for traffic to/from the public internet), guest (for guest-guest traffic), and private (for management and usually storage traffic). You can use the default virtual switch for all three, or create one or two other vSwitches for those traffic types.
+
+ If you want to separate traffic in this way you should first create and configure vSwitches in vCenter according to the vCenter instructions. Take note of the vSwitch names you have used for each traffic type. You will configure CloudStack to use these vSwitches.
+ 8.3.5.1.2. Increasing Ports
+ By default a virtual switch on ESXi hosts is created with 56 ports. We recommend setting it to 4088, the maximum number of ports allowed. To do that, click the "Properties..." link for virtual switch (note this is not the Properties link for Networking).
+
+ In vSwitch properties dialog, select the vSwitch and click Edit. You should see the following dialog:
+
+ In this dialog, you can change the number of switch ports. After you've done that, ESXi hosts are required to reboot in order for the setting to take effect.
+ 8.3.5.2. Configure vCenter Management Network
+ In the vSwitch properties dialog box, you may see a vCenter management network. This same network will also be used as the CloudStack management network. CloudStack requires the vCenter management network to be configured properly. Select the management network item in the dialog, then click Edit.
+
+ Make sure the following values are set:
+ •
+ VLAN ID set to the desired ID
+ •
+ vMotion enabled.
+ •
+ Management traffic enabled.
+
+ If the ESXi hosts have multiple VMKernel ports, and ESXi is not using the default value "Management Network" as the management network name, you must follow these guidelines to configure the management network port group so that CloudStack can find it:
+ •
+ Use one label for the management network port across all ESXi hosts.
+ •
+ In the CloudStack UI, go to Configuration - Global Settings and set vmware.management.portgroup to the management network label from the ESXi hosts.
+ 8.3.5.3. Extend Port Range for CloudStack Console Proxy
+ (Applies only to VMware vSphere version 4.x)
+
+ You need to extend the range of firewall ports that the console proxy works with on the hosts. This is to enable the console proxy to work with VMware-based VMs. The default additional port range is 59000-60000. To extend the port range, log in to the VMware ESX service console on each host and run the following commands:
+
+esxcfg-firewall -o 59000-60000,tcp,in,vncextras
+esxcfg-firewall -o 59000-60000,tcp,out,vncextras
+8.3.5.4. Configure NIC Bonding for vSphere
+ NIC bonding on vSphere hosts may be done according to the vSphere installation guide.
+ Storage Preparation for vSphere (iSCSI only)8.3.6. Storage Preparation for vSphere (iSCSI only)
+ Use of iSCSI requires preparatory work in vCenter. You must add an iSCSI target and create an iSCSI datastore.
+
+ If you are using NFS, skip this section.
+ 8.3.6.1. Enable iSCSI initiator for ESXi hosts1.
+ In vCenter, go to hosts and Clusters/Configuration, and click Storage Adapters link. You will see:
+ 2.
+ Select iSCSI software adapter and click Properties.
+ 3.
+ Click the Configure... button.
+ 4.
+ Check Enabled to enable the initiator.
+ 5.
+ Click OK to save.
+ 8.3.6.2. Add iSCSI target
+ Under the properties dialog, add the iSCSI target info:
+
+ Repeat these steps for all ESXi hosts in the cluster.
+ 8.3.6.3. Create an iSCSI datastore
+ You should now create a VMFS datastore. Follow these steps to do so:
+ 1.
+ Select Home/Inventory/Datastores.
+ 2.
+ Right click on the datacenter node.
+ 3.
+ Choose Add Datastore... command.
+ 4.
+ Follow the wizard to create a iSCSI datastore.
+
+ This procedure should be done on one host in the cluster. It is not necessary to do this on all hosts.
+ 8.3.6.4. Multipathing for vSphere (Optional)
+ Storage multipathing on vSphere nodes may be done according to the vSphere installation guide.
+ Add Hosts or Configure Clusters (vSphere)8.3.7. Add Hosts or Configure Clusters (vSphere)
+ Use vCenter to create a vCenter cluster and add your desired hosts to the cluster. You will later add the entire cluster to CloudStack. (see Section 6.4.2, “Add Cluster: vSphere”).
+ Chapter 9.Chapter 9. Choosing a Deployment ArchitectureChoosing a Deployment Architecture
+ The architecture used in a deployment will vary depending on the size and purpose of the deployment. This section contains examples of deployment architecture, including a small-scale deployment useful for test and trial deployments and a fully-redundant large-scale setup for production deployments.
+ Small-Scale Deployment9.1. Small-Scale Deployment
+ This diagram illustrates the network architecture of a small-scale CloudStack deployment.
+ •
+ A firewall provides a connection to the Internet. The firewall is configured in NAT mode. The firewall forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+ •
+ A layer-2 switch connects all physical servers and storage.
+ •
+ A single NFS server functions as both the primary and secondary storage.
+ •
+ The Management Server is connected to the management network.
+ Large-Scale Redundant Setup9.2. Large-Scale Redundant Setup
+ This diagram illustrates the network architecture of a large-scale CloudStack deployment.
+ •
+ A layer-3 switching layer is at the core of the data center. A router redundancy protocol like VRRP should be deployed. Typically high-end core switches also include firewall modules. Separate firewall appliances may also be used if the layer-3 switch does not have integrated firewall capabilities. The firewalls are configured in NAT mode. The firewalls provide the following functions:
+ •
+ Forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+ •
+ When the cloud spans multiple zones, the firewalls should enable site-to-site VPN such that servers in different zones can directly reach each other.
+ •
+ A layer-2 access switch layer is established for each pod. Multiple switches can be stacked to increase port count. In either case, redundant pairs of layer-2 switches should be deployed.
+ •
+ The Management Server cluster (including front-end load balancers, Management Server nodes, and the MySQL database) is connected to the management network through a pair of load balancers.
+ •
+ Secondary storage servers are connected to the management network.
+ •
+ Each pod contains storage and computing servers. Each storage and computing server should have redundant NICs connected to separate layer-2 access switches.
+ Separate Storage Network9.3. Separate Storage Network
+ In the large-scale redundant setup described in the previous section, storage traffic can overload the management network. A separate storage network is optional for deployments. Storage protocols such as iSCSI are sensitive to network delays. A separate storage network ensures guest network traffic contention does not impact storage performance.
+ Multi-Node Management Server9.4. Multi-Node Management Server
+ The CloudStack Management Server is deployed on one or more front-end servers connected to a single MySQL database. Optionally a pair of hardware load balancers distributes requests from the web. A backup management server set may be deployed using MySQL replication at a remote site to add DR capabilities.
+
+ The administrator must decide the following.
+ •
+ Whether or not load balancers will be used.
+ •
+ How many Management Servers will be deployed.
+ •
+ Whether MySQL replication will be deployed to enable disaster recovery.
+ Multi-Site Deployment9.5. Multi-Site Deployment
+ The CloudStack platform scales well into multiple sites through the use of zones. The following diagram shows an example of a multi-site deployment.
+
+ Data Center 1 houses the primary Management Server as well as zone 1. The MySQL database is replicated in real time to the secondary Management Server installation in Data Center 2.
+
+ This diagram illustrates a setup with a separate storage network. Each server has four NICs, two connected to pod-level network switches and two connected to storage network switches.
+
+ There are two ways to configure the storage network:
+ •
+ Bonded NIC and redundant switches can be deployed for NFS. In NFS deployments, redundant switches and bonded NICs still result in one network (one CIDR block+ default gateway address).
+ •
+ iSCSI can take advantage of two separate storage networks (two CIDR blocks each with its own default gateway). Multipath iSCSI client can failover and load balance between separate storage networks.
+
+ This diagram illustrates the differences between NIC bonding and Multipath I/O (MPIO). NIC bonding configuration involves only one network. MPIO involves two separate networks.
+ Chapter 10.Chapter 10. Amazon Web Service Interface CompatibilityAmazon Web Service Interface CompatibilityAmazon Web Services EC2 Compatible Interface10.1. Amazon Web Services EC2 Compatible Interface
+ CloudStack can translate Amazon Web Services (AWS) API calls to native CloudStack API calls so that users can continue using existing AWS-compatible tools. This translation service runs as a separate web application in the same tomcat server as the management server of CloudStack, listening on the same port. This Amazon EC2-compatible API is accessible through a SOAP web service.
+ Note
+ This service was previously enabled by separate software called CloudBridge. It is now fully integrated with the CloudStack management server.
+
+ Limitations
+ •
+ Supported only in zones that use basic networking.
+ •
+ Available in fresh installations of CloudStack. Not available through upgrade of previous versions.
+ •
+ If you need to support features such as elastic IP, set up a Citrix NetScaler to provide this service. The commands such as ec2-associate-address will not work without EIP setup. Users running VMs in this zone will be using the NetScaler-enabled network offering (DefaultSharedNetscalerEIP and ELBNetworkOffering).
+ System Requirements10.2. System Requirements•
+ This interface complies with Amazon's WDSL version dated November 15, 2010, available at http://ec2.amazonaws.com/doc/2010-11-15/.
+ •
+ Compatible with the EC2 command-line tools EC2 tools v. 1.3.6230, which can be downloaded at http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-62308.zip.
+ Enabling the AWS API Compatible Interface10.3. Enabling the AWS API Compatible Interface
+ The software that provides AWS API compatibility is installed along with CloudPlatform. However, you must enable the feature and perform some setup steps.
+ 1.
+ Set the global configuration parameter enable.ec2.api to true. See Chapter 7, Setting Global Configuration Parameters.
+ 2.
+ Create a set of CloudStack service offerings with names that match the Amazon service offerings. You can do this through the CloudStack UI as described in the Administration Guide.
+ Warning
+ Be sure you have included the Amazon default service offering, m1.small.
+ 3.
+ If you did not already do so when you set the configuration parameter in step 1, restart the Management Server.
+ # service cloud-management restart4.
+ (Optional) The AWS API listens for requests on port 7080. If you prefer AWS API to listen on another port, you can change it as follows:
+ a.
+ Edit the files /etc/cloud/management/server.xml, /etc/cloud/management/server-nonssl.xml, and /etc/cloud/management/server-ssl.xml.
+ b.
+ In each file, find the tag <Service name="Catalina7080">. Under this tag, locate <Connector executor="tomcatThreadPool-internal" port= ....<.
+ c.
+ Change the port to whatever port you want to use, then save the files.
+ d.
+ Restart the Management Server.
+ Note
+ If you re-install CloudStack, you will have to make these changes again.
+ AWS API User Setup Steps10.4. AWS API User Setup Steps
+ In general, users need not be aware that they are using a translation service provided by CloudStack. They need only send AWS API calls to CloudStack's endpoint, and it will translate the calls to the native API. Users of the Amazon EC2 compatible interface will be able to keep their existing EC2 tools and scripts and use them with their CloudStack deployment, by specifying the endpoint of the management server and using the proper user credentials. In order to do this, each user must perform the following configuration steps:
+
+ •
+ Generate user credentials and register with the service.
+ •
+ Set up the environment variables for the EC2 command-line tools.
+ •
+ For SOAP access, use the endpoint http://CloudStack-management-server:8080/awsapi. The CloudStack-management-server can be specified by a fully-qualified domain name or IP address.
+
+
+ AWS API User Registration10.4.1. AWS API User Registration
+ Each user must perform a one-time registration. The user follows these steps:
+ 1.
+ Obtain the following by looking in the CloudStack UI, using the API, or asking the cloud administrator:
+ •
+ The CloudStack server's publicly available DNS name or IP address
+ •
+ The user account's API key and Secret key
+ 2.
+ Generate a private key and a self-signed X.509 certificate. The user substitutes their own desired storage location for /path/to/… below.
+
+
+$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /path/to/private_key.pem -out /path/to/cert.pem
+
+ 3.
+ Register the mapping from the X.509 certificate to the API/Secret keys. Download the following script from http://download.cloud.com/releases/3.0.3/cloudstack-aws-api-register and run it. Substitute the values that were obtained in step 1 in the URL below.
+
+
+$ cloudstack-aws-api-register --apikey=User’s CloudStack API key --secretkey=User’s CloudStack Secret key --cert=/path/to/cert.pem --url=http://CloudStack.server:8080/awsapi
+
+ Note
+ A user with an existing AWS certificate could choose to use the same certificate with CloudStack, but the public key would be uploaded to the CloudStack management server database.
+ AWS API Command-Line Tools Setup10.4.2. AWS API Command-Line Tools Setup
+ To use the EC2 command-line tools, the user must perform these steps:
+ 1.
+ Be sure you have the right version of EC2 Tools. The supported version is available at http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-62308.zip.
+ 2.
+ Set up the environment variables that will direct the tools to the server. As a best practice, you may wish to place these commands in a script that may be sourced before using the AWS API translation feature.
+ $ export EC2_CERT=/path/to/cert.pem
+$ export EC2_PRIVATE_KEY=/path/to/private_key.pem
+$ export EC2_URL=http://CloudStack.server:8080/awsapi
+$ export EC2_HOME=/path/to/EC2_tools_directoryUsing Timeouts to Ensure AWS API Command Completion10.5. Using Timeouts to Ensure AWS API Command Completion
+ The Amazon EC2 command-line tools have a default connection timeout. When used with CloudStack, a longer timeout might be needed for some commands. If you find that commands are not completing due to timeouts, you can gain more time for commands to finish by overriding the default timeouts on individual commands. You can add the following optional command-line parameters to any CloudStack-supported EC2 command:
+
+
+--connection-timeout TIMEOUT
+
+ Specifies a connection timeout (in seconds). Example:
+--connection-timeout 30
+
+
+
+--request-timeout TIMEOUT
+
+ Specifies a request timeout (in seconds). Example:
+--request-timeout 45
+
+
+ Example:
+ ec2-run-instances 2 –z us-test1 –n 1-3 --connection-timeout 120 --request-timeout 120Supported AWS API Calls10.6. Supported AWS API Calls
+ The following Amazon EC2 commands are supported by CloudStack when the AWS API compatibility feature is enabled. For a few commands, there are differences between the CloudStack and Amazon EC2 versions, and these differences are noted. The underlying SOAP call for each command is also given, for those who have built tools using those calls.
+ Table 10.1. Elastic IP API mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-allocate-address
+
+ AllocateAddress
+
+ associateIpAddress
+
+ ec2-associate-address
+
+ AssociateAddress
+
+ enableStaticNat
+
+ ec2-describe-addresses
+
+ DescribeAddresses
+
+ listPublicIpAddresses
+
+ ec2-diassociate-address
+
+ DisassociateAddress
+
+ disableStaticNat
+
+ ec2-release-address
+
+ ReleaseAddress
+
+ disassociateIpAddress
+ Table 10.2. Availability Zone API mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-describe-availability-zones
+
+ DescribeAvailabilityZones
+
+ listZones
+ Table 10.3. Images API mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-create-image
+
+ CreateImage
+
+ createTemplate
+
+ ec2-deregister
+
+ DeregisterImage
+
+ DeleteTemplate
+
+ ec2-describe-images
+
+ DescribeImages
+
+ listTemplates
+
+ ec2-register
+
+ RegisterImage
+
+ registerTemplate
+ Table 10.4. Image Attributes API mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-describe-image-attribute
+
+ DescribeImageAttribute
+
+ listTemplatePermissions
+
+ ec2-modify-image-attribute
+
+ ModifyImageAttribute
+
+ updateTemplatePermissions
+
+ ec2-reset-image-attribute
+
+ ResetImageAttribute
+
+ updateTemplatePermissions
+ Table 10.5. Instances API mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-describe-instances
+
+ DescribeInstances
+
+ listVirtualMachines
+
+ ec2-run-instances
+
+ RunInstances
+
+ deployVirtualMachine
+
+ ec2-reboot-instances
+
+ RebootInstances
+
+ rebootVirtualMachine
+
+ ec2-start-instances
+
+ StartInstances
+
+ startVirtualMachine
+
+ ec2-stop-instances
+
+ StopInstances
+
+ stopVirtualMachine
+
+ ec2-terminate-instances
+
+ TerminateInstances
+
+ destroyVirtualMachine
+ Table 10.6. Instance Attributes Mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-describe-instance-attribute
+
+ DescribeInstanceAttribute
+
+ listVirtualMachines
+ Table 10.7. Keys Pairs Mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-add-keypair
+
+ CreateKeyPair
+
+ createSSHKeyPair
+
+ ec2-delete-keypair
+
+ DeleteKeyPair
+
+ deleteSSHKeyPair
+
+ ec2-describe-keypairs
+
+ DescribeKeyPairs
+
+ listSSHKeyPairs
+
+ ec2-import-keypair
+
+ ImportKeyPair
+
+ registerSSHKeyPair
+ Table 10.8. Passwords API Mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-get-password
+
+ GetPasswordData
+
+ getVMPassword
+ Table 10.9. Security Groups API Mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-authorize
+
+ AuthorizeSecurityGroupIngress
+
+ authorizeSecurityGroupIngress
+
+ ec2-add-group
+
+ CreateSecurityGroup
+
+ createSecurityGroup
+
+ ec2-delete-group
+
+ DeleteSecurityGroup
+
+ deleteSecurityGroup
+
+ ec2-describe-group
+
+ DescribeSecurityGroups
+
+ listSecurityGroups
+
+ ec2-revoke
+
+ RevokeSecurityGroupIngress
+
+ revokeSecurityGroupIngress
+ Table 10.10. Snapshots API Mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-create-snapshot
+
+ CreateSnapshot
+
+ createSnapshot
+
+ ec2-delete-snapshot
+
+ DeleteSnapshot
+
+ deleteSnapshot
+
+ ec2-describe-snapshots
+
+ DescribeSnapshots
+
+ listSnapshots
+ Table 10.11. Volumes API Mapping
+ EC2 command
+
+ SOAP call
+
+ CloudStack API call
+
+ ec2-attach-volume
+
+ AttachVolume
+
+ attachVolume
+
+ ec2-create-volume
+
+ CreateVolume
+
+ createVolume
+
+ ec2-delete-volume
+
+ DeleteVolume
+
+ deleteVolume
+
+ ec2-describe-volume
+
+ DescribeVolume
+
+ listVolumes
+
+ ec2-detach-volume
+
+ DetachVolume
+
+ detachVolume
+ Chapter 11.Chapter 11. Managing Networks and TrafficManaging Networks and Traffic
+ In a CloudStack, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN. The CloudStack virtual router is the main component providing networking features for guest traffic.
+ Guest Traffic11.1. Guest Traffic
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+
+ Figure 1 illustrates a typical guest traffic setup:
+
+ The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+
+ The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
+
+ Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
+ Networking in a Pod11.2. Networking in a Pod
+ Figure 2 illustrates network setup within a single pod. The hosts are connected to a pod-level switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
+
+ Servers are connected as follows:
+ •
+ Storage devices are connected to only the network that carries management traffic.
+ •
+ Hosts are connected to networks for both management traffic and public traffic.
+ •
+ Hosts are also connected to one or more networks carrying guest traffic.
+
+ We recommend the use of multiple physical Ethernet cards to implement each network interface as well as redundant switch fabric in order to maximize throughput and improve reliability.
+ Networking in a Zone11.3. Networking in a Zone
+ Figure 3 illustrates the network setup within a single zone.
+
+ A firewall for management traffic operates in the NAT mode. The network typically is assigned IP addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses in the 192.168.*.0/24 Class C private address space.
+
+ Each zone has its own set of public IP addresses. Public IP addresses from different zones do not overlap.
+ Basic Zone Physical Network Configuration11.4. Basic Zone Physical Network Configuration
+ In a basic network, configuring the physical network is fairly straightforward. You only need to configure one guest network to carry traffic that is generated by guest VMs. When you first add a zone to CloudPlatform, you set up the guest network through the Add Zone screens.
+ Advanced Zone Physical Network Configuration11.5. Advanced Zone Physical Network Configuration
+ Within a zone that uses advanced networking, you need to tell the Management Server how the physical network is set up to carry different kinds of traffic in isolation.
+ Configure Guest Traffic in an Advanced Zone11.5.1. Configure Guest Traffic in an Advanced Zone
+ These steps assume you have already logged in to the CloudStack UI. To configure the base guest network:
+ 1.
+ In the left navigation, choose Infrastructure. On Zones, click View More, then click the zone to which you want to add a network.
+ 2.
+ Click the Network tab.
+ 3.
+ Click Add guest network.
+
+ The Add guest network window is displayed:
+ 4.
+ Provide the following information:
+ •
+ Name. The name of the network. This will be user-visible
+ •
+ Display Text: The description of the network. This will be user-visible
+ •
+ Zone: The zone in which you are configuring the guest network.
+ •
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network
+ •
+ Guest Gateway: The gateway that the guests should use
+ •
+ Guest Netmask: The netmask in use on the subnet the guests will use
+ 5.
+ Click OK.
+ Configure Public Traffic in an Advanced Zone11.5.2. Configure Public Traffic in an Advanced Zone
+ In a zone that uses advanced networking, you need to configure at least one range of IP addresses for Internet traffic.
+ Using Multiple Guest Networks11.6. Using Multiple Guest Networks
+ In zones that use advanced networking, additional networks for guest traffic may be added at any time after the initial installation. You can also customize the domain name associated with the network by specifying a DNS suffix for each network.
+
+ A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has been created, although the user can go into the guest and remove the IP address from the NIC on a particular network.
+
+ Each VM has just one default network. The virtual router's DHCP reply will set the guest's default gateway as that for the default network. Multiple non-default networks may be added to a guest in addition to the single, required default network. The administrator can control which networks are available as the default network.
+
+ Additional networks can either be available to all accounts or be assigned to a specific account. Networks that are available to all accounts are zone-wide. Any user with access to the zone can create a VM with access to that network. These zone-wide networks provide little or no isolation between guests.Networks that are assigned to a specific account provide strong isolation.
+ Adding an Additional Guest Network11.6.1. Adding an Additional Guest Network1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ Click Add guest network. Provide the following information:
+ •
+ Name: The name of the network. This will be user-visible.
+ •
+ Display Text: The description of the network. This will be user-visible.
+ •
+ Zone. The name of the zone this network applies to. Each zone is a broadcast domain, and therefore each zone has a different IP range for the guest network. The administrator must configure the IP range for each zone.
+ •
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network.
+ •
+ Guest Gateway: The gateway that the guests should use.
+ •
+ Guest Netmask: The netmask in use on the subnet the guests will use.
+ 4.
+ Click Create.
+ Changing the Network Offering on a Guest Network11.6.2. Changing the Network Offering on a Guest Network
+ A user or administrator can change the network offering that is associated with an existing guest network.
+ •
+ Log in to the CloudStack UI as an administrator or end user.
+ •
+ If you are changing from a network offering that uses the CloudStack virtual router to one that uses external devices as network service providers, you must first stop all the VMs on the network. See Stopping and Starting VMs. Then return here and continue to the next step
+ •
+ In the left navigation, choose Network
+ •
+ Click the name of the network you want to modify
+
+ .
+ •
+ In Network Offering, choose the new network offering, then click Apply.
+ •
+ A prompt appears asking whether you want to keep the existing CIDR. This is to let you know that if you change the network offering, the CIDR will be affected. Choose No to proceed with the change.
+ •
+ Wait for the update to complete. Don’t try to restart VMs until after the network change is complete.
+ •
+ If you stopped any VMs in step 2, restart them.
+ Security Groups11.7. Security GroupsAbout Security Groups11.7.1. About Security Groups
+ Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In CloudStack 3.0.3 - 3.0.5, security groups are supported only in zones that use basic networking.
+ Note
+ In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
+
+
+ Each CloudStack account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.
+
+ Any CloudStack user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.
+
+ You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.
+
+ If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+ Adding a Security Group11.7.2. Adding a Security Group
+ A user or administrator can define a new security group.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network
+ 3.
+ In Select view, choose Security Groups.
+ 4.
+ Click Add Security Group.
+ 5.
+ Provide a name and description.
+ 6.
+ Click OK.
+
+ The new security group appears in the Security Groups Details tab.
+ 7.
+ To make the security group useful, continue to Adding Ingress and Egress Rules to a Security Group.
+ Enabling Security Groups11.7.3. Enabling Security Groups
+ In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide.
+ Adding Ingress and Egress Rules to a Security Group11.7.4. Adding Ingress and Egress Rules to a Security Group1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network
+ 3.
+ In Select view, choose Security Groups, then click the security group you want .
+ 4.
+ To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify what network traffic is allowed into VM instances in this security group. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+ •
+ Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow incoming traffic from all VMs in another security group
+ •
+ Protocol. The networking protocol that sources will use to send traffic to the security group. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+ •
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+ •
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be accepted.
+ •
+ CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+ •
+ Account, Security Group. (Add by Account only) To accept only traffic from another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter the same name you used in step 7.
+
+ The following example allows inbound HTTP access from anywhere:
+ 5.
+ To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been allowed in through an ingress rule
+ •
+ Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP address (CIDR) or an existing security group in a CloudStack account (Account). Choose Account if you want to allow outgoing traffic to all VMs in another security group.
+ •
+ Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+ •
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
+ •
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
+ •
+ CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+ •
+ Account, Security Group. (Add by Account only) To allow traffic to be sent to another security group, enter the CloudStack account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter its name.
+ 6.
+ Click Add.
+ External Firewalls and Load Balancers11.8. External Firewalls and Load Balancers
+ CloudStack is capable of replacing its Virtual Router with an external Juniper SRX device and an optional external NetScaler or F5 load balancer for gateway and load balancing services. In this case, the VMs use the SRX as their gateway.
+ Load Balancer Rules11.9. Load Balancer Rules
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.
+ Note
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudStack virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+ Guest IP Ranges11.10. Guest IP Ranges
+ The IP ranges for guest network traffic are set on a per-account basis by the user. This allows the users to configure their network in a fashion that will enable VPN linking between their guest network and their clients.
+ Acquiring a New IP Address11.11. Acquiring a New IP Address1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ Click the name of the network where you want to work with.
+ 4.
+ Click View IP Addresses.
+ 5.
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.
+ Releasing an IP Address11.12. Releasing an IP Address1.
+ Log in to the CloudPlatform UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ Click the name of the network where you want to work with.
+ 4.
+ Click View IP Addresses.
+ 5.
+ Click the IP address you want to release.
+ 6.
+ Click the Release IP button
+
+ .
+ Static NAT11.13. Static NAT
+ A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
+ IP Forwarding and Firewalling11.14. IP Forwarding and Firewalling
+ By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is translated via NAT to the public IP address and is allowed.
+
+ To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example, you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44. Then use port forwarding rules to direct traffic from individual ports within that range to specific ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public IP's port 33 to port 100 on one user VM's private IP.
+
+ For the steps to implement these rules, see Firewall Rules and Port Forwarding.
+ IP Load Balancing11.15. IP Load Balancing
+ The user may choose to associate the same public IP for multiple guests. CloudStack implements a TCP-level load balancer with the following policies.
+ •
+ Round-robin
+ •
+ Least connection
+ •
+ Source IP
+
+ This is similar to port forwarding but the destination may be multiple IP addresses.
+ DNS and DHCP11.16. DNS and DHCP
+ The Virtual Router provides DNS and DHCP services to the guests. It proxies DNS requests to the DNS server configured on the Availability Zone.
+ VPN11.17. VPN
+ CloudStack account owners can create virtual private networks (VPN) to access their virtual machines. If the guest network is instantiated from a network offering that offers the Remote Access VPN service, the virtual router (based on the System VM) is used to provide the service. CloudStack provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN. CloudStack does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.
+ Note
+ Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
+ •
+ Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
+ •
+ Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.
+ Configuring VPN11.17.1. Configuring VPN
+ To set up VPN for the cloud:
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, click Global Settings.
+ 3.
+ Set the following global configuration parameters.
+ •
+ remote.access.vpn.client.ip.range – The range of IP addressess to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
+ •
+ remote.access.vpn.psk.length – Length of the IPSec key.
+ •
+ remote.access.vpn.user.limit – Maximum number of VPN users per account.
+
+ To enable VPN for a particular network:
+ 1.
+ Log in as a user or administrator to the CloudStack UI.
+ 2.
+ In the left navigation, click Network.
+ 3.
+ Click the name of the network you want to work with.
+ 4.
+ Click View IP Addresses.
+ 5.
+ Click one of the displayed IP address names.
+ 6.
+ Click the Enable VPN button
+
+ .
+
+ The IPsec key is displayed in a popup window.
+ Using VPN with Windows11.17.2. Using VPN with Windows
+ The procedure to use VPN varies by Windows version. Generally, the user must edit the VPN properties and make sure that the default route is not the VPN. The following steps are for Windows L2TP clients on Windows Vista. The commands should be similar for other Windows versions.
+ 1.
+ Log in to the CloudStack UI and click on the source NAT IP for the account. The VPN tab should display the IPsec preshared key. Make a note of this and the source NAT IP. The UI also lists one or more users and their passwords. Choose one of these users, or, if none exists, add a user and password.
+ 2.
+ On the Windows box, go to Control Panel, then select Network and Sharing center. Click Setup a connection or network.
+ 3.
+ In the next dialog, select No, create a new connection.
+ 4.
+ In the next dialog, select Use my Internet Connection (VPN).
+ 5.
+ In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check Don't connect now.
+ 6.
+ In the next dialog, enter the user name and password selected in step 1.
+ 7.
+ Click Create.
+ 8.
+ Go back to the Control Panel and click Network Connections to see the new connection. The connection is not active yet.
+ 9.
+ Right-click the new connection and select Properties. In the Properties dialog, select the Networking tab.
+ 10.
+ In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key. Enter the preshared key from Step 1.
+ 11.
+ The connection is ready for activation. Go back to Control Panel -> Network Connections and double-click the created connection.
+ 12.
+ Enter the user name and password from Step 1.
+ Using VPN with Mac OS X11.17.3. Using VPN with Mac OS X
+ In Mac OS X, in Network Preferences - Advanced, make sure Send all traffic over VPN connection is not checked.
+ Setting Up a Site-to-Site VPN Connection11.17.4. Setting Up a Site-to-Site VPN Connection
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+ •
+ Cisco ISR with IOS 12.4 or later
+ •
+ Juniper J-Series routers with JunOS 9.5 or later
+ Note
+ In addition to the specific Cisco and Juniper devices listed above, the expectation is that any Cisco or Juniper device running on the supported operating systems are able to establish VPN connections.
+
+ To set up a Site-to-Site VPN connection, perform the following:
+ 1.
+ Create a Virtual Private Cloud (VPC).
+
+ See Section 11.19, “Configuring a Virtual Private Cloud”.
+ 2.
+ Create a VPN Customer Gateway.
+ 3.
+ Create a VPN gateway for the VPC that you created.
+ 4.
+ Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
+ 11.17.4.1. Creating and Updating a VPN Customer GatewayNote
+ A VPN customer gateway can be connected to only one VPN gateway at a time.
+
+ To add a VPN Customer Gateway:
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPN Customer Gateway.
+ 4.
+ Click Add site-to-site VPN.
+
+ Provide the following information:
+ •
+ Name: A unique name for the VPN customer gateway you create.
+ •
+ Gateway: The IP address for the remote gateway.
+ •
+ CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be RFC1918-compliant.
+ •
+ IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share a secret key. This key value is used to authenticate the customer gateway and the VPC VPN gateway to each other.
+ Note
+ The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.
+ •
+ IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is accomplished through the Preshared Keys.
+ Note
+ The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.
+ •
+ IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.
+ •
+ IKE DH: A public-key cryptography protocol which allows two parties to establish a shared secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).
+ •
+ ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192, AES256, and 3DES.
+ Note
+ The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.
+ •
+ ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash algorithms are SHA1 and MD5.
+ •
+ Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised. This property enforces a new Diffie-Hellman key exchange. It provides the keying material that has greater key material life and thereby greater resistance to cryptographic attacks. The available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key exchanges increase as the DH groups grow larger, as does the time of the exchanges.
+ Note
+ When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.
+ •
+ IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is 86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.
+ •
+ ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a new IPsec encryption and authentication session keys.
+ •
+ Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual router to query the liveliness of its IKE peer at regular intervals. It’s recommended to have the same configuration of DPD on both side of VPN connection.
+ 5.
+ Click OK.
+ Updating and Removing a VPN Customer Gateway
+ You can update a customer gateway either with no VPN connection, or related VPN connection is in error state.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPN Customer Gateway.
+ 4.
+ Select the VPN customer gateway you want to work with.
+ 5.
+ To modify the required parameters, click the Edit VPN Customer Gateway button
+
+ 6.
+ To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
+
+ 7.
+ Click OK.
+ 11.17.4.2. Creating a VPN gateway for the VPC1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select Site-to-Site VPN.
+
+ If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN prompts you to create a VPN gateway.
+ 7.
+ In the confirmation dialog, click Yes to confirm.
+
+ Within a few moments, the VPN gateway is created. You will be prompted to view the details of the VPN gateway you have created. Click Yes to confirm.
+
+ The following details are displayed in the VPN Gateway page:
+ •
+ IP Address
+ •
+ Account
+ •
+ Domain
+ 11.17.4.3. Creating a VPN Connection1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you create for the account are listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ASLs
+ 6.
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+ 7.
+ From the Select View drop-down, ensure that VPN Connection is selected.
+ 8.
+ Click Create VPN Connection.
+
+ The Create VPN Connection dialog is displayed:
+ 9.
+ Select the desired customer gateway, then click OK to confirm.
+
+ Within a few moments, the VPN Connection is displayed.
+
+ The following information on the VPN connection is displayed:
+ •
+ IP Address
+ •
+ Gateway
+ •
+ State
+ •
+ IPSec Preshared Key
+ •
+ IKE Policy
+ •
+ ESP Policy
+ 11.17.4.4. Restarting and Removing a VPN Connection1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ASLs
+ 6.
+ Select Site-to-Site VPN.
+
+ The Site-to-Site VPN page is displayed.
+ 7.
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+ All the VPN connections you created are displayed.
+ 8.
+ Select the VPN connection you want to work with.
+
+ The Details tab is displayed.
+ 9.
+ To remove a VPN connection, click the Delete VPN connection button
+
+
+ To restart a VPN connection, click the Reset VPN connection button present in the Details tab.
+
+ About Inter-VLAN Routing11.18. About Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You provision VLANs to the tiers your create, and VMs can be deployed on different tiers. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications, such as Web, Application, or Database. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+ The major advantages are:
+ •
+ The administrator can deploy a set of VLANs and allow users to deploy VMs on these VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that account.
+ Note
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+ •
+ The administrator can allow users create their own VPC and deploy the application. In this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that account.
+ •
+ Both administrators and users can create multiple VPCs. The guest network NIC is plugged to the VPC virtual router when the first VM is deployed in a tier.
+ •
+ The administrator can create the following gateways to send to or receive traffic from the VMs:
+ •
+ VPN Gateway: For more information, see Section 11.17.4.2, “Creating a VPN gateway for the VPC”.
+ •
+ Public Gateway: The public gateway for a VPC is added to the virtual router when the virtual router is created for VPC. The public gateway is not exposed to the end users. You are not allowed to list it, nor allowed to create any static routes.
+ •
+ Private Gateway: For more information, see Section 11.19.5, “Adding a Private Gateway to a VPC”.
+ •
+ Both administrators and users can create various possible destinations-gateway combinations. However, only one gateway of each type can be used in a deployment.
+
+ For example:
+ •
+ VLANs and Public Gateway: For example, an application is deployed in the cloud, and the Web application VMs communicate with the Internet.
+ •
+ VLANs, VPN Gateway, and Public Gateway: For example, an application is deployed in the cloud; the Web application VMs communicate with the Internet; and the database VMs communicate with the on-premise devices.
+ •
+ The administrator can define Access Control List (ACL) on the virtual router to filter the traffic among the VLANs or between the Internet and a VLAN. You can define ACL based on CIDR, port range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress type.
+
+ The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
+
+ To set up a multi-tier Inter-VLAN deployment, see Section 11.19, “Configuring a Virtual Private Cloud”.
+ Configuring a Virtual Private Cloud11.19. Configuring a Virtual Private CloudAbout Virtual Private Clouds11.19.1. About Virtual Private Clouds
+ CloudStack Virtual Private Cloud is a private, isolated part of CloudStack. A VPC can have its own virtual network topology that resembles a traditional physical network. You can launch VMs in the virtual network that can have private addresses in the range of your choice, for example: 10.0.0.0/16. You can define network tiers within your VPC network range, which in turn enables you to group similar kinds of instances based on IP address range.
+
+ For example, if a VPC has the private range 10.0.0.0/16, its guest networks can have the network ranges 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on.
+ Major Components of a VPC:
+ A VPC is comprised of the following network components:
+ •
+ VPC: A VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router.
+ •
+ Network Tiers: Each tier acts as an isolated network with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
+ •
+ Virtual Router: A virtual router is automatically created and started when you create a VPC. The virtual router connect the tiers and direct traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and DHCP services through its IP.
+ •
+ Public Gateway: The traffic to and from the Internet routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to the end user; therefore, static routes are not support for the public gateway.
+ •
+ Private Gateway: All the traffic to and from a private network routed to the VPC through the private gateway. For more information, see Section 11.19.5, “Adding a Private Gateway to a VPC”.
+ •
+ VPN Gateway: The VPC side of a VPN connection.
+ •
+ Site-to-Site VPN Connection: A hardware-based VPN connection between your VPC and your datacenter, home network, or co-location facility. For more information, see Section 11.17.4, “Setting Up a Site-to-Site VPN Connection”.
+ •
+ Customer Gateway: The customer side of a VPN Connection. For more information, see Section 11.17.4.1, “Creating and Updating a VPN Customer Gateway”.
+ •
+ NAT Instance: An instance that provides Port Address Translation for instances to access the Internet via the public gateway. For more information, see Section 11.19.9, “Enabling or Disabling Static NAT on a VPC”.
+ Network Architecture in a VPC
+ In a VPC, the following four basic options of network architectures are present:
+ •
+ VPC with a public gateway only
+ •
+ VPC with public and private gateways
+ •
+ VPC with public and private gateways and site-to-site VPN access
+ •
+ VPC with a private gateway only and site-to-site VPN access
+ Connectivity Options for a VPC
+ You can connect your VPC to:
+ •
+ The Internet through the public gateway.
+ •
+ The corporate datacenter by using a site-to-site VPN connection through the VPN gateway.
+ •
+ Both the Internet and your corporate datacenter by using both the public gateway and a VPN gateway.
+ VPC Network Considerations
+ Consider the following before you create a VPC:
+ •
+ A VPC, by default, is created in the enabled state.
+ •
+ A VPC can be created in Advance zone only, and can't belong to more than one zone at a time.
+ •
+ The default number of VPCs an account can create is 20. However, you can change it by using the max.account.vpcs global parameter, which controls the maximum number of VPCs an account is allowed to create.
+ •
+ The default number of tiers an account can create within a VPC is 3. You can configure this number by using the vpc.max.networks parameter.
+ •
+ Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be within the VPC CIDR range.
+ •
+ A tier belongs to only one VPC.
+ •
+ All network tiers inside the VPC should belong to the same account.
+ •
+ When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP is released only when the VPC is removed.
+ •
+ A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it cannot be used for StaticNAT or port forwarding.
+ •
+ The instances only have a private IP address that you provision. To communicate with the Internet, enable NAT to an instance that you launch in your VPC.
+ •
+ Only new networks can be added to a VPC. The maximum number of networks per VPC is limited by the value you specify in the vpc.max.networks parameter. The default value is three.
+ •
+ The load balancing service can be supported by only one tier inside the VPC.
+ •
+ If an IP address is assigned to a tier:
+ •
+ That IP can't be used by more than one tier at a time in the VPC. For example, if you have tiers A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A or B, but not for both.
+ •
+ That IP can't be used for StaticNAT, load balancing, or port forwarding rules for another guest network inside the VPC.
+ •
+ Remote access VPN is not supported in VPC networks.
+ Adding a Virtual Private Cloud11.19.2. Adding a Virtual Private Cloud
+ When creating the VPC, you simply provide the zone and a set of IP addresses for the VPC network address space. You specify this set of addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+ 4.
+ Click Add VPC. The Add VPC page is displayed as follows:
+
+ Provide the following information:
+ •
+ Name: A short name for the VPC that you are creating.
+ •
+ Description: A brief description of the VPC.
+ •
+ Zone: Choose the zone where you want the VPC to be available.
+ •
+ Super CIDR for Guest Networks: Defines the CIDR range for all the tiers (guest networks) within a VPC. When you create a tier, ensure that its CIDR is within the Super CIDR value you enter. The CIDR must be RFC1918 compliant.
+ •
+ DNS domain for Guest Networks: If you want to assign a special domain name, specify the DNS suffix. This parameter is applied to all the tiers within the VPC. That implies, all the tiers you create in the VPC belong to the same DNS domain. If the parameter is not specified, a DNS domain name is generated automatically.
+ Adding Tiers11.19.3. Adding Tiers
+ Tiers are distinct locations within a VPC that act as isolated networks, which do not have access to other tiers by default. Tiers are set up on different VLANs that can communicate with each other by using a virtual router. Tiers provide inexpensive, low latency network connectivity to other tiers within the VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+ Note
+ The end users can see their own VPCs, while root and domain admin can see any VPC they are authorized to see.
+ 4.
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Add new tier dialog is displayed, as follows:
+
+ If you have already created tiers, the VPC diagram is displayed. Click Create Tier to add a new tier.
+ 5.
+ Specify the following:
+
+ All the fields are mandatory.
+ •
+ Name: A unique name for the tier you create.
+ •
+ Network Offering: The following default network offerings are listed: DefaultIsolatedNetworkOfferingForVpcNetworksNoLB, DefaultIsolatedNetworkOfferingForVpcNetworks
+
+ In a VPC, only one tier can be created by using LB-enabled network offering.
+ •
+ Gateway: The gateway for the tier you create. Ensure that the gateway is within the Super CIDR range that you specified while creating the VPC, and is not overlapped with the CIDR of any existing tier within the VPC.
+ •
+ Netmask: The netmask for the tier you create.
+
+ For example, if the VPC CIDR is 10.0.0.0/16 and the network tier CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the netmask of the tier is 255.255.255.0.
+ 6.
+ Click OK.
+ 7.
+ Continue with configuring access control list for the tier.
+ Configuring Access Control List11.19.4. Configuring Access Control List
+ Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service is supported.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 5.
+ Select Network ACLs.
+
+ The Network ACLs page is displayed.
+ 6.
+ Click Add Network ACLs.
+
+ To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed in this tier.
+ •
+ CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or to the IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+ •
+ Protocol: The networking protocol that sources use to send traffic to the tier. The TCP and UDP protocols are typically used for data exchange and end-user communications. The ICMP protocol is typically used to send error messages or network monitoring data.
+ •
+ Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+ •
+ Select Tier: Select the tier for which you want to add this ACL rule.
+ •
+ ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
+ •
+ Traffic Type: Select the traffic type you want to apply.
+ •
+ Egress: To add an egress rule, select Egress from the Traffic type drop-down box and click Add. This specifies what type of traffic is allowed to be sent out of VM instances in this tier. If no egress rules are specified, all traffic from the tier is allowed out at the VPC virtual router. Once egress rules are specified, only the traffic specified in egress rules and the responses to any traffic that has been allowed in through an ingress rule are allowed out. No egress rule is required for the VMs in a tier to communicate with each other.
+ •
+ Ingress: To add an ingress rule, select Ingress from the Traffic type drop-down box and click Add. This specifies what network traffic is allowed into the VM instances in this tier. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+ Note
+ By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, create a new network ACL.
+ 7.
+ Click Add. The ACL rule is added.
+
+ To view the list of ACL rules you have added, click the desired tier from the Network ACLs page, then select the Network ACL tab.
+
+ You can edit the tags assigned to the ACL rules and delete the ACL rules you have created. Click the appropriate button in the Actions column.
+ Adding a Private Gateway to a VPC11.19.5. Adding a Private Gateway to a VPC
+ A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. No gateways with duplicated VLAN and IP are allowed in the same data center.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Private Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select Private Gateways.
+
+ The Gateways page is displayed.
+ 7.
+ Click Add new gateway:
+ 8.
+ Specify the following:
+ •
+ Physical Network: The physical network you have created in the zone.
+ •
+ IP Address: The IP address associated with the VPC gateway.
+ •
+ Gateway: The gateway through which the traffic is routed to and from the VPC.
+ •
+ Netmask: The netmask associated with the VPC gateway.
+ •
+ VLAN: The VLAN associated with the VPC gateway.
+
+ The new gateway appears in the list. You can repeat these steps to add more gateway for this VPC.
+ Deploying VMs to the Tier11.19.6. Deploying VMs to the Tier1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed.
+ 5.
+ Click the Add VM button of the tier for which you want to add a VM.
+
+ The Add Instance page is displayed.
+
+ Follow the on-screen instruction to add an instance. For information on adding an instance, see Adding Instances section in the Installation Guide.
+ Acquiring a New IP Address for a VPC11.19.7. Acquiring a New IP Address for a VPC
+ When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks within the VPC. The IPs are associated to the guest network only when the first port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP can't be associated to more than one network at a time.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding, load balancing, and static NAT rules.
+ Releasing an IP Address Alloted to a VPC11.19.8. Releasing an IP Address Alloted to a VPC
+ The IP address is a limited resource. If you no longer need a particular IP, you can disassociate it from its VPC and return it to the pool of available addresses. An IP address can be released from its tier, only when all the networking ( port forwarding, load balancing, or StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to the same VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC whose IP you want to release.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click the IP you want to release.
+ 8.
+ In the Details tab, click the Release IP button
+
+ Enabling or Disabling Static NAT on a VPC11.19.9. Enabling or Disabling Static NAT on a VPC
+ A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to allow Internet traffic to it. This section tells how to enable or disable static NAT for a particular IP address in a VPC.
+
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click the IP you want to work with.
+ 8.
+ In the Details tab,click the Static NAT button.
+
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+ 9.
+ If you are enabling static NAT, a dialog appears as follows:
+ 10.
+ Select the tier and the destination VM, then click Apply.
+ Adding Load Balancing Rules on a VPC11.19.10. Adding Load Balancing Rules on a VPC
+ A CloudStack user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Select IP Addresses.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+ 8.
+ In the Load Balancing node of the diagram, click View All.
+ 9.
+ Select the tier to which you want to apply the rule.
+ Note
+ In a VPC, the load balancing service is supported only on a single tier.
+ 10.
+ Specify the following:
+ •
+ Name: A name for the load balancer rule.
+ •
+ Public Port: The port that receives the incoming traffic to be balanced.
+ •
+ Private Port: The port that the VMs will use to receive the traffic.
+ •
+ Algorithm. Choose the load balancing algorithm you want CloudStack to use. CloudStack supports the following well-known algorithms:
+ •
+ Round-robin
+ •
+ Least connections
+ •
+ Source
+ •
+ Stickiness. (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
+ •
+ Add VMs: Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.
+
+ The new load balancing rule appears in the list. You can repeat these steps to add more load balancing rules for this IP address.
+ Adding a Port Forwarding Rule on a VPC11.19.11. Adding a Port Forwarding Rule on a VPC1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+ 5.
+ Click the Settings icon.
+
+ The following options are displayed.
+ •
+ IP Addresses
+ •
+ Gateways
+ •
+ Site-to-Site VPN
+ •
+ Network ACLs
+ 6.
+ Choose an existing IP address or acquire a new IP address. Click the name of the IP address in the list.
+
+ The IP Addresses page is displayed.
+ 7.
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+ 8.
+ In the Port Forwarding node of the diagram, click View All.
+ 9.
+ Select the tier to which you want to apply the rule.
+ 10.
+ Specify the following:
+ •
+ Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+ •
+ Private Port: The port on which the instance is listening for forwarded public traffic.
+ •
+ Protocol: The communication protocol in use between the two ports.
+ •
+ TCP
+ •
+ UDP
+ •
+ Add VM: Click Add VM. Select the name of the instance to which this rule applies, and click Apply.
+
+ You can test the rule by opening an ssh session to the instance.
+ Removing Tiers11.19.12. Removing Tiers
+ You can remove a tier from a VPC. A removed tier cannot be revoked. When a tier is removed, only the resources of the tier are expunged. All the network rules (port forwarding, load balancing and staticNAT) and the IP addresses associated to the tier are removed. The IP address still be belonging to the same VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPC that you have created for the account is listed in the page.
+ 4.
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+ The Configure VPC page is displayed. Locate the tier you want to work with.
+ 5.
+ Click the Remove VPC button:
+
+ Wait for some time for the tier to be removed.
+ Editing, Restarting, and Removing a Virtual Private Cloud11.19.13. Editing, Restarting, and Removing a Virtual Private CloudNote
+ Ensure that all the tiers are removed before you remove a VPC.
+ 1.
+ Log in to the CloudStack UI as an administrator or end user.
+ 2.
+ In the left navigation, choose Network.
+ 3.
+ In the Select view, select VPC.
+
+ All the VPCs that you have created for the account is listed in the page.
+ 4.
+ Select the VPC you want to work with.
+ 5.
+ To remove, click the Remove VPC button
+
+
+ You can edit the name and description of a VPC. To do that, select the VPC, then click the Edit button.
+
+
+ To restart a VPC, select the VPC, then click the Restart button.
+
+ Appendix A. Revision HistoryAppendix A. Revision History
+ Revision 1-0October 5 2012Jessica Tomechak , Radhika PC , Wido den Hollander
+ Initial publication
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Installation_Guide.xml b/docs/tmp/en-US/xml/Installation_Guide.xml
new file mode 100644
index 00000000000..cabaa96396f
--- /dev/null
+++ b/docs/tmp/en-US/xml/Installation_Guide.xml
@@ -0,0 +1,62 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ &PRODUCT; Installation Guide
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Installation Guide for &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/LDAPserver-for-user-authentication.xml b/docs/tmp/en-US/xml/LDAPserver-for-user-authentication.xml
new file mode 100644
index 00000000000..7d89ff6c2d2
--- /dev/null
+++ b/docs/tmp/en-US/xml/LDAPserver-for-user-authentication.xml
@@ -0,0 +1,60 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using an LDAP Server for User Authentication
+
+ You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate &PRODUCT; end-users. Just map &PRODUCT; 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 &PRODUCT; for matching common values such as the user’s email address and name. &PRODUCT; 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 &PRODUCT;, call the &PRODUCT; 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 &PRODUCT; permission to search on the LDAP server
+
+
+
+
+ SSL keystore and password, if SSL is used
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Preface.xml b/docs/tmp/en-US/xml/Preface.xml
new file mode 100644
index 00000000000..e43513f4caa
--- /dev/null
+++ b/docs/tmp/en-US/xml/Preface.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Preface
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Release_Notes.ent b/docs/tmp/en-US/xml/Release_Notes.ent
new file mode 100644
index 00000000000..7858ad5f2e0
--- /dev/null
+++ b/docs/tmp/en-US/xml/Release_Notes.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Release_Notes.fo b/docs/tmp/en-US/xml/Release_Notes.fo
new file mode 100644
index 00000000000..50e6b6e9de2
--- /dev/null
+++ b/docs/tmp/en-US/xml/Release_Notes.fo
@@ -0,0 +1,3237 @@
+
+Version 4.0.0-incubating Release Notes - Revised October 17, 2012 19:49 UTCDocBook XSL Stylesheets with Apache FOPVersion 4.0.0-incubating Release NotesTable of ContentsChapter 1. Submitting Feedback and Getting HelpChapter 2. Upgrade Instructions2.1. Upgrade from 3.0.2 to 4.0.0-incubating2.2. Upgrade from 2.2.14 to 4.0.0-incubatingChapter 3. Version 4.0.0-incubating3.1. What’s New in 4.0.0-incubating3.1.1. Inter-VLAN Routing3.1.2. Site-to-Site VPN3.1.3. Local Storage Support for Data Volumes3.1.4. Tags3.1.5. AWS API Changes for Tags3.1.6. Secure Console Access on XenServer3.1.7. Stopped VM3.1.8. Uploading an Existing Volume to a Virtual Machine3.1.9. Dedicated High-Availability Hosts3.1.10. Support for Amazon Web Services API3.1.11. The Nicira NVP Plugin3.1.12. Support for CAStor Cluster3.1.13. Clustered Logical Volume Manager Support for KVM3.1.14. Rados Block Device Support for KVM3.2. Issues Fixed in 4.0.0-incubating3.3. Known Issues in 4.0.0-incubatingChapter 4. API Changes from 3.0.2 to 4.0.0-incubating4.1. New API Commands in 4.0.0-incubating4.2. Changed API Commands in 4.0.0-incubatingVersion 4.0.0-incubating Release NotesApache CloudStack Version 4.0.0-incubating Release NotesRevised October 17, 2012 19:49 UTC
+
+
+ Apache CloudStackApache CloudStack Version 4.0.0-incubating Release NotesRevised October 17, 2012 19:49 UTCAuthorApache CloudStack
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+ Release notes for the Apache CloudStack 4.0.0-incubating release.
+ Version 4.0.0-incubating Release Notes1. Submitting Feedback and Getting Help2. Upgrade Instructions2.1. Upgrade from 3.0.2 to 4.0.0-incubating2.2. Upgrade from 2.2.14 to 4.0.0-incubating3. Version 4.0.0-incubating3.1. What’s New in 4.0.0-incubating3.2. Issues Fixed in 4.0.0-incubating3.3. Known Issues in 4.0.0-incubating4. API Changes from 3.0.2 to 4.0.0-incubating4.1. New API Commands in 4.0.0-incubating4.2. Changed API Commands in 4.0.0-incubatingChapter 1.Chapter 1. Submitting Feedback and Getting HelpSubmitting Feedback and Getting Help
+ The Apache CloudStack project has mailing lists for users and developers. These are the official channels of communication for the project and are the best way to get answers about using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users mailing list if you've deployed or are deploying CloudStack into production, and even for test deployments.
+
+ The CloudStack developer's mailing list (cloudstack-dev) is for discussions about CloudStack development, and is the best list for discussing possible bugs in CloudStack. Anyone contributing to CloudStack should be on this mailing list.
+
+ You can also report bugs in CloudStack using the Apache Defect Tracking System11https://issues.apache.org/jira/secure/CreateIssue!default.jspa.
+
+ To posts to the lists, you'll need to be subscribed. See the CloudStack Web site22http://incubator.apache.org/cloudstack/mailing-lists.html for instructions.
+ Chapter 2.Chapter 2. Upgrade InstructionsUpgrade InstructionsUpgrade from 3.0.2 to 4.0.0-incubating2.1. Upgrade from 3.0.2 to 4.0.0-incubating
+ Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note that some of the steps here are only required if you're using a specific hypervisor. The steps that are hypervisor-specific are called out with a note.
+ 1.
+ Ensure that you query your IP address usage records and process them or make a backup. During the upgrade you will lose the old IP address usage records.
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading, any existing IP address usage records in the old format will no longer be available.
+ 2.Note
+ The following upgrade instructions apply only if you're using VMware hosts. If you're not using VMware hosts, skip this step and move on to step 3: stopping all usage servers.
+
+ In each zone that includes VMware hosts, you need to add a new system VM template.
+ a.
+ While running the existing 3.0.2 system, log in to the UI as root administrator.
+ b.
+ In the left navigation bar, click Templates.
+ c.
+ In Select view, click Templates.
+ d.
+ Click Register template.
+
+ The Register template dialog box is displayed.
+ e.
+ In the Register template dialog box, specify the following values (do not change these):
+
+
+ Field
+
+
+
+ Value
+
+
+
+ Name
+
+
+
+ systemvm-vmware-3.0.0
+
+
+
+ Description
+
+
+
+ systemvm-vmware-3.0.0
+
+
+
+ URL
+
+
+
+ http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+
+ Zone
+
+
+
+ Choose the zone where this hypervisor is used
+
+
+
+ Hypervisor
+
+
+
+ VMware
+
+
+
+ Format
+
+
+
+ OVA
+
+
+
+ OS Type
+
+
+
+ Debian GNU/Linux 5.0 (32-bit)
+
+
+
+ Extractable
+
+
+
+ no
+
+
+
+ Password Enabled
+
+
+
+ no
+
+
+
+ Public
+
+
+
+ no
+
+
+
+ Featured
+
+
+
+ no
+
+ f.
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful.
+ 3.
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+ # service cloud-usage stop4.
+ Stop the Management Servers. Run this on all Management Server hosts.
+ # service cloud-management stop5.
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+ 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.
+ #mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp6.
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
+ 7.
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
+#yum update cloud-*
+
+#apt-get update
+#apt-get upgrade cloud-*
+
+
+ You will, of course, have to agree to the changes suggested by Yum or APT.
+ Note
+ If the upgrade output includes a message similar to the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+ warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+ Instructions follow in the next step.
+ 8.
+ If you have made changes to your copy of /etc/cloud/management/components.xml the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+ a.
+ Make a backup copy of /etc/cloud/management/components.xml. For example:
+ # mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backupb.
+ Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:
+ # cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xmlc.
+ Merge your changes from the backup file into the new components.xml.
+ # vi /etc/cloud/management/components.xmlNote
+ If you have more than one management server node, repeat the upgrade steps on each node.
+ 9.
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+ # service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. After confirmation, start the other Management Servers one at a time by running the same command on each node.
+ Note
+ Failing to restart the Management Server indicates a problem in the upgrade. Having the Management Server restarted without any issues indicates that the upgrade is successfully completed.
+ 10.
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
+ # service cloud-usage start
+ 11.Note
+ Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+ a.
+ Configure a yum or apt respository containing the CloudStack packages as outlined in the Installation Guide.
+ b.
+ Stop the running agent.
+
+ # service cloud-agent stop
+ c.
+ Update the agent software with one of the following command sets as appropriate for your environment.
+
+ # yum update cloud-*
+
+ # apt-get update
+
+ # apt-get upgrade cloud-*
+ d.
+ Start the agent.
+ # service cloud-agent starte.
+ Edit /etc/cloud/agent/agent.properties to change the resource parameter from "com.cloud.agent.resource.computing.LibvirtComputingResource" to "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
+ f.
+ Start the cloud agent and cloud management services.
+ g.
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+ 12.
+ Log in to the CloudStack UI as administrator, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+ Note
+ Troubleshooting: If login fails, clear your browser cache and reload the page.
+
+
+ Do not proceed to the next step until the hosts show in Up state.
+ 13.
+ If you are upgrading from 3.0.2, perform the following:
+ a.
+ Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter.
+
+ This port is used by the cloud-sysvmadm script at the end of the upgrade procedure. For information about how to set this parameter, see "Setting Global Configuration Parameters" in the Installation Guide.
+ b.
+ Restart the Management Server.
+ Note
+ If you don't want the admin port to remain open, you can set it to null after the upgrade is done and restart the management server.
+ 14.
+ Run the cloud-sysvmadm script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the -c and -r arguments. For example:
+
+ # nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+
+ # tail -f sysvm.log
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+ 15.
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+ 16.
+ Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+ a.
+ Disconnect the XenServer cluster from CloudStack.
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+ b.
+ To clean up the VLAN, log in to one XenServer host and run:
+
+ /opt/xensource/bin/cloud-clean-vlan.sh
+ c.
+ Now prepare the upgrade by running the following on one XenServer host:
+
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+
+ If you see a message like "can't eject CD", log in to the VM and unmount the CD, then run this script again.
+ d.
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /tmp.
+
+ On the Xen pool master, upload the hotfix with this command:
+
+ xe patch-upload file-name=XS602E003.xsupdate
+
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+ Note
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+ e.
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
+ # xe vm-list
+
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+ # xe vm-migrate live=true host=host-name vm=VM-name
+ Troubleshooting
+ If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
+
+ /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.
+ f.
+ Apply the hotfix. First, get the UUID of this host:
+ # xe host-list
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+ xe patch-apply host-uuid=host-uuid uuid=hotfix-uuidg.
+ Copy the following files from the CloudStack Management Server to the host.
+
+
+ Copy from here...
+
+
+
+ ...to here
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+ h.
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
+ •
+ Download the CSP software onto the XenServer host from one of the following links:
+
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+ •
+ Extract the file:
+ # tar xf xenserver-cloud-supp.tgz•
+ Run the following script:
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso•
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+ # xe-switch-network-backend bridgei.
+ Reboot this XenServer host.
+ j.
+ Run the following:
+ /opt/xensource/bin/setupxenserver.shNote
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+ k.
+ Run the following:
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;l.
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+ Troubleshooting Tip
+ If passwords which you know to be valid appear not to work after upgrade, or other UI issues are seen, try clearing your browser cache and reloading the UI page.
+ Upgrade from 2.2.14 to 4.0.0-incubating2.2. Upgrade from 2.2.14 to 4.0.0-incubating1.
+ Ensure that you query your IPaddress usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading to 4.0.0-incubating, any existing IP address usage records in the old format will no longer be available.
+ 2.
+ If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the instructions in the 2.2.14 Release Notes.
+ KVM Hosts
+ If KVM hypervisor is used in your cloud, be sure you completed the step to insert a valid username and password into the host_details table on each KVM node as described in the 2.2.14 Release Notes. This step is critical, as the database will be encrypted after the upgrade to 4.0.0-incubating.
+ 3.
+ While running the 2.2.14 system, log in to the UI as root administrator.
+ 4.
+ Using the UI, add a new System VM template for each hypervisor type that is used in your cloud. In each zone, add a system VM template for each hypervisor used in that zone
+ a.
+ In the left navigation bar, click Templates.
+ b.
+ In Select view, click Templates.
+ c.
+ Click Register template.
+
+ The Register template dialog box is displayed.
+ d.
+ In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):
+
+
+ Hypervisor
+
+
+
+ Description
+
+
+
+ XenServer
+
+
+
+ Name: systemvm-xenserver-3.0.0
+
+
+ Description: systemvm-xenserver-3.0.0
+
+
+ URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: XenServer
+
+
+ Format: VHD
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+ KVM
+
+
+
+ Name: systemvm-kvm-3.0.0
+
+
+ Description: systemvm-kvm-3.0.0
+
+
+ URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: KVM
+
+
+ Format: QCOW2
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+ VMware
+
+
+
+ Name: systemvm-vmware-3.0.0
+
+
+ Description: systemvm-vmware-3.0.0
+
+
+ URL: http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: VMware
+
+
+ Format: OVA
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+ 5.
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful
+ 6.
+ WARNING: If you use more than one type of hypervisor in your cloud, be sure you have repeated these steps to download the system VM template for each hypervisor type. Otherwise, the upgrade will fail.
+ 7.
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+ # service cloud-usage stop8.
+ Stop the Management Servers. Run this on all Management Server hosts.
+ # service cloud-management stop9.
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+ 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.
+ #mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp10.
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
+ 11.
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
+#yum update cloud-*
+
+#apt-get update
+#apt-get upgrade cloud-*
+
+
+ You will, of course, have to agree to the changes suggested by Yum or APT.
+ 12.
+ If you have made changes to your existing copy of the file components.xml in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+ Note
+ How will you know whether you need to do this? If the upgrade output in the previous step included a message like the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+ warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnewa.
+ Make a backup copy of your /etc/cloud/management/components.xml file. For example:
+ #mv/etc/cloud/management/components.xml/etc/cloud/management/components.xml-backupb.
+ Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:
+ #cp -ap /etc/cloud/management/components.xml.rpmnew/etc/cloud/management/components.xmlc.
+ Merge your changes from the backup file into the new components.xml file.
+ #vi/etc/cloud/management/components.xml
+13.
+ If you have made changes to your existing copy of the /etc/cloud/management/db.properties file in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+ a.
+ Make a backup copy of your file /etc/cloud/management/db.properties. For example:
+ #mv/etc/cloud/management/db.properties/etc/cloud/management/db.properties-backupb.
+ Copy /etc/cloud/management/db.properties.rpmnew to create a new /etc/cloud/management/db.properties:
+ #cp -ap /etc/cloud/management/db.properties.rpmnewetc/cloud/management/db.propertiesc.
+ Merge your changes from the backup file into the new db.properties file.
+ #vi/etc/cloud/management/db.properties14.
+ On the management server node, run the following command. It is recommended that you use the command-line flags to provide your own encryption keys. See Password and Key Encryption in the Installation Guide.
+ #cloud-setup-encryption -e encryption_type -m management_server_key -k database_key
+ When used without arguments, as in the following example, the default encryption type and keys will be used:
+ •
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file.
+ •
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the properties file. Default: password. It is highly recommended that you replace this with a more secure value
+ •
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value.
+ 15.
+ Repeat steps 10 - 14 on every management server node. If you provided your own encryption key in step 14, use the same key on all other management servers.
+ 16.
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+ # service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. You should see a message like "Complete! Done." After confirmation, start the other Management Servers one at a time by running the same command on each node.
+ 17.
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+ # service cloud-usage start18.
+ (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+ a.
+ Configure your CloudStack package repositories as outlined in the Installation Guide
+ b.
+ Stop the running agent.
+ # service cloud-agent stopc.
+ Update the agent software with one of the following command sets as appropriate.
+ #yum update cloud-*
+ #apt-get update
+#apt-get upgrade cloud-*
+d.
+ Start the agent.
+ # service cloud-agent starte.
+ Copy the contents of the agent.properties file to the new agent.properties file by using the following command
+ sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.propertiesf.
+ Start the cloud agent and cloud management services.
+ g.
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+ 19.
+ Log in to the CloudStack UI as admin, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
+ Do not proceed to the next step until the hosts show in the Up state. If the hosts do not come to the Up state, contact support.
+ 20.
+ Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers.
+ a.
+ Run the command once on one management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the "-c" and "-r" arguments. For example:
+ #nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+#tail -f sysvm.log
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+ b.
+ After the script terminates, check the log to verify correct execution:
+ #tail -f sysvm.log
+ The content should be like the following:
+
+Stopping and starting 1 secondary storage vm(s)...
+Done stopping and starting secondary storage vm(s)
+Stopping and starting 1 console proxy vm(s)...
+Done stopping and starting console proxy vm(s).
+Stopping and starting 4 running routing vm(s)...
+Done restarting router(s).
+21.
+ If you would like additional confirmation that the new system VM templates were correctly applied when these system VMs were rebooted, SSH into the System VM and check the version.
+
+ Use one of the following techniques, depending on the hypervisor.
+ XenServer or KVM:
+ SSH in by using the link local IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own link local IP.
+
+ Run the following commands on the XenServer or KVM host on which the system VM is present:
+ #ssh -i private-key-pathlink-local-ip -p 3922
+# cat /etc/cloudstack-release
+ The output should be like the following:
+ Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012ESXi
+ SSH in using the private IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own private IP.
+
+ Run the following commands on the Management Server:
+ #ssh -i private-key-pathprivate-ip -p 3922
+#cat/etc/cloudstack-release
+ The output should be like the following:
+ Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 201222.
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+ 23.
+ Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+ a.
+ Disconnect the XenServer cluster from CloudStack.
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+ b.
+ To clean up the VLAN, log in to one XenServer host and run:
+ /opt/xensource/bin/cloud-clean-vlan.shc.
+ Prepare the upgrade by running the following on one XenServer host:
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+ If you see a message like "can't eject CD", log in to the VM and umount the CD, then run this script again.
+ d.
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /root or /tmp.
+
+ On the Xen pool master, upload the hotfix with this command:
+ xe patch-upload file-name=XS602E003.xsupdate
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+ Note
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+ e.
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+ # xe vm-list
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+ #xe vm-migrate live=true host=host-name vm=VM-nameTroubleshooting
+ If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
+
+ /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.
+ f.
+ Apply the hotfix. First, get the UUID of this host:
+
+ # xe host-list
+
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+ xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid
+ g.
+ Copy the following files from the CloudStack Management Server to the host.
+
+
+ Copy from here...
+
+
+
+ ...to here
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+ h.
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
+ •
+ Download the CSP software onto the XenServer host from one of the following links:
+
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+ •
+ Extract the file:
+
+ # tar xf xenserver-cloud-supp.tgz
+ •
+ Run the following script:
+
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso
+ •
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
+ # xe-switch-network-backend bridge
+ i.
+ Reboot this XenServer host.
+ j.
+ Run the following:
+
+ /opt/xensource/bin/setupxenserver.sh
+ Note
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+ k.
+ Run the following:
+
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+ l.
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+ Chapter 3.Chapter 3. Version 4.0.0-incubatingVersion 4.0.0-incubatingWhat’s New in 4.0.0-incubating3.1. What’s New in 4.0.0-incubating
+ Apache CloudStack 4.0.0-incubating includes the following new features:
+ Inter-VLAN Routing3.1.1. Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You can provision VLANs to the tiers your create, and VMs can be deployed on different tiers, such as Web, Application, or Database. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+ Site-to-Site VPN3.1.2. Site-to-Site VPN
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+ •
+ Cisco ISR with IOS 12.4 or later
+ •
+ Juniper J-Series routers with JunOS 9.5 or later
+ Local Storage Support for Data Volumes3.1.3. Local Storage Support for Data Volumes
+ You can now create data volumes on local storage. The data volume is placed on the same XenServer host as the VM instance that is attached to the data volume. These local data volumes can be attached to virtual machines, detached, re-attached, and deleted just as with the other types of data volume. In earlier releases of CloudStack, only the root disk could be placed in local storage.
+
+ Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some of the benefits include reduced disk I/O latency and cost reduction from using inexpensive local disks.
+
+ In order for local volumes to be used, the feature must be enabled for the zone.
+
+ You can create a data disk offering for local storage. When a user creates a new VM, they can select this disk offering in order to cause the data disk volume to be placed in local storage.
+
+ You can not migrate a VM that has a volume in local storage to a different host, nor migrate the volume itself away to a different host. If you want to put a host into maintenance mode, you must first stop any VMs with local data volumes on that host.
+
+ Local storage support for volumes is available for XenServer, KVM, and VMware hypervisors.
+ Tags3.1.4. Tags
+ 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 new 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.
+
+ A new optional input parameter, "tags," has been added to 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:
+ 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 new "tags" input parameter:
+ •
+ listVirtualMachines
+ •
+ listVolumes
+ •
+ listSnapshots
+ •
+ listNetworks
+ •
+ listTemplates
+ •
+ listIsos
+ •
+ listFirewallRules
+ •
+ listPortForwardingRules
+ •
+ listPublicIpAddresses
+ •
+ listSecurityGroups
+ •
+ listLoadBalancerRules
+ •
+ listProjects
+ •
+ listVPCs
+ •
+ listNetworkACLs
+ •
+ listStaticRoutes
+ AWS API Changes for Tags3.1.5. AWS API Changes for Tags
+ Some changes have been made to the Amazon Web Services API compatibility support in order to accommodate the new tagging feature.
+
+ New APIs:
+
+
+ New API
+
+
+
+
+ Description
+
+
+
+
+ ec2-create-tags
+
+
+
+
+ Add tags to one or more resources.
+
+
+
+
+ ec2-delete-tags
+
+
+
+
+ Remove tags from one or more resources.
+
+
+
+ ec2-describe-tags
+
+
+ Show currently defined tags.
+
+
+
+ Changed APIs:
+
+
+ Changed API
+
+
+
+
+ Description
+
+
+
+ ec2-describe-images
+
+
+ Output now shows tags defined for each image.
+
+
+
+
+ ec2-describe-instances
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+ ec2-describe-snapshots
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+ ec2-describe-volumes
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+ Secure Console Access on XenServer3.1.6. Secure Console Access on XenServer
+ With the addition of Secure Console feature, users can now securely access the VM consoles on the XenServer hypervisor. You can either SSH or use the View Console option in the Management Server to securely connect to the VMs on the XenServer host. The Management Server uses the xapi API to stream the VM consoles. However, there is no change in the way you can access the console of a VM. This feature is supported on XenServer 5.6 and 6.0 versions.
+ Stopped VM3.1.7. Stopped VM
+ This release supports creating VMs without starting them on the backend. You can determine whether the VM needs to be started as part of the VM deployment. A VM can be deployed in two ways: create and start a VM (the default method); create a VM and leave it in the stopped state.
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. The possible values are:
+ •
+ true - The VM starts as a part of the VM deployment
+ •
+ false - The VM is left in stopped state at the end of the VM deployment
+ Uploading an Existing Volume to a Virtual Machine3.1.8. Uploading an Existing Volume to a Virtual Machine
+ Existing data can now be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs. The upload is performed by using HTTP. The uploaded volume is placed in the zone's secondary storage.
+
+ This functionality is supported for the following hypervisors:
+ •
+ Hypervisor : Disk Image Format
+ •
+ XenServer : VHD
+ •
+ VMware : OVA
+ •
+ KVM : QCOW2
+ Dedicated High-Availability Hosts3.1.9. Dedicated High-Availability Hosts
+ One or more hosts can now be designated for use only by high-availability (HA) enabled VMs that are restarted due to a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HA-enabled VMs make it easier to determine which VMs are restarted as part of the high-availability function. You can designate a host as a dedicated-HA restart node only if the Dedicated HA Hosts feature is enabled by setting the appropriate global configuration parameter.
+ Support for Amazon Web Services API3.1.10. Support for Amazon Web Services API
+ This release supports Amazon Web Services APIs, including Elastic Compute Cloud (EC2) API. Fidelity with the EC2 API and the installation experience for this functionality are both enhanced. In prior releases, users were required to install a separate component called CloudBridge, in addition to installing the Management Server. For new installations of CloudStack 4.0.0-incubating, this software is installed automatically along with CloudStack and runs in a more closely integrated fashion. The feature is disabled by default, but can be easily enabled by setting the appropriate global configuration parameter and performing a few setup steps.
+ The Nicira NVP Plugin3.1.11. The Nicira NVP Plugin
+ The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating this plug-in supports the Connectivity service. This service is responsible for creating Layer 2 networks supporting the networks created by guests. When a tenant creates a new network, instead of a traditional VLAN, a logical network will be created by sending the appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira NVP versions 2.1.0, 2.2.0 and 2.2.1.
+ Support for CAStor Cluster3.1.12. Support for CAStor Cluster
+ CloudStack 4.0.0-incubating supports using a CAStor cluster as the back-end storage system for a CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends the existing storage classes and allows the storage configuration attribute to point to a CAStor cluster. This feature makes use of the CloudStack server's local disk to spool files before writing them to CAStor when handling the PUT operations. However, a file must be successfully written into the CAStor cluster prior to the return of a success code to the S3 client to ensure that the transaction outcome is correctly reported.
+
+ The S3 multipart file upload is not supported in this release. You are prompted with proper error message if a multipart upload is attempted.
+ Clustered Logical Volume Manager Support for KVM3.1.13. Clustered Logical Volume Manager Support for KVM
+ This release adds Clustered Logical Volume Manager (CLVM) storage support for KVM hosts. With this support, you can use CLVM as primary storage.
+
+ The CLVM support for KVM allows root and data disks (primary storage) to reside on Linux logical volumes. The administrators are required to configure CLVM on the KVM hosts independent of CloudStack. When the volume groups are available, an administrator can simply add primary storage of type CLVM, providing the volume group name. Then CloudStack creates and manages logical volumes as needed.
+
+ CLVM also supports Snapshots. CloudStack creates an LVM snapshot, copy the applicable logical volume to the secondary storage in the qcow2 format, and then delete the LVM snapshot.
+ Rados Block Device Support for KVM3.1.14. Rados Block Device Support for KVM
+ You can now use Rados Block Device (RBD) to run instances on Apache CloudStack 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least 0.10 with RBD enabled on the KVM host
+
+ Create a disk offering for RBD so that you can ensure that StoragePoolAllocator chooses the RBD pool to deploy instances.
+ Issues Fixed in 4.0.0-incubating3.2. Issues Fixed in 4.0.0-incubating
+ Many bugs include a defect number that reflects the bug number that was held in the bug tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira11https://issues.apache.org/jira/browse/CLOUDSTACK to manage its bugs, so some of the bugs that are referenced here may not be available to view. However, we are still including them for completeness.
+
+
+ Defect
+
+
+
+
+ Description
+
+
+
+
+ Many
+
+
+
+ vSphere 5.0 now has GA support. Formerly only Beta support was provided.
+
+
+
+ CS-16135
+
+
+
+ Creating volumes after upgrading from snapshot taken in 2.2.14 no longer deletes the snapshot physically from the secondary storage.
+
+
+
+ CS-16122
+
+
+
+ In a site-to-site VPN setup, alerts are generated when the VPC virtual router is rebooted with multiple vpn connections.
+
+
+
+ CS-16022
+
+
+
+ If host connection fails due to a database error, host now disconnects and the Managerment Server id is removed.
+
+
+
+ CS-16011
+
+
+
+ Name of network offering is no longer truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+ CS-15978
+
+
+
+ When the virtual router and its host go down, the high availability mechanism now works for the virtual router.
+
+
+
+
+ CS-15921
+
+
+
+ The 2.2.x security group script now accounts for the VMs created in the version 2.1 timeframe.
+
+
+
+
+ CS-15919
+
+
+
+ A level parameter is added to the listVolumes command; therefore queries return the response more quickly.
+
+
+
+ CS-15904
+
+
+
+ Upgrade from version 2.2.14 to CloudStack-3.0.5-0.2944-rhel5 works as expected. The upgrade script, /usr/share/cloud/setup/db/schema-2214to30-cleanup.sql, works as expected.
+
+
+
+ CS-15879
+
+
+
+ The database upgrade from version 3.0.4 to 3.0.5 works as expected.
+
+
+
+
+ CS-15807
+
+
+
+ Network label for OVM now available in UI.
+
+
+
+
+ CS-15779
+
+
+
+ When the thumbnail is requested, the console session will not be terminated.
+
+
+
+
+ CS-15778
+
+
+
+ Fetching a VM thumbnail now gets a thumbnail of appropriate visual dimensions.
+
+
+
+
+ CS-15734
+
+
+
+ KVM Snapshots no longer shows incorrect disk usage.
+
+
+
+ CS-15733
+
+
+
+ The domainId parameter for the listNetworks command now lists the resources belonging to the domain specified.
+
+
+
+ CS-15676
+
+
+
+ Stopping the router no longer fails with the null pointer exception.
+
+
+
+
+ CS-15648
+
+
+
+ If creating a volume from a snapshot fails, the error is reported on the UI but the volume is stuck in the creating state.
+
+
+
+
+ CS-15646
+
+
+
+ createFirewallRule API no longer causes null pointer exception.
+
+
+
+ CS-15628
+
+
+
+ In a KVM host, the high availability mechanism no longer takes a long time to migrate VMs to another KVM host if there are multiple storage pools.
+
+
+
+ CS-15627
+
+
+
+ Metadata instance-id and vm-id for existing VMs stays the same after upgrade.
+
+
+
+ CS-15621
+
+
+
+ Solved difficulty with allocating disk volumes when running multiple VM deployment in parallel.
+
+
+
+ CS-15603
+
+
+
+ CloudStack now stop the VMs when destroyVM command is called.
+
+
+
+ CS-15586
+
+
+
+ Public Vlan for an account no longer fails if multiple physical networks are present.
+
+
+
+ CS-15582
+
+
+
+ The dns-name filter is now supported for ec2-describe-instances in the Amazon Web Services API compatibility commands. The filter maps to the name of a user VM.
+
+
+
+ CS-15503
+
+
+
+ An IP address which has static NAT rules can now be released. Subsequently, restarting this network after it was shutdown can succeed.
+
+
+
+ CS-15464
+
+
+
+ Can now delete static route whose state is set to Revoke.
+
+
+
+ CS-15443
+
+
+
+ Creating a firewall rule no longer fails with an internal server error.
+
+
+
+ CS-15398
+
+
+
+ Corrected technique for programming DNS on the user VMs.
+
+
+
+ CS-15356
+
+
+
+ Internal DNS 2 entry now correctly shown in UI.
+
+
+
+ CS-15335
+
+
+
+ The CloudBridge S3 Engine now connects to the database by using the deciphered password in the db.properties file.
+
+
+
+ CS-15318
+
+
+
+ UI now correctly prevents the user from stopping a VM that is in the Starting state.
+
+
+
+ CS-15307
+
+
+
+ Fixed Japanese localization of instance statuses in the Instances menu.
+
+
+
+ CS-15278
+
+
+
+ The deployment planner no longer takes long time to locate a suitable host to deploy VMs when large number of clusters are present.
+
+
+
+ CS-15274
+
+
+
+ Creating a VLAN range using Zone ID without network ID now succeeds.
+
+
+
+ CS-15243
+
+
+
+ Now check to be sure source NAT and VPN have same provider.
+
+
+
+ CS-15232
+
+
+
+ Ensure that networks using external load balancer/firewall in 2.2.14 or earlier can properly upgrade.
+
+
+
+ CS-15200
+
+
+
+ No exception when trying to attach the same volume while attaching the first volume is in progress.
+
+
+
+ CS-15173
+
+
+
+ Additional cluster can no longer be added with same VSM IP address as another cluster.
+
+
+
+ CS-15167
+
+
+
+ AWS API calls now honor the admin account's ability to view or act on the resources owned by the regular users.
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+ CS-15157
+
+
+
+ Can now add/enable service providers for multiple physical networks through the UI.
+
+
+
+ CS-15145
+
+
+
+ AWS API call ec2-register has better error handling for negative cases.
+
+
+
+ CS-15122
+
+
+
+ Filters now supported for AWS API call ec2-describe-availability-zones.
+
+
+
+ CS-15120
+
+
+
+ Actions column in UI of Volume page now shows action links.
+
+
+
+ CS-15099
+
+
+
+ Buttons no longer overlap text on Account Deletion confirmation page in UI.
+
+
+
+ CS-15095
+
+
+
+ Ensures you can not create a VM with a CPU frequency greater than the host CPU frequency.
+
+
+
+ CS-15094
+
+
+
+ CPU cap now set properly in VMware.
+
+
+
+ CS-15077
+
+
+
+ NullPointerException is no longer observed while executing the command to list the public IP in a basic zone created with the default shared NetScaler EIP and ELB network offering.
+
+
+
+ CS-15044
+
+
+
+ UI now provides option to view the list of instances which are part of the guest network.
+
+
+
+ CS-15026
+
+
+
+ UI in Deploy VM dialog now lists only templates or ISOs depending on which is selected in previous dialog.
+
+
+
+ CS-14989
+
+
+
+ In KVM, the Create Instance wizard now shows only templates from the current (KVM) zone.
+
+
+
+ CS-14986, CS-14985
+
+
+
+ Listing filters works as expected in the ec2-describe-volumes and ec2-describe-snapshots commands.
+
+
+
+ CS-14964
+
+
+
+ Automatically starting the Console Proxy no longer fails due to its missing volume on the primary storage
+
+
+
+ CS-14907
+
+
+
+ User is now correctly prevented from trying to download an uploaded volume which has not yet been moved to primary storage.
+
+
+
+ CS-14879
+
+
+
+ When a user VM is stopped or terminated, the static NAT associated with this VM is now disabled. This public IP address is no longer owned by this account and can be associated to any other user VM.
+
+
+
+ CS-14854
+
+
+
+ Only the admin user can change the template permission to Public, so this option is removed from the UI for domain Admins and regular Users.
+
+
+
+ CS-14817
+
+
+
+ While checking if network has any external provider, CloudStack will consider all providers in the network.
+
+
+
+ CS-14796
+
+
+
+ When deploying a VM with ec2-run-instances, userdata is now encoded.
+
+
+
+ CS-14770
+
+
+
+ The API returns the keypair information when a VM is deployed with sshkey. This affects the API commands related to virtual machines (deployVirtualMachine, listVirtualMachines, ... *VirtualMachine), as well as the corresponding AWS APIs.
+
+
+
+ CS-14724
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+ CS-14345
+
+
+
+ Logout API returns XML header.
+
+
+
+ CS-14724
+
+
+
+ Host IPs now associated with appropriate IPs according to traffic type.
+
+
+
+ CS-14253
+
+
+
+ Can now delete and re-create port forwarding rule on same firewall.
+
+
+
+ CS-14724
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+ CS-14452
+
+
+
+ Data disk volumes are now automatically copied from one cluster to another.
+
+
+
+ CS-13539
+
+
+
+ Windows VM can get IP after reboot.
+
+
+
+ CS-13537
+
+
+
+ When user tries to delete a domain that contains sub-domains, an error message is now sent to convey the reason for the delete failure.
+
+
+
+ CS-13153
+
+
+
+ System VMs support HTTP proxy.
+
+
+
+ CS-12642
+
+
+
+ Added Close button to Select Project list view popup in UI.
+
+
+
+ CS-12510
+
+
+
+ Deleting and reinserting host_details no longer causes deadlocks.
+
+
+
+ CS-12407
+
+
+
+ F5 and Netscaler - when dedicated is selected, capacity field is disabled.
+
+
+
+ CS-12111
+
+
+
+ Email validation for edit user form.
+
+
+
+ CS-10928
+
+
+
+ Network read/write values now always positive numbers.
+
+
+
+ CS-15376, CS-15373
+
+
+
+ The AWS APIs (EC2 and S3) now listen on the 7080 port and send request to CloudStack on the 8080 port just as any other clients of CloudStack.
+
+
+
+ CS-13944
+
+
+
+ The CloudStack 2.2.x to 3.0.x database upgrade for multiple physical networks is now supported.
+
+
+
+ CS-15300
+
+
+
+ The admin accounts of a domain now honour the limits imposed on that domain just like the regular accounts do. A domain admin now is not allowed to create an unlimited number of instances, volumes, snapshots, and so on.
+
+
+
+ CS-15396
+
+
+
+ The CloudStack database now contain the UUD information after the 2.2.14 to 3.0.4 upgrade.
+
+
+
+ CS-15450
+
+
+
+ Upgrade from 2.2.14 to 3.0.4 no longer fails on a VMware host.
+
+
+
+ CS-15449
+
+
+
+ Running cloudstack-aws-api-register no longer fails with the "User registration failed with error: [Errno 113] No route to host" error.
+
+
+
+ CS-15455
+
+
+
+ The iptable rules are configured to open the awsapi port (7080) as part of the installation.
+
+
+
+ CS-15429
+
+
+
+ While creating an instance with data volume, disk offering also is considered while checking the account limit on volume resources.
+
+
+
+ CS-15414
+
+
+
+ After the 2.2.14 to 3.0.4 upgrade, the value of the global parameter xen.guest.network.device is now decrypted before setting the traffic label.
+
+
+
+ CS-15382
+
+
+
+ During 2.2.14 to 3.0.4 upgrade, the hosts no longer go to the Alert state if destroyed networks existed with non-existent tags prior to upgrade.
+
+
+
+ CS-15323
+
+
+
+ CloudStack supports the following Citrix XenServer hotfixes: XS602E003, XS602E004, and XS602E005.
+
+
+
+ CS-15430
+
+
+
+ Create snapshot now fails if creating a snapshot exceeds the snapshot resource limit for a domain admin or a user account.
+
+
+
+ CS-14256
+
+
+
+ Virtual Router no longer remains in starting state for subdomain or user on a KVM 3.0.1 prerlease host on RHEL 6.2.
+
+
+
+ CS-7495
+
+
+
+ Implemented a variety of Xen management host improvements.
+
+
+
+ CS-8105
+
+
+
+ NFS v4 for primary storage now works as expected on KVM hosts.
+
+
+
+ CS-9989
+
+
+
+ The error messages returned during VM deployment failure will have much more details than before.
+
+
+
+ CS-12584
+
+
+
+ You can no longer add security groups not supported by the hypervisor in use.
+
+
+
+ CS-12705
+
+
+
+ When creating a Network offering by using SRX as the service provider for SourceNAT servcies, an option is given in the CloudStack UI now to set the source_nat type to "per Zone"/"per account".
+
+
+
+ CS-12782
+
+
+
+ Assigning a VM from Basic to Advanced zone no longer ignores the network ID. A warning message is displayed for VM movements across zones.
+
+
+
+ CS-12591
+
+
+
+ Broadcast Address on the Second Public IP NIC is now corrected.
+
+
+
+ CS-13272
+
+
+
+ When a user is deleted, all the associated properties, such as IPs and virtual routers, are now deleted.
+
+
+
+ CS-13377
+
+
+
+ Creating template from a root disk of a stopped instance now provides an option to make it a "Featured template".
+
+
+
+ CS-13500
+
+
+
+ Reaching the first guest VM by using its public IP from the second guest VM no longer fails.
+
+
+
+ CS-13853
+
+
+
+ The default gateway can no longer be 0.0.0.0 in the Secondary Storage VM (SSVM).
+
+
+
+ CS-13863
+
+
+
+ The queryAsyncJobResult command in XML format now returns the correct UUIDs.
+
+
+
+ CS-13867
+
+
+
+ Corrected CSP xenserver-cloud-supp.tgz for XenServer 5.6 and 6.0.
+
+
+
+ CS-13904
+
+
+
+ Labels and values for the service offerings CPU and memory are now consistent.
+
+
+
+ CS-13998
+
+
+
+ The SSVM kernel panic issue is fixed on XenServer.
+
+
+
+ CS-14090
+
+
+
+ The issue is fixed where running the VMware snapshots randomly fails with the ArrayIndexOutOfBoundsException error.
+
+
+
+ CS-14021
+
+
+
+ The java.lang.OutOfMemoryError is fixed on the Management Server.
+
+
+
+ CS-14025
+
+
+
+ The Python Eggs are provided to easily package the test client for each branch of CloudStack.
+
+
+
+ CS-14068
+
+
+
+ Resetting the VM password through the CloudStack UI no longer causes any error.
+
+
+
+ CS-14156
+
+
+
+ The pod which has the administrator's virtual router is no longer selected while creating the virtual routers for guests.
+
+
+
+ CS-14182
+
+
+
+ The users can now delete their ISOs as normal users.
+
+
+
+ CS-14185
+
+
+
+ The listOSTypes API now filters out the types of operating system by using the keywords.
+
+
+
+ CS-14204
+
+
+
+ The cloud-setup-bonding.sh command no longer generates the "command not found" error.
+
+
+
+ CS-14214
+
+
+
+ The Specify VLAN option cannot be enabled now for an isolated Network offering with SourceNAT enabled.
+
+
+
+ CS-14234
+
+
+
+ Sending project invite email to an account now requires SMTP configured in CloudStack.
+
+
+
+ CS-14237
+
+
+
+ The garbage collector of the primary storage no longer fails when the first host in the cluster is not up.
+
+
+
+ CS-14241
+
+
+
+ Custom Volume Disk Offering is now matching the Global configuration value.
+
+
+
+ CS-14270
+
+
+
+ The listNetworks API no longer assumes that the broadcast type is always VLAN.
+
+
+
+ CS-14319
+
+
+
+ The internal name of the VM is no longer present in the error message that is displayed to a domain administrator.
+
+
+
+ CS-14321
+
+
+
+ The listVolumes API call now returns a valid value for the isExtractable parameter for the ISO-derived disk and data disk volumes.
+
+
+
+ CS-14323
+
+
+
+ Invalid API calls will now give valid response in json/xml format.
+
+
+
+ CS-14339
+
+
+
+ Custom Disk Size will now allow values larger than 100GB.
+
+
+
+ CS-14357
+
+
+
+ The ConsoleProxyLoadReportCommand is no longer fired continuously.
+
+
+
+ CS-14421
+
+
+
+ Fixed the issue of virtual router deployments. The DHCP entries can now be assigned to the router.
+
+
+
+ CS-14555
+
+
+
+ Unzipped downloaded template MD5SUM will no longer override the zipped template MD5SUM in the database.
+
+
+
+ CS-14598
+
+
+
+ The complete screen of the running VM is now displayed in the console proxy.
+
+
+
+ CS-14600
+
+
+
+ Windows or Linux based consoles are no longer lost upon rebooting VMs.
+
+
+
+ CS-14784
+
+
+
+ Multiple subnets with the same VLAN now work as expected.
+
+
+
+ CS-13303, 14874, 13897, 13944, 14088, 14190
+
+
+
+ A variety of upgrade issues have been fixed in release 3.0.3.
+
+
+
+ CS-15080
+
+
+
+ Setting a private network on a VLAN for VMWare environment is now supported.
+
+
+
+ CS-15168
+
+
+
+ The console proxy now works as expected and no exception is shown in the log after upgrading from version 2.2.14 to 3.0.2.
+
+
+
+ CS-15172
+
+
+
+ Version 3.0.2 now accepts the valid public key.
+
+ Known Issues in 4.0.0-incubating3.3. Known Issues in 4.0.0-incubating
+
+ Issue ID
+
+
+
+
+ Description
+
+
+
+
+ CLOUDSTACK-301
+
+
+
+ Nexus 1000v DVS integration is not functional
+
+
+ This source code release includes some partial functionality to support the Cisco Nexus 1000v Distributed Virtual Switch within a VMware hypervisor environment. The functionality is not complete at this time.
+
+
+
+
+ CLOUDSTACK-368
+
+
+
+ OVM - cannot create guest VM
+
+
+ This source code release has regressed from the CloudStack 2.2.x code and is unable to support Oracle VM (OVM).
+
+
+
+
+ CLOUDSTACK-279
+
+
+
+ Deleting a project fails when executed by the regular user. This works as expected for root/domain admin. To workaround, perform either of the following:
+
+ •
+ Use the account cleanup thread which will eventually complete the project deletion.
+ •
+ Execute the call as the root/domain admin on behalf of the regular user.
+
+
+
+
+ CS-16067
+
+
+
+ The command=listTags&key=city command does not work as expected. The command does not return tags for the resources of the account with the tag, city
+
+
+
+
+ CS-16063
+
+
+
+ The current values of volumes and snapshots are incorrect when using KVM as a host. To fix this, the database upgrade codes, volumes.size and snapshots.size, should be changed to show the virtual sizes.
+
+
+
+
+ CS-16058
+
+
+
+ Null pointer Exception while deleting the host after moving the host to maintenance state.
+
+
+
+
+ CS-16045
+
+
+
+ Only the root administrator can handle the API keys. The domain administrators are not allowed to create, delete, or retrieve API keys for the users in their domain.
+
+
+
+
+ CS-16019
+
+
+
+ CIDR list in the Add VPN Customer Gateway dialog does not prompt the user that they can provide a comma separated CIDRs if multiple CIDRs have to be supplied.
+
+
+
+
+ CS-16015
+
+
+
+ Deleting a network is not supported when its network providers are disabled.
+
+
+
+
+ CS-16012
+
+
+
+ Unable to delete a zone in the UI because the necessary cleanup cannot be completed. When the hosts are removed, the expunge process fails to delete the volumes as no hosts are present to send the commands to. Therefore, the storage pool removal fails, and zone can't be cleaned and deleted.
+
+
+
+
+ CS-16011
+
+
+
+ Name of network offering might be truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+ CS-15789
+
+
+
+ Invalid global setting prevents management server to restart. For example, if you configure the "project.invite.timeout" parameter to "300" and attempt to restart management server, it fails without throwing a warning or setting the value to the default.
+
+
+
+
+ CS-15749
+
+
+
+ Restarting VPC is resulting in intermittent connection loss to the port forwarding and StaticNAT rules.
+
+
+
+
+ CS-15690
+
+
+
+ The IpAssoc command failed as a part of starting the virtual router, but the final start result is reported as succes.
+
+
+
+
+ CS-15672, CS-15635
+
+
+
+ The FQDN of the VM is not configured if it is deployed as a part of default shared network and isolated guest network (DefaultIsolatedNetworkOfferingWithSourceNatService).
+
+
+
+
+ CS-15634
+
+
+
+ The FQDN of a VM that is deployed as a part of both a shared network and default isolated guest network has the suffix of the shared network instead of the default isolated guest network.
+
+
+
+
+ CS-15576
+
+
+
+ Stopping a VM on XenServer creates a backlog of API commands. For example, the Attach volume calls become delayed while waiting for the stopVirtualMachine command to be executed.
+
+
+
+
+ CS-15569
+
+
+
+ Misleading error message in the exception when creating a StaticNAT rule fails in a VPC.
+
+
+
+
+ CS-15566
+
+
+
+ External device such as Netscaler is not supported in VPC.
+
+
+
+ CS-15557
+
+
+
+ Intermittent traffic loss in the VPN connection if Juniper is the remote router and the life time is 300 seconds.
+
+
+
+
+ CS-15361
+
+
+
+ Egress rules are not working in NetScaler loadbalancer.
+
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+ CS-15105
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+ CS-15092
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+ CS-15037
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+ CS-15009
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+ CS-14939
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+ CS-14780
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+ CS-14756
+
+
+
+ Installing KVM on RHEL 6.2 will result in unreliable network performance. Workaround: blacklist vhost-net. Edit /etc/modprobe.d/blacklist-kvm.conf and include vhost-net.
+
+
+
+ CS-14346
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+ CS-14303 (was 14537)
+
+
+
+ The IP addresses for a shared network are still being consumed even if no services are defined for that network.
+
+
+
+ CS-14296 (was 14530)
+
+
+
+ OVM: Network traffic labels are not supported.
+
+
+
+ CS-14291 (was 14523)
+
+
+
+ The EIP/ELB network offering for basic zones does not support multiple NetScalers.
+
+
+
+ CS-14275 (was 14506)
+
+
+
+ F5: Unable to properly remove a F5 device.
+
+
+
+ CS-14201 (was 14430)
+
+
+
+ VMWare: Template sizes are being reported different depending on whether the primary storage is using ISCSI or NFS.
+
+
+
+ CS-13758 (was 13963)
+
+
+
+ vSphere: template download from templates created off of the root volume does not work properly.
+
+
+
+ CS-13733 (was 13935)
+
+
+
+ vSphere: detaching an ISO from a restored VM instance fails.
+
+
+
+ CS-13682 (was 13883)
+
+
+
+ Multiple NetScalers are not supported in Basic Networking.
+
+
+
+ CS-13599 (was 13359)
+
+
+
+ Programming F5/NetScaler rules can be better optimized.
+
+
+
+ CS-13337 (was 13518)
+
+
+
+ Security Groups are not supported in Advanced Networking
+
+
+
+ CS-13173 (was 13336)
+
+
+
+ vSphere: cross cluster volume migration does not work properly.
+
+
+
+ CS-12714 (was 12840)
+
+
+
+ Capacity view is not available for pods or clusters.
+
+
+
+ CS-12624 (was 12741)
+
+
+
+ vSphere: maintenance mode will not live migrate system VM to another host.
+
+
+
+ CS-15476
+
+
+
+
+ The 2.2.14 to 4.0.0-incubating upgrade fails if multiple untagged physical networks exist before the upgrade.
+
+
+
+
+ CS-15407
+
+
+
+
+ After the 2.2.14 to 4.0.0-incubating upgrade, VLAN allocation on multiple physical networks does not happen as expected.
+
+
+ To workaround this issue, follow the instructions given below:
+
+ 1.
+ Revert to your 2.2.14 setup.
+ 2.
+ Stop all the VMs with the isolated virtual networks in your cloud setup.
+ 3.
+ Run following query to find if any networks still have the NICs allocated:
+ a.
+ Check if any virtual guest networks have the NICs allocated:
+ #SELECT DISTINCT op.id from `cloud`.`op_networks` op JOIN `cloud`.`networks` n on op.id=n.id WHERE nics_count != 0 AND guest_type = 'Virtual';b.
+ If this returns any network IDs, then ensure the following:
+ i.
+ All the VMs are stopped.
+ ii.
+ No new VM is started.
+ iii.
+ Shutdown the Management Server.
+ c.
+ Remove the NICs count for the virtual network IDs returned in step (a), and set the NIC count to 0:
+ UPDATE `cloud`.`op_networks` SET nics_count = 0 WHERE id = enter id of virtual networkd.
+ Restart the Management Server, and wait for all the networks to shut down.
+ Note
+ Networks shutdown is determined by the network.gc.interval and network.gc.wait parameters.
+ 4.
+ Ensure that all the networks are shut down and all the guest VNETs are free.
+ 5.
+ Run the upgrade script.
+
+ This allocates all your guest VNET ranges to the first physical network.
+ 6.
+ By using the updatePhysicalNetwork API, reconfigure the VNET ranges for each physical network as desired.
+ 7.
+ Start all the VMs.
+
+
+
+
+ CS-14680
+
+
+
+
+ CloudStack and LDAP user validation cannot happen simultaneously because the user password is hashed and stored in the database, and LDAP requires the passwords in plain text.
+
+
+ To work with the LDAP user, the MD5 hash should be disabled in the login process by commenting the following variable in sharedFunctions.js file available at /usr/share/cloud/management/webapps/client/scripts, and restart the cloud-management service.
+
+
+var md5HashedLogin = false;
+
+ However, if md5HashedLogin is set to false, the end user can login with the LDAP credentials but not with the CloudStack user credentials.
+
+
+
+
+ CS-14346
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+ CS-15130
+
+
+
+ Data disk volumes are not automatically copied from one cluster to another.
+
+
+
+ CS-14780
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+ CS-14939
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+ CS-15009
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+ CS-15037
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+ CS-15092
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+ CS-15105
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+ Chapter 4.Chapter 4. API Changes from 3.0.2 to 4.0.0-incubatingAPI Changes from 3.0.2 to 4.0.0-incubatingNew API Commands in 4.0.0-incubating4.1. New API Commands in 4.0.0-incubating•
+ createCounter (Adds metric counter)
+ •
+ deleteCounter (Deletes a counter)
+ •
+ listCounters (List the counters)
+ •
+ createCondition (Creates a condition)
+ •
+ deleteCondition (Removes a condition)
+ •
+ listConditions (List Conditions for the specific user)
+ •
+ createTags. Add tags to one or more resources. Example:
+command=createTags
+&resourceIds=1,10,12
+&resourceType=userVm
+&tags[0].key=region
+&tags[0].value=canada
+&tags[1].key=city
+&tags[1].value=Toronto
+ •
+ deleteTags. Remove tags from one or more resources. Example:
+command=deleteTags
+&resourceIds=1,12
+&resourceType=Snapshot
+&tags[0].key=city
+ •
+ listTags (Show currently defined resource tags)
+ •
+ createVPC (Creates a VPC)
+ •
+ listVPCs (Lists VPCs)
+ •
+ deleteVPC (Deletes a VPC)
+ •
+ updateVPC (Updates a VPC)
+ •
+ restartVPC (Restarts a VPC)
+ •
+ createVPCOffering (Creates VPC offering)
+ •
+ updateVPCOffering (Updates VPC offering)
+ •
+ deleteVPCOffering (Deletes VPC offering)
+ •
+ listVPCOfferings (Lists VPC offerings)
+ •
+ createPrivateGateway (Creates a private gateway)
+ •
+ listPrivateGateways (List private gateways)
+ •
+ deletePrivateGateway (Deletes a Private gateway)
+ •
+ createNetworkACL (Creates a ACL rule the given network (the network has to belong to VPC))
+ •
+ deleteNetworkACL (Deletes a Network ACL)
+ •
+ listNetworkACLs (Lists all network ACLs)
+ •
+ createStaticRoute (Creates a static route)
+ •
+ deleteStaticRoute (Deletes a static route)
+ •
+ listStaticRoutes (Lists all static routes)
+ •
+ createVpnCustomerGateway (Creates site to site vpn customer gateway)
+ •
+ createVpnGateway (Creates site to site vpn local gateway)
+ •
+ createVpnConnection (Create site to site vpn connection)
+ •
+ deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
+ •
+ deleteVpnGateway (Delete site to site vpn gateway)
+ •
+ deleteVpnConnection (Delete site to site vpn connection)
+ •
+ updateVpnCustomerGateway (Update site to site vpn customer gateway)
+ •
+ resetVpnConnection (Reset site to site vpn connection)
+ •
+ listVpnCustomerGateways (Lists site to site vpn customer gateways)
+ •
+ listVpnGateways (Lists site 2 site vpn gateways)
+ •
+ listVpnConnections (Lists site to site vpn connection gateways)
+ •
+ markDefaultZoneForAccount (Marks a default zone for the current account)
+ •
+ uploadVolume (Uploads a data disk)
+ Changed API Commands in 4.0.0-incubating4.2. Changed API Commands in 4.0.0-incubating
+
+ API Commands
+
+
+
+ Description
+
+
+
+ copyTemplate
+
+
+ prepareTemplate
+
+
+ registerTemplate
+
+
+ updateTemplate
+
+
+ createProject
+
+
+ activateProject
+
+
+ suspendProject
+
+
+ updateProject
+
+
+ listProjectAccounts
+
+
+ createVolume
+
+
+ migrateVolume
+
+
+ attachVolume
+
+
+ detachVolume
+
+
+ uploadVolume
+
+
+ createSecurityGroup
+
+
+ registerIso
+
+
+ copyIso
+
+
+ updateIso
+
+
+ createIpForwardingRule
+
+
+ listIpForwardingRules
+
+
+ createLoadBalancerRule
+
+
+ updateLoadBalancerRule
+
+
+ createSnapshot
+
+
+
+
+ The commands in this list have a single new response parameter, and no other changes.
+
+
+ New response parameter: tags(*)
+
+ Note
+ Many other commands also have the new tags(*) parameter in addition to other changes; those commands are listed separately.
+
+
+
+ rebootVirtualMachine
+
+
+ attachIso
+
+
+ detachIso
+
+
+ listLoadBalancerRuleInstances
+
+
+ resetPasswordForVirtualMachine
+
+
+ changeServiceForVirtualMachine
+
+
+ recoverVirtualMachine
+
+
+ startVirtualMachine
+
+
+ migrateVirtualMachine
+
+
+ deployVirtualMachine
+
+
+ assignVirtualMachine
+
+
+ updateVirtualMachine
+
+
+ restoreVirtualMachine
+
+
+ stopVirtualMachine
+
+
+ destroyVirtualMachine
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+ listSecurityGroups
+
+
+ listFirewallRules
+
+
+ listPortForwardingRules
+
+
+ listSnapshots
+
+
+ listIsos
+
+
+ listProjects
+
+
+ listTemplates
+
+
+ listLoadBalancerRules
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: tags (optional)
+
+
+ New response parameter: tags(*)
+
+
+
+
+ listF5LoadBalancerNetworks
+
+
+ listNetscalerLoadBalancerNetworks
+
+
+ listSrxFirewallNetworks
+
+
+ updateNetwork
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ createZone
+
+
+ updateZone
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: localstorageenabled (optional)
+
+
+ New response parameter: localstorageenabled
+
+
+
+
+ listZones
+
+
+
+ New response parameter: localstorageenabled
+
+
+
+ rebootRouter
+
+
+ changeServiceForRouter
+
+
+ startRouter
+
+
+ destroyRouter
+
+
+ stopRouter
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+ updateAccount
+
+
+ disableAccount
+
+
+ listAccounts
+
+
+ markDefaultZoneForAccount
+
+
+ enableAccount
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: vpcavailable, vpclimit, vpctotal
+
+
+
+ listRouters
+
+
+
+ New request parameters: forvpc (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+
+ listNetworkOfferings
+
+
+
+ New request parameters: forvpc (optional)
+
+
+ New response parameters: forvpc
+
+
+
+
+ listVolumes
+
+
+
+ New request parameters: details (optional), tags (optional)
+
+
+ New response parameters: tags(*)
+
+
+
+
+ addTrafficMonitor
+
+
+
+ New request parameters: excludezones (optional), includezones (optional)
+
+
+
+
+ createNetwork
+
+
+
+ New request parameters: vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ listPublicIpAddresses
+
+
+
+ New request parameters: tags (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+ listNetworks
+
+
+
+ New request parameters: canusefordeploy (optional), forvpc (optional), tags (optional), vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ restartNetwork
+
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+ enableStaticNat
+
+
+
+ New request parameter: networkid (optional)
+
+
+
+
+ createDiskOffering
+
+
+
+ New request parameter: storagetype (optional)
+
+
+ New response parameter: storagetype
+
+
+
+
+ listDiskOfferings
+
+
+
+ New response parameter: storagetype
+
+
+
+
+ updateDiskOffering
+
+
+
+ New response parameter: storagetype
+
+
+
+
+ createFirewallRule
+
+
+
+ Changed request parameters: ipaddressid (old version - optional, new version - required)
+
+
+ New response parameter: tags(*)
+
+
+
+
+ listVirtualMachines
+
+
+
+ New request parameters: isoid (optional), tags (optional), templateid (optional)
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+ updateStorageNetworkIpRange
+
+
+
+ New response parameters: id, endip, gateway, netmask, networkid, podid, startip, vlan, zoneid
+
+
+
+
+ reconnectHost
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+ addCluster
+
+
+
+ The following request parameters are added:
+
+ •
+ vsmipaddress (optional)
+ •
+ vsmpassword (optional)
+ •
+ vsmusername (optional)
+
+
+ The following parameter is made mandatory: podid
+
+
+
+
+ listVolumes
+
+
+
+ A new response parameter is added: status
+
+
+
+ migrateVolume
+
+
+
+ A new response parameter is added: status
+
+
+
+ prepareHostForMaintenance
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+ addSecondaryStorage
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+ enableAccount
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+ attachVolume
+
+
+
+ A new response parameter is added: status
+
+
+
+ cancelHostMaintenance
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ addSwift
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ listSwifts
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ listExternalLoadBalancers
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ createVolume
+
+
+
+ A new response parameter is added: status
+
+
+
+ listCapabilities
+
+
+
+ A new response parameter is added: customdiskofferingmaxsize
+
+
+
+ disableAccount
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+ deployVirtualMachine
+
+
+
+ A new request parameter is added: startvm (optional)
+
+
+
+ deleteStoragePool
+
+
+
+ A new request parameter is added: forced (optional)
+
+
+
+ updateAccount
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+ addHost
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ updateHost
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ detachVolume
+
+
+
+ A new response parameter is added: status
+
+
+
+ listAccounts
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+ listHosts
+
+
+
+ A new response parameter is added: hahost
+
+
+ A new request parameter is added: hahost (optional)
+
+
diff --git a/docs/tmp/en-US/xml/Release_Notes.xml b/docs/tmp/en-US/xml/Release_Notes.xml
new file mode 100644
index 00000000000..aa690d66b09
--- /dev/null
+++ b/docs/tmp/en-US/xml/Release_Notes.xml
@@ -0,0 +1,5952 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Submitting Feedback and Getting Help
+
+ The Apache CloudStack project has mailing lists for users and developers. These are the official channels of communication for the project and are the best way to get answers about using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users mailing list if you've deployed or are deploying CloudStack into production, and even for test deployments.
+
+
+ The CloudStack developer's mailing list (cloudstack-dev) is for discussions about CloudStack development, and is the best list for discussing possible bugs in CloudStack. Anyone contributing to CloudStack should be on this mailing list.
+
+
+ You can also report bugs in CloudStack using the Apache Defect Tracking System.
+
+
+ To posts to the lists, you'll need to be subscribed. See the CloudStack Web site for instructions.
+
+
+
+
+ Upgrade Instructions
+
+ Upgrade from 3.0.2 to 4.0.0-incubating
+
+ Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note that some of the steps here are only required if you're using a specific hypervisor. The steps that are hypervisor-specific are called out with a note.
+
+
+
+
+ Ensure that you query your IP address usage records and process them or make a backup. During the upgrade you will lose the old IP address usage records.
+
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading, any existing IP address usage records in the old format will no longer be available.
+
+
+
+
+
+
+ The following upgrade instructions apply only if you're using VMware hosts. If you're not using VMware hosts, skip this step and move on to step 3: stopping all usage servers.
+
+
+
+
+ In each zone that includes VMware hosts, you need to add a new system VM template.
+
+
+
+
+ While running the existing 3.0.2 system, log in to the UI as root administrator.
+
+
+
+
+
+ In the left navigation bar, click Templates.
+
+
+
+
+
+ In Select view, click Templates.
+
+
+
+
+
+ Click Register template.
+
+
+ The Register template dialog box is displayed.
+
+
+
+
+
+ In the Register template dialog box, specify the following values (do not change these):
+
+
+
+
+
+
+
+
+
+ Field
+
+
+
+
+ Value
+
+
+
+
+
+
+
+
+
+
+ Name
+
+
+
+
+ systemvm-vmware-3.0.0
+
+
+
+
+
+
+
+ Description
+
+
+
+
+ systemvm-vmware-3.0.0
+
+
+
+
+
+
+
+ URL
+
+
+
+
+ http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+
+
+
+
+
+ Zone
+
+
+
+
+ Choose the zone where this hypervisor is used
+
+
+
+
+
+
+
+ Hypervisor
+
+
+
+
+ VMware
+
+
+
+
+
+
+
+ Format
+
+
+
+
+ OVA
+
+
+
+
+
+
+
+ OS Type
+
+
+
+
+ Debian GNU/Linux 5.0 (32-bit)
+
+
+
+
+
+
+
+ Extractable
+
+
+
+
+ no
+
+
+
+
+
+
+
+ Password Enabled
+
+
+
+
+ no
+
+
+
+
+
+
+
+ Public
+
+
+
+
+ no
+
+
+
+
+
+
+
+ Featured
+
+
+
+
+ no
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful.
+
+
+
+
+
+
+
+
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+
+
+# service cloud-usage stop
+
+
+
+
+ Stop the Management Servers. Run this on all Management Server hosts.
+
+
+# service cloud-management stop
+
+
+
+
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+
+ 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.
+
+
+#mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp
+
+
+
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the &PRODUCT; binaries.
+
+
+
+
+
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade &PRODUCT;:
+#yum update cloud-*
+
+#apt-get update
+#apt-get upgrade cloud-*
+
+
+
+ You will, of course, have to agree to the changes suggested by Yum or APT.
+
+
+
+ If the upgrade output includes a message similar to the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+
+
+warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+
+ Instructions follow in the next step.
+
+
+
+
+
+
+
+ If you have made changes to your copy of /etc/cloud/management/components.xml the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+
+
+
+ Make a backup copy of /etc/cloud/management/components.xml. For example:
+
+
+# mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backup
+
+
+
+
+ Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:
+
+
+# cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xml
+
+
+
+
+ Merge your changes from the backup file into the new components.xml.
+
+
+# vi /etc/cloud/management/components.xml
+
+
+
+
+
+
+ If you have more than one management server node, repeat the upgrade steps on each node.
+
+
+
+
+
+
+
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+
+
+# service cloud-management start
+
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. After confirmation, start the other Management Servers one at a time by running the same command on each node.
+
+
+
+ Failing to restart the Management Server indicates a problem in the upgrade. Having the Management Server restarted without any issues indicates that the upgrade is successfully completed.
+
+
+
+
+
+
+
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
+
+ # service cloud-usage start
+
+
+
+
+
+
+ Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+
+
+
+
+
+
+ Configure a yum or apt respository containing the &PRODUCT; packages as outlined in the Installation Guide.
+
+
+
+
+
+ Stop the running agent.
+
+
+ # service cloud-agent stop
+
+
+
+
+
+ Update the agent software with one of the following command sets as appropriate for your environment.
+
+
+ # yum update cloud-*
+
+
+ # apt-get update
+
+
+ # apt-get upgrade cloud-*
+
+
+
+
+
+ Start the agent.
+
+
+# service cloud-agent start
+
+
+
+
+ Edit /etc/cloud/agent/agent.properties to change the resource parameter from "com.cloud.agent.resource.computing.LibvirtComputingResource" to "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
+
+
+
+
+
+ Start the cloud agent and cloud management services.
+
+
+
+
+
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+
+
+
+
+
+
+
+
+
+ Log in to the CloudStack UI as administrator, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
+
+
+ Troubleshooting: If login fails, clear your browser cache and reload the page.
+
+
+
+
+
+
+ Do not proceed to the next step until the hosts show in Up state.
+
+
+
+
+
+ If you are upgrading from 3.0.2, perform the following:
+
+
+
+
+ Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter.
+
+
+ This port is used by the cloud-sysvmadm script at the end of the upgrade procedure. For information about how to set this parameter, see "Setting Global Configuration Parameters" in the Installation Guide.
+
+
+
+
+
+ Restart the Management Server.
+
+
+
+ If you don't want the admin port to remain open, you can set it to null after the upgrade is done and restart the management server.
+
+
+
+
+
+
+
+
+
+
+
+ Run the cloud-sysvmadm script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the -c and -r arguments. For example:
+
+
+ # nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+
+
+ # tail -f sysvm.log
+
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+
+
+
+
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+
+
+
+
+
+ Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+
+
+
+
+ Disconnect the XenServer cluster from CloudStack.
+
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+
+
+
+
+
+ To clean up the VLAN, log in to one XenServer host and run:
+
+
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+
+
+
+ Now prepare the upgrade by running the following on one XenServer host:
+
+
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+
+
+ If you see a message like "can't eject CD", log in to the VM and unmount the CD, then run this script again.
+
+
+
+
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /tmp.
+
+
+ On the Xen pool master, upload the hotfix with this command:
+
+
+ xe patch-upload file-name=XS602E003.xsupdate
+
+
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+
+
+
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+
+
+
+
+
+
+
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
+
+ # xe vm-list
+
+
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+
+ # xe vm-migrate live=true host=host-name vm=VM-name
+
+
+ Troubleshooting
+
+ If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
+
+
+ /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.
+
+
+
+
+
+
+
+ Apply the hotfix. First, get the UUID of this host:
+
+
+# xe host-list
+
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+
+xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid
+
+
+
+
+ Copy the following files from the CloudStack Management Server to the host.
+
+
+
+
+
+
+
+
+
+ Copy from here...
+
+
+
+
+ ...to here
+
+
+
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
+
+
+
+
+ Download the CSP software onto the XenServer host from one of the following links:
+
+
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+
+
+
+ Extract the file:
+
+
+# tar xf xenserver-cloud-supp.tgz
+
+
+
+
+ Run the following script:
+
+
+# xe-install-supplemental-pack xenserver-cloud-supp.iso
+
+
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
+
+# xe-switch-network-backend bridge
+
+
+
+
+
+
+
+
+ Reboot this XenServer host.
+
+
+
+
+
+ Run the following:
+
+
+/opt/xensource/bin/setupxenserver.sh
+
+
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+
+
+
+
+
+
+
+ Run the following:
+
+
+for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+
+
+
+
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+
+
+
+
+
+
+
+
+
+
+ Troubleshooting Tip
+
+ If passwords which you know to be valid appear not to work after upgrade, or other UI issues are seen, try clearing your browser cache and reloading the UI page.
+
+
+
+
+
+
+
+ Upgrade from 2.2.14 to 4.0.0-incubating
+
+
+
+ Ensure that you query your IPaddress usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.
+
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading to 4.0.0-incubating, any existing IP address usage records in the old format will no longer be available.
+
+
+
+
+
+ If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the instructions in the 2.2.14 Release Notes.
+
+
+ KVM Hosts
+
+ If KVM hypervisor is used in your cloud, be sure you completed the step to insert a valid username and password into the host_details table on each KVM node as described in the 2.2.14 Release Notes. This step is critical, as the database will be encrypted after the upgrade to 4.0.0-incubating.
+
+
+
+
+
+
+
+ While running the 2.2.14 system, log in to the UI as root administrator.
+
+
+
+
+
+ Using the UI, add a new System VM template for each hypervisor type that is used in your cloud. In each zone, add a system VM template for each hypervisor used in that zone
+
+
+
+
+ In the left navigation bar, click Templates.
+
+
+
+
+
+ In Select view, click Templates.
+
+
+
+
+
+ Click Register template.
+
+
+ The Register template dialog box is displayed.
+
+
+
+
+
+ In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):
+
+
+
+
+
+
+
+
+
+ Hypervisor
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+ XenServer
+
+
+
+
+ Name: systemvm-xenserver-3.0.0
+
+
+ Description: systemvm-xenserver-3.0.0
+
+
+ URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: XenServer
+
+
+ Format: VHD
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+
+
+
+
+ KVM
+
+
+
+
+ Name: systemvm-kvm-3.0.0
+
+
+ Description: systemvm-kvm-3.0.0
+
+
+ URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: KVM
+
+
+ Format: QCOW2
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+
+
+
+
+ VMware
+
+
+
+
+ Name: systemvm-vmware-3.0.0
+
+
+ Description: systemvm-vmware-3.0.0
+
+
+ URL: http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: VMware
+
+
+ Format: OVA
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful
+
+
+
+
+
+ WARNING: If you use more than one type of hypervisor in your cloud, be sure you have repeated these steps to download the system VM template for each hypervisor type. Otherwise, the upgrade will fail.
+
+
+
+
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+
+
+# service cloud-usage stop
+
+
+
+
+ Stop the Management Servers. Run this on all Management Server hosts.
+
+
+# service cloud-management stop
+
+
+
+
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+
+ 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.
+
+
+#mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp
+
+
+
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the &PRODUCT; binaries.
+
+
+
+
+
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade &PRODUCT;:
+#yum update cloud-*
+
+#apt-get update
+#apt-get upgrade cloud-*
+
+
+
+ You will, of course, have to agree to the changes suggested by Yum or APT.
+
+
+
+
+
+ If you have made changes to your existing copy of the file components.xml in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+
+
+ How will you know whether you need to do this? If the upgrade output in the previous step included a message like the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+
+
+
+
+warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+
+
+
+ Make a backup copy of your /etc/cloud/management/components.xml file. For example:
+
+
+#mv/etc/cloud/management/components.xml/etc/cloud/management/components.xml-backup
+
+
+
+
+ Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:
+
+
+#cp -ap /etc/cloud/management/components.xml.rpmnew/etc/cloud/management/components.xml
+
+
+
+
+ Merge your changes from the backup file into the new components.xml file.
+
+
+#vi/etc/cloud/management/components.xml
+
+
+
+
+
+
+
+
+
+ If you have made changes to your existing copy of the /etc/cloud/management/db.properties file in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+
+
+
+ Make a backup copy of your file /etc/cloud/management/db.properties. For example:
+
+
+#mv/etc/cloud/management/db.properties/etc/cloud/management/db.properties-backup
+
+
+
+
+ Copy /etc/cloud/management/db.properties.rpmnew to create a new /etc/cloud/management/db.properties:
+
+
+#cp -ap /etc/cloud/management/db.properties.rpmnewetc/cloud/management/db.properties
+
+
+
+
+ Merge your changes from the backup file into the new db.properties file.
+
+
+#vi/etc/cloud/management/db.properties
+
+
+
+
+
+
+
+
+ On the management server node, run the following command. It is recommended that you use the command-line flags to provide your own encryption keys. See Password and Key Encryption in the Installation Guide.
+
+
+#cloud-setup-encryption -e encryption_type -m management_server_key -k database_key
+
+ When used without arguments, as in the following example, the default encryption type and keys will be used:
+
+
+
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file.
+
+
+
+
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the properties file. Default: password. It is highly recommended that you replace this with a more secure value
+
+
+
+
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value.
+
+
+
+
+
+
+
+
+
+ Repeat steps 10 - 14 on every management server node. If you provided your own encryption key in step 14, use the same key on all other management servers.
+
+
+
+
+
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+
+
+# service cloud-management start
+
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. You should see a message like "Complete! Done." After confirmation, start the other Management Servers one at a time by running the same command on each node.
+
+
+
+
+
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
+
+# service cloud-usage start
+
+
+
+
+ (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+
+
+
+
+ Configure your CloudStack package repositories as outlined in the Installation Guide
+
+
+
+
+
+ Stop the running agent.
+
+
+# service cloud-agent stop
+
+
+
+
+ Update the agent software with one of the following command sets as appropriate.
+
+
+#yum update cloud-*
+
+
+ #apt-get update
+#apt-get upgrade cloud-*
+
+
+
+
+
+ Start the agent.
+
+
+# service cloud-agent start
+
+
+
+
+ Copy the contents of the agent.properties file to the new agent.properties file by using the following command
+
+
+sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.properties
+
+
+
+
+ Start the cloud agent and cloud management services.
+
+
+
+
+
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+
+
+
+
+
+
+
+
+
+ Log in to the CloudStack UI as admin, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
+
+ Do not proceed to the next step until the hosts show in the Up state. If the hosts do not come to the Up state, contact support.
+
+
+
+
+
+ Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers.
+
+
+
+
+ Run the command once on one management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the "-c" and "-r" arguments. For example:
+
+
+#nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+#tail -f sysvm.log
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+
+
+
+
+
+ After the script terminates, check the log to verify correct execution:
+
+
+#tail -f sysvm.log
+
+ The content should be like the following:
+
+
+
+Stopping and starting 1 secondary storage vm(s)...
+Done stopping and starting secondary storage vm(s)
+Stopping and starting 1 console proxy vm(s)...
+Done stopping and starting console proxy vm(s).
+Stopping and starting 4 running routing vm(s)...
+Done restarting router(s).
+
+
+
+
+
+
+
+
+
+ If you would like additional confirmation that the new system VM templates were correctly applied when these system VMs were rebooted, SSH into the System VM and check the version.
+
+
+ Use one of the following techniques, depending on the hypervisor.
+
+
+ XenServer or KVM:
+
+ SSH in by using the link local IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own link local IP.
+
+
+
+
+ Run the following commands on the XenServer or KVM host on which the system VM is present:
+
+
+#ssh -i private-key-pathlink-local-ip -p 3922
+# cat /etc/cloudstack-release
+
+ The output should be like the following:
+
+
+Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+
+ ESXi
+
+ SSH in using the private IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own private IP.
+
+
+
+
+ Run the following commands on the Management Server:
+
+
+#ssh -i private-key-pathprivate-ip -p 3922
+#cat/etc/cloudstack-release
+
+ The output should be like the following:
+
+
+Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+
+
+
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+
+
+
+
+
+ Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+
+
+
+
+ Disconnect the XenServer cluster from CloudStack.
+
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+
+
+
+
+
+ To clean up the VLAN, log in to one XenServer host and run:
+
+
+/opt/xensource/bin/cloud-clean-vlan.sh
+
+
+
+
+ Prepare the upgrade by running the following on one XenServer host:
+
+
+/opt/xensource/bin/cloud-prepare-upgrade.sh
+
+ If you see a message like "can't eject CD", log in to the VM and umount the CD, then run this script again.
+
+
+
+
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /root or /tmp.
+
+
+ On the Xen pool master, upload the hotfix with this command:
+
+
+xe patch-upload file-name=XS602E003.xsupdate
+
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+
+
+
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+
+
+
+
+
+
+
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
+
+# xe vm-list
+
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+
+#xe vm-migrate live=true host=host-name vm=VM-name
+
+ Troubleshooting
+
+ If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
+
+
+ /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.
+
+
+
+
+
+
+
+ Apply the hotfix. First, get the UUID of this host:
+
+
+ # xe host-list
+
+
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+
+ xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid
+
+
+
+
+
+ Copy the following files from the CloudStack Management Server to the host.
+
+
+
+
+
+
+
+
+
+ Copy from here...
+
+
+
+
+ ...to here
+
+
+
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
+
+
+
+
+ Download the CSP software onto the XenServer host from one of the following links:
+
+
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+
+
+
+ Extract the file:
+
+
+ # tar xf xenserver-cloud-supp.tgz
+
+
+
+
+
+ Run the following script:
+
+
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso
+
+
+
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
+
+ # xe-switch-network-backend bridge
+
+
+
+
+
+
+
+
+
+ Reboot this XenServer host.
+
+
+
+
+
+ Run the following:
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+
+
+
+
+
+
+
+ Run the following:
+
+
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+
+
+
+
+
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Version 4.0.0-incubating
+
+ What’s New in 4.0.0-incubating
+
+ Apache CloudStack 4.0.0-incubating includes the following new features:
+
+
+ Inter-VLAN Routing
+
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You can provision VLANs to the tiers your create, and VMs can be deployed on different tiers, such as Web, Application, or Database. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+
+
+
+
+ Site-to-Site VPN
+
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+
+ The supported endpoints on the remote datacenters are:
+
+
+
+
+ Cisco ISR with IOS 12.4 or later
+
+
+
+
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
+
+
+
+
+
+
+
+
+ Local Storage Support for Data Volumes
+
+ You can now create data volumes on local storage. The data volume is placed on the same XenServer host as the VM instance that is attached to the data volume. These local data volumes can be attached to virtual machines, detached, re-attached, and deleted just as with the other types of data volume. In earlier releases of CloudStack, only the root disk could be placed in local storage.
+
+
+ Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some of the benefits include reduced disk I/O latency and cost reduction from using inexpensive local disks.
+
+
+ In order for local volumes to be used, the feature must be enabled for the zone.
+
+
+ You can create a data disk offering for local storage. When a user creates a new VM, they can select this disk offering in order to cause the data disk volume to be placed in local storage.
+
+
+ You can not migrate a VM that has a volume in local storage to a different host, nor migrate the volume itself away to a different host. If you want to put a host into maintenance mode, you must first stop any VMs with local data volumes on that host.
+
+
+ Local storage support for volumes is available for XenServer, KVM, and VMware hypervisors.
+
+
+
+
+
+ Tags
+
+ 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 new 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.
+
+
+ A new optional input parameter, "tags," has been added to 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:
+
+
+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 new "tags" input parameter:
+
+
+
+
+ listVirtualMachines
+
+
+
+
+
+ listVolumes
+
+
+
+
+
+ listSnapshots
+
+
+
+
+
+ listNetworks
+
+
+
+
+
+ listTemplates
+
+
+
+
+
+ listIsos
+
+
+
+
+
+ listFirewallRules
+
+
+
+
+
+ listPortForwardingRules
+
+
+
+
+
+ listPublicIpAddresses
+
+
+
+
+
+ listSecurityGroups
+
+
+
+
+
+ listLoadBalancerRules
+
+
+
+
+
+ listProjects
+
+
+
+
+
+ listVPCs
+
+
+
+
+
+ listNetworkACLs
+
+
+
+
+
+ listStaticRoutes
+
+
+
+
+
+
+
+
+
+ AWS API Changes for Tags
+
+ Some changes have been made to the Amazon Web Services API compatibility support in order to accommodate the new tagging feature.
+
+
+ New APIs:
+
+
+
+
+
+
+
+
+
+ New API
+
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+
+ ec2-create-tags
+
+
+
+
+
+ Add tags to one or more resources.
+
+
+
+
+
+
+
+
+ ec2-delete-tags
+
+
+
+
+
+ Remove tags from one or more resources.
+
+
+
+
+
+
+
+ ec2-describe-tags
+
+
+
+ Show currently defined tags.
+
+
+
+
+
+
+
+
+
+
+
+
+ Changed APIs:
+
+
+
+
+
+
+
+
+
+ Changed API
+
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+ ec2-describe-images
+
+
+
+ Output now shows tags defined for each image.
+
+
+
+
+
+
+
+
+ ec2-describe-instances
+
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+
+
+
+
+ ec2-describe-snapshots
+
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+
+
+
+ ec2-describe-volumes
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Secure Console Access on XenServer
+
+ With the addition of Secure Console feature, users can now securely access the VM consoles on the XenServer hypervisor. You can either SSH or use the View Console option in the Management Server to securely connect to the VMs on the XenServer host. The Management Server uses the xapi API to stream the VM consoles. However, there is no change in the way you can access the console of a VM. This feature is supported on XenServer 5.6 and 6.0 versions.
+
+
+
+
+
+ Stopped VM
+
+ This release supports creating VMs without starting them on the backend. You can determine whether the VM needs to be started as part of the VM deployment. A VM can be deployed in two ways: create and start a VM (the default method); create a VM and leave it in the stopped state.
+
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. The possible values are:
+
+
+
+
+ true - The VM starts as a part of the VM deployment
+
+
+
+
+
+ false - The VM is left in stopped state at the end of the VM deployment
+
+
+
+
+
+
+
+
+
+ Uploading an Existing Volume to a Virtual Machine
+
+ Existing data can now be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs. The upload is performed by using HTTP. The uploaded volume is placed in the zone's secondary storage.
+
+
+ This functionality is supported for the following hypervisors:
+
+
+
+
+ Hypervisor : Disk Image Format
+
+
+
+
+
+ XenServer : VHD
+
+
+
+
+
+ VMware : OVA
+
+
+
+
+
+ KVM : QCOW2
+
+
+
+
+
+
+
+
+
+ Dedicated High-Availability Hosts
+
+ One or more hosts can now be designated for use only by high-availability (HA) enabled VMs that are restarted due to a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HA-enabled VMs make it easier to determine which VMs are restarted as part of the high-availability function. You can designate a host as a dedicated-HA restart node only if the Dedicated HA Hosts feature is enabled by setting the appropriate global configuration parameter.
+
+
+
+
+
+ Support for Amazon Web Services API
+
+ This release supports Amazon Web Services APIs, including Elastic Compute Cloud (EC2) API. Fidelity with the EC2 API and the installation experience for this functionality are both enhanced. In prior releases, users were required to install a separate component called CloudBridge, in addition to installing the Management Server. For new installations of CloudStack 4.0.0-incubating, this software is installed automatically along with CloudStack and runs in a more closely integrated fashion. The feature is disabled by default, but can be easily enabled by setting the appropriate global configuration parameter and performing a few setup steps.
+
+
+
+
+
+ The Nicira NVP Plugin
+
+ The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating this plug-in supports the Connectivity service. This service is responsible for creating Layer 2 networks supporting the networks created by guests. When a tenant creates a new network, instead of a traditional VLAN, a logical network will be created by sending the appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira NVP versions 2.1.0, 2.2.0 and 2.2.1.
+
+
+
+
+
+ Support for CAStor Cluster
+
+ CloudStack 4.0.0-incubating supports using a CAStor cluster as the back-end storage system for a CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends the existing storage classes and allows the storage configuration attribute to point to a CAStor cluster. This feature makes use of the CloudStack server's local disk to spool files before writing them to CAStor when handling the PUT operations. However, a file must be successfully written into the CAStor cluster prior to the return of a success code to the S3 client to ensure that the transaction outcome is correctly reported.
+
+
+ The S3 multipart file upload is not supported in this release. You are prompted with proper error message if a multipart upload is attempted.
+
+
+
+
+
+ Clustered Logical Volume Manager Support for KVM
+
+ This release adds Clustered Logical Volume Manager (CLVM) storage support for KVM hosts. With this support, you can use CLVM as primary storage.
+
+
+ The CLVM support for KVM allows root and data disks (primary storage) to reside on Linux logical volumes. The administrators are required to configure CLVM on the KVM hosts independent of CloudStack. When the volume groups are available, an administrator can simply add primary storage of type CLVM, providing the volume group name. Then CloudStack creates and manages logical volumes as needed.
+
+
+ CLVM also supports Snapshots. CloudStack creates an LVM snapshot, copy the applicable logical volume to the secondary storage in the qcow2 format, and then delete the LVM snapshot.
+
+
+
+
+
+ Rados Block Device Support for KVM
+
+ You can now use Rados Block Device (RBD) to run instances on Apache CloudStack 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least 0.10 with RBD enabled on the KVM host
+
+
+ Create a disk offering for RBD so that you can ensure that StoragePoolAllocator chooses the RBD pool to deploy instances.
+
+
+
+
+
+
+
+
+ Issues Fixed in 4.0.0-incubating
+
+ Many bugs include a defect number that reflects the bug number that was held in the bug tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira to manage its bugs, so some of the bugs that are referenced here may not be available to view. However, we are still including them for completeness.
+
+
+
+
+
+
+
+
+
+ Defect
+
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+
+ Many
+
+
+
+
+ vSphere 5.0 now has GA support. Formerly only Beta support was provided.
+
+
+
+
+
+
+
+ CS-16135
+
+
+
+
+ Creating volumes after upgrading from snapshot taken in 2.2.14 no longer deletes the snapshot physically from the secondary storage.
+
+
+
+
+
+
+
+ CS-16122
+
+
+
+
+ In a site-to-site VPN setup, alerts are generated when the VPC virtual router is rebooted with multiple vpn connections.
+
+
+
+
+
+
+
+ CS-16022
+
+
+
+
+ If host connection fails due to a database error, host now disconnects and the Managerment Server id is removed.
+
+
+
+
+
+
+
+ CS-16011
+
+
+
+
+ Name of network offering is no longer truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+
+
+
+
+ CS-15978
+
+
+
+
+ When the virtual router and its host go down, the high availability mechanism now works for the virtual router.
+
+
+
+
+
+
+
+
+ CS-15921
+
+
+
+
+ The 2.2.x security group script now accounts for the VMs created in the version 2.1 timeframe.
+
+
+
+
+
+
+
+
+ CS-15919
+
+
+
+
+ A level parameter is added to the listVolumes command; therefore queries return the response more quickly.
+
+
+
+
+
+
+
+ CS-15904
+
+
+
+
+ Upgrade from version 2.2.14 to CloudStack-3.0.5-0.2944-rhel5 works as expected. The upgrade script, /usr/share/cloud/setup/db/schema-2214to30-cleanup.sql, works as expected.
+
+
+
+
+
+
+
+ CS-15879
+
+
+
+
+ The database upgrade from version 3.0.4 to 3.0.5 works as expected.
+
+
+
+
+
+
+
+
+ CS-15807
+
+
+
+
+ Network label for OVM now available in UI.
+
+
+
+
+
+
+
+
+ CS-15779
+
+
+
+
+ When the thumbnail is requested, the console session will not be terminated.
+
+
+
+
+
+
+
+
+ CS-15778
+
+
+
+
+ Fetching a VM thumbnail now gets a thumbnail of appropriate visual dimensions.
+
+
+
+
+
+
+
+
+ CS-15734
+
+
+
+
+ KVM Snapshots no longer shows incorrect disk usage.
+
+
+
+
+
+
+
+ CS-15733
+
+
+
+
+ The domainId parameter for the listNetworks command now lists the resources belonging to the domain specified.
+
+
+
+
+
+
+
+ CS-15676
+
+
+
+
+ Stopping the router no longer fails with the null pointer exception.
+
+
+
+
+
+
+
+
+ CS-15648
+
+
+
+
+ If creating a volume from a snapshot fails, the error is reported on the UI but the volume is stuck in the creating state.
+
+
+
+
+
+
+
+
+ CS-15646
+
+
+
+
+ createFirewallRule API no longer causes null pointer exception.
+
+
+
+
+
+
+
+ CS-15628
+
+
+
+
+ In a KVM host, the high availability mechanism no longer takes a long time to migrate VMs to another KVM host if there are multiple storage pools.
+
+
+
+
+
+
+
+ CS-15627
+
+
+
+
+ Metadata instance-id and vm-id for existing VMs stays the same after upgrade.
+
+
+
+
+
+
+
+ CS-15621
+
+
+
+
+ Solved difficulty with allocating disk volumes when running multiple VM deployment in parallel.
+
+
+
+
+
+
+
+ CS-15603
+
+
+
+
+ CloudStack now stop the VMs when destroyVM command is called.
+
+
+
+
+
+
+
+ CS-15586
+
+
+
+
+ Public Vlan for an account no longer fails if multiple physical networks are present.
+
+
+
+
+
+
+
+ CS-15582
+
+
+
+
+ The dns-name filter is now supported for ec2-describe-instances in the Amazon Web Services API compatibility commands. The filter maps to the name of a user VM.
+
+
+
+
+
+
+
+ CS-15503
+
+
+
+
+ An IP address which has static NAT rules can now be released. Subsequently, restarting this network after it was shutdown can succeed.
+
+
+
+
+
+
+
+ CS-15464
+
+
+
+
+ Can now delete static route whose state is set to Revoke.
+
+
+
+
+
+
+
+ CS-15443
+
+
+
+
+ Creating a firewall rule no longer fails with an internal server error.
+
+
+
+
+
+
+
+ CS-15398
+
+
+
+
+ Corrected technique for programming DNS on the user VMs.
+
+
+
+
+
+
+
+ CS-15356
+
+
+
+
+ Internal DNS 2 entry now correctly shown in UI.
+
+
+
+
+
+
+
+ CS-15335
+
+
+
+
+ The CloudBridge S3 Engine now connects to the database by using the deciphered password in the db.properties file.
+
+
+
+
+
+
+
+ CS-15318
+
+
+
+
+ UI now correctly prevents the user from stopping a VM that is in the Starting state.
+
+
+
+
+
+
+
+ CS-15307
+
+
+
+
+ Fixed Japanese localization of instance statuses in the Instances menu.
+
+
+
+
+
+
+
+ CS-15278
+
+
+
+
+ The deployment planner no longer takes long time to locate a suitable host to deploy VMs when large number of clusters are present.
+
+
+
+
+
+
+
+ CS-15274
+
+
+
+
+ Creating a VLAN range using Zone ID without network ID now succeeds.
+
+
+
+
+
+
+
+ CS-15243
+
+
+
+
+ Now check to be sure source NAT and VPN have same provider.
+
+
+
+
+
+
+
+ CS-15232
+
+
+
+
+ Ensure that networks using external load balancer/firewall in 2.2.14 or earlier can properly upgrade.
+
+
+
+
+
+
+
+ CS-15200
+
+
+
+
+ No exception when trying to attach the same volume while attaching the first volume is in progress.
+
+
+
+
+
+
+
+ CS-15173
+
+
+
+
+ Additional cluster can no longer be added with same VSM IP address as another cluster.
+
+
+
+
+
+
+
+ CS-15167
+
+
+
+
+ AWS API calls now honor the admin account's ability to view or act on the resources owned by the regular users.
+
+
+
+
+
+
+
+ CS-15163
+
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+
+
+
+
+ CS-15157
+
+
+
+
+ Can now add/enable service providers for multiple physical networks through the UI.
+
+
+
+
+
+
+
+ CS-15145
+
+
+
+
+ AWS API call ec2-register has better error handling for negative cases.
+
+
+
+
+
+
+
+ CS-15122
+
+
+
+
+ Filters now supported for AWS API call ec2-describe-availability-zones.
+
+
+
+
+
+
+
+ CS-15120
+
+
+
+
+ Actions column in UI of Volume page now shows action links.
+
+
+
+
+
+
+
+ CS-15099
+
+
+
+
+ Buttons no longer overlap text on Account Deletion confirmation page in UI.
+
+
+
+
+
+
+
+ CS-15095
+
+
+
+
+ Ensures you can not create a VM with a CPU frequency greater than the host CPU frequency.
+
+
+
+
+
+
+
+ CS-15094
+
+
+
+
+ CPU cap now set properly in VMware.
+
+
+
+
+
+
+
+ CS-15077
+
+
+
+
+ NullPointerException is no longer observed while executing the command to list the public IP in a basic zone created with the default shared NetScaler EIP and ELB network offering.
+
+
+
+
+
+
+
+ CS-15044
+
+
+
+
+ UI now provides option to view the list of instances which are part of the guest network.
+
+
+
+
+
+
+
+ CS-15026
+
+
+
+
+ UI in Deploy VM dialog now lists only templates or ISOs depending on which is selected in previous dialog.
+
+
+
+
+
+
+
+ CS-14989
+
+
+
+
+ In KVM, the Create Instance wizard now shows only templates from the current (KVM) zone.
+
+
+
+
+
+
+
+ CS-14986, CS-14985
+
+
+
+
+ Listing filters works as expected in the ec2-describe-volumes and ec2-describe-snapshots commands.
+
+
+
+
+
+
+
+ CS-14964
+
+
+
+
+ Automatically starting the Console Proxy no longer fails due to its missing volume on the primary storage
+
+
+
+
+
+
+
+ CS-14907
+
+
+
+
+ User is now correctly prevented from trying to download an uploaded volume which has not yet been moved to primary storage.
+
+
+
+
+
+
+
+ CS-14879
+
+
+
+
+ When a user VM is stopped or terminated, the static NAT associated with this VM is now disabled. This public IP address is no longer owned by this account and can be associated to any other user VM.
+
+
+
+
+
+
+
+ CS-14854
+
+
+
+
+ Only the admin user can change the template permission to Public, so this option is removed from the UI for domain Admins and regular Users.
+
+
+
+
+
+
+
+ CS-14817
+
+
+
+
+ While checking if network has any external provider, CloudStack will consider all providers in the network.
+
+
+
+
+
+
+
+ CS-14796
+
+
+
+
+ When deploying a VM with ec2-run-instances, userdata is now encoded.
+
+
+
+
+
+
+
+ CS-14770
+
+
+
+
+ The API returns the keypair information when a VM is deployed with sshkey. This affects the API commands related to virtual machines (deployVirtualMachine, listVirtualMachines, ... *VirtualMachine), as well as the corresponding AWS APIs.
+
+
+
+
+
+
+
+ CS-14724
+
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+
+
+
+
+ CS-14345
+
+
+
+
+ Logout API returns XML header.
+
+
+
+
+
+
+
+ CS-14724
+
+
+
+
+ Host IPs now associated with appropriate IPs according to traffic type.
+
+
+
+
+
+
+
+ CS-14253
+
+
+
+
+ Can now delete and re-create port forwarding rule on same firewall.
+
+
+
+
+
+
+
+ CS-14724
+
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+
+
+
+
+ CS-14452
+
+
+
+
+ Data disk volumes are now automatically copied from one cluster to another.
+
+
+
+
+
+
+
+ CS-13539
+
+
+
+
+ Windows VM can get IP after reboot.
+
+
+
+
+
+
+
+ CS-13537
+
+
+
+
+ When user tries to delete a domain that contains sub-domains, an error message is now sent to convey the reason for the delete failure.
+
+
+
+
+
+
+
+ CS-13153
+
+
+
+
+ System VMs support HTTP proxy.
+
+
+
+
+
+
+
+ CS-12642
+
+
+
+
+ Added Close button to Select Project list view popup in UI.
+
+
+
+
+
+
+
+ CS-12510
+
+
+
+
+ Deleting and reinserting host_details no longer causes deadlocks.
+
+
+
+
+
+
+
+ CS-12407
+
+
+
+
+ F5 and Netscaler - when dedicated is selected, capacity field is disabled.
+
+
+
+
+
+
+
+ CS-12111
+
+
+
+
+ Email validation for edit user form.
+
+
+
+
+
+
+
+ CS-10928
+
+
+
+
+ Network read/write values now always positive numbers.
+
+
+
+
+
+
+
+ CS-15376, CS-15373
+
+
+
+
+ The AWS APIs (EC2 and S3) now listen on the 7080 port and send request to CloudStack on the 8080 port just as any other clients of CloudStack.
+
+
+
+
+
+
+
+ CS-13944
+
+
+
+
+ The CloudStack 2.2.x to 3.0.x database upgrade for multiple physical networks is now supported.
+
+
+
+
+
+
+
+ CS-15300
+
+
+
+
+ The admin accounts of a domain now honour the limits imposed on that domain just like the regular accounts do. A domain admin now is not allowed to create an unlimited number of instances, volumes, snapshots, and so on.
+
+
+
+
+
+
+
+ CS-15396
+
+
+
+
+ The CloudStack database now contain the UUD information after the 2.2.14 to 3.0.4 upgrade.
+
+
+
+
+
+
+
+ CS-15450
+
+
+
+
+ Upgrade from 2.2.14 to 3.0.4 no longer fails on a VMware host.
+
+
+
+
+
+
+
+ CS-15449
+
+
+
+
+ Running cloudstack-aws-api-register no longer fails with the "User registration failed with error: [Errno 113] No route to host" error.
+
+
+
+
+
+
+
+ CS-15455
+
+
+
+
+ The iptable rules are configured to open the awsapi port (7080) as part of the installation.
+
+
+
+
+
+
+
+ CS-15429
+
+
+
+
+ While creating an instance with data volume, disk offering also is considered while checking the account limit on volume resources.
+
+
+
+
+
+
+
+ CS-15414
+
+
+
+
+ After the 2.2.14 to 3.0.4 upgrade, the value of the global parameter xen.guest.network.device is now decrypted before setting the traffic label.
+
+
+
+
+
+
+
+ CS-15382
+
+
+
+
+ During 2.2.14 to 3.0.4 upgrade, the hosts no longer go to the Alert state if destroyed networks existed with non-existent tags prior to upgrade.
+
+
+
+
+
+
+
+ CS-15323
+
+
+
+
+ CloudStack supports the following Citrix XenServer hotfixes: XS602E003, XS602E004, and XS602E005.
+
+
+
+
+
+
+
+ CS-15430
+
+
+
+
+ Create snapshot now fails if creating a snapshot exceeds the snapshot resource limit for a domain admin or a user account.
+
+
+
+
+
+
+
+ CS-14256
+
+
+
+
+ Virtual Router no longer remains in starting state for subdomain or user on a KVM 3.0.1 prerlease host on RHEL 6.2.
+
+
+
+
+
+
+
+ CS-7495
+
+
+
+
+ Implemented a variety of Xen management host improvements.
+
+
+
+
+
+
+
+ CS-8105
+
+
+
+
+ NFS v4 for primary storage now works as expected on KVM hosts.
+
+
+
+
+
+
+
+ CS-9989
+
+
+
+
+ The error messages returned during VM deployment failure will have much more details than before.
+
+
+
+
+
+
+
+ CS-12584
+
+
+
+
+ You can no longer add security groups not supported by the hypervisor in use.
+
+
+
+
+
+
+
+ CS-12705
+
+
+
+
+ When creating a Network offering by using SRX as the service provider for SourceNAT servcies, an option is given in the CloudStack UI now to set the source_nat type to "per Zone"/"per account".
+
+
+
+
+
+
+
+ CS-12782
+
+
+
+
+ Assigning a VM from Basic to Advanced zone no longer ignores the network ID. A warning message is displayed for VM movements across zones.
+
+
+
+
+
+
+
+ CS-12591
+
+
+
+
+ Broadcast Address on the Second Public IP NIC is now corrected.
+
+
+
+
+
+
+
+ CS-13272
+
+
+
+
+ When a user is deleted, all the associated properties, such as IPs and virtual routers, are now deleted.
+
+
+
+
+
+
+
+ CS-13377
+
+
+
+
+ Creating template from a root disk of a stopped instance now provides an option to make it a "Featured template".
+
+
+
+
+
+
+
+ CS-13500
+
+
+
+
+ Reaching the first guest VM by using its public IP from the second guest VM no longer fails.
+
+
+
+
+
+
+
+ CS-13853
+
+
+
+
+ The default gateway can no longer be 0.0.0.0 in the Secondary Storage VM (SSVM).
+
+
+
+
+
+
+
+ CS-13863
+
+
+
+
+ The queryAsyncJobResult command in XML format now returns the correct UUIDs.
+
+
+
+
+
+
+
+ CS-13867
+
+
+
+
+ Corrected CSP xenserver-cloud-supp.tgz for XenServer 5.6 and 6.0.
+
+
+
+
+
+
+
+ CS-13904
+
+
+
+
+ Labels and values for the service offerings CPU and memory are now consistent.
+
+
+
+
+
+
+
+ CS-13998
+
+
+
+
+ The SSVM kernel panic issue is fixed on XenServer.
+
+
+
+
+
+
+
+ CS-14090
+
+
+
+
+ The issue is fixed where running the VMware snapshots randomly fails with the ArrayIndexOutOfBoundsException error.
+
+
+
+
+
+
+
+ CS-14021
+
+
+
+
+ The java.lang.OutOfMemoryError is fixed on the Management Server.
+
+
+
+
+
+
+
+ CS-14025
+
+
+
+
+ The Python Eggs are provided to easily package the test client for each branch of CloudStack.
+
+
+
+
+
+
+
+ CS-14068
+
+
+
+
+ Resetting the VM password through the CloudStack UI no longer causes any error.
+
+
+
+
+
+
+
+ CS-14156
+
+
+
+
+ The pod which has the administrator's virtual router is no longer selected while creating the virtual routers for guests.
+
+
+
+
+
+
+
+ CS-14182
+
+
+
+
+ The users can now delete their ISOs as normal users.
+
+
+
+
+
+
+
+ CS-14185
+
+
+
+
+ The listOSTypes API now filters out the types of operating system by using the keywords.
+
+
+
+
+
+
+
+ CS-14204
+
+
+
+
+ The cloud-setup-bonding.sh command no longer generates the "command not found" error.
+
+
+
+
+
+
+
+ CS-14214
+
+
+
+
+ The Specify VLAN option cannot be enabled now for an isolated Network offering with SourceNAT enabled.
+
+
+
+
+
+
+
+ CS-14234
+
+
+
+
+ Sending project invite email to an account now requires SMTP configured in CloudStack.
+
+
+
+
+
+
+
+ CS-14237
+
+
+
+
+ The garbage collector of the primary storage no longer fails when the first host in the cluster is not up.
+
+
+
+
+
+
+
+ CS-14241
+
+
+
+
+ Custom Volume Disk Offering is now matching the Global configuration value.
+
+
+
+
+
+
+
+ CS-14270
+
+
+
+
+ The listNetworks API no longer assumes that the broadcast type is always VLAN.
+
+
+
+
+
+
+
+ CS-14319
+
+
+
+
+ The internal name of the VM is no longer present in the error message that is displayed to a domain administrator.
+
+
+
+
+
+
+
+ CS-14321
+
+
+
+
+ The listVolumes API call now returns a valid value for the isExtractable parameter for the ISO-derived disk and data disk volumes.
+
+
+
+
+
+
+
+ CS-14323
+
+
+
+
+ Invalid API calls will now give valid response in json/xml format.
+
+
+
+
+
+
+
+ CS-14339
+
+
+
+
+ Custom Disk Size will now allow values larger than 100GB.
+
+
+
+
+
+
+
+ CS-14357
+
+
+
+
+ The ConsoleProxyLoadReportCommand is no longer fired continuously.
+
+
+
+
+
+
+
+ CS-14421
+
+
+
+
+ Fixed the issue of virtual router deployments. The DHCP entries can now be assigned to the router.
+
+
+
+
+
+
+
+ CS-14555
+
+
+
+
+ Unzipped downloaded template MD5SUM will no longer override the zipped template MD5SUM in the database.
+
+
+
+
+
+
+
+ CS-14598
+
+
+
+
+ The complete screen of the running VM is now displayed in the console proxy.
+
+
+
+
+
+
+
+ CS-14600
+
+
+
+
+ Windows or Linux based consoles are no longer lost upon rebooting VMs.
+
+
+
+
+
+
+
+ CS-14784
+
+
+
+
+ Multiple subnets with the same VLAN now work as expected.
+
+
+
+
+
+
+
+ CS-13303, 14874, 13897, 13944, 14088, 14190
+
+
+
+
+ A variety of upgrade issues have been fixed in release 3.0.3.
+
+
+
+
+
+
+
+ CS-15080
+
+
+
+
+ Setting a private network on a VLAN for VMWare environment is now supported.
+
+
+
+
+
+
+
+ CS-15168
+
+
+
+
+ The console proxy now works as expected and no exception is shown in the log after upgrading from version 2.2.14 to 3.0.2.
+
+
+
+
+
+
+
+ CS-15172
+
+
+
+
+ Version 3.0.2 now accepts the valid public key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Known Issues in 4.0.0-incubating
+
+
+
+
+
+
+
+
+ Issue ID
+
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+
+ CLOUDSTACK-301
+
+
+
+
+ Nexus 1000v DVS integration is not functional
+
+
+ This source code release includes some partial functionality to support the Cisco Nexus 1000v Distributed Virtual Switch within a VMware hypervisor environment. The functionality is not complete at this time.
+
+
+
+
+
+
+
+
+ CLOUDSTACK-368
+
+
+
+
+ OVM - cannot create guest VM
+
+
+ This source code release has regressed from the CloudStack 2.2.x code and is unable to support Oracle VM (OVM).
+
+
+
+
+
+
+
+
+ CLOUDSTACK-279
+
+
+
+
+ Deleting a project fails when executed by the regular user. This works as expected for root/domain admin. To workaround, perform either of the following:
+
+
+
+
+ Use the account cleanup thread which will eventually complete the project deletion.
+
+
+
+
+
+ Execute the call as the root/domain admin on behalf of the regular user.
+
+
+
+
+
+
+
+
+
+
+
+
+ CS-16067
+
+
+
+
+ The command=listTags&key=city command does not work as expected. The command does not return tags for the resources of the account with the tag, city
+
+
+
+
+
+
+
+
+ CS-16063
+
+
+
+
+ The current values of volumes and snapshots are incorrect when using KVM as a host. To fix this, the database upgrade codes, volumes.size and snapshots.size, should be changed to show the virtual sizes.
+
+
+
+
+
+
+
+
+ CS-16058
+
+
+
+
+ Null pointer Exception while deleting the host after moving the host to maintenance state.
+
+
+
+
+
+
+
+
+ CS-16045
+
+
+
+
+ Only the root administrator can handle the API keys. The domain administrators are not allowed to create, delete, or retrieve API keys for the users in their domain.
+
+
+
+
+
+
+
+
+ CS-16019
+
+
+
+
+ CIDR list in the Add VPN Customer Gateway dialog does not prompt the user that they can provide a comma separated CIDRs if multiple CIDRs have to be supplied.
+
+
+
+
+
+
+
+
+ CS-16015
+
+
+
+
+ Deleting a network is not supported when its network providers are disabled.
+
+
+
+
+
+
+
+
+ CS-16012
+
+
+
+
+ Unable to delete a zone in the UI because the necessary cleanup cannot be completed. When the hosts are removed, the expunge process fails to delete the volumes as no hosts are present to send the commands to. Therefore, the storage pool removal fails, and zone can't be cleaned and deleted.
+
+
+
+
+
+
+
+
+ CS-16011
+
+
+
+
+ Name of network offering might be truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+
+
+
+
+ CS-15789
+
+
+
+
+ Invalid global setting prevents management server to restart. For example, if you configure the "project.invite.timeout" parameter to "300" and attempt to restart management server, it fails without throwing a warning or setting the value to the default.
+
+
+
+
+
+
+
+
+ CS-15749
+
+
+
+
+ Restarting VPC is resulting in intermittent connection loss to the port forwarding and StaticNAT rules.
+
+
+
+
+
+
+
+
+ CS-15690
+
+
+
+
+ The IpAssoc command failed as a part of starting the virtual router, but the final start result is reported as succes.
+
+
+
+
+
+
+
+
+ CS-15672, CS-15635
+
+
+
+
+ The FQDN of the VM is not configured if it is deployed as a part of default shared network and isolated guest network (DefaultIsolatedNetworkOfferingWithSourceNatService).
+
+
+
+
+
+
+
+
+ CS-15634
+
+
+
+
+ The FQDN of a VM that is deployed as a part of both a shared network and default isolated guest network has the suffix of the shared network instead of the default isolated guest network.
+
+
+
+
+
+
+
+
+ CS-15576
+
+
+
+
+ Stopping a VM on XenServer creates a backlog of API commands. For example, the Attach volume calls become delayed while waiting for the stopVirtualMachine command to be executed.
+
+
+
+
+
+
+
+
+ CS-15569
+
+
+
+
+ Misleading error message in the exception when creating a StaticNAT rule fails in a VPC.
+
+
+
+
+
+
+
+
+ CS-15566
+
+
+
+
+ External device such as Netscaler is not supported in VPC.
+
+
+
+
+
+
+
+ CS-15557
+
+
+
+
+ Intermittent traffic loss in the VPN connection if Juniper is the remote router and the life time is 300 seconds.
+
+
+
+
+
+
+
+
+ CS-15361
+
+
+
+
+ Egress rules are not working in NetScaler loadbalancer.
+
+
+
+
+
+
+
+
+ CS-15163
+
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+
+
+
+
+ CS-15105
+
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+
+
+
+
+ CS-15092
+
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+
+
+
+
+ CS-15037
+
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+
+
+
+
+ CS-15009
+
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+
+
+
+
+ CS-14939
+
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+
+
+
+
+ CS-14780
+
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+
+
+
+
+ CS-14756
+
+
+
+
+ Installing KVM on RHEL 6.2 will result in unreliable network performance. Workaround: blacklist vhost-net. Edit /etc/modprobe.d/blacklist-kvm.conf and include vhost-net.
+
+
+
+
+
+
+
+ CS-14346
+
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+
+
+
+
+ CS-14303 (was 14537)
+
+
+
+
+ The IP addresses for a shared network are still being consumed even if no services are defined for that network.
+
+
+
+
+
+
+
+ CS-14296 (was 14530)
+
+
+
+
+ OVM: Network traffic labels are not supported.
+
+
+
+
+
+
+
+ CS-14291 (was 14523)
+
+
+
+
+ The EIP/ELB network offering for basic zones does not support multiple NetScalers.
+
+
+
+
+
+
+
+ CS-14275 (was 14506)
+
+
+
+
+ F5: Unable to properly remove a F5 device.
+
+
+
+
+
+
+
+ CS-14201 (was 14430)
+
+
+
+
+ VMWare: Template sizes are being reported different depending on whether the primary storage is using ISCSI or NFS.
+
+
+
+
+
+
+
+ CS-13758 (was 13963)
+
+
+
+
+ vSphere: template download from templates created off of the root volume does not work properly.
+
+
+
+
+
+
+
+ CS-13733 (was 13935)
+
+
+
+
+ vSphere: detaching an ISO from a restored VM instance fails.
+
+
+
+
+
+
+
+ CS-13682 (was 13883)
+
+
+
+
+ Multiple NetScalers are not supported in Basic Networking.
+
+
+
+
+
+
+
+ CS-13599 (was 13359)
+
+
+
+
+ Programming F5/NetScaler rules can be better optimized.
+
+
+
+
+
+
+
+ CS-13337 (was 13518)
+
+
+
+
+ Security Groups are not supported in Advanced Networking
+
+
+
+
+
+
+
+ CS-13173 (was 13336)
+
+
+
+
+ vSphere: cross cluster volume migration does not work properly.
+
+
+
+
+
+
+
+ CS-12714 (was 12840)
+
+
+
+
+ Capacity view is not available for pods or clusters.
+
+
+
+
+
+
+
+ CS-12624 (was 12741)
+
+
+
+
+ vSphere: maintenance mode will not live migrate system VM to another host.
+
+
+
+
+
+
+
+ CS-15476
+
+
+
+
+
+ The 2.2.14 to 4.0.0-incubating upgrade fails if multiple untagged physical networks exist before the upgrade.
+
+
+
+
+
+
+
+
+ CS-15407
+
+
+
+
+
+ After the 2.2.14 to 4.0.0-incubating upgrade, VLAN allocation on multiple physical networks does not happen as expected.
+
+
+ To workaround this issue, follow the instructions given below:
+
+
+
+
+ Revert to your 2.2.14 setup.
+
+
+
+
+
+ Stop all the VMs with the isolated virtual networks in your cloud setup.
+
+
+
+
+
+ Run following query to find if any networks still have the NICs allocated:
+
+
+
+
+ Check if any virtual guest networks have the NICs allocated:
+
+
+#SELECT DISTINCT op.id from `cloud`.`op_networks` op JOIN `cloud`.`networks` n on op.id=n.id WHERE nics_count != 0 AND guest_type = 'Virtual';
+
+
+
+
+ If this returns any network IDs, then ensure the following:
+
+
+
+
+ All the VMs are stopped.
+
+
+
+
+
+ No new VM is started.
+
+
+
+
+
+ Shutdown the Management Server.
+
+
+
+
+
+
+
+
+
+ Remove the NICs count for the virtual network IDs returned in step (a), and set the NIC count to 0:
+
+
+UPDATE `cloud`.`op_networks` SET nics_count = 0 WHERE id = enter id of virtual network
+
+
+
+
+ Restart the Management Server, and wait for all the networks to shut down.
+
+
+
+ Networks shutdown is determined by the network.gc.interval and network.gc.wait parameters.
+
+
+
+
+
+
+
+
+
+
+
+ Ensure that all the networks are shut down and all the guest VNETs are free.
+
+
+
+
+
+ Run the upgrade script.
+
+
+ This allocates all your guest VNET ranges to the first physical network.
+
+
+
+
+
+ By using the updatePhysicalNetwork API, reconfigure the VNET ranges for each physical network as desired.
+
+
+
+
+
+ Start all the VMs.
+
+
+
+
+
+
+
+
+
+
+
+
+ CS-14680
+
+
+
+
+
+ CloudStack and LDAP user validation cannot happen simultaneously because the user password is hashed and stored in the database, and LDAP requires the passwords in plain text.
+
+
+ To work with the LDAP user, the MD5 hash should be disabled in the login process by commenting the following variable in sharedFunctions.js file available at /usr/share/cloud/management/webapps/client/scripts, and restart the cloud-management service.
+
+
+var md5HashedLogin = false;
+
+ However, if md5HashedLogin is set to false, the end user can login with the LDAP credentials but not with the CloudStack user credentials.
+
+
+
+
+
+
+
+
+ CS-14346
+
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+
+
+
+
+ CS-15130
+
+
+
+
+ Data disk volumes are not automatically copied from one cluster to another.
+
+
+
+
+
+
+
+ CS-14780
+
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+
+
+
+
+ CS-14939
+
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+
+
+
+
+ CS-15009
+
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+
+
+
+
+ CS-15037
+
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+
+
+
+
+ CS-15092
+
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+
+
+
+
+ CS-15105
+
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+
+
+
+
+ CS-15163
+
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ API Changes from 3.0.2 to 4.0.0-incubating
+
+ New API Commands in 4.0.0-incubating
+
+
+
+ createCounter (Adds metric counter)
+
+
+
+
+
+ deleteCounter (Deletes a counter)
+
+
+
+
+
+ listCounters (List the counters)
+
+
+
+
+
+ createCondition (Creates a condition)
+
+
+
+
+
+ deleteCondition (Removes a condition)
+
+
+
+
+
+ listConditions (List Conditions for the specific user)
+
+
+
+
+
+ createTags. Add tags to one or more resources. Example:
+command=createTags
+&resourceIds=1,10,12
+&resourceType=userVm
+&tags[0].key=region
+&tags[0].value=canada
+&tags[1].key=city
+&tags[1].value=Toronto
+
+
+
+
+
+ deleteTags. Remove tags from one or more resources. Example:
+command=deleteTags
+&resourceIds=1,12
+&resourceType=Snapshot
+&tags[0].key=city
+
+
+
+
+
+ listTags (Show currently defined resource tags)
+
+
+
+
+
+ createVPC (Creates a VPC)
+
+
+
+
+
+ listVPCs (Lists VPCs)
+
+
+
+
+
+ deleteVPC (Deletes a VPC)
+
+
+
+
+
+ updateVPC (Updates a VPC)
+
+
+
+
+
+ restartVPC (Restarts a VPC)
+
+
+
+
+
+ createVPCOffering (Creates VPC offering)
+
+
+
+
+
+ updateVPCOffering (Updates VPC offering)
+
+
+
+
+
+ deleteVPCOffering (Deletes VPC offering)
+
+
+
+
+
+ listVPCOfferings (Lists VPC offerings)
+
+
+
+
+
+ createPrivateGateway (Creates a private gateway)
+
+
+
+
+
+ listPrivateGateways (List private gateways)
+
+
+
+
+
+ deletePrivateGateway (Deletes a Private gateway)
+
+
+
+
+
+ createNetworkACL (Creates a ACL rule the given network (the network has to belong to VPC))
+
+
+
+
+
+ deleteNetworkACL (Deletes a Network ACL)
+
+
+
+
+
+ listNetworkACLs (Lists all network ACLs)
+
+
+
+
+
+ createStaticRoute (Creates a static route)
+
+
+
+
+
+ deleteStaticRoute (Deletes a static route)
+
+
+
+
+
+ listStaticRoutes (Lists all static routes)
+
+
+
+
+
+ createVpnCustomerGateway (Creates site to site vpn customer gateway)
+
+
+
+
+
+ createVpnGateway (Creates site to site vpn local gateway)
+
+
+
+
+
+ createVpnConnection (Create site to site vpn connection)
+
+
+
+
+
+ deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
+
+
+
+
+
+ deleteVpnGateway (Delete site to site vpn gateway)
+
+
+
+
+
+ deleteVpnConnection (Delete site to site vpn connection)
+
+
+
+
+
+ updateVpnCustomerGateway (Update site to site vpn customer gateway)
+
+
+
+
+
+ resetVpnConnection (Reset site to site vpn connection)
+
+
+
+
+
+ listVpnCustomerGateways (Lists site to site vpn customer gateways)
+
+
+
+
+
+ listVpnGateways (Lists site 2 site vpn gateways)
+
+
+
+
+
+ listVpnConnections (Lists site to site vpn connection gateways)
+
+
+
+
+
+ markDefaultZoneForAccount (Marks a default zone for the current account)
+
+
+
+
+
+ uploadVolume (Uploads a data disk)
+
+
+
+
+
+
+
+
+
+ Changed API Commands in 4.0.0-incubating
+
+
+
+
+
+
+
+
+ API Commands
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+ copyTemplate
+
+
+ prepareTemplate
+
+
+ registerTemplate
+
+
+ updateTemplate
+
+
+ createProject
+
+
+ activateProject
+
+
+ suspendProject
+
+
+ updateProject
+
+
+ listProjectAccounts
+
+
+ createVolume
+
+
+ migrateVolume
+
+
+ attachVolume
+
+
+ detachVolume
+
+
+ uploadVolume
+
+
+ createSecurityGroup
+
+
+ registerIso
+
+
+ copyIso
+
+
+ updateIso
+
+
+ createIpForwardingRule
+
+
+ listIpForwardingRules
+
+
+ createLoadBalancerRule
+
+
+ updateLoadBalancerRule
+
+
+ createSnapshot
+
+
+
+
+
+ The commands in this list have a single new response parameter, and no other changes.
+
+
+ New response parameter: tags(*)
+
+
+
+ Many other commands also have the new tags(*) parameter in addition to other changes; those commands are listed separately.
+
+
+
+
+
+
+
+
+
+ rebootVirtualMachine
+
+
+ attachIso
+
+
+ detachIso
+
+
+ listLoadBalancerRuleInstances
+
+
+ resetPasswordForVirtualMachine
+
+
+ changeServiceForVirtualMachine
+
+
+ recoverVirtualMachine
+
+
+ startVirtualMachine
+
+
+ migrateVirtualMachine
+
+
+ deployVirtualMachine
+
+
+ assignVirtualMachine
+
+
+ updateVirtualMachine
+
+
+ restoreVirtualMachine
+
+
+ stopVirtualMachine
+
+
+ destroyVirtualMachine
+
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+
+
+
+
+ listSecurityGroups
+
+
+ listFirewallRules
+
+
+ listPortForwardingRules
+
+
+ listSnapshots
+
+
+ listIsos
+
+
+ listProjects
+
+
+ listTemplates
+
+
+ listLoadBalancerRules
+
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: tags (optional)
+
+
+ New response parameter: tags(*)
+
+
+
+
+
+
+
+
+ listF5LoadBalancerNetworks
+
+
+ listNetscalerLoadBalancerNetworks
+
+
+ listSrxFirewallNetworks
+
+
+ updateNetwork
+
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+
+
+
+
+ createZone
+
+
+ updateZone
+
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: localstorageenabled (optional)
+
+
+ New response parameter: localstorageenabled
+
+
+
+
+
+
+
+
+ listZones
+
+
+
+
+ New response parameter: localstorageenabled
+
+
+
+
+
+
+
+ rebootRouter
+
+
+ changeServiceForRouter
+
+
+ startRouter
+
+
+ destroyRouter
+
+
+ stopRouter
+
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+
+
+
+
+ updateAccount
+
+
+ disableAccount
+
+
+ listAccounts
+
+
+ markDefaultZoneForAccount
+
+
+ enableAccount
+
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: vpcavailable, vpclimit, vpctotal
+
+
+
+
+
+
+
+ listRouters
+
+
+
+
+ New request parameters: forvpc (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+
+
+
+
+
+ listNetworkOfferings
+
+
+
+
+ New request parameters: forvpc (optional)
+
+
+ New response parameters: forvpc
+
+
+
+
+
+
+
+
+ listVolumes
+
+
+
+
+ New request parameters: details (optional), tags (optional)
+
+
+ New response parameters: tags(*)
+
+
+
+
+
+
+
+
+ addTrafficMonitor
+
+
+
+
+ New request parameters: excludezones (optional), includezones (optional)
+
+
+
+
+
+
+
+
+ createNetwork
+
+
+
+
+ New request parameters: vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+
+
+
+
+ listPublicIpAddresses
+
+
+
+
+ New request parameters: tags (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+
+
+
+
+ listNetworks
+
+
+
+
+ New request parameters: canusefordeploy (optional), forvpc (optional), tags (optional), vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+
+
+
+
+ restartNetwork
+
+
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+
+
+
+
+ enableStaticNat
+
+
+
+
+ New request parameter: networkid (optional)
+
+
+
+
+
+
+
+
+ createDiskOffering
+
+
+
+
+ New request parameter: storagetype (optional)
+
+
+ New response parameter: storagetype
+
+
+
+
+
+
+
+
+ listDiskOfferings
+
+
+
+
+ New response parameter: storagetype
+
+
+
+
+
+
+
+
+ updateDiskOffering
+
+
+
+
+ New response parameter: storagetype
+
+
+
+
+
+
+
+
+ createFirewallRule
+
+
+
+
+ Changed request parameters: ipaddressid (old version - optional, new version - required)
+
+
+ New response parameter: tags(*)
+
+
+
+
+
+
+
+
+ listVirtualMachines
+
+
+
+
+ New request parameters: isoid (optional), tags (optional), templateid (optional)
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+
+
+
+
+ updateStorageNetworkIpRange
+
+
+
+
+ New response parameters: id, endip, gateway, netmask, networkid, podid, startip, vlan, zoneid
+
+
+
+
+
+
+
+
+ reconnectHost
+
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+
+
+
+
+ addCluster
+
+
+
+
+ The following request parameters are added:
+
+
+
+
+ vsmipaddress (optional)
+
+
+
+
+
+ vsmpassword (optional)
+
+
+
+
+
+ vsmusername (optional)
+
+
+
+
+
+
+ The following parameter is made mandatory: podid
+
+
+
+
+
+
+
+
+ listVolumes
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ migrateVolume
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ prepareHostForMaintenance
+
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+
+
+
+
+ addSecondaryStorage
+
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+
+
+
+
+ enableAccount
+
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+
+
+
+
+ attachVolume
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ cancelHostMaintenance
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ addSwift
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ listSwifts
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ listExternalLoadBalancers
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ createVolume
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ listCapabilities
+
+
+
+
+ A new response parameter is added: customdiskofferingmaxsize
+
+
+
+
+
+
+
+ disableAccount
+
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+
+
+
+
+ deployVirtualMachine
+
+
+
+
+ A new request parameter is added: startvm (optional)
+
+
+
+
+
+
+
+ deleteStoragePool
+
+
+
+
+ A new request parameter is added: forced (optional)
+
+
+
+
+
+
+
+ updateAccount
+
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+
+
+
+
+ addHost
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ updateHost
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ detachVolume
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ listAccounts
+
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+
+
+
+
+ listHosts
+
+
+
+
+ A new response parameter is added: hahost
+
+
+ A new request parameter is added: hahost (optional)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Revision_History.xml b/docs/tmp/en-US/xml/Revision_History.xml
new file mode 100644
index 00000000000..864e2ca772a
--- /dev/null
+++ b/docs/tmp/en-US/xml/Revision_History.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Revision History
+
+
+
+ 0-0
+ Tue May 29 2012
+
+ Jessica
+ Tomechak
+
+
+
+
+
+ Initial creation of book by publican
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/Revision_History_Install_Guide.xml b/docs/tmp/en-US/xml/Revision_History_Install_Guide.xml
new file mode 100644
index 00000000000..5f610a509e3
--- /dev/null
+++ b/docs/tmp/en-US/xml/Revision_History_Install_Guide.xml
@@ -0,0 +1,61 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Revision History
+
+
+
+ 1-0
+ October 5 2012
+
+ Jessica
+ Tomechak
+
+
+
+
+ Radhika
+ PC
+
+
+
+
+ Wido
+ den Hollander
+
+
+
+
+
+ Initial publication
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/SSL-keystore-path-and-password.xml b/docs/tmp/en-US/xml/SSL-keystore-path-and-password.xml
new file mode 100644
index 00000000000..05a50ed073f
--- /dev/null
+++ b/docs/tmp/en-US/xml/SSL-keystore-path-and-password.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/VPN-user-usage-record-format.xml b/docs/tmp/en-US/xml/VPN-user-usage-record-format.xml
new file mode 100644
index 00000000000..d356866834d
--- /dev/null
+++ b/docs/tmp/en-US/xml/VPN-user-usage-record-format.xml
@@ -0,0 +1,84 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ VPN User Usage Record Format
+
+
+
+ account – name of the account
+
+
+
+
+ accountid – ID of the account
+
+
+
+
+ domainid – ID of the domain in which this account resides
+
+
+
+
+ zoneid – Zone where the usage occurred
+
+
+
+
+ description – A string describing what the usage record is tracking
+
+
+
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+
+
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+
+
+
+ rawusage – A number representing the actual usage in hours
+
+
+
+
+ usageid – VPN user ID
+
+
+
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+
+
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-clusters.xml b/docs/tmp/en-US/xml/about-clusters.xml
new file mode 100644
index 00000000000..0ea432735a7
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-clusters.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Clusters
+
+ A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set of KVM servers, , or a VMware cluster preconfigured in vCenter. The hosts in a cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the same shared primary storage. Virtual machine instances (VMs) can be live-migrated from one host to another within the same cluster, without interrupting service to the user.
+
+
+ A cluster is the third-largest organizational unit within a &PRODUCT; deployment. Clusters are contained within pods, and pods are contained within zones. Size of the cluster is limited by the underlying hypervisor, although the &PRODUCT; recommends less in most cases; see Best Practices.
+
+
+ A cluster consists of one or more hosts and one or more primary storage servers.
+
+
+
+
+
+
+ cluster-overview.png: Structure of a simple cluster
+
+
+
+
+ &PRODUCT; allows multiple clusters in a cloud deployment.
+
+
+ Even when local storage is used exclusively, clusters are still required organizationally, even if there is just one host per cluster.
+
+
+ When VMware is used, every VMware cluster is managed by a vCenter server. Administrator must register the vCenter server with &PRODUCT;. There may be multiple vCenter servers per zone. Each vCenter server may manage multiple VMware clusters.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-hosts.xml b/docs/tmp/en-US/xml/about-hosts.xml
new file mode 100644
index 00000000000..395efbbb1c5
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-hosts.xml
@@ -0,0 +1,88 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Hosts
+
+ A host is a single computer. Hosts provide the computing resources that run the guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a Linux KVM-enabled server, a Citrix XenServer server, and an ESXi server are hosts.
+
+
+ The host is the smallest organizational unit within a &PRODUCT; deployment. Hosts are contained within clusters, clusters are contained within pods, and pods are contained within zones.
+
+
+ Hosts in a &PRODUCT; deployment:
+
+
+
+
+ Provide the CPU, memory, storage, and networking resources needed to host the virtual machines
+
+
+
+
+ Interconnect using a high bandwidth TCP/IP network and connect to the Internet
+
+
+
+
+ May reside in multiple data centers across different geographic locations
+
+
+
+
+ May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the hosts within a cluster must all be homogeneous
+
+
+
+
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs.
+
+
+ &PRODUCT; automatically detects the amount of CPU and memory resources provided by the Hosts.
+
+
+ Hosts are not visible to the end user. An end user cannot determine which host their guest has been assigned to.
+
+
+ For a host to function in &PRODUCT;, you must do the following:
+
+
+
+
+ Install hypervisor software on the host
+
+
+
+
+ Assign an IP address to the host
+
+
+
+
+ Ensure the host is connected to the &PRODUCT; Management Server
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-physical-networks.xml b/docs/tmp/en-US/xml/about-physical-networks.xml
new file mode 100644
index 00000000000..5a0cccbd742
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-physical-networks.xml
@@ -0,0 +1,72 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Physical Networks
+
+ Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical networks can be associated with each zone. The network corresponds to a NIC on the hypervisor host. Each physical network can carry one or more types of network traffic. The choices of traffic type for each network vary depending on whether you are creating a zone with basic networking or advanced networking.
+
+
+ A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can:
+
+
+
+
+ Add/Remove/Update physical networks in a zone
+
+
+
+
+ Configure VLANs on the physical network
+
+
+
+
+ Configure a name so the network can be recognized by hypervisors
+
+
+
+
+ Configure the service providers (firewalls, load balancers, etc.) available on a physical network
+
+
+
+
+ Configure the IP addresses trunked to a physical network
+
+
+
+
+ Specify what type of traffic is carried on the physical network, as well as other properties like network speed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-pods.xml b/docs/tmp/en-US/xml/about-pods.xml
new file mode 100644
index 00000000000..5c169ec6c46
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-pods.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Pods
+
+ A pod often represents a single rack. Hosts in the same pod are in the same subnet.
+
+
+ A pod is the second-largest organizational unit within a &PRODUCT; deployment. Pods are contained within zones. Each zone can contain one or more pods.
+
+
+ Pods are not visible to the end user.
+
+
+ A pod consists of one or more clusters of hosts and one or more primary storage servers.
+
+
+
+
+
+
+ pod-overview.png: Nested structure of a simple pod
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-primary-storage.xml b/docs/tmp/en-US/xml/about-primary-storage.xml
new file mode 100644
index 00000000000..350093a9606
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-primary-storage.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Primary Storage
+
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required. It is typically located close to the hosts for increased performance.
+
+
+ &PRODUCT; is designed to work with all standards-compliant iSCSI and NFS servers that are supported by the underlying hypervisor, including, for example:
+
+
+
+
+ Dell EqualLogic™ for iSCSI
+
+
+
+
+ Network Appliances filers for NFS and iSCSI
+
+
+
+
+ Scale Computing for NFS
+
+
+
+
+
+ If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-secondary-storage.xml b/docs/tmp/en-US/xml/about-secondary-storage.xml
new file mode 100644
index 00000000000..9acb4f49642
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-secondary-storage.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Secondary Storage
+
+ Secondary storage is associated with a zone, and it stores the following:
+
+
+
+
+ Templates — OS images that can be used to boot VMs and can include additional configuration information, such as installed applications
+
+
+
+
+ ISO images — disc images containing data or bootable media for operating systems
+
+
+
+
+ Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
+
+
+
+
+
+ The items in zone-based NFS secondary storage are available to all hosts in the zone. &PRODUCT; manages the allocation of guest virtual disks to particular primary storage devices.
+
+
+ To make items in secondary storage available to all hosts throughout the cloud, you can add OpenStack Object Storage (Swift, swift.openstack.org) in addition to the zone-based NFS secondary storage. When using Swift, you configure Swift storage for the entire &PRODUCT;, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-security-groups.xml b/docs/tmp/en-US/xml/about-security-groups.xml
new file mode 100644
index 00000000000..906d8f81066
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-security-groups.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Security Groups
+
+ Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In &PRODUCT; 3.0.3 - 3.0.5, security groups are supported only in zones that use basic networking.
+
+
+
+ In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
+
+
+
+
+
+
+ Each &PRODUCT; account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.
+
+
+ Any &PRODUCT; user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.
+
+
+ You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.
+
+
+ If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-virtual-networks.xml b/docs/tmp/en-US/xml/about-virtual-networks.xml
new file mode 100644
index 00000000000..95de9f7b48a
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-virtual-networks.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Virtual Networks
+
+ A virtual network is a logical construct that enables multi-tenancy on a single physical network. In &PRODUCT; a virtual network can be shared or isolated.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-working-with-vms.xml b/docs/tmp/en-US/xml/about-working-with-vms.xml
new file mode 100644
index 00000000000..4ee25325e39
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-working-with-vms.xml
@@ -0,0 +1,62 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Working with Virtual Machines
+
+ &PRODUCT; provides administrators with complete control over the lifecycle of all guest VMs executing in the cloud. &PRODUCT; provides several guest management operations for end users and administrators. VMs may be stopped, started, rebooted, and destroyed.
+
+
+ Guest VMs have a name and group. VM names and groups are opaque to &PRODUCT; and are available for end users to organize their VMs. Each VM can have three names for use in different contexts. Only two of these names can be controlled by the user:
+
+
+
+
+ Instance name – a unique, immutable ID that is generated by &PRODUCT; and can not be modified by the user. This name conforms to the requirements in IETF RFC 1123.
+
+
+
+
+ Display name – the name displayed in the &PRODUCT; web UI. Can be set by the user. Defaults to instance name.
+
+
+
+
+ Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to instance name
+
+
+
+
+
+ Guest VMs can be configured to be Highly Available (HA). An HA-enabled VM is monitored by the system. If the system detects that the VM is down, it will attempt to restart the VM, possibly on a different host. For more information, see HA-Enabled Virtual Machines on
+
+
+ Each new VM is allocated one public IP address. When the VM is started, &PRODUCT; automatically creates a static NAT between this public IP address and the private IP address of the VM.
+
+
+ If elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new VM is not marked as elastic. The user must replace the automatically configured IP with a specifically acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s private IP. The VM’s original IP address is then released and returned to the pool of available public IPs.
+
+
+ &PRODUCT; cannot distinguish a guest VM that was shut down by the user (such as with the “shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut down from inside the VM, &PRODUCT; will restart it. To shut down an HA-enabled VM, you must go through the &PRODUCT; UI or API.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/about-zones.xml b/docs/tmp/en-US/xml/about-zones.xml
new file mode 100644
index 00000000000..74489ccbc3c
--- /dev/null
+++ b/docs/tmp/en-US/xml/about-zones.xml
@@ -0,0 +1,97 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Zones
+
+ A zone is the largest organizational unit within a &PRODUCT; deployment. A zone typically corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter. The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required).
+
+
+ A zone consists of:
+
+
+
+
+ One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
+
+
+
+
+ Secondary storage, which is shared by all the pods in the zone.
+
+
+
+
+
+
+
+
+
+ zone-overview.png: Nested structure of a simple zone
+
+
+
+
+ Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones.
+
+
+ Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone.
+
+
+ Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels.
+
+
+ For each zone, the administrator must decide the following.
+
+
+
+
+ How many pods to place in a zone.
+
+
+
+
+ How many clusters to place in each pod.
+
+
+
+
+ How many hosts to place in each cluster.
+
+
+
+
+ How many primary storage servers to place in each cluster and total capacity for the storage servers.
+
+
+
+
+ How much secondary storage to deploy in 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/accept-membership-invite.xml b/docs/tmp/en-US/xml/accept-membership-invite.xml
new file mode 100644
index 00000000000..853191025e5
--- /dev/null
+++ b/docs/tmp/en-US/xml/accept-membership-invite.xml
@@ -0,0 +1,61 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Accepting a Membership Invitation
+
+ If you have received an invitation to join a &PRODUCT; project, and you want to accept the invitation, follow these steps:
+
+
+
+
+ Log in to the &PRODUCT; 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 &PRODUCT; 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.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/accessing-vms.xml b/docs/tmp/en-US/xml/accessing-vms.xml
new file mode 100644
index 00000000000..5f1597cd11f
--- /dev/null
+++ b/docs/tmp/en-US/xml/accessing-vms.xml
@@ -0,0 +1,71 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Accessing VMs
+
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
+
+ To access a VM through the &PRODUCT; UI:
+
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+ Click Instances, then click the name of a running VM.
+
+
+
+
+ Click the View Console button .
+
+
+
+
+
+ To access a VM directly over the network:
+
+
+
+
+ The VM must have some port open to incoming traffic. For example, in a basic zone, a new VM might be assigned to a security group which allows incoming traffic. This depends on what security group you picked when creating the VM. In other cases, you can open a port by setting up a port forwarding policy. See IP Forwarding and Firewalling.
+
+
+
+
+ If a port is open but you can not access the VM using ssh, it’s possible that ssh is not already enabled on the VM. This will depend on whether ssh is enabled in the template you picked when creating the VM. Access the VM through the &PRODUCT; UI and enable ssh on the machine using the commands for the VM’s operating system.
+
+
+
+
+ If the network has an external firewall device, you will need to create a firewall rule to allow access. See IP Forwarding and Firewalling.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/accounts-users-domains.xml b/docs/tmp/en-US/xml/accounts-users-domains.xml
new file mode 100644
index 00000000000..df4f9a3f13f
--- /dev/null
+++ b/docs/tmp/en-US/xml/accounts-users-domains.xml
@@ -0,0 +1,73 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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
+
+
+
+
+ The 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/accounts.xml b/docs/tmp/en-US/xml/accounts.xml
new file mode 100644
index 00000000000..8c9a5910ac2
--- /dev/null
+++ b/docs/tmp/en-US/xml/accounts.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Accounts
+
+
+
+
diff --git a/docs/tmp/en-US/xml/acquire-new-ip-address.xml b/docs/tmp/en-US/xml/acquire-new-ip-address.xml
new file mode 100644
index 00000000000..6d3b24fa42a
--- /dev/null
+++ b/docs/tmp/en-US/xml/acquire-new-ip-address.xml
@@ -0,0 +1,58 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Acquiring a New IP Address
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+ Click the name of the network where you want to work with.
+
+
+
+
+ Click View IP Addresses.
+
+
+
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/acquire-new-ip-for-vpc.xml b/docs/tmp/en-US/xml/acquire-new-ip-for-vpc.xml
new file mode 100644
index 00000000000..0a7d7f16aac
--- /dev/null
+++ b/docs/tmp/en-US/xml/acquire-new-ip-for-vpc.xml
@@ -0,0 +1,114 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Acquiring a New IP Address for a VPC
+
+ When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks within the VPC. The IPs are associated to the guest network only when the first port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP can't be associated to more than one network at a time.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ACLs
+
+
+
+
+
+
+
+
+
+ Select IP Addresses.
+
+
+ The IP Addresses page is displayed.
+
+
+
+
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+
+
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding, load balancing, and static NAT rules.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-additional-guest-network.xml b/docs/tmp/en-US/xml/add-additional-guest-network.xml
new file mode 100644
index 00000000000..ac8ad6222ed
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-additional-guest-network.xml
@@ -0,0 +1,90 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding an Additional Guest Network
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ Click Add guest network. Provide the following information:
+
+
+
+
+ Name: The name of the network. This will be user-visible.
+
+
+
+
+
+ Display Text: The description of the network. This will be user-visible.
+
+
+
+
+
+ Zone. The name of the zone this network applies to. Each zone is a broadcast domain, and therefore each zone has a different IP range for the guest network. The administrator must configure the IP range for each zone.
+
+
+
+
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network.
+
+
+
+
+
+ Guest Gateway: The gateway that the guests should use.
+
+
+
+
+
+ Guest Netmask: The netmask in use on the subnet the guests will use.
+
+
+
+
+
+
+
+
+
+ Click Create.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-clusters-kvm-xenserver.xml b/docs/tmp/en-US/xml/add-clusters-kvm-xenserver.xml
new file mode 100644
index 00000000000..77a096052be
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-clusters-kvm-xenserver.xml
@@ -0,0 +1,78 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Add Cluster: KVM or XenServer
+
+ These steps assume you have already installed the hypervisor on the hosts and logged in to the &PRODUCT; 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 &PRODUCT;.
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-clusters-ovm.xml b/docs/tmp/en-US/xml/add-clusters-ovm.xml
new file mode 100644
index 00000000000..c5f9d28da88
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-clusters-ovm.xml
@@ -0,0 +1,84 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Add Cluster: OVM
+
+ To add a Cluster of hosts that run Oracle VM (OVM):
+
+
+
+
+ Add a companion non-OVM cluster to the Pod. This cluster provides an environment where the CloudPlatform System VMs can run. You should have already installed a non-OVM hypervisor on at least one Host to prepare for this step. Depending on which hypervisor you used:
+
+
+
+
+ For VMWare, follow the steps in Add Cluster: vSphere. When finished, return here and continue with the next step.
+
+
+
+
+ For KVM or XenServer, follow the steps in . When finished, return here and continue with the next step
+
+
+
+
+
+
+
+
+ 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 Pods node, click View All. Select the same pod you used in step 1.
+
+
+
+
+ Click View Clusters, then click Add Cluster.
+
+
+ The Add Cluster dialog is displayed.
+
+
+
+
+ In Hypervisor, choose OVM.
+
+
+
+
+ In Cluster, enter a name for the cluster.
+
+
+
+
+ Click Add.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-clusters-vsphere.xml b/docs/tmp/en-US/xml/add-clusters-vsphere.xml
new file mode 100644
index 00000000000..fea79fa0cb5
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-clusters-vsphere.xml
@@ -0,0 +1,156 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Add Cluster: vSphere
+
+ Host management for vSphere is done through a combination of vCenter and the &PRODUCT; admin UI. &PRODUCT; requires that all hosts be in a &PRODUCT; 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 &PRODUCT;. 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 &PRODUCT;.
+
+
+
+
+
+
+ To add a vSphere cluster to &PRODUCT;:
+
+
+
+
+ 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 values from vCenter.
+
+
+
+
+ Cluster Name. Enter the name of the cluster you created in vCenter. For example, "cloud.cluster.2.2.1"
+
+
+
+
+
+ vCenter Host. Enter the hostname or IP address of the vCenter server.
+
+
+
+
+
+ vCenter Username. Enter the username that &PRODUCT; should use to connect to vCenter. This user must have all administrative privileges.
+
+
+
+
+
+ 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".
+
+
+
+
+
+
+
+
+
+ addcluster.png: add cluster
+
+
+
+
+ There might be a slight delay while the cluster is provisioned. It will automatically display in the UI
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-gateway-vpc.xml b/docs/tmp/en-US/xml/add-gateway-vpc.xml
new file mode 100644
index 00000000000..4db83a4025c
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-gateway-vpc.xml
@@ -0,0 +1,162 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Private Gateway to a VPC
+
+ A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. No gateways with duplicated VLAN and IP are allowed in the same data center.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Private Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ACLs
+
+
+
+
+
+
+
+
+
+ Select Private Gateways.
+
+
+ The Gateways page is displayed.
+
+
+
+
+
+ Click Add new gateway:
+
+
+
+
+
+
+ add-new-gateway-vpc.png: adding a private gateway for the VPC.
+
+
+
+
+
+
+
+ Specify the following:
+
+
+
+
+ Physical Network: The physical network you have created in the zone.
+
+
+
+
+
+ IP Address: The IP address associated with the VPC gateway.
+
+
+
+
+
+ Gateway: The gateway through which the traffic is routed to and from the VPC.
+
+
+
+
+
+ Netmask: The netmask associated with the VPC gateway.
+
+
+
+
+
+ VLAN: The VLAN associated with the VPC gateway.
+
+
+
+
+
+
+ The new gateway appears in the list. You can repeat these steps to add more gateway for this VPC.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-ingress-egress-rules.xml b/docs/tmp/en-US/xml/add-ingress-egress-rules.xml
new file mode 100644
index 00000000000..ccba869d102
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-ingress-egress-rules.xml
@@ -0,0 +1,153 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding Ingress and Egress Rules to a Security Group
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network
+
+
+
+
+
+ In Select view, choose Security Groups, then click the security group you want .
+
+
+
+
+
+ To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify what network traffic is allowed into VM instances in this security group. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
+
+
+
+ Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address (CIDR) or an existing security group in a &PRODUCT; account (Account). Choose Account if you want to allow incoming traffic from all VMs in another security group
+
+
+
+
+
+ Protocol. The networking protocol that sources will use to send traffic to the security group. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+
+
+
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+
+
+
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be accepted.
+
+
+
+
+
+ CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+
+
+
+
+ Account, Security Group. (Add by Account only) To accept only traffic from another security group, enter the &PRODUCT; account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter the same name you used in step 7.
+
+
+
+
+
+
+ The following example allows inbound HTTP access from anywhere:
+
+
+
+
+
+
+ httpaccess.png: allows inbound HTTP access from anywhere
+
+
+
+
+
+
+
+ To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules are specified, then all traffic will be allowed out. Once egress rules are specified, the following types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been allowed in through an ingress rule
+
+
+
+
+ Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP address (CIDR) or an existing security group in a &PRODUCT; account (Account). Choose Account if you want to allow outgoing traffic to all VMs in another security group.
+
+
+
+
+
+ Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user communications. ICMP is typically used to send error messages or network monitoring data.
+
+
+
+
+
+ Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for the outgoing traffic. If you are opening a single port, use the same number in both fields.
+
+
+
+
+
+ ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
+
+
+
+
+
+ CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+
+
+
+
+ Account, Security Group. (Add by Account only) To allow traffic to be sent to another security group, enter the &PRODUCT; account and name of a security group that has already been defined in that account. To allow traffic between VMs within the security group you are editing now, enter its name.
+
+
+
+
+
+
+
+
+
+ Click Add.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-iso.xml b/docs/tmp/en-US/xml/add-iso.xml
new file mode 100644
index 00000000000..a1ca2faee27
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-iso.xml
@@ -0,0 +1,261 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding an ISO
+
+ To make additional operating system or other software available for use with guest VMs, you can add an ISO. The ISO is typically thought of as an operating system image, but you can also add ISOs for other types of software, such as desktop applications that you want to be installed as part of a template.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation bar, click Templates.
+
+
+
+
+
+ In Select View, choose ISOs.
+
+
+
+
+
+ Click Add ISO.
+
+
+
+
+
+ In the Add ISO screen, provide the following:
+
+
+
+
+ Name: Short name for the ISO image. For example, CentOS 6.2 64-bit.
+
+
+
+
+
+ Description: Display test for the ISO image. For example, CentOS 6.2 64-bit.
+
+
+
+
+
+ URL: The URL that hosts the ISO image. The Management Server must be able to access this location via HTTP. If needed you can place the ISO image directly on the Management Server
+
+
+
+
+
+ Zone: Choose the zone where you want the ISO to be available, or All Zones to make it available throughout &PRODUCT;.
+
+
+
+
+
+ Bootable: Whether or not a guest could boot off this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not bootable.
+
+
+
+
+
+ OS Type: This helps &PRODUCT; and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+
+
+
+ If the operating system of your desired ISO image is listed, choose it.
+
+
+
+
+
+ If the OS Type of the ISO is not listed or if the ISO is not bootable, choose Other.
+
+
+
+
+
+ (XenServer only) If you want to boot from this ISO in PV mode, choose Other PV (32-bit) or Other PV (64-bit)
+
+
+
+
+
+ (KVM only) If you choose an OS that is PV-enabled, the VMs created from this ISO will have a SCSI (virtio) root disk. If the OS is not PV-enabled, the VMs will have an IDE root disk. The PV-enabled types are:
+
+
+
+
+
+
+
+ Fedora 13
+
+
+
+
+ Fedora 12
+
+
+
+
+ Fedora 11
+
+
+
+
+
+
+
+ Fedora 10
+
+
+
+
+ Fedora 9
+
+
+
+
+ Other PV
+
+
+
+
+
+
+
+ Debian GNU/Linux
+
+
+
+
+ CentOS 5.3
+
+
+
+
+ CentOS 5.4
+
+
+
+
+
+
+
+ CentOS 5.5
+
+
+
+
+ Red Hat Enterprise Linux 5.3
+
+
+
+
+ Red Hat Enterprise Linux 5.4
+
+
+
+
+
+
+
+ Red Hat Enterprise Linux 5.5
+
+
+
+
+ Red Hat Enterprise Linux 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ It is not recommended to choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not work. In these cases, choose Other.
+
+
+
+
+
+
+
+ Extractable: Choose Yes if the ISO should be available for extraction.
+
+
+
+
+
+ Public: Choose Yes if this ISO should be available to other users.
+
+
+
+
+
+ Featured: Choose Yes if you would like this ISO to be more prominent for users to select. The ISO will appear in the Featured ISOs list. Only an administrator can make an ISO Featured.
+
+
+
+
+
+
+
+
+
+ Click OK.
+
+
+ The Management Server will download the ISO. Depending on the size of the ISO, this may take a long time. The ISO status column will display Ready once it has been successfully downloaded into secondary storage. Clicking Refresh updates the download percentage.
+
+
+
+
+
+ Important: Wait for the ISO to finish downloading. If you move on to the next task and try to use the ISO right away, it will appear to fail. The entire ISO must be available before &PRODUCT; can work with it.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-load-balancer-rule.xml b/docs/tmp/en-US/xml/add-load-balancer-rule.xml
new file mode 100644
index 00000000000..9d2f1e1b374
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-load-balancer-rule.xml
@@ -0,0 +1,117 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Load Balancer Rule
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ Click the name of the network where you want to load balance the traffic.
+
+
+
+
+
+ Click View IP Addresses.
+
+
+
+
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+
+
+
+
+ In the Load Balancing node of the diagram, click View All.
+
+
+ In a Basic zone, you can also create a load balancing rule without acquiring or selecting an IP address. &PRODUCT; internally assign an IP when you create the load balancing rule, which is listed in the IP Addresses page when the rule is created.
+
+
+ To do that, select the name of the network, then click Add Load Balancer tab. Continue with .
+
+
+
+
+
+ Fill in the following:
+
+
+
+
+ Name: A name for the load balancer rule.
+
+
+
+
+
+ Public Port: The port receiving incoming traffic to be balanced.
+
+
+
+
+
+ Private Port: The port that the VMs will use to receive the traffic.
+
+
+
+
+
+ Algorithm: Choose the load balancing algorithm you want &PRODUCT; to use. &PRODUCT; supports a variety of well-known algorithms. If you are not familiar with these choices, you will find plenty of information about them on the Internet.
+
+
+
+
+
+ Stickiness: (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
+
+
+
+
+
+
+
+
+
+ Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.
+
+
+ The new load balancer rule appears in the list. You can repeat these steps to add more load balancer rules for this IP address.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-loadbalancer-rule-vpc.xml b/docs/tmp/en-US/xml/add-loadbalancer-rule-vpc.xml
new file mode 100644
index 00000000000..0f1015c67c5
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-loadbalancer-rule-vpc.xml
@@ -0,0 +1,198 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding Load Balancing Rules on a VPC
+
+ A &PRODUCT; user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a VPC.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC to which you want to configure load balancing rules.
+
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ACLs
+
+
+
+
+
+
+
+
+
+ Select IP Addresses.
+
+
+ The IP Addresses page is displayed.
+
+
+
+
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+
+
+
+
+ In the Load Balancing node of the diagram, click View All.
+
+
+
+
+
+ Select the tier to which you want to apply the rule.
+
+
+
+ In a VPC, the load balancing service is supported only on a single tier.
+
+
+
+
+
+
+
+ Specify the following:
+
+
+
+
+ Name: A name for the load balancer rule.
+
+
+
+
+
+ Public Port: The port that receives the incoming traffic to be balanced.
+
+
+
+
+
+ Private Port: The port that the VMs will use to receive the traffic.
+
+
+
+
+
+ Algorithm. Choose the load balancing algorithm you want &PRODUCT; to use. &PRODUCT; supports the following well-known algorithms:
+
+
+
+
+ Round-robin
+
+
+
+
+
+ Least connections
+
+
+
+
+
+ Source
+
+
+
+
+
+
+
+
+
+ Stickiness. (Optional) Click Configure and choose the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer Rules.
+
+
+
+
+
+ Add VMs: Click Add VMs, then select two or more VMs that will divide the load of incoming traffic, and click Apply.
+
+
+
+
+
+
+
+
+
+
+ The new load balancing rule appears in the list. You can repeat these steps to add more load balancing rules for this IP address.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-members-to-projects.xml b/docs/tmp/en-US/xml/add-members-to-projects.xml
new file mode 100644
index 00000000000..ebda1e13424
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-members-to-projects.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; root administrator. There are two ways to add members in &PRODUCT;, 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.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-more-clusters.xml b/docs/tmp/en-US/xml/add-more-clusters.xml
new file mode 100644
index 00000000000..b77e6c860b2
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-more-clusters.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Add More Clusters (Optional)
+
+ You need to tell &PRODUCT; 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.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-password-management-to-templates.xml b/docs/tmp/en-US/xml/add-password-management-to-templates.xml
new file mode 100644
index 00000000000..a7a527b16ec
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-password-management-to-templates.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding Password Management to Your Templates
+
+ &PRODUCT; provides an optional password reset feature that allows users to set a temporary admin or root password as well as reset the existing admin or root password from the &PRODUCT; UI.
+
+
+ To enable the Reset Password feature, you will need to download an additional script to patch your template. When you later upload the template into &PRODUCT;, you can specify whether reset admin/root password feature should be enabled for this template.
+
+
+ The password management feature works always resets the account password on instance boot. The script does an HTTP call to the virtual router to retrieve the account password that should be set. As long as the virtual router is accessible the guest will have access to the account password that should be used. When the user requests a password reset the management server generates and sends a new password to the virtual router for the account. Thus an instance reboot is necessary to effect any password changes.
+
+
+ If the script is unable to contact the virtual router during instance boot it will not set the password but boot will continue normally.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-portforward-rule-vpc.xml b/docs/tmp/en-US/xml/add-portforward-rule-vpc.xml
new file mode 100644
index 00000000000..a44a17f05bf
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-portforward-rule-vpc.xml
@@ -0,0 +1,171 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Port Forwarding Rule on a VPC
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ACLs
+
+
+
+
+
+
+
+
+
+ Choose an existing IP address or acquire a new IP address. Click the name of the IP address in the list.
+
+
+ The IP Addresses page is displayed.
+
+
+
+
+
+ Click the IP address for which you want to create the rule, then click the Configuration tab.
+
+
+
+
+
+ In the Port Forwarding node of the diagram, click View All.
+
+
+
+
+
+ Select the tier to which you want to apply the rule.
+
+
+
+
+
+ Specify the following:
+
+
+
+
+ Public Port: The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+
+
+
+
+
+ Private Port: The port on which the instance is listening for forwarded public traffic.
+
+
+
+
+
+ Protocol: The communication protocol in use between the two ports.
+
+
+
+
+ TCP
+
+
+
+
+
+ UDP
+
+
+
+
+
+
+
+
+
+ Add VM: Click Add VM. Select the name of the instance to which this rule applies, and click Apply.
+
+
+ You can test the rule by opening an ssh session to the instance.
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-primary-storage.xml b/docs/tmp/en-US/xml/add-primary-storage.xml
new file mode 100644
index 00000000000..ffbb866f3a0
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-primary-storage.xml
@@ -0,0 +1,162 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding Primary Storage
+
+
+ Ensure that nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+
+
+
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+
+
+
+
+ Log in to the &PRODUCT; UI.
+
+
+
+
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+
+
+
+
+
+ Click the Compute tab.
+
+
+
+
+
+ In the Primary Storage node of the diagram, click View All.
+
+
+
+
+
+ Click Add Primary Storage.
+
+
+
+
+
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+
+
+
+
+ Pod. The pod for the storage device.
+
+
+
+
+
+ Cluster. The cluster for the storage device.
+
+
+
+
+
+ Name. The name of the storage device
+
+
+
+
+
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS
+
+
+
+
+
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device
+
+
+
+
+
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+
+
+
+
+
+ Path (for NFS). In NFS this is the exported path from the server.
+
+
+
+
+
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+
+
+
+
+
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+
+
+
+
+
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside &PRODUCT;.
+
+
+
+
+
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984
+
+
+
+
+
+ Lun # (for iSCSI). In iSCSI this is 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.
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-projects-members-from-ui.xml b/docs/tmp/en-US/xml/add-projects-members-from-ui.xml
new file mode 100644
index 00000000000..e478dd3e308
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-projects-members-from-ui.xml
@@ -0,0 +1,63 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 , use the procedure in .
+
+
+
+
+ Log in to the &PRODUCT; 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.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-secondary-storage.xml b/docs/tmp/en-US/xml/add-secondary-storage.xml
new file mode 100644
index 00000000000..1e6196c2030
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-secondary-storage.xml
@@ -0,0 +1,60 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding Secondary Storage
+
+
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will destroy any existing data.
+
+
+
+
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+
+
+
+
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to &PRODUCT; before you add the local zone secondary storage servers.
+
+
+
+
+
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation.
+
+
+
+
+
+ Make sure you prepared the system VM template during Management Server installation.
+
+
+
+
+
+ 4. Now that the secondary storage server for per-zone storage is prepared, add it to &PRODUCT;. Secondary storage is added as part of the procedure for adding a new zone.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-security-group.xml b/docs/tmp/en-US/xml/add-security-group.xml
new file mode 100644
index 00000000000..057cbc56bf9
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-security-group.xml
@@ -0,0 +1,75 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Security Group
+
+ A user or administrator can define a new security group.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network
+
+
+
+
+
+ In Select view, choose Security Groups.
+
+
+
+
+
+ Click Add Security Group.
+
+
+
+
+
+ Provide a name and description.
+
+
+
+
+
+ Click OK.
+
+
+ The new security group appears in the Security Groups Details tab.
+
+
+
+
+
+ To make the security group useful, continue to Adding Ingress and Egress Rules to a Security Group.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-tier.xml b/docs/tmp/en-US/xml/add-tier.xml
new file mode 100644
index 00000000000..59944be00bb
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-tier.xml
@@ -0,0 +1,132 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding Tiers
+
+ Tiers are distinct locations within a VPC that act as isolated networks, which do not have access to other tiers by default. Tiers are set up on different VLANs that can communicate with each other by using a virtual router. Tiers provide inexpensive, low latency network connectivity to other tiers within the VPC.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPC that you have created for the account is listed in the page.
+
+
+
+ The end users can see their own VPCs, while root and domain admin can see any VPC they are authorized to see.
+
+
+
+
+
+
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+
+ The Add new tier dialog is displayed, as follows:
+
+
+
+
+
+
+ add-tier.png: adding a tier to a vpc.
+
+
+
+
+ If you have already created tiers, the VPC diagram is displayed. Click Create Tier to add a new tier.
+
+
+
+
+
+ Specify the following:
+
+
+ All the fields are mandatory.
+
+
+
+
+ Name: A unique name for the tier you create.
+
+
+
+
+
+ Network Offering: The following default network offerings are listed: DefaultIsolatedNetworkOfferingForVpcNetworksNoLB, DefaultIsolatedNetworkOfferingForVpcNetworks
+
+
+ In a VPC, only one tier can be created by using LB-enabled network offering.
+
+
+
+
+
+ Gateway: The gateway for the tier you create. Ensure that the gateway is within the Super CIDR range that you specified while creating the VPC, and is not overlapped with the CIDR of any existing tier within the VPC.
+
+
+
+
+
+ Netmask: The netmask for the tier you create.
+
+
+ For example, if the VPC CIDR is 10.0.0.0/16 and the network tier CIDR is 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the netmask of the tier is 255.255.255.0.
+
+
+
+
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+ Continue with configuring access control list for the tier.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-vm-to-tier.xml b/docs/tmp/en-US/xml/add-vm-to-tier.xml
new file mode 100644
index 00000000000..4cb29c3637d
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-vm-to-tier.xml
@@ -0,0 +1,69 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Deploying VMs to the Tier
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+
+ The VPC page is displayed where all the tiers you created are listed.
+
+
+
+
+
+ Click the Add VM button of the tier for which you want to add a VM.
+
+
+ The Add Instance page is displayed.
+
+
+ Follow the on-screen instruction to add an instance. For information on adding an instance, see Adding Instances section in the Installation Guide.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/add-vpc.xml b/docs/tmp/en-US/xml/add-vpc.xml
new file mode 100644
index 00000000000..19bef5629d7
--- /dev/null
+++ b/docs/tmp/en-US/xml/add-vpc.xml
@@ -0,0 +1,99 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Virtual Private Cloud
+
+ When creating the VPC, you simply provide the zone and a set of IP addresses for the VPC network address space. You specify this set of addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+
+
+
+ Click Add VPC. The Add VPC page is displayed as follows:
+
+
+
+
+
+
+ add-vpc.png: adding a vpc.
+
+
+
+
+ Provide the following information:
+
+
+
+
+ Name: A short name for the VPC that you are creating.
+
+
+
+
+
+ Description: A brief description of the VPC.
+
+
+
+
+
+ Zone: Choose the zone where you want the VPC to be available.
+
+
+
+
+
+ Super CIDR for Guest Networks: Defines the CIDR range for all the tiers (guest networks) within a VPC. When you create a tier, ensure that its CIDR is within the Super CIDR value you enter. The CIDR must be RFC1918 compliant.
+
+
+
+
+
+ DNS domain for Guest Networks: If you want to assign a special domain name, specify the DNS suffix. This parameter is applied to all the tiers within the VPC. That implies, all the tiers you create in the VPC belong to the same DNS domain. If the parameter is not specified, a DNS domain name is generated automatically.
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/added-API-commands-4.0.xml b/docs/tmp/en-US/xml/added-API-commands-4.0.xml
new file mode 100644
index 00000000000..a5096afdc01
--- /dev/null
+++ b/docs/tmp/en-US/xml/added-API-commands-4.0.xml
@@ -0,0 +1,290 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Added API Commands in 4.0.0-incubating
+
+
+
+ createCounter (Adds metric counter)
+
+
+
+
+
+ deleteCounter (Deletes a counter)
+
+
+
+
+
+ listCounters (List the counters)
+
+
+
+
+
+ createCondition (Creates a condition)
+
+
+
+
+
+ deleteCondition (Removes a condition)
+
+
+
+
+
+ listConditions (List Conditions for the specific user)
+
+
+
+
+
+ createTags. Add tags to one or more resources. Example:
+command=createTags
+&resourceIds=1,10,12
+&resourceType=userVm
+&tags[0].key=region
+&tags[0].value=canada
+&tags[1].key=city
+&tags[1].value=Toronto
+
+
+
+
+
+ deleteTags. Remove tags from one or more resources. Example:
+command=deleteTags
+&resourceIds=1,12
+&resourceType=Snapshot
+&tags[0].key=city
+
+
+
+
+
+ listTags (Show currently defined resource tags)
+
+
+
+
+
+ createVPC (Creates a VPC)
+
+
+
+
+
+ listVPCs (Lists VPCs)
+
+
+
+
+
+ deleteVPC (Deletes a VPC)
+
+
+
+
+
+ updateVPC (Updates a VPC)
+
+
+
+
+
+ restartVPC (Restarts a VPC)
+
+
+
+
+
+ createVPCOffering (Creates VPC offering)
+
+
+
+
+
+ updateVPCOffering (Updates VPC offering)
+
+
+
+
+
+ deleteVPCOffering (Deletes VPC offering)
+
+
+
+
+
+ listVPCOfferings (Lists VPC offerings)
+
+
+
+
+
+ createPrivateGateway (Creates a private gateway)
+
+
+
+
+
+ listPrivateGateways (List private gateways)
+
+
+
+
+
+ deletePrivateGateway (Deletes a Private gateway)
+
+
+
+
+
+ createNetworkACL (Creates a ACL rule the given network (the network has to belong to VPC))
+
+
+
+
+
+ deleteNetworkACL (Deletes a Network ACL)
+
+
+
+
+
+ listNetworkACLs (Lists all network ACLs)
+
+
+
+
+
+ createStaticRoute (Creates a static route)
+
+
+
+
+
+ deleteStaticRoute (Deletes a static route)
+
+
+
+
+
+ listStaticRoutes (Lists all static routes)
+
+
+
+
+
+ createVpnCustomerGateway (Creates site to site vpn customer gateway)
+
+
+
+
+
+ createVpnGateway (Creates site to site vpn local gateway)
+
+
+
+
+
+ createVpnConnection (Create site to site vpn connection)
+
+
+
+
+
+ deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
+
+
+
+
+
+ deleteVpnGateway (Delete site to site vpn gateway)
+
+
+
+
+
+ deleteVpnConnection (Delete site to site vpn connection)
+
+
+
+
+
+ updateVpnCustomerGateway (Update site to site vpn customer gateway)
+
+
+
+
+
+ resetVpnConnection (Reset site to site vpn connection)
+
+
+
+
+
+ listVpnCustomerGateways (Lists site to site vpn customer gateways)
+
+
+
+
+
+ listVpnGateways (Lists site 2 site vpn gateways)
+
+
+
+
+
+ listVpnConnections (Lists site to site vpn connection gateways)
+
+
+
+
+
+ enableCiscoNexusVSM (Enables Nexus 1000v dvSwitch in &PRODUCT;.)
+
+
+
+
+
+ disableCiscoNexusVSM (Disables Nexus 1000v dvSwitch in &PRODUCT;.)
+
+
+
+
+
+ deleteCiscoNexusVSM (Deletes Nexus 1000v dvSwitch in &PRODUCT;.)
+
+
+
+
+
+ listCiscoNexusVSMs (Lists the control VLAN ID, packet VLAN ID, and data VLAN ID, as well as the IP address of the Nexus 1000v dvSwitch.)
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/added-API-commands.xml b/docs/tmp/en-US/xml/added-API-commands.xml
new file mode 100644
index 00000000000..3a4666ad118
--- /dev/null
+++ b/docs/tmp/en-US/xml/added-API-commands.xml
@@ -0,0 +1,469 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Added API commands in 3.0
+
+ Added in 3.0.2
+
+
+
+ changeServiceForSystemVm
+
+
+ Changes the service offering for a system VM (console proxy or secondary storage). The system VM must be in a "Stopped" state for this command to take effect.
+
+
+
+
+
+
+
+
+
+ Added in 3.0.1
+
+
+
+ changeServiceForSystemVm
+
+
+ Changes the service offering for a system VM (console proxy or secondary storage). The system VM must be in a "Stopped" state for this command to take effect.
+
+
+
+
+
+
+
+
+
+ Added in 3.0.0
+
+
+
+
+
+
+
+
+
+ assignVirtualMachine (Move a user VM to another user under same domain.)
+
+
+
+
+ restoreVirtualMachine (Restore a VM to original template or specific snapshot)
+
+
+
+
+ createLBStickinessPolicy (Creates a Load Balancer stickiness policy )
+
+
+
+
+
+
+
+ deleteLBStickinessPolicy (Deletes a LB stickiness policy.)
+
+
+
+
+ listLBStickinessPolicies (Lists LBStickiness policies.)
+
+
+
+
+ ldapConfig (Configure the LDAP context for this site.)
+
+
+
+
+
+
+
+ addSwift (Adds Swift.)
+
+
+
+
+ listSwifts (List Swift.)
+
+
+
+
+ migrateVolume (Migrate volume)
+
+
+
+
+
+
+
+ updateStoragePool (Updates a storage pool.)
+
+
+
+
+ authorizeSecurityGroupEgress (Authorizes a particular egress rule for this security group)
+
+
+
+
+ revokeSecurityGroupEgress (Deletes a particular egress rule from this security group)
+
+
+
+
+
+
+
+ createNetworkOffering (Creates a network offering.)
+
+
+
+
+ deleteNetworkOffering (Deletes a network offering.)
+
+
+
+
+ createProject (Creates a project)
+
+
+
+
+
+
+
+ deleteProject (Deletes a project)
+
+
+
+
+ updateProject (Updates a project)
+
+
+
+
+ activateProject (Activates a project)
+
+
+
+
+
+
+
+ suspendProject (Suspends a project)
+
+
+
+
+ listProjects (Lists projects and provides detailed information for listed projects)
+
+
+
+
+ addAccountToProject (Adds acoount to a project)
+
+
+
+
+
+
+
+ deleteAccountFromProject (Deletes account from the project)
+
+
+
+
+ listProjectAccounts (Lists project's accounts)
+
+
+
+
+ listProjectInvitations (Lists an account's invitations to join projects)
+
+
+
+
+
+
+
+ updateProjectInvitation (Accepts or declines project invitation)
+
+
+
+
+ deleteProjectInvitation (Deletes a project invitation)
+
+
+
+
+ updateHypervisorCapabilities (Updates a hypervisor capabilities.)
+
+
+
+
+
+
+
+ listHypervisorCapabilities (Lists all hypervisor capabilities.)
+
+
+
+
+ createPhysicalNetwork (Creates a physical network)
+
+
+
+
+ deletePhysicalNetwork (Deletes a Physical Network.)
+
+
+
+
+
+
+
+ listPhysicalNetworks (Lists physical networks)
+
+
+
+
+ updatePhysicalNetwork (Updates a physical network)
+
+
+
+
+ listSupportedNetworkServices (Lists all network services provided by &PRODUCT; or for the given Provider.)
+
+
+
+
+
+
+
+ addNetworkServiceProvider (Adds a network serviceProvider to a physical network)
+
+
+
+
+ deleteNetworkServiceProvider (Deletes a Network Service Provider.)
+
+
+
+
+ listNetworkServiceProviders (Lists network serviceproviders for a given physical network.)
+
+
+
+
+
+
+
+ updateNetworkServiceProvider (Updates a network serviceProvider of a physical network)
+
+
+
+
+ addTrafficType (Adds traffic type to a physical network)
+
+
+
+
+ deleteTrafficType (Deletes traffic type of a physical network)
+
+
+
+
+
+
+
+ listTrafficTypes (Lists traffic types of a given physical network.)
+
+
+
+
+ updateTrafficType (Updates traffic type of a physical network)
+
+
+
+
+ listTrafficTypeImplementors (Lists implementors of implementor of a network traffic type or implementors of all network traffic types)
+
+
+
+
+
+
+
+ createStorageNetworkIpRange (Creates a Storage network IP range.)
+
+
+
+
+ deleteStorageNetworkIpRange (Deletes a storage network IP Range.)
+
+
+
+
+ listStorageNetworkIpRange (List a storage network IP range.)
+
+
+
+
+
+
+
+ updateStorageNetworkIpRange (Update a Storage network IP range, only allowed when no IPs in this range have been allocated.)
+
+
+
+
+ listUsageTypes (List Usage Types)
+
+
+
+
+ addF5LoadBalancer (Adds a F5 BigIP load balancer device)
+
+
+
+
+
+
+
+ configureF5LoadBalancer (configures a F5 load balancer device)
+
+
+
+
+ deleteF5LoadBalancer ( delete a F5 load balancer device)
+
+
+
+
+ listF5LoadBalancers (lists F5 load balancer devices)
+
+
+
+
+
+
+
+ listF5LoadBalancerNetworks (lists network that are using a F5 load balancer device)
+
+
+
+
+ addSrxFirewall (Adds a SRX firewall device)
+
+
+
+
+ deleteSrxFirewall ( delete a SRX firewall device)
+
+
+
+
+
+
+
+ listSrxFirewalls (lists SRX firewall devices in a physical network)
+
+
+
+
+ listSrxFirewallNetworks (lists network that are using SRX firewall device)
+
+
+
+
+ addNetscalerLoadBalancer (Adds a netscaler load balancer device)
+
+
+
+
+
+
+
+ deleteNetscalerLoadBalancer ( delete a netscaler load balancer device)
+
+
+
+
+ configureNetscalerLoadBalancer (configures a netscaler load balancer device)
+
+
+
+
+ listNetscalerLoadBalancers (lists netscaler load balancer devices)
+
+
+
+
+
+
+
+ listNetscalerLoadBalancerNetworks (lists network that are using a netscaler load balancer device)
+
+
+
+
+ createVirtualRouterElement (Create a virtual router element.)
+
+
+
+
+ configureVirtualRouterElement (Configures a virtual router element.)
+
+
+
+
+
+
+
+ listVirtualRouterElements (Lists all available virtual router elements.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/added-cloudPlatform-error-codes.xml b/docs/tmp/en-US/xml/added-cloudPlatform-error-codes.xml
new file mode 100644
index 00000000000..06002f0e4a0
--- /dev/null
+++ b/docs/tmp/en-US/xml/added-cloudPlatform-error-codes.xml
@@ -0,0 +1,401 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Added &PRODUCT; Error Codes
+
+ You can now find the &PRODUCT;-specific error code in the exception response for each type of exception. The following list of error codes is added to the new class named CSExceptionErrorCode. These codes are applicable in &PRODUCT; 3.0.3 and later versions.
+
+
+
+
+
+
+
+
+
+
+ 4250 : "com.cloud.utils.exception.CloudRuntimeException"
+
+
+
+
+ 4255 : "com.cloud.utils.exception.ExceptionUtil"
+
+
+
+
+ 4260 : "com.cloud.utils.exception.ExecutionException"
+
+
+
+
+
+
+
+ 4265 : "com.cloud.utils.exception.HypervisorVersionChangedException"
+
+
+
+
+ 4270 : "com.cloud.utils.exception.RuntimeCloudException"
+
+
+
+
+ 4275 : "com.cloud.exception.CloudException"
+
+
+
+
+
+
+
+ 4280 : "com.cloud.exception.AccountLimitException"
+
+
+
+
+ 4285 : "com.cloud.exception.AgentUnavailableException"
+
+
+
+
+ 4290 : "com.cloud.exception.CloudAuthenticationException"
+
+
+
+
+
+
+
+ 4295 : "com.cloud.exception.CloudExecutionException"
+
+
+
+
+ 4300 : "com.cloud.exception.ConcurrentOperationException"
+
+
+
+
+ 4305 : "com.cloud.exception.ConflictingNetworkSettingsException"
+
+
+
+
+
+
+
+ 4310 : "com.cloud.exception.DiscoveredWithErrorException"
+
+
+
+
+ 4315 : "com.cloud.exception.HAStateException"
+
+
+
+
+ 4320 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+
+
+
+
+
+ 4325 : "com.cloud.exception.InsufficientCapacityException"
+
+
+
+
+ 4330 : "com.cloud.exception.InsufficientNetworkCapacityException"
+
+
+
+
+ 4335 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+
+
+
+
+
+ 4340 : "com.cloud.exception.InsufficientStorageCapacityException"
+
+
+
+
+ 4345 : "com.cloud.exception.InternalErrorException"
+
+
+
+
+ 4350 : "com.cloud.exception.InvalidParameterValueException"
+
+
+
+
+
+
+
+ 4355 : "com.cloud.exception.ManagementServerException"
+
+
+
+
+ 4360 : "com.cloud.exception.NetworkRuleConflictException"
+
+
+
+
+ 4365 : "com.cloud.exception.PermissionDeniedException"
+
+
+
+
+
+
+
+ 4370 : "com.cloud.exception.ResourceAllocationException"
+
+
+
+
+ 4375 : "com.cloud.exception.ResourceInUseException"
+
+
+
+
+ 4380 : "com.cloud.exception.ResourceUnavailableException"
+
+
+
+
+
+
+
+ 4385 : "com.cloud.exception.StorageUnavailableException"
+
+
+
+
+ 4390 : "com.cloud.exception.UnsupportedServiceException"
+
+
+
+
+ 4395 : "com.cloud.exception.VirtualMachineMigrationException"
+
+
+
+
+
+
+
+ 4400 : "com.cloud.exception.AccountLimitException"
+
+
+
+
+ 4405 : "com.cloud.exception.AgentUnavailableException"
+
+
+
+
+ 4410 : "com.cloud.exception.CloudAuthenticationException"
+
+
+
+
+
+
+
+ 4415 : "com.cloud.exception.CloudException"
+
+
+
+
+ 4420 : "com.cloud.exception.CloudExecutionException"
+
+
+
+
+ 4425 : "com.cloud.exception.ConcurrentOperationException"
+
+
+
+
+
+
+
+ 4430 : "com.cloud.exception.ConflictingNetworkSettingsException"
+
+
+
+
+ 4435 : "com.cloud.exception.ConnectionException"
+
+
+
+
+ 4440 : "com.cloud.exception.DiscoveredWithErrorException"
+
+
+
+
+
+
+
+ 4445 : "com.cloud.exception.DiscoveryException"
+
+
+
+
+ 4450 : "com.cloud.exception.HAStateException"
+
+
+
+
+ 4455 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+
+
+
+
+
+ 4460 : "com.cloud.exception.InsufficientCapacityException"
+
+
+
+
+ 4465 : "com.cloud.exception.InsufficientNetworkCapacityException"
+
+
+
+
+ 4470 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+
+
+
+
+
+ 4475 : "com.cloud.exception.InsufficientStorageCapacityException"
+
+
+
+
+ 4480 : "com.cloud.exception.InsufficientVirtualNetworkCapcityException"
+
+
+
+
+ 4485 : "com.cloud.exception.InternalErrorException"
+
+
+
+
+
+
+
+ 4490 : "com.cloud.exception.InvalidParameterValueException"
+
+
+
+
+ 4495 : "com.cloud.exception.ManagementServerException"
+
+
+
+
+ 4500 : "com.cloud.exception.NetworkRuleConflictException"
+
+
+
+
+
+
+
+ 4505 : "com.cloud.exception.PermissionDeniedException"
+
+
+
+
+ 4510 : "com.cloud.exception.ResourceAllocationException"
+
+
+
+
+ 4515 : "com.cloud.exception.ResourceInUseException"
+
+
+
+
+
+
+
+ 4520 : "com.cloud.exception.ResourceUnavailableException"
+
+
+
+
+ 4525 : "com.cloud.exception.StorageUnavailableException"
+
+
+
+
+ 4530 : "com.cloud.exception.UnsupportedServiceException"
+
+
+
+
+
+
+
+ 4535 : "com.cloud.exception.VirtualMachineMigrationException"
+
+
+
+
+ 9999 : "com.cloud.api.ServerApiException"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/added-error-codes.xml b/docs/tmp/en-US/xml/added-error-codes.xml
new file mode 100644
index 00000000000..c7ff3ef5444
--- /dev/null
+++ b/docs/tmp/en-US/xml/added-error-codes.xml
@@ -0,0 +1,401 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Added &PRODUCT; Error Codes
+
+ You can now find the &PRODUCT;-specific error code in the exception response for each type of exception. The following list of error codes is added to the new class named CSExceptionErrorCode. These codes are applicable in &PRODUCT; 3.0.3 and later versions.
+
+
+
+
+
+
+
+
+
+
+ 4250 : "com.cloud.utils.exception.CloudRuntimeException"
+
+
+
+
+ 4255 : "com.cloud.utils.exception.ExceptionUtil"
+
+
+
+
+ 4260 : "com.cloud.utils.exception.ExecutionException"
+
+
+
+
+
+
+
+ 4265 : "com.cloud.utils.exception.HypervisorVersionChangedException"
+
+
+
+
+ 4270 : "com.cloud.utils.exception.RuntimeCloudException"
+
+
+
+
+ 4275 : "com.cloud.exception.CloudException"
+
+
+
+
+
+
+
+ 4280 : "com.cloud.exception.AccountLimitException"
+
+
+
+
+ 4285 : "com.cloud.exception.AgentUnavailableException"
+
+
+
+
+ 4290 : "com.cloud.exception.CloudAuthenticationException"
+
+
+
+
+
+
+
+ 4295 : "com.cloud.exception.CloudExecutionException"
+
+
+
+
+ 4300 : "com.cloud.exception.ConcurrentOperationException"
+
+
+
+
+ 4305 : "com.cloud.exception.ConflictingNetworkSettingsException"
+
+
+
+
+
+
+
+ 4310 : "com.cloud.exception.DiscoveredWithErrorException"
+
+
+
+
+ 4315 : "com.cloud.exception.HAStateException"
+
+
+
+
+ 4320 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+
+
+
+
+
+ 4325 : "com.cloud.exception.InsufficientCapacityException"
+
+
+
+
+ 4330 : "com.cloud.exception.InsufficientNetworkCapacityException"
+
+
+
+
+ 4335 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+
+
+
+
+
+ 4340 : "com.cloud.exception.InsufficientStorageCapacityException"
+
+
+
+
+ 4345 : "com.cloud.exception.InternalErrorException"
+
+
+
+
+ 4350 : "com.cloud.exception.InvalidParameterValueException"
+
+
+
+
+
+
+
+ 4355 : "com.cloud.exception.ManagementServerException"
+
+
+
+
+ 4360 : "com.cloud.exception.NetworkRuleConflictException"
+
+
+
+
+ 4365 : "com.cloud.exception.PermissionDeniedException"
+
+
+
+
+
+
+
+ 4370 : "com.cloud.exception.ResourceAllocationException"
+
+
+
+
+ 4375 : "com.cloud.exception.ResourceInUseException"
+
+
+
+
+ 4380 : "com.cloud.exception.ResourceUnavailableException"
+
+
+
+
+
+
+
+ 4385 : "com.cloud.exception.StorageUnavailableException"
+
+
+
+
+ 4390 : "com.cloud.exception.UnsupportedServiceException"
+
+
+
+
+ 4395 : "com.cloud.exception.VirtualMachineMigrationException"
+
+
+
+
+
+
+
+ 4400 : "com.cloud.exception.AccountLimitException"
+
+
+
+
+ 4405 : "com.cloud.exception.AgentUnavailableException"
+
+
+
+
+ 4410 : "com.cloud.exception.CloudAuthenticationException"
+
+
+
+
+
+
+
+ 4415 : "com.cloud.exception.CloudException"
+
+
+
+
+ 4420 : "com.cloud.exception.CloudExecutionException"
+
+
+
+
+ 4425 : "com.cloud.exception.ConcurrentOperationException"
+
+
+
+
+
+
+
+ 4430 : "com.cloud.exception.ConflictingNetworkSettingsException"
+
+
+
+
+ 4435 : "com.cloud.exception.ConnectionException"
+
+
+
+
+ 4440 : "com.cloud.exception.DiscoveredWithErrorException"
+
+
+
+
+
+
+
+ 4445 : "com.cloud.exception.DiscoveryException"
+
+
+
+
+ 4450 : "com.cloud.exception.HAStateException"
+
+
+
+
+ 4455 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+
+
+
+
+
+ 4460 : "com.cloud.exception.InsufficientCapacityException"
+
+
+
+
+ 4465 : "com.cloud.exception.InsufficientNetworkCapacityException"
+
+
+
+
+ 4470 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+
+
+
+
+
+ 4475 : "com.cloud.exception.InsufficientStorageCapacityException"
+
+
+
+
+ 4480 : "com.cloud.exception.InsufficientVirtualNetworkCapcityException"
+
+
+
+
+ 4485 : "com.cloud.exception.InternalErrorException"
+
+
+
+
+
+
+
+ 4490 : "com.cloud.exception.InvalidParameterValueException"
+
+
+
+
+ 4495 : "com.cloud.exception.ManagementServerException"
+
+
+
+
+ 4500 : "com.cloud.exception.NetworkRuleConflictException"
+
+
+
+
+
+
+
+ 4505 : "com.cloud.exception.PermissionDeniedException"
+
+
+
+
+ 4510 : "com.cloud.exception.ResourceAllocationException"
+
+
+
+
+ 4515 : "com.cloud.exception.ResourceInUseException"
+
+
+
+
+
+
+
+ 4520 : "com.cloud.exception.ResourceUnavailableException"
+
+
+
+
+ 4525 : "com.cloud.exception.StorageUnavailableException"
+
+
+
+
+ 4530 : "com.cloud.exception.UnsupportedServiceException"
+
+
+
+
+
+
+
+ 4535 : "com.cloud.exception.VirtualMachineMigrationException"
+
+
+
+
+ 9999 : "com.cloud.api.ServerApiException"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/adding-IP-addresses-for-the-public-network.xml b/docs/tmp/en-US/xml/adding-IP-addresses-for-the-public-network.xml
new file mode 100644
index 00000000000..0e98406d3f7
--- /dev/null
+++ b/docs/tmp/en-US/xml/adding-IP-addresses-for-the-public-network.xml
@@ -0,0 +1,87 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding IP Addresses for the Public Network
+
+ These instructions assume you have already logged in to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the desired zone .
+
+
+
+
+ Click the Network tab.
+
+
+
+
+ In the Public node of the diagram, click Configure.
+
+
+
+
+ Click the IP Ranges tab.
+
+
+
+
+ Provide the following information:
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+ Click Add.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/admin-alerts.xml b/docs/tmp/en-US/xml/admin-alerts.xml
new file mode 100644
index 00000000000..c1f6cc6f699
--- /dev/null
+++ b/docs/tmp/en-US/xml/admin-alerts.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/admin-guide.xml b/docs/tmp/en-US/xml/admin-guide.xml
new file mode 100644
index 00000000000..9b48abaef2d
--- /dev/null
+++ b/docs/tmp/en-US/xml/admin-guide.xml
@@ -0,0 +1,91 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Administrator Guide
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/adv-zone-topology-req.xml b/docs/tmp/en-US/xml/adv-zone-topology-req.xml
new file mode 100644
index 00000000000..c1ca86ca0f3
--- /dev/null
+++ b/docs/tmp/en-US/xml/adv-zone-topology-req.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Advanced Zone Topology Requirements
+
+ With Advanced Networking, separate subnets must be used for private and public networks.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/advanced-zone-configuration.xml b/docs/tmp/en-US/xml/advanced-zone-configuration.xml
new file mode 100644
index 00000000000..2b80750f3d4
--- /dev/null
+++ b/docs/tmp/en-US/xml/advanced-zone-configuration.xml
@@ -0,0 +1,509 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; 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 . 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.
+
+
+
+
+
+ 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, &PRODUCT; adds the first pod for you. You can always add more pods later. For an overview of what a pod is, see .
+
+
+ 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 &PRODUCT; uses to manage various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP. For more information, see .
+
+
+
+
+
+
+
+
+
+ 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, &PRODUCT; adds the first cluster for you. You can always add more clusters later. For an overview of what a cluster is, see .
+
+
+ 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 &PRODUCT;. See Add Cluster: vSphere .
+
+
+
+
+
+ Cluster name. Enter a name for the cluster. This can be text of your choosing and is not used by &PRODUCT;.
+
+
+
+
+
+
+
+
+
+ In a new cluster, &PRODUCT; adds the first host for you. You can always add more hosts later. For an overview of what a host is, see .
+
+
+
+ When you deploy &PRODUCT;, 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 &PRODUCT; and what additional configuration is required to ensure the host will work with &PRODUCT;. To find these installation details, see:
+
+
+
+
+ Citrix XenServer Installation for &PRODUCT;
+
+
+
+
+
+ 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, &PRODUCT; adds the first primary storage server for you. You can always add more servers later. For an overview of what primary storage is, see .
+
+
+ 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 &PRODUCT;.
+
+
+
+
+
+ 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, &PRODUCT; adds the first secondary storage server for you. For an overview of what secondary storage is, see .
+
+
+ Before you can fill out this screen, you need to prepare the secondary storage by setting up NFS shares and installing the latest &PRODUCT; System VM template. See Adding Secondary Storage :
+
+
+
+
+ NFS Server. The IP address of the server.
+
+
+
+
+
+ Path. The exported path from the server.
+
+
+
+
+
+
+
+
+
+ Click Launch.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/advanced-zone-guest-ip-addresses.xml b/docs/tmp/en-US/xml/advanced-zone-guest-ip-addresses.xml
new file mode 100644
index 00000000000..6fc3d5c126e
--- /dev/null
+++ b/docs/tmp/en-US/xml/advanced-zone-guest-ip-addresses.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Advanced Zone Guest IP Addresses
+
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/advanced-zone-network-traffic-types.xml b/docs/tmp/en-US/xml/advanced-zone-network-traffic-types.xml
new file mode 100644
index 00000000000..c452d0e58e4
--- /dev/null
+++ b/docs/tmp/en-US/xml/advanced-zone-network-traffic-types.xml
@@ -0,0 +1,55 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Advanced Zone Network Traffic Types
+
+ When advanced networking is used, there can be multiple physical networks in the zone. Each physical network can carry one or more traffic types, and you need to let &PRODUCT; know which type of network traffic you want each network to carry. The traffic types in an advanced zone are:
+
+
+
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each &PRODUCT; account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network.
+
+
+
+
+ Management. When &PRODUCT;’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by &PRODUCT; to perform various tasks in the cloud), and any other component that communicates directly with the &PRODUCT; Management Server. You must configure the IP range for the system VMs to use.
+
+
+
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the &PRODUCT; UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide.
+
+
+
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. &PRODUCT; uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+
+
+
+
+ These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/advanced-zone-physical-network-configuration.xml b/docs/tmp/en-US/xml/advanced-zone-physical-network-configuration.xml
new file mode 100644
index 00000000000..393c7b3d521
--- /dev/null
+++ b/docs/tmp/en-US/xml/advanced-zone-physical-network-configuration.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Advanced Zone Physical Network Configuration
+
+ Within a zone that uses advanced networking, you need to tell the Management Server how the physical network is set up to carry different kinds of traffic in isolation.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/advanced-zone-public-ip-addresses.xml b/docs/tmp/en-US/xml/advanced-zone-public-ip-addresses.xml
new file mode 100644
index 00000000000..47494911cb9
--- /dev/null
+++ b/docs/tmp/en-US/xml/advanced-zone-public-ip-addresses.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Advanced Zone Public IP Addresses
+
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/alerts.xml b/docs/tmp/en-US/xml/alerts.xml
new file mode 100644
index 00000000000..f13372e63da
--- /dev/null
+++ b/docs/tmp/en-US/xml/alerts.xml
@@ -0,0 +1,80 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Alerts
+
+ The following is the list of alert type numbers. The current alerts can be found by calling listAlerts.
+
+
+MEMORY = 0
+
+CPU = 1
+
+STORAGE =2
+
+STORAGE_ALLOCATED = 3
+
+PUBLIC_IP = 4
+
+PRIVATE_IP = 5
+
+HOST = 6
+
+USERVM = 7
+
+DOMAIN_ROUTER = 8
+
+CONSOLE_PROXY = 9
+
+ROUTING = 10// lost connection to default route (to the gateway)
+
+STORAGE_MISC = 11 // lost connection to default route (to the gateway)
+
+USAGE_SERVER = 12 // lost connection to default route (to the gateway)
+
+MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)
+
+DOMAIN_ROUTER_MIGRATE = 14
+
+CONSOLE_PROXY_MIGRATE = 15
+
+USERVM_MIGRATE = 16
+
+VLAN = 17
+
+SSVM = 18
+
+USAGE_SERVER_RESULT = 19
+
+STORAGE_DELETE = 20;
+
+UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource count
+
+USAGE_SANITY_RESULT = 22;
+
+DIRECT_ATTACHED_PUBLIC_IP = 23;
+
+LOCAL_STORAGE = 24;
+
+RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only
+
+
diff --git a/docs/tmp/en-US/xml/allocators.xml b/docs/tmp/en-US/xml/allocators.xml
new file mode 100644
index 00000000000..9515062c18b
--- /dev/null
+++ b/docs/tmp/en-US/xml/allocators.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Allocators
+
+ &PRODUCT; enables administrators to write custom allocators that will choose the Host to place a new guest and the storage host from which to allocate guest virtual disk images.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/api-calls.xml b/docs/tmp/en-US/xml/api-calls.xml
new file mode 100644
index 00000000000..efd09260f79
--- /dev/null
+++ b/docs/tmp/en-US/xml/api-calls.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Calling the &PRODUCT; API
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/api-overview.xml b/docs/tmp/en-US/xml/api-overview.xml
new file mode 100644
index 00000000000..633f2d40c86
--- /dev/null
+++ b/docs/tmp/en-US/xml/api-overview.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ &PRODUCT; API
+
+ The &PRODUCT; API is a low level API that has been used to implement the &PRODUCT; web UIs. It is also a good basis for implementing other popular APIs such as EC2/S3 and emerging DMTF standards.
+
+
+ Many &PRODUCT; 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 and the API Reference.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/api-reference.xml b/docs/tmp/en-US/xml/api-reference.xml
new file mode 100644
index 00000000000..c4bf6473457
--- /dev/null
+++ b/docs/tmp/en-US/xml/api-reference.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ API Reference Documentation
+
+ 2.2 API Reference:
+
+
+ http://download.cloud.com/support/downloads.html/
+
+
+ 3.0 API Reference:
+
+
+ http://download.cloud.com/releases/3.0.0/api_3.0.0/TOC_Root_Admin.html/
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/appendix-a-time-zones.xml b/docs/tmp/en-US/xml/appendix-a-time-zones.xml
new file mode 100644
index 00000000000..0eea648a69e
--- /dev/null
+++ b/docs/tmp/en-US/xml/appendix-a-time-zones.xml
@@ -0,0 +1,396 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Appendix A—Time Zones
+
+ The following time zone identifiers are accepted by &PRODUCT;. 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
+
+
+
+
+ America/La_Paz
+
+
+
+
+ Asia/Jerusalem
+
+
+
+
+
+
+
+ Etc/GMT+11
+
+
+
+
+ America/Santiago
+
+
+
+
+ Europe/Minsk
+
+
+
+
+
+
+
+ Pacific/Samoa
+
+
+
+
+ America/St_Johns
+
+
+
+
+ Europe/Moscow
+
+
+
+
+
+
+
+ Pacific/Honolulu
+
+
+
+
+ America/Araguaina
+
+
+
+
+ Africa/Nairobi
+
+
+
+
+
+
+
+ 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/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/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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/asynchronous-commands-example.xml b/docs/tmp/en-US/xml/asynchronous-commands-example.xml
new file mode 100644
index 00000000000..0d2cfbe65a9
--- /dev/null
+++ b/docs/tmp/en-US/xml/asynchronous-commands-example.xml
@@ -0,0 +1,131 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Example
+
+ The following shows an example of using an asynchronous command. Assume the API command:
+
+
+command=deployVirtualMachine&zoneId=1&serviceOfferingId=1&diskOfferingId=1&templateId=1
+
+
+ CloudStack will immediately return a job ID and any other additional data.
+
+
+
+ <deployvirtualmachineresponse>
+ <jobid>1</jobid>
+ <id>100</id>
+ </deployvirtualmachineresponse>
+
+
+ Using the job ID, you can periodically poll for the results by using the queryAsyncJobResult command.
+
+
+command=queryAsyncJobResult&jobId=1
+
+ Three possible results could come from this query.
+
+
+ Job is still pending:
+
+
+
+ <queryasyncjobresult>
+ <jobid>1</jobid>
+ <jobstatus>0</jobstatus>
+ <jobprocstatus>1</jobprocstatus>
+ </queryasyncjobresult>
+
+
+ Job has succeeded:
+
+
+
+ <queryasyncjobresultresponse cloud-stack-version="3.0.1.6">
+ <jobid>1</jobid>
+ <jobstatus>1</jobstatus>
+ <jobprocstatus>0</jobprocstatus>
+ <jobresultcode>0</jobresultcode>
+ <jobresulttype>object</jobresulttype>
+ <jobresult>
+ <virtualmachine>
+ <id>450</id>
+ <name>i-2-450-VM</name>
+ <displayname>i-2-450-VM</displayname>
+ <account>admin</account>
+ <domainid>1</domainid>
+ <domain>ROOT</domain>
+ <created>2011-03-10T18:20:25-0800</created>
+ <state>Running</state>
+ <haenable>false</haenable>
+ <zoneid>1</zoneid>
+ <zonename>San Jose 1</zonename>
+ <hostid>2</hostid>
+ <hostname>905-13.sjc.lab.vmops.com</hostname>
+ <templateid>1</templateid>
+ <templatename>CentOS 5.3 64bit LAMP</templatename>
+ <templatedisplaytext>CentOS 5.3 64bit LAMP</templatedisplaytext>
+ <passwordenabled>false</passwordenabled>
+ <serviceofferingid>1</serviceofferingid>
+ <serviceofferingname>Small Instance</serviceofferingname>
+ <cpunumber>1</cpunumber>
+ <cpuspeed>500</cpuspeed>
+ <memory>512</memory>
+ <guestosid>12</guestosid>
+ <rootdeviceid>0</rootdeviceid>
+ <rootdevicetype>NetworkFilesystem</rootdevicetype>
+ <nic>
+ <id>561</id>
+ <networkid>205</networkid>
+ <netmask>255.255.255.0</netmask>
+ <gateway>10.1.1.1</gateway>
+ <ipaddress>10.1.1.225</ipaddress>
+ <isolationuri>vlan://295</isolationuri>
+ <broadcasturi>vlan://295</broadcasturi>
+ <traffictype>Guest</traffictype>
+ <type>Virtual</type>
+ <isdefault>true</isdefault>
+ </nic>
+ <hypervisor>XenServer</hypervisor>
+ </virtualmachine>
+ </jobresult>
+ </queryasyncjobresultresponse>
+
+
+ Job has failed:
+
+
+
+ <queryasyncjobresult>
+ <jobid>1</jobid>
+ <jobstatus>2</jobstatus>
+ <jobprocstatus>0</jobprocstatus>
+ <jobresultcode>551</jobresultcode>
+ <jobresulttype>text</jobresulttype>
+ <jobresult>Unable to deploy virtual machine id = 100 due to not enough capacity</jobresult>
+ </queryasyncjobresult>
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/asynchronous-commands.xml b/docs/tmp/en-US/xml/asynchronous-commands.xml
new file mode 100644
index 00000000000..3f9fb6c5ce5
--- /dev/null
+++ b/docs/tmp/en-US/xml/asynchronous-commands.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Asynchronous Commands
+
+ Asynchronous commands were introduced in &PRODUCT; 2.x. Commands are designated as asynchronous when they can potentially take a long period of time to complete such as creating a snapshot or disk volume. They differ from synchronous commands by the following:
+
+
+
+
+ They are identified in the API Reference by an (A).
+
+
+
+
+ They will immediately return a job ID to refer to the job that will be responsible in processing the command.
+
+
+
+
+ If executed as a "create" resource command, it will return the resource ID as well as the job ID.
+
+
+ You can periodically check the status of the job by making a simple API call to the command, queryAsyncJobResult and passing in the job ID.
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/attach-iso-to-vm.xml b/docs/tmp/en-US/xml/attach-iso-to-vm.xml
new file mode 100644
index 00000000000..4c0ead26739
--- /dev/null
+++ b/docs/tmp/en-US/xml/attach-iso-to-vm.xml
@@ -0,0 +1,63 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Attaching an ISO to a VM
+
+
+
+ In the left navigation, click Instances.
+
+
+
+
+ Choose the virtual machine you want to work with.
+
+
+
+
+ Click the Attach ISO button
+
+
+
+
+
+ iso.png: Depicts adding an iso image
+
+
+
+
+
+
+
+ In the Attach ISO dialog box, select the desired ISO.
+
+
+
+
+ Click OK
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/attaching-volume.xml b/docs/tmp/en-US/xml/attaching-volume.xml
new file mode 100644
index 00000000000..513db0dea10
--- /dev/null
+++ b/docs/tmp/en-US/xml/attaching-volume.xml
@@ -0,0 +1,74 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Attaching a Volume
+
+ You can attach a volume to a guest VM to provide extra disk storage. Attach a volume when you first create a new volume, when you are moving an existing volume from one VM to another, or after you have migrated a volume from one storage pool to another.
+
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+ In the left navigation, click Storage.
+
+
+
+
+ In Select View, choose Volumes.
+
+
+
+
+ 4. Click the volume name in the Volumes list, then click the Attach Disk button
+
+
+
+
+
+ AttachDiskButton.png: button to attach a volume
+
+
+
+
+
+
+
+
+ In the Instance popup, choose the VM to which you want to attach the volume. You will only see instances to which you are allowed to attach volumes; for example, a user will see only instances created by that user, but the administrator will have more choices.
+
+
+
+
+
+ When the volume has been attached, you should be able to see it by clicking Instances, the instance name, and View Volumes.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/automatic-snapshot-creation-retention.xml b/docs/tmp/en-US/xml/automatic-snapshot-creation-retention.xml
new file mode 100644
index 00000000000..8abcfd2e70a
--- /dev/null
+++ b/docs/tmp/en-US/xml/automatic-snapshot-creation-retention.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Automatic Snapshot Creation and Retention
+
+ (Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)
+
+
+ Users can set up a recurring snapshot policy to automatically create multiple snapshots of a disk at regular intervals. Snapshots can be created on an hourly, daily, weekly, or monthly interval. One snapshot policy can be set up per disk volume. For example, a user can set up a daily snapshot at 02:30.
+
+
+ With each snapshot schedule, users can also specify the number of scheduled snapshots to be retained. Older snapshots that exceed the retention limit are automatically deleted. This user-defined limit must be equal to or lower than the global limit set by the &PRODUCT; administrator. See . The limit applies only to those snapshots that are taken as part of an automatic recurring snapshot policy. Additional manual snapshots can be created and retained.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/aws-ec2-configuration.xml b/docs/tmp/en-US/xml/aws-ec2-configuration.xml
new file mode 100644
index 00000000000..c7b9216b3fa
--- /dev/null
+++ b/docs/tmp/en-US/xml/aws-ec2-configuration.xml
@@ -0,0 +1,90 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Enabling the AWS API Compatible Interface
+
+ The software that provides AWS API compatibility is installed along with CloudPlatform. However, you must enable the feature and perform some setup steps.
+
+
+
+
+ Set the global configuration parameter enable.ec2.api to true. See .
+
+
+
+
+ Create a set of &PRODUCT; service offerings with names that match the Amazon service offerings. You can do this through the &PRODUCT; UI as described in the Administration Guide.
+
+
+
+ Be sure you have included the Amazon default service offering, m1.small.
+
+
+
+
+
+ If you did not already do so when you set the configuration parameter in step 1, restart the Management Server.
+
+
+# service cloud-management restart
+
+
+
+ (Optional) The AWS API listens for requests on port 7080. If you prefer AWS API to listen on another port, you can change it as follows:
+
+
+
+
+ Edit the files /etc/cloud/management/server.xml, /etc/cloud/management/server-nonssl.xml, and /etc/cloud/management/server-ssl.xml.
+
+
+
+
+ In each file, find the tag <Service name="Catalina7080">. Under this tag, locate <Connector executor="tomcatThreadPool-internal" port= ....<.
+
+
+
+
+ Change the port to whatever port you want to use, then save the files.
+
+
+
+
+ Restart the Management Server.
+
+
+
+ If you re-install CloudStack, you will have to make these changes again.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/aws-ec2-introduction.xml b/docs/tmp/en-US/xml/aws-ec2-introduction.xml
new file mode 100644
index 00000000000..00b64029ff7
--- /dev/null
+++ b/docs/tmp/en-US/xml/aws-ec2-introduction.xml
@@ -0,0 +1,59 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Amazon Web Services EC2 Compatible Interface
+
+ &PRODUCT; can translate Amazon Web Services (AWS) API calls to native &PRODUCT; API calls so that users can continue using existing AWS-compatible tools. This translation service runs as a separate web application in the same tomcat server as the management server of &PRODUCT;, listening on the same port. This Amazon EC2-compatible API is accessible through a SOAP web service.
+
+
+
+ This service was previously enabled by separate software called CloudBridge. It is now fully integrated with the &PRODUCT; management server.
+
+
+
+
+ Limitations
+
+
+
+
+ Supported only in zones that use basic networking.
+
+
+
+
+
+ Available in fresh installations of &PRODUCT;. Not available through upgrade of previous versions.
+
+
+
+
+
+ If you need to support features such as elastic IP, set up a Citrix NetScaler to provide this service. The commands such as ec2-associate-address will not work without EIP setup. Users running VMs in this zone will be using the NetScaler-enabled network offering (DefaultSharedNetscalerEIP and ELBNetworkOffering).
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/aws-ec2-requirements.xml b/docs/tmp/en-US/xml/aws-ec2-requirements.xml
new file mode 100644
index 00000000000..87943cbf883
--- /dev/null
+++ b/docs/tmp/en-US/xml/aws-ec2-requirements.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ System Requirements
+
+
+
+ This interface complies with Amazon's WDSL version dated November 15, 2010, available at http://ec2.amazonaws.com/doc/2010-11-15/.
+
+
+
+
+ Compatible with the EC2 command-line tools EC2 tools v. 1.3.6230, which can be downloaded at http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-62308.zip.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/aws-ec2-supported-commands.xml b/docs/tmp/en-US/xml/aws-ec2-supported-commands.xml
new file mode 100644
index 00000000000..56e873ae7f4
--- /dev/null
+++ b/docs/tmp/en-US/xml/aws-ec2-supported-commands.xml
@@ -0,0 +1,771 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Supported AWS API Calls
+
+ The following Amazon EC2 commands are supported by &PRODUCT; when the AWS API compatibility feature is enabled. For a few commands, there are differences between the &PRODUCT; and Amazon EC2 versions, and these differences are noted. The underlying SOAP call for each command is also given, for those who have built tools using those calls.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/aws-ec2-timeouts.xml b/docs/tmp/en-US/xml/aws-ec2-timeouts.xml
new file mode 100644
index 00000000000..e1fb82842fc
--- /dev/null
+++ b/docs/tmp/en-US/xml/aws-ec2-timeouts.xml
@@ -0,0 +1,69 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using Timeouts to Ensure AWS API Command Completion
+
+ The Amazon EC2 command-line tools have a default connection timeout. When used with &PRODUCT;, a longer timeout might be needed for some commands. If you find that commands are not completing due to timeouts, you can gain more time for commands to finish by overriding the default timeouts on individual commands. You can add the following optional command-line parameters to any &PRODUCT;-supported EC2 command:
+
+
+
+
+
+
+
+
+
+--connection-timeout TIMEOUT
+
+
+ Specifies a connection timeout (in seconds). Example:
+--connection-timeout 30
+
+
+
+
+
+
+
+--request-timeout TIMEOUT
+
+
+ Specifies a request timeout (in seconds). Example:
+--request-timeout 45
+
+
+
+
+
+
+
+
+
+
+
+ Example:
+
+
+ec2-run-instances 2 –z us-test1 –n 1-3 --connection-timeout 120 --request-timeout 120
+
+
+
diff --git a/docs/tmp/en-US/xml/aws-ec2-user-setup.xml b/docs/tmp/en-US/xml/aws-ec2-user-setup.xml
new file mode 100644
index 00000000000..25885347c6a
--- /dev/null
+++ b/docs/tmp/en-US/xml/aws-ec2-user-setup.xml
@@ -0,0 +1,139 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ AWS API User Setup Steps
+
+ In general, users need not be aware that they are using a translation service provided by &PRODUCT;. They need only send AWS API calls to &PRODUCT;'s endpoint, and it will translate the calls to the native API. Users of the Amazon EC2 compatible interface will be able to keep their existing EC2 tools and scripts and use them with their &PRODUCT; deployment, by specifying the endpoint of the management server and using the proper user credentials. In order to do this, each user must perform the following configuration steps:
+
+
+
+
+
+ Generate user credentials and register with the service.
+
+
+
+
+
+ Set up the environment variables for the EC2 command-line tools.
+
+
+
+
+
+ For SOAP access, use the endpoint http://&PRODUCT;-management-server:7080/awsapi. The &PRODUCT;-management-server can be specified by a fully-qualified domain name or IP address.
+
+
+
+
+
+
+
+
+ AWS API User Registration
+
+ Each user must perform a one-time registration. The user follows these steps:
+
+
+
+
+ Obtain the following by looking in the &PRODUCT; UI, using the API, or asking the cloud administrator:
+
+
+
+
+ The &PRODUCT; server's publicly available DNS name or IP address
+
+
+
+
+ The user account's API key and Secret key
+
+
+
+
+
+
+
+
+ Generate a private key and a self-signed X.509 certificate. The user substitutes their own desired storage location for /path/to/… below.
+
+
+
+$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /path/to/private_key.pem -out /path/to/cert.pem
+
+
+
+
+
+
+ Register the mapping from the X.509 certificate to the API/Secret keys. Download the following script from http://download.cloud.com/releases/3.0.3/cloudstack-aws-api-register and run it. Substitute the values that were obtained in step 1 in the URL below.
+
+
+
+$ cloudstack-aws-api-register --apikey=User’s &PRODUCT; API key --secretkey=User’s &PRODUCT; Secret key --cert=/path/to/cert.pem --url=http://&PRODUCT;.server:7080/awsapi
+
+
+
+
+
+
+
+
+ A user with an existing AWS certificate could choose to use the same certificate with &PRODUCT;, but the public key would be uploaded to the &PRODUCT; management server database.
+
+
+
+
+
+
+
+ AWS API Command-Line Tools Setup
+
+ To use the EC2 command-line tools, the user must perform these steps:
+
+
+
+
+ Be sure you have the right version of EC2 Tools. The supported version is available at http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-62308.zip.
+
+
+
+
+
+ Set up the environment variables that will direct the tools to the server. As a best practice, you may wish to place these commands in a script that may be sourced before using the AWS API translation feature.
+
+
+$ export EC2_CERT=/path/to/cert.pem
+$ export EC2_PRIVATE_KEY=/path/to/private_key.pem
+$ export EC2_URL=http://&PRODUCT;.server:7080/awsapi
+$ export EC2_HOME=/path/to/EC2_tools_directory
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/aws-interface-compatibility.xml b/docs/tmp/en-US/xml/aws-interface-compatibility.xml
new file mode 100644
index 00000000000..f137b0673bb
--- /dev/null
+++ b/docs/tmp/en-US/xml/aws-interface-compatibility.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Amazon Web Service Interface Compatibility
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/basic-adv-networking.xml b/docs/tmp/en-US/xml/basic-adv-networking.xml
new file mode 100644
index 00000000000..f5ef3a388d0
--- /dev/null
+++ b/docs/tmp/en-US/xml/basic-adv-networking.xml
@@ -0,0 +1,281 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Basic and Advanced Networking
+
+ &PRODUCT; provides two styles of networking:.
+
+
+ Basic
+
+ For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+
+
+
+
+ Advanced
+
+ For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks, but requires more configuration steps than basic networking.
+
+
+
+
+ Each zone has either basic or advanced networking. Once the choice of networking model for a zone has been made and configured in &PRODUCT;, it can not be changed. A zone is either basic or advanced for its entire lifetime.
+
+
+ The following table compares the networking features in the two networking models.
+
+
+
+
+
+
+
+ Networking Feature
+
+
+
+
+ Basic Network
+
+
+
+
+ Advanced Network
+
+
+
+
+
+
+
+
+
+
+ Number of networks
+
+
+
+
+ Single network
+
+
+
+
+ Multiple networks
+
+
+
+
+
+
+
+ Firewall type
+
+
+
+
+ Physical
+
+
+
+
+ Physical and Virtual
+
+
+
+
+
+
+
+ Load balancer
+
+
+
+
+ Physical
+
+
+
+
+ Physical and Virtual
+
+
+
+
+
+
+
+ Isolation type
+
+
+
+
+ Layer 3
+
+
+
+
+ Layer 2 and Layer 3
+
+
+
+
+
+
+
+ VPN support
+
+
+
+
+ No
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+ Port forwarding
+
+
+
+
+ Physical
+
+
+
+
+ Physical and Virtual
+
+
+
+
+
+
+
+ 1:1 NAT
+
+
+
+
+ Physical
+
+
+
+
+ Physical and Virtual
+
+
+
+
+
+
+
+ Source NAT
+
+
+
+
+ No
+
+
+
+
+ Physical and Virtual
+
+
+
+
+
+
+
+ Userdata
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+ Network usage monitoring
+
+
+
+
+ sFlow / netFlow at physical router
+
+
+
+
+ Hypervisor and Virtual Router
+
+
+
+
+
+
+
+ DNS and DHCP
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+
+
+
+
+ The two types of networking may be in use in the same cloud. However, a given zone must use either Basic Networking or Advanced Networking.
+
+
+ Different types of network traffic can be segmented on the same physical network. Guest traffic can also be segmented by account. To isolate traffic, you can use separate VLANs. If you are using separate VLANs on a single physical network, make sure the VLAN tags are in separate numerical ranges.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/basic-zone-configuration.xml b/docs/tmp/en-US/xml/basic-zone-configuration.xml
new file mode 100644
index 00000000000..837daffa765
--- /dev/null
+++ b/docs/tmp/en-US/xml/basic-zone-configuration.xml
@@ -0,0 +1,413 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; 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.
+
+
+
+
+
+ (Introduced in version 3.0.1) 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. &PRODUCT; 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, &PRODUCT; adds the first pod for you. You can always add more pods later. For an overview of what a pod is, see .
+
+
+ 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 &PRODUCT; 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 &PRODUCT; 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, &PRODUCT; 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 &PRODUCT;. See Add Cluster: vSphere.
+
+
+
+
+ Cluster name. Enter a name for the cluster. This can be text of your choosing and is not used by &PRODUCT;.
+
+
+
+
+
+
+
+
+ In a new cluster, &PRODUCT; adds the first host for you. You can always add more hosts later. For an overview of what a host is, see About Hosts.
+
+
+
+ When you add a hypervisor host to &PRODUCT;, 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 &PRODUCT; and what additional configuration is required to ensure the host will work with &PRODUCT;. 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, CloudPlatform 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.
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/basic-zone-guest-ip-addresses.xml b/docs/tmp/en-US/xml/basic-zone-guest-ip-addresses.xml
new file mode 100644
index 00000000000..209b8d08334
--- /dev/null
+++ b/docs/tmp/en-US/xml/basic-zone-guest-ip-addresses.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Basic Zone Guest IP Addresses
+
+ When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/basic-zone-network-traffic-types.xml b/docs/tmp/en-US/xml/basic-zone-network-traffic-types.xml
new file mode 100644
index 00000000000..08df3b1727d
--- /dev/null
+++ b/docs/tmp/en-US/xml/basic-zone-network-traffic-types.xml
@@ -0,0 +1,60 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Basic Zone Network Traffic Types
+
+ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types:
+
+
+
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod.
+
+
+
+
+ Management. When &PRODUCT;’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by &PRODUCT; to perform various tasks in the cloud), and any other component that communicates directly with the &PRODUCT; Management Server. You must configure the IP range for the system VMs to use.
+
+
+
+ We strongly recommend the use of separate NICs for management traffic and guest traffic.
+
+
+
+
+
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the &PRODUCT; UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address.
+
+
+
+
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. &PRODUCT; uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+
+
+
+
+ In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. &PRODUCT; takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/basic-zone-physical-network-configuration.xml b/docs/tmp/en-US/xml/basic-zone-physical-network-configuration.xml
new file mode 100644
index 00000000000..8b019d7db84
--- /dev/null
+++ b/docs/tmp/en-US/xml/basic-zone-physical-network-configuration.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Basic Zone Physical Network Configuration
+
+ In a basic network, configuring the physical network is fairly straightforward. You only need to configure one guest network to carry traffic that is generated by guest VMs. When you first add a zone to CloudPlatform, you set up the guest network through the Add Zone screens.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/best-practices-for-vms.xml b/docs/tmp/en-US/xml/best-practices-for-vms.xml
new file mode 100644
index 00000000000..967798eb3e0
--- /dev/null
+++ b/docs/tmp/en-US/xml/best-practices-for-vms.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Best Practices for Virtual Machines
+
+ The &PRODUCT; administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use &PRODUCT; global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the &PRODUCT; UI to disable allocation of more VMs to the cluster.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/best-practices-primary-storage.xml b/docs/tmp/en-US/xml/best-practices-primary-storage.xml
new file mode 100644
index 00000000000..57b1abf2959
--- /dev/null
+++ b/docs/tmp/en-US/xml/best-practices-primary-storage.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Best Practices for Primary Storage
+
+
+
+ The speed of primary storage will impact guest performance. If possible, choose smaller, higher RPM drives for primary storage.
+
+
+
+
+ Ensure that nothing is stored on the server. Adding the server to CloudPlatform will destroy any existing data
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/best-practices-secondary-storage.xml b/docs/tmp/en-US/xml/best-practices-secondary-storage.xml
new file mode 100644
index 00000000000..9a3ff15fdff
--- /dev/null
+++ b/docs/tmp/en-US/xml/best-practices-secondary-storage.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Best Practices for Secondary Storage
+
+
+
+ Each Zone can have one or more secondary storage servers. Multiple secondary storage servers provide increased scalability to the system.
+
+
+
+
+ Secondary storage has a high read:write ratio and is expected to consist of larger drives with lower IOPS than primary storage.
+
+
+
+
+ Ensure that nothing is stored on the server. Adding the server to CloudPlatform will destroy any existing data.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/best-practices-templates.xml b/docs/tmp/en-US/xml/best-practices-templates.xml
new file mode 100644
index 00000000000..170d5a74446
--- /dev/null
+++ b/docs/tmp/en-US/xml/best-practices-templates.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Best Practices for Templates
+
+ If you plan to use large templates (100 GB or larger), be sure you have a 10-gigabit network to support the large templates. A slower network can lead to timeouts and other errors when large templates are used.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/best-practices-virtual-router.xml b/docs/tmp/en-US/xml/best-practices-virtual-router.xml
new file mode 100644
index 00000000000..3d95e80ce4b
--- /dev/null
+++ b/docs/tmp/en-US/xml/best-practices-virtual-router.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Best Practices for Virtual Routers
+
+
+
+ WARNING: Restarting a virtual router from a hypervisor console deletes all the iptables rules. To work around this issue, stop the virtual router and start it from the &PRODUCT; UI.
+
+
+
+
+ WARNING: Do not use the destroyRouter API when only one router is available in the network, because restartNetwork API with the cleanup=false parameter can't recreate it later. If you want to destroy and recreate the single router available in the network, use the restartNetwork API with the cleanup=true parameter.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/build-deb.xml b/docs/tmp/en-US/xml/build-deb.xml
new file mode 100644
index 00000000000..2b419b04adb
--- /dev/null
+++ b/docs/tmp/en-US/xml/build-deb.xml
@@ -0,0 +1,118 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Building DEB packages
+
+ In addition to the bootstrap dependencies, you'll also need to install several other dependencies. Note that we recommend using Maven 3, which is not currently available in 12.04.1 LTS. So, you'll also need to add a PPA repository that includes Maven 3. After running the command add-apt-repository, you will be prompted to continue and a GPG key will be added.
+
+
+
+$ sudo apt-get update
+$ sudo apt-get install python-software-properties
+$ sudo add-apt-repository ppa:natecarlson/maven3
+$ sudo apt-get update
+$ sudo apt-get install ant debhelper openjdk-6-jdk tomcat6 libws-commons-util-java genisoimage python-mysqldb libcommons-codec-java libcommons-httpclient-java liblog4j1.2-java maven3
+
+ While we have defined, and you have presumably already installed the bootstrap prerequisites, there are a number of build time prerequisites that need to be resolved. &PRODUCT; uses maven for dependency resolution. You can resolve the buildtime depdencies for CloudStack by running:
+
+
+$ mvn3 -P deps
+
+ Now that we have resolved the dependencies we can move on to building &PRODUCT; and packaging them into DEBs by issuing the following command.
+
+
+
+$ dpkg-buildpackge -uc -us
+
+ This command will build 16 Debian packages. You should have all of the following:
+
+
+
+cloud-agent_4.0.0-incubating_amd64.deb
+cloud-agent-deps_4.0.0-incubating_amd64.deb
+cloud-agent-libs_4.0.0-incubating_amd64.deb
+cloud-awsapi_4.0.0-incubating_amd64.deb
+cloud-cli_4.0.0-incubating_amd64.deb
+cloud-client_4.0.0-incubating_amd64.deb
+cloud-client-ui_4.0.0-incubating_amd64.deb
+cloud-core_4.0.0-incubating_amd64.deb
+cloud-deps_4.0.0-incubating_amd64.deb
+cloud-python_4.0.0-incubating_amd64.deb
+cloud-scripts_4.0.0-incubating_amd64.deb
+cloud-server_4.0.0-incubating_amd64.deb
+cloud-setup_4.0.0-incubating_amd64.deb
+cloud-system-iso_4.0.0-incubating_amd64.deb
+cloud-usage_4.0.0-incubating_amd64.deb
+cloud-utils_4.0.0-incubating_amd64.deb
+
+
+ Setting up an APT repo
+
+ After you've created the packages, you'll want to copy them to a system where you can serve the packages over HTTP. You'll create a directory for the packages and then use dpkg-scanpackages to create Packages.gz, which holds information about the archive structure. Finally, you'll add the repository to your system(s) so you can install the packages using APT.
+
+
+ The first step is to make sure that you have the dpkg-dev package installed. This should have been installed when you pulled in the debhelper application previously, but if you're generating Packages.gz on a different system, be sure that it's installed there as well.
+
+
+$ sudo apt-get install dpkg-dev
+
+ The next step is to copy the DEBs to the directory where they can be served over HTTP. We'll use /var/www/cloudstack/repo in the examples, but change the directory to whatever works for you.
+
+
+
+sudo mkdir -p /var/www/cloudstack/repo/binary
+sudo cp *.deb /var/www/cloudstack/repo/binary
+sudo cd /var/www/cloudstack/repo/binary
+sudo dpkg-scanpackages . /dev/null | tee Packages | gzip -9 > Packages.gz
+
+ Note: Override Files
+
+ You can safely ignore the warning about a missing override file.
+
+
+
+ Now you should have all of the DEB packages and Packages.gz in the binary directory and available over HTTP. (You may want to use wget or curl to test this before moving on to the next step.)
+
+
+
+
+
+ Configuring your machines to use the APT repository
+
+ Now that we have created the repository, you need to configure your machine to make use of the APT repository. You can do this by adding a repository file under /etc/apt/sources.list.d. Use your preferred editor to create /etc/apt/sources.list.d/cloudstack.list with this line:
+
+
+deb http://server.url/cloudstack/repo binary/
+
+ Now that you have the repository info in place, you'll want to run another update so that APT knows where to find the &PRODUCT; packages.
+
+
+$ sudo apt-get update
+
+ You can now move on to the instructions under Install on Ubuntu.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/build-rpm.xml b/docs/tmp/en-US/xml/build-rpm.xml
new file mode 100644
index 00000000000..1331de8b542
--- /dev/null
+++ b/docs/tmp/en-US/xml/build-rpm.xml
@@ -0,0 +1,76 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Building RPMs
+
+ While we have defined, and you have presumably already installed the bootstrap prerequisites, there are a number of build time prerequisites that need to be resolved. &PRODUCT; uses maven for dependency resolution. You can resolve the buildtime depdencies for CloudStack by running the following command:
+$mvn -P deps
+
+
+
+ Now that we have resolved the dependencies we can move on to building &PRODUCT; and packaging them into RPMs by issuing the following command.
+$./waf rpm
+
+
+
+ Once this completes, you should find assembled RPMs in artifacts/rpmbuild/RPMS/x86_64
+
+
+ Creating a yum repo
+
+ While RPMs is an ideal packaging format - it's most easily consumed from yum repositories over a network. We'll move into the directory with the newly created RPMs by issuing the following command:
+$cd artifacts/rpmbuild/RPMS/x86_64
+
+
+
+ Next we'll issue a command to create the repository metadata by issuing the following command:
+$createrepo ./
+
+
+
+ The files and directories within our current working directory can now be uploaded to a web server and serve as a yum repository
+
+
+
+
+
+ Configuring your systems to use your new yum repository
+
+ Now that your yum repository is populated with RPMs and metadata we need to configure our machines that need to install CloudStack. We will create a file at /etc/yum.repos.d/cloudstack.repo with the following content:
+
+[apache-cloudstack]
+name=Apache CloudStack
+baseurl=http://webserver.tld/path/to/repo
+enabled=1
+gpgcheck=0
+
+
+
+
+ Completing this step will allow you to easily install CloudStack on a number of machines across the network.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/castor-with-cs.xml b/docs/tmp/en-US/xml/castor-with-cs.xml
new file mode 100644
index 00000000000..c3519ded4a2
--- /dev/null
+++ b/docs/tmp/en-US/xml/castor-with-cs.xml
@@ -0,0 +1,115 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using the CAStor Back-end Storage with &PRODUCT;
+
+ This section describes how to use a CAStor cluster as the back-end storage system for a &PRODUCT; S3 front-end. The CAStor back-end storage for &PRODUCT; extends the existing storage classes and allows the storage configuration attribute to point to a CAStor cluster.
+
+
+ This feature makes use of the &PRODUCT; server's local disk to spool files before writing them to CAStor when handling the PUT operations. However, a file must be successfully written into the CAStor cluster prior to the return of a success code to the S3 client to ensure that the transaction outcome is correctly reported.
+
+
+
+ The S3 multipart file upload is not supported in this release. You are prompted with proper error message if a multipart upload is attempted.
+
+
+
+
+ To configure CAStor:
+
+
+
+
+ Install &PRODUCT; 4.0.0-incubating by following the instructions given in the INSTALL.txt file.
+
+
+
+ You can use the S3 storage system in &PRODUCT; without setting up and installing the compute components.
+
+
+
+
+
+
+
+ Enable the S3 API by setting "enable.s3.api = true" in the Global parameter section in the UI and register a user.
+
+
+ For more information, see S3 API in &PRODUCT;.
+
+
+
+
+
+ Edit the cloud-bridge.properties file and modify the "storage.root" parameter.
+
+
+
+
+ Set "storage.root" to the key word "castor".
+
+
+
+
+
+ Specify a CAStor tenant domain to which content is written. If the domain is not specified, the CAStor default domain, specified by the "cluster" parameter in CAStor's node.cfg file, will be used.
+
+
+
+
+
+ Specify a list of node IP addresses, or set "zeroconf" and the cluster name. When using a static IP list with a large cluster, it is not necessary to include every node, only a few is required to initialize the client software.
+
+
+ For example:
+
+
+storage.root=castor domain=cloudstack 10.1.1.51 10.1.1.52 10.1.1.53
+
+ In this example, the configuration file directs &PRODUCT; to write the S3 files to CAStor instead of to a file system, where the CAStor domain name is cloudstack, and the CAStor node IP addresses are those listed.
+
+
+
+
+
+ (Optional) The last value is a port number on which to communicate with the CAStor cluster. If not specified, the default is 80.
+
+
+#Static IP list with optional port
+storage.root=castor domain=cloudstack 10.1.1.51 10.1.1.52 10.1.1.53 80
+#Zeroconf locator for cluster named "castor.example.com"
+storage.root=castor domain=cloudstack zeroconf=castor.example.com
+
+
+
+
+
+
+
+
+ Create the tenant domain within the CAStor storage cluster. If you omit this step before attempting to store content, you will get HTTP 412 errors in the awsapi.log.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/change-console-proxy-ssl-certificate-domain.xml b/docs/tmp/en-US/xml/change-console-proxy-ssl-certificate-domain.xml
new file mode 100644
index 00000000000..268e82a569c
--- /dev/null
+++ b/docs/tmp/en-US/xml/change-console-proxy-ssl-certificate-domain.xml
@@ -0,0 +1,114 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Changing the Console Proxy SSL Certificate and Domain
+
+ If the administrator prefers, it is possible for the URL of the customer's console session to show a domain other than realhostip.com. The administrator can customize the displayed domain by selecting a different domain and uploading a new SSL certificate and private key. The domain must run a DNS service that is capable of resolving queries for addresses of the form aaa-bbb-ccc-ddd.your.domain to an IPv4 IP address in the form aaa.bbb.ccc.ddd, for example, 202.8.44.1. To change the console proxy domain, SSL certificate, and private key:
+
+
+
+
+ Set up dynamic name resolution or populate all possible DNS names in your public IP range into your existing DNS server with the format aaa-bbb-ccc-ddd.company.com -> aaa.bbb.ccc.ddd.
+
+
+
+
+ Generate the private key and certificate signing request (CSR). When you are using openssl to generate private/public key pairs and CSRs, for the private key that you are going to paste into the &PRODUCT; UI, be sure to convert it into PKCS#8 format.
+
+
+
+
+ Generate a new 2048-bit private key
+
+
+openssl genrsa -des3 -out yourprivate.key 2048
+
+
+
+ Generate a new certificate CSR
+
+
+openssl req -new -key yourprivate.key -out yourcertificate.csr
+
+
+
+ Head to the website of your favorite trusted Certificate Authority, purchase an SSL certificate, and submit the CSR. You should receive a valid certificate in return
+
+
+
+
+ Convert your private key format into PKCS#8 encrypted format.
+
+
+openssl pkcs8 -topk8 -in yourprivate.key -out yourprivate.pkcs8.encryped.key
+
+
+
+ Convert your PKCS#8 encrypted private key into the PKCS#8 format that is compliant with &PRODUCT;
+
+
+openssl pkcs8 -in yourprivate.pkcs8.encrypted.key -out yourprivate.pkcs8.key
+
+
+
+
+
+
+
+ In the Update SSL Certificate screen of the &PRODUCT; UI, paste the following
+
+
+
+
+ Certificate from step 1(c).
+
+
+
+
+ Private key from step 1(e).
+
+
+
+
+ The desired new domain name; for example, company.com
+
+
+
+
+
+
+
+
+ The desired new domain name; for example, company.com
+
+
+ This stops all currently running console proxy VMs, then restarts them with the new certificate and key. Users might notice a brief interruption in console availability
+
+
+
+
+
+ The Management Server will generate URLs of the form "aaa-bbb-ccc-ddd.company.com" after this change is made. New console requests will be served with the new DNS domain name, certificate, and key
+
+
+
+
diff --git a/docs/tmp/en-US/xml/change-database-config.xml b/docs/tmp/en-US/xml/change-database-config.xml
new file mode 100644
index 00000000000..e088da9eb62
--- /dev/null
+++ b/docs/tmp/en-US/xml/change-database-config.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Changing the Database Configuration
+
+ The &PRODUCT; Management Server stores database configuration information (e.g., hostname, port, credentials) in the file /etc/cloud/management/db.properties. To effect a change, edit this file on each Management Server, then restart the Management Server.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/change-host-password.xml b/docs/tmp/en-US/xml/change-host-password.xml
new file mode 100644
index 00000000000..db13677c14f
--- /dev/null
+++ b/docs/tmp/en-US/xml/change-host-password.xml
@@ -0,0 +1,67 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; 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:
+
+
+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".
+
+
+mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/change-network-offering-on-guest-network.xml b/docs/tmp/en-US/xml/change-network-offering-on-guest-network.xml
new file mode 100644
index 00000000000..6bde9ec91e8
--- /dev/null
+++ b/docs/tmp/en-US/xml/change-network-offering-on-guest-network.xml
@@ -0,0 +1,83 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Changing the Network Offering on a Guest Network
+
+ A user or administrator can change the network offering that is associated with an existing guest network.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+ If you are changing from a network offering that uses the &PRODUCT; virtual router to one that uses external devices as network service providers, you must first stop all the VMs on the network. See Stopping and Starting VMs. Then return here and continue to the next step
+
+
+
+
+ In the left navigation, choose Network
+
+
+
+
+ Click the name of the network you want to modify
+
+
+
+
+
+ AttachDiskButton.png: button to attach a volume
+
+
+
+ .
+
+
+
+
+ In Network Offering, choose the new network offering, then click Apply.
+
+
+
+
+ A prompt appears asking whether you want to keep the existing CIDR. This is to let you know that if you change the network offering, the CIDR will be affected. Choose No to proceed with the change.
+
+
+
+
+ Wait for the update to complete. Don’t try to restart VMs until after the network change is complete.
+
+
+
+
+ If you stopped any VMs in step 2, restart them.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/change-to-behavior-of-list-commands.xml b/docs/tmp/en-US/xml/change-to-behavior-of-list-commands.xml
new file mode 100644
index 00000000000..deafa93104e
--- /dev/null
+++ b/docs/tmp/en-US/xml/change-to-behavior-of-list-commands.xml
@@ -0,0 +1,190 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Change to Behavior of List Commands
+
+ There was a major change in how our List* API commands work in CloudStack 3.0 compared to 2.2.x. The rules below apply only for managed resources – those that belong to an account, domain, or project. They are irrelevant for the List* commands displaying unmanaged (system) resources, such as hosts, clusters, and external network resources.
+
+
+ When no parameters are passed in to the call, the caller sees only resources owned by the caller (even when the caller is the administrator). Previously, the administrator saw everyone else's resources by default.
+
+
+ When accountName and domainId are passed in:
+
+
+
+
+ The caller sees the resources dedicated to the account specified.
+
+
+
+
+
+ If the call is executed by a regular user, the user is authorized to specify only the user's own account and domainId.
+
+
+
+
+
+ If the caller is a domain administrator, CloudStack performs an authorization check to see whether the caller is permitted to view resources for the given account and domainId.
+
+
+
+
+
+
+ When projectId is passed in, only resources belonging to that project are listed.
+
+
+ When domainId is passed in, the call returns only resources belonging to the domain specified. To see the resources of subdomains, use the parameter isRecursive=true. Again, the regular user can see only resources owned by that user, the root administrator can list anything, and a domain administrator is authorized to see only resources of the administrator's own domain and subdomains.
+
+
+ To see all resources the caller is authorized to see, except for Project resources, use the parameter listAll=true.
+
+
+ To see all Project resources the caller is authorized to see, use the parameter projectId=-1.
+
+
+ There is one API command that doesn't fall under the rules above completely: the listTemplates command. This command has its own flags defining the list rules:
+
+
+
+
+
+
+
+
+
+ listTemplates Flag
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+ featured
+
+
+
+
+ Returns templates that have been marked as featured and public.
+
+
+
+
+
+
+
+ self
+
+
+
+
+ Returns templates that have been registered or created by the calling user.
+
+
+
+
+
+
+
+ selfexecutable
+
+
+
+
+ Same as self, but only returns templates that are ready to be deployed with.
+
+
+
+
+
+
+
+ sharedexecutable
+
+
+
+
+ Ready templates that have been granted to the calling user by another user.
+
+
+
+
+
+
+
+ executable
+
+
+
+
+ Templates that are owned by the calling user, or public templates, that can be used to deploy a new VM.
+
+
+
+
+
+
+
+ community
+
+
+
+
+ Returns templates that have been marked as public but not featured.
+
+
+
+
+
+
+
+ all
+
+
+
+
+ Returns all templates (only usable by admins).
+
+
+
+
+
+
+
+
+
+
+
+ The &PRODUCT; UI on a general view will display all resources that the logged-in user is authorized to see, except for project resources. To see the project resources, select the project view.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/changed-apicommands-4.0.xml b/docs/tmp/en-US/xml/changed-apicommands-4.0.xml
new file mode 100644
index 00000000000..9dd89ac690b
--- /dev/null
+++ b/docs/tmp/en-US/xml/changed-apicommands-4.0.xml
@@ -0,0 +1,601 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Changed API Commands in 4.0.0-incubating
+
+
+
+
+
+
+
+
+ API Commands
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+ copyTemplate
+
+
+ prepareTemplate
+
+
+ registerTemplate
+
+
+ updateTemplate
+
+
+ createProject
+
+
+ activateProject
+
+
+ suspendProject
+
+
+ updateProject
+
+
+ listProjectAccounts
+
+
+ createVolume
+
+
+ migrateVolume
+
+
+ attachVolume
+
+
+ detachVolume
+
+
+ uploadVolume
+
+
+ createSecurityGroup
+
+
+ registerIso
+
+
+ copyIso
+
+
+ updateIso
+
+
+ createIpForwardingRule
+
+
+ listIpForwardingRules
+
+
+ createLoadBalancerRule
+
+
+ updateLoadBalancerRule
+
+
+ createSnapshot
+
+
+
+
+
+ The commands in this list have a single new response parameter, and no other changes.
+
+
+ New response parameter: tags(*)
+
+
+
+ Many other commands also have the new tags(*) parameter in addition to other changes; those commands are listed separately.
+
+
+
+
+
+
+
+
+
+ rebootVirtualMachine
+
+
+ attachIso
+
+
+ detachIso
+
+
+ listLoadBalancerRuleInstances
+
+
+ resetPasswordForVirtualMachine
+
+
+ changeServiceForVirtualMachine
+
+
+ recoverVirtualMachine
+
+
+ startVirtualMachine
+
+
+ migrateVirtualMachine
+
+
+ deployVirtualMachine
+
+
+ assignVirtualMachine
+
+
+ updateVirtualMachine
+
+
+ restoreVirtualMachine
+
+
+ stopVirtualMachine
+
+
+ destroyVirtualMachine
+
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+
+
+
+
+ listSecurityGroups
+
+
+ listFirewallRules
+
+
+ listPortForwardingRules
+
+
+ listSnapshots
+
+
+ listIsos
+
+
+ listProjects
+
+
+ listTemplates
+
+
+ listLoadBalancerRules
+
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: tags (optional)
+
+
+ New response parameter: tags(*)
+
+
+
+
+
+
+
+
+ listF5LoadBalancerNetworks
+
+
+ listNetscalerLoadBalancerNetworks
+
+
+ listSrxFirewallNetworks
+
+
+ updateNetwork
+
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+
+
+
+
+ createZone
+
+
+ updateZone
+
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: localstorageenabled (optional)
+
+
+ New response parameter: localstorageenabled
+
+
+
+
+
+
+
+
+ listZones
+
+
+
+
+ New response parameter: localstorageenabled
+
+
+
+
+
+
+
+ rebootRouter
+
+
+ changeServiceForRouter
+
+
+ startRouter
+
+
+ destroyRouter
+
+
+ stopRouter
+
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+
+
+
+
+ updateAccount
+
+
+ disableAccount
+
+
+ listAccounts
+
+
+ markDefaultZoneForAccount
+
+
+ enableAccount
+
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: vpcavailable, vpclimit, vpctotal
+
+
+
+
+
+
+
+ listRouters
+
+
+
+
+ New request parameters: forvpc (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+
+
+
+
+
+ listNetworkOfferings
+
+
+
+
+ New request parameters: forvpc (optional)
+
+
+ New response parameters: forvpc
+
+
+
+
+
+
+
+
+ listVolumes
+
+
+
+
+ New request parameters: details (optional), tags (optional)
+
+
+ New response parameters: tags(*)
+
+
+
+
+
+
+
+
+ addTrafficMonitor
+
+
+
+
+ New request parameters: excludezones (optional), includezones (optional)
+
+
+
+
+
+
+
+
+ createNetwork
+
+
+
+
+ New request parameters: vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+
+
+
+
+ listPublicIpAddresses
+
+
+
+
+ New request parameters: tags (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+
+
+
+
+ listNetworks
+
+
+
+
+ New request parameters: canusefordeploy (optional), forvpc (optional), tags (optional), vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+
+
+
+
+ restartNetwork
+
+
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+
+
+
+
+ enableStaticNat
+
+
+
+
+ New request parameter: networkid (optional)
+
+
+
+
+
+
+
+
+ createDiskOffering
+
+
+
+
+ New request parameter: storagetype (optional)
+
+
+ New response parameter: storagetype
+
+
+
+
+
+
+
+
+ listDiskOfferings
+
+
+
+
+ New response parameter: storagetype
+
+
+
+
+
+
+
+
+ updateDiskOffering
+
+
+
+
+ New response parameter: storagetype
+
+
+
+
+
+
+
+
+ createFirewallRule
+
+
+
+
+ Changed request parameters: ipaddressid (old version - optional, new version - required)
+
+
+ New response parameter: tags(*)
+
+
+
+
+
+
+
+
+ listVirtualMachines
+
+
+
+
+ New request parameters: isoid (optional), tags (optional), templateid (optional)
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+
+
+
+
+ updateStorageNetworkIpRange
+
+
+
+
+ New response parameters: id, endip, gateway, netmask, networkid, podid, startip, vlan, zoneid
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/changing-root-password.xml b/docs/tmp/en-US/xml/changing-root-password.xml
new file mode 100644
index 00000000000..e6f0a046f01
--- /dev/null
+++ b/docs/tmp/en-US/xml/changing-root-password.xml
@@ -0,0 +1,85 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; 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 &PRODUCT;, 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:
+
+
+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.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/changing-secondary-storage-ip.xml b/docs/tmp/en-US/xml/changing-secondary-storage-ip.xml
new file mode 100644
index 00000000000..555e1ea7d8f
--- /dev/null
+++ b/docs/tmp/en-US/xml/changing-secondary-storage-ip.xml
@@ -0,0 +1,52 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Making API Requests
+
+ You can change the secondary storage IP address after it has been provisioned. After changing the IP address on the host, log in to your management server and execute the following commands. Replace HOSTID below with your own value, and change the URL to use the appropriate IP address and path for your server:
+
+
+
+ # mysql -p
+ mysql> use cloud;
+ mysql> select id from host where type = 'SecondaryStorage';
+ mysql> update host_details set value = 'nfs://192.168.160.20/export/mike-ss1'
+ where host_id = HOSTID and name = 'orig.url';
+ mysql> update host set name = 'nfs://192.168.160.20/export/mike-ss1' where type
+ = 'SecondaryStorage' and id = #;
+ mysql> update host set url = 'nfs://192.168.160.20/export/mike-ss1' where type
+ = 'SecondaryStorage' and id = #;
+ mysql> update host set guid = 'nfs://192.168.160.20/export/mike-ss1' where type
+ = 'SecondaryStorage' and id = #;
+
+
+
+ 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.
+
+
+
+ Then log in to the cloud console UI and stop and start (not reboot) the Secondary Storage VM for that Zone.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/changing-secondary-storage-servers.xml b/docs/tmp/en-US/xml/changing-secondary-storage-servers.xml
new file mode 100644
index 00000000000..2433acbac46
--- /dev/null
+++ b/docs/tmp/en-US/xml/changing-secondary-storage-servers.xml
@@ -0,0 +1,58 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Changing Secondary Storage Servers
+
+ You can change the secondary storage NFS mount. Perform the following steps to do so:
+
+
+
+
+ Stop all running Management Servers.
+
+
+
+
+ Wait 30 minutes. This allows any writes to secondary storage to complete.
+
+
+
+
+ Copy all files from the old secondary storage mount to the new.
+
+
+
+
+ Use the procedure above to change the IP address for secondary storage if required.
+
+
+
+
+ Start the Management Server.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/changing-secondary-storage-serversp.xml b/docs/tmp/en-US/xml/changing-secondary-storage-serversp.xml
new file mode 100644
index 00000000000..2433acbac46
--- /dev/null
+++ b/docs/tmp/en-US/xml/changing-secondary-storage-serversp.xml
@@ -0,0 +1,58 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Changing Secondary Storage Servers
+
+ You can change the secondary storage NFS mount. Perform the following steps to do so:
+
+
+
+
+ Stop all running Management Servers.
+
+
+
+
+ Wait 30 minutes. This allows any writes to secondary storage to complete.
+
+
+
+
+ Copy all files from the old secondary storage mount to the new.
+
+
+
+
+ Use the procedure above to change the IP address for secondary storage if required.
+
+
+
+
+ Start the Management Server.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/changing-service-offering-for-vm.xml b/docs/tmp/en-US/xml/changing-service-offering-for-vm.xml
new file mode 100644
index 00000000000..6597596001f
--- /dev/null
+++ b/docs/tmp/en-US/xml/changing-service-offering-for-vm.xml
@@ -0,0 +1,88 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Changing the Service Offering for a VM
+
+ To upgrade or downgrade the level of compute resources available to a virtual machine, you can change the VM's compute offering.
+
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+ In the left navigation, click Instances.
+
+
+
+
+ Choose the VM that you want to work with.
+
+
+
+
+ Click the Stop button to stop the VM
+
+
+
+
+
+ StopButton.png: button to stop a VM
+
+
+
+
+
+
+
+
+ Click the Change Service button
+
+
+
+
+
+ ChangeServiceButton.png: button to change the service of a VM
+
+
+
+ . The Change service dialog box is displayed.
+
+
+
+
+ Select the offering you want.
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/changing-vm-name-os-group.xml b/docs/tmp/en-US/xml/changing-vm-name-os-group.xml
new file mode 100644
index 00000000000..d0db048165b
--- /dev/null
+++ b/docs/tmp/en-US/xml/changing-vm-name-os-group.xml
@@ -0,0 +1,106 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Changing the VM Name, OS, or Group
+
+ After a VM is created, you can modify the display name, operating system, and the group it belongs to.
+
+
+ To access a VM through the &PRODUCT; UI:
+
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+ In the left navigation, click Instances.
+
+
+
+
+ Select the VM that you want to modify.
+
+
+
+
+ Click the Stop button to stop the VM
+
+
+
+
+
+ StopButton.png: button to stop a VM
+
+
+
+
+
+
+
+
+ Click Edit
+
+
+
+
+
+ StopButton.png: button to edit the properties of a VM
+
+
+
+ .
+
+
+
+
+ Make the desired changes to the following:
+
+
+
+
+ Display name: Enter a new display name if you want to change the name of the VM.
+
+
+
+
+ OS Type: Select the desired operating system.
+
+
+
+
+ Group: Enter the group name for the VM.
+
+
+
+
+ Click Apply.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/choosing-a-deployment-architecture.xml b/docs/tmp/en-US/xml/choosing-a-deployment-architecture.xml
new file mode 100644
index 00000000000..cdbf4ec032f
--- /dev/null
+++ b/docs/tmp/en-US/xml/choosing-a-deployment-architecture.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Choosing a Deployment Architecture
+
+ The architecture used in a deployment will vary depending on the size and purpose of the deployment. This section contains examples of deployment architecture, including a small-scale deployment useful for test and trial deployments and a fully-redundant large-scale setup for production deployments.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cisco3750-hardware.xml b/docs/tmp/en-US/xml/cisco3750-hardware.xml
new file mode 100644
index 00000000000..487765713f2
--- /dev/null
+++ b/docs/tmp/en-US/xml/cisco3750-hardware.xml
@@ -0,0 +1,70 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Cisco 3750
+
+ The following steps show how a Cisco 3750 is configured for zone-level layer-3 switching. These steps assume VLAN 201 is used to route untagged private IPs for pod 1, and pod 1’s layer-2 switch is connected to GigabitEthernet1/0/1.
+
+
+
+
+ Setting VTP mode to transparent allows us to utilize VLAN IDs above 1000. Since we only use VLANs up to 999, vtp transparent mode is not strictly required.
+
+
+vtp mode transparent
+vlan 200-999
+exit
+
+
+
+
+ Configure GigabitEthernet1/0/1.
+
+
+interface GigabitEthernet1/0/1
+switchport trunk encapsulation dot1q
+switchport mode trunk
+switchport trunk native vlan 201
+exit
+
+
+
+
+
+ The statements configure GigabitEthernet1/0/1 as follows:
+
+
+
+
+ VLAN 201 is the native untagged VLAN for port GigabitEthernet1/0/1.
+
+
+
+
+
+ Cisco passes all VLANs by default. As a result, all VLANs (300-999) are passed to all the pod-level layer-2 switches.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cisco3750-layer2.xml b/docs/tmp/en-US/xml/cisco3750-layer2.xml
new file mode 100644
index 00000000000..571b5c8bf65
--- /dev/null
+++ b/docs/tmp/en-US/xml/cisco3750-layer2.xml
@@ -0,0 +1,55 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Cisco 3750
+
+ The following steps show how a Cisco 3750 is configured for pod-level layer-2 switching.
+
+
+
+
+ Setting VTP mode to transparent allows us to utilize VLAN IDs above 1000. Since we only use VLANs up to 999, vtp transparent mode is not strictly required.
+
+
+vtp mode transparent
+vlan 300-999
+exit
+
+
+
+
+ Configure all ports to dot1q and set 201 as the native VLAN.
+
+
+interface range GigabitEthernet 1/0/1-24
+switchport trunk encapsulation dot1q
+switchport mode trunk
+switchport trunk native vlan 201
+exit
+
+
+
+
+
+ By default, Cisco passes all VLANs. Cisco switches complain of the native VLAN IDs are different when 2 ports are connected together. That’s why you must specify VLAN 201 as the native VLAN on the layer-2 switch.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/citrix-xenserver-installation.xml b/docs/tmp/en-US/xml/citrix-xenserver-installation.xml
new file mode 100644
index 00000000000..4dbbc285953
--- /dev/null
+++ b/docs/tmp/en-US/xml/citrix-xenserver-installation.xml
@@ -0,0 +1,1174 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Citrix XenServer Installation for &PRODUCT;
+
+ If you want to use the Citrix XenServer hypervisor to run guest virtual machines, install XenServer 6.0 or XenServer 6.0.2 on the host(s) in your cloud. For an initial installation, follow the steps below. If you have previously installed XenServer and want to upgrade to another version, see .
+
+
+ System Requirements for XenServer Hosts
+
+
+
+ The host must be certified as compatible with one of the following. See the Citrix Hardware Compatibility Guide: http://hcl.xensource.com
+
+
+
+
+ XenServer 5.6 SP2
+
+
+
+
+
+ XenServer 6.0
+
+
+
+
+
+ XenServer 6.0.2
+
+
+
+
+
+
+
+
+
+ You must re-install Citrix XenServer if you are going to re-use a host from a previous install.
+
+
+
+
+
+ Must support HVM (Intel-VT or AMD-V enabled)
+
+
+
+
+
+ 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. &PRODUCT; 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.
+
+
+
+
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+
+
+
+
+ Must support HVM (Intel-VT or AMD-V enabled in BIOS)
+
+
+
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+
+
+
+
+ Hardware virtualization support required
+
+
+
+
+
+ 4 GB of memory
+
+
+
+
+
+ 36 GB of local disk
+
+
+
+
+
+ At least 1 NIC
+
+
+
+
+
+ Statically allocated IP Address
+
+
+
+
+
+ When you deploy &PRODUCT;, the hypervisor host must not have any VMs already running
+
+
+
+
+
+
+
+ The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+
+
+
+
+
+
+
+ XenServer Installation Steps
+
+
+
+ From https://www.citrix.com/English/ss/downloads/, download the appropriate version of XenServer for your &PRODUCT; version (see ). Install it using the Citrix XenServer Installation Guide.
+
+
+
+
+
+ After installation, perform the following configuration steps, which are described in the next few sections:
+
+
+
+
+
+
+
+
+
+ Required
+
+
+
+
+ Optional
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Set up SR if not using NFS, iSCSI, or local disk; see
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Configure XenServer dom0 Memory
+
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see http://support.citrix.com/article/CTX126531. The article refers to XenServer 5.6, but the same information applies to XenServer 6.0.
+
+
+
+
+
+ Username and Password
+
+ All XenServers in a cluster must have the same username and password as configured in &PRODUCT;.
+
+
+
+
+
+ Time Synchronization
+
+ The host must be set to use NTP. All hosts in a pod must have the same time.
+
+
+
+
+ Install NTP.
+
+
+# yum install ntp
+
+
+
+
+ Edit the NTP configuration file to point to your NTP server.
+
+
+# vi /etc/ntp.conf
+
+ Add one or more server lines in this file with the names of the NTP servers you want to use. For example:
+
+
+server 0.xenserver.pool.ntp.org
+server 1.xenserver.pool.ntp.org
+server 2.xenserver.pool.ntp.org
+server 3.xenserver.pool.ntp.org
+
+
+
+
+
+ Restart the NTP client.
+
+
+# service ntpd restart
+
+
+
+
+ Make sure NTP will start again upon reboot.
+
+
+# chkconfig ntpd on
+
+
+
+
+
+
+
+
+ Licensing
+
+ Citrix XenServer Free version provides 30 days usage without a license. Following the 30 day trial, XenServer requires a free activation and license. You can choose to install a license now or skip this step. If you skip this step, you will need to install a license when you activate and license the XenServer.
+
+
+ Getting and Deploying a License
+
+ If you choose to install a license now you will need to use the XenCenter to activate and get a license.
+
+
+
+
+ In XenCenter, click Tools > License manager.
+
+
+
+
+
+ Select your XenServer and select Activate Free XenServer.
+
+
+
+
+
+ Request a license.
+
+
+
+
+
+
+ You can install the license with XenCenter or using the xe command line tool.
+
+
+
+
+
+
+
+
+ Install &PRODUCT; XenServer Support Package (CSP)
+
+ (Optional)
+
+
+ To enable security groups, elastic load balancing, and elastic IP on XenServer, download and install the &PRODUCT; XenServer Support Package (CSP). After installing XenServer, perform the following additional steps on each XenServer host.
+
+
+
+
+ Download the CSP software onto the XenServer host from one of the following links:
+
+
+ For XenServer 6.0.2:
+
+
+ http://download.cloud.com/releases/3.0.1/XS-6.0.2/xenserver-cloud-supp.tgz
+
+
+ For XenServer 5.6 SP2:
+
+
+ http://download.cloud.com/releases/2.2.0/xenserver-cloud-supp.tgz
+
+
+ For XenServer 6.0:
+
+
+ http://download.cloud.com/releases/3.0/xenserver-cloud-supp.tgz
+
+
+
+
+
+ Extract the file:
+
+
+# tar xf xenserver-cloud-supp.tgz
+
+
+
+
+ Run the following script:
+
+
+# xe-install-supplemental-pack xenserver-cloud-supp.iso
+
+
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
+
+# xe-switch-network-backend bridge
+
+ Restart the host machine when prompted.
+
+
+
+
+
+
+ The XenServer host is now ready to be added to &PRODUCT;.
+
+
+
+
+
+ Primary Storage Setup for XenServer
+
+ &PRODUCT; natively supports NFS, iSCSI and local storage. If you are using one of these storage types, there is no need to create the XenServer Storage Repository ("SR").
+
+
+ If, however, you would like to use storage connected via some other technology, such as FiberChannel, you must set up the SR yourself. To do so, perform the following steps. If you have your hosts in a XenServer pool, perform the steps on the master node. If you are working with a single XenServer which is not part of a cluster, perform the steps on that XenServer.
+
+
+
+
+ Connect FiberChannel cable to all hosts in the cluster and to the FiberChannel storage host.
+
+
+
+
+
+ Rescan the SCSI bus. Either use the following command or use XenCenter to perform an HBA rescan.
+
+
+# scsi-rescan
+
+
+
+
+ Repeat step 2 on every host.
+
+
+
+
+
+ Check to be sure you see the new SCSI disk.
+
+
+# ls /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -l
+
+ The output should look like this, although the specific file name will be different (scsi-<scsiID>):
+
+
+lrwxrwxrwx 1 root root 9 Mar 16 13:47
+/dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -> ../../sdc
+
+
+
+
+
+ Repeat step 4 on every host.
+
+
+
+
+
+ On the storage server, run this command to get a unique ID for the new SR.
+
+
+# uuidgen
+
+ The output should look like this, although the specific ID will be different:
+
+
+e6849e96-86c3-4f2c-8fcc-350cc711be3d
+
+
+
+
+ Create the FiberChannel SR. In name-label, use the unique ID you just generated.
+
+
+
+# xe sr-create type=lvmohba shared=true
+device-config:SCSIid=360a98000503365344e6f6177615a516b
+name-label="e6849e96-86c3-4f2c-8fcc-350cc711be3d"
+
+
+ This command returns a unique ID for the SR, like the following example (your ID will be different):
+
+
+7a143820-e893-6c6a-236e-472da6ee66bf
+
+
+
+
+ To create a human-readable description for the SR, use the following command. In uuid, use the SR ID returned by the previous command. In name-description, set whatever friendly text you prefer.
+
+
+# xe sr-param-set uuid=7a143820-e893-6c6a-236e-472da6ee66bf name-description="Fiber Channel storage repository"
+
+ Make note of the values you will need when you add this storage to &PRODUCT; later (see ). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the name-label you set earlier (in this example, e6849e96-86c3-4f2c-8fcc-350cc711be3d).
+
+
+
+
+
+ (Optional) If you want to enable multipath I/O on a FiberChannel SAN, refer to the documentation provided by the SAN vendor.
+
+
+
+
+
+
+
+
+
+ iSCSI Multipath Setup for XenServer (Optional)
+
+ When setting up the storage repository on a Citrix XenServer, you can enable multipath I/O, which uses redundant physical components to provide greater reliability in the connection between the server and the SAN. To enable multipathing, use a SAN solution that is supported for Citrix servers and follow the procedures in Citrix documentation. The following links provide a starting point:
+
+
+
+
+ http://support.citrix.com/article/CTX118791
+
+
+
+
+
+ http://support.citrix.com/article/CTX125403
+
+
+
+
+
+
+ You can also ask your SAN vendor for advice about setting up your Citrix repository for multipathing.
+
+
+ Make note of the values you will need when you add this storage to the &PRODUCT; later (see ). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the same name used to create the SR.
+
+
+ If you encounter difficulty, address the support team for the SAN provided by your vendor. If they are not able to solve your issue, see Contacting Support.
+
+
+
+
+
+ Physical Networking Setup for XenServer
+
+ Once XenServer has been installed, you may need to do some additional network configuration. At this point in the installation, you should have a plan for what NICs the host will have and what traffic each NIC will carry. The NICs should be cabled as necessary to implement your plan.
+
+
+ If you plan on using NIC bonding, the NICs on all hosts in the cluster must be cabled exactly the same. For example, if eth0 is in the private bond on one host in a cluster, then eth0 must be in the private bond on all hosts in the cluster.
+
+
+ The IP address assigned for the management network interface must be static. It can be set on the host itself or obtained via static DHCP.
+
+
+ &PRODUCT; configures network traffic of various types to use different NICs or bonds on the XenServer host. You can control this process and provide input to the Management Server through the use of XenServer network name labels. The name labels are placed on physical interfaces or bonds and configured in &PRODUCT;. In some simple cases the name labels are not required.
+
+
+ Configuring Public Network with a Dedicated NIC for XenServer (Optional)
+
+ &PRODUCT; supports the use of a second NIC (or bonded pair of NICs, described in ) for the public network. If bonding is not used, the public network can be on any NIC and can be on different NICs on the hosts in a cluster. For example, the public network can be on eth0 on node A and eth1 on node B. However, the XenServer name-label for the public network must be identical across all hosts. The following examples set the network label to "cloud-public". After the management server is installed and running you must configure it with the name of the chosen network label (e.g. "cloud-public"); this is discussed in .
+
+
+ If you are using two NICs bonded together to create a public network, see .
+
+
+ If you are using a single dedicated NIC to provide public network access, follow this procedure on each new host that is added to &PRODUCT; before adding the host.
+
+
+
+
+ Run xe network-list and find the public network. This is usually attached to the NIC that is public. Once you find the network make note of its UUID. Call this <UUID-Public>.
+
+
+
+
+
+ Run the following command.
+
+
+# xe network-param-set name-label=cloud-public uuid=<UUID-Public>
+
+
+
+
+
+
+
+
+ Configuring Multiple Guest Networks for XenServer (Optional)
+
+ &PRODUCT; supports the use of multiple guest networks with the XenServer hypervisor. Each network is assigned a name-label in XenServer. For example, you might have two networks with the labels "cloud-guest" and "cloud-guest2". After the management server is installed and running, you must add the networks and use these labels so that &PRODUCT; is aware of the networks.
+
+
+ Follow this procedure on each new host before adding the host to &PRODUCT;:
+
+
+
+
+ Run xe network-list and find one of the guest networks. Once you find the network make note of its UUID. Call this <UUID-Guest>.
+
+
+
+
+
+ Run the following command, substituting your own name-label and uuid values.
+
+
+# xe network-param-set name-label=<cloud-guestN> uuid=<UUID-Guest>
+
+
+
+
+ Repeat these steps for each additional guest network, using a different name-label and uuid each time.
+
+
+
+
+
+
+
+
+
+ Separate Storage Network for XenServer (Optional)
+
+ You can optionally set up a separate storage network. This should be done first on the host, before implementing the bonding steps below. This can be done using one or two available NICs. With two NICs bonding may be done as above. It is the administrator's responsibility to set up a separate storage network.
+
+
+ Give the storage network a different name-label than what will be given for other networks.
+
+
+ For the separate storage network to work correctly, it must be the only interface that can ping the primary storage device's IP address. For example, if eth0 is the management network NIC, ping -I eth0 <primary storage device IP> must fail. In all deployments, secondary storage devices must be pingable from the management network NIC or bond. If a secondary storage device has been placed on the storage network, it must also be pingable via the storage network NIC or bond on the hosts as well.
+
+
+ You can set up two separate storage networks as well. For example, if you intend to implement iSCSI multipath, dedicate two non-bonded NICs to multipath. Each of the two networks needs a unique name-label.
+
+
+ If no bonding is done, the administrator must set up and name-label the separate storage network on all hosts (masters and slaves).
+
+
+ Here is an example to set up eth5 to access a storage network on 172.16.0.0/24.
+
+
+
+# xe pif-list host-name-label='hostname' device=eth5
+uuid(RO): ab0d3dd4-5744-8fae-9693-a022c7a3471d
+device ( RO): eth5
+#xe pif-reconfigure-ip DNS=172.16.3.3 gateway=172.16.0.1 IP=172.16.0.55 mode=static netmask=255.255.255.0 uuid=ab0d3dd4-5744-8fae-9693-a022c7a3471d
+
+
+
+
+ NIC Bonding for XenServer (Optional)
+
+ XenServer supports Source Level Balancing (SLB) NIC bonding. Two NICs can be bonded together to carry public, private, and guest traffic, or some combination of these. Separate storage networks are also possible. Here are some example supported configurations:
+
+
+
+
+ 2 NICs on private, 2 NICs on public, 2 NICs on storage
+
+
+
+
+
+ 2 NICs on private, 1 NIC on public, storage uses management network
+
+
+
+
+
+ 2 NICs on private, 2 NICs on public, storage uses management network
+
+
+
+
+
+ 1 NIC for private, public, and storage
+
+
+
+
+
+
+ All NIC bonding is optional.
+
+
+ XenServer expects all nodes in a cluster will have the same network cabling and same bonds implemented. In an installation the master will be the first host that was added to the cluster and the slave hosts will be all subsequent hosts added to the cluster. The bonds present on the master set the expectation for hosts added to the cluster later. The procedure to set up bonds on the master and slaves are different, and are described below. There are several important implications of this:
+
+
+
+
+ You must set bonds on the first host added to a cluster. Then you must use xe commands as below to establish the same bonds in the second and subsequent hosts added to a cluster.
+
+
+
+
+
+ Slave hosts in a cluster must be cabled exactly the same as the master. For example, if eth0 is in the private bond on the master, it must be in the management network for added slave hosts.
+
+
+
+
+
+
+ Management Network Bonding
+
+ The administrator must bond the management network NICs prior to adding the host to &PRODUCT;.
+
+
+
+
+
+ Creating a Private Bond on the First Host in the Cluster
+
+ Use the following steps to create a bond in XenServer. These steps should be run on only the first host in a cluster. This example creates the cloud-private network with two physical NICs (eth0 and eth1) bonded into it.
+
+
+
+
+ Find the physical NICs that you want to bond together.
+
+
+# xe pif-list host-name-label='hostname' device=eth0
+# xe pif-list host-name-label='hostname' device=eth1
+
+ These command shows the eth0 and eth1 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
+
+
+
+
+
+ Create a new network for the bond. For example, a new network with name "cloud-private".
+
+
+ This label is important. &PRODUCT; looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the management network.
+
+
+# xe network-create name-label=cloud-private
+# xe bond-create network-uuid=[uuid of cloud-private created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+
+
+
+
+
+ Now you have a bonded pair that can be recognized by &PRODUCT; as the management network.
+
+
+
+
+
+ Public Network Bonding
+
+ Bonding can be implemented on a separate, public network. The administrator is responsible for creating a bond for the public network if that network will be bonded and will be separate from the management network.
+
+
+
+
+
+ Creating a Public Bond on the First Host in the Cluster
+
+ These steps should be run on only the first host in a cluster. This example creates the cloud-public network with two physical NICs (eth2 and eth3) bonded into it.
+
+
+
+
+ Find the physical NICs that you want to bond together.
+
+
+#xe pif-list host-name-label='hostname' device=eth2
+# xe pif-list host-name-label='hostname' device=eth3
+
+ These command shows the eth2 and eth3 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
+
+
+
+
+
+ Create a new network for the bond. For example, a new network with name "cloud-public".
+
+
+ This label is important. &PRODUCT; looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the public network.
+
+
+# xe network-create name-label=cloud-public
+# xe bond-create network-uuid=[uuid of cloud-public created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+
+
+
+
+
+ Now you have a bonded pair that can be recognized by &PRODUCT; as the public network.
+
+
+
+
+
+ Adding More Hosts to the Cluster
+
+ With the bonds (if any) established on the master, you should add additional, slave hosts. Run the following command for all additional hosts to be added to the cluster. This will cause the host to join the master in a single XenServer pool.
+
+
+# xe pool-join master-address=[master IP] master-username=root
+master-password=[your password]
+
+
+
+
+ Complete the Bonding Setup Across the Cluster
+
+ With all hosts added to the pool, run the cloud-setup-bond script. This script will complete the configuration and set up of the bonds across all hosts in the cluster.
+
+
+
+
+ Copy the script from the Management Server in /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+
+
+
+
+
+ Run the script:
+
+
+# ./cloud-setup-bonding.sh
+
+
+
+
+
+ Now the bonds are set up and configured properly across the cluster.
+
+
+
+
+
+
+
+
+
+
+
+ Upgrading XenServer Versions
+
+ This section tells how to upgrade XenServer software on &PRODUCT; hosts. The actual upgrade is described in XenServer documentation, but there are some additional steps you must perform before and after the upgrade.
+
+
+
+ Be sure the hardware is certified compatible with the new version of XenServer.
+
+
+
+
+ To upgrade XenServer:
+
+
+
+
+ Upgrade the database. On the Management Server node:
+
+
+
+
+ Back up the database:
+
+
+# mysqldump --user=root --databases cloud > cloud.backup.sql
+# mysqldump --user=root --databases cloud_usage > cloud_usage.backup.sql
+
+
+
+
+ You might need to change the OS type settings for VMs running on the upgraded hosts.
+
+
+
+
+ If you upgraded from XenServer 5.6 GA to XenServer 5.6 SP2, change any VMs that have the OS type CentOS 5.5 (32-bit), Oracle Enterprise Linux 5.5 (32-bit), or Red Hat Enterprise Linux 5.5 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit).
+
+
+
+
+
+ If you upgraded from XenServer 5.6 SP2 to XenServer 6.0.2, change any VMs that have the OS type CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux 5.6 (32-bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.6 (32-bit) , or Red Hat Enterprise Linux 5.7 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit).
+
+
+
+
+
+ If you upgraded from XenServer 5.6 to XenServer 6.0.2, do all of the above.
+
+
+
+
+
+
+
+
+
+ Restart the Management Server and Usage Server. You only need to do this once for all clusters.
+
+
+# service cloud-management start
+# service cloud-usage start
+
+
+
+
+
+
+
+
+ Disconnect the XenServer cluster from &PRODUCT;.
+
+
+
+
+ Log in to the &PRODUCT; UI as root.
+
+
+
+
+
+ Navigate to the XenServer cluster, and click Actions – Unmanage.
+
+
+
+
+
+ Watch the cluster status until it shows Unmanaged.
+
+
+
+
+
+
+
+
+
+ Log in to one of the hosts in the cluster, and run this command to clean up the VLAN:
+
+
+# . /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+
+
+ Still logged in to the host, run the upgrade preparation script:
+
+
+# /opt/xensource/bin/cloud-prepare-upgrade.sh
+
+ Troubleshooting: If you see the error "can't eject CD," log in to the VM and umount the CD, then run the script again.
+
+
+
+
+
+ Upgrade the XenServer software on all hosts in the cluster. Upgrade the master first.
+
+
+
+
+ Live migrate all VMs on this host to other hosts. See the instructions for live migration in the Administrator's Guide.
+
+
+ Troubleshooting: You might see the following error when you migrate a VM:
+
+
+[root@xenserver-qa-2-49-4 ~]# xe vm-migrate live=true host=xenserver-qa-2-49-5 vm=i-2-8-VM
+You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected.
+vm: b6cf79c8-02ee-050b-922f-49583d9f1a14 (i-2-8-VM)
+
+ To solve this issue, run the following:
+
+
+# /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14
+
+
+
+
+ Reboot the host.
+
+
+
+
+
+ Upgrade to the newer version of XenServer. Use the steps in XenServer documentation.
+
+
+
+
+
+ After the upgrade is complete, copy the following files from the management server to this host, in the directory locations shown below:
+
+
+
+
+
+
+
+
+
+ Copy this Management Server file...
+
+
+
+
+ ...to this location on the XenServer host
+
+
+
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-clean-vlan.sh
+
+
+
+
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Run the following script:
+
+
+# /opt/xensource/bin/setupxenserver.sh
+
+ Troubleshooting: If you see the following error message, you can safely ignore it.
+
+
+mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory
+
+
+
+
+ Plug in the storage repositories (physical block devices) to the XenServer host:
+
+
+# for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; done
+
+ Note: If you add a host to this XenServer pool, you need to migrate all VMs on this host to other hosts, and eject this host from XenServer pool.
+
+
+
+
+
+
+
+
+
+ Repeat these steps to upgrade every host in the cluster to the same version of XenServer.
+
+
+
+
+
+ Run the following command on one host in the XenServer cluster to clean up the host tags:
+
+
+# for host in $(xe host-list | grep ^uuid | awk '{print $NF}') ; do xe host-param-clear uuid=$host param-name=tags; done;
+
+
+ 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.
+
+
+
+
+
+
+
+ Reconnect the XenServer cluster to &PRODUCT;.
+
+
+
+
+ Log in to the &PRODUCT; UI as root.
+
+
+
+
+
+ Navigate to the XenServer cluster, and click Actions – Manage.
+
+
+
+
+
+ Watch the status to see that all the hosts come up.
+
+
+
+
+
+
+
+
+
+ After all hosts are up, run the following on one host in the cluster:
+
+
+# /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloud-infrastructure-concepts.xml b/docs/tmp/en-US/xml/cloud-infrastructure-concepts.xml
new file mode 100644
index 00000000000..867baec24c3
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloud-infrastructure-concepts.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Cloud Infrastructure Concepts
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloud-infrastructure-overview.xml b/docs/tmp/en-US/xml/cloud-infrastructure-overview.xml
new file mode 100644
index 00000000000..564bc5b12ee
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloud-infrastructure-overview.xml
@@ -0,0 +1,82 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Cloud Infrastructure Overview
+
+ The Management Server manages one or more zones (typically, datacenters) containing host computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
+
+
+
+
+ Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods and secondary storage.
+
+
+
+
+
+ Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
+
+
+
+
+
+ Cluster: A cluster consists of one or more hosts and primary storage.
+
+
+
+
+
+ Host: A single compute node within a cluster. The hosts are where the actual cloud services run in the form of guest virtual machines.
+
+
+
+
+
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster.
+
+
+
+
+ Secondary storage is associated with a zone, and it stores templates, ISO images, and disk volume snapshots.
+
+
+
+
+
+
+
+
+
+
+ infrastructure_overview.png: Nested organization of a zone
+
+
+
+
+ More Information
+
+
+ For more information, see documentation on cloud infrastructure concepts.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudplatform-api.xml b/docs/tmp/en-US/xml/cloudplatform-api.xml
new file mode 100644
index 00000000000..dd6856544b7
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudplatform-api.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ &PRODUCT; API
+
+ The &PRODUCT; API is a low level API that has been used to implement the &PRODUCT; web UIs. It is also a good basis for implementing other popular APIs such as EC2/S3 and emerging DMTF standards.
+
+
+ Many &PRODUCT; 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 and the API Reference.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack-admin.xml b/docs/tmp/en-US/xml/cloudstack-admin.xml
new file mode 100644
index 00000000000..c3843061602
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack-admin.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack.ent b/docs/tmp/en-US/xml/cloudstack.ent
new file mode 100644
index 00000000000..abb18851bcf
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack.xml b/docs/tmp/en-US/xml/cloudstack.xml
new file mode 100644
index 00000000000..4eba67adc23
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack.xml
@@ -0,0 +1,81 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ &PRODUCT; Complete Documentation
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Complete documentation for &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack_admin.xml b/docs/tmp/en-US/xml/cloudstack_admin.xml
new file mode 100644
index 00000000000..c3843061602
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack_admin.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack_developers.xml b/docs/tmp/en-US/xml/cloudstack_developers.xml
new file mode 100644
index 00000000000..6564a314913
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack_developers.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack_features.xml b/docs/tmp/en-US/xml/cloudstack_features.xml
new file mode 100644
index 00000000000..813bd79868b
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack_features.xml
@@ -0,0 +1,69 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ What Can &PRODUCT; Do?
+
+ Multiple Hypervisor Support
+
+
+ &PRODUCT; works with a variety of hypervisors. A single cloud deployment can contain multiple hypervisor implementations. You have the complete freedom to choose the right hypervisor for your workload. &PRODUCT; is designed to work with open source Xen and KVM hypervisors as well as enterprise-grade hypervisors such as Citrix XenServer, VMware vSphere, and Oracle VM (OVM). You can also provision “bare metal” hosts with no hypervisor (Beta feature. Untested in &PRODUCT; 3.0.x0.)
+
+
+ Massively Scalable Infrastructure Management
+
+
+ &PRODUCT; can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+
+ Automatic Configuration Management
+
+
+ &PRODUCT; automatically configures each guest virtual machine’s networking and storage settings.
+
+
+ &PRODUCT; internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+
+ Graphical User Interface
+
+
+ &PRODUCT; offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+
+ API and Extensibility
+
+
+ &PRODUCT; provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at http://docs.cloud.com/CloudStack_Documentation.
+
+
+ The &PRODUCT; platform pluggable allocation architecture allows the creation of new types of allocators for the selection of storage and Hosts. See the Allocator Implementation Guide (http://docs.cloud.com/CloudStack_Documentation/Allocator_Implementation_Guide).
+
+
+ High Availability
+
+
+ The &PRODUCT; platform has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the Hosts, the &PRODUCT; platform supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack_installation.xml b/docs/tmp/en-US/xml/cloudstack_installation.xml
new file mode 100644
index 00000000000..36a11305889
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack_installation.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack_system_requirements.xml b/docs/tmp/en-US/xml/cloudstack_system_requirements.xml
new file mode 100644
index 00000000000..fa207262080
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack_system_requirements.xml
@@ -0,0 +1,165 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Minimum System Requirements
+
+ The machines that will run the Management Server and MySQL database must meet the following requirements. The same machines can also be used to provide primary and secondary storage, such as via localdisk or NFS. The Management Server may be placed on a virtual machine.
+
+
+
+
+ Operating system:
+
+
+
+
+ Commercial users: Preferred: RHEL 6.2+ 64-bit (https://access.redhat.com/downloads) or CentOS 6.2+ 64-bit (http://isoredirect.centos.org/centos/6/isos/x86_64/). Also supported (v3.0.3 and greater): RHEL and CentOS 5.4-5.x 64-bit
+
+
+
+
+ Open-source community users: RHEL 5.4-5.x 64-bit or 6.2+ 64-bit; CentOS 5.4-5.x 64-bit or 6.2+ 64-bit; Ubuntu 10.04 LTS
+
+
+
+
+
+
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+
+
+
+ 4 GB of memory
+
+
+
+
+ 250 GB of local disk (more results in better capability; 500 GB recommended)
+
+
+
+
+ At least 1 NIC
+
+
+
+
+ Statically allocated IP address
+
+
+
+
+ Fully qualified domain name as returned by the hostname command
+
+
+
+
+
+ The host is where the cloud services run in the form of guest virtual machines. Each host is one machine that meets the following requirements:
+
+
+
+
+ Must be 64-bit and must support HVM (Intel-VT or AMD-V enabled).
+
+
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+
+
+
+ Hardware virtualization support required
+
+
+
+
+ 4 GB of memory
+
+
+
+
+ 36 GB of local disk
+
+
+
+
+ At least 1 NIC
+
+
+
+
+ Statically allocated IP Address
+
+
+
+
+ Latest hotfixes applied to hypervisor software
+
+
+
+
+ When you deploy &PRODUCT;, the hypervisor host must not have any VMs already running
+
+
+
+
+
+ Hosts have additional requirements depending on the hypervisor. See the requirements listed at the top of the Installation section for your chosen hypervisor:
+
+
+
+
+ Citrix XenServer Installation for &PRODUCT;
+
+
+
+
+ VMware vSphere Installation and Configuration
+
+
+
+
+ KVM Installation and Configuration
+
+
+
+
+ Oracle VM (OVM) Installation and Configuration
+
+
+
+
+
+
+ Be sure you fulfill the additional hypervisor requirements and installation steps provided in this Guide. Hypervisor hosts must be properly prepared to work with &PRODUCT;. For example, the requirements for XenServer are listed under Citrix XenServer Installation for &PRODUCT;.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack_trial_installation.xml b/docs/tmp/en-US/xml/cloudstack_trial_installation.xml
new file mode 100644
index 00000000000..a473272b173
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack_trial_installation.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cloudstack_whatis.xml b/docs/tmp/en-US/xml/cloudstack_whatis.xml
new file mode 100644
index 00000000000..bac7076891a
--- /dev/null
+++ b/docs/tmp/en-US/xml/cloudstack_whatis.xml
@@ -0,0 +1,50 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ What Is &PRODUCT;?
+
+ Who Should Read This
+
+
+ If you are new to &PRODUCT; or you want to learn more about concepts before installing and running &PRODUCT;, read this overview. If you just want to get started, you can skip to Overview of Installation Steps.
+
+
+ &PRODUCT; is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. &PRODUCT; manages the network, storage, and compute nodes that make up a cloud infrastructure. Use &PRODUCT; to deploy, manage, and configure cloud computing environments. Typical users are service providers and enterprises. With &PRODUCT;, you can:
+
+
+
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+
+
+
+
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with &PRODUCT; an enterprise can offer self-service virtual machines to users without involving IT departments.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/cluster-add.xml b/docs/tmp/en-US/xml/cluster-add.xml
new file mode 100644
index 00000000000..f07a197ddda
--- /dev/null
+++ b/docs/tmp/en-US/xml/cluster-add.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Cluster
+
+ You need to tell &PRODUCT; 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.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/compatibility-matrix.xml b/docs/tmp/en-US/xml/compatibility-matrix.xml
new file mode 100644
index 00000000000..0bebdba6b43
--- /dev/null
+++ b/docs/tmp/en-US/xml/compatibility-matrix.xml
@@ -0,0 +1,380 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Compatibility Matrix
+
+
+
+
+
+
+ Hypervisor
+
+
+
+
+ CloudStack 2.1.x
+
+
+
+
+ CloudStack 2.2.x
+
+
+
+
+ CloudStack 3.0.0
+
+
+
+
+ CloudStack 3.0.1
+
+
+
+
+ CloudStack 3.0.2
+
+
+
+
+ CloudStack 3.0.3
+
+
+
+
+
+
+
+
+
+
+ XenServer 5.6
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+
+
+
+ XenServer 5.6 FP1
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+
+
+
+ XenServer 5.6 SP2
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+ XenServer 6.0.0
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+ XenServer 6.0.2
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+ XenServer 6.1
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+ No
+
+
+
+
+
+
+
+ KVM (RHEL 6.0 or 6.1)
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+ VMware (vSphere and vCenter, both version 4.1)
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/compute-disk-service-offerings.xml b/docs/tmp/en-US/xml/compute-disk-service-offerings.xml
new file mode 100644
index 00000000000..007d4ed2e4f
--- /dev/null
+++ b/docs/tmp/en-US/xml/compute-disk-service-offerings.xml
@@ -0,0 +1,97 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Compute and Disk Service Offerings
+
+ A service offering is a set of virtual hardware features such as CPU core count and speed, memory, and disk size. The &PRODUCT; administrator can set up various offerings, and then end users choose from the available offerings when they create a new VM. A service offering includes the following elements:
+
+
+
+
+ CPU, memory, and network resource guarantees
+
+
+
+
+ How resources are metered
+
+
+
+
+ How the resource usage is charged
+
+
+
+
+ How often the charges are generated
+
+
+
+
+
+ For example, one service offering might allow users to create a virtual machine instance that is equivalent to a 1 GHz Intel® Core™ 2 CPU, with 1 GB memory at $0.20/hour, with network traffic metered at $0.10/GB. Based on the user’s selected offering, &PRODUCT; emits usage records that can be integrated with billing systems. &PRODUCT; separates service offerings into compute offerings and disk offerings. The computing service offering specifies:
+
+
+
+
+ Guest CPU
+
+
+
+
+ Guest RAM
+
+
+
+
+ Guest Networking type (virtual or direct)
+
+
+
+
+ Tags on the root disk
+
+
+
+
+
+ The disk offering specifies:
+
+
+
+
+ Disk size (optional). An offering without a disk size will allow users to pick their own
+
+
+
+
+ Tags on the data disk
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/concepts.xml b/docs/tmp/en-US/xml/concepts.xml
new file mode 100644
index 00000000000..3923607286d
--- /dev/null
+++ b/docs/tmp/en-US/xml/concepts.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Concepts
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-acl.xml b/docs/tmp/en-US/xml/configure-acl.xml
new file mode 100644
index 00000000000..b2b11d52d8b
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-acl.xml
@@ -0,0 +1,186 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configuring Access Control List
+
+ Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service is supported.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ACLs
+
+
+
+
+
+
+
+
+
+ Select Network ACLs.
+
+
+ The Network ACLs page is displayed.
+
+
+
+
+
+ Click Add Network ACLs.
+
+
+ To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed in this tier.
+
+
+
+
+ CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or to the IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+
+
+
+
+ Protocol: The networking protocol that sources use to send traffic to the tier. The TCP and UDP protocols are typically used for data exchange and end-user communications. The ICMP protocol is typically used to send error messages or network monitoring data.
+
+
+
+
+
+ Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for the incoming traffic. If you are opening a single port, use the same number in both fields.
+
+
+
+
+
+ Select Tier: Select the tier for which you want to add this ACL rule.
+
+
+
+
+
+ ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
+
+
+
+
+
+ Traffic Type: Select the traffic type you want to apply.
+
+
+
+
+ Egress: To add an egress rule, select Egress from the Traffic type drop-down box and click Add. This specifies what type of traffic is allowed to be sent out of VM instances in this tier. If no egress rules are specified, all traffic from the tier is allowed out at the VPC virtual router. Once egress rules are specified, only the traffic specified in egress rules and the responses to any traffic that has been allowed in through an ingress rule are allowed out. No egress rule is required for the VMs in a tier to communicate with each other.
+
+
+
+
+
+ Ingress: To add an ingress rule, select Ingress from the Traffic type drop-down box and click Add. This specifies what network traffic is allowed into the VM instances in this tier. If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
+
+
+
+
+
+
+ By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, create a new network ACL.
+
+
+
+
+
+
+
+
+
+
+
+ Click Add. The ACL rule is added.
+
+
+ To view the list of ACL rules you have added, click the desired tier from the Network ACLs page, then select the Network ACL tab.
+
+
+
+
+
+
+ network-acl.png: adding, editing, deleting an ACL rule.
+
+
+
+
+ You can edit the tags assigned to the ACL rules and delete the ACL rules you have created. Click the appropriate button in the Actions column.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-guest-traffic-in-advanced-zone.xml b/docs/tmp/en-US/xml/configure-guest-traffic-in-advanced-zone.xml
new file mode 100644
index 00000000000..306c2661b4b
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-guest-traffic-in-advanced-zone.xml
@@ -0,0 +1,111 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configure Guest Traffic in an Advanced Zone
+
+ These steps assume you have already logged in to the &PRODUCT; UI. To configure the base guest network:
+
+
+
+
+ In the left navigation, choose Infrastructure. On Zones, click View More, then click the zone to which you want to add a network.
+
+
+
+
+
+ Click the Network tab.
+
+
+
+
+
+ Click Add guest network.
+
+
+ The Add guest network window is displayed:
+
+
+
+
+
+
+ networksetupzone.png: Depicts network setup in a single zone
+
+
+
+
+
+
+
+ Provide the following information:
+
+
+
+
+ Name. The name of the network. This will be user-visible
+
+
+
+
+
+ Display Text: The description of the network. This will be user-visible
+
+
+
+
+
+ Zone: The zone in which you are configuring the guest network.
+
+
+
+
+
+ Network offering: If the administrator has configured multiple network offerings, select the one you want to use for this network
+
+
+
+
+
+ Guest Gateway: The gateway that the guests should use
+
+
+
+
+
+ Guest Netmask: The netmask in use on the subnet the guests will use
+
+
+
+
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-package-repository.xml b/docs/tmp/en-US/xml/configure-package-repository.xml
new file mode 100644
index 00000000000..e5f30110972
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-package-repository.xml
@@ -0,0 +1,92 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configure package repository
+
+ &PRODUCT; is only distributed from source from the official mirrors. However, members of the CloudStack community may build convenience binaries so that users can install Apache CloudStack without needing to build from source.
+
+
+ If you didn't follow the steps to build your own packages from source in the sections for or you may find pre-built DEB and RPM packages for your convience linked from the downloads page.
+
+
+
+ These repositories contain both the Management Server and KVM Hypervisor packages.
+
+
+
+
+ DEB package repository
+
+ You can add a DEB package repository to your apt sources with the following commands. Please note that only packages for Ubuntu 12.04 LTS (precise) are being built at this time.
+
+
+ Use your preferred editor and open (or create) /etc/apt/sources.list.d/cloudstack.list. Add the community provided repository to the file:
+
+
+deb http://cloudstack.apt-get.eu/ubuntu precise 4.0
+
+ We now have to add the public key to the trusted keys.
+
+
+$wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
+
+ Now update your local apt cache.
+
+
+$apt-get update
+
+ Your DEB package repository should now be configured and ready for use.
+
+
+
+
+
+ RPM package repository
+
+ There is a RPM package repository for &PRODUCT; so you can easily install on RHEL based platforms.
+
+
+ If you're using an RPM-based system, you'll want to add the Yum repository so that you can install &PRODUCT; with Yum.
+
+
+ Yum repository information is found under /etc/yum.repos.d. You'll see several .repo files in this directory, each one denoting a specific repository.
+
+
+ To add the &PRODUCT; repository, create /etc/yum.repos.d/cloudstack.repo and insert the following information.
+
+
+
+[cloudstack]
+name=cloudstack
+baseurl=http://cloudstack.apt-get.eu/rhel/4.0/
+enabled=1
+gpgcheck=0
+
+
+ Now you should be able to install CloudStack using Yum.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-public-traffic-in-an-advanced-zone.xml b/docs/tmp/en-US/xml/configure-public-traffic-in-an-advanced-zone.xml
new file mode 100644
index 00000000000..ea96c8c2b62
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-public-traffic-in-an-advanced-zone.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configure Public Traffic in an Advanced Zone
+
+ In a zone that uses advanced networking, you need to configure at least one range of IP addresses for Internet traffic.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-usage-server.xml b/docs/tmp/en-US/xml/configure-usage-server.xml
new file mode 100644
index 00000000000..2b032bc927d
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-usage-server.xml
@@ -0,0 +1,241 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configuring the Usage Server
+
+ To configure the usage server:
+
+
+
+
+ Be sure the Usage Server has been installed. This requires extra steps beyond just installing the &PRODUCT; software. See Installing the Usage Server (Optional) in the Advanced Installation Guide.
+
+
+
+
+ Log in to the &PRODUCT; UI as administrator.
+
+
+
+
+ Click Global Settings.
+
+
+
+
+ In Search, type usage. Find the configuration parameter that controls the behavior you want to set. See the table below for a description of the available parameters.
+
+
+
+
+ In Actions, click the Edit icon.
+
+
+
+
+ Type the desired value and click the Save icon.
+
+
+
+
+ Restart the Management Server (as usual with any global configuration change) and also the Usage Server:
+
+
+# service cloud-management restart
+# service cloud-usage restart
+
+
+
+
+
+ The following table shows the global configuration settings that control the behavior of the Usage Server.
+
+
+
+
+
+
+
+ Parameter Name
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+ enable.usage.server
+
+
+
+
+ Whether the Usage Server is active.
+
+
+
+
+
+
+
+ usage.aggregation.timezone
+
+
+
+
+ Time zone of usage records. Set this if the usage records and daily job execution are in different time zones. For example, with the following settings, the usage job will run at PST 00:15 and generate usage records for the 24 hours from 00:00:00 GMT to 23:59:59 GMT:
+
+
+usage.stats.job.exec.time = 00:15
+usage.execution.timezone = PST
+usage.aggregation.timezone = GMT
+
+
+ Valid values for the time zone are specified in
+
+
+ Default: GMT
+
+
+
+
+
+
+
+
+ usage.execution.timezone
+
+
+
+
+ The time zone of usage.stats.job.exec.time. Valid values for the time zone are specified in
+
+
+ Default: The time zone of the management server.
+
+
+
+
+
+
+
+
+ usage.sanity.check.interval
+
+
+
+
+ The number of days between sanity checks. Set this in order to periodically search for records with erroneous data before issuing customer invoices. For example, this checks for VM usage records created after the VM was destroyed, and similar checks for templates, volumes, and so on. It also checks for usage times longer than the aggregation range. If any issue is found, the alert ALERT_TYPE_USAGE_SANITY_RESULT = 21 is sent.
+
+
+
+
+
+
+
+ usage.stats.job.aggregation.range
+
+
+
+
+ The time period in minutes between Usage Server processing jobs. For example, if you set it to 1440, the Usage Server will run once per day. If you set it to 600, it will run every ten hours. In general, when a Usage Server job runs, it processes all events generated since usage was last run.
+
+
+ There is special handling for the case of 1440 (once per day). In this case the Usage Server does not necessarily process all records since Usage was last run. &PRODUCT; assumes that you require processing once per day for the previous, complete day’s records. For example, if the current day is October 7, then it is assumed you would like to process records for October 6, from midnight to midnight. &PRODUCT; assumes this "midnight to midnight" is relative to the usage.execution.timezone.
+
+
+ Default: 1440
+
+
+
+
+
+
+
+
+ usage.stats.job.exec.time
+
+
+
+
+ The time when the Usage Server processing will start. It is specified in 24-hour format (HH:MM) in the time zone of the server, which should be GMT. For example, to start the Usage job at 10:30 GMT, enter "10:30".
+
+
+ If usage.stats.job.aggregation.range is also set, and its value is not 1440, then its value will be added to usage.stats.job.exec.time to get the time to run the Usage Server job again. This is repeated until 24 hours have elapsed, and the next day's processing begins again at usage.stats.job.exec.time.
+
+
+ Default: 00:15.
+
+
+
+
+
+
+
+
+
+
+
+
+ For example, suppose that your server is in GMT, your user population is predominantly in the East Coast of the United States, and you would like to process usage records every night at 2 AM local (EST) time. Choose these settings:
+
+
+
+
+ enable.usage.server = true
+
+
+
+
+ usage.execution.timezone = America/New_York
+
+
+
+
+ usage.stats.job.exec.time = 07:00. This will run the Usage job at 2:00 AM EST. Note that this will shift by an hour as the East Coast of the U.S. enters and exits Daylight Savings Time.
+
+
+
+
+ usage.stats.job.aggregation.range = 1440
+
+
+
+
+
+ With this configuration, the Usage job will run every night at 2 AM EST and will process records for the previous day’s midnight-midnight as defined by the EST (America/New_York) time zone.
+
+
+
+ Because the special value 1440 has been used for usage.stats.job.aggregation.range, the Usage Server will ignore the data between midnight and 2 AM. That data will be included in the next day's run
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-virtual-router.xml b/docs/tmp/en-US/xml/configure-virtual-router.xml
new file mode 100644
index 00000000000..db340afea45
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-virtual-router.xml
@@ -0,0 +1,58 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configuring the Virtual Router
+
+ You can set the following:
+
+
+
+
+ IP range
+
+
+
+
+ Supported network services
+
+
+
+
+ Default domain name for the network serviced by the virtual router
+
+
+
+
+ Gateway IP address
+
+
+
+
+ How often &PRODUCT; fetches network usage statistics from &PRODUCT; virtual routers. If you want to collect traffic metering data from the virtual router, set the global configuration parameter router.stats.interval. If you are not using the virtual router to gather network usage statistics, set it to 0.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-vpc.xml b/docs/tmp/en-US/xml/configure-vpc.xml
new file mode 100644
index 00000000000..6994330120e
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-vpc.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configuring a Virtual Private Cloud
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-vpn.xml b/docs/tmp/en-US/xml/configure-vpn.xml
new file mode 100644
index 00000000000..f35501443bc
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-vpn.xml
@@ -0,0 +1,113 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configuring VPN
+
+ To set up VPN for the cloud:
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+ In the left navigation, click Global Settings.
+
+
+
+
+ Set the following global configuration parameters.
+
+
+
+
+ remote.access.vpn.client.ip.range – The range of IP addressess to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
+
+
+
+
+ remote.access.vpn.psk.length – Length of the IPSec key.
+
+
+
+
+ remote.access.vpn.user.limit – Maximum number of VPN users per account.
+
+
+
+
+
+
+
+ To enable VPN for a particular network:
+
+
+
+
+ Log in as a user or administrator to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation, click Network.
+
+
+
+
+ Click the name of the network you want to work with.
+
+
+
+
+ Click View IP Addresses.
+
+
+
+
+ Click one of the displayed IP address names.
+
+
+
+
+ Click the Enable VPN button
+
+
+
+
+
+ AttachDiskButton.png: button to attach a volume
+
+
+
+ .
+
+
+ The IPsec key is displayed in a popup window.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-xenserver-dom-memory.xml b/docs/tmp/en-US/xml/configure-xenserver-dom-memory.xml
new file mode 100644
index 00000000000..f1796eb2122
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-xenserver-dom-memory.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configure XenServer dom0 Memory
+
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configure-xenserver-dom0-memory.xml b/docs/tmp/en-US/xml/configure-xenserver-dom0-memory.xml
new file mode 100644
index 00000000000..f1796eb2122
--- /dev/null
+++ b/docs/tmp/en-US/xml/configure-xenserver-dom0-memory.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configure XenServer dom0 Memory
+
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+
+
+
+
diff --git a/docs/tmp/en-US/xml/configuring-projects.xml b/docs/tmp/en-US/xml/configuring-projects.xml
new file mode 100644
index 00000000000..46df9390772
--- /dev/null
+++ b/docs/tmp/en-US/xml/configuring-projects.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configuring Projects
+
+ Before CloudPlatform users start using projects, the CloudPlatform administrator must set up various systems to support them, including membership invitations, limits on project resources, and controls on who can create projects.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/console-proxy.xml b/docs/tmp/en-US/xml/console-proxy.xml
new file mode 100644
index 00000000000..0c63c5e7e3d
--- /dev/null
+++ b/docs/tmp/en-US/xml/console-proxy.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Console Proxy
+
+ The Console Proxy is a type of System Virtual Machine that has a role in presenting a console view via the web UI. It connects the user’s browser to the VNC port made available via the hypervisor for the console of the guest. Both the administrator and end user web UIs offer a console connection.
+
+
+ Clicking on a console icon brings up a new window. The AJAX code downloaded into that window refers to the public IP address of a console proxy VM. There is exactly one public IP address allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then proxies the connection to the VNC port for the requested VM on the Host hosting the guest. .
+
+
+
+ The hypervisors will have many ports assigned to VNC usage so that multiple VNC sessions can occur simultaneously.
+
+
+
+ There is never any traffic to the guest virtual IP, and there is no need to enable VNC within the guest.
+
+
+ The console proxy VM will periodically report its active session count to the Management Server. The default reporting interval is five seconds. This can be changed through standard Management Server configuration with the parameter consoleproxy.loadscan.interval.
+
+
+ Assignment of guest VM to console proxy is determined by first determining if the guest VM has a previous session associated with a console proxy. If it does, the Management Server will assign the guest VM to the target Console Proxy VM regardless of the load on the proxy VM. Failing that, the first available running Console Proxy VM that has the capacity to handle new sessions is used.
+
+
+ Console proxies can be restarted by administrators but this will interrupt existing console sessions for users.
+
+
+ The console viewing functionality uses a dynamic DNS service under the domain name realhostip.com to assist in providing SSL security to console sessions. The console proxy is assigned a public IP address. In order to avoid browser warnings for mismatched SSL certificates, the URL for the new console window is set to the form of https://aaa-bbb-ccc-ddd.realhostip.com. Customers will see this URL during console session creation. &PRODUCT; includes the realhostip.com SSL certificate in the console proxy VM. Of course, &PRODUCT; cannot know about DNS A records for our customers' public IPs prior to shipping the software. &PRODUCT; therefore runs a dynamic DNS server that is authoritative for the realhostip.com domain. It maps the aaa-bbb-ccc-ddd part of the DNS name to the IP address aaa.bbb.ccc.ddd on lookups. This allows the browser to correctly connect to the console proxy's public IP, where it then expects and receives a SSL certificate for realhostip.com, and SSL is set up without browser warnings.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/convert-hyperv-vm-to-template.xml b/docs/tmp/en-US/xml/convert-hyperv-vm-to-template.xml
new file mode 100644
index 00000000000..44d8909c389
--- /dev/null
+++ b/docs/tmp/en-US/xml/convert-hyperv-vm-to-template.xml
@@ -0,0 +1,173 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Converting a Hyper-V VM to a Template
+
+ To convert a Hyper-V VM to a XenServer-compatible &PRODUCT; template, you will need a standalone XenServer host with an attached NFS VHD SR. Use whatever XenServer version you are using with &PRODUCT;, but use XenCenter 5.6 FP1 or SP2 (it is backwards compatible to 5.6). Additionally, it may help to have an attached NFS ISO SR.
+
+
+ For Linux VMs, you may need to do some preparation in Hyper-V before trying to get the VM to work in XenServer. Clone the VM and work on the clone if you still want to use the VM in Hyper-V. Uninstall Hyper-V Integration Components and check for any references to device names in /etc/fstab:
+
+
+
+
+ From the linux_ic/drivers/dist directory, run make uninstall (where "linux_ic" is the path to the copied Hyper-V Integration Components files).
+
+
+
+
+ Restore the original initrd from backup in /boot/ (the backup is named *.backup0).
+
+
+
+
+ Remove the "hdX=noprobe" entries from /boot/grub/menu.lst.
+
+
+
+
+ Check /etc/fstab for any partitions mounted by device name. Change those entries (if any) to mount by LABEL or UUID (get that information with the "blkid" command)..
+
+
+
+
+
+ The next step is make sure the VM is not running in Hyper-V, then get the VHD into XenServer. There are two options for doing this.
+
+
+ Option one:
+
+
+
+
+ Import the VHD using XenCenter. In XenCenter, go to Tools>Virtual Appliance Tools>Disk Image Import.
+
+
+
+
+ Choose the VHD, then click Next.
+
+
+
+
+ Name the VM, choose the NFS VHD SR under Storage, enable "Run Operating System Fixups" and choose the NFS ISO SR.
+
+
+
+
+ Click Next, then Finish. A VM should be created.
+
+
+
+
+
+ Option two
+
+
+
+
+ Run XenConvert, under From choose VHD, under To choose XenServer. Click Next.
+
+
+
+
+ Choose the VHD, then click Next.
+
+
+
+
+ Input the XenServer host info, then click Next.
+
+
+
+
+ Name the VM, then click Next, then Convert. A VM should be created
+
+
+
+
+
+ Once you have a VM created from the Hyper-V VHD, prepare it using the following steps:
+
+
+
+
+ Boot the VM, uninstall Hyper-V Integration Services, and reboot.
+
+
+
+
+ Install XenServer Tools, then reboot.
+
+
+
+
+ Prepare the VM as desired. For example, run sysprep on Windows VMs. See
+
+
+
+
+
+ Either option above will create a VM in HVM mode. This is fine for Windows VMs, but Linux VMs may not perform optimally. Converting a Linux VM to PV mode will require additional steps and will vary by distribution.
+
+
+
+
+ Shut down the VM and copy the VHD from the NFS storage to a web server; for example, mount the NFS share on the web server and copy it, or from the XenServer host use sftp or scp to upload it to the web server.
+
+
+
+
+ In &PRODUCT;, create a new template using the following values:
+
+
+
+
+ URL. Give the URL for the VHD
+
+
+
+
+ OS Type. Use the appropriate OS. For PV mode on CentOS, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServer.
+
+
+
+
+ Hypervisor. XenServer
+
+
+
+
+ Format. VHD
+
+
+
+
+
+
+
+
+ The template will be created, and you can create instances from it.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-bare-metal-template.xml b/docs/tmp/en-US/xml/create-bare-metal-template.xml
new file mode 100644
index 00000000000..af29c9f89d5
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-bare-metal-template.xml
@@ -0,0 +1,110 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a Bare Metal Template
+
+
+ Beta feature. Untested in &PRODUCT; 3.0.3. Provided without guarantee of performance.
+
+
+
+ Before you can create a bare metal template, you must have performed several other installation and setup steps to create a bare metal cluster and environment. See Bare Metal Installation in the Installation Guide. It is assumed you already have a directory named "win7_64bit" on your CIFS server, containing the image for the bare metal instance. This directory and image are set up as part of the Bare Metal Installation procedure.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+ In the left navigation bar, click Templates.
+
+
+
+
+ Click Create Template.
+
+
+
+
+ In the dialog box, enter the following values.
+
+
+
+
+ Name. Short name for the template.
+
+
+
+
+ Display Text. Description of the template.
+
+
+
+
+ URL. The directory name which contains image file on your CIFS server. For example, win7_64bit.
+
+
+
+
+ Zone. All Zones.
+
+
+
+
+ OS Type. Select the OS type of the ISO image. Choose other if the OS Type of the ISO is not listed or if the ISO is not bootable.
+
+
+
+
+ Hypervisor. BareMetal.
+
+
+
+
+ Format. BareMetal.
+
+
+
+
+ Password Enabled. No.
+
+
+
+
+ Public. No.
+
+
+
+
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. Only administrators may make templates featured.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-new-projects.xml b/docs/tmp/en-US/xml/create-new-projects.xml
new file mode 100644
index 00000000000..1d7e2e18bf2
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-new-projects.xml
@@ -0,0 +1,68 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a New Project
+
+ &PRODUCT; 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 &PRODUCT; 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.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-template-from-existing-vm.xml b/docs/tmp/en-US/xml/create-template-from-existing-vm.xml
new file mode 100644
index 00000000000..26544150a9a
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-template-from-existing-vm.xml
@@ -0,0 +1,107 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a Template from an Existing Virtual Machine
+
+ Once you have at least one VM set up in the way you want, you can use it as the prototype for other VMs.
+
+
+
+
+ Create and start a virtual machine using any of the techniques given in .
+
+
+
+
+ Make any desired configuration changes on the running VM, then click Stop.
+
+
+
+
+ Wait for the VM to stop. When the status shows Stopped, go to the next step.
+
+
+
+
+ Click Create Template and provide the following:
+
+
+
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+
+
+
+ OS Type. This helps &PRODUCT; and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+
+
+
+ If the operating system of the stopped VM is listed, choose it.
+
+
+
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
+
+
+
+ If you want to boot from this template in PV mode, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServere:
+
+
+
+ Note: Generally you should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+
+
+
+
+
+
+
+
+ Public. Choose Yes to make this template accessible to all users of this &PRODUCT; installation. The template will appear in the Community Templates list. See .
+
+
+
+
+ Password Enabled. Choose Yes if your template has the &PRODUCT; password change script installed. See Adding Password Management to Your Templates.
+
+
+
+
+
+
+
+ Click Add.
+
+
+
+
+
+ The new template will be visible in the Templates section when the template creation process has been completed. The template is then available when creating a new VM
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-template-from-snapshot.xml b/docs/tmp/en-US/xml/create-template-from-snapshot.xml
new file mode 100644
index 00000000000..4f6468187f2
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-template-from-snapshot.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a Template from a Snapshot
+
+ If you do not want to stop the VM in order to use the Create Template menu item (as described in ), you can create a template directly from any snapshot through the &PRODUCT; UI.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-templates-overview.xml b/docs/tmp/en-US/xml/create-templates-overview.xml
new file mode 100644
index 00000000000..2a4c46f9e7a
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-templates-overview.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating Templates: Overview
+
+ &PRODUCT; ships with a default template for the CentOS operating system. There are a variety of ways to add more templates. Administrators and end users can add templates. The typical sequence of events is:
+
+
+
+
+ Launch a VM instance that has the operating system you want. Make any other desired configuration changes to the VM.
+
+
+
+
+ Stop the VM.
+
+
+
+
+ Convert the volume into a template.
+
+
+
+
+
+ There are other ways to add templates to &PRODUCT;. For example, you can take a snapshot of the VM's volume and create a template from the snapshot, or import a VHD from another system into &PRODUCT;
+
+
+ The various techniques for creating templates are described in the next few sections.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-vpn-connection-vpc.xml b/docs/tmp/en-US/xml/create-vpn-connection-vpc.xml
new file mode 100644
index 00000000000..474121aa4dc
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-vpn-connection-vpc.xml
@@ -0,0 +1,177 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a VPN Connection
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you create for the account are listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ASLs
+
+
+
+
+
+
+
+
+
+ Select Site-to-Site VPN.
+
+
+ The Site-to-Site VPN page is displayed.
+
+
+
+
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+
+
+
+
+ Click Create VPN Connection.
+
+
+ The Create VPN Connection dialog is displayed:
+
+
+
+
+
+
+ createvpnconnection.png: creating a vpn connection to the customer gateway.
+
+
+
+
+
+
+
+ Select the desired customer gateway, then click OK to confirm.
+
+
+ Within a few moments, the VPN Connection is displayed.
+
+
+ The following information on the VPN connection is displayed:
+
+
+
+
+ IP Address
+
+
+
+
+
+ Gateway
+
+
+
+
+
+ State
+
+
+
+
+
+ IPSec Preshared Key
+
+
+
+
+
+ IKE Policy
+
+
+
+
+
+ ESP Policy
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-vpn-customer-gateway.xml b/docs/tmp/en-US/xml/create-vpn-customer-gateway.xml
new file mode 100644
index 00000000000..11c689ac10c
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-vpn-customer-gateway.xml
@@ -0,0 +1,253 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating and Updating a VPN Customer Gateway
+
+
+ A VPN customer gateway can be connected to only one VPN gateway at a time.
+
+
+
+
+ To add a VPN Customer Gateway:
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPN Customer Gateway.
+
+
+
+
+
+ Click Add site-to-site VPN.
+
+
+
+
+
+
+ addvpncustomergateway.png: adding a customer gateway.
+
+
+
+
+ Provide the following information:
+
+
+
+
+ Name: A unique name for the VPN customer gateway you create.
+
+
+
+
+
+ Gateway: The IP address for the remote gateway.
+
+
+
+
+
+ CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be RFC1918-compliant.
+
+
+
+
+
+ IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share a secret key. This key value is used to authenticate the customer gateway and the VPC VPN gateway to each other.
+
+
+
+ The IKE peers (VPN end points) authenticate each other by computing and sending a keyed hash of data that includes the Preshared key. If the receiving peer is able to create the same hash independently by using its Preshared key, it knows that both peers must share the same secret, thus authenticating the customer gateway.
+
+
+
+
+
+
+
+ IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is accomplished through the Preshared Keys.
+
+
+
+ The phase-1 is the first phase in the IKE process. In this initial negotiation phase, the two VPN endpoints agree on the methods to be used to provide security for the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each other, by confirming that the remote gateway has a matching Preshared Key.
+
+
+
+
+
+
+
+ IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.
+
+
+
+
+
+ IKE DH: A public-key cryptography protocol which allows two parties to establish a shared secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).
+
+
+
+
+
+ ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192, AES256, and 3DES.
+
+
+
+ The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to provide session keys to use in protecting the VPN data flow.
+
+
+
+
+
+
+
+ ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash algorithms are SHA1 and MD5.
+
+
+
+
+
+ Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a session key derived from a set of long-term public and private keys will not be compromised. This property enforces a new Diffie-Hellman key exchange. It provides the keying material that has greater key material life and thereby greater resistance to cryptographic attacks. The available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key exchanges increase as the DH groups grow larger, as does the time of the exchanges.
+
+
+
+ When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways must generate a new set of phase-1 keys. This adds an extra layer of protection that PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new phase-2 SA’s have not been generated from the current phase-1 keying material.
+
+
+
+
+
+
+
+ IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is 86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.
+
+
+
+
+
+ ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a new IPsec encryption and authentication session keys.
+
+
+
+
+
+ Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual router to query the liveliness of its IKE peer at regular intervals. It’s recommended to have the same configuration of DPD on both side of VPN connection.
+
+
+
+
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+ Updating and Removing a VPN Customer Gateway
+
+ You can update a customer gateway either with no VPN connection, or related VPN connection is in error state.
+
+
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPN Customer Gateway.
+
+
+
+
+
+ Select the VPN customer gateway you want to work with.
+
+
+
+
+
+ To modify the required parameters, click the Edit VPN Customer Gateway button
+
+
+
+
+
+ edit.png: button to edit a VPN customer gateway
+
+
+
+
+
+
+
+
+ To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
+
+
+
+
+
+ delete.png: button to remove a VPN customer gateway
+
+
+
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-vpn-gateway-for-vpc.xml b/docs/tmp/en-US/xml/create-vpn-gateway-for-vpc.xml
new file mode 100644
index 00000000000..7023eb5d134
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-vpn-gateway-for-vpc.xml
@@ -0,0 +1,135 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a VPN gateway for the VPC
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ACLs
+
+
+
+
+
+
+
+
+
+ Select Site-to-Site VPN.
+
+
+ If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN prompts you to create a VPN gateway.
+
+
+
+
+
+ In the confirmation dialog, click Yes to confirm.
+
+
+ Within a few moments, the VPN gateway is created. You will be prompted to view the details of the VPN gateway you have created. Click Yes to confirm.
+
+
+ The following details are displayed in the VPN Gateway page:
+
+
+
+
+ IP Address
+
+
+
+
+
+ Account
+
+
+
+
+
+ Domain
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-vr-network-offering.xml b/docs/tmp/en-US/xml/create-vr-network-offering.xml
new file mode 100644
index 00000000000..360f2ccdabb
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-vr-network-offering.xml
@@ -0,0 +1,156 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating and Changing a Virtual Router Network Offering
+
+ To create the network offering in association with a virtual router system service offering:
+
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+
+ First, create a system service offering, for example: VRsystemofferingHA.
+
+
+ For more information on creating a system service offering, see .
+
+
+
+
+
+ From the Select Offering drop-down, choose Network Offering.
+
+
+
+
+
+ Click Add Network Offering.
+
+
+
+
+
+ In the dialog, make the following choices:
+
+
+
+
+ Name. Any desired name for the network offering.
+
+
+
+
+
+ Description. A short description of the offering that can be displayed to users.
+
+
+
+
+
+ Network Rate. Allowed data transfer rate in MB per second.
+
+
+
+
+
+ Traffic Type. The type of network traffic that will be carried on the network.
+
+
+
+
+
+ Guest Type. Choose whether the guest network is isolated or shared. For a description of these terms, see .
+
+
+
+
+
+ Specify VLAN. (Isolated guest networks only) Indicate whether a VLAN should be specified when this offering is used.
+
+
+
+
+
+ Supported Services. Select one or more of the possible network services. For some services, you must also choose the service provider; for example, if you select Load Balancer, you can choose the &PRODUCT; virtual router or any other load balancers that have been configured in the cloud. Depending on which services you choose, additional fields may appear in the rest of the dialog box. For more information, see
+
+
+
+
+
+ System Offering. Choose the system service offering that you want virtual routers to use in this network. In this case, the default “System Offering For Software Router” and the custom “VRsystemofferingHA” are available and displayed.
+
+
+
+
+
+
+
+
+
+ Click OK and the network offering is created.
+
+
+
+
+
+
+ To change the network offering of a guest network to the virtual router service offering:
+
+
+
+
+ Select Network from the left navigation pane.
+
+
+
+
+
+ Select the guest network that you want to offer this network service to.
+
+
+
+
+
+ Click the Edit button.
+
+
+
+
+
+ From the Network Offering drop-down, select the virtual router network offering you have just created.
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/create-windows-template.xml b/docs/tmp/en-US/xml/create-windows-template.xml
new file mode 100644
index 00000000000..a548da1914b
--- /dev/null
+++ b/docs/tmp/en-US/xml/create-windows-template.xml
@@ -0,0 +1,68 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a Windows Template
+
+ Windows templates must be prepared with Sysprep before they can be provisioned on multiple machines. Sysprep allows you to create a generic Windows template and avoid any possible SID conflicts.
+
+
+
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+
+
+ An overview of the procedure is as follows:
+
+
+
+
+ Upload your Windows ISO.
+
+
+ For more information, see
+
+
+
+
+ Create a VM Instance with this ISO.
+
+
+ For more information, see
+
+
+
+
+ Follow the steps in Sysprep for Windows Server 2008 R2 (below) or Sysprep for Windows Server 2003 R2, depending on your version of Windows Server
+
+
+
+
+ The preparation steps are complete. Now you can actually create the template as described in Creating the Windows Template.
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/creating-compute-offerings.xml b/docs/tmp/en-US/xml/creating-compute-offerings.xml
new file mode 100644
index 00000000000..663f1e184e5
--- /dev/null
+++ b/docs/tmp/en-US/xml/creating-compute-offerings.xml
@@ -0,0 +1,126 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a New Compute Offering
+
+ To create a new compute offering:
+
+
+
+
+ Log in with admin privileges to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation bar, click Service Offerings.
+
+
+
+
+ In Select Offering, choose Compute Offering.
+
+
+
+
+ Click Add Compute Offering.
+
+
+
+
+ In the dialog, make the following choices:
+
+
+
+
+ Name: Any desired name for the service offering.
+
+
+
+
+ Description: A short description of the offering that can be displayed to users
+
+
+
+
+ Storage type: The type of disk that should be allocated. Local allocates from storage attached directly to the host where the system VM is running. Shared allocates from storage accessible via NFS.
+
+
+
+
+ # of CPU cores: The number of cores which should be allocated to a system VM with this offering
+
+
+
+
+ CPU (in MHz): The CPU speed of the cores that the system VM is allocated. For example, “2000” would provide for a 2 GHz clock.
+
+
+
+
+ Memory (in MB): The amount of memory in megabytes that the system VM should be allocated. For example, “2048” would provide for a 2 GB RAM allocation.
+
+
+
+
+ Network Rate: Allowed data transfer rate in MB per second.
+
+
+
+
+ Offer HA: If yes, the administrator can choose to have the system VM be monitored and as highly available as possible.
+
+
+
+
+ Storage Tags: The tags that should be associated with the primary storage used by the system VM.
+
+
+
+
+ Host Tags: (Optional) Any tags that you use to organize your hosts
+
+
+
+
+ CPU cap: Whether to limit the level of CPU usage even if spare capacity is available.
+
+
+
+
+ Public: Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; &PRODUCT; will then prompt for the subdomain's name.
+
+
+
+
+
+
+
+ Click Add.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/creating-disk-offerings.xml b/docs/tmp/en-US/xml/creating-disk-offerings.xml
new file mode 100644
index 00000000000..6fc3493490b
--- /dev/null
+++ b/docs/tmp/en-US/xml/creating-disk-offerings.xml
@@ -0,0 +1,95 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a New Disk Offering
+
+ To create a system service offering:
+
+
+
+
+ Log in with admin privileges to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation bar, click Service Offerings.
+
+
+
+
+ In Select Offering, choose Disk Offering.
+
+
+
+
+ Click Add Disk Offering.
+
+
+
+
+ In the dialog, make the following choices:
+
+
+
+
+ Name. Any desired name for the system offering.
+
+
+
+
+ Description. A short description of the offering that can be displayed to users
+
+
+
+
+ Custom Disk Size. If checked, the user can set their own disk size. If not checked, the root administrator must define a value in Disk Size.
+
+
+
+
+ Disk Size. Appears only if Custom Disk Size is not selected. Define the volume size in GB.
+
+
+
+
+ (Optional)Storage Tags. The tags that should be associated with the primary storage for this disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue". Tags are also added on Primary Storage. &PRODUCT; matches tags on a disk offering to tags on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation from the disk offering will fail..
+
+
+
+
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; &PRODUCT; will then prompt for the subdomain's name.
+
+
+
+
+
+
+
+ Click Add.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/creating-network-offerings.xml b/docs/tmp/en-US/xml/creating-network-offerings.xml
new file mode 100644
index 00000000000..44aad3a5e90
--- /dev/null
+++ b/docs/tmp/en-US/xml/creating-network-offerings.xml
@@ -0,0 +1,362 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a New Network Offering
+
+ To create a network offering:
+
+
+
+
+ Log in with admin privileges to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation bar, click Service Offerings.
+
+
+
+
+ In Select Offering, choose Network Offering.
+
+
+
+
+ Click Add Network Offering.
+
+
+
+
+ In the dialog, make the following choices:
+
+
+
+
+ Name. Any desired name for the network offering
+
+
+
+
+ Description. A short description of the offering that can be displayed to users
+
+
+
+
+ Network Rate. Allowed data transfer rate in MB per second
+
+
+
+
+ Traffic Type. The type of network traffic that will be carried on the network
+
+
+
+
+ Guest Type. Choose whether the guest network is isolated or shared. For a description of these terms, see
+
+
+
+
+ Specify VLAN. (Isolated guest networks only) Indicate whether a VLAN should be specified when this offering is used
+
+
+
+
+ Supported Services. Select one or more of the possible network services. For some services, you must also choose the service provider; for example, if you select Load Balancer, you can choose the &PRODUCT; virtual router or any other load balancers that have been configured in the cloud. Depending on which services you choose, additional fields may appear in the rest of the dialog box.
+
+
+ Based on the guest network type selected, you can see the following supported services:
+
+
+
+
+
+
+
+ Supported Services
+
+
+
+
+ Description
+
+
+
+
+ Isolated
+
+
+
+
+ Shared
+
+
+
+
+
+
+
+
+
+
+ DHCP
+
+
+
+
+
+
+
+
+ Supported
+
+
+
+
+ Supported
+
+
+
+
+
+
+
+ DNS
+
+
+
+
+
+
+
+
+ Supported
+
+
+
+
+ Supported
+
+
+
+
+
+
+
+ Load Balancer
+
+
+
+
+ If you select Load Balancer, you can choose the &PRODUCT; virtual router or any other load balancers that have been configured in the cloud.
+
+
+
+
+ Supported
+
+
+
+
+ Supported
+
+
+
+
+
+
+
+ Source NAT
+
+
+
+
+ If you select Source NAT, you can choose the &PRODUCT; virtual router or any other Source NAT providers that have been configured in the cloud.
+
+
+
+
+ Supported
+
+
+
+
+ Supported
+
+
+
+
+
+
+
+ Static NAT
+
+
+
+
+ If you select Static NAT, you can choose the &PRODUCT; virtual router or any other Static NAT providers that have been configured in the cloud.
+
+
+
+
+ Supported
+
+
+
+
+ Supported
+
+
+
+
+
+
+
+ Port Forwarding
+
+
+
+
+ If you select Port Forwarding, you can choose the &PRODUCT; virtual router or any other Port Forwarding providers that have been configured in the cloud.
+
+
+
+
+ Supported
+
+
+
+
+ Not Supported
+
+
+
+
+
+
+
+ VPN
+
+
+
+
+
+
+
+
+ Supported
+
+
+
+
+ Not Supported
+
+
+
+
+
+
+
+ User Data
+
+
+
+
+
+
+
+
+ Not Supported
+
+
+
+
+ Supported
+
+
+
+
+
+
+
+ Security Groups
+
+
+
+
+ See .
+
+
+
+
+ Not Supported
+
+
+
+
+ Supported
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ System Offering. If the service provider for any of the services selected in Supported Services is a virtual router, the System Offering field appears. Choose the system service offering that you want virtual routers to use in this network. For example, if you selected Load Balancer in Supported Services and selected a virtual router to provide load balancing, the System Offering field appears so you can choose between the &PRODUCT; default system service offering and any custom system service offerings that have been defined by the &PRODUCT; root administrator. For more information, see System Service Offerings.
+
+
+
+
+ Redundant router capability. (v3.0.3 and greater) Available only when Virtual Router is selected as the Source NAT provider. Select this option if you want to use two virtual routers in the network for uninterrupted connection: one operating as the master virtual router and the other as the backup. The master virtual router receives requests from and sends responses to the user’s VM. The backup virtual router is activated only when the master is down. After the failover, the backup becomes the master virtual router. &PRODUCT; deploys the routers on different hosts to ensure reliability if one host is down.
+
+
+
+
+ Conserve mode. Indicate whether to use conserve mode. In this mode, network resources are allocated only when the first virtual machine starts in the network
+
+
+
+
+ Tags. Network tag to specify which physical network to use
+
+
+
+
+
+
+
+ Click Add.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/creating-new-volumes.xml b/docs/tmp/en-US/xml/creating-new-volumes.xml
new file mode 100644
index 00000000000..914d31b00bb
--- /dev/null
+++ b/docs/tmp/en-US/xml/creating-new-volumes.xml
@@ -0,0 +1,79 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a New Volume
+
+ You can add more data disk volumes to a guest VM at any time, up to the limits of your storage capacity. Both &PRODUCT; administrators and users can add volumes to VM instances. When you create a new volume, it is stored as an entity in &PRODUCT;, but the actual storage resources are not allocated on the physical storage device until you attach the volume. This optimization allows the &PRODUCT; to provision the volume nearest to the guest that will use it when the first attachment is made.
+
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+ In the left navigation bar, click Storage.
+
+
+
+
+ In Select View, choose Volumes.
+
+
+
+
+ To create a new volume, click Add Volume, provide the following details, and click OK.
+
+
+
+
+ Name. Give the volume a unique name so you can find it later.
+
+
+
+
+ Availability Zone. Where do you want the storage to reside? This should be close to the VM that will use the volume.
+
+
+
+
+ Disk Offering. Choose the characteristics of the storage.
+
+
+
+
+
+ The new volume appears in the list of volumes with the state “Allocated.” The volume data is stored in &PRODUCT;, but the volume is not yet ready for use
+
+
+
+
+ To start using the volume, continue to Attaching a Volume
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/creating-system-service-offerings.xml b/docs/tmp/en-US/xml/creating-system-service-offerings.xml
new file mode 100644
index 00000000000..abefb1a2691
--- /dev/null
+++ b/docs/tmp/en-US/xml/creating-system-service-offerings.xml
@@ -0,0 +1,131 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating a New System Service Offering
+
+ To create a system service offering:
+
+
+
+
+ Log in with admin privileges to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation bar, click Service Offerings.
+
+
+
+
+ In Select Offering, choose System Offering.
+
+
+
+
+ Click Add System Service Offering.
+
+
+
+
+ In the dialog, make the following choices:
+
+
+
+
+ Name. Any desired name for the system offering.
+
+
+
+
+ Description. A short description of the offering that can be displayed to users
+
+
+
+
+ System VM Type. Select the type of system virtual machine that this offering is intended to support.
+
+
+
+
+ Storage type. The type of disk that should be allocated. Local allocates from storage attached directly to the host where the system VM is running. Shared allocates from storage accessible via NFS.
+
+
+
+
+ # of CPU cores. The number of cores which should be allocated to a system VM with this offering
+
+
+
+
+ CPU (in MHz). The CPU speed of the cores that the system VM is allocated. For example, "2000" would provide for a 2 GHz clock.
+
+
+
+
+ Memory (in MB). The amount of memory in megabytes that the system VM should be allocated. For example, "2048" would provide for a 2 GB RAM allocation.
+
+
+
+
+ Network Rate. Allowed data transfer rate in MB per second.
+
+
+
+
+ Offer HA. If yes, the administrator can choose to have the system VM be monitored and as highly available as possible.
+
+
+
+
+ Storage Tags. The tags that should be associated with the primary storage used by the system VM.
+
+
+
+
+ Host Tags. (Optional) Any tags that you use to organize your hosts
+
+
+
+
+ CPU cap. Whether to limit the level of CPU usage even if spare capacity is available.
+
+
+
+
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; &PRODUCT; will then prompt for the subdomain's name.
+
+
+
+
+
+
+
+ Click Add.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/creating-vms.xml b/docs/tmp/en-US/xml/creating-vms.xml
new file mode 100644
index 00000000000..80de980605d
--- /dev/null
+++ b/docs/tmp/en-US/xml/creating-vms.xml
@@ -0,0 +1,111 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Creating VMs
+
+ Virtual machines are usually created from a template. Users can also create blank virtual machines. A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and install the OS from the CD/DVD-ROM.
+
+
+ To create a VM from a template:
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or user.
+
+
+
+
+ In the left navigation bar, click Instances.
+
+
+
+
+ Click Add Instance.
+
+
+
+
+ Select a template, then follow the steps in the wizard. (For more information about how the templates came to be in this list, see Working with Templates.
+
+
+
+
+ Be sure that the hardware you have allows starting the selected service offering.
+
+
+
+
+ Click Submit and your VM will be created and started.
+
+
+
+ For security reason, the internal name of the VM is visible only to the root admin.
+
+
+
+
+
+
+
+ Starting with v3.0.3, you can create a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A new request parameter, startVM, is introduced in the deployVm API to support this feature. For more information, see the Developer's Guide
+
+
+
+ To create a VM from an ISO:
+
+
+
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or user.
+
+
+
+
+ In the left navigation bar, click Instances.
+
+
+
+
+ Click Add Instance.
+
+
+
+
+ Select ISO Boot, and follow the steps in the wizard.
+
+
+
+
+ Click Submit and your VM will be created and started.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/customizing-dns.xml b/docs/tmp/en-US/xml/customizing-dns.xml
new file mode 100644
index 00000000000..7abc706ce4b
--- /dev/null
+++ b/docs/tmp/en-US/xml/customizing-dns.xml
@@ -0,0 +1,86 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; 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 or with the updateNetwork command in the &PRODUCT; API.
+
+
+
+
+ At the account, domain, or zone level, the DNS suffix can be assigned with the appropriate &PRODUCT; 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 &PRODUCT; 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 &PRODUCT; 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.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/dates-in-usage-record.xml b/docs/tmp/en-US/xml/dates-in-usage-record.xml
new file mode 100644
index 00000000000..b106b9574b3
--- /dev/null
+++ b/docs/tmp/en-US/xml/dates-in-usage-record.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Dates in the Usage Record
+
+ Usage records include a start date and an end date. These dates define the period of time for which the raw usage number was calculated. If daily aggregation is used, the start date is midnight on the day in question and the end date is 23:59:59 on the day in question (with one exception; see below). A virtual machine could have been deployed at noon on that day, stopped at 6pm on that day, then started up again at 11pm. When usage is calculated on that day, there will be 7 hours of running VM usage (usage type 1) and 12 hours of allocated VM usage (usage type 2). If the same virtual machine runs for the entire next day, there will 24 hours of both running VM usage (type 1) and allocated VM usage (type 2).
+
+
+ Note: The start date is not the time a virtual machine was started, and the end date is not the time when a virtual machine was stopped. The start and end dates give the time range within which usage was calculated.
+
+
+ For network usage, the start date and end date again define the range in which the number of bytes transferred was calculated. If a user downloads 10 MB and uploads 1 MB in one day, there will be two records, one showing the 10 megabytes received and one showing the 1 megabyte sent.
+
+
+ There is one case where the start date and end date do not correspond to midnight and 11:59:59pm when daily aggregation is used. This occurs only for network usage records. When the usage server has more than one day's worth of unprocessed data, the old data will be included in the aggregation period. The start date in the usage record will show the date and time of the earliest event. For other types of usage, such as IP addresses and VMs, the old unprocessed data is not included in daily aggregation.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/dedicated-ha-hosts.xml b/docs/tmp/en-US/xml/dedicated-ha-hosts.xml
new file mode 100644
index 00000000000..959ae155cfa
--- /dev/null
+++ b/docs/tmp/en-US/xml/dedicated-ha-hosts.xml
@@ -0,0 +1,50 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Dedicated HA Hosts
+
+ (v3.0.3 and greater) One or more hosts can be designated for use only by HA-enabled VMs that are restarting due to a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HA-enabled VMs is useful to:
+
+
+
+
+ Make it easier to determine which VMs have been restarted as part of the &PRODUCT; high-availability function. If a VM is running on a dedicated HA host, then it must be an HA-enabled VM whose original host failed. (With one exception: It is possible for an administrator to manually migrate any VM to a dedicated HA host.).
+
+
+
+
+ Keep HA-enabled VMs from restarting on hosts which may be reserved for other purposes.
+
+
+
+
+
+ The dedicated HA option is set through a special host tag when the host is created. To allow the administrator to dedicate hosts to only HA-enabled VMs, set the global configuration variable ha.tag to the desired tag (for example, "ha_host"), and restart the Management Server. Enter the value in the Host Tags field when adding the host(s) that you want to dedicate to HA-enabled VMs.
+
+
+
+ If you set ha.tag, be sure to actually use that tag on at least one host in your cloud. If the tag specified in ha.tag is not set for any host in the cloud, the HA-enabled VMs will fail to restart after a crash.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/default-account-resource-limit.xml b/docs/tmp/en-US/xml/default-account-resource-limit.xml
new file mode 100644
index 00000000000..46fd8cde0c5
--- /dev/null
+++ b/docs/tmp/en-US/xml/default-account-resource-limit.xml
@@ -0,0 +1,64 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Default Account Resource Limits
+
+ You can limit resource use by accounts. The default limits are set using global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account (max.account.snapshots, etc.)..
+
+
+ To override a default limit for a particular account, set a per-account resource limit.
+
+
+
+
+ Log in to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation tree, click Accounts.
+
+
+
+
+ Select the account you want to modify. The current limits are displayed. A value of -1 shows that there is no limit in place
+
+
+
+
+ Click the Edit button
+
+
+
+
+
+ editbutton.png: edits the settings.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/default-template.xml b/docs/tmp/en-US/xml/default-template.xml
new file mode 100644
index 00000000000..601e7ec5b96
--- /dev/null
+++ b/docs/tmp/en-US/xml/default-template.xml
@@ -0,0 +1,64 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ The Default Template
+
+ &PRODUCT; includes a CentOS template. This template is downloaded by the Secondary Storage VM after the primary and secondary storage are configured. You can use this template in your production deployment or you can delete it and use custom templates.
+
+
+ The root password for the default template is "password".
+
+
+ A default template is provided for each of XenServer, KVM, and vSphere. The templates that are downloaded depend on the hypervisor type that is available in your cloud. Each template is approximately 2.5 GB physical size.
+
+
+ The default template includes the standard iptables rules, which will block most access to the template excluding ssh.
+
+
+# iptables --list
+Chain INPUT (policy ACCEPT)
+target prot opt source destination
+RH-Firewall-1-INPUT all -- anywhere anywhere
+
+Chain FORWARD (policy ACCEPT)
+target prot opt source destination
+RH-Firewall-1-INPUT all -- anywhere anywhere
+
+Chain OUTPUT (policy ACCEPT)
+target prot opt source destination
+
+Chain RH-Firewall-1-INPUT (2 references)
+target prot opt source destination
+ACCEPT all -- anywhere anywhere
+ACCEPT icmp -- anywhere anywhere icmp any
+ACCEPT esp -- anywhere anywhere
+ACCEPT ah -- anywhere anywhere
+ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
+ACCEPT udp -- anywhere anywhere udp dpt:ipp
+ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
+ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
+ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
+REJECT all -- anywhere anywhere reject-with icmp-host-
+
+
+
+
diff --git a/docs/tmp/en-US/xml/delete-reset-vpn.xml b/docs/tmp/en-US/xml/delete-reset-vpn.xml
new file mode 100644
index 00000000000..587c4f96ddf
--- /dev/null
+++ b/docs/tmp/en-US/xml/delete-reset-vpn.xml
@@ -0,0 +1,147 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Restarting and Removing a VPN Connection
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ASLs
+
+
+
+
+
+
+
+
+
+ Select Site-to-Site VPN.
+
+
+ The Site-to-Site VPN page is displayed.
+
+
+
+
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+
+ All the VPN connections you created are displayed.
+
+
+
+
+
+ Select the VPN connection you want to work with.
+
+
+ The Details tab is displayed.
+
+
+
+
+
+ To remove a VPN connection, click the Delete VPN connection button
+
+
+
+
+
+ remove-vpn.png: button to remove a VPN connection
+
+
+
+
+
+ To restart a VPN connection, click the Reset VPN connection button present in the Details tab.
+
+
+
+
+
+ reset-vpn.png: button to reset a VPN connection
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/delete-templates.xml b/docs/tmp/en-US/xml/delete-templates.xml
new file mode 100644
index 00000000000..5adac157832
--- /dev/null
+++ b/docs/tmp/en-US/xml/delete-templates.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Deleting Templates
+
+ Templates may be deleted. In general, when a template spans multiple Zones, only the copy that is selected for deletion will be deleted; the same template in other Zones will not be deleted. The provided CentOS template is an exception to this. If the provided CentOS template is deleted, it will be deleted from all Zones.
+
+
+ When templates are deleted, the VMs instantiated from them will continue to run. However, new VMs cannot be created based on the deleted template.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/deleting-vms.xml b/docs/tmp/en-US/xml/deleting-vms.xml
new file mode 100644
index 00000000000..3eaacff5e0f
--- /dev/null
+++ b/docs/tmp/en-US/xml/deleting-vms.xml
@@ -0,0 +1,66 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Deleting VMs
+
+ Users can delete their own virtual machines. A running virtual machine will be abruptly stopped before it is deleted. Administrators can delete any virtual machines.
+
+
+ To delete a virtual machine:
+
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+ In the left navigation, click Instances.
+
+
+
+
+ Choose the VM that you want to delete.
+
+
+
+
+ Click the Destroy Instance button
+
+
+
+
+
+ Destroyinstance.png: button to destroy an instance
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/dell62xx-hardware.xml b/docs/tmp/en-US/xml/dell62xx-hardware.xml
new file mode 100644
index 00000000000..5c42d71e86d
--- /dev/null
+++ b/docs/tmp/en-US/xml/dell62xx-hardware.xml
@@ -0,0 +1,74 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Dell 62xx
+
+ The following steps show how a Dell 62xx is configured for zone-level layer-3 switching. These steps assume VLAN 201 is used to route untagged private IPs for pod 1, and pod 1’s layer-2 switch is connected to Ethernet port 1/g1.
+
+
+ The Dell 62xx Series switch supports up to 1024 VLANs.
+
+
+
+
+ Configure all the VLANs in the database.
+
+
+vlan database
+vlan 200-999
+exit
+
+
+
+
+ Configure Ethernet port 1/g1.
+
+
+interface ethernet 1/g1
+switchport mode general
+switchport general pvid 201
+switchport general allowed vlan add 201 untagged
+switchport general allowed vlan add 300-999 tagged
+exit
+
+
+
+
+
+ The statements configure Ethernet port 1/g1 as follows:
+
+
+
+
+ VLAN 201 is the native untagged VLAN for port 1/g1.
+
+
+
+
+
+ All VLANs (300-999) are passed to all the pod-level layer-2 switches.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/dell62xx-layer2.xml b/docs/tmp/en-US/xml/dell62xx-layer2.xml
new file mode 100644
index 00000000000..8468549af51
--- /dev/null
+++ b/docs/tmp/en-US/xml/dell62xx-layer2.xml
@@ -0,0 +1,69 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Dell 62xx
+
+ The following steps show how a Dell 62xx is configured for pod-level layer-2 switching.
+
+
+
+
+ Configure all the VLANs in the database.
+
+
+vlan database
+vlan 300-999
+exit
+
+
+
+
+ VLAN 201 is used to route untagged private IP addresses for pod 1, and pod 1 is connected to this layer-2 switch.
+
+
+interface range ethernet all
+switchport mode general
+switchport general allowed vlan add 300-999 tagged
+exit
+
+
+
+
+
+ The statements configure all Ethernet ports to function as follows:
+
+
+
+
+ All ports are configured the same way.
+
+
+
+
+
+ All VLANs (300-999) are passed through all the ports of the layer-2 switch.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/deployment-architecture-overview.xml b/docs/tmp/en-US/xml/deployment-architecture-overview.xml
new file mode 100644
index 00000000000..e7b7425a032
--- /dev/null
+++ b/docs/tmp/en-US/xml/deployment-architecture-overview.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Deployment Architecture Overview
+
+ A &PRODUCT; installation consists of two parts: the Management Server and the cloud infrastructure that it manages. When you set up and manage a &PRODUCT; cloud, you provision resources such as hosts, storage devices, and IP addresses into the Management Server, and the Management Server manages those resources.
+
+
+ The minimum production installation consists of one machine running the &PRODUCT; Management Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure consisting of one host running hypervisor software). In its smallest deployment, a single machine can act as both the Management Server and the hypervisor host (using the KVM hypervisor).
+
+
+
+
+
+
+ basic-deployment.png: Basic two-machine deployment
+
+
+
+
+ A more full-featured installation consists of a highly-available multi-node Management Server installation and up to tens of thousands of hosts using any of several advanced networking setups. For information about deployment options, see Choosing a Deployment Architecture.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/detach-move-volumes.xml b/docs/tmp/en-US/xml/detach-move-volumes.xml
new file mode 100644
index 00000000000..a2638b3b631
--- /dev/null
+++ b/docs/tmp/en-US/xml/detach-move-volumes.xml
@@ -0,0 +1,71 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Attaching a Volume
+
+
+ This procedure is different from moving disk volumes from one storage pool to another. See VM Storage Migration
+
+
+
+ A volume can be detached from a guest VM and attached to another guest. Both &PRODUCT; administrators and users can detach volumes from VMs and move them to other VMs.
+
+
+ If the two VMs are in different clusters, and the volume is large, it may take several minutes for the volume to be moved to the new VM.
+
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+ In the left navigation bar, click Storage, and choose Volumes in Select View. Alternatively, if you know which VM the volume is attached to, you can click Instances, click the VM name, and click View Volumes.
+
+
+
+
+ Click the name of the volume you want to detach, then click the Detach Disk button
+
+
+
+
+
+ DetachDiskButton.png: button to detach a volume
+
+
+
+
+
+
+
+
+ To move the volume to another VM, follow the steps in Attaching a Volume .
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/developer-getting-started.xml b/docs/tmp/en-US/xml/developer-getting-started.xml
new file mode 100644
index 00000000000..26989f283d4
--- /dev/null
+++ b/docs/tmp/en-US/xml/developer-getting-started.xml
@@ -0,0 +1,58 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Getting Started
+
+ To get started using the &PRODUCT; API, you should have the following:
+
+
+
+
+ URL of the &PRODUCT; server you wish to integrate with.
+
+
+
+
+ Both the API Key and Secret Key for an account. This should have been generated by the administrator of the cloud instance and given to you.
+
+
+
+
+ Familiarity with HTTP GET/POST and query strings.
+
+
+
+
+ Knowledge of either XML or JSON.
+
+
+
+
+ Knowledge of a programming language that can generate HTTP requests; for example, Java or PHP.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/developer-guide.xml b/docs/tmp/en-US/xml/developer-guide.xml
new file mode 100644
index 00000000000..402869882df
--- /dev/null
+++ b/docs/tmp/en-US/xml/developer-guide.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using the API
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/developer-introduction.xml b/docs/tmp/en-US/xml/developer-introduction.xml
new file mode 100644
index 00000000000..b1e37947805
--- /dev/null
+++ b/docs/tmp/en-US/xml/developer-introduction.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Introduction for Developers
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/developer_guide.xml b/docs/tmp/en-US/xml/developer_guide.xml
new file mode 100644
index 00000000000..62c302bc96e
--- /dev/null
+++ b/docs/tmp/en-US/xml/developer_guide.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Developer Guide
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/disable-enable-zones-pods-clusters.xml b/docs/tmp/en-US/xml/disable-enable-zones-pods-clusters.xml
new file mode 100644
index 00000000000..0d1a04b6d44
--- /dev/null
+++ b/docs/tmp/en-US/xml/disable-enable-zones-pods-clusters.xml
@@ -0,0 +1,100 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/disk-volume-usage-record-format.xml b/docs/tmp/en-US/xml/disk-volume-usage-record-format.xml
new file mode 100644
index 00000000000..cc580ff924a
--- /dev/null
+++ b/docs/tmp/en-US/xml/disk-volume-usage-record-format.xml
@@ -0,0 +1,103 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Disk Volume Usage Record Format
+
+ For disk volumes, the following fields exist in a usage record.
+
+
+
+
+ account – name of the account
+
+
+
+
+ accountid – ID of the account
+
+
+
+
+ domainid – ID of the domain in which this account resides
+
+
+
+
+ zoneid – Zone where the usage occurred
+
+
+
+
+ description – A string describing what the usage record is tracking
+
+
+
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+
+
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+
+
+
+ rawusage – A number representing the actual usage in hours
+
+
+
+
+ usageid – The volume ID
+
+
+
+
+ offeringid – The ID of the disk offering
+
+
+
+
+ type – Hypervisor
+
+
+
+
+ templateid – ROOT template ID
+
+
+
+
+ size – The amount of storage allocated
+
+
+
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/dns-dhcp.xml b/docs/tmp/en-US/xml/dns-dhcp.xml
new file mode 100644
index 00000000000..9071b7bb3b3
--- /dev/null
+++ b/docs/tmp/en-US/xml/dns-dhcp.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ DNS and DHCP
+
+ The Virtual Router provides DNS and DHCP services to the guests. It proxies DNS requests to the DNS server configured on the Availability Zone.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/domains.xml b/docs/tmp/en-US/xml/domains.xml
new file mode 100644
index 00000000000..46577a98c13
--- /dev/null
+++ b/docs/tmp/en-US/xml/domains.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Domains
+
+ 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.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/enable-disable-static-nat-vpc.xml b/docs/tmp/en-US/xml/enable-disable-static-nat-vpc.xml
new file mode 100644
index 00000000000..c33f0aa9a5b
--- /dev/null
+++ b/docs/tmp/en-US/xml/enable-disable-static-nat-vpc.xml
@@ -0,0 +1,154 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Enabling or Disabling Static NAT on a VPC
+
+ A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to allow Internet traffic to it. This section tells how to enable or disable static NAT for a particular IP address in a VPC.
+
+
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+
+
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ACLs
+
+
+
+
+
+
+
+
+
+ Select IP Addresses.
+
+
+ The IP Addresses page is displayed.
+
+
+
+
+
+ Click the IP you want to work with.
+
+
+
+
+
+ In the Details tab,click the Static NAT button.
+
+
+
+
+
+ enable-disable.png: button to enable Statid NAT.
+
+
+
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+
+
+
+
+
+ If you are enabling static NAT, a dialog appears as follows:
+
+
+
+
+
+
+ select-vmstatic-nat.png: selecting a tier to apply staticNAT.
+
+
+
+
+
+
+
+ Select the tier and the destination VM, then click Apply.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/enable-disable-static-nat.xml b/docs/tmp/en-US/xml/enable-disable-static-nat.xml
new file mode 100644
index 00000000000..ee222aa8fc9
--- /dev/null
+++ b/docs/tmp/en-US/xml/enable-disable-static-nat.xml
@@ -0,0 +1,81 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Enabling or Disabling Static NAT
+
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+
+
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+ Click the name of the network where you want to work with.
+
+
+
+
+ Click View IP Addresses.
+
+
+
+
+ Click the IP address you want to work with.
+
+
+
+
+
+ Click the Static NAT button.
+
+
+
+
+
+ ReleaseIPButton.png: button to release an IP
+
+
+
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+
+
+
+
+ If you are enabling static NAT, a dialog appears where you can choose the destination VM and click Apply
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/enable-security-groups.xml b/docs/tmp/en-US/xml/enable-security-groups.xml
new file mode 100644
index 00000000000..d1bd47abf23
--- /dev/null
+++ b/docs/tmp/en-US/xml/enable-security-groups.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Enabling Security Groups
+
+ In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/enabling-api-call-expiration.xml b/docs/tmp/en-US/xml/enabling-api-call-expiration.xml
new file mode 100644
index 00000000000..5e1d13edf2b
--- /dev/null
+++ b/docs/tmp/en-US/xml/enabling-api-call-expiration.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Enabling API Call Expiration
+
+ You can set an expiry timestamp on API calls to prevent replay attacks over non-secure channels, such as HTTP. The server tracks the expiry timestamp you have specified and rejects all the subsequent API requests that come in after this validity period.
+
+
+ To enable this feature, add the following parameters to the API request:
+
+
+
+
+ signatureVersion=3: If the signatureVersion parameter is missing or is not equal to 3, the expires parameter is ignored in the API request.
+
+
+
+
+ expires=YYYY-MM-DDThh:mm:ssZ: Specifies the date and time at which the signature included in the request is expired. The timestamp is expressed in the YYYY-MM-DDThh:mm:ssZ format, as specified in the ISO 8601 standard.
+
+
+
+
+
+ For example:
+
+
+expires=2011-10-10T12:00:00+0530
+
+ A sample API request with expiration is given below:
+
+
+http://<IPAddress>:8080/client/api?command=listZones&signatureVersion=3&expires=2011-10-10T12:00:00+0530&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+
+
+
diff --git a/docs/tmp/en-US/xml/enabling-port-8096.xml b/docs/tmp/en-US/xml/enabling-port-8096.xml
new file mode 100644
index 00000000000..1aae14fbd67
--- /dev/null
+++ b/docs/tmp/en-US/xml/enabling-port-8096.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Enabling Port 8096
+
+ Port 8096, which allows API calls without authentication, is closed and disabled by default on any fresh 3.0.1 installations. You can enable 8096 (or another port) for this purpose as follows:
+
+
+
+
+ Ensure that the first Management Server is installed and running.
+
+
+
+
+ Set the global configuration parameter integration.api.port to the desired port.
+
+
+
+
+ Restart the Management Server.
+
+
+
+
+ On the Management Server host machine, create an iptables rule allowing access to that port.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/end-user-ui-overview.xml b/docs/tmp/en-US/xml/end-user-ui-overview.xml
new file mode 100644
index 00000000000..c1d7875b226
--- /dev/null
+++ b/docs/tmp/en-US/xml/end-user-ui-overview.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ End User's UI Overview
+
+ The &PRODUCT; 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 &PRODUCT; projects, the UI can provide a project-oriented view.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/error-handling.xml b/docs/tmp/en-US/xml/error-handling.xml
new file mode 100644
index 00000000000..b26b55f3dcb
--- /dev/null
+++ b/docs/tmp/en-US/xml/error-handling.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Error Handling
+
+ If an error occurs while processing an API request, the appropriate response in the format specified is returned. Each error response consists of an error code and an error text describing what possibly can go wrong. For an example error response, see page 12.
+
+
+ An HTTP error code of 401 is always returned if API request was rejected due to bad signatures, missing API Keys, or the user simply did not have the permissions to execute the command.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/event-log-queries.xml b/docs/tmp/en-US/xml/event-log-queries.xml
new file mode 100644
index 00000000000..68649a3d170
--- /dev/null
+++ b/docs/tmp/en-US/xml/event-log-queries.xml
@@ -0,0 +1,64 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/event-types.xml b/docs/tmp/en-US/xml/event-types.xml
new file mode 100644
index 00000000000..e83a86574bb
--- /dev/null
+++ b/docs/tmp/en-US/xml/event-types.xml
@@ -0,0 +1,701 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Event Types
+
+
+
+
+
+
+
+
+ VM.CREATE
+
+
+
+
+ TEMPLATE.EXTRACT
+
+
+
+
+ SG.REVOKE.INGRESS
+
+
+
+
+
+
+
+ VM.DESTROY
+
+
+
+
+ TEMPLATE.UPLOAD
+
+
+
+
+ HOST.RECONNECT
+
+
+
+
+
+
+
+ VM.START
+
+
+
+
+ TEMPLATE.CLEANUP
+
+
+
+
+ MAINT.CANCEL
+
+
+
+
+
+
+
+ VM.STOP
+
+
+
+
+ VOLUME.CREATE
+
+
+
+
+ MAINT.CANCEL.PS
+
+
+
+
+
+
+
+ VM.REBOOT
+
+
+
+
+ VOLUME.DELETE
+
+
+
+
+ MAINT.PREPARE
+
+
+
+
+
+
+
+ VM.UPGRADE
+
+
+
+
+ VOLUME.ATTACH
+
+
+
+
+ MAINT.PREPARE.PS
+
+
+
+
+
+
+
+ VM.RESETPASSWORD
+
+
+
+
+ VOLUME.DETACH
+
+
+
+
+ VPN.REMOTE.ACCESS.CREATE
+
+
+
+
+
+
+
+ ROUTER.CREATE
+
+
+
+
+ VOLUME.UPLOAD
+
+
+
+
+ VPN.USER.ADD
+
+
+
+
+
+
+
+ ROUTER.DESTROY
+
+
+
+
+ SERVICEOFFERING.CREATE
+
+
+
+
+ VPN.USER.REMOVE
+
+
+
+
+
+
+
+ ROUTER.START
+
+
+
+
+ SERVICEOFFERING.UPDATE
+
+
+
+
+ NETWORK.RESTART
+
+
+
+
+
+
+
+ ROUTER.STOP
+
+
+
+
+ SERVICEOFFERING.DELETE
+
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+
+
+
+
+ ROUTER.REBOOT
+
+
+
+
+ DOMAIN.CREATE
+
+
+
+
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+
+
+
+
+
+ ROUTER.HA
+
+
+
+
+ DOMAIN.DELETE
+
+
+
+
+ STATICNAT.DISABLE
+
+
+
+
+
+
+
+ PROXY.CREATE
+
+
+
+
+ DOMAIN.UPDATE
+
+
+
+
+ SSVM.CREATE
+
+
+
+
+
+
+
+ PROXY.DESTROY
+
+
+
+
+ SNAPSHOT.CREATE
+
+
+
+
+ SSVM.DESTROY
+
+
+
+
+
+
+
+ PROXY.START
+
+
+
+
+ SNAPSHOT.DELETE
+
+
+
+
+ SSVM.START
+
+
+
+
+
+
+
+ PROXY.STOP
+
+
+
+
+ SNAPSHOTPOLICY.CREATE
+
+
+
+
+ SSVM.STOP
+
+
+
+
+
+
+
+ PROXY.REBOOT
+
+
+
+
+ SNAPSHOTPOLICY.UPDATE
+
+
+
+
+ SSVM.REBOOT
+
+
+
+
+
+
+
+ PROXY.HA
+
+
+
+
+ SNAPSHOTPOLICY.DELETE
+
+
+
+
+ SSVM.H
+
+
+
+
+
+
+
+ VNC.CONNECT
+
+
+
+
+ VNC.DISCONNECT
+
+
+
+
+ NET.IPASSIGN
+
+
+
+
+
+
+
+ NET.IPRELEASE
+
+
+
+
+ NET.RULEADD
+
+
+
+
+ NET.RULEDELETE
+
+
+
+
+
+
+
+ NET.RULEMODIFY
+
+
+
+
+ NETWORK.CREATE
+
+
+
+
+ NETWORK.DELETE
+
+
+
+
+
+
+
+ LB.ASSIGN.TO.RULE
+
+
+
+
+ LB.REMOVE.FROM.RULE
+
+
+
+
+ LB.CREATE
+
+
+
+
+
+
+
+ LB.DELETE
+
+
+
+
+ LB.UPDATE
+
+
+
+
+ USER.LOGIN
+
+
+
+
+
+
+
+ USER.LOGOUT
+
+
+
+
+ USER.CREATE
+
+
+
+
+ USER.DELETE
+
+
+
+
+
+
+
+ USER.UPDATE
+
+
+
+
+ USER.DISABLE
+
+
+
+
+ TEMPLATE.CREATE
+
+
+
+
+
+
+
+ TEMPLATE.DELETE
+
+
+
+
+ TEMPLATE.UPDATE
+
+
+
+
+ TEMPLATE.COPY
+
+
+
+
+
+
+
+ TEMPLATE.DOWNLOAD.START
+
+
+
+
+ TEMPLATE.DOWNLOAD.SUCCESS
+
+
+
+
+ TEMPLATE.DOWNLOAD.FAILED
+
+
+
+
+
+
+
+ ISO.CREATE
+
+
+
+
+ ISO.DELETE
+
+
+
+
+ ISO.COPY
+
+
+
+
+
+
+
+ ISO.ATTACH
+
+
+
+
+ ISO.DETACH
+
+
+
+
+ ISO.EXTRACT
+
+
+
+
+
+
+
+ ISO.UPLOAD
+
+
+
+
+ SERVICE.OFFERING.CREATE
+
+
+
+
+ SERVICE.OFFERING.EDIT
+
+
+
+
+
+
+
+ SERVICE.OFFERING.DELETE
+
+
+
+
+ DISK.OFFERING.CREATE
+
+
+
+
+ DISK.OFFERING.EDIT
+
+
+
+
+
+
+
+ DISK.OFFERING.DELETE
+
+
+
+
+ NETWORK.OFFERING.CREATE
+
+
+
+
+ NETWORK.OFFERING.EDIT
+
+
+
+
+
+
+
+ NETWORK.OFFERING.DELETE
+
+
+
+
+ POD.CREATE
+
+
+
+
+ POD.EDIT
+
+
+
+
+
+
+
+ POD.DELETE
+
+
+
+
+ ZONE.CREATE
+
+
+
+
+ ZONE.EDIT
+
+
+
+
+
+
+
+ ZONE.DELETE
+
+
+
+
+ VLAN.IP.RANGE.CREATE
+
+
+
+
+ VLAN.IP.RANGE.DELETE
+
+
+
+
+
+
+
+ CONFIGURATION.VALUE.EDIT
+
+
+
+
+ SG.AUTH.INGRESS
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/events-log.xml b/docs/tmp/en-US/xml/events-log.xml
new file mode 100644
index 00000000000..db3ca58b247
--- /dev/null
+++ b/docs/tmp/en-US/xml/events-log.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Event Logs
+
+ There are two types of events logged in the &PRODUCT; 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..
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/events.xml b/docs/tmp/en-US/xml/events.xml
new file mode 100644
index 00000000000..8c852697b4d
--- /dev/null
+++ b/docs/tmp/en-US/xml/events.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Events
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/example-LDAP-configuration-commands.xml b/docs/tmp/en-US/xml/example-LDAP-configuration-commands.xml
new file mode 100644
index 00000000000..4e4d57d9a52
--- /dev/null
+++ b/docs/tmp/en-US/xml/example-LDAP-configuration-commands.xml
@@ -0,0 +1,59 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Example LDAP Configuration Commands
+
+ To understand the examples in this section, you need to know the basic concepts behind calling the &PRODUCT; API, which are explained in the Developer’s Guide.
+
+
+ The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
+
+
+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:
+
+
+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.
+
+
+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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/example-response-from-listUsageRecords.xml b/docs/tmp/en-US/xml/example-response-from-listUsageRecords.xml
new file mode 100644
index 00000000000..c5bc1384fe7
--- /dev/null
+++ b/docs/tmp/en-US/xml/example-response-from-listUsageRecords.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Example response from listUsageRecords
+
+ All &PRODUCT; API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+
+
+
+ <listusagerecordsresponse>
+ <count>1816</count>
+ <usagerecord>
+ <account>user5</account>
+ <accountid>10004</accountid>
+ <domainid>1</domainid>
+ <zoneid>1</zoneid>
+ <description>i-3-4-WC running time (ServiceOffering: 1) (Template: 3)</description>
+ <usage>2.95288 Hrs</usage>
+ <usagetype>1</usagetype>
+ <rawusage>2.95288</rawusage>
+ <virtualmachineid>4</virtualmachineid>
+ <name>i-3-4-WC</name>
+ <offeringid>1</offeringid>
+ <templateid>3</templateid>
+ <usageid>245554</usageid>
+ <type>XenServer</type>
+ <startdate>2009-09-15T00:00:00-0700</startdate>
+ <enddate>2009-09-18T16:14:26-0700</enddate>
+ </usagerecord>
+
+ … (1,815 more usage records)
+ </listusagerecordsresponse>
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/export-template.xml b/docs/tmp/en-US/xml/export-template.xml
new file mode 100644
index 00000000000..2e6120bc0cd
--- /dev/null
+++ b/docs/tmp/en-US/xml/export-template.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Exporting Templates
+
+ End users and Administrators may export templates from the &PRODUCT;. Navigate to the template in the UI and choose the Download function from the Actions menu.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/external-firewalls-and-load-balancers.xml b/docs/tmp/en-US/xml/external-firewalls-and-load-balancers.xml
new file mode 100644
index 00000000000..e78624ea6ec
--- /dev/null
+++ b/docs/tmp/en-US/xml/external-firewalls-and-load-balancers.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ External Firewalls and Load Balancers
+
+ &PRODUCT; is capable of replacing its Virtual Router with an external Juniper SRX device and an optional external NetScaler or F5 load balancer for gateway and load balancing services. In this case, the VMs use the SRX as their gateway.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/external-fw-topology-req.xml b/docs/tmp/en-US/xml/external-fw-topology-req.xml
new file mode 100644
index 00000000000..f30f226c70a
--- /dev/null
+++ b/docs/tmp/en-US/xml/external-fw-topology-req.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ External Firewall Topology Requirements
+
+ When external firewall integration is in place, the public IP VLAN must still be trunked to the Hosts. This is required to support the Secondary Storage VM and Console Proxy VM.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/external-guest-firewall-integration.xml b/docs/tmp/en-US/xml/external-guest-firewall-integration.xml
new file mode 100644
index 00000000000..04d05196214
--- /dev/null
+++ b/docs/tmp/en-US/xml/external-guest-firewall-integration.xml
@@ -0,0 +1,287 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ External Guest Firewall Integration for Juniper SRX (Optional)
+
+
+ Available only for guests using advanced networking.
+
+
+
+
+ &PRODUCT; provides for direct management of the Juniper SRX series of firewalls. This enables &PRODUCT; to establish static NAT mappings from public IPs to guest VMs, and to use the Juniper device in place of the virtual router for firewall services. You can have one or more Juniper SRX per zone. This feature is optional. If Juniper integration is not provisioned, &PRODUCT; will use the virtual router for these services.
+
+
+ The Juniper SRX can optionally be used in conjunction with an external load balancer. External Network elements can be deployed in a side-by-side or inline configuration.
+
+
+
+
+
+
+ parallel-mode.png: adding a firewall and load balancer in parallel mode.
+
+
+
+
+ &PRODUCT; requires the Juniper to be configured as follows:
+
+
+
+ Supported SRX software version is 10.3 or higher.
+
+
+
+
+
+
+ Install your SRX appliance according to the vendor's instructions.
+
+
+
+
+
+ Connect one interface to the management network and one interface to the public network. Alternatively, you can connect the same interface to both networks and a use a VLAN for the public network.
+
+
+
+
+
+ Make sure "vlan-tagging" is enabled on the private interface.
+
+
+
+
+
+ Record the public and private interface names. If you used a VLAN for the public interface, add a ".[VLAN TAG]" after the interface name. For example, if you are using ge-0/0/3 for your public interface and VLAN tag 301, your public interface name would be "ge-0/0/3.301". Your private interface name should always be untagged because the &PRODUCT; software automatically creates tagged logical interfaces.
+
+
+
+
+
+ Create a public security zone and a private security zone. By default, these will already exist and will be called "untrust" and "trust". Add the public interface to the public zone and the private interface to the private zone. Note down the security zone names.
+
+
+
+
+
+ Make sure there is a security policy from the private zone to the public zone that allows all traffic.
+
+
+
+
+
+ Note the username and password of the account you want the &PRODUCT; software to log in to when it is programming rules.
+
+
+
+
+
+ Make sure the "ssh" and "xnm-clear-text" system services are enabled.
+
+
+
+
+
+ If traffic metering is desired:
+
+
+
+
+ a. Create an incoming firewall filter and an outgoing firewall filter. These filters should be the same names as your public security zone name and private security zone name respectively. The filters should be set to be "interface-specific". For example, here is the configuration where the public zone is "untrust" and the private zone is "trust":
+
+
+root@cloud-srx# show firewall
+filter trust {
+ interface-specific;
+}
+filter untrust {
+ interface-specific;
+}
+
+
+
+
+ Add the firewall filters to your public interface. For example, a sample configuration output (for public interface ge-0/0/3.0, public security zone untrust, and private security zone trust) is:
+
+
+ge-0/0/3 {
+ unit 0 {
+ family inet {
+ filter {
+ input untrust;
+ output trust;
+ }
+ address 172.25.0.252/16;
+ }
+ }
+}
+
+
+
+
+
+
+
+
+ Make sure all VLANs are brought to the private interface of the SRX.
+
+
+
+
+
+ After the &PRODUCT; Management Server is installed, log in to the &PRODUCT; UI as administrator.
+
+
+
+
+
+ In the left navigation bar, click Infrastructure.
+
+
+
+
+
+ In Zones, click View More.
+
+
+
+
+
+ Choose the zone you want to work with.
+
+
+
+
+
+ Click the Network tab.
+
+
+
+
+
+ In the Network Service Providers node of the diagram, click Configure. (You might have to scroll down to see this.)
+
+
+
+
+
+ Click SRX.
+
+
+
+
+
+ Click the Add New SRX button (+) and provide the following:
+
+
+
+
+ IP Address: The IP address of the SRX.
+
+
+
+
+
+ Username: The user name of the account on the SRX that &PRODUCT; should use.
+
+
+
+
+
+ Password: The password of the account.
+
+
+
+
+
+ Public Interface. The name of the public interface on the SRX. For example, ge-0/0/2. A ".x" at the end of the interface indicates the VLAN that is in use.
+
+
+
+
+
+ Private Interface: The name of the private interface on the SRX. For example, ge-0/0/1.
+
+
+
+
+
+ Usage Interface: (Optional) Typically, the public interface is used to meter traffic. If you want to use a different interface, specify its name here
+
+
+
+
+
+ Number of Retries: The number of times to attempt a command on the SRX before failing. The default value is 2.
+
+
+
+
+
+ Timeout (seconds): The time to wait for a command on the SRX before considering it failed. Default is 300 seconds.
+
+
+
+
+
+ Public Network: The name of the public network on the SRX. For example, trust.
+
+
+
+
+
+ Private Network: The name of the private network on the SRX. For example, untrust.
+
+
+
+
+
+ Capacity: The number of networks the device can handle
+
+
+
+
+
+ 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
+
+
+
+
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+ Click Global Settings. Set the parameter external.network.stats.interval to indicate how often you want &PRODUCT; to fetch network usage statistics from the Juniper SRX. If you are not using the SRX to gather network usage statistics, set to 0.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/external-guest-lb-integration.xml b/docs/tmp/en-US/xml/external-guest-lb-integration.xml
new file mode 100644
index 00000000000..0077453fe21
--- /dev/null
+++ b/docs/tmp/en-US/xml/external-guest-lb-integration.xml
@@ -0,0 +1,168 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ External Guest Load Balancer Integration (Optional)
+
+ &PRODUCT; can optionally use a Citrix NetScaler or BigIP F5 load balancer to provide load balancing services to guests. If this is not enabled, &PRODUCT; will use the software load balancer in the virtual router.
+
+
+ To install and enable an external load balancer for &PRODUCT; management:
+
+
+
+
+ Set up the appliance according to the vendor's directions.
+
+
+
+
+
+ Connect it to the networks carrying public traffic and management traffic (these could be the same network).
+
+
+
+
+
+ Record the IP address, username, password, public interface name, and private interface name. The interface names will be something like "1.1" or "1.2".
+
+
+
+
+
+ Make sure that the VLANs are trunked to the management network interface.
+
+
+
+
+
+ After the &PRODUCT; Management Server is installed, log in as administrator to the &PRODUCT; UI.
+
+
+
+
+
+ In the left navigation bar, click Infrastructure.
+
+
+
+
+
+ In Zones, click View More.
+
+
+
+
+
+ Choose the zone you want to work with.
+
+
+
+
+
+ Click the Network tab.
+
+
+
+
+
+ In the Network Service Providers node of the diagram, click Configure. (You might have to scroll down to see this.)
+
+
+
+
+
+ Click NetScaler or F5.
+
+
+
+
+
+ Click the Add button (+) and provide the following:
+
+
+ For NetScaler:
+
+
+
+
+ IP Address: The IP address of the SRX.
+
+
+
+
+
+ Username/Password: The authentication credentials to access the device. &PRODUCT; uses these credentials to access the device.
+
+
+
+
+
+ Type: The type of device that is being added. It could be F5 Big Ip Load Balancer, NetScaler VPX, NetScaler MPX, or NetScaler SDX. For a comparison of the NetScaler types, see the &PRODUCT; Administration Guide.
+
+
+
+
+
+ Public interface: Interface of device that is configured to be part of the public network.
+
+
+
+
+
+ Private interface: Interface of device 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: The number of networks the device can handle.
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+ The installation and provisioning of the external load balancer is finished. You can proceed to add VMs and NAT or load balancing rules.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/extracting-source.xml b/docs/tmp/en-US/xml/extracting-source.xml
new file mode 100644
index 00000000000..07f1a562eb7
--- /dev/null
+++ b/docs/tmp/en-US/xml/extracting-source.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Extracting source
+
+ Extracting the &PRODUCT; release is relatively simple and can be done with a single command as follows:
+$tar -jxvf apache-cloudstack-4.0.0-incubating-src.tar.bz2
+
+
+
+ You can now move into the directory:
+$cd ./apache-cloudstack-4.0.0-incubating-src
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/feature-overview.xml b/docs/tmp/en-US/xml/feature-overview.xml
new file mode 100644
index 00000000000..452a594e6a6
--- /dev/null
+++ b/docs/tmp/en-US/xml/feature-overview.xml
@@ -0,0 +1,68 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ What Can &PRODUCT; Do?
+
+ Multiple Hypervisor Support
+
+
+ &PRODUCT; works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of &PRODUCT; supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+
+ Massively Scalable Infrastructure Management
+
+
+ &PRODUCT; can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+
+ Automatic Configuration Management
+
+
+ &PRODUCT; automatically configures each guest virtual machine’s networking and storage settings.
+
+
+ &PRODUCT; internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+
+ Graphical User Interface
+
+
+ &PRODUCT; offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+
+ API and Extensibility
+
+
+ &PRODUCT; provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at Apache CloudStack Guides and Apache CloudStack API Reference respectively.
+
+
+ The &PRODUCT; pluggable allocation architecture allows the creation of new types of allocators for the selection of storage and Hosts. See the Allocator Implementation Guide (http://docs.cloudstack.org/CloudStack_Documentation/Allocator_Implementation_Guide).
+
+
+ High Availability
+
+
+ &PRODUCT; has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the hosts, &PRODUCT; supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/firewall-rules.xml b/docs/tmp/en-US/xml/firewall-rules.xml
new file mode 100644
index 00000000000..13a8481bfae
--- /dev/null
+++ b/docs/tmp/en-US/xml/firewall-rules.xml
@@ -0,0 +1,100 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Firewall Rules
+
+ By default, all incoming traffic to the public IP address is rejected by the firewall. To allow external traffic, you can open firewall ports by specifying firewall rules. You can optionally specify one or more CIDRs to filter the source IPs. This is useful when you want to allow only incoming requests from certain IP addresses.
+
+
+ You cannot use firewall rules to open ports for an elastic IP address. When elastic IP is used, outside access is instead controlled through the use of security groups. See .
+
+
+ Firewall rules can be created using the Firewall tab in the Management Server UI. This tab is not displayed by default when &PRODUCT; is installed. To display the Firewall tab, the &PRODUCT; administrator must set the global configuration parameter firewall.rule.ui.enabled to "true."
+
+
+ To create a firewall rule:
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+ Click the name of the network where you want to work with.
+
+
+
+
+ Click View IP Addresses.
+
+
+
+
+ Click the IP address you want to work with.
+
+
+
+
+
+ Click the Configuration tab and fill in the following values.
+
+
+
+
+ Source CIDR. (Optional) To accept only traffic from IP addresses within a particular address block, enter a CIDR or a comma-separated list of CIDRs. Example: 192.168.0.0/22. Leave empty to allow all CIDRs.
+
+
+
+
+ Protocol. The communication protocol in use on the opened port(s).
+
+
+
+
+ Start Port and End Port. The port(s) you want to open on the firewall. If you are opening a single port, use the same number in both fields
+
+
+
+
+ ICMP Type and ICMP Code. Used only if Protocol is set to ICMP. Provide the type and code required by the ICMP protocol to fill out the ICMP header. Refer to ICMP documentation for more details if you are not sure what to enter
+
+
+
+
+
+
+
+ Click Add
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/first_ms_node_install.xml b/docs/tmp/en-US/xml/first_ms_node_install.xml
new file mode 100644
index 00000000000..a1693cdd7fa
--- /dev/null
+++ b/docs/tmp/en-US/xml/first_ms_node_install.xml
@@ -0,0 +1,58 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install the First Management Server
+
+
+
+ Ensure you have configured your machine according to or as appropriate for your platform.
+
+
+
+
+
+ Install the &PRODUCT; management server packages by issuing one of the following commands as appropriate:
+#yum install cloud-client
+
+#apt-get install cloud-client
+
+
+
+
+
+
+ (RPM-based distributions) When the installation is finished, run the following commands to start essential services:
+
+
+#service rpcbind start
+#service nfs start
+#chkconfig nfs on
+#chkconfig rpcbind on
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/generic-firewall-provisions.xml b/docs/tmp/en-US/xml/generic-firewall-provisions.xml
new file mode 100644
index 00000000000..51a724995f6
--- /dev/null
+++ b/docs/tmp/en-US/xml/generic-firewall-provisions.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Generic Firewall Provisions
+
+ The hardware firewall is required to serve two purposes:
+
+
+
+
+ Protect the Management Servers. NAT and port forwarding should be configured to direct traffic from the public Internet to the Management Servers.
+
+
+
+
+
+ Route management network traffic between multiple zones. Site-to-site VPN should be configured between multiple zones.
+
+
+
+
+
+
+ To achieve the above purposes you must set up fixed configurations for the firewall. Firewall rules and policies need not change as users are provisioned into the cloud. Any brand of hardware firewall that supports NAT and site-to-site VPN can be used.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/getting-release.xml b/docs/tmp/en-US/xml/getting-release.xml
new file mode 100644
index 00000000000..ddecfb34dea
--- /dev/null
+++ b/docs/tmp/en-US/xml/getting-release.xml
@@ -0,0 +1,59 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Getting the release
+
+ You can download the latest &PRODUCT; release from the Apache CloudStack project download page.
+
+
+ You'll notice several links under the 'Latest release' section.
+
+
+
+
+ apache-cloudstack-4.0.0-incubating-src.tar.bz2 - This is the link to the release itself.
+
+
+
+
+
+ PGP - This is a detached cryptographic signature that can be used to help verify the authenticity of the release.
+
+
+
+
+
+ MD5 - An MD5 hash of the release to aid in verify the validity of the release download.
+
+
+
+
+
+ SHA512 - A SHA512 hash of the release to aid in verify the validity of the release download.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/global-config.xml b/docs/tmp/en-US/xml/global-config.xml
new file mode 100644
index 00000000000..83e7d8cbba0
--- /dev/null
+++ b/docs/tmp/en-US/xml/global-config.xml
@@ -0,0 +1,74 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Global Configuration Parameters
+
+ &PRODUCT; provides parameters that you can set to control many aspects of the cloud. When &PRODUCT; is first installed, and periodically thereafter, you might need to modify these settings.
+
+
+
+
+ Log in to the UI as administrator.
+
+
+
+
+
+ In the left navigation bar, click Global Settings.
+
+
+
+
+
+ In Select View, choose one of the following:
+
+
+
+
+ Global Settings. This displays a list of the parameters with brief descriptions and current values.
+
+
+
+
+
+ Hypervisor Capabilities. This displays a list of hypervisor versions with the maximum number of guests supported for each.
+
+
+
+
+
+
+
+
+
+ Use the search box to narrow down the list to those you are interested in.
+
+
+
+
+
+ Click the Edit icon to modify a value. If you are viewing Hypervisor Capabilities, you must click the name of the hypervisor first to display the editing screen.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/globally-configured-limit.xml b/docs/tmp/en-US/xml/globally-configured-limit.xml
new file mode 100644
index 00000000000..a60d1369381
--- /dev/null
+++ b/docs/tmp/en-US/xml/globally-configured-limit.xml
@@ -0,0 +1,216 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Globally Configured Limits
+
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+
+
+ The following table lists limits set in the Global Configuration:
+
+
+
+
+
+
+
+ Parameter Name
+
+
+
+
+ Definition
+
+
+
+
+
+
+
+
+
+
+ max.account.public.ips
+
+
+
+
+ Number of public IP addresses that can be owned by an account
+
+
+
+
+
+
+
+ max.account.snapshots
+
+
+
+
+ Number of snapshots that can exist for an account
+
+
+
+
+
+
+
+ max.account.templates
+
+
+
+
+ Number of templates that can exist for an account
+
+
+
+
+
+
+
+ max.account.user.vms
+
+
+
+
+ Number of virtual machine instances that can exist for an account
+
+
+
+
+
+
+
+ max.account.volumes
+
+
+
+
+ Number of disk volumes that can exist for an account
+
+
+
+
+
+
+
+ max.template.iso.size
+
+
+
+
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+
+
+
+
+ max.volume.size.gb
+
+
+
+
+ Maximum size for a volume in GB
+
+
+
+
+
+
+
+ network.throttling.rate
+
+
+
+
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+
+
+
+
+
+ snapshot.max.hourly
+
+
+
+
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+
+
+
+
+ snapshot.max.daily
+
+
+
+
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+
+
+
+
+
+ snapshot.max.weekly
+
+
+
+
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+
+
+
+
+ snapshot.max.monthly
+
+
+
+
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+
+
+
+
+
+
+
+
+
+ To modify global configuration parameters, use the global configuration screen in the &PRODUCT; UI. See Setting Global Configuration Parameters
+
+
+
+
diff --git a/docs/tmp/en-US/xml/globally-configured-limits.xml b/docs/tmp/en-US/xml/globally-configured-limits.xml
new file mode 100644
index 00000000000..26925aad2b2
--- /dev/null
+++ b/docs/tmp/en-US/xml/globally-configured-limits.xml
@@ -0,0 +1,216 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Globally Configured Limits
+
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+
+
+ The following table lists limits set in the Global Configuration:
+
+
+
+
+
+
+
+ Parameter Name
+
+
+
+
+ Definition
+
+
+
+
+
+
+
+
+
+
+ max.account.public.ips
+
+
+
+
+ Number of public IP addresses that can be owned by an account
+
+
+
+
+
+
+
+ max.account.snapshots
+
+
+
+
+ Number of snapshots that can exist for an account
+
+
+
+
+
+
+
+ max.account.templates
+
+
+
+
+ Number of templates that can exist for an account
+
+
+
+
+
+
+
+ max.account.user.vms
+
+
+
+
+ Number of virtual machine instances that can exist for an account
+
+
+
+
+
+
+
+ max.account.volumes
+
+
+
+
+ Number of disk volumes that can exist for an account
+
+
+
+
+
+
+
+ max.template.iso.size
+
+
+
+
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+
+
+
+
+ max.volume.size.gb
+
+
+
+
+ Maximum size for a volume in GB
+
+
+
+
+
+
+
+ network.throttling.rate
+
+
+
+
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+
+
+
+
+
+ snapshot.max.hourly
+
+
+
+
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+
+
+
+
+ snapshot.max.daily
+
+
+
+
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+
+
+
+
+
+ snapshot.max.weekly
+
+
+
+
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+
+
+
+
+ snapshot.max.monthly
+
+
+
+
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+
+
+
+
+
+
+
+
+
+ To modify global configuration parameters, use the global configuration screen in the &PRODUCT; UI. See Setting Global Configuration Parameters
+
+
+
+
diff --git a/docs/tmp/en-US/xml/guest-ip-ranges.xml b/docs/tmp/en-US/xml/guest-ip-ranges.xml
new file mode 100644
index 00000000000..67924d9e255
--- /dev/null
+++ b/docs/tmp/en-US/xml/guest-ip-ranges.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Guest IP Ranges
+
+ The IP ranges for guest network traffic are set on a per-account basis by the user. This allows the users to configure their network in a fashion that will enable VPN linking between their guest network and their clients.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/guest-network.xml b/docs/tmp/en-US/xml/guest-network.xml
new file mode 100644
index 00000000000..db0ae84e6e7
--- /dev/null
+++ b/docs/tmp/en-US/xml/guest-network.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Guest Network
+
+ In a &PRODUCT; cloud, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN.
+
+
+ The &PRODUCT; virtual router is the main component providing networking features for guest traffic.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/guest-nw-usage-with-traffic-sentinel.xml b/docs/tmp/en-US/xml/guest-nw-usage-with-traffic-sentinel.xml
new file mode 100644
index 00000000000..5be46c0d509
--- /dev/null
+++ b/docs/tmp/en-US/xml/guest-nw-usage-with-traffic-sentinel.xml
@@ -0,0 +1,78 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Guest Network Usage Integration for Traffic Sentinel
+
+ To collect usage data for a guest network, &PRODUCT; needs to pull the data from an external network statistics collector installed on the network. Metering statistics for guest networks are available through &PRODUCT;’s integration with inMon Traffic Sentinel.
+
+
+ Traffic Sentinel is a network traffic usage data collection package. &PRODUCT; can feed statistics from Traffic Sentinel into its own usage records, providing a basis for billing users of cloud infrastructure. Traffic Sentinel uses the traffic monitoring protocol sFlow. Routers and switches generate sFlow records and provide them for collection by Traffic Sentinel, then &PRODUCT; queries the Traffic Sentinel database to obtain this information
+
+
+ To construct the query, &PRODUCT; determines what guest IPs were in use during the current query interval. This includes both newly assigned IPs and IPs that were assigned in a previous time period and continued to be in use. &PRODUCT; queries Traffic Sentinel for network statistics that apply to these IPs during the time period they remained allocated in &PRODUCT;. The returned data is correlated with the customer account that owned each IP and the timestamps when IPs were assigned and released in order to create billable metering records in &PRODUCT;. When the Usage Server runs, it collects this data.
+
+
+ To set up the integration between &PRODUCT; and Traffic Sentinel:
+
+
+
+
+ On your network infrastructure, install Traffic Sentinel and configure it to gather traffic data. For installation and configuration steps, see inMon documentation at Traffic Sentinel Documentation.
+
+
+
+
+
+ In the Traffic Sentinel UI, configure Traffic Sentinel to accept script querying from guest users. &PRODUCT; will be the guest user performing the remote queries to gather network usage for one or more IP addresses.
+
+
+ Click File > Users > Access Control > Reports Query, then select Guest from the drop-down list.
+
+
+
+
+
+ On &PRODUCT;, add the Traffic Sentinel host by calling the &PRODUCT; API command addTrafficMonitor. Pass in the URL of the Traffic Sentinel as protocol + host + port (optional); for example, http://10.147.28.100:8080. For the addTrafficMonitor command syntax, see the API Reference at API Documentation.
+
+
+ For information about how to call the &PRODUCT; API, see the Developer’s Guide at CloudStack API Developer's Guide.
+
+
+
+
+
+ Log in to the &PRODUCT; UI as administrator.
+
+
+
+
+
+ Select Configuration from the Global Settings page, and set the following:
+
+
+ direct.network.stats.interval: How often you want &PRODUCT; to query Traffic Sentinel.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/guest-traffic.xml b/docs/tmp/en-US/xml/guest-traffic.xml
new file mode 100644
index 00000000000..a7393dc87b4
--- /dev/null
+++ b/docs/tmp/en-US/xml/guest-traffic.xml
@@ -0,0 +1,50 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Guest Traffic
+
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+
+
+ Figure 1 illustrates a typical guest traffic setup:
+
+
+
+
+
+
+ guesttraffic.png: Depicts a guest traffic setup
+
+
+
+
+ The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+
+
+ The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
+
+
+ Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ha-enabled-vm.xml b/docs/tmp/en-US/xml/ha-enabled-vm.xml
new file mode 100644
index 00000000000..676394a309f
--- /dev/null
+++ b/docs/tmp/en-US/xml/ha-enabled-vm.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ HA-Enabled Virtual Machines
+
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, &PRODUCT; detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. &PRODUCT; has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ha-for-hosts.xml b/docs/tmp/en-US/xml/ha-for-hosts.xml
new file mode 100644
index 00000000000..6d91da8df2d
--- /dev/null
+++ b/docs/tmp/en-US/xml/ha-for-hosts.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ HA for Hosts
+
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, &PRODUCT; detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. &PRODUCT; has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+
+
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ha-management-server.xml b/docs/tmp/en-US/xml/ha-management-server.xml
new file mode 100644
index 00000000000..16902015916
--- /dev/null
+++ b/docs/tmp/en-US/xml/ha-management-server.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ HA for Management Server
+
+ The &PRODUCT; Management Server should be deployed in a multi-node configuration such that it is not susceptible to individual server failures. The Management Server itself (as distinct from the MySQL database) is stateless and may be placed behind a load balancer.
+
+
+ Normal operation of Hosts is not impacted by an outage of all Management Serves. All guest VMs will continue to work.
+
+
+ When the Management Server is down, no new VMs can be created, and the end user and admin UI, API, dynamic load distribution, and HA will cease to work.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hardware-config-eg.xml b/docs/tmp/en-US/xml/hardware-config-eg.xml
new file mode 100644
index 00000000000..875d2806a3c
--- /dev/null
+++ b/docs/tmp/en-US/xml/hardware-config-eg.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Example Hardware Configuration
+
+ This section contains an example configuration of specific switch models for zone-level layer-3 switching. It assumes VLAN management protocols, such as VTP or GVRP, have been disabled. The example scripts must be changed appropriately if you choose to use VTP or GVRP.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hardware-firewall.xml b/docs/tmp/en-US/xml/hardware-firewall.xml
new file mode 100644
index 00000000000..d3a78b6f3f4
--- /dev/null
+++ b/docs/tmp/en-US/xml/hardware-firewall.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Hardware Firewall
+
+ All deployments should have a firewall protecting the management server; see Generic Firewall Provisions. Optionally, some deployments may also have a Juniper SRX firewall that will be the default gateway for the guest networks; see .
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/host-add-vsphere.xml b/docs/tmp/en-US/xml/host-add-vsphere.xml
new file mode 100644
index 00000000000..c84d30e31c3
--- /dev/null
+++ b/docs/tmp/en-US/xml/host-add-vsphere.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Host (vSphere)
+
+ For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the entire cluster to &PRODUCT;. See Add Cluster: vSphere.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/host-add-xenserver-kvm-ovm.xml b/docs/tmp/en-US/xml/host-add-xenserver-kvm-ovm.xml
new file mode 100644
index 00000000000..0e40a3d9320
--- /dev/null
+++ b/docs/tmp/en-US/xml/host-add-xenserver-kvm-ovm.xml
@@ -0,0 +1,222 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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
+
+
+ Make sure the hypervisor host does not have any VMs already running before you add it to &PRODUCT;.
+
+
+
+
+ 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 &PRODUCT; 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.
+
+
+# xe pool-join master-address=[master IP] master-username=root master-password=[your password]
+
+
+ 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/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
+
+
+
+
+
+ Run the script:
+
+
+# ./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.
+
+
+
+
+
+
+
+
+
+
+
+
+ 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 &PRODUCT; and what additional configuration is required to ensure the host will work with &PRODUCT;. To find these installation details, see the appropriate section for your hypervisor in the &PRODUCT; Installation Guide.
+
+
+
+
+
+ Log in to the &PRODUCT; 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 delay while the host is provisioned. It should automatically display in the UI.
+
+
+
+
+
+ Repeat for additional hosts.
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/host-add.xml b/docs/tmp/en-US/xml/host-add.xml
new file mode 100644
index 00000000000..f850d514c78
--- /dev/null
+++ b/docs/tmp/en-US/xml/host-add.xml
@@ -0,0 +1,64 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Host
+
+
+
+ Before adding a host to the &PRODUCT; configuration, you must first install your chosen hypervisor on the host. &PRODUCT; can manage hosts running VMs under a variety of hypervisors.
+
+
+ The &PRODUCT; Installation Guide provides instructions on how to install each supported hypervisor and configure it for use with &PRODUCT;. 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 &PRODUCT;.
+
+
+
+ Be sure you have performed the additional &PRODUCT;-specific configuration steps described in the hypervisor installation section for your particular hypervisor.
+
+
+
+
+
+
+ Now add the hypervisor host to &PRODUCT;. The technique to use varies depending on the hypervisor.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/host-allocation.xml b/docs/tmp/en-US/xml/host-allocation.xml
new file mode 100644
index 00000000000..1e25e41b09b
--- /dev/null
+++ b/docs/tmp/en-US/xml/host-allocation.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Host Allocation
+
+ The system automatically picks the most appropriate host to run each virtual machine. End users may specify the zone in which the virtual machine will be created. End users do not have control over which host will run the virtual machine instance.
+
+
+ &PRODUCT; administrators can specify that certain hosts should have a preference for particular types of guest instances. For example, an administrator could state that a host should have a preference to run Windows guests. The default host allocator will attempt to place guests of that OS type on such hosts first. If no such host is available, the allocator will place the instance wherever there is sufficient physical capacity.
+
+
+ Both vertical and horizontal allocation is allowed. Vertical allocation consumes all the resources of a given host before allocating any guests on a second host. This reduces power consumption in the cloud. Horizontal allocation places a guest on each host in a round-robin fashion. This may yield better performance to the guests in some cases. &PRODUCT; also allows an element of CPU over-provisioning as configured by the administrator. Over-provisioning allows the administrator to commit more CPU cycles to the allocated guests than are actually available from the hardware.
+
+
+ &PRODUCT; also provides a pluggable interface for adding new allocators. These custom allocators can provide any policy the administrator desires.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-host-install-agent.xml b/docs/tmp/en-US/xml/hypervisor-host-install-agent.xml
new file mode 100644
index 00000000000..76f64b75d8f
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-host-install-agent.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install and configure the Agent
+
+ To manage KVM instances on the host &PRODUCT; uses a Agent. This Agent communicates with the Management server and controls all the instances on the host.
+
+
+ First we start by installing the agent:
+
+
+ In RHEL or CentOS:
+
+
+$ yum install cloud-agent
+
+ In Ubuntu:
+
+
+$ apt-get install cloud-agent
+
+ The host is now ready to be added to a cluster. This is covered in a later section, see . It is recommended that you continue to read the documentation before adding the host!
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-host-install-finish.xml b/docs/tmp/en-US/xml/hypervisor-host-install-finish.xml
new file mode 100644
index 00000000000..28cd48962eb
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-host-install-finish.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Add the host to CloudStack
+
+ The host is now ready to be added to a cluster. This is covered in a later section, see . It is recommended that you continue to read the documentation before adding the host!
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-host-install-firewall.xml b/docs/tmp/en-US/xml/hypervisor-host-install-firewall.xml
new file mode 100644
index 00000000000..5b45832cbfb
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-host-install-firewall.xml
@@ -0,0 +1,112 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configuring the firewall
+
+ The hypervisor needs to be able to communicate with other hypervisors and the management server needs to be able to reach the hypervisor.
+
+
+ In order to do so we have to open the following TCP ports (if you are using a firewall):
+
+
+
+
+ 22 (SSH)
+
+
+
+
+ 1798
+
+
+
+
+ 16509 (libvirt)
+
+
+
+
+ 5900 - 6100 (VNC consoles)
+
+
+
+
+ 49152 - 49216 (libvirt live migration)
+
+
+
+
+
+ It depends on the firewall you are using how to open these ports. Below you'll find examples how to open these ports in RHEL/CentOS and Ubuntu.
+
+
+ Open ports in RHEL/CentOS
+
+ RHEL and CentOS use iptables for firewalling the system, you can open extra ports by executing the following iptable commands:
+
+
+$ iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT
+
+$ iptables -I INPUT -p tcp -m tcp --dport 1798 -j ACCEPT
+
+$ iptables -I INPUT -p tcp -m tcp --dport 16509 -j ACCEPT
+
+$ iptables -I INPUT -p tcp -m tcp --dport 5900:6100 -j ACCEPT
+
+$ iptables -I INPUT -p tcp -m tcp --dport 49152:49216 -j ACCEPT
+
+ These iptable settings are not persistent accross reboots, we have to save them first.
+
+
+$ iptables-save > /etc/sysconfig/iptables
+
+
+
+
+ Open ports in Ubuntu
+
+ The default firewall under Ubuntu is UFW (Uncomplicated FireWall), which is a Python wrapper around iptables.
+
+
+ To open the required ports, execute the following commands:
+
+
+$ ufw allow proto tcp from any to any port 22
+
+$ ufw allow proto tcp from any to any port 1798
+
+$ ufw allow proto tcp from any to any port 16509
+
+$ ufw allow proto tcp from any to any port 5900:6100
+
+$ ufw allow proto tcp from any to any port 49152:49216
+
+
+ By default UFW is not enabled on Ubuntu. Executing these commands with the firewall disabled does not enable the firewall.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-host-install-flow.xml b/docs/tmp/en-US/xml/hypervisor-host-install-flow.xml
new file mode 100644
index 00000000000..cb57499c2eb
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-host-install-flow.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Hypervisor Host installation
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-host-install-libvirt.xml b/docs/tmp/en-US/xml/hypervisor-host-install-libvirt.xml
new file mode 100644
index 00000000000..943a09728ab
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-host-install-libvirt.xml
@@ -0,0 +1,94 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install and Configure libvirt
+
+ &PRODUCT; uses libvirt for managing virtual machines. Therefore it is vital that libvirt is configured correctly. Libvirt is a dependency of cloud-agent and should already be installed.
+
+
+
+
+ In order to have live migration working libvirt has to listen for unsecured TCP connections. We also need to turn off libvirts attempt to use Multicast DNS advertising. Both of these settings are in /etc/libvirt/libvirtd.conf
+
+
+ Set the following paramaters:
+
+
+listen_tls = 0
+
+listen_tcp = 1
+
+tcp_port = 16059
+
+auth_tcp = "none"
+
+mdns_adv = 0
+
+
+
+
+ Turning on "listen_tcp" in libvirtd.conf is not enough, we have to change the parameters as well:
+
+
+ On RHEL or CentOS modify /etc/sysconfig/libvirtd:
+
+
+ Uncomment the following line:
+
+
+#LIBVIRTD_ARGS="--listen"
+
+ On Ubuntu: modify /etc/init/libvirt-bin.conf
+
+
+ Change the following line (at the end of the file):
+
+
+exec /usr/sbin/libvirtd -d
+
+ to (just add -l)
+
+
+exec /usr/sbin/libvirtd -d -l
+
+
+
+
+ Restart libvirt
+
+
+ In RHEL or CentOS:
+
+
+$ service libvirtd restart
+
+ In Ubuntu:
+
+
+$ service libvirt-bin restart
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-host-install-network.xml b/docs/tmp/en-US/xml/hypervisor-host-install-network.xml
new file mode 100644
index 00000000000..6e5af2c6cc7
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-host-install-network.xml
@@ -0,0 +1,239 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configure the network bridges
+
+
+ This is a very important section, please make sure you read this thoroughly.
+
+
+
+ In order to forward traffic to your instances you will need at least two bridges: public and private.
+
+
+ By default these bridges are called cloudbr0 and cloudbr1, but you do have to make sure they are available on each hypervisor.
+
+
+ The most important factor is that you keep the configuration consistent on all your hypervisors.
+
+
+ Network example
+
+ There are many ways to configure your network. In the Basic networking mode you should have two (V)LAN's, one for your private network and one for the public network.
+
+
+ We assume that the hypervisor has one NIC (eth0) with three tagged VLAN's:
+
+
+
+
+ VLAN 100 for management of the hypervisor
+
+
+
+
+ VLAN 200 for public network of the instances (cloudbr0)
+
+
+
+
+ VLAN 300 for private network of the instances (cloudbr1)
+
+
+
+
+
+ On VLAN 100 we give the Hypervisor the IP-Address 192.168.42.11/24 with the gateway 192.168.42.1
+
+
+
+ The Hypervisor and Management server don't have to be in the same subnet!
+
+
+
+
+
+
+ Configuring the network bridges
+
+ It depends on the distribution you are using how to configure these, below you'll find examples for RHEL/CentOS and Ubuntu.
+
+
+
+ The goal is to have two bridges called 'cloudbr0' and 'cloudbr1' after this section. This should be used as a guideline only. The exact configuration will depend on your network layout.
+
+
+
+ Configure in RHEL or CentOS
+
+ The required packages were installed when libvirt was installed, we can proceed to configuring the network.
+
+
+ First we configure eth0
+
+
+vi /etc/sysconfig/network-scripts/ifcfg-eth0
+
+ Make sure it looks similair to:
+
+
+DEVICE=eth0
+HWADDR=00:04:xx:xx:xx:xx
+ONBOOT=yes
+HOTPLUG=no
+BOOTPROTO=none
+TYPE=Ethernet
+
+ We now have to configure the three VLAN interfaces:
+
+
+vi /etc/sysconfig/network-scripts/ifcfg-eth0.100
+
+DEVICE=eth0.100
+HWADDR=00:04:xx:xx:xx:xx
+ONBOOT=yes
+HOTPLUG=no
+BOOTPROTO=none
+TYPE=Ethernet
+VLAN=yes
+IPADDR=192.168.42.11
+GATEWAY=192.168.42.1
+NETMASK=255.255.255.0
+
+vi /etc/sysconfig/network-scripts/ifcfg-eth0.200
+
+DEVICE=eth0.200
+HWADDR=00:04:xx:xx:xx:xx
+ONBOOT=yes
+HOTPLUG=no
+BOOTPROTO=none
+TYPE=Ethernet
+VLAN=yes
+BRIDGE=cloudbr0
+
+vi /etc/sysconfig/network-scripts/ifcfg-eth0.300
+
+DEVICE=eth0.300
+HWADDR=00:04:xx:xx:xx:xx
+ONBOOT=yes
+HOTPLUG=no
+BOOTPROTO=none
+TYPE=Ethernet
+VLAN=yes
+BRIDGE=cloudbr1
+
+ Now we have the VLAN interfaces configured we can add the bridges on top of them.
+
+
+vi /etc/sysconfig/network-scripts/ifcfg-cloudbr0
+
+ Now we just configure it is a plain bridge without an IP-Adress
+
+
+DEVICE=cloudbr0
+TYPE=Bridge
+ONBOOT=yes
+BOOTPROTO=none
+IPV6INIT=no
+IPV6_AUTOCONF=no
+DELAY=5
+STP=yes
+
+ We do the same for cloudbr1
+
+
+vi /etc/sysconfig/network-scripts/ifcfg-cloudbr1
+
+DEVICE=cloudbr1
+TYPE=Bridge
+ONBOOT=yes
+BOOTPROTO=none
+IPV6INIT=no
+IPV6_AUTOCONF=no
+DELAY=5
+STP=yes
+
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+
+
+
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+
+
+
+
+
+
+ Configure in Ubuntu
+
+ All the required packages were installed when you installed libvirt, so we only have to configure the network.
+
+
+vi /etc/network/interfaces
+
+ Modify the interfaces file to look like this:
+
+
+auto lo
+iface lo inet loopback
+
+# The primary network interface
+auto eth0.100
+iface eth0.100 inet static
+ address 192.168.42.11
+ netmask 255.255.255.240
+ gateway 192.168.42.1
+ dns-nameservers 8.8.8.8 8.8.4.4
+ dns-domain lab.example.org
+
+# Public network
+auto cloudbr0
+iface cloudbr0 inet manual
+ bridge_ports eth0.200
+ bridge_fd 5
+ bridge_stp off
+ bridge_maxwait 1
+
+# Private network
+auto cloudbr1
+iface cloudbr1 inet manual
+ bridge_ports eth0.300
+ bridge_fd 5
+ bridge_stp off
+ bridge_maxwait 1
+
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+
+
+
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-host-install-overview.xml b/docs/tmp/en-US/xml/hypervisor-host-install-overview.xml
new file mode 100644
index 00000000000..da890cf191d
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-host-install-overview.xml
@@ -0,0 +1,65 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ KVM Installation Overview
+
+ If you want to use the Linux Kernel Virtual Machine (KVM) hypervisor to run guest virtual machines, install KVM on the host(s) in your cloud. The material in this section doesn't duplicate KVM installation docs. It provides the &PRODUCT;-specific steps that are needed to prepare a KVM host to work with &PRODUCT;.
+
+
+
+ Before continuing, make sure that you have applied the latest updates to your host.
+
+
+
+
+ It is NOT recommended to run services on this host not controlled by &PRODUCT;.
+
+
+
+ The procedure for installing a KVM Hypervisor Host is:
+
+
+
+
+ Prepare the Operating System
+
+
+
+
+ Install and configure libvirt
+
+
+
+
+ Configure Security Policies (AppArmor and SELinux)
+
+
+
+
+ Install and configure the Agent
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-host-install-prepare-os.xml b/docs/tmp/en-US/xml/hypervisor-host-install-prepare-os.xml
new file mode 100644
index 00000000000..a81103cfdea
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-host-install-prepare-os.xml
@@ -0,0 +1,91 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare the Operating System
+
+ The OS of the Host must be prepared to host the &PRODUCT; Agent and run KVM instances.
+
+
+
+
+ Log in to your OS as root.
+
+
+
+
+ Check for a fully qualified hostname.
+
+
+$ hostname --fqdn
+
+ This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+
+
+
+
+ Make sure that the machine can reach the Internet.
+
+
+$ ping www.cloudstack.org
+
+
+
+
+ Turn on NTP for time synchronization.
+
+
+
+ NTP is required to synchronize the clocks of the servers in your cloud. Unsynchronized clocks can cause unexpected problems.
+
+
+
+
+
+ Install NTP
+
+
+ On RHEL or CentOS:
+
+
+$ yum install ntp
+
+ On Ubuntu:
+
+
+$ apt-get install openntpd
+
+
+
+
+
+
+
+
+ Repeat all of these steps on every hypervisor host.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-host-install-security-policies.xml b/docs/tmp/en-US/xml/hypervisor-host-install-security-policies.xml
new file mode 100644
index 00000000000..7c3bc2642b7
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-host-install-security-policies.xml
@@ -0,0 +1,115 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configure the Security Policies
+
+ &PRODUCT; does various things which can be blocked by security mechanisms like AppArmor and SELinux. These have to be disabled to ensure the Agent has all the required permissions.
+
+
+
+
+ Configure SELinux (RHEL and CentOS)
+
+
+
+
+ Check to see whether SELinux is installed on your machine. If not, you can skip this section.
+
+
+ In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
+
+
+$ rpm -qa | grep selinux
+
+
+
+
+ Set the SELINUX variable in /etc/selinux/config to "permissive". This ensures that the permissive setting will be maintained after a system reboot.
+
+
+ In RHEL or CentOS:
+
+
+vi /etc/selinux/config
+
+ Change the following line
+
+
+SELINUX=enforcing
+
+ to this
+
+
+SELINUX=permissive
+
+
+
+
+ Then set SELinux to permissive starting immediately, without requiring a system reboot.
+
+
+$ setenforce permissive
+
+
+
+
+
+
+
+
+ Configure Apparmor (Ubuntu)
+
+
+
+
+ Check to see whether AppArmor is installed on your machine. If not, you can skip this section.
+
+
+ In Ubuntu AppArmor is installed and enabled by default. You can verify this with:
+
+
+$ dpkg --list 'apparmor'
+
+
+
+
+ Disable the AppArmor profiles for libvirt
+
+
+$ ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
+
+$ ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
+
+$ apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
+
+$ apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-installation.xml b/docs/tmp/en-US/xml/hypervisor-installation.xml
new file mode 100644
index 00000000000..2aa661b2881
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-installation.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Hypervisor Installation
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-kvm-install-flow.xml b/docs/tmp/en-US/xml/hypervisor-kvm-install-flow.xml
new file mode 100644
index 00000000000..36cef1f42c7
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-kvm-install-flow.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ KVM Hypervisor Host Installation
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-kvm-requirements.xml b/docs/tmp/en-US/xml/hypervisor-kvm-requirements.xml
new file mode 100644
index 00000000000..bfe6f44733f
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-kvm-requirements.xml
@@ -0,0 +1,99 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ System Requirements for KVM Hypervisor Hosts
+
+ KVM is included with a variety of Linux-based operating systems. Although you are not required to run these distributions, the following are recommended:
+
+
+
+
+ CentOS / RHEL: 6.3
+
+
+
+
+ Ubuntu: 12.04(.1)
+
+
+
+
+
+ The main requirement for KVM hypervisors is the libvirt and Qemu version. No matter what Linux distribution you are using, make sure the following requirements are met:
+
+
+
+
+ libvirt: 0.9.4 or higher
+
+
+
+
+ Qemu/KVM: 1.0 or higher
+
+
+
+
+
+ In addition, the following hardware requirements apply:
+
+
+
+
+ Within a single cluster, the hosts must be of the same distribution version.
+
+
+
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+
+
+
+ Must support HVM (Intel-VT or AMD-V enabled)
+
+
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+
+
+
+ 4 GB of memory
+
+
+
+
+ At least 1 NIC
+
+
+
+
+ When you deploy &PRODUCT;, the hypervisor host must not have any VMs already running
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/hypervisor-support-for-primarystorage.xml b/docs/tmp/en-US/xml/hypervisor-support-for-primarystorage.xml
new file mode 100644
index 00000000000..ab28dd37c7f
--- /dev/null
+++ b/docs/tmp/en-US/xml/hypervisor-support-for-primarystorage.xml
@@ -0,0 +1,222 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Hypervisor Support for Primary Storage
+
+ The following table shows storage options and parameters for different hypervisors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ VMware vSphere
+
+
+
+
+ Citrix XenServer
+
+
+
+
+ KVM
+
+
+
+
+
+
+
+
+
+
+ Format for Disks, Templates, and Snapshots
+
+
+
+
+ VMDK
+
+
+
+
+ VHD
+
+
+
+
+ QCOW2
+
+
+
+
+
+
+
+ iSCSI support
+
+
+
+
+ VMFS
+
+
+
+
+ Clustered LVM
+
+
+
+
+ Yes, via Shared Mountpoint
+
+
+
+
+
+
+
+ Fiber Channel support
+
+
+
+
+ VMFS
+
+
+
+
+ Yes, via Existing SR
+
+
+
+
+ Yes, via Shared Mountpoint
+
+
+
+
+
+
+
+ NFS support
+
+
+
+
+ Y
+
+
+
+
+ Y
+
+
+
+
+ Y
+
+
+
+
+
+
+
+ Local storage support
+
+
+
+
+ Y
+
+
+
+
+ Y
+
+
+
+
+ Y
+
+
+
+
+
+
+
+ Storage over-provisioning
+
+
+
+
+ NFS and iSCSI
+
+
+
+
+ NFS
+
+
+
+
+ NFS
+
+
+
+
+
+
+
+
+
+
+
+ XenServer uses a clustered LVM system to store VM images on iSCSI and Fiber Channel volumes and does not support over-provisioning in the hypervisor. The storage server itself, however, can support thin-provisioning. As a result the &PRODUCT; can still support storage over-provisioning by running on thin-provisioned storage volumes.
+
+
+ KVM supports "Shared Mountpoint" storage. A shared mountpoint is a file system path local to each server in a given cluster. The path must be the same across all Hosts in the cluster, for example /mnt/primary1. This shared mountpoint is assumed to be a clustered filesystem such as OCFS2. In this case the &PRODUCT; does not attempt to mount or unmount the storage as is done with NFS. The &PRODUCT; requires that the administrator insure that the storage is available
+
+
+ With NFS storage, &PRODUCT; manages the overprovisioning. In this case the global configuration parameter storage.overprovisioning.factor controls the degree of overprovisioning. This is independent of hypervisor type.
+
+
+ Local storage is an option for primary storage for vSphere, XenServer, and KVM. When the local disk option is enabled, a local disk storage pool is automatically created on each host. To use local storage for the System Virtual Machines (such as the Virtual Router), set system.vm.use.local.storage to true in global configuration.
+
+
+ &PRODUCT; supports multiple primary storage pools in a Cluster. For example, you could provision 2 NFS servers in primary storage. Or you could provision 1 iSCSI LUN initially and then add a second iSCSI LUN when the first approaches capacity.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/images/1000-foot-view.png b/docs/tmp/en-US/xml/images/1000-foot-view.png
new file mode 100644
index 00000000000..2fe3c1658b3
Binary files /dev/null and b/docs/tmp/en-US/xml/images/1000-foot-view.png differ
diff --git a/docs/tmp/en-US/xml/images/add-cluster.png b/docs/tmp/en-US/xml/images/add-cluster.png
new file mode 100644
index 00000000000..383f375ebed
Binary files /dev/null and b/docs/tmp/en-US/xml/images/add-cluster.png differ
diff --git a/docs/tmp/en-US/xml/images/add-gateway.png b/docs/tmp/en-US/xml/images/add-gateway.png
new file mode 100644
index 00000000000..da8eed955f5
Binary files /dev/null and b/docs/tmp/en-US/xml/images/add-gateway.png differ
diff --git a/docs/tmp/en-US/xml/images/add-guest-network.png b/docs/tmp/en-US/xml/images/add-guest-network.png
new file mode 100644
index 00000000000..5740ab58d32
Binary files /dev/null and b/docs/tmp/en-US/xml/images/add-guest-network.png differ
diff --git a/docs/tmp/en-US/xml/images/add-new-gateway-vpc.png b/docs/tmp/en-US/xml/images/add-new-gateway-vpc.png
new file mode 100644
index 00000000000..f15b778e0f2
Binary files /dev/null and b/docs/tmp/en-US/xml/images/add-new-gateway-vpc.png differ
diff --git a/docs/tmp/en-US/xml/images/add-tier.png b/docs/tmp/en-US/xml/images/add-tier.png
new file mode 100644
index 00000000000..881671e2133
Binary files /dev/null and b/docs/tmp/en-US/xml/images/add-tier.png differ
diff --git a/docs/tmp/en-US/xml/images/add-vpc.png b/docs/tmp/en-US/xml/images/add-vpc.png
new file mode 100644
index 00000000000..6b9c6379d9f
Binary files /dev/null and b/docs/tmp/en-US/xml/images/add-vpc.png differ
diff --git a/docs/tmp/en-US/xml/images/add-vpn-customer-gateway.png b/docs/tmp/en-US/xml/images/add-vpn-customer-gateway.png
new file mode 100644
index 00000000000..fdc3177e9eb
Binary files /dev/null and b/docs/tmp/en-US/xml/images/add-vpn-customer-gateway.png differ
diff --git a/docs/tmp/en-US/xml/images/attach-disk-icon.png b/docs/tmp/en-US/xml/images/attach-disk-icon.png
new file mode 100644
index 00000000000..5e81d04fda2
Binary files /dev/null and b/docs/tmp/en-US/xml/images/attach-disk-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/autoscale-config.png b/docs/tmp/en-US/xml/images/autoscale-config.png
new file mode 100644
index 00000000000..735ae961f81
Binary files /dev/null and b/docs/tmp/en-US/xml/images/autoscale-config.png differ
diff --git a/docs/tmp/en-US/xml/images/basic-deployment.png b/docs/tmp/en-US/xml/images/basic-deployment.png
new file mode 100644
index 00000000000..894a05327bf
Binary files /dev/null and b/docs/tmp/en-US/xml/images/basic-deployment.png differ
diff --git a/docs/tmp/en-US/xml/images/change-admin-password.png b/docs/tmp/en-US/xml/images/change-admin-password.png
new file mode 100644
index 00000000000..938e8616a35
Binary files /dev/null and b/docs/tmp/en-US/xml/images/change-admin-password.png differ
diff --git a/docs/tmp/en-US/xml/images/change-password.png b/docs/tmp/en-US/xml/images/change-password.png
new file mode 100644
index 00000000000..fbb203a5e25
Binary files /dev/null and b/docs/tmp/en-US/xml/images/change-password.png differ
diff --git a/docs/tmp/en-US/xml/images/change-service-icon.png b/docs/tmp/en-US/xml/images/change-service-icon.png
new file mode 100644
index 00000000000..780e235f2f5
Binary files /dev/null and b/docs/tmp/en-US/xml/images/change-service-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/cluster-overview.png b/docs/tmp/en-US/xml/images/cluster-overview.png
new file mode 100644
index 00000000000..33f1a0477ef
Binary files /dev/null and b/docs/tmp/en-US/xml/images/cluster-overview.png differ
diff --git a/docs/tmp/en-US/xml/images/console-icon.png b/docs/tmp/en-US/xml/images/console-icon.png
new file mode 100644
index 00000000000..bf288869745
Binary files /dev/null and b/docs/tmp/en-US/xml/images/console-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/create-vpn-connection.png b/docs/tmp/en-US/xml/images/create-vpn-connection.png
new file mode 100644
index 00000000000..cd5515f53c7
Binary files /dev/null and b/docs/tmp/en-US/xml/images/create-vpn-connection.png differ
diff --git a/docs/tmp/en-US/xml/images/delete-button.png b/docs/tmp/en-US/xml/images/delete-button.png
new file mode 100644
index 00000000000..27145cebbc7
Binary files /dev/null and b/docs/tmp/en-US/xml/images/delete-button.png differ
diff --git a/docs/tmp/en-US/xml/images/destroy-instance.png b/docs/tmp/en-US/xml/images/destroy-instance.png
new file mode 100644
index 00000000000..aa9846cfd9b
Binary files /dev/null and b/docs/tmp/en-US/xml/images/destroy-instance.png differ
diff --git a/docs/tmp/en-US/xml/images/detach-disk-icon.png b/docs/tmp/en-US/xml/images/detach-disk-icon.png
new file mode 100644
index 00000000000..536a4f8d001
Binary files /dev/null and b/docs/tmp/en-US/xml/images/detach-disk-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/edit-icon.png b/docs/tmp/en-US/xml/images/edit-icon.png
new file mode 100644
index 00000000000..42417e278d3
Binary files /dev/null and b/docs/tmp/en-US/xml/images/edit-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/enable-disable-autoscale.png b/docs/tmp/en-US/xml/images/enable-disable-autoscale.png
new file mode 100644
index 00000000000..ee02ef21c69
Binary files /dev/null and b/docs/tmp/en-US/xml/images/enable-disable-autoscale.png differ
diff --git a/docs/tmp/en-US/xml/images/enable-disable.png b/docs/tmp/en-US/xml/images/enable-disable.png
new file mode 100644
index 00000000000..cab31ae3d59
Binary files /dev/null and b/docs/tmp/en-US/xml/images/enable-disable.png differ
diff --git a/docs/tmp/en-US/xml/images/guest-traffic-setup.png b/docs/tmp/en-US/xml/images/guest-traffic-setup.png
new file mode 100644
index 00000000000..52508194ac1
Binary files /dev/null and b/docs/tmp/en-US/xml/images/guest-traffic-setup.png differ
diff --git a/docs/tmp/en-US/xml/images/http-access.png b/docs/tmp/en-US/xml/images/http-access.png
new file mode 100644
index 00000000000..817f197985a
Binary files /dev/null and b/docs/tmp/en-US/xml/images/http-access.png differ
diff --git a/docs/tmp/en-US/xml/images/icon.svg b/docs/tmp/en-US/xml/images/icon.svg
new file mode 100644
index 00000000000..37f94c06c1b
--- /dev/null
+++ b/docs/tmp/en-US/xml/images/icon.svg
@@ -0,0 +1,37 @@
+
+
+
diff --git a/docs/tmp/en-US/xml/images/infrastructure-overview.png b/docs/tmp/en-US/xml/images/infrastructure-overview.png
new file mode 100644
index 00000000000..24aeecfcd1e
Binary files /dev/null and b/docs/tmp/en-US/xml/images/infrastructure-overview.png differ
diff --git a/docs/tmp/en-US/xml/images/installation-complete.png b/docs/tmp/en-US/xml/images/installation-complete.png
new file mode 100644
index 00000000000..4626f86d133
Binary files /dev/null and b/docs/tmp/en-US/xml/images/installation-complete.png differ
diff --git a/docs/tmp/en-US/xml/images/iso-icon.png b/docs/tmp/en-US/xml/images/iso-icon.png
new file mode 100644
index 00000000000..8d547fb397e
Binary files /dev/null and b/docs/tmp/en-US/xml/images/iso-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/large-scale-redundant-setup.png b/docs/tmp/en-US/xml/images/large-scale-redundant-setup.png
new file mode 100644
index 00000000000..5d2581afb43
Binary files /dev/null and b/docs/tmp/en-US/xml/images/large-scale-redundant-setup.png differ
diff --git a/docs/tmp/en-US/xml/images/migrate-instance.png b/docs/tmp/en-US/xml/images/migrate-instance.png
new file mode 100644
index 00000000000..25ff57245b3
Binary files /dev/null and b/docs/tmp/en-US/xml/images/migrate-instance.png differ
diff --git a/docs/tmp/en-US/xml/images/multi-node-management-server.png b/docs/tmp/en-US/xml/images/multi-node-management-server.png
new file mode 100644
index 00000000000..5cf5ed5456f
Binary files /dev/null and b/docs/tmp/en-US/xml/images/multi-node-management-server.png differ
diff --git a/docs/tmp/en-US/xml/images/multi-site-deployment.png b/docs/tmp/en-US/xml/images/multi-site-deployment.png
new file mode 100644
index 00000000000..f3ae5bb6b5c
Binary files /dev/null and b/docs/tmp/en-US/xml/images/multi-site-deployment.png differ
diff --git a/docs/tmp/en-US/xml/images/multi-tier-app.png b/docs/tmp/en-US/xml/images/multi-tier-app.png
new file mode 100644
index 00000000000..cec11228e26
Binary files /dev/null and b/docs/tmp/en-US/xml/images/multi-tier-app.png differ
diff --git a/docs/tmp/en-US/xml/images/network-acl.png b/docs/tmp/en-US/xml/images/network-acl.png
new file mode 100644
index 00000000000..5602827f415
Binary files /dev/null and b/docs/tmp/en-US/xml/images/network-acl.png differ
diff --git a/docs/tmp/en-US/xml/images/network-setup-zone.png b/docs/tmp/en-US/xml/images/network-setup-zone.png
new file mode 100644
index 00000000000..8324ff8beaa
Binary files /dev/null and b/docs/tmp/en-US/xml/images/network-setup-zone.png differ
diff --git a/docs/tmp/en-US/xml/images/network-singlepod.png b/docs/tmp/en-US/xml/images/network-singlepod.png
new file mode 100644
index 00000000000..e1214ea7f69
Binary files /dev/null and b/docs/tmp/en-US/xml/images/network-singlepod.png differ
diff --git a/docs/tmp/en-US/xml/images/networking-in-a-pod.png b/docs/tmp/en-US/xml/images/networking-in-a-pod.png
new file mode 100644
index 00000000000..bf731712042
Binary files /dev/null and b/docs/tmp/en-US/xml/images/networking-in-a-pod.png differ
diff --git a/docs/tmp/en-US/xml/images/networking-in-a-zone.png b/docs/tmp/en-US/xml/images/networking-in-a-zone.png
new file mode 100644
index 00000000000..fb740da448e
Binary files /dev/null and b/docs/tmp/en-US/xml/images/networking-in-a-zone.png differ
diff --git a/docs/tmp/en-US/xml/images/nic-bonding-and-multipath-io.png b/docs/tmp/en-US/xml/images/nic-bonding-and-multipath-io.png
new file mode 100644
index 00000000000..0fe60b66ed6
Binary files /dev/null and b/docs/tmp/en-US/xml/images/nic-bonding-and-multipath-io.png differ
diff --git a/docs/tmp/en-US/xml/images/parallel-mode.png b/docs/tmp/en-US/xml/images/parallel-mode.png
new file mode 100644
index 00000000000..3b67a17af9d
Binary files /dev/null and b/docs/tmp/en-US/xml/images/parallel-mode.png differ
diff --git a/docs/tmp/en-US/xml/images/pod-overview.png b/docs/tmp/en-US/xml/images/pod-overview.png
new file mode 100644
index 00000000000..c180060ba48
Binary files /dev/null and b/docs/tmp/en-US/xml/images/pod-overview.png differ
diff --git a/docs/tmp/en-US/xml/images/provisioning-overview.png b/docs/tmp/en-US/xml/images/provisioning-overview.png
new file mode 100644
index 00000000000..25cc97e3557
Binary files /dev/null and b/docs/tmp/en-US/xml/images/provisioning-overview.png differ
diff --git a/docs/tmp/en-US/xml/images/release-ip-icon.png b/docs/tmp/en-US/xml/images/release-ip-icon.png
new file mode 100644
index 00000000000..aa9846cfd9b
Binary files /dev/null and b/docs/tmp/en-US/xml/images/release-ip-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/remove-tier.png b/docs/tmp/en-US/xml/images/remove-tier.png
new file mode 100644
index 00000000000..e14d08f8052
Binary files /dev/null and b/docs/tmp/en-US/xml/images/remove-tier.png differ
diff --git a/docs/tmp/en-US/xml/images/remove-vpc.png b/docs/tmp/en-US/xml/images/remove-vpc.png
new file mode 100644
index 00000000000..aa9846cfd9b
Binary files /dev/null and b/docs/tmp/en-US/xml/images/remove-vpc.png differ
diff --git a/docs/tmp/en-US/xml/images/remove-vpn.png b/docs/tmp/en-US/xml/images/remove-vpn.png
new file mode 100644
index 00000000000..27145cebbc7
Binary files /dev/null and b/docs/tmp/en-US/xml/images/remove-vpn.png differ
diff --git a/docs/tmp/en-US/xml/images/reset-vpn.png b/docs/tmp/en-US/xml/images/reset-vpn.png
new file mode 100644
index 00000000000..04655dc37ad
Binary files /dev/null and b/docs/tmp/en-US/xml/images/reset-vpn.png differ
diff --git a/docs/tmp/en-US/xml/images/restart-vpc.png b/docs/tmp/en-US/xml/images/restart-vpc.png
new file mode 100644
index 00000000000..04655dc37ad
Binary files /dev/null and b/docs/tmp/en-US/xml/images/restart-vpc.png differ
diff --git a/docs/tmp/en-US/xml/images/search-button.png b/docs/tmp/en-US/xml/images/search-button.png
new file mode 100644
index 00000000000..f329aef4a25
Binary files /dev/null and b/docs/tmp/en-US/xml/images/search-button.png differ
diff --git a/docs/tmp/en-US/xml/images/select-vm-staticnat-vpc.png b/docs/tmp/en-US/xml/images/select-vm-staticnat-vpc.png
new file mode 100644
index 00000000000..12fde26d883
Binary files /dev/null and b/docs/tmp/en-US/xml/images/select-vm-staticnat-vpc.png differ
diff --git a/docs/tmp/en-US/xml/images/separate-storage-network.png b/docs/tmp/en-US/xml/images/separate-storage-network.png
new file mode 100644
index 00000000000..24dbbefc5b4
Binary files /dev/null and b/docs/tmp/en-US/xml/images/separate-storage-network.png differ
diff --git a/docs/tmp/en-US/xml/images/small-scale-deployment.png b/docs/tmp/en-US/xml/images/small-scale-deployment.png
new file mode 100644
index 00000000000..1c88520e7b4
Binary files /dev/null and b/docs/tmp/en-US/xml/images/small-scale-deployment.png differ
diff --git a/docs/tmp/en-US/xml/images/software-license.png b/docs/tmp/en-US/xml/images/software-license.png
new file mode 100644
index 00000000000..67aa2555341
Binary files /dev/null and b/docs/tmp/en-US/xml/images/software-license.png differ
diff --git a/docs/tmp/en-US/xml/images/stop-instance-icon.png b/docs/tmp/en-US/xml/images/stop-instance-icon.png
new file mode 100644
index 00000000000..209afce5086
Binary files /dev/null and b/docs/tmp/en-US/xml/images/stop-instance-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/suspend-icon.png b/docs/tmp/en-US/xml/images/suspend-icon.png
new file mode 100644
index 00000000000..cab31ae3d59
Binary files /dev/null and b/docs/tmp/en-US/xml/images/suspend-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/sysmanager.png b/docs/tmp/en-US/xml/images/sysmanager.png
new file mode 100644
index 00000000000..5b9df347a60
Binary files /dev/null and b/docs/tmp/en-US/xml/images/sysmanager.png differ
diff --git a/docs/tmp/en-US/xml/images/vm-lifecycle.png b/docs/tmp/en-US/xml/images/vm-lifecycle.png
new file mode 100644
index 00000000000..97823fc568a
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vm-lifecycle.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-increase-ports.png b/docs/tmp/en-US/xml/images/vmware-increase-ports.png
new file mode 100644
index 00000000000..fe968153262
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-increase-ports.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-iscsi-datastore.png b/docs/tmp/en-US/xml/images/vmware-iscsi-datastore.png
new file mode 100644
index 00000000000..9f6b33f01ed
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-iscsi-datastore.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-iscsi-general.png b/docs/tmp/en-US/xml/images/vmware-iscsi-general.png
new file mode 100644
index 00000000000..863602b9eb7
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-iscsi-general.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-iscsi-initiator-properties.png b/docs/tmp/en-US/xml/images/vmware-iscsi-initiator-properties.png
new file mode 100644
index 00000000000..1fab03143b1
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-iscsi-initiator-properties.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-iscsi-initiator.png b/docs/tmp/en-US/xml/images/vmware-iscsi-initiator.png
new file mode 100644
index 00000000000..a9a8301d74d
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-iscsi-initiator.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-iscsi-target-add.png b/docs/tmp/en-US/xml/images/vmware-iscsi-target-add.png
new file mode 100644
index 00000000000..f016da7956d
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-iscsi-target-add.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-mgt-network-properties.png b/docs/tmp/en-US/xml/images/vmware-mgt-network-properties.png
new file mode 100644
index 00000000000..9141af9c42f
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-mgt-network-properties.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-nexus-add-cluster.png b/docs/tmp/en-US/xml/images/vmware-nexus-add-cluster.png
new file mode 100644
index 00000000000..7c1dd73f775
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-nexus-add-cluster.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-nexus-port-profile.png b/docs/tmp/en-US/xml/images/vmware-nexus-port-profile.png
new file mode 100644
index 00000000000..19b264f7a0a
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-nexus-port-profile.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-physical-network.png b/docs/tmp/en-US/xml/images/vmware-physical-network.png
new file mode 100644
index 00000000000..a7495c77b14
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-physical-network.png differ
diff --git a/docs/tmp/en-US/xml/images/vmware-vswitch-properties.png b/docs/tmp/en-US/xml/images/vmware-vswitch-properties.png
new file mode 100644
index 00000000000..bc247d276d6
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vmware-vswitch-properties.png differ
diff --git a/docs/tmp/en-US/xml/images/vpc-setting.png b/docs/tmp/en-US/xml/images/vpc-setting.png
new file mode 100644
index 00000000000..782299e9f54
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vpc-setting.png differ
diff --git a/docs/tmp/en-US/xml/images/vpn-icon.png b/docs/tmp/en-US/xml/images/vpn-icon.png
new file mode 100644
index 00000000000..2ac12f77c40
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vpn-icon.png differ
diff --git a/docs/tmp/en-US/xml/images/vsphere-client.png b/docs/tmp/en-US/xml/images/vsphere-client.png
new file mode 100644
index 00000000000..2acc8b802ad
Binary files /dev/null and b/docs/tmp/en-US/xml/images/vsphere-client.png differ
diff --git a/docs/tmp/en-US/xml/images/zone-overview.png b/docs/tmp/en-US/xml/images/zone-overview.png
new file mode 100644
index 00000000000..24aeecfcd1e
Binary files /dev/null and b/docs/tmp/en-US/xml/images/zone-overview.png differ
diff --git a/docs/tmp/en-US/xml/import-ami.xml b/docs/tmp/en-US/xml/import-ami.xml
new file mode 100644
index 00000000000..1f2531efafb
--- /dev/null
+++ b/docs/tmp/en-US/xml/import-ami.xml
@@ -0,0 +1,213 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Importing Amazon Machine Images
+
+ The following procedures describe how to import an Amazon Machine Image (AMI) into &PRODUCT; when using the XenServer hypervisor.
+
+
+ Assume you have an AMI file and this file is called CentOS_6.2_x64. Assume further that you are working on a CentOS host. If the AMI is a Fedora image, you need to be working on a Fedora host initially.
+
+
+ You need to have a XenServer host with a file-based storage repository (either a local ext3 SR or an NFS SR) to convert to a VHD once the image file has been customized on the Centos/Fedora host.
+
+
+
+ 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.
+
+
+
+
+
+ Set up loopback on image file:
+
+
+# mkdir -p /mnt/loop/centos62
+# mount -o loop CentOS_6.2_x64 /mnt/loop/centos54
+
+
+
+
+ Install the kernel-xen package into the image. This downloads the PV kernel and ramdisk to the image.
+
+
+# yum -c /mnt/loop/centos54/etc/yum.conf --installroot=/mnt/loop/centos62/ -y install kernel-xen
+
+
+
+ Create a grub entry in /boot/grub/grub.conf.
+
+
+# mkdir -p /mnt/loop/centos62/boot/grub
+# touch /mnt/loop/centos62/boot/grub/grub.conf
+# echo "" > /mnt/loop/centos62/boot/grub/grub.conf
+
+
+
+
+ Determine the name of the PV kernel that has been installed into the image.
+
+
+# cd /mnt/loop/centos62
+# ls lib/modules/
+2.6.16.33-xenU 2.6.16-xenU 2.6.18-164.15.1.el5xen 2.6.18-164.6.1.el5.centos.plus 2.6.18-xenU-ec2-v1.0 2.6.21.7-2.fc8xen 2.6.31-302-ec2
+# ls boot/initrd*
+boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
+# ls boot/vmlinuz*
+boot/vmlinuz-2.6.18-164.15.1.el5xen boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus boot/vmlinuz-2.6.18-xenU-ec2-v1.0 boot/vmlinuz-2.6.21-2952.fc8xen
+
+
+ Xen kernels/ramdisk always end with "xen". For the kernel version you choose, there has to be an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.
+
+
+
+
+ Based on your findings, create an entry in the grub.conf file. Below is an example entry.
+
+
+default=0
+timeout=5
+hiddenmenu
+title CentOS (2.6.18-164.15.1.el5xen)
+ root (hd0,0)
+ kernel /boot/vmlinuz-2.6.18-164.15.1.el5xen ro root=/dev/xvda
+ initrd /boot/initrd-2.6.18-164.15.1.el5xen.img
+
+
+
+
+ Edit etc/fstab, changing “sda1” to “xvda” and changing “sdb” to “xvdb”.
+
+
+# cat etc/fstab
+/dev/xvda / ext3 defaults 1 1
+/dev/xvdb /mnt ext3 defaults 0 0
+none /dev/pts devpts gid=5,mode=620 0 0
+none /proc proc defaults 0 0
+none /sys sysfs defaults 0 0
+
+
+
+
+ Enable login via the console. The default console device in a XenServer system is xvc0. Ensure that etc/inittab and etc/securetty have the following lines respectively:
+
+
+# grep xvc0 etc/inittab
+co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
+# grep xvc0 etc/securetty
+xvc0
+
+
+
+
+ Ensure the ramdisk supports PV disk and PV network. Customize this for the kernel version you have determined above.
+
+
+# chroot /mnt/loop/centos54
+# cd /boot/
+# mv initrd-2.6.18-164.15.1.el5xen.img initrd-2.6.18-164.15.1.el5xen.img.bak
+# mkinitrd -f /boot/initrd-2.6.18-164.15.1.el5xen.img --with=xennet --preload=xenblk --omit-scsi-modules 2.6.18-164.15.1.el5xen
+
+
+
+
+ Change the password.
+
+
+# passwd
+Changing password for user root.
+New UNIX password:
+Retype new UNIX password:
+passwd: all authentication tokens updated successfully.
+
+
+
+
+ Exit out of chroot.
+
+
+# exit
+
+
+
+ Check etc/ssh/sshd_config for lines allowing ssh login using a password.
+
+
+# egrep "PermitRootLogin|PasswordAuthentication" /mnt/loop/centos54/etc/ssh/sshd_config
+PermitRootLogin yes
+PasswordAuthentication yes
+
+
+
+
+ If you need the template to be enabled to reset passwords from the &PRODUCT; UI or API, install the password change script into the image at this point. See .
+
+
+
+
+ Unmount and delete loopback mount.
+
+
+# umount /mnt/loop/centos54
+# losetup -d /dev/loop0
+
+
+
+
+ Copy the image file to your XenServer host's file-based storage repository. In the example below, the Xenserver is "xenhost". This XenServer has an NFS repository whose uuid is a9c5b8c8-536b-a193-a6dc-51af3e5ff799.
+
+
+# scp CentOS_6.2_x64 xenhost:/var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799/
+
+
+
+ Log in to the Xenserver and create a VDI the same size as the image.
+
+
+[root@xenhost ~]# cd /var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# ls -lh CentOS_6.2_x64
+-rw-r--r-- 1 root root 10G Mar 16 16:49 CentOS_6.2_x64
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-create virtual-size=10GiB sr-uuid=a9c5b8c8-536b-a193-a6dc-51af3e5ff799 type=user name-label="Centos 6.2 x86_64"
+cad7317c-258b-4ef7-b207-cdf0283a7923
+
+
+
+
+ Import the image file into the VDI. This may take 10–20 minutes.
+
+
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-import filename=CentOS_6.2_x64 uuid=cad7317c-258b-4ef7-b207-cdf0283a7923
+
+
+
+ Locate a the VHD file. This is the file with the VDI’s UUID as its name. Compress it and upload it to your web server.
+
+
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# bzip2 -c cad7317c-258b-4ef7-b207-cdf0283a7923.vhd > CentOS_6.2_x64.vhd.bz2
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# scp CentOS_6.2_x64.vhd.bz2 webserver:/var/www/html/templates/
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/increase-management-server-max-memory.xml b/docs/tmp/en-US/xml/increase-management-server-max-memory.xml
new file mode 100644
index 00000000000..1e4f2b8e66f
--- /dev/null
+++ b/docs/tmp/en-US/xml/increase-management-server-max-memory.xml
@@ -0,0 +1,57 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Increase Management Server Maximum Memory
+
+ If the Management Server is subject to high demand, the default maximum JVM memory allocation can be insufficient. To increase the memory:
+
+
+
+
+ Edit the Tomcat configuration file:
+
+
+/etc/cloud/management/tomcat6.conf
+
+
+
+ Change the command-line parameter -XmxNNNm to a higher value of N.
+
+
+ For example, if the current value is -Xmx128m, change it to -Xmx1024m or higher.
+
+
+
+
+ To put the new setting into effect, restart the Management Server.
+
+
+# service cloud-management restart
+
+
+
+
+ For more information about memory issues, see "FAQ: Memory" at Tomcat Wiki.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/incremental-snapshots-backup.xml b/docs/tmp/en-US/xml/incremental-snapshots-backup.xml
new file mode 100644
index 00000000000..a08964ecc3e
--- /dev/null
+++ b/docs/tmp/en-US/xml/incremental-snapshots-backup.xml
@@ -0,0 +1,88 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Incremental Snapshots and Backup
+
+ Snapshots are created on primary storage where a disk resides. After a snapshot is created, it is immediately backed up to secondary storage and removed from primary storage for optimal utilization of space on primary storage.
+
+
+ &PRODUCT; does incremental backups for some hypervisors. When incremental backups are supported, every N backup is a full backup.
+
+
+
+
+
+
+
+
+
+ VMware vSphere
+
+
+
+
+ Citrix XenServer
+
+
+
+
+ KVM
+
+
+
+
+
+
+
+
+
+
+ Support incremental backup
+
+
+
+
+ N
+
+
+
+
+ Y
+
+
+
+
+ N
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/initial-setup-of-external-firewalls-loadbalancers.xml b/docs/tmp/en-US/xml/initial-setup-of-external-firewalls-loadbalancers.xml
new file mode 100644
index 00000000000..54e1f43fea1
--- /dev/null
+++ b/docs/tmp/en-US/xml/initial-setup-of-external-firewalls-loadbalancers.xml
@@ -0,0 +1,64 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Initial Setup of External Firewalls and Load Balancers
+
+ When the first VM is created for a new account, &PRODUCT; programs the external firewall and load balancer to work with the VM. The following objects are created on the firewall:
+
+
+
+
+ A new logical interface to connect to the account's private VLAN. The interface IP is always the first IP of the account's private subnet (e.g. 10.1.1.1).
+
+
+
+
+ A source NAT rule that forwards all outgoing traffic from the account's private VLAN to the public Internet, using the account's public IP address as the source address
+
+
+
+
+ A firewall filter counter that measures the number of bytes of outgoing traffic for the account
+
+
+
+
+
+ The following objects are created on the load balancer:
+
+
+
+
+ A new VLAN that matches the account's provisioned Zone VLAN
+
+
+
+
+ A self IP for the VLAN. This is always the second IP of the account's private subnet (e.g. 10.1.1.2).
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/initialize-and-test.xml b/docs/tmp/en-US/xml/initialize-and-test.xml
new file mode 100644
index 00000000000..d86d6670ae9
--- /dev/null
+++ b/docs/tmp/en-US/xml/initialize-and-test.xml
@@ -0,0 +1,108 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Initialize and Test
+
+ After everything is configured, &PRODUCT; will perform its initialization. This can take 30 minutes or more, depending on the speed of your network. When the initialization has completed successfully, the administrator's Dashboard should be displayed in the &PRODUCT; UI.
+
+
+
+
+ Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS 5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do not proceed to the next step until this status is displayed.
+
+
+
+
+ Go to the Instances tab, and filter by My Instances.
+
+
+
+
+ Click Add Instance and follow the steps in the wizard.
+
+
+
+
+ Choose the zone you just added.
+
+
+
+
+ In the template selection, choose the template to use in the VM. If this is a fresh installation, likely only the provided CentOS template is available.
+
+
+
+
+ Select a service offering. Be sure that the hardware you have allows starting the selected service offering.
+
+
+
+
+ In data disk offering, if desired, add another data disk. This is a second volume that will be available to but not mounted in the guest. For example, in Linux on XenServer you will see /dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PV-enabled OS kernel in use.
+
+
+
+
+ In default network, choose the primary network for the guest. In a trial installation, you would have only one option here.
+
+
+
+
+ Optionally give your VM a name and a group. Use any descriptive text you would like.
+
+
+
+
+ Click Launch VM. Your VM will be created and started. It might take some time to download the template and complete the VM startup. You can watch the VM’s progress in the Instances screen.
+
+
+
+
+
+
+
+
+ To use the VM, click the View Console button.
+
+
+
+
+
+ ConsoleButton.png: button to launch a console
+
+
+
+
+
+
+
+
+
+
+ Congratulations! You have successfully completed a &PRODUCT; Installation.
+
+
+ If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/install-database-on-management-server-node.xml b/docs/tmp/en-US/xml/install-database-on-management-server-node.xml
new file mode 100644
index 00000000000..20fe65941c4
--- /dev/null
+++ b/docs/tmp/en-US/xml/install-database-on-management-server-node.xml
@@ -0,0 +1,211 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install the Database on the Management Server Node
+
+ This section describes how to install MySQL on the same machine with the Management Server. This technique is intended for a simple deployment that has a single Management Server node. If you have a multi-node Management Server deployment, you will typically use a separate node for MySQL. See .
+
+
+
+
+ If you already have a version of MySQL installed on the Management Server node, make one of the following choices, depending on what version of MySQL it is. The most recent version tested is 5.1.58.
+
+
+
+
+ If you already have installed MySQL version 5.1.58 or later, skip to step 4.
+
+
+
+
+
+ If you have installed a version of MySQL earlier than 5.1.58, you can either skip to step 4 or uninstall MySQL and proceed to step 2 to install a more recent version.
+
+
+
+
+
+
+ It is important that you choose the right database version. Never downgrade a MySQL installation.
+
+
+
+
+
+
+ On the same computer where you installed the Management Server, re-run install.sh.
+
+
+# ./install.sh
+
+ You should see a few messages as the installer prepares, followed by a list of choices.
+
+
+
+
+
+ Choose D to install the MySQL server from the distribution’s repo.
+
+
+ > D
+
+ Troubleshooting: If you do not see the D option, you already have MySQL installed. Please go back to step 1.
+
+
+
+
+
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes one Management Server.
+
+
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=350
+log-bin=mysql-bin
+binlog-format = 'ROW'
+
+
+
+ The binlog-format variable is supported in MySQL versions 5.1 and greater. It is not supported in MySQL 5.0. In some versions of MySQL, an underscore character is used in place of the hyphen in the variable name. For the exact syntax and spelling of each variable, consult the documentation for your version of MySQL.
+
+
+
+
+
+
+ Restart the MySQL service, then invoke MySQL as the root user.
+
+
+
+# service mysqld restart
+# mysql -u root
+
+
+
+
+
+ Best Practice: On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password.
+
+
+mysql> SET PASSWORD = PASSWORD('password');
+
+ From now on, start MySQL with mysql -p so it will prompt you for the password.
+
+
+
+
+
+ To grant access privileges to remote users, perform the following steps.
+
+
+
+
+ Run the following commands from the mysql prompt:
+
+
+
+mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
+mysql> exit
+
+
+
+
+
+ Restart the MySQL service.
+
+
+# service mysqld restart
+
+
+
+ Open the MySQL server port (3306) in the firewall to allow remote clients to connect.
+
+
+# iptables -I INPUT -p tcp --dport 3306 -j ACCEPT
+
+
+
+ Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the INPUT chain.
+
+
+ -A INPUT -p tcp --dport 3306 -j ACCEPT
+
+
+
+
+
+
+
+ Set up the database. The following command creates the cloud user on the database.
+
+
+
+
+ In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password.
+
+
+
+
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
+
+
+
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+
+
+
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+
+
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+
+
+
+
+# cloud-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m <management_server_key> -k <database_key>
+
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
+
+
+
+
+ Now that the database is set up, you can finish configuring the OS for the Management Server. This command will set up iptables, sudoers, and start the Management Server.
+
+
+# cloud-setup-management
+
+ You should see the message “Management Server setup is done.”
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/install-database-on-separate-node.xml b/docs/tmp/en-US/xml/install-database-on-separate-node.xml
new file mode 100644
index 00000000000..d7014614f2d
--- /dev/null
+++ b/docs/tmp/en-US/xml/install-database-on-separate-node.xml
@@ -0,0 +1,203 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install the Database on a Separate Node
+
+ This section describes how to install MySQL on a standalone machine, separate from the Management Server. This technique is intended for a deployment that includes several Management Server nodes. If you have a single-node Management Server deployment, you will typically use the same node for MySQL. See .
+
+
+
+
+ If you already have a version of MySQL installed on the Management Server node, make one of the following choices, depending on what version of MySQL it is. The most recent version tested is 5.1.58.
+
+
+
+
+ If you already have installed MySQL version 5.1.58 or later, skip to step 3.
+
+
+
+
+
+ If you have installed a version of MySQL earlier than 5.1.58, you can either skip to step 3 or uninstall MySQL and proceed to step 2 to install a more recent version.
+
+
+
+
+
+
+ It is important that you choose the right database version. Never downgrade a MySQL installation.
+
+
+
+
+
+
+ Log in as root to your Database Node and run the following commands. If you are going to install a replica database, then log in to the master.
+
+
+
+# yum install mysql-server
+# chkconfig --level 35 mysqld on
+
+
+
+
+
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes two Management Servers.
+
+
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=700
+log-bin=mysql-bin
+binlog-format = 'ROW'
+
+
+
+ The binlog-format variable is supported in MySQL versions 5.1 and greater. It is not supported in MySQL 5.0. In some versions of MySQL, an underscore character is used in place of the hyphen in the variable name. For the exact syntax and spelling of each variable, consult the documentation for your version of MySQL.
+
+
+
+
+
+
+ Restart the MySQL service, then invoke MySQL as the root user.
+
+
+
+# service mysqld restart
+# mysql -u root
+
+
+
+
+
+ Best Practice: On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password.
+
+
+mysql> SET PASSWORD = PASSWORD('password');
+
+ From now on, start MySQL with mysql -p so it will prompt you for the password.
+
+
+
+
+
+ To grant access privileges to remote users, perform the following steps.
+
+
+
+
+ Run the following commands from the mysql prompt:
+
+
+
+mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
+mysql> exit
+
+
+
+
+
+ Restart the MySQL service.
+
+
+# service mysqld restart
+
+
+
+
+ Open the MySQL server port (3306) in the firewall to allow remote clients to connect.
+
+
+# iptables -I INPUT -p tcp --dport 3306 -j ACCEPT
+
+
+
+
+ Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the INPUT chain.
+
+
+ -A INPUT -p tcp --dport 3306 -j ACCEPT
+
+
+
+
+
+
+
+
+ Set up the database. The following command creates the cloud user on the database.
+
+
+
+
+ In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password.
+
+
+
+
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
+
+
+
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+
+
+
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+
+
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+
+
+
+
+# cloud-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m <management_server_key> -k <database_key>
+
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
+
+
+
+
+ Now that the database is set up, you can finish configuring the OS for the Management Server. This command will set up iptables, sudoers, and start the Management Server.
+
+
+# cloud-setup-management
+
+ You should see the message “Management Server setup is done.”
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/install-management-server-multi-nodes.xml b/docs/tmp/en-US/xml/install-management-server-multi-nodes.xml
new file mode 100644
index 00000000000..b6851315f8e
--- /dev/null
+++ b/docs/tmp/en-US/xml/install-management-server-multi-nodes.xml
@@ -0,0 +1,133 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare and Start Additional Management Servers
+
+ For your second and subsequent Management Servers, you will install the Management Server software, connect it to the database, and set up the OS for the Management Server.
+
+
+
+
+ Perform the steps in .
+
+
+
+
+
+ Download the Management Server onto the additional host where it will run. Get the software from the following link.
+
+
+ https://www.citrix.com/English/ss/downloads/
+
+
+ FIXME
+
+
+ You will need a MyCitrix account.
+
+
+
+
+
+ Install the packages. You should have a file in the form of “&PRODUCT;-VERSION-N-OSVERSION.tar.gz”. Untar the file and then run the install.sh script inside it. Replace the file and directory names below with those you are using:
+
+
+
+# tar xzf &PRODUCT;-VERSION-N-OSVERSION.tar.gz
+# cd &PRODUCT;-VERSION-N-OSVERSION
+# ./install.sh
+
+
+ You should see a few messages as the installer prepares, followed by a list of choices.
+
+
+
+
+
+ Choose M to install the Management Server software.
+
+
+ > M
+
+
+
+
+ Wait for a message like “Complete! Done,” which indicates that the software was installed successfully.
+
+
+
+
+
+ (RHEL or CentOS) When the installation is finished, run the following commands to start essential services (the commands might be different depending on your OS):
+
+
+
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+
+
+
+
+
+ Configure the database client. Note the absence of the --deploy-as argument in this case. (For more details about the arguments to this command, see .)
+
+
+# cloud-setup-databases cloud:<dbpassword>@<dbhost> -e <encryption_type> -m <management_server_key> -k <database_key>
+
+
+
+
+
+ (Trial installations only) If you are running the hypervisor on the same machine with the Management Server, edit /etc/sudoers and add the following line:
+
+
+Defaults:cloud !requiretty
+
+
+
+
+ Configure the OS and start the Management Server:
+
+
+# cloud-setup-management
+
+ The Management Server on this node should now be running.
+
+
+
+
+
+ Repeat these steps on each additional Management Server.
+
+
+
+
+ Be sure to configure a load balancer for the Management Servers. See Management Server Load Balancing.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/install-management-server.xml b/docs/tmp/en-US/xml/install-management-server.xml
new file mode 100644
index 00000000000..cf2ba8aa9d3
--- /dev/null
+++ b/docs/tmp/en-US/xml/install-management-server.xml
@@ -0,0 +1,94 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install the Management Server on the First Host
+
+ The first step in installation, whether you are installing the Management Server on one host or many, is to install the software on a single node.
+
+
+
+ If you are planning to install the Management Server on multiple nodes for high availability, do not proceed to the additional nodes yet. That step will come later.
+
+
+
+
+
+ Download the Management Server onto the host where it will run. Get the software from the following link.
+
+
+ https://www.citrix.com/English/ss/downloads/
+
+
+ FIXME
+
+
+ You will need a MyCitrix account.
+
+
+
+
+
+ Install the packages. You should have a file in the form of “&PRODUCT;-VERSION-N-OSVERSION.tar.gz”. Untar the file and then run the install.sh script inside it. Replace the file and directory names below with those you are using:
+
+
+
+# tar xzf &PRODUCT;-VERSION-N-OSVERSION.tar.gz
+# cd &PRODUCT;-VERSION-N-OSVERSION
+# ./install.sh
+
+
+ You should see a few messages as the installer prepares, followed by a list of choices.
+
+
+
+
+
+ Choose M to install the Management Server software.
+
+
+ > M
+
+
+
+
+ Wait for a message like “Complete! Done,” which indicates that the software was installed successfully.
+
+
+
+
+
+ (RHEL or CentOS) When the installation is finished, run the following commands to start essential services (the commands might be different depending on your OS):
+
+
+
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/installation-complete.xml b/docs/tmp/en-US/xml/installation-complete.xml
new file mode 100644
index 00000000000..f660e673007
--- /dev/null
+++ b/docs/tmp/en-US/xml/installation-complete.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Installation Complete! Next Steps
+
+ Congratulations! You have now installed &PRODUCT; Management Server and the database it uses to persist system data.
+
+
+
+
+
+
+ installation-complete.png: Finished installs with single Management Server and multiple Management Servers
+
+
+
+
+ What should you do next?
+
+
+
+
+ Even without adding any cloud infrastructure, you can run the UI to get a feel for what's offered and how you will interact with &PRODUCT; on an ongoing basis. See .
+
+
+
+
+ When you're ready, add the cloud infrastructure and try running some virtual machines on it, so you can watch how &PRODUCT; manages the infrastructure. See .
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/installation-steps-overview.xml b/docs/tmp/en-US/xml/installation-steps-overview.xml
new file mode 100644
index 00000000000..c7c16931a4a
--- /dev/null
+++ b/docs/tmp/en-US/xml/installation-steps-overview.xml
@@ -0,0 +1,120 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Overview of Installation Steps
+
+ For anything more than a simple trial installation, you will need guidance for a variety of configuration choices. It is strongly recommended that you read the following:
+
+
+
+
+ Choosing a Deployment Architecture
+
+
+
+
+ Choosing a Hypervisor: Supported Features
+
+
+
+
+ Network Setup
+
+
+
+
+ Storage Setup
+
+
+
+
+ Best Practices
+
+
+
+
+
+
+
+ Make sure you have the required hardware ready. See
+
+
+
+
+
+ Install the Management Server (choose single-node or multi-node). See
+
+
+
+
+
+ Log in to the UI. See
+
+
+
+
+
+ Add a zone. Includes the first pod, cluster, and host. See
+
+
+
+
+
+ Add more pods (optional). See
+
+
+
+
+
+ Add more clusters (optional). See
+
+
+
+
+
+ Add more hosts (optional). See
+
+
+
+
+
+ Add more primary storage (optional). See
+
+
+
+
+
+ Add more secondary storage (optional). See
+
+
+
+
+
+ Try using the cloud. See
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/installation.xml b/docs/tmp/en-US/xml/installation.xml
new file mode 100644
index 00000000000..0ad461c131f
--- /dev/null
+++ b/docs/tmp/en-US/xml/installation.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Installation
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/installation_overview.xml b/docs/tmp/en-US/xml/installation_overview.xml
new file mode 100644
index 00000000000..158aa9b3a09
--- /dev/null
+++ b/docs/tmp/en-US/xml/installation_overview.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Installation Overview
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/installation_steps_overview.xml b/docs/tmp/en-US/xml/installation_steps_overview.xml
new file mode 100644
index 00000000000..2e1db38f54a
--- /dev/null
+++ b/docs/tmp/en-US/xml/installation_steps_overview.xml
@@ -0,0 +1,147 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Overview of Installation Steps
+
+ For anything more than a simple trial installation, you will need guidance for a variety of configuration choices. It is strongly recommended that you read the following:
+
+
+
+
+ Choosing a Deployment Architecture
+
+
+
+
+ Choosing a Hypervisor: Supported Features
+
+
+
+
+ Network Setup
+
+
+
+
+ Storage Setup
+
+
+
+
+ Best Practices
+
+
+
+
+
+
+
+ Prepare
+
+
+ Make sure you have the required hardware ready
+
+
+
+
+
+ (Optional) Fill out the preparation checklists
+
+
+
+
+
+ Install the &PRODUCT; software
+
+
+
+
+
+ Install the Management Server (choose single-node or multi-node)
+
+
+
+
+
+ Log in to the UI
+
+
+
+
+
+ Provision your cloud infrastructure
+
+
+
+
+
+ Add a zone. Includes the first pod, cluster, and host
+
+
+
+
+
+ Add more pods
+
+
+
+
+
+ Add more clusters
+
+
+
+
+
+ Add more hosts
+
+
+
+
+
+ Add more primary storage
+
+
+
+
+
+ Add more secondary storage
+
+
+
+
+
+ Try using the cloud
+
+
+
+
+
+ Initialization and testing
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/inter-vlan-routing.xml b/docs/tmp/en-US/xml/inter-vlan-routing.xml
new file mode 100644
index 00000000000..6ba07c1e2db
--- /dev/null
+++ b/docs/tmp/en-US/xml/inter-vlan-routing.xml
@@ -0,0 +1,132 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Inter-VLAN Routing
+
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You provision VLANs to the tiers your create, and VMs can be deployed on different tiers. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications, such as Web, Application, or Database. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+
+ The major advantages are:
+
+
+
+
+ The administrator can deploy a set of VLANs and allow users to deploy VMs on these VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that account.
+
+
+
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+
+
+
+
+
+
+
+ The administrator can allow users create their own VPC and deploy the application. In this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that account.
+
+
+
+
+
+ Both administrators and users can create multiple VPCs. The guest network NIC is plugged to the VPC virtual router when the first VM is deployed in a tier.
+
+
+
+
+
+ The administrator can create the following gateways to send to or receive traffic from the VMs:
+
+
+
+
+ VPN Gateway: For more information, see .
+
+
+
+
+
+ Public Gateway: The public gateway for a VPC is added to the virtual router when the virtual router is created for VPC. The public gateway is not exposed to the end users. You are not allowed to list it, nor allowed to create any static routes.
+
+
+
+
+
+ Private Gateway: For more information, see .
+
+
+
+
+
+
+
+
+
+ Both administrators and users can create various possible destinations-gateway combinations. However, only one gateway of each type can be used in a deployment.
+
+
+ For example:
+
+
+
+
+ VLANs and Public Gateway: For example, an application is deployed in the cloud, and the Web application VMs communicate with the Internet.
+
+
+
+
+
+ VLANs, VPN Gateway, and Public Gateway: For example, an application is deployed in the cloud; the Web application VMs communicate with the Internet; and the database VMs communicate with the on-premise devices.
+
+
+
+
+
+
+
+
+
+ The administrator can define Access Control List (ACL) on the virtual router to filter the traffic among the VLANs or between the Internet and a VLAN. You can define ACL based on CIDR, port range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress type.
+
+
+
+
+
+
+ The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
+
+
+
+
+
+
+ mutltier.png: a multi-tier setup.
+
+
+
+
+ To set up a multi-tier Inter-VLAN deployment, see .
+
+
+
+
diff --git a/docs/tmp/en-US/xml/introduction.xml b/docs/tmp/en-US/xml/introduction.xml
new file mode 100644
index 00000000000..b9dde40905a
--- /dev/null
+++ b/docs/tmp/en-US/xml/introduction.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Introduction
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ip-forwarding-firewalling.xml b/docs/tmp/en-US/xml/ip-forwarding-firewalling.xml
new file mode 100644
index 00000000000..d9977a3e982
--- /dev/null
+++ b/docs/tmp/en-US/xml/ip-forwarding-firewalling.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ IP Forwarding and Firewalling
+
+ By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is translated via NAT to the public IP address and is allowed.
+
+
+ To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example, you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44. Then use port forwarding rules to direct traffic from individual ports within that range to specific ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public IP's port 33 to port 100 on one user VM's private IP.
+
+
+ For the steps to implement these rules, see Firewall Rules and Port Forwarding.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ip-load-balancing.xml b/docs/tmp/en-US/xml/ip-load-balancing.xml
new file mode 100644
index 00000000000..f914d055374
--- /dev/null
+++ b/docs/tmp/en-US/xml/ip-load-balancing.xml
@@ -0,0 +1,50 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ IP Load Balancing
+
+ The user may choose to associate the same public IP for multiple guests. &PRODUCT; implements a TCP-level load balancer with the following policies.
+
+
+
+
+ Round-robin
+
+
+
+
+ Least connection
+
+
+
+
+ Source IP
+
+
+
+
+
+ This is similar to port forwarding but the destination may be multiple IP addresses.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ipaddress-usage-record-format.xml b/docs/tmp/en-US/xml/ipaddress-usage-record-format.xml
new file mode 100644
index 00000000000..972d56327df
--- /dev/null
+++ b/docs/tmp/en-US/xml/ipaddress-usage-record-format.xml
@@ -0,0 +1,92 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ IP Address Usage Record Format
+
+ For IP address usage the following fields exist in a usage record.
+
+
+
+
+ account - name of the account
+
+
+
+
+ accountid - ID of the account
+
+
+
+
+ domainid - ID of the domain in which this account resides
+
+
+
+
+ zoneid - Zone where the usage occurred
+
+
+
+
+ description - A string describing what the usage record is tracking
+
+
+
+
+ usage - String representation of the usage, including the units of usage
+
+
+
+
+ usagetype - A number representing the usage type (see Usage Types)
+
+
+
+
+ rawusage - A number representing the actual usage in hours
+
+
+
+
+ usageid - IP address ID
+
+
+
+
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
+
+
+ issourcenat - Whether source NAT is enabled for the IP address
+
+
+
+
+ iselastic - True if the IP address is elastic.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/isolated-networks.xml b/docs/tmp/en-US/xml/isolated-networks.xml
new file mode 100644
index 00000000000..a242ae44dbc
--- /dev/null
+++ b/docs/tmp/en-US/xml/isolated-networks.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Isolated Networks
+
+ An isolated network can be accessed only by virtual machines of a single account. Isolated networks have the following properties.
+
+
+
+
+ Resources such as VLAN are allocated and garbage collected dynamically
+
+
+
+
+ There is one network offering for the entire network
+
+
+
+
+ The network offering can be upgraded or downgraded but it is for the entire network
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/job-status.xml b/docs/tmp/en-US/xml/job-status.xml
new file mode 100644
index 00000000000..0a4bb17041c
--- /dev/null
+++ b/docs/tmp/en-US/xml/job-status.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Job Status
+
+ The key to using an asynchronous command is the job ID that is returned immediately once the command has been executed. With the job ID, you can periodically check the job status by making calls to queryAsyncJobResult command. The command will return three possible job status integer values:
+
+
+
+
+ 0 - Job is still in progress. Continue to periodically poll for any status changes.
+
+
+
+
+ 1 - Job has successfully completed. The job will return any successful response values associated with command that was originally executed.
+
+
+
+
+ 2 - Job has failed to complete. Please check the "jobresultcode" tag for failure reason code and "jobresult" for the failure reason.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/kvm-topology-req.xml b/docs/tmp/en-US/xml/kvm-topology-req.xml
new file mode 100644
index 00000000000..93985a66603
--- /dev/null
+++ b/docs/tmp/en-US/xml/kvm-topology-req.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ KVM Topology Requirements
+
+ The Management Servers communicate with KVM hosts on port 22 (ssh).
+
+
+
+
diff --git a/docs/tmp/en-US/xml/large_scale_redundant_setup.xml b/docs/tmp/en-US/xml/large_scale_redundant_setup.xml
new file mode 100644
index 00000000000..25fdee72d67
--- /dev/null
+++ b/docs/tmp/en-US/xml/large_scale_redundant_setup.xml
@@ -0,0 +1,78 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Large-Scale Redundant Setup
+
+
+
+
+
+ Large-Scale Redundant Setup
+
+
+
+
+ This diagram illustrates the network architecture of a large-scale &PRODUCT; deployment.
+
+
+
+
+ A layer-3 switching layer is at the core of the data center. A router redundancy protocol like VRRP should be deployed. Typically high-end core switches also include firewall modules. Separate firewall appliances may also be used if the layer-3 switch does not have integrated firewall capabilities. The firewalls are configured in NAT mode. The firewalls provide the following functions:
+
+
+
+
+ Forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+
+
+
+
+ When the cloud spans multiple zones, the firewalls should enable site-to-site VPN such that servers in different zones can directly reach each other.
+
+
+
+
+
+
+
+
+ A layer-2 access switch layer is established for each pod. Multiple switches can be stacked to increase port count. In either case, redundant pairs of layer-2 switches should be deployed.
+
+
+
+
+ The Management Server cluster (including front-end load balancers, Management Server nodes, and the MySQL database) is connected to the management network through a pair of load balancers.
+
+
+
+
+ Secondary storage servers are connected to the management network.
+
+
+
+
+ Each pod contains storage and computing servers. Each storage and computing server should have redundant NICs connected to separate layer-2 access switches.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/layer2-switch.xml b/docs/tmp/en-US/xml/layer2-switch.xml
new file mode 100644
index 00000000000..32e54ff7c44
--- /dev/null
+++ b/docs/tmp/en-US/xml/layer2-switch.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Layer-2 Switch
+
+ The layer-2 switch is the access switching layer inside the pod.
+
+
+
+
+ It should trunk all VLANs into every computing host.
+
+
+
+
+
+ It should switch traffic for the management network containing computing and storage hosts. The layer-3 switch will serve as the gateway for the management network.
+
+
+
+
+
+
+ Example Configurations
+
+ This section contains example configurations for specific switch models for pod-level layer-2 switching. It assumes VLAN management protocols such as VTP or GVRP have been disabled. The scripts must be changed appropriately if you choose to use VTP or GVRP.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/linux-installation.xml b/docs/tmp/en-US/xml/linux-installation.xml
new file mode 100644
index 00000000000..e01eb11df3d
--- /dev/null
+++ b/docs/tmp/en-US/xml/linux-installation.xml
@@ -0,0 +1,89 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Linux OS Installation
+
+ Use the following steps to begin the Linux OS installation:
+
+
+
+
+ Download the script file cloud-set-guest-password:
+
+
+
+
+ Linux:
+
+
+
+
+ Windows:
+
+
+
+
+
+
+
+
+ Copy this file to /etc/init.d.
+
+
+ On some Linux distributions, copy the file to /etc/rc.d/init.d.
+
+
+
+
+
+ Run the following command to make the script executable:
+
+
+chmod +x /etc/init.d/cloud-set-guest-password
+
+
+
+
+ Depending on the Linux distribution, continue with the appropriate step.
+
+
+ On Fedora, CentOS/RHEL, and Debian, run:
+
+
+chkconfig --add cloud-set-guest-password
+
+ On Ubuntu with VMware tools, link the script file to the /etc/network/if-up and /etc/network/if-down folders, and run the script:
+
+
+#ln -s /etc/init.d/cloud-set-guest-password /etc/network/if-up/cloud-set-guest-password
+ #ln -s /etc/init.d/cloud-set-guest-password /etc/network/if-down/cloud-set-guest-password
+
+ If you are using Ubuntu 11.04, start by creating a directory called /var/lib/dhcp3 on your Ubuntu machine (works around a known issue with this version of Ubuntu). On all Ubuntu versions: Run “sudo update-rc.d cloud-set-guest-password defaults 98”. To test, run "mkpasswd" and check that it is generating a new password. If the “mkpasswd” command does not exist, run "sudo apt-get install whois" (or sudo apt-get install mkpasswd, depending on your Ubuntu version) and repeat.
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/load-balancer-rules.xml b/docs/tmp/en-US/xml/load-balancer-rules.xml
new file mode 100644
index 00000000000..c297fb4c6a7
--- /dev/null
+++ b/docs/tmp/en-US/xml/load-balancer-rules.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Load Balancer Rules
+
+ A &PRODUCT; user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.
+
+
+
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the &PRODUCT; virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/loadbalancer-policy-port-forwarding-rule-usage-record-format.xml b/docs/tmp/en-US/xml/loadbalancer-policy-port-forwarding-rule-usage-record-format.xml
new file mode 100644
index 00000000000..46fb3c3774c
--- /dev/null
+++ b/docs/tmp/en-US/xml/loadbalancer-policy-port-forwarding-rule-usage-record-format.xml
@@ -0,0 +1,84 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Load Balancer Policy or Port Forwarding Rule Usage Record Format
+
+
+
+ account - name of the account
+
+
+
+
+ accountid - ID of the account
+
+
+
+
+ domainid - ID of the domain in which this account resides
+
+
+
+
+ zoneid - Zone where the usage occurred
+
+
+
+
+ description - A string describing what the usage record is tracking
+
+
+
+
+ usage - String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+
+
+
+ usagetype - A number representing the usage type (see Usage Types)
+
+
+
+
+ rawusage - A number representing the actual usage in hours
+
+
+
+
+ usageid - ID of the load balancer policy or port forwarding rule
+
+
+
+
+ usagetype - A number representing the usage type (see Usage Types)
+
+
+
+
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/log-in-root-admin.xml b/docs/tmp/en-US/xml/log-in-root-admin.xml
new file mode 100644
index 00000000000..b2fd370b00c
--- /dev/null
+++ b/docs/tmp/en-US/xml/log-in-root-admin.xml
@@ -0,0 +1,80 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Logging In as the Root Administrator
+
+ After the Management Server software is installed and running, you can run the &PRODUCT; 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:
+
+
+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 &PRODUCT;, 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 &PRODUCT; 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 &PRODUCT; 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 CloudPlatform, 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 .
+
+
+
+
+
+
+ You are logging in as the root administrator. This account manages the &PRODUCT; 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.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/log-in.xml b/docs/tmp/en-US/xml/log-in.xml
new file mode 100644
index 00000000000..8331ff51aa8
--- /dev/null
+++ b/docs/tmp/en-US/xml/log-in.xml
@@ -0,0 +1,68 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Log In to the UI
+
+ &PRODUCT; 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)
+
+
+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.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/long-running-job-events.xml b/docs/tmp/en-US/xml/long-running-job-events.xml
new file mode 100644
index 00000000000..6b8b017c2f4
--- /dev/null
+++ b/docs/tmp/en-US/xml/long-running-job-events.xml
@@ -0,0 +1,67 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/maintain-hypervisors-on-hosts.xml b/docs/tmp/en-US/xml/maintain-hypervisors-on-hosts.xml
new file mode 100644
index 00000000000..4037b84c856
--- /dev/null
+++ b/docs/tmp/en-US/xml/maintain-hypervisors-on-hosts.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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. &PRODUCT; 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.
+
+
+
+ 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 &PRODUCT; Knowledge Base
+
+
+
+
diff --git a/docs/tmp/en-US/xml/maintenance-mode-for-primary-storage.xml b/docs/tmp/en-US/xml/maintenance-mode-for-primary-storage.xml
new file mode 100644
index 00000000000..90d09fa8126
--- /dev/null
+++ b/docs/tmp/en-US/xml/maintenance-mode-for-primary-storage.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Maintenance Mode for Primary Storage
+
+ Primary storage may be placed into maintenance mode. This is useful, for example, to replace faulty RAM in a storage device. Maintenance mode for a storage device will first stop any new guests from being provisioned on the storage device. Then it will stop all guests that have any volume on that storage device. When all such guests are stopped the storage device is in maintenance mode and may be shut down. When the storage device is online again you may cancel maintenance mode for the device. The &PRODUCT; will bring the device back online and attempt to start all guests that were running at the time of the entry into maintenance mode.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/making-api-request.xml b/docs/tmp/en-US/xml/making-api-request.xml
new file mode 100644
index 00000000000..677bede9d17
--- /dev/null
+++ b/docs/tmp/en-US/xml/making-api-request.xml
@@ -0,0 +1,83 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Making API Requests
+
+ All &PRODUCT; API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+
+
+
+
+ &PRODUCT; API URL: This is the web services API entry point(for example, http://www.cloud.com:8080/client/api)
+
+
+
+
+ Command: The web services command you wish to execute, such as start a virtual machine or create a disk volume
+
+
+
+
+ Parameters: Any additional required or optional parameters for the command
+
+
+
+
+
+ A sample API GET request looks like the following:
+
+
+http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+
+ Or in a more readable format:
+
+
+
+1. http://localhost:8080/client/api
+2. ?command=deployVirtualMachine
+3. &serviceOfferingId=1
+4. &diskOfferingId=1
+5. &templateId=2
+6. &zoneId=4
+7. &apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ
+8. &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+
+ The first line is the &PRODUCT; API URL. This is the Cloud instance you wish to interact with.
+
+
+ The second line refers to the command you wish to execute. In our example, we are attempting to deploy a fresh new virtual machine. It is preceded by a (?) to separate itself from the &PRODUCT; API URL.
+
+
+ Lines 3-6 are the parameters for this given command. To see the command and its request parameters, please refer to the appropriate section in the &PRODUCT; API documentation. Each parameter field-value pair (field=value) is preceded by an ampersand character (&).
+
+
+ Line 7 is the user API Key that uniquely identifies the account. See Signing API Requests on page 7.
+
+
+ Line 8 is the signature hash created to authenticate the user account executing the API command. See Signing API Requests on page 7.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/manage-cloud.xml b/docs/tmp/en-US/xml/manage-cloud.xml
new file mode 100644
index 00000000000..51dc8b4329e
--- /dev/null
+++ b/docs/tmp/en-US/xml/manage-cloud.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Managing the Cloud
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-client.xml b/docs/tmp/en-US/xml/management-server-install-client.xml
new file mode 100644
index 00000000000..66cf2ca092a
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-client.xml
@@ -0,0 +1,72 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install the Management Server on the First Host
+
+ The first step in installation, whether you are installing the Management Server on one host or many, is to install the software on a single node.
+
+
+
+ If you are planning to install the Management Server on multiple nodes for high availability, do not proceed to the additional nodes yet. That step will come later.
+
+
+
+
+ The &PRODUCT; Management server can be installed using either RPM or DEB packages. These packages will depend on everything you need to run the Management server.
+
+
+ Downloading vhd-util
+
+ This procedure is required only for installations where XenServer is installed on the hypervisor hosts.
+
+
+ Before setting up the Management Server, download vhd-util from vhd-util.
+
+
+ If the Management Server is RHEL or CentOS, copy vhd-util to /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver.
+
+
+ If the Management Server is Ubuntu, copy vhd-util to /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util.
+
+
+
+
+
+ Install on CentOS/RHEL
+
+ We start by installing the required packages:
+
+
+yum install cloud-client
+
+
+
+
+ Install on Ubuntu
+
+apt-get install cloud-client
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-complete.xml b/docs/tmp/en-US/xml/management-server-install-complete.xml
new file mode 100644
index 00000000000..5b2e723316a
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-complete.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Installation Complete! Next Steps
+
+ Congratulations! You have now installed &PRODUCT; Management Server and the database it uses to persist system data.
+
+
+
+
+
+
+ installation-complete.png: Finished installs with single Management Server and multiple Management Servers
+
+
+
+
+ What should you do next?
+
+
+
+
+ Even without adding any cloud infrastructure, you can run the UI to get a feel for what's offered and how you will interact with &PRODUCT; on an ongoing basis. See Log In to the UI.
+
+
+
+
+ When you're ready, add the cloud infrastructure and try running some virtual machines on it, so you can watch how &PRODUCT; manages the infrastructure. See Provision Your Cloud Infrastructure.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-db-external.xml b/docs/tmp/en-US/xml/management-server-install-db-external.xml
new file mode 100644
index 00000000000..31b8debea55
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-db-external.xml
@@ -0,0 +1,187 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install the Database on a Separate Node
+
+ This section describes how to install MySQL on a standalone machine, separate from the Management Server. This technique is intended for a deployment that includes several Management Server nodes. If you have a single-node Management Server deployment, you will typically use the same node for MySQL. See .
+
+
+
+ The management server doesn't require a specific distribution for the MySQL node. You can use a distribution or Operating System of your choice. Using the same distribution as the management server is recommended, but not required. See .
+
+
+
+
+
+
+ Install MySQL from the package repository from your distribution:
+
+
+ On RHEL or CentOS:
+
+
+yum install mysql-server
+
+ On Ubuntu:
+
+
+apt-get install mysql-server
+
+
+
+
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes two Management Servers.
+
+
+
+ On Ubuntu, you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add these directives there. Don't forget to add [mysqld] on the first line of the file.
+
+
+
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=700
+log-bin=mysql-bin
+binlog-format = 'ROW'
+bind-address = 0.0.0.0
+
+
+
+
+ Start or restart MySQL to put the new configuration into effect.
+
+
+ On RHEL/CentOS, MySQL doesn't automatically start after installation. Start it manually.
+
+
+service mysqld start
+
+ On Ubuntu, restart MySQL.
+
+
+service mysqld restart
+
+
+
+
+ (CentOS and RHEL only; not required on Ubuntu)
+
+
+
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution.
+
+
+
+
+ Run the following command to secure your installation. You can answer "Y" to all questions except "Disallow root login remotely?". Remote root login is required to set up the databases.
+
+
+mysql_secure_installation
+
+
+
+
+ If a firewall is present on the system, open TCP port 3306 so external MySQL connections can be established.
+
+
+ On Ubuntu, UFW is the default firewall. Open the port with this command:
+
+
+ufw allow mysql
+
+ On RHEL/CentOS:
+
+
+
+
+ Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the INPUT chain.
+
+
+-A INPUT -p tcp --dport 3306 -j ACCEPT
+
+
+
+
+ Now reload the iptables rules.
+
+
+service iptables restart
+
+
+
+
+
+
+
+
+ Return to the root shell on your first Management Server.
+
+
+
+
+ Set up the database. The following command creates the cloud user on the database.
+
+
+
+
+ In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password.
+
+
+
+
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
+
+
+
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+
+
+
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+
+
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+
+
+
+
+cloud-setup-databases cloud:<dbpassword>@<ip address mysql server> \
+ --deploy-as=root:<password> \
+ -e <encryption_type> \
+ -m <management_server_key> \
+ -k <database_key>
+
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-db-local.xml b/docs/tmp/en-US/xml/management-server-install-db-local.xml
new file mode 100644
index 00000000000..4dae0690e7c
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-db-local.xml
@@ -0,0 +1,166 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install the Database on the Management Server Node
+
+ This section describes how to install MySQL on the same machine with the Management Server. This technique is intended for a simple deployment that has a single Management Server node. If you have a multi-node Management Server deployment, you will typically use a separate node for MySQL. See .
+
+
+
+
+ Install MySQL from the package repository from your distribution:
+
+
+ On RHEL or CentOS:
+
+
+yum install mysql-server
+
+ On Ubuntu:
+
+
+apt-get install mysql-server
+
+
+
+
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes one Management Server.
+
+
+
+ On Ubuntu, you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add these directives there. Don't forget to add [mysqld] on the first line of the file.
+
+
+
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=350
+log-bin=mysql-bin
+binlog-format = 'ROW'
+
+
+
+
+ Start or restart MySQL to put the new configuration into effect.
+
+
+ On RHEL/CentOS, MySQL doesn't automatically start after installation. Start it manually.
+
+
+service mysqld start
+
+ On Ubuntu, restart MySQL.
+
+
+service mysqld restart
+
+
+
+
+ (CentOS and RHEL only; not required on Ubuntu)
+
+
+
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution.
+
+
+
+
+ Run the following command to secure your installation. You can answer "Y" to all questions.
+
+
+mysql_secure_installation
+
+
+
+
+ Set up the database. The following command creates the "cloud" user on the database.
+
+
+
+
+ In dbpassword, specify the password to be assigned to the "cloud" user. You can choose to provide no password although that is not recommended.
+
+
+
+
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the "cloud" user.
+
+
+
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+
+
+
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+
+
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+
+
+
+
+cloud-setup-databases cloud:<dbpassword>@localhost \
+ --deploy-as=root:<password> \
+ -e <encryption_type> \
+ -m <management_server_key> \
+ -k <database_key>
+
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
+
+
+
+
+ If you are running the KVM hypervisor on the same machine with the Management Server, edit /etc/sudoers and add the following line:
+
+
+Defaults:cloud !requiretty
+
+
+ This type of single-machine setup is recommended only for a trial installation.
+
+
+
+
+
+
+ Now that the database is set up, you can finish configuring the OS for the Management Server. This command will set up iptables, sudoers, and start the Management Server.
+
+
+# cloud-setup-management
+
+ You should see the message “&PRODUCT; Management Server setup is done.”
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-db.xml b/docs/tmp/en-US/xml/management-server-install-db.xml
new file mode 100644
index 00000000000..160f329f674
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-db.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Install the database server
+
+ The &PRODUCT; management server uses a MySQL database server to store its data. When you are installing the management server on a single node, you can install the MySQL server locally. For an installation that has multiple management server nodes, we assume the MySQL database also runs on a separate node.
+
+
+ &PRODUCT; has been tested with MySQL 5.1 and 5.5. These versions are included in RHEL/CentOS and Ubuntu.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-flow.xml b/docs/tmp/en-US/xml/management-server-install-flow.xml
new file mode 100644
index 00000000000..dc46997e3cc
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-flow.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Management Server Installation
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-multi-node.xml b/docs/tmp/en-US/xml/management-server-install-multi-node.xml
new file mode 100644
index 00000000000..fa317f4c720
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-multi-node.xml
@@ -0,0 +1,97 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare and Start Additional Management Servers
+
+ For your second and subsequent Management Servers, you will install the Management Server software, connect it to the database, and set up the OS for the Management Server.
+
+
+
+
+ Perform the steps in and or as appropriate.
+
+
+
+
+
+ This step is required only for installations where XenServer is installed on the hypervisor hosts.
+
+
+ Download vhd-util from vhd-util
+
+
+ If the Management Server is RHEL or CentOS, copy vhd-util to /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver.
+
+
+ If the Management Server is Ubuntu, copy vhd-util to /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util.
+
+
+
+
+
+ Ensure that necessary services are started and set to start on boot.
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+
+
+
+
+
+
+
+ Configure the database client. Note the absence of the --deploy-as argument in this case. (For more details about the arguments to this command, see .)
+
+
+# cloud-setup-databases cloud:dbpassword@dbhost -e encryption_type -m management_server_key -k database_key
+
+
+
+
+
+ Configure the OS and start the Management Server:
+
+
+# cloud-setup-management
+
+ The Management Server on this node should now be running.
+
+
+
+
+
+ Repeat these steps on each additional Management Server.
+
+
+
+
+
+ Be sure to configure a load balancer for the Management Servers. See Management Server Load Balancing.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-nfs-shares.xml b/docs/tmp/en-US/xml/management-server-install-nfs-shares.xml
new file mode 100644
index 00000000000..85b122c6c5b
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-nfs-shares.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare NFS Shares
+
+ &PRODUCT; needs a place to keep primary and secondary storage (see Cloud Infrastructure Overview). Both of these can be NFS shares. This section tells how to set up the NFS shares before adding the storage to &PRODUCT;.
+
+
+ For primary storage, you can use iSCSI instead.
+
+
+ The requirements for primary and secondary storage are described in:
+
+
+
+
+ About Primary Storage
+
+
+
+
+ About Secondary Storage
+
+
+
+
+
+ A production installation typically uses a separate NFS server. See .
+
+
+ You can also use the Management Server node as the NFS server. This is more typical of a trial installation, but is technically possible in a larger deployment. See .
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-overview.xml b/docs/tmp/en-US/xml/management-server-install-overview.xml
new file mode 100644
index 00000000000..fc6588d5bcf
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-overview.xml
@@ -0,0 +1,94 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Management Server Installation Overview
+
+ This section describes installing the Management Server. There are two slightly different installation flows, depending on how many Management Server nodes will be in your cloud:
+
+
+
+
+ A single Management Server node, with MySQL on the same node.
+
+
+
+
+ Multiple Management Server nodes, with MySQL on a node separate from the Management Servers.
+
+
+
+
+
+ In either case, each machine must meet the system requirements described in System Requirements.
+
+
+
+ For the sake of security, be sure the public Internet can not access port 8096 or port 8250 on the Management Server.
+
+
+
+ The procedure for installing the Management Server is:
+
+
+
+
+ Prepare the Operating System
+
+
+
+
+
+ (XenServer only) Download and install vhd-util.
+
+
+
+
+
+ Install the First Management Server
+
+
+
+
+ Install and Configure the MySQL database
+
+
+
+
+ Prepare NFS Shares
+
+
+
+
+ Prepare and Start Additional Management Servers (optional)
+
+
+
+
+ Prepare the System VM Template
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-prepare-os.xml b/docs/tmp/en-US/xml/management-server-install-prepare-os.xml
new file mode 100644
index 00000000000..fd28eb57ed1
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-prepare-os.xml
@@ -0,0 +1,91 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare the Operating System
+
+ The OS must be prepared to host the Management Server using the following steps. These steps must be performed on each Management Server node.
+
+
+
+
+ Log in to your OS as root.
+
+
+
+
+ Check for a fully qualified hostname.
+
+
+hostname --fqdn
+
+ This should return a fully qualified hostname such as "managament1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+
+
+
+
+ Make sure that the machine can reach the Internet.
+
+
+ping www.cloudstack.org
+
+
+
+
+ Turn on NTP for time synchronization.
+
+
+
+ NTP is required to synchronize the clocks of the servers in your cloud.
+
+
+
+
+
+ Install NTP.
+
+
+ On RHEL or CentOS:
+
+
+yum install ntp
+
+ On Ubuntu:
+
+
+apt-get install openntpd
+
+
+
+
+
+
+
+
+ Repeat all of these steps on every host where the Management Server will be installed.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-install-systemvm.xml b/docs/tmp/en-US/xml/management-server-install-systemvm.xml
new file mode 100644
index 00000000000..2f3161cf984
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-install-systemvm.xml
@@ -0,0 +1,98 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare the System VM Template
+
+ Secondary storage must be seeded with a template that is used for &PRODUCT; system VMs.
+
+
+
+ When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text.
+
+
+
+
+
+
+ On the Management Server, run one or more of the following cloud-install-sys-tmplt commands to retrieve and decompress the system VM template. Run the command for each hypervisor type that you expect end users to run in this Zone.
+
+
+ If your secondary storage mount point is not named /mnt/secondary, substitute your own mount point name.
+
+
+ If you set the &PRODUCT; database encryption type to "web" when you set up the database, you must now add the parameter -s <management-server-secret-key>. See About Password and Key Encryption.
+
+
+ This process will require approximately 5 GB of free space on the local file system and up to 30 minutes each time it runs.
+
+
+
+
+ For XenServer:
+
+
+# /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 -h xenserver -s <optional-management-server-secret-key> -F
+
+
+
+
+ For vSphere:
+
+
+# /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova -h vmware -s <optional-management-server-secret-key> -F
+
+
+
+
+ For KVM:
+
+
+# /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -s <optional-management-server-secret-key> -F
+
+
+
+
+
+
+
+
+ If you are using a separate NFS server, perform this step. If you are using the Management Server as the NFS server, you MUST NOT perform this step.
+
+
+ When the script has finished, unmount secondary storage and remove the created directory.
+
+
+# umount /mnt/secondary
+# rmdir /mnt/secondary
+
+
+
+
+ Repeat these steps for each secondary storage server.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-installation-overview.xml b/docs/tmp/en-US/xml/management-server-installation-overview.xml
new file mode 100644
index 00000000000..67160bda5e0
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-installation-overview.xml
@@ -0,0 +1,87 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Management Server Installation Overview
+
+ This section describes installing the Management Server. There are two slightly different installation flows, depending on how many Management Server nodes will be in your cloud:
+
+
+
+
+ A single Management Server node, with MySQL on the same node.
+
+
+
+
+ Multiple Management Server nodes, with MySQL on a node separate from the Management Servers.
+
+
+
+
+
+ In either case, each machine must meet the system requirements described in System Requirements.
+
+
+
+ For the sake of security, be sure the public Internet can not access port 8096 or port 8250 on the Management Server.
+
+
+
+ The procedure for installing the Management Server is:
+
+
+
+
+ Prepare the Operating System
+
+
+
+
+ Install the First Management Server
+
+
+
+
+ Install and Configure the Database
+
+
+
+
+ Prepare NFS Shares
+
+
+
+
+ Prepare and Start Additional Management Servers (optional)
+
+
+
+
+ Prepare the System VM Template
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-lb.xml b/docs/tmp/en-US/xml/management-server-lb.xml
new file mode 100644
index 00000000000..505ea005da3
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-lb.xml
@@ -0,0 +1,134 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Zone VLAN and Running VM Maximums
+
+ CloudPlatform can use a load balancer to provide a virtual IP for multiple Management Servers. The administrator is responsible for creating the load balancer rules for the Management Servers. The application requires persistence or stickiness across multiple sessions. The following chart lists the ports that should be load balanced and whether or not persistence is required.
+
+
+ Even if persistence is not required, enabling it is permitted.
+
+
+
+
+
+
+
+ Source Port
+
+
+
+
+ Destination Port
+
+
+
+
+ Protocol
+
+
+
+
+ Persistence Required?
+
+
+
+
+
+
+
+
+
+
+ 80 or 443
+
+
+
+
+ 8080 (or 20400 with AJP)
+
+
+
+
+ HTTP (or AJP)
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+ 8250
+
+
+
+
+ 8250
+
+
+
+
+ TCP
+
+
+
+
+ Yes
+
+
+
+
+
+
+
+ 8096
+
+
+
+
+ 8096
+
+
+
+
+ HTTP
+
+
+
+
+ No
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management-server-overview.xml b/docs/tmp/en-US/xml/management-server-overview.xml
new file mode 100644
index 00000000000..dde8d3fc20a
--- /dev/null
+++ b/docs/tmp/en-US/xml/management-server-overview.xml
@@ -0,0 +1,84 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Management Server Overview
+
+ The Management Server is the &PRODUCT; software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+
+ The machine must meet the system requirements described in System Requirements.
+
+
+ The Management Server:
+
+
+
+
+ Provides the web user interface for the administrator and a reference user interface for end users.
+
+
+
+
+
+ Provides the APIs for &PRODUCT;.
+
+
+
+
+
+ Manages the assignment of guest VMs to particular hosts.
+
+
+
+
+
+ Manages the assignment of public and private IP addresses to particular accounts.
+
+
+
+
+
+ Manages the allocation of storage to guests as virtual disks.
+
+
+
+
+
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+
+
+
+
+
+ Provides a single point of configuration for the cloud.
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management_server_multi_node_install.xml b/docs/tmp/en-US/xml/management_server_multi_node_install.xml
new file mode 100644
index 00000000000..4882a5fd9c9
--- /dev/null
+++ b/docs/tmp/en-US/xml/management_server_multi_node_install.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Management Server Multi-Node Installation
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/management_server_overview.xml b/docs/tmp/en-US/xml/management_server_overview.xml
new file mode 100644
index 00000000000..8661e6f1c42
--- /dev/null
+++ b/docs/tmp/en-US/xml/management_server_overview.xml
@@ -0,0 +1,84 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Management Server Overview
+
+ The Management Server is the &PRODUCT; software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+
+
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The &PRODUCT; Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+
+
+ The machine must meet the system requirements described in System Requirements.
+
+
+ The Management Server:
+
+
+
+
+ Provides the web user interface for the administrator and a reference user interface for end users.
+
+
+
+
+
+ Provides the APIs for the &PRODUCT; platform.
+
+
+
+
+
+ Manages the assignment of guest VMs to particular hosts.
+
+
+
+
+
+ Manages the assignment of public and private IP addresses to particular accounts.
+
+
+
+
+
+ Manages the allocation of storage to guests as virtual disks.
+
+
+
+
+
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+
+
+
+
+
+ Provides a single point of configuration for the cloud.
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/manual-live-migration.xml b/docs/tmp/en-US/xml/manual-live-migration.xml
new file mode 100644
index 00000000000..75a8e468005
--- /dev/null
+++ b/docs/tmp/en-US/xml/manual-live-migration.xml
@@ -0,0 +1,104 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Moving VMs Between Hosts (Manual Live Migration)
+
+ The CloudPlatform administrator can move a running VM from one host to another without interrupting service to users or going into maintenance mode. This is called manual live migration, and can be done under the following conditions:
+
+
+
+
+ The root administrator is logged in. Domain admins and users can not perform manual live migration of VMs.
+
+
+
+
+ The VM is running. Stopped VMs can not be live migrated.
+
+
+
+
+ The destination host must be in the same cluster as the original host.
+
+
+
+
+ The VM must not be using local disk storage.
+
+
+
+
+ The destination host must have enough available capacity. If not, the VM will remain in the "migrating" state until memory becomes available.
+
+
+
+
+
+ To manually live migrate a virtual machine
+
+
+
+
+ Log in to the CloudPlatform UI as a user or admin.
+
+
+
+
+ In the left navigation, click Instances.
+
+
+
+
+ Choose the VM that you want to migrate.
+
+
+
+
+ Click the Migrate Instance button
+
+
+
+
+
+ Migrateinstance.png: button to migrate an instance
+
+
+
+
+
+
+
+
+ From the list of hosts, choose the one to which you want to move the VM.
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/max-result-page-returned.xml b/docs/tmp/en-US/xml/max-result-page-returned.xml
new file mode 100644
index 00000000000..0366b5291a0
--- /dev/null
+++ b/docs/tmp/en-US/xml/max-result-page-returned.xml
@@ -0,0 +1,52 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Maximum Result Pages Returned
+
+ For each cloud, there is a default upper limit on the number of results that any API command will return in a single page. This is to help prevent overloading the cloud servers and prevent DOS attacks. For example, if the page size limit is 500 and a command returns 10,000 results, the command will return 20 pages.
+
+
+ The default page size limit can be different for each cloud. It is set in the global configuration parameter default.page.size. If your cloud has many users with lots of VMs, you might need to increase the value of this parameter. At the same time, be careful not to set it so high that your site can be taken down by an enormous return from an API call. For more information about how to set global configuration parameters, see "Describe Your Deployment" in the Installation Guide.
+
+
+ To decrease the page size limit for an individual API command, override the global setting with the page and pagesize parameters, which are available in any list* command (listCapabilities, listDiskOfferings, etc.).
+
+
+
+
+ Both parameters must be specified together.
+
+
+
+
+ The value of the pagesize parameter must be smaller than the value of default.page.size. That is, you can not increase the number of possible items in a result page, only decrease it.
+
+
+
+
+
+ For syntax information on the list* commands, see the API Reference.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/migrate-datadisk-volume-new-storage-pool.xml b/docs/tmp/en-US/xml/migrate-datadisk-volume-new-storage-pool.xml
new file mode 100644
index 00000000000..f57811f9874
--- /dev/null
+++ b/docs/tmp/en-US/xml/migrate-datadisk-volume-new-storage-pool.xml
@@ -0,0 +1,55 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Migrating a Data Disk Volume to a New Storage Pool
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+ Detach the data disk from the VM. See Detaching and Moving Volumes (but skip the “reattach” step at the end. You will do that after migrating to new storage).
+
+
+
+
+ Call the &PRODUCT; API command migrateVolume and pass in the volume ID and the ID of any storage pool in the zone.
+
+
+
+
+ Watch for the volume status to change to Migrating, then back to Ready.
+
+
+
+
+ Attach the volume to any desired VM running in the same cluster as the new storage server. See Attaching a Volume
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/migrate-vm-rootvolume-volume-new-storage-pool.xml b/docs/tmp/en-US/xml/migrate-vm-rootvolume-volume-new-storage-pool.xml
new file mode 100644
index 00000000000..b891a223f90
--- /dev/null
+++ b/docs/tmp/en-US/xml/migrate-vm-rootvolume-volume-new-storage-pool.xml
@@ -0,0 +1,63 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Migrating a VM Root Volume to a New Storage Pool
+
+ When migrating the root disk volume, the VM must first be stopped, and users can not access the VM. After migration is complete, the VM can be restarted.
+
+
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+
+
+ Detach the data disk from the VM. See Detaching and Moving Volumes (but skip the “reattach” step at the end. You will do that after migrating to new storage).
+
+
+
+
+ Stop the VM.
+
+
+
+
+ Call the &PRODUCT; API command migrateVirtualMachine with the ID of the VM to migrate and the IDs of a destination host and destination storage pool in the same zone.
+
+
+
+
+ Watch for the VM status to change to Migrating, then back to Stopped.
+
+
+
+
+ Restart the VM.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/minimum-system-requirements.xml b/docs/tmp/en-US/xml/minimum-system-requirements.xml
new file mode 100644
index 00000000000..3726ee8e141
--- /dev/null
+++ b/docs/tmp/en-US/xml/minimum-system-requirements.xml
@@ -0,0 +1,171 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Minimum System Requirements
+
+ Management Server, Database, and Storage System Requirements
+
+ The machines that will run the Management Server and MySQL database must meet the following requirements. The same machines can also be used to provide primary and secondary storage, such as via localdisk or NFS. The Management Server may be placed on a virtual machine.
+
+
+
+
+ Operating system:
+
+
+
+
+ Preferred: CentOS/RHEL 6.3+ or Ubuntu 12.04(.1)
+
+
+
+
+
+
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+
+
+
+ 4 GB of memory
+
+
+
+
+ 50 GB of local disk (When running secondary storage on the management server 500GB is recommended)
+
+
+
+
+ At least 1 NIC
+
+
+
+
+ Statically allocated IP address
+
+
+
+
+ Fully qualified domain name as returned by the hostname command
+
+
+
+
+
+
+
+
+ Host/Hypervisor System Requirements
+
+ The host is where the cloud services run in the form of guest virtual machines. Each host is one machine that meets the following requirements:
+
+
+
+
+ Must support HVM (Intel-VT or AMD-V enabled).
+
+
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+
+
+
+ Hardware virtualization support required
+
+
+
+
+ 4 GB of memory
+
+
+
+
+ 36 GB of local disk
+
+
+
+
+ At least 1 NIC
+
+
+
+
+
+ If DHCP is used for hosts, ensure that no conflict occurs between DHCP server used for these hosts and the DHCP router created by &PRODUCT;.
+
+
+
+
+
+ Latest hotfixes applied to hypervisor software
+
+
+
+
+ When you deploy &PRODUCT;, the hypervisor host must not have any VMs already running
+
+
+
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+
+
+
+
+ Hosts have additional requirements depending on the hypervisor. See the requirements listed at the top of the Installation section for your chosen hypervisor:
+
+
+
+ Be sure you fulfill the additional hypervisor requirements and installation steps provided in this Guide. Hypervisor hosts must be properly prepared to work with CloudStack. For example, the requirements for XenServer are listed under Citrix XenServer Installation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/modify-delete-service-offerings.xml b/docs/tmp/en-US/xml/modify-delete-service-offerings.xml
new file mode 100644
index 00000000000..77e4f64715a
--- /dev/null
+++ b/docs/tmp/en-US/xml/modify-delete-service-offerings.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Modifying or Deleting a Service Offering
+
+ Service offerings cannot be changed once created. This applies to both compute offerings and disk offerings.
+
+
+ A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently. If the service offering is still in use, it will remain in the database until all the virtual machines referencing it have been deleted. After deletion by the administrator, a service offering will not be available to end users that are creating new instances.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/multi_node_management_server.xml b/docs/tmp/en-US/xml/multi_node_management_server.xml
new file mode 100644
index 00000000000..c92cea58801
--- /dev/null
+++ b/docs/tmp/en-US/xml/multi_node_management_server.xml
@@ -0,0 +1,57 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Multi-Node Management Server
+
+ The &PRODUCT; Management Server is deployed on one or more front-end servers connected to a single MySQL database. Optionally a pair of hardware load balancers distributes requests from the web. A backup management server set may be deployed using MySQL replication at a remote site to add DR capabilities.
+
+
+
+
+
+
+ Multi-Node Management Server
+
+
+
+
+ The administrator must decide the following.
+
+
+
+
+ Whether or not load balancers will be used.
+
+
+
+
+ How many Management Servers will be deployed.
+
+
+
+
+ Whether MySQL replication will be deployed to enable disaster recovery.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/multi_node_overview.xml b/docs/tmp/en-US/xml/multi_node_overview.xml
new file mode 100644
index 00000000000..f1e820f5e2a
--- /dev/null
+++ b/docs/tmp/en-US/xml/multi_node_overview.xml
@@ -0,0 +1,71 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Management Server Multi-Node Installation Overview
+
+ This section describes installing multiple Management Servers and installing MySQL on a node separate from the Management Servers. The machines must meet the system requirements described in System Requirements.
+
+
+
+ For the sake of security, be sure the public Internet can not access port 8096 or port 8250 on the Management Server.
+
+
+
+ The procedure for a multi-node installation is:
+
+
+
+
+ Prepare the Operating System
+
+
+
+
+ Install the First Management Server
+
+
+
+
+ Install and Configure the Database
+
+
+
+
+ Prepare NFS Shares
+
+
+
+
+ Prepare and Start Additional Management Servers
+
+
+
+
+ Prepare the System VM Template
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/multi_site_deployment.xml b/docs/tmp/en-US/xml/multi_site_deployment.xml
new file mode 100644
index 00000000000..6ad2c8afc91
--- /dev/null
+++ b/docs/tmp/en-US/xml/multi_site_deployment.xml
@@ -0,0 +1,79 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Multi-Site Deployment
+
+ The &PRODUCT; platform scales well into multiple sites through the use of zones. The following diagram shows an example of a multi-site deployment.
+
+
+
+
+
+
+ Example Of A Multi-Site Deployment
+
+
+
+
+ Data Center 1 houses the primary Management Server as well as zone 1. The MySQL database is replicated in real time to the secondary Management Server installation in Data Center 2.
+
+
+
+
+
+
+ Separate Storage Network
+
+
+
+
+ This diagram illustrates a setup with a separate storage network. Each server has four NICs, two connected to pod-level network switches and two connected to storage network switches.
+
+
+ There are two ways to configure the storage network:
+
+
+
+
+ Bonded NIC and redundant switches can be deployed for NFS. In NFS deployments, redundant switches and bonded NICs still result in one network (one CIDR block+ default gateway address).
+
+
+
+
+ iSCSI can take advantage of two separate storage networks (two CIDR blocks each with its own default gateway). Multipath iSCSI client can failover and load balance between separate storage networks.
+
+
+
+
+
+
+
+
+
+ NIC Bonding And Multipath I/O
+
+
+
+
+ This diagram illustrates the differences between NIC bonding and Multipath I/O (MPIO). NIC bonding configuration involves only one network. MPIO involves two separate networks.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/multiple-system-vm-vmware.xml b/docs/tmp/en-US/xml/multiple-system-vm-vmware.xml
new file mode 100644
index 00000000000..71afa9e1b10
--- /dev/null
+++ b/docs/tmp/en-US/xml/multiple-system-vm-vmware.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Multiple System VM Support for VMware
+
+ Every &PRODUCT; zone has single System VM for template processing tasks such as downloading templates, uploading templates, and uploading ISOs. In a zone where VMware is being used, additional System VMs can be launched to process VMware-specific tasks such as taking snapshots and creating private templates. The &PRODUCT; management server launches additional System VMs for VMware-specific tasks as the load increases. The management server monitors and weights all commands sent to these System VMs and performs dynamic load balancing and scaling-up of more System VMs.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/network-offering-usage-record-format.xml b/docs/tmp/en-US/xml/network-offering-usage-record-format.xml
new file mode 100644
index 00000000000..1c7df79941a
--- /dev/null
+++ b/docs/tmp/en-US/xml/network-offering-usage-record-format.xml
@@ -0,0 +1,99 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Network Offering Usage Record Format
+
+
+
+ account – name of the account
+
+
+
+
+ accountid – ID of the account
+
+
+
+
+ domainid – ID of the domain in which this account resides
+
+
+
+
+ zoneid – Zone where the usage occurred
+
+
+
+
+ description – A string describing what the usage record is tracking
+
+
+
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+
+
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+
+
+
+ rawusage – A number representing the actual usage in hours
+
+
+
+
+ usageid – ID of the network offering
+
+
+
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+
+
+
+ offeringid – Network offering ID
+
+
+
+
+ virtualMachineId – The ID of the virtual machine
+
+
+
+
+ virtualMachineId – The ID of the virtual machine
+
+
+
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/network-offerings.xml b/docs/tmp/en-US/xml/network-offerings.xml
new file mode 100644
index 00000000000..a042cf53c2a
--- /dev/null
+++ b/docs/tmp/en-US/xml/network-offerings.xml
@@ -0,0 +1,105 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Network Offerings
+
+
+ For the most up-to-date list of supported network services, see the CloudPlatform UI or call listNetworkServices.
+
+
+
+ A network offering is a named set of network services, such as:
+
+
+
+
+ DHCP
+
+
+
+
+ DNS
+
+
+
+
+ Source NAT
+
+
+
+
+ Static NAT
+
+
+
+
+ Port Forwarding
+
+
+
+
+ Load Balancing
+
+
+
+
+ Firewall
+
+
+
+
+ VPN
+
+
+
+
+ Optional) Name one of several available providers to use for a given service, such as Juniper for the firewall
+
+
+
+
+ (Optional) Network tag to specify which physical network to use
+
+
+
+
+
+ When creating a new VM, the user chooses one of the available network offerings, and that determines which network services the VM can use.
+
+
+ The CloudPlatform administrator can create any number of custom network offerings, in addition to the default network offerings provided by CloudPlatform. By creating multiple custom network offerings, you can set up your cloud to offer different classes of service on a single multi-tenant physical network. For example, while the underlying physical wiring may be the same for two tenants, tenant A may only need simple firewall protection for their website, while tenant B may be running a web server farm and require a scalable firewall solution, load balancing solution, and alternate networks for accessing the database backend.
+
+
+
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudPlatform virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
+
+
+ When creating a new virtual network, the CloudPlatform administrator chooses which network offering to enable for that network. Each virtual network is associated with one network offering. A virtual network can be upgraded or downgraded by changing its associated network offering. If you do this, be sure to reprogram the physical network to match.
+
+
+ CloudPlatform also has internal network offerings for use by CloudPlatform system VMs. These network offerings are not visible to users but can be modified by administrators.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/network-service-providers.xml b/docs/tmp/en-US/xml/network-service-providers.xml
new file mode 100644
index 00000000000..02c53f005de
--- /dev/null
+++ b/docs/tmp/en-US/xml/network-service-providers.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Network Service Providers
+
+
+ For the most up-to-date list of supported network service providers, see the CloudPlatform UI or call listNetworkServiceProviders.
+
+
+
+ A service provider (also called a network element) is hardware or virtual appliance that makes a network service possible; for example, a firewall appliance can be installed in the cloud to provide firewall service. On a single network, multiple providers can provide the same network service. For example, a firewall service may be provided by Cisco or Juniper devices in the same physical network.
+
+
+ You can have multiple instances of the same service provider in a network (say, more than one Juniper SRX device).
+
+
+ If different providers are set up to provide the same service on the network, the administrator can create network offerings so users can specify which network service provider they prefer (along with the other choices offered in network offerings). Otherwise, CloudPlatform will choose which provider to use whenever the service is called for.
+
+
+ Supported Network Service Providers
+
+ CloudPlatform ships with an internal list of the supported service providers, and you can choose from this list when creating a network offering.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/network-setup.xml b/docs/tmp/en-US/xml/network-setup.xml
new file mode 100644
index 00000000000..ceaec7d0958
--- /dev/null
+++ b/docs/tmp/en-US/xml/network-setup.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Network Setup
+
+ Achieving the correct networking setup is crucial to a successful &PRODUCT; installation. This section contains information to help you make decisions and follow the right procedures to get your network set up correctly.
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/network-usage-record-format.xml b/docs/tmp/en-US/xml/network-usage-record-format.xml
new file mode 100644
index 00000000000..f70c7197826
--- /dev/null
+++ b/docs/tmp/en-US/xml/network-usage-record-format.xml
@@ -0,0 +1,82 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Network Usage Record Format
+
+ For network usage (bytes sent/received), the following fields exist in a usage record.
+
+
+
+
+ account – name of the account
+
+
+
+
+ accountid – ID of the account
+
+
+
+
+ domainid – ID of the domain in which this account resides
+
+
+
+
+ zoneid – Zone where the usage occurred
+
+
+
+
+ description – A string describing what the usage record is tracking
+
+
+
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+
+
+
+ rawusage – A number representing the actual usage in hours
+
+
+
+
+ usageid – Device ID (virtual router ID or external device ID)
+
+
+
+
+ type – Device type (domain router, external load balancer, etc.)
+
+
+
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/networking-in-a-pod.xml b/docs/tmp/en-US/xml/networking-in-a-pod.xml
new file mode 100644
index 00000000000..b2ad5e3fd0b
--- /dev/null
+++ b/docs/tmp/en-US/xml/networking-in-a-pod.xml
@@ -0,0 +1,62 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Networking in a Pod
+
+ Figure 2 illustrates network setup within a single pod. The hosts are connected to a pod-level switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
+
+
+
+
+
+
+ networking-in-a-pod.png: Network setup in a pod
+
+
+
+
+ Servers are connected as follows:
+
+
+
+
+ Storage devices are connected to only the network that carries management traffic.
+
+
+
+
+ Hosts are connected to networks for both management traffic and public traffic.
+
+
+
+
+ Hosts are also connected to one or more networks carrying guest traffic.
+
+
+
+
+
+ We recommend the use of multiple physical Ethernet cards to implement each network interface as well as redundant switch fabric in order to maximize throughput and improve reliability.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/networking-in-a-zone.xml b/docs/tmp/en-US/xml/networking-in-a-zone.xml
new file mode 100644
index 00000000000..100557966c4
--- /dev/null
+++ b/docs/tmp/en-US/xml/networking-in-a-zone.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Networking in a Zone
+
+ Figure 3 illustrates the network setup within a single zone.
+
+
+
+
+
+
+ networking-in-a-zone.png: Network setup in a single zone
+
+
+
+
+ A firewall for management traffic operates in the NAT mode. The network typically is assigned IP addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses in the 192.168.*.0/24 Class C private address space.
+
+
+ Each zone has its own set of public IP addresses. Public IP addresses from different zones do not overlap.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/networking-overview.xml b/docs/tmp/en-US/xml/networking-overview.xml
new file mode 100644
index 00000000000..1ea09055d5f
--- /dev/null
+++ b/docs/tmp/en-US/xml/networking-overview.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Networking Overview
+
+ &PRODUCT; offers two types of networking scenario:
+
+
+
+
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+
+
+
+
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+
+
+
+
+ For more details, see Network Setup.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/networking_overview.xml b/docs/tmp/en-US/xml/networking_overview.xml
new file mode 100644
index 00000000000..3a33fbfdc03
--- /dev/null
+++ b/docs/tmp/en-US/xml/networking_overview.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Networking Overview
+
+ CloudStack offers two types of networking scenario:
+
+
+
+
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+
+
+
+
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+
+
+
+
+ For more details, see Network Setup.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/networks-for-users-overview.xml b/docs/tmp/en-US/xml/networks-for-users-overview.xml
new file mode 100644
index 00000000000..7fac46248c1
--- /dev/null
+++ b/docs/tmp/en-US/xml/networks-for-users-overview.xml
@@ -0,0 +1,57 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Overview of Setting Up Networking for Users
+
+ People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a &PRODUCT; administrator, you can do the following things to set up networking for your users:
+
+
+
+
+ Set up physical networks in zones
+
+
+
+
+ Set up several different providers for the same service on a single physical network (for example, both Cisco and Juniper firewalls)
+
+
+
+
+ Bundle different types of network services into network offerings, so users can choose the desired network services for any given virtual machine
+
+
+
+
+ Add new network offerings as time goes on so end users can upgrade to a better class of service on their network
+
+
+
+
+ Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/networks.xml b/docs/tmp/en-US/xml/networks.xml
new file mode 100644
index 00000000000..4e31d32b582
--- /dev/null
+++ b/docs/tmp/en-US/xml/networks.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Managing Networks and Traffic
+
+ In a &PRODUCT;, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN. The &PRODUCT; virtual router is the main component providing networking features for guest traffic.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/nfs-shares-on-management-server.xml b/docs/tmp/en-US/xml/nfs-shares-on-management-server.xml
new file mode 100644
index 00000000000..904835aa32a
--- /dev/null
+++ b/docs/tmp/en-US/xml/nfs-shares-on-management-server.xml
@@ -0,0 +1,188 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using the Management Server As the NFS Server
+
+ This section tells how to set up NFS shares for primary and secondary storage on the same node with the Management Server. This is more typical of a trial installation, but is technically possible in a larger deployment. It is assumed that you will have less than 16TB of storage on the host.
+
+
+ The exact commands for the following steps may vary depending on your operating system version.
+
+
+
+
+ On the Management Server host, create two directories that you will use for primary and secondary storage. For example:
+
+
+
+# mkdir -p /export/primary
+# mkdir -p /export/secondary
+
+
+
+
+
+ To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s) with rw,async,no_root_squash. For example:
+
+
+# vi /etc/exports
+
+ Insert the following line.
+
+
+/export *(rw,async,no_root_squash)
+
+
+
+
+ Export the /export directory.
+
+
+# exportfs -a
+
+
+
+
+ Edit the /etc/sysconfig/nfs file.
+
+
+# vi /etc/sysconfig/nfs
+
+ Uncomment the following lines:
+
+
+
+LOCKD_TCPPORT=32803
+LOCKD_UDPPORT=32769
+MOUNTD_PORT=892
+RQUOTAD_PORT=875
+STATD_PORT=662
+STATD_OUTGOING_PORT=2020
+
+
+
+
+
+ Edit the /etc/sysconfig/iptables file.
+
+
+# vi /etc/sysconfig/iptables
+
+ Add the following lines at the beginning of the INPUT chain where <NETWORK> is the network that you'll be using:
+
+
+
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 32769 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 662 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 662 -j ACCEPT
+
+
+
+
+
+ Run the following commands:
+
+
+
+# service iptables restart
+# service iptables save
+
+
+
+
+
+ If NFS v4 communication is used between client and server, add your domain to /etc/idmapd.conf on both the hypervisor host and Management Server.
+
+
+# vi /etc/idmapd.conf
+
+ Remove the character # from the beginning of the Domain line in idmapd.conf and replace the value in the file with your own domain. In the example below, the domain is company.com.
+
+
+Domain = company.com
+
+
+
+
+ Reboot the Management Server host.
+
+
+ Two NFS shares called /export/primary and /export/secondary are now set up.
+
+
+
+
+
+ It is recommended that you test to be sure the previous steps have been successful.
+
+
+
+
+ Log in to the hypervisor host.
+
+
+
+
+ Be sure NFS and rpcbind are running. The commands might be different depending on your OS. For example:
+
+
+
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+# reboot
+
+
+
+
+
+ Log back in to the hypervisor host and try to mount the /export directories. For example (substitute your own management server name):
+
+
+
+# mkdir /primarymount
+# mount -t nfs <management-server-name>:/export/primary /primarymount
+# umount /primarymount
+# mkdir /secondarymount
+# mount -t nfs <management-server-name>:/export/secondary /secondarymount
+# umount /secondarymount
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/nfs-shares-on-separate-server.xml b/docs/tmp/en-US/xml/nfs-shares-on-separate-server.xml
new file mode 100644
index 00000000000..a3c0958f849
--- /dev/null
+++ b/docs/tmp/en-US/xml/nfs-shares-on-separate-server.xml
@@ -0,0 +1,88 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using a Separate NFS Server
+
+ This section tells how to set up NFS shares for secondary and (optionally) primary storage on an NFS server running on a separate node from the Management Server.
+
+
+ The exact commands for the following steps may vary depending on your operating system version.
+
+
+
+ (KVM only) Ensure that no volume is already mounted at your NFS mount point.
+
+
+
+
+
+ On the storage server, create an NFS share for secondary storage and, if you are using NFS for primary storage as well, create a second NFS share. For example:
+
+
+
+# mkdir -p /export/primary
+# mkdir -p /export/secondary
+
+
+
+
+
+ To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s) with rw,async,no_root_squash. For example:
+
+
+# vi /etc/exports
+
+ Insert the following line.
+
+
+/export *(rw,async,no_root_squash)
+
+
+
+
+ Export the /export directory.
+
+
+# exportfs -a
+
+
+
+
+ On the management server, create a mount point for secondary storage. For example:
+
+
+# mkdir -p /mnt/secondary
+
+
+
+
+ Mount the secondary storage on your Management Server. Replace the example NFS server name and NFS share paths below with your own.
+
+
+# mount -t nfs nfsservername:/nfs/share/secondary /mnt/secondary
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/offerings.xml b/docs/tmp/en-US/xml/offerings.xml
new file mode 100644
index 00000000000..347e6148c45
--- /dev/null
+++ b/docs/tmp/en-US/xml/offerings.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Service Offerings
+
+ In this chapter we discuss compute, disk, and system service offerings. Network offerings are discussed in the section on setting up networking for users.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ongoing-configuration-of-external-firewalls-loadbalancer.xml b/docs/tmp/en-US/xml/ongoing-configuration-of-external-firewalls-loadbalancer.xml
new file mode 100644
index 00000000000..59cdbcc1c22
--- /dev/null
+++ b/docs/tmp/en-US/xml/ongoing-configuration-of-external-firewalls-loadbalancer.xml
@@ -0,0 +1,50 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Ongoing Configuration of External Firewalls and Load Balancers
+
+ Additional user actions (e.g. setting a port forward) will cause further programming of the firewall and load balancer. A user may request additional public IP addresses and forward traffic received at these IPs to specific VMs. This is accomplished by enabling static NAT for a public IP address, assigning the IP to a VM, and specifying a set of protocols and port ranges to open. When a static NAT rule is created, &PRODUCT; programs the zone's external firewall with the following objects:
+
+
+
+
+ A static NAT rule that maps the public IP address to the private IP address of a VM.
+
+
+
+
+ A security policy that allows traffic within the set of protocols and port ranges that are specified.
+
+
+
+
+ A firewall filter counter that measures the number of bytes of incoming traffic to the public IP.
+
+
+
+
+
+ The number of incoming and outgoing bytes through source NAT, static NAT, and load balancing rules is measured and saved on each external element. This data is collected on a regular basis and stored in the &PRODUCT; database.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/over-provisioning-service-offering-limits.xml b/docs/tmp/en-US/xml/over-provisioning-service-offering-limits.xml
new file mode 100644
index 00000000000..d6150c5b0ea
--- /dev/null
+++ b/docs/tmp/en-US/xml/over-provisioning-service-offering-limits.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Over-Provisioning and Service Offering Limits
+
+ &PRODUCT; performs CPU over-provisioning based on an over-provisioning ratio configured by the administrator. This is defined by the cpu.overprovisioning.factor global configuration variable.
+
+
+ &PRODUCT; performs CPU over-provisioning based on an over-provisioning ratio configured by the administrator. This is defined by the cpu.overprovisioning.factor global configuration variable
+
+
+ Service offerings 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. &PRODUCT; does not perform memory over-provisioning.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ovm-install.xml b/docs/tmp/en-US/xml/ovm-install.xml
new file mode 100644
index 00000000000..a8c9eba039c
--- /dev/null
+++ b/docs/tmp/en-US/xml/ovm-install.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Installing OVM for &PRODUCT;
+
+ TODO
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ovm-requirements.xml b/docs/tmp/en-US/xml/ovm-requirements.xml
new file mode 100644
index 00000000000..b50071f78a4
--- /dev/null
+++ b/docs/tmp/en-US/xml/ovm-requirements.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ System Requirements for OVM
+
+ TODO
+
+
+
+
diff --git a/docs/tmp/en-US/xml/per-domain-limits.xml b/docs/tmp/en-US/xml/per-domain-limits.xml
new file mode 100644
index 00000000000..d904590764e
--- /dev/null
+++ b/docs/tmp/en-US/xml/per-domain-limits.xml
@@ -0,0 +1,64 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Per-Domain Limits
+
+ &PRODUCT; allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of all accounts in the domain as well as all accounts in all subdomains of that domain. Limits set at the root domain level apply to the sum of resource usage by the accounts in all domains and sub-domains below that root domain.
+
+
+ To set a domain limit:
+
+
+
+
+ Log in to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation tree, click Domains.
+
+
+
+
+ Select the domain you want to modify. The current domain limits are displayed. A value of -1 shows that there is no limit in place.
+
+
+
+
+ Click the Edit button
+
+
+
+
+
+ editbutton.png: edits the settings.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/performance-monitoring.xml b/docs/tmp/en-US/xml/performance-monitoring.xml
new file mode 100644
index 00000000000..cacf39e0a59
--- /dev/null
+++ b/docs/tmp/en-US/xml/performance-monitoring.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Performance Monitoring
+
+ Host and guest performance monitoring is available to end users and administrators. This allows the user to monitor their utilization of resources and determine when it is appropriate to choose a more powerful service offering or larger disk.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/physical-network-configuration-settings.xml b/docs/tmp/en-US/xml/physical-network-configuration-settings.xml
new file mode 100644
index 00000000000..bc0e7582b0b
--- /dev/null
+++ b/docs/tmp/en-US/xml/physical-network-configuration-settings.xml
@@ -0,0 +1,67 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configurable Characteristics of Physical Networks
+
+ &PRODUCT; provides configuration settings you can use to set up a physical network in a zone, including:
+
+
+
+
+ What type of network traffic it carries (guest, public, management, storage)
+
+
+
+
+ VLANs
+
+
+
+
+ Unique name that the hypervisor can use to find that particular network
+
+
+
+
+ Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator sets the physical network to enabled, and it begins to be used. The administrator can later disable the network again, which prevents any new virtual networks from being created on that physical network; the existing network traffic continues even though the state is disabled.
+
+
+
+
+ Speed
+
+
+
+
+ Tags, so network offerings can be matched to physical networks
+
+
+
+
+ Isolation method
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-about.xml b/docs/tmp/en-US/xml/plugin-niciranvp-about.xml
new file mode 100644
index 00000000000..7601037d42b
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-about.xml
@@ -0,0 +1,25 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ The Nicira NVP Plugin
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-devicemanagement.xml b/docs/tmp/en-US/xml/plugin-niciranvp-devicemanagement.xml
new file mode 100644
index 00000000000..3cb8bb265b8
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-devicemanagement.xml
@@ -0,0 +1,91 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Device-management
+
+ In CloudStack 4.0.x each Nicira NVP setup is considered a "device" that can be added and removed from a physical network. To complete the configuration of the Nicira NVP plugin a device needs to be added to the physical network using the "addNiciraNVPDevice" API call. The plugin is now enabled on the physical network and any guest networks created on that network will be provisioned using the Nicra NVP Controller.
+
+
+ The plugin introduces a set of new API calls to manage the devices, see below or refer to the API reference.
+
+
+
+
+ addNiciraNvpDevice
+
+
+
+
+
+
+ physicalnetworkid: the UUID of the physical network on which the device is configured
+
+
+
+
+ hostname: the IP address of the NVP controller
+
+
+
+
+ username: the username for access to the NVP API
+
+
+
+
+ password: the password for access to the NVP API
+
+
+
+
+ transportzoneuuid: the UUID of the transportzone
+
+
+
+
+
+
+
+
+ deleteNiciraNVPDevice
+
+
+
+
+
+
+ nvpdeviceid: the UUID of the device
+
+
+
+
+
+
+
+
+ listNiciraNVPDevices
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-features.xml b/docs/tmp/en-US/xml/plugin-niciranvp-features.xml
new file mode 100644
index 00000000000..37819ddab67
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-features.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Features of the Nicira NVP Plugin
+
+ In CloudStack release 4.0.0-incubating this plugin supports the Connectivity service. This service is responsible for creating Layer 2 networks supporting the networks created by Guests. In other words when an tennant creates a new network, instead of the traditional VLAN a logical network will be created by sending the appropriate calls to the Nicira NVP Controller.
+
+
+ The plugin has been tested with Nicira NVP versions 2.1.0, 2.2.0 and 2.2.1
+
+
+
+ In CloudStack 4.0.0-incubating only the XenServer hypervisor is supported for use in combination with Nicira NVP
+
+
+
+
+ In CloudStack 4.0.0-incubating the UI components for this plugin are not complete, configuration is done by sending commands to the API
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-guide.xml b/docs/tmp/en-US/xml/plugin-niciranvp-guide.xml
new file mode 100644
index 00000000000..dfcc3291450
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-guide.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Plugin Guide for the Nicira NVP Plugin
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-introduction.xml b/docs/tmp/en-US/xml/plugin-niciranvp-introduction.xml
new file mode 100644
index 00000000000..af74860e7d6
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-introduction.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Introduction to the Nicira NVP Plugin
+
+ The Nicira NVP plugin allows CloudStack to use the Nicira solution for virtualized network as a provider for CloudStack networks and services.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-preparations.xml b/docs/tmp/en-US/xml/plugin-niciranvp-preparations.xml
new file mode 100644
index 00000000000..6a9816fe69f
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-preparations.xml
@@ -0,0 +1,66 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prerequisites
+
+ Before enabling the Nicira NVP plugin the NVP Controller needs to be configured. Please review the NVP User Guide on how to do that.
+
+
+ CloudStack needs to have at least one physical network with the isolation method set to "STT". This network should be enabled for the Guest traffic type.
+
+
+
+ The Guest traffic type should be configured with the traffic label that matches the name of the Integration Bridge on XenServer. See the Nicira NVP User Guide for more details on how to set this up in XenServer.
+
+
+
+ Make sure you have the following information ready:
+
+
+
+
+ The IP address of the NVP Controller
+
+
+
+
+ The username to access the API
+
+
+
+
+ The password to access the API
+
+
+
+
+ The UUID of the Transport Zone that contains the hypervisors in this Zone
+
+
+
+
+ The UUID of the Physical Network that will used for the Guest networks
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-provider.xml b/docs/tmp/en-US/xml/plugin-niciranvp-provider.xml
new file mode 100644
index 00000000000..070d2d241ff
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-provider.xml
@@ -0,0 +1,72 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Enabling the service provider
+
+ To allow CloudStack to use the Nicira NVP Plugin the network service provider needs to be enabled on the physical network. The following sequence of API calls will enable the network service provider
+
+
+
+
+ addNetworkServiceProvider
+
+
+
+
+
+
+ name = "NiciraNvp"
+
+
+
+
+ physicalnetworkid = <the uuid of the physical network>
+
+
+
+
+
+
+
+
+ updateNetworkServiceProvider
+
+
+
+
+
+
+ id = <the provider uuid returned by the previous call>
+
+
+
+
+ state = "Enabled"
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-revisions.xml b/docs/tmp/en-US/xml/plugin-niciranvp-revisions.xml
new file mode 100644
index 00000000000..60583414fb2
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-revisions.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Revision History
+
+
+
+ 0-0
+ Wed Oct 03 2012
+
+ Hugo
+ Trippaers
+ hugo@apache.org
+
+
+
+
+ Documentation created for 4.0.0-incubating version of the NVP Plugin
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-tables.xml b/docs/tmp/en-US/xml/plugin-niciranvp-tables.xml
new file mode 100644
index 00000000000..df6a1814809
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-tables.xml
@@ -0,0 +1,106 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Database tables
+
+ The following tables are added to the cloud database for the Nicira NVP Plugin
+
+
+
+
+ nicira_nvp_nic_map, contains a mapping from nic to logical switch port
+
+
+
+
+
+
+ id
+
+
+
+
+ logicalswitch, uuid of the logical switch this port is connected to
+
+
+
+
+ logicalswitchport, uuid of the logical switch port for this nic
+
+
+
+
+ nic, the CloudStack uuid for this nic, reference to the nics table
+
+
+
+
+
+
+
+
+
+
+
+ external_nicira_nvp_devices, contains all configured devices
+
+
+
+
+
+
+ id
+
+
+
+
+ uuid
+
+
+
+
+ physical_network_id, the physical network this device is configured on
+
+
+
+
+ provider_name, set to "NiciraNvp"
+
+
+
+
+ device_name, display name for this device
+
+
+
+
+ host_id, reference to the host table with the device configuration
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-troubleshooting.xml b/docs/tmp/en-US/xml/plugin-niciranvp-troubleshooting.xml
new file mode 100644
index 00000000000..ae958131366
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-troubleshooting.xml
@@ -0,0 +1,25 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Troubleshooting the Nicira NVP Plugin
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-usage.xml b/docs/tmp/en-US/xml/plugin-niciranvp-usage.xml
new file mode 100644
index 00000000000..726a0bccdb4
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-usage.xml
@@ -0,0 +1,26 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using the Nicira NVP Plugin
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/plugin-niciranvp-uuidreferences.xml b/docs/tmp/en-US/xml/plugin-niciranvp-uuidreferences.xml
new file mode 100644
index 00000000000..23f88ff799f
--- /dev/null
+++ b/docs/tmp/en-US/xml/plugin-niciranvp-uuidreferences.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ UUID References
+
+ The plugin maintains several references in the CloudStack database to items created on the NVP Controller.
+
+
+ Every guest network this is created will have its broadcast type set to Lswitch and if the network is in state "Implemented", the broadcast URI will have the UUID of the Logical Switch that was created for this network on the NVP Controller.
+
+
+ The Nics that are connected to one of the Logical Switches will have their Logical Switch Port UUID listed in the nicira_nvp_nic_map table
+
+
+
+ All devices created on the NVP Controller will have a tag set to domain-account of the owner of the network, this string can be used to search for items in the NVP Controller.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/pod-add.xml b/docs/tmp/en-US/xml/pod-add.xml
new file mode 100644
index 00000000000..021086db2ad
--- /dev/null
+++ b/docs/tmp/en-US/xml/pod-add.xml
@@ -0,0 +1,86 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Pod
+
+ When you created a new zone, &PRODUCT; adds the first pod for you. You can add more pods at any time using the procedure in this section.
+
+
+
+
+ Log in to the &PRODUCT; UI. See .
+
+
+
+
+ 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 &PRODUCT; 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.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/port-forwarding.xml b/docs/tmp/en-US/xml/port-forwarding.xml
new file mode 100644
index 00000000000..6d53f6e9be9
--- /dev/null
+++ b/docs/tmp/en-US/xml/port-forwarding.xml
@@ -0,0 +1,110 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Port Forwarding
+
+ A port forward service is a set of port forwarding rules that define a policy. A port forward service is then applied to one or more guest VMs. The guest VM then has its inbound network access managed according to the policy defined by the port forwarding service. You can optionally specify one or more CIDRs to filter the source IPs. This is useful when you want to allow only incoming requests from certain IP addresses to be forwarded.
+
+
+ A guest VM can be in any number of port forward services. Port forward services can be defined but have no members. If a guest VM is part of more than one network, port forwarding rules will function only if they are defined on the default network
+
+
+ You cannot use port forwarding to open ports for an elastic IP address. When elastic IP is used, outside access is instead controlled through the use of security groups. See Security Groups.
+
+
+ To set up port forwarding:
+
+
+
+
+ Log in to the CloudPlatform UI as an administrator or end user.
+
+
+
+
+ If you have not already done so, add a public IP address range to a zone in CloudPlatform. See Adding a Zone and Pod in the Installation Guide.
+
+
+
+
+ Add one or more VM instances to CloudPlatform.
+
+
+
+
+ In the left navigation bar, click Network.
+
+
+
+
+ Click the name of the guest network where the VMs are running.
+
+
+
+
+
+ Choose an existing IP address or acquire a new IP address. (See Acquiring a New IP Address on page 73.) Click the name of the IP address in the list.
+
+
+
+
+ Click the Configuration tab.
+
+
+
+
+ In the Port Forwarding node of the diagram, click View All.
+
+
+
+
+ Fill in the following:
+
+
+
+
+ Public Port. The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+
+
+
+
+ Private Port. The port on which the instance is listening for forwarded public traffic.
+
+
+
+
+ Protocol. The communication protocol in use between the two ports.
+
+
+
+
+
+
+
+ Click Add.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/prepare-nfs-shares.xml b/docs/tmp/en-US/xml/prepare-nfs-shares.xml
new file mode 100644
index 00000000000..85b122c6c5b
--- /dev/null
+++ b/docs/tmp/en-US/xml/prepare-nfs-shares.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare NFS Shares
+
+ &PRODUCT; needs a place to keep primary and secondary storage (see Cloud Infrastructure Overview). Both of these can be NFS shares. This section tells how to set up the NFS shares before adding the storage to &PRODUCT;.
+
+
+ For primary storage, you can use iSCSI instead.
+
+
+ The requirements for primary and secondary storage are described in:
+
+
+
+
+ About Primary Storage
+
+
+
+
+ About Secondary Storage
+
+
+
+
+
+ A production installation typically uses a separate NFS server. See .
+
+
+ You can also use the Management Server node as the NFS server. This is more typical of a trial installation, but is technically possible in a larger deployment. See .
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/prepare-os.xml b/docs/tmp/en-US/xml/prepare-os.xml
new file mode 100644
index 00000000000..98278eafc77
--- /dev/null
+++ b/docs/tmp/en-US/xml/prepare-os.xml
@@ -0,0 +1,228 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare the Operating System
+
+ The OS must be prepared to host the Management Server using the following steps. These steps must be performed on each Management Server node.
+
+
+
+
+ Log in to your OS as root.
+
+
+
+
+ Check for a fully qualified hostname.
+
+
+# hostname --fqdn
+
+ This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+
+
+
+
+ Set SELinux to be permissive by default.
+
+
+
+
+ Check to see whether SELinux is installed on your machine. If not, you can skip to step 4.
+
+
+ In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
+
+
+# rpm -qa | grep selinux
+
+ In Ubuntu, SELinux is not installed by default. You can verify this with:
+
+
+# dpkg --list 'selinux'
+
+
+
+
+ Set the SELINUX variable in /etc/selinux/config to “permissive”. This ensures that the permissive setting will be maintained after a system reboot.
+
+
+ In RHEL or CentOS:
+
+
+# vi /etc/selinux/config
+
+ In Ubuntu (do this step only if SELinux was found on the machine in the previous step):
+
+
+# selinux-config-enforcing permissive
+
+
+
+
+ Then set SELinux to permissive starting immediately, without requiring a system reboot.
+
+
+ In CentOS:
+
+
+# setenforce permissive
+
+ In RHEL:
+
+
+# setenforce 0
+
+ In Ubuntu (do this step only if SELinux was found on the machine):
+
+
+# setenforce permissive
+
+
+
+
+
+
+
+
+ Make sure that the machine can reach the Internet.
+
+
+# ping www.google.com
+
+
+
+
+ (RHEL 6.2) If you do not have a Red Hat Network account, you need to prepare a local Yum repository.
+
+
+
+
+ If you are working with a physical host, insert the RHEL 6.2 installation CD. If you are using a VM, attach the RHEL6 ISO.
+
+
+
+
+ Mount the CDROM to /media.
+
+
+
+
+ Create a repo file at /etc/yum.repos.d/rhel6.repo. In the file, insert the following lines:
+
+
+
+[rhel]
+name=rhel6
+baseurl=file:///media
+enabled=1
+gpgcheck=0
+
+
+
+
+
+
+
+
+
+ Turn on NTP for time synchronization.
+
+
+
+ NTP is required to synchronize the clocks of the servers in your cloud.
+
+
+
+
+
+ Install NTP.
+
+
+ On RHEL or CentOS:
+
+
+# yum install ntp
+
+ On Ubuntu:
+
+
+# apt-get install ntp
+
+
+
+
+ Edit the NTP configuration file to point to your NTP server.
+
+
+# vi /etc/ntp.conf
+
+ Add one or more server lines in this file with the names of the NTP servers you want to use. For example:
+
+
+server 0.xenserver.pool.ntp.org
+server 1.xenserver.pool.ntp.org
+server 2.xenserver.pool.ntp.org
+server 3.xenserver.pool.ntp.org
+
+
+
+
+
+ Restart the NTP client.
+
+
+# service ntpd restart
+
+
+
+
+ Make sure NTP will start again upon reboot.
+
+
+ On RHEL or CentOS:
+
+
+# chkconfig ntpd on
+
+ On Ubuntu:
+
+
+# chkconfig ntp on
+
+
+
+
+
+
+
+
+ Repeat all of these steps on every host where the Management Server will be installed.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/prepare-system-vm-template.xml b/docs/tmp/en-US/xml/prepare-system-vm-template.xml
new file mode 100644
index 00000000000..7e5e0899c2c
--- /dev/null
+++ b/docs/tmp/en-US/xml/prepare-system-vm-template.xml
@@ -0,0 +1,98 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare the System VM Template
+
+ Secondary storage must be seeded with a template that is used for &PRODUCT; system VMs.
+
+
+
+ When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text.
+
+
+
+
+
+
+ On the Management Server, run one or more of the following cloud-install-sys-tmplt commands to retrieve and decompress the system VM template. Run the command for each hypervisor type that you expect end users to run in this Zone.
+
+
+ If your secondary storage mount point is not named /mnt/secondary, substitute your own mount point name.
+
+
+ If you set the &PRODUCT; database encryption type to "web" when you set up the database, you must now add the parameter -s <management-server-secret-key>. See About Password and Key Encryption.
+
+
+ This process will require approximately 5 GB of free space on the local file system and up to 30 minutes each time it runs.
+
+
+
+
+ For XenServer:
+
+
+# /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 -h xenserver -s <optional-management-server-secret-key> -F
+
+
+
+
+ For vSphere:
+
+
+# /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.ova -h vmware -s <optional-management-server-secret-key> -F
+
+
+
+
+ For KVM:
+
+
+# /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -s <optional-management-server-secret-key> -F
+
+
+
+
+
+
+
+
+ If you are using a separate NFS server, perform this step. If you are using the Management Server as the NFS server, you MUST NOT perform this step.
+
+
+ When the script has finished, unmount secondary storage and remove the created directory.
+
+
+# umount /mnt/secondary
+# rmdir /mnt/secondary
+
+
+
+
+ Repeat these steps for each secondary storage server.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/prepare_os.xml b/docs/tmp/en-US/xml/prepare_os.xml
new file mode 100644
index 00000000000..45b0a07bc95
--- /dev/null
+++ b/docs/tmp/en-US/xml/prepare_os.xml
@@ -0,0 +1,223 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prepare the Operating System
+
+ The OS must be prepared to host the Management Server using the following steps. These steps must be performed on each Management Server node.
+
+
+
+
+ Log in to your OS as root.
+
+
+
+
+ Check for a fully qualified hostname.
+
+
+# hostname --fqdn
+
+ This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+
+
+
+
+ Set SELinux to be permissive by default.
+
+
+
+
+ Check to see whether SELinux is installed on your machine. If not, you can skip to step 4.
+
+
+ In RHEL or CentOS, SELinux are installed and enabled by default. You can verify this with:
+
+
+# rpm -qa | grep selinux
+
+ In Ubuntu, SELinux is not installed by default. You can verify this with:
+
+
+# dpkg --list 'selinux'
+
+
+
+
+ Set the SELINUX variable in /etc/selinux/config to “permissive”. This ensures that the permissive setting will be maintained after a system reboot.
+
+
+ In RHEL or CentOS:
+
+
+# vi /etc/selinux/config
+
+ In Ubuntu (do this step only if SELinux was found on the machine in the previous step):
+
+
+# selinux-config-enforcing permissive
+
+
+
+
+ Then set SELinux to permissive starting immediately, without requiring a system reboot.
+
+
+ In CentOS:
+
+
+# setenforce permissive
+
+ In RHEL:
+
+
+# setenforce 0
+
+ In Ubuntu (do this step only if SELinux was found on the machine):
+
+
+# setenforce permissive
+
+
+
+
+
+
+
+
+ Make sure that the Management Server can reach the Internet.
+
+
+# ping www.google.com
+
+
+
+
+ (RHEL 6.2) If you do not have a Red Hat Network account, you need to prepare a local Yum repository.
+
+
+
+
+ If you are working with a physical host, insert the RHEL 6.2 installation CD. If you are using a VM, attach the RHEL6 ISO.
+
+
+
+
+ Mount the CDROM to /media.
+
+
+
+
+ Create a repo file at /etc/yum.repos.d/rhel6.repo. In the file, insert the following lines:
+
+
+
+[rhel]
+name=rhel6
+baseurl=file:///media
+enabled=1
+gpgcheck=0
+
+
+
+
+
+
+
+
+
+ Turn on NTP for time synchronization.
+
+
+
+ NTP is required to synchronize the clocks of the servers in your cloud.
+
+
+
+
+
+ Install NTP.
+
+
+ On RHEL or CentOS:
+
+
+# yum install ntp
+
+ On Ubuntu:
+
+
+# apt-get install ntp
+
+
+
+
+ Edit the NTP configuration file to point to your NTP server.
+
+
+# vi /etc/ntp.conf
+
+ For example, you can use one of the following:
+
+
+0.xenserver.pool.ntp.org
+1.xenserver.pool.ntp.org
+2.xenserver.pool.ntp.org
+3.xenserver.pool.ntp.org
+
+
+
+
+
+ Restart the NTP client.
+
+
+# service ntpd restart
+
+
+
+
+ Make sure NTP will start again upon reboot.
+
+
+ On RHEL or CentOS:
+
+
+# chkconfig ntpd on
+
+ On Ubuntu:
+
+
+# chkconfig ntp on
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/primary-storage-add.xml b/docs/tmp/en-US/xml/primary-storage-add.xml
new file mode 100644
index 00000000000..daa786ef02f
--- /dev/null
+++ b/docs/tmp/en-US/xml/primary-storage-add.xml
@@ -0,0 +1,191 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Add Primary Storage
+
+ System Requirements for Primary Storage
+
+ Hardware requirements:
+
+
+
+
+ Any standards-compliant iSCSI or NFS server that is supported by the underlying hypervisor.
+
+
+
+
+ The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller.
+
+
+
+
+ Minimum required capacity depends on your needs.
+
+
+
+
+
+ When setting up primary storage, follow these restrictions:
+
+
+
+
+ Primary storage cannot be added until a host has been added to the cluster.
+
+
+
+
+ If you do not provision shared primary storage, you must set the global configuration parameter system.vm.local.storage.required to true, or else you will not be able to start VMs.
+
+
+
+
+
+
+
+
+ Adding Primary Stroage
+
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+
+
+
+ Be sure there is nothing stored on the server. Adding the server to &PRODUCT; will destroy any existing data.
+
+
+
+
+
+ Log in to the &PRODUCT; UI (see ).
+
+
+
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+
+
+
+
+ Click the Compute tab.
+
+
+
+
+ In the Primary Storage node of the diagram, click View All.
+
+
+
+
+ Click Add Primary Storage.
+
+
+
+
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+
+
+
+
+ Pod. The pod for the storage device.
+
+
+
+
+ Cluster. The cluster for the storage device.
+
+
+
+
+ Name. The name of the storage device.
+
+
+
+
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS.
+
+
+
+
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device.
+
+
+
+
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+
+
+
+
+ Path (for NFS). In NFS this is the exported path from the server.
+
+
+
+
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+
+
+
+
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+
+
+
+
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside &PRODUCT;.
+
+
+
+
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
+
+
+
+
+ Lun # (for iSCSI). In iSCSI this is 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.
+
+
+
+
+
+ Click OK.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/primary-storage-outage-and-data-loss.xml b/docs/tmp/en-US/xml/primary-storage-outage-and-data-loss.xml
new file mode 100644
index 00000000000..1d34c4e2c83
--- /dev/null
+++ b/docs/tmp/en-US/xml/primary-storage-outage-and-data-loss.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Primary Storage Outage and Data Loss
+
+ When a primary storage outage occurs the hypervisor immediately stops all VMs stored on that storage device. Guests that are marked for HA will be restarted as soon as practical when the primary storage comes back on line. With NFS, the hypervisor may allow the virtual machines to continue running depending on the nature of the issue. For example, an NFS hang will cause the guest VMs to be suspended until storage connectivity is restored.Primary storage is not designed to be backed up. Individual volumes in primary storage can be backed up using snapshots.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/primary-storage.xml b/docs/tmp/en-US/xml/primary-storage.xml
new file mode 100644
index 00000000000..04348e1fa60
--- /dev/null
+++ b/docs/tmp/en-US/xml/primary-storage.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Primary Storage
+
+ This section gives concepts and technical details about CloudPlatform primary storage. For information about how to install and configure primary storage through the CloudPlatform UI, see the Advanced Installation Guide.
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/private-public-template.xml b/docs/tmp/en-US/xml/private-public-template.xml
new file mode 100644
index 00000000000..c16fae44177
--- /dev/null
+++ b/docs/tmp/en-US/xml/private-public-template.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Private and Public Templates
+
+ When a user creates a template, it can be designated private or public.
+
+
+ Private templates are only available to the user who created them. By default, an uploaded template is private.
+
+
+ When a user marks a template as “public,” the template becomes available to all users in all accounts in the user's domain, as well as users in any other domains that have access to the Zone where the template is stored. This depends on whether the Zone, in turn, was defined as private or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any domain. If a public template is created in a private Zone, it is available only to users in the domain assigned to that Zone. If a public template is created in a public Zone, it is available to all users in all domains.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/projects-overview.xml b/docs/tmp/en-US/xml/projects-overview.xml
new file mode 100644
index 00000000000..570d83a616f
--- /dev/null
+++ b/docs/tmp/en-US/xml/projects-overview.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Overview of Projects
+
+ Projects are used to organize people and resources. &PRODUCT; 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. &PRODUCT; 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 &PRODUCT; to allow any user to create a new project, or you can restrict that ability to just &PRODUCT; administrators. Once you have created a project, you become that project’s administrator, and you can add others within your domain to the project. &PRODUCT; 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 &PRODUCT; 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 &PRODUCT; 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 &PRODUCT; 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..
+
+
+
+
diff --git a/docs/tmp/en-US/xml/projects.xml b/docs/tmp/en-US/xml/projects.xml
new file mode 100644
index 00000000000..8f14d21ba36
--- /dev/null
+++ b/docs/tmp/en-US/xml/projects.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using Projects to Organize Users and Resources
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/provisioning-auth-api.xml b/docs/tmp/en-US/xml/provisioning-auth-api.xml
new file mode 100644
index 00000000000..f91adc46da6
--- /dev/null
+++ b/docs/tmp/en-US/xml/provisioning-auth-api.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Provisioning and Authentication API
+
+ &PRODUCT; 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 &PRODUCT; to add/remove users..
+
+
+ &PRODUCT; supports pluggable authenticators. By default, &PRODUCT; 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/provisioning-steps-overview.xml b/docs/tmp/en-US/xml/provisioning-steps-overview.xml
new file mode 100644
index 00000000000..665f5ff9a4e
--- /dev/null
+++ b/docs/tmp/en-US/xml/provisioning-steps-overview.xml
@@ -0,0 +1,87 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; cloud infrastructure is organized, see .
+
+
+ To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
+
+
+
+
+ Change the root password. See .
+
+
+
+
+ Add a zone. See .
+
+
+
+
+ Add more pods (optional). See .
+
+
+
+
+ Add more clusters (optional). See .
+
+
+
+
+ Add more hosts (optional). See .
+
+
+
+
+ Add primary storage. See .
+
+
+
+
+ Add secondary storage. See .
+
+
+
+
+ Initialize and test the new cloud. See .
+
+
+
+
+
+ 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
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/provisioning-steps.xml b/docs/tmp/en-US/xml/provisioning-steps.xml
new file mode 100644
index 00000000000..de2246dcad3
--- /dev/null
+++ b/docs/tmp/en-US/xml/provisioning-steps.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Steps to Provisioning Your Cloud Infrastructure
+
+ This section tells how to add zones, pods, clusters, hosts, storage, and networks to your cloud. If you are unfamiliar with these entities, please begin by looking through .
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/provisioning.xml b/docs/tmp/en-US/xml/provisioning.xml
new file mode 100644
index 00000000000..252504c9de7
--- /dev/null
+++ b/docs/tmp/en-US/xml/provisioning.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Provisioning Your Cloud Infrastructure
+
+
+
+
diff --git a/docs/tmp/en-US/xml/query-filter.xml b/docs/tmp/en-US/xml/query-filter.xml
new file mode 100644
index 00000000000..eb60ff8e390
--- /dev/null
+++ b/docs/tmp/en-US/xml/query-filter.xml
@@ -0,0 +1,114 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Query Filter
+
+ The query filter is used to find a mapped user in the external LDAP server. The query filter should uniquely map the CloudPlatform user to LDAP user for a meaningful authentication. For more information about query filter syntax, consult the documentation for your LDAP server.
+
+
+ The CloudPlatform 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 CloudPlatform user name is the same as the LDAP user ID:
+
+
+(uid=%u)
+
+ If the CloudPlatform user name is the LDAP display name:
+
+
+(displayName=%u)
+
+ To find a user by email address:
+
+
+(mail=%e)
+
+
+
diff --git a/docs/tmp/en-US/xml/re-install-hosts.xml b/docs/tmp/en-US/xml/re-install-hosts.xml
new file mode 100644
index 00000000000..fed0a672874
--- /dev/null
+++ b/docs/tmp/en-US/xml/re-install-hosts.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/release-ip-address.xml b/docs/tmp/en-US/xml/release-ip-address.xml
new file mode 100644
index 00000000000..3211a3ce606
--- /dev/null
+++ b/docs/tmp/en-US/xml/release-ip-address.xml
@@ -0,0 +1,70 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Releasing an IP Address
+
+
+
+ Log in to the CloudPlatform UI as an administrator or end user.
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+ Click the name of the network where you want to work with.
+
+
+
+
+ Click View IP Addresses.
+
+
+
+
+ Click the IP address you want to release.
+
+
+
+
+
+ Click the Release IP button
+
+
+
+
+
+ ReleaseIPButton.png: button to release an IP
+
+
+
+ .
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/release-ip-for-vpc.xml b/docs/tmp/en-US/xml/release-ip-for-vpc.xml
new file mode 100644
index 00000000000..dc7cd78820d
--- /dev/null
+++ b/docs/tmp/en-US/xml/release-ip-for-vpc.xml
@@ -0,0 +1,126 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Releasing an IP Address Alloted to a VPC
+
+ The IP address is a limited resource. If you no longer need a particular IP, you can disassociate it from its VPC and return it to the pool of available addresses. An IP address can be released from its tier, only when all the networking ( port forwarding, load balancing, or StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to the same VPC.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC whose IP you want to release.
+
+
+ The VPC page is displayed where all the tiers you created are listed in a diagram.
+
+
+
+
+
+ Click the Settings icon.
+
+
+ The following options are displayed.
+
+
+
+
+ IP Addresses
+
+
+
+
+
+ Gateways
+
+
+
+
+
+ Site-to-Site VPN
+
+
+
+
+
+ Network ACLs
+
+
+
+
+
+
+
+
+
+ Select IP Addresses.
+
+
+ The IP Addresses page is displayed.
+
+
+
+
+
+ Click the IP you want to release.
+
+
+
+
+
+ In the Details tab, click the Release IP button
+
+
+
+
+
+ release-ip-icon.png: button to release an IP.
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/release-notes.ent b/docs/tmp/en-US/xml/release-notes.ent
new file mode 100644
index 00000000000..7858ad5f2e0
--- /dev/null
+++ b/docs/tmp/en-US/xml/release-notes.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/release-notes.fo b/docs/tmp/en-US/xml/release-notes.fo
new file mode 100644
index 00000000000..04d91b269f4
--- /dev/null
+++ b/docs/tmp/en-US/xml/release-notes.fo
@@ -0,0 +1,3233 @@
+
+Version 4.0.0-incubating Release Notes - Revised October 17, 2012 19:49 UTCDocBook XSL Stylesheets with Apache FOPVersion 4.0.0-incubating Release NotesTable of ContentsChapter 1. Submitting Feedback and Getting HelpChapter 2. Upgrade Instructions2.1. Upgrade from 3.0.2 to 4.0.0-incubating2.2. Upgrade from 2.2.14 to 4.0.0-incubatingChapter 3. Version 4.0.0-incubating3.1. What’s New in 4.0.0-incubating3.1.1. Inter-VLAN Routing3.1.2. Site-to-Site VPN3.1.3. Local Storage Support for Data Volumes3.1.4. Tags3.1.5. AWS API Changes for Tags3.1.6. Secure Console Access on XenServer3.1.7. Stopped VM3.1.8. Uploading an Existing Volume to a Virtual Machine3.1.9. Dedicated High-Availability Hosts3.1.10. Support for Amazon Web Services API3.1.11. The Nicira NVP Plugin3.1.12. Support for CAStor Cluster3.1.13. Clustered Logical Volume Manager Support for KVM3.1.14. Rados Block Device Support for KVM3.2. Issues Fixed in 4.0.0-incubating3.3. Known Issues in 4.0.0-incubatingChapter 4. API Changes from 3.0.2 to 4.0.0-incubating4.1. New API Commands in 4.0.0-incubating4.2. Changed API Commands in 4.0.0-incubatingVersion 4.0.0-incubating Release NotesApache CloudStack Version 4.0.0-incubating Release NotesRevised October 17, 2012 19:49 UTC
+
+
+ Apache CloudStackApache CloudStack Version 4.0.0-incubating Release NotesRevised October 17, 2012 19:49 UTCAuthorApache CloudStack
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+ Release notes for the Apache CloudStack 4.0.0-incubating release.
+ Version 4.0.0-incubating Release Notes1. Submitting Feedback and Getting Help2. Upgrade Instructions2.1. Upgrade from 3.0.2 to 4.0.0-incubating2.2. Upgrade from 2.2.14 to 4.0.0-incubating3. Version 4.0.0-incubating3.1. What’s New in 4.0.0-incubating3.2. Issues Fixed in 4.0.0-incubating3.3. Known Issues in 4.0.0-incubating4. API Changes from 3.0.2 to 4.0.0-incubating4.1. New API Commands in 4.0.0-incubating4.2. Changed API Commands in 4.0.0-incubatingChapter 1.Chapter 1. Submitting Feedback and Getting HelpSubmitting Feedback and Getting Help
+ The Apache CloudStack project has mailing lists for users and developers. These are the official channels of communication for the project and are the best way to get answers about using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users mailing list if you've deployed or are deploying CloudStack into production, and even for test deployments.
+
+ The CloudStack developer's mailing list (cloudstack-dev) is for discussions about CloudStack development, and is the best list for discussing possible bugs in CloudStack. Anyone contributing to CloudStack should be on this mailing list.
+
+ You can also report bugs in CloudStack using the Apache Defect Tracking System11https://issues.apache.org/jira/secure/CreateIssue!default.jspa
+
+ To posts to the lists, you'll need to be subscribed. See the CloudStack Web site22http://incubator.apache.org/cloudstack/mailing-lists.html for instructions.
+ Chapter 2.Chapter 2. Upgrade InstructionsUpgrade InstructionsUpgrade from 3.0.2 to 4.0.0-incubating2.1. Upgrade from 3.0.2 to 4.0.0-incubating
+ Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note that some of the steps here are only required if you're using a specific hypervisor. The steps that are hypervisor-specific are called out with a note.
+ 1.
+ Ensure that you query your IP address usage records and process them or make a backup. During the upgrade you will lose the old IP address usage records.
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading, any existing IP address usage records in the old format will no longer be available.
+ 2.Note
+ The following upgrade instructions apply only if you're using VMware hosts. If you're not using VMware hosts, skip this step and move on to step 3: stopping all usage servers.
+
+ In each zone that includes VMware hosts, you need to add a new system VM template.
+ a.
+ While running the existing 3.0.2 system, log in to the UI as root administrator.
+ b.
+ In the left navigation bar, click Templates.
+ c.
+ In Select view, click Templates.
+ d.
+ Click Register template.
+
+ The Register template dialog box is displayed.
+ e.
+ In the Register template dialog box, specify the following values (do not change these):
+
+
+ Field
+
+
+
+ Value
+
+
+
+ Name
+
+
+
+ systemvm-vmware-3.0.5
+
+
+
+ Description
+
+
+
+ systemvm-vmware-3.0.5
+
+
+
+ URL
+
+
+
+ http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+
+ Zone
+
+
+
+ Choose the zone where this hypervisor is used
+
+
+
+ Hypervisor
+
+
+
+ VMware
+
+
+
+ Format
+
+
+
+ OVA
+
+
+
+ OS Type
+
+
+
+ Debian GNU/Linux 5.0 (32-bit)
+
+
+
+ Extractable
+
+
+
+ no
+
+
+
+ Password Enabled
+
+
+
+ no
+
+
+
+ Public
+
+
+
+ no
+
+
+
+ Featured
+
+
+
+ no
+
+ f.
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful.
+ 3.
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+ # service cloud-usage stop4.
+ Stop the Management Servers. Run this on all Management Server hosts.
+ # service cloud-management stop5.
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+ 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.
+ #mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp6.
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
+ 7.
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
+#yum update cloud-*
+
+#apt-get update
+#apt-get upgrade cloud-*
+
+ Note
+ If the upgrade output includes a message similar to the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+ warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+ Instructions follow in the next step.
+ 8.
+ If you have made changes to your copy of /etc/cloud/management/components.xml the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+ a.
+ Make a backup copy of /etc/cloud/management/components.xml. For example:
+ # mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backupb.
+ Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:
+ # cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xmlc.
+ Merge your changes from the backup file into the new components.xml.
+ # vi /etc/cloud/management/components.xmlNote
+ If you have more than one management server node, repeat the upgrade steps on each node.
+ 9.
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+ # service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. After confirmation, start the other Management Servers one at a time by running the same command on each node.
+ Note
+ Failing to restart the Management Server indicates a problem in the upgrade. Having the Management Server restarted without any issues indicates that the upgrade is successfully completed.
+ 10.
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
+ # service cloud-usage start
+ 11.Note
+ Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+ a.
+ Configure a yum or apt respository containing the CloudStack packages as outlined in the Installation Guide.
+ b.
+ Stop the running agent.
+
+ # service cloud-agent stop
+ c.
+ Update the agent software with one of the following command sets as appropriate for your environment.
+
+ # yum update cloud-*
+
+ # apt-get update
+
+ # apt-get upgrade cloud-*
+ d.
+ Start the agent.
+ # service cloud-agent starte.
+ Edit /etc/cloud/agent/agent.properties to change the resource parameter from "com.cloud.agent.resource.computing.LibvirtComputingResource" to "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
+ f.
+ Start the cloud agent and cloud management services.
+ g.
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+ 12.
+ Log in to the CloudStack UI as administrator, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+ Note
+ Troubleshooting: If login fails, clear your browser cache and reload the page.
+
+
+ Do not proceed to the next step until the hosts show in Up state.
+ 13.
+ If you are upgrading from 3.0.2, perform the following:
+ a.
+ Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter.
+
+ This port is used by the cloud-sysvmadm script at the end of the upgrade procedure. For information about how to set this parameter, see "Setting Global Configuration Parameters" in the Installation Guide.
+ b.
+ Restart the Management Server.
+ Note
+ If you don't want the admin port to remain open, you can set it to null after the upgrade is done and restart the management server.
+ 14.
+ Run the cloud-sysvmadm script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the -c and -r arguments. For example:
+
+ # nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+
+ # tail -f sysvm.log
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+ 15.
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+ 16.
+ Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+ a.
+ Disconnect the XenServer cluster from CloudStack.
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+ b.
+ To clean up the VLAN, log in to one XenServer host and run:
+
+ /opt/xensource/bin/cloud-clean-vlan.sh
+ c.
+ Now prepare the upgrade by running the following on one XenServer host:
+
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+
+ If you see a message like "can't eject CD", log in to the VM and unmount the CD, then run this script again.
+ d.
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /tmp.
+
+ On the Xen pool master, upload the hotfix with this command:
+
+ xe patch-upload file-name=XS602E003.xsupdate
+
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+ Note
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+ e.
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
+ # xe vm-list
+
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+ # xe vm-migrate live=true host=host-name vm=VM-name
+ Troubleshooting
+ If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
+
+ /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.
+ f.
+ Apply the hotfix. First, get the UUID of this host:
+ # xe host-list
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+ xe patch-apply host-uuid=host-uuid uuid=hotfix-uuidg.
+ Copy the following files from the CloudStack Management Server to the host.
+
+
+ Copy from here...
+
+
+
+ ...to here
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+ h.
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
+ •
+ Download the CSP software onto the XenServer host from one of the following links:
+
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+ •
+ Extract the file:
+ # tar xf xenserver-cloud-supp.tgz•
+ Run the following script:
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso•
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+ # xe-switch-network-backend bridgei.
+ Reboot this XenServer host.
+ j.
+ Run the following:
+ /opt/xensource/bin/setupxenserver.shNote
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+ k.
+ Run the following:
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;l.
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+ Troubleshooting Tip
+ If passwords which you know to be valid appear not to work after upgrade, or other UI issues are seen, try clearing your browser cache and reloading the UI page.
+ Upgrade from 2.2.14 to 4.0.0-incubating2.2. Upgrade from 2.2.14 to 4.0.0-incubating1.
+ Ensure that you query your IPaddress usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading to 4.0.0-incubating, any existing IP address usage records in the old format will no longer be available.
+ 2.
+ If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the instructions in the 2.2.14 Release Notes.
+ KVM Hosts
+ If KVM hypervisor is used in your cloud, be sure you completed the step to insert a valid username and password into the host_details table on each KVM node as described in the 2.2.14 Release Notes. This step is critical, as the database will be encrypted after the upgrade to 4.0.0-incubating.
+ 3.
+ While running the 2.2.14 system, log in to the UI as root administrator.
+ 4.
+ Using the UI, add a new System VM template for each hypervisor type that is used in your cloud. In each zone, add a system VM template for each hypervisor used in that zone
+ a.
+ In the left navigation bar, click Templates.
+ b.
+ In Select view, click Templates.
+ c.
+ Click Register template.
+
+ The Register template dialog box is displayed.
+ d.
+ In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):
+
+
+ Hypervisor
+
+
+
+ Description
+
+
+
+ XenServer
+
+
+
+ Name: systemvm-xenserver-3.0.0
+
+
+ Description: systemvm-xenserver-3.0.0
+
+
+ URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: XenServer
+
+
+ Format: VHD
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+ KVM
+
+
+
+ Name: systemvm-kvm-3.0.0
+
+
+ Description: systemvm-kvm-3.0.0
+
+
+ URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: KVM
+
+
+ Format: QCOW2
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+ VMware
+
+
+
+ Name: systemvm-vmware-3.0.5
+
+
+ Description: systemvm-vmware-3.0.5
+
+
+ URL: http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: VMware
+
+
+ Format: OVA
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+ 5.
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful
+ 6.
+ WARNING: If you use more than one type of hypervisor in your cloud, be sure you have repeated these steps to download the system VM template for each hypervisor type. Otherwise, the upgrade will fail.
+ 7.
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+ # service cloud-usage stop8.
+ Stop the Management Servers. Run this on all Management Server hosts.
+ # service cloud-management stop9.
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+ 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.
+ #mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp10.
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
+ 11.
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
+#yum update cloud-*
+
+#apt-get update
+#apt-get upgrade cloud-*
+
+ 12.
+ If you have made changes to your existing copy of the file components.xml in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+ Note
+ How will you know whether you need to do this? If the upgrade output in the previous step included a message like the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+ warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnewa.
+ Make a backup copy of your /etc/cloud/management/components.xml file. For example:
+ #mv/etc/cloud/management/components.xml/etc/cloud/management/components.xml-backupb.
+ Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:
+ #cp -ap /etc/cloud/management/components.xml.rpmnew/etc/cloud/management/components.xmlc.
+ Merge your changes from the backup file into the new components.xml file.
+ #vi/etc/cloud/management/components.xml
+13.
+ If you have made changes to your existing copy of the /etc/cloud/management/db.properties file in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+ a.
+ Make a backup copy of your file /etc/cloud/management/db.properties. For example:
+ #mv/etc/cloud/management/db.properties/etc/cloud/management/db.properties-backupb.
+ Copy /etc/cloud/management/db.properties.rpmnew to create a new /etc/cloud/management/db.properties:
+ #cp -ap /etc/cloud/management/db.properties.rpmnewetc/cloud/management/db.propertiesc.
+ Merge your changes from the backup file into the new db.properties file.
+ #vi/etc/cloud/management/db.properties14.
+ On the management server node, run the following command. It is recommended that you use the command-line flags to provide your own encryption keys. See Password and Key Encryption in the Installation Guide.
+ #cloud-setup-encryption -e encryption_type -m management_server_key -k database_key
+ When used without arguments, as in the following example, the default encryption type and keys will be used:
+ •
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file.
+ •
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the properties file. Default: password. It is highly recommended that you replace this with a more secure value
+ •
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value.
+ 15.
+ Repeat steps 10 - 14 on every management server node. If you provided your own encryption key in step 14, use the same key on all other management servers.
+ 16.
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+ # service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. You should see a message like "Complete! Done." After confirmation, start the other Management Servers one at a time by running the same command on each node.
+ 17.
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+ # service cloud-usage start18.
+ (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+ a.
+ Configure your CloudStack package repositories as outlined in the Installation Guide
+ b.
+ Stop the running agent.
+ # service cloud-agent stopc.
+ Update the agent software with one of the following command sets as appropriate.
+ #yum update cloud-*
+ #apt-get update
+#apt-get upgrade cloud-*
+d.
+ Start the agent.
+ # service cloud-agent starte.
+ Copy the contents of the agent.properties file to the new agent.properties file by using the following command
+ sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.propertiesf.
+ Start the cloud agent and cloud management services.
+ g.
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+ 19.
+ Log in to the CloudStack UI as admin, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
+ Do not proceed to the next step until the hosts show in the Up state. If the hosts do not come to the Up state, contact support.
+ 20.
+ Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers.
+ a.
+ Run the command once on one management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the "-c" and "-r" arguments. For example:
+ #nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+#tail -f sysvm.log
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+ b.
+ After the script terminates, check the log to verify correct execution:
+ #tail -f sysvm.log
+ The content should be like the following:
+
+Stopping and starting 1 secondary storage vm(s)...
+Done stopping and starting secondary storage vm(s)
+Stopping and starting 1 console proxy vm(s)...
+Done stopping and starting console proxy vm(s).
+Stopping and starting 4 running routing vm(s)...
+Done restarting router(s).
+21.
+ If you would like additional confirmation that the new system VM templates were correctly applied when these system VMs were rebooted, SSH into the System VM and check the version.
+
+ Use one of the following techniques, depending on the hypervisor.
+ XenServer or KVM:
+ SSH in by using the link local IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own link local IP.
+
+ Run the following commands on the XenServer or KVM host on which the system VM is present:
+ #ssh -i private-key-pathlink-local-ip -p 3922
+# cat /etc/cloudstack-release
+ The output should be like the following:
+ Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012ESXi
+ SSH in using the private IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own private IP.
+
+ Run the following commands on the Management Server:
+ #ssh -i private-key-pathprivate-ip -p 3922
+#cat/etc/cloudstack-release
+ The output should be like the following:
+ Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 201222.
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+ 23.
+ Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+ a.
+ Disconnect the XenServer cluster from CloudStack.
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+ b.
+ To clean up the VLAN, log in to one XenServer host and run:
+ /opt/xensource/bin/cloud-clean-vlan.shc.
+ Prepare the upgrade by running the following on one XenServer host:
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+ If you see a message like "can't eject CD", log in to the VM and umount the CD, then run this script again.
+ d.
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /root or /tmp.
+
+ On the Xen pool master, upload the hotfix with this command:
+ xe patch-upload file-name=XS602E003.xsupdate
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+ Note
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+ e.
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+ # xe vm-list
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+ #xe vm-migrate live=true host=host-name vm=VM-nameTroubleshooting
+ If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
+
+ /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.
+ f.
+ Apply the hotfix. First, get the UUID of this host:
+
+ # xe host-list
+
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+ xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid
+ g.
+ Copy the following files from the CloudStack Management Server to the host.
+
+
+ Copy from here...
+
+
+
+ ...to here
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+ h.
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
+ •
+ Download the CSP software onto the XenServer host from one of the following links:
+
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+ •
+ Extract the file:
+
+ # tar xf xenserver-cloud-supp.tgz
+ •
+ Run the following script:
+
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso
+ •
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
+ # xe-switch-network-backend bridge
+ i.
+ Reboot this XenServer host.
+ j.
+ Run the following:
+
+ /opt/xensource/bin/setupxenserver.sh
+ Note
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+ k.
+ Run the following:
+
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+ l.
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+ Chapter 3.Chapter 3. Version 4.0.0-incubatingVersion 4.0.0-incubatingWhat’s New in 4.0.0-incubating3.1. What’s New in 4.0.0-incubating
+ Apache CloudStack 4.0.0-incubating includes the following new features:
+ Inter-VLAN Routing3.1.1. Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You can provision VLANs to the tiers your create, and VMs can be deployed on different tiers, such as Web, Application, or Database. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+ This feature is supported on XenServer and VMware hypervisors.
+ Site-to-Site VPN3.1.2. Site-to-Site VPN
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+ The supported endpoints on the remote datacenters are:
+ •
+ Cisco ISR with IOS 12.4 or later
+ •
+ Juniper J-Series routers with JunOS 9.5 or later
+ Local Storage Support for Data Volumes3.1.3. Local Storage Support for Data Volumes
+ You can now create data volumes on local storage. The data volume is placed on the same XenServer host as the VM instance that is attached to the data volume. These local data volumes can be attached to virtual machines, detached, re-attached, and deleted just as with the other types of data volume. In earlier releases of CloudStack, only the root disk could be placed in local storage.
+
+ Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some of the benefits include reduced disk I/O latency and cost reduction from using inexpensive local disks.
+
+ In order for local volumes to be used, the feature must be enabled for the zone.
+
+ You can create a data disk offering for local storage. When a user creates a new VM, they can select this disk offering in order to cause the data disk volume to be placed in local storage.
+
+ You can not migrate a VM that has a volume in local storage to a different host, nor migrate the volume itself away to a different host. If you want to put a host into maintenance mode, you must first stop any VMs with local data volumes on that host.
+
+ Local storage support for volumes is available for XenServer, KVM, and VMware hypervisors.
+ Tags3.1.4. Tags
+ 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 new 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.
+
+ A new optional input parameter, "tags," has been added to 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:
+ 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 new "tags" input parameter:
+ •
+ listVirtualMachines
+ •
+ listVolumes
+ •
+ listSnapshots
+ •
+ listNetworks
+ •
+ listTemplates
+ •
+ listIsos
+ •
+ listFirewallRules
+ •
+ listPortForwardingRules
+ •
+ listPublicIpAddresses
+ •
+ listSecurityGroups
+ •
+ listLoadBalancerRules
+ •
+ listProjects
+ •
+ listVPCs
+ •
+ listNetworkACLs
+ •
+ listStaticRoutes
+ AWS API Changes for Tags3.1.5. AWS API Changes for Tags
+ Some changes have been made to the Amazon Web Services API compatibility support in order to accommodate the new tagging feature.
+
+ New APIs:
+
+
+ New API
+
+
+
+
+ Description
+
+
+
+
+ ec2-create-tags
+
+
+
+
+ Add tags to one or more resources.
+
+
+
+
+ ec2-delete-tags
+
+
+
+
+ Remove tags from one or more resources.
+
+
+
+ ec2-describe-tags
+
+
+ Show currently defined tags.
+
+
+
+ Changed APIs:
+
+
+ Changed API
+
+
+
+
+ Description
+
+
+
+ ec2-describe-images
+
+
+ Output now shows tags defined for each image.
+
+
+
+
+ ec2-describe-instances
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+ ec2-describe-snapshots
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+ ec2-describe-volumes
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+ Secure Console Access on XenServer3.1.6. Secure Console Access on XenServer
+ With the addition of Secure Console feature, users can now securely access the VM consoles on the XenServer hypervisor. You can either SSH or use the View Console option in the Management Server to securely connect to the VMs on the XenServer host. The Management Server uses the xapi API to stream the VM consoles. However, there is no change in the way you can access the console of a VM. This feature is supported on XenServer 5.6 and 6.0 versions.
+ Stopped VM3.1.7. Stopped VM
+ This release supports creating VMs without starting them on the backend. You can determine whether the VM needs to be started as part of the VM deployment. A VM can be deployed in two ways: create and start a VM (the default method); create a VM and leave it in the stopped state.
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. The possible values are:
+ •
+ true - The VM starts as a part of the VM deployment
+ •
+ false - The VM is left in stopped state at the end of the VM deployment
+ Uploading an Existing Volume to a Virtual Machine3.1.8. Uploading an Existing Volume to a Virtual Machine
+ Existing data can now be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs. The upload is performed by using HTTP. The uploaded volume is placed in the zone's secondary storage.
+
+ This functionality is supported for the following hypervisors:
+ •
+ Hypervisor : Disk Image Format
+ •
+ XenServer : VHD
+ •
+ VMware : OVA
+ •
+ KVM : QCOW2
+ Dedicated High-Availability Hosts3.1.9. Dedicated High-Availability Hosts
+ One or more hosts can now be designated for use only by high-availability (HA) enabled VMs that are restarted due to a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HA-enabled VMs make it easier to determine which VMs are restarted as part of the high-availability function. You can designate a host as a dedicated-HA restart node only if the Dedicated HA Hosts feature is enabled by setting the appropriate global configuration parameter.
+ Support for Amazon Web Services API3.1.10. Support for Amazon Web Services API
+ This release supports Amazon Web Services APIs, including Elastic Compute Cloud (EC2) API. Fidelity with the EC2 API and the installation experience for this functionality are both enhanced. In prior releases, users were required to install a separate component called CloudBridge, in addition to installing the Management Server. For new installations of CloudStack 4.0.0-incubating, this software is installed automatically along with CloudStack and runs in a more closely integrated fashion. The feature is disabled by default, but can be easily enabled by setting the appropriate global configuration parameter and performing a few setup steps.
+ The Nicira NVP Plugin3.1.11. The Nicira NVP Plugin
+ The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating this plug-in supports the Connectivity service. This service is responsible for creating Layer 2 networks supporting the networks created by guests. When a tenant creates a new network, instead of a traditional VLAN, a logical network will be created by sending the appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira NVP versions 2.1.0, 2.2.0 and 2.2.1.
+ Support for CAStor Cluster3.1.12. Support for CAStor Cluster
+ CloudStack 4.0.0-incubating supports using a CAStor cluster as the back-end storage system for a CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends the existing storage classes and allows the storage configuration attribute to point to a CAStor cluster. This feature makes use of the CloudStack server's local disk to spool files before writing them to CAStor when handling the PUT operations. However, a file must be successfully written into the CAStor cluster prior to the return of a success code to the S3 client to ensure that the transaction outcome is correctly reported.
+
+ The S3 multipart file upload is not supported in this release. You are prompted with proper error message if a multipart upload is attempted.
+ Clustered Logical Volume Manager Support for KVM3.1.13. Clustered Logical Volume Manager Support for KVM
+ This release adds Clustered Logical Volume Manager (CLVM) storage support for KVM hosts. With this support, you can use CLVM as primary storage.
+
+ The CLVM support for KVM allows root and data disks (primary storage) to reside on Linux logical volumes. The administrators are required to configure CLVM on the KVM hosts independent of CloudStack. When the volume groups are available, an administrator can simply add primary storage of type CLVM, providing the volume group name. Then CloudStack creates and manages logical volumes as needed.
+
+ CLVM also supports Snapshots. CloudStack creates an LVM snapshot, copy the applicable logical volume to the secondary storage in the qcow2 format, and then delete the LVM snapshot.
+ Rados Block Device Support for KVM3.1.14. Rados Block Device Support for KVM
+ You can now use Rados Block Device (RBD) to run instances on Apache CloudStack 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least 0.10 with RBD enabled on the KVM host
+
+ Create a disk offering for RBD so that you can ensure that StoragePoolAllocator chooses the RBD pool to deploy instances.
+ Issues Fixed in 4.0.0-incubating3.2. Issues Fixed in 4.0.0-incubating
+ Many bugs include a defect number that reflects the bug number that was held in the bug tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira11https://issues.apache.org/jira/browse/CLOUDSTACK to manage its bugs, so some of the bugs that are referenced here may not be available to view. However, we are still including them for completeness.
+
+
+ Defect
+
+
+
+
+ Description
+
+
+
+
+ Many
+
+
+
+ vSphere 5.0 now has GA support. Formerly only Beta support was provided.
+
+
+
+ CS-16135
+
+
+
+ Creating volumes after upgrading from snapshot taken in 2.2.14 no longer deletes the snapshot physically from the secondary storage.
+
+
+
+ CS-16122
+
+
+
+ In a site-to-site VPN setup, alerts are generated when the VPC virtual router is rebooted with multiple vpn connections.
+
+
+
+ CS-16022
+
+
+
+ If host connection fails due to a database error, host now disconnects and the Managerment Server id is removed.
+
+
+
+ CS-16011
+
+
+
+ Name of network offering is no longer truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+ CS-15978
+
+
+
+ When the virtual router and its host go down, the high availability mechanism now works for the virtual router.
+
+
+
+
+ CS-15921
+
+
+
+ The 2.2.x security group script now accounts for the VMs created in the version 2.1 timeframe.
+
+
+
+
+ CS-15919
+
+
+
+ A level parameter is added to the listVolumes command; therefore queries return the response more quickly.
+
+
+
+ CS-15904
+
+
+
+ Upgrade from version 2.2.14 to CloudStack-3.0.5-0.2944-rhel5 works as expected. The upgrade script, /usr/share/cloud/setup/db/schema-2214to30-cleanup.sql, works as expected.
+
+
+
+ CS-15879
+
+
+
+ The database upgrade from version 3.0.4 to 3.0.5 works as expected.
+
+
+
+
+ CS-15807
+
+
+
+ Network label for OVM now available in UI.
+
+
+
+
+ CS-15779
+
+
+
+ When the thumbnail is requested, the console session will not be terminated.
+
+
+
+
+ CS-15778
+
+
+
+ Fetching a VM thumbnail now gets a thumbnail of appropriate visual dimensions.
+
+
+
+
+ CS-15734
+
+
+
+ KVM Snapshots no longer shows incorrect disk usage.
+
+
+
+ CS-15733
+
+
+
+ The domainId parameter for the listNetworks command now lists the resources belonging to the domain specified.
+
+
+
+ CS-15676
+
+
+
+ Stopping the router no longer fails with the null pointer exception.
+
+
+
+
+ CS-15648
+
+
+
+ If creating a volume from a snapshot fails, the error is reported on the UI but the volume is stuck in the creating state.
+
+
+
+
+ CS-15646
+
+
+
+ createFirewallRule API no longer causes null pointer exception.
+
+
+
+ CS-15628
+
+
+
+ In a KVM host, the high availability mechanism no longer takes a long time to migrate VMs to another KVM host if there are multiple storage pools.
+
+
+
+ CS-15627
+
+
+
+ Metadata instance-id and vm-id for existing VMs stays the same after upgrade.
+
+
+
+ CS-15621
+
+
+
+ Solved difficulty with allocating disk volumes when running multiple VM deployment in parallel.
+
+
+
+ CS-15603
+
+
+
+ CloudStack now stop the VMs when destroyVM command is called.
+
+
+
+ CS-15586
+
+
+
+ Public Vlan for an account no longer fails if multiple physical networks are present.
+
+
+
+ CS-15582
+
+
+
+ The dns-name filter is now supported for ec2-describe-instances in the Amazon Web Services API compatibility commands. The filter maps to the name of a user VM.
+
+
+
+ CS-15503
+
+
+
+ An IP address which has static NAT rules can now be released. Subsequently, restarting this network after it was shutdown can succeed.
+
+
+
+ CS-15464
+
+
+
+ Can now delete static route whose state is set to Revoke.
+
+
+
+ CS-15443
+
+
+
+ Creating a firewall rule no longer fails with an internal server error.
+
+
+
+ CS-15398
+
+
+
+ Corrected technique for programming DNS on the user VMs.
+
+
+
+ CS-15356
+
+
+
+ Internal DNS 2 entry now correctly shown in UI.
+
+
+
+ CS-15335
+
+
+
+ The CloudBridge S3 Engine now connects to the database by using the deciphered password in the db.properties file.
+
+
+
+ CS-15318
+
+
+
+ UI now correctly prevents the user from stopping a VM that is in the Starting state.
+
+
+
+ CS-15307
+
+
+
+ Fixed Japanese localization of instance statuses in the Instances menu.
+
+
+
+ CS-15278
+
+
+
+ The deployment planner no longer takes long time to locate a suitable host to deploy VMs when large number of clusters are present.
+
+
+
+ CS-15274
+
+
+
+ Creating a VLAN range using Zone ID without network ID now succeeds.
+
+
+
+ CS-15243
+
+
+
+ Now check to be sure source NAT and VPN have same provider.
+
+
+
+ CS-15232
+
+
+
+ Ensure that networks using external load balancer/firewall in 2.2.14 or earlier can properly upgrade.
+
+
+
+ CS-15200
+
+
+
+ No exception when trying to attach the same volume while attaching the first volume is in progress.
+
+
+
+ CS-15173
+
+
+
+ Additional cluster can no longer be added with same VSM IP address as another cluster.
+
+
+
+ CS-15167
+
+
+
+ AWS API calls now honor the admin account's ability to view or act on the resources owned by the regular users.
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+ CS-15157
+
+
+
+ Can now add/enable service providers for multiple physical networks through the UI.
+
+
+
+ CS-15145
+
+
+
+ AWS API call ec2-register has better error handling for negative cases.
+
+
+
+ CS-15122
+
+
+
+ Filters now supported for AWS API call ec2-describe-availability-zones.
+
+
+
+ CS-15120
+
+
+
+ Actions column in UI of Volume page now shows action links.
+
+
+
+ CS-15099
+
+
+
+ Buttons no longer overlap text on Account Deletion confirmation page in UI.
+
+
+
+ CS-15095
+
+
+
+ Ensures you can not create a VM with a CPU frequency greater than the host CPU frequency.
+
+
+
+ CS-15094
+
+
+
+ CPU cap now set properly in VMware.
+
+
+
+ CS-15077
+
+
+
+ NullPointerException is no longer observed while executing the command to list the public IP in a basic zone created with the default shared NetScaler EIP and ELB network offering.
+
+
+
+ CS-15044
+
+
+
+ UI now provides option to view the list of instances which are part of the guest network.
+
+
+
+ CS-15026
+
+
+
+ UI in Deploy VM dialog now lists only templates or ISOs depending on which is selected in previous dialog.
+
+
+
+ CS-14989
+
+
+
+ In KVM, the Create Instance wizard now shows only templates from the current (KVM) zone.
+
+
+
+ CS-14986, CS-14985
+
+
+
+ Listing filters works as expected in the ec2-describe-volumes and ec2-describe-snapshots commands.
+
+
+
+ CS-14964
+
+
+
+ Automatically starting the Console Proxy no longer fails due to its missing volume on the primary storage
+
+
+
+ CS-14907
+
+
+
+ User is now correctly prevented from trying to download an uploaded volume which has not yet been moved to primary storage.
+
+
+
+ CS-14879
+
+
+
+ When a user VM is stopped or terminated, the static NAT associated with this VM is now disabled. This public IP address is no longer owned by this account and can be associated to any other user VM.
+
+
+
+ CS-14854
+
+
+
+ Only the admin user can change the template permission to Public, so this option is removed from the UI for domain Admins and regular Users.
+
+
+
+ CS-14817
+
+
+
+ While checking if network has any external provider, CloudStack will consider all providers in the network.
+
+
+
+ CS-14796
+
+
+
+ When deploying a VM with ec2-run-instances, userdata is now encoded.
+
+
+
+ CS-14770
+
+
+
+ The API returns the keypair information when a VM is deployed with sshkey. This affects the API commands related to virtual machines (deployVirtualMachine, listVirtualMachines, ... *VirtualMachine), as well as the corresponding AWS APIs.
+
+
+
+ CS-14724
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+ CS-14345
+
+
+
+ Logout API returns XML header.
+
+
+
+ CS-14724
+
+
+
+ Host IPs now associated with appropriate IPs according to traffic type.
+
+
+
+ CS-14253
+
+
+
+ Can now delete and re-create port forwarding rule on same firewall.
+
+
+
+ CS-14724
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+ CS-14452
+
+
+
+ Data disk volumes are now automatically copied from one cluster to another.
+
+
+
+ CS-13539
+
+
+
+ Windows VM can get IP after reboot.
+
+
+
+ CS-13537
+
+
+
+ When user tries to delete a domain that contains sub-domains, an error message is now sent to convey the reason for the delete failure.
+
+
+
+ CS-13153
+
+
+
+ System VMs support HTTP proxy.
+
+
+
+ CS-12642
+
+
+
+ Added Close button to Select Project list view popup in UI.
+
+
+
+ CS-12510
+
+
+
+ Deleting and reinserting host_details no longer causes deadlocks.
+
+
+
+ CS-12407
+
+
+
+ F5 and Netscaler - when dedicated is selected, capacity field is disabled.
+
+
+
+ CS-12111
+
+
+
+ Email validation for edit user form.
+
+
+
+ CS-10928
+
+
+
+ Network read/write values now always positive numbers.
+
+
+
+ CS-15376, CS-15373
+
+
+
+ The AWS APIs (EC2 and S3) now listen on the 7080 port and send request to CloudStack on the 8080 port just as any other clients of CloudStack.
+
+
+
+ CS-13944
+
+
+
+ The CloudStack 2.2.x to 3.0.x database upgrade for multiple physical networks is now supported.
+
+
+
+ CS-15300
+
+
+
+ The admin accounts of a domain now honour the limits imposed on that domain just like the regular accounts do. A domain admin now is not allowed to create an unlimited number of instances, volumes, snapshots, and so on.
+
+
+
+ CS-15396
+
+
+
+ The CloudStack database now contain the UUD information after the 2.2.14 to 3.0.4 upgrade.
+
+
+
+ CS-15450
+
+
+
+ Upgrade from 2.2.14 to 3.0.4 no longer fails on a VMware host.
+
+
+
+ CS-15449
+
+
+
+ Running cloudstack-aws-api-register no longer fails with the "User registration failed with error: [Errno 113] No route to host" error.
+
+
+
+ CS-15455
+
+
+
+ The iptable rules are configured to open the awsapi port (7080) as part of the installation.
+
+
+
+ CS-15429
+
+
+
+ While creating an instance with data volume, disk offering also is considered while checking the account limit on volume resources.
+
+
+
+ CS-15414
+
+
+
+ After the 2.2.14 to 3.0.4 upgrade, the value of the global parameter xen.guest.network.device is now decrypted before setting the traffic label.
+
+
+
+ CS-15382
+
+
+
+ During 2.2.14 to 3.0.4 upgrade, the hosts no longer go to the Alert state if destroyed networks existed with non-existent tags prior to upgrade.
+
+
+
+ CS-15323
+
+
+
+ CloudStack supports the following Citrix XenServer hotfixes: XS602E003, XS602E004, and XS602E005.
+
+
+
+ CS-15430
+
+
+
+ Create snapshot now fails if creating a snapshot exceeds the snapshot resource limit for a domain admin or a user account.
+
+
+
+ CS-14256
+
+
+
+ Virtual Router no longer remains in starting state for subdomain or user on a KVM 3.0.1 prerlease host on RHEL 6.2.
+
+
+
+ CS-7495
+
+
+
+ Implemented a variety of Xen management host improvements.
+
+
+
+ CS-8105
+
+
+
+ NFS v4 for primary storage now works as expected on KVM hosts.
+
+
+
+ CS-9989
+
+
+
+ The error messages returned during VM deployment failure will have much more details than before.
+
+
+
+ CS-12584
+
+
+
+ You can no longer add security groups not supported by the hypervisor in use.
+
+
+
+ CS-12705
+
+
+
+ When creating a Network offering by using SRX as the service provider for SourceNAT servcies, an option is given in the CloudStack UI now to set the source_nat type to "per Zone"/"per account".
+
+
+
+ CS-12782
+
+
+
+ Assigning a VM from Basic to Advanced zone no longer ignores the network ID. A warning message is displayed for VM movements across zones.
+
+
+
+ CS-12591
+
+
+
+ Broadcast Address on the Second Public IP NIC is now corrected.
+
+
+
+ CS-13272
+
+
+
+ When a user is deleted, all the associated properties, such as IPs and virtual routers, are now deleted.
+
+
+
+ CS-13377
+
+
+
+ Creating template from a root disk of a stopped instance now provides an option to make it a "Featured template".
+
+
+
+ CS-13500
+
+
+
+ Reaching the first guest VM by using its public IP from the second guest VM no longer fails.
+
+
+
+ CS-13853
+
+
+
+ The default gateway can no longer be 0.0.0.0 in the Secondary Storage VM (SSVM).
+
+
+
+ CS-13863
+
+
+
+ The queryAsyncJobResult command in XML format now returns the correct UUIDs.
+
+
+
+ CS-13867
+
+
+
+ Corrected CSP xenserver-cloud-supp.tgz for XenServer 5.6 and 6.0.
+
+
+
+ CS-13904
+
+
+
+ Labels and values for the service offerings CPU and memory are now consistent.
+
+
+
+ CS-13998
+
+
+
+ The SSVM kernel panic issue is fixed on XenServer.
+
+
+
+ CS-14090
+
+
+
+ The issue is fixed where running the VMware snapshots randomly fails with the ArrayIndexOutOfBoundsException error.
+
+
+
+ CS-14021
+
+
+
+ The java.lang.OutOfMemoryError is fixed on the Management Server.
+
+
+
+ CS-14025
+
+
+
+ The Python Eggs are provided to easily package the test client for each branch of CloudStack.
+
+
+
+ CS-14068
+
+
+
+ Resetting the VM password through the CloudStack UI no longer causes any error.
+
+
+
+ CS-14156
+
+
+
+ The pod which has the administrator's virtual router is no longer selected while creating the virtual routers for guests.
+
+
+
+ CS-14182
+
+
+
+ The users can now delete their ISOs as normal users.
+
+
+
+ CS-14185
+
+
+
+ The listOSTypes API now filters out the types of operating system by using the keywords.
+
+
+
+ CS-14204
+
+
+
+ The cloud-setup-bonding.sh command no longer generates the "command not found" error.
+
+
+
+ CS-14214
+
+
+
+ The Specify VLAN option cannot be enabled now for an isolated Network offering with SourceNAT enabled.
+
+
+
+ CS-14234
+
+
+
+ Sending project invite email to an account now requires SMTP configured in CloudStack.
+
+
+
+ CS-14237
+
+
+
+ The garbage collector of the primary storage no longer fails when the first host in the cluster is not up.
+
+
+
+ CS-14241
+
+
+
+ Custom Volume Disk Offering is now matching the Global configuration value.
+
+
+
+ CS-14270
+
+
+
+ The listNetworks API no longer assumes that the broadcast type is always VLAN.
+
+
+
+ CS-14319
+
+
+
+ The internal name of the VM is no longer present in the error message that is displayed to a domain administrator.
+
+
+
+ CS-14321
+
+
+
+ The listVolumes API call now returns a valid value for the isExtractable parameter for the ISO-derived disk and data disk volumes.
+
+
+
+ CS-14323
+
+
+
+ Invalid API calls will now give valid response in json/xml format.
+
+
+
+ CS-14339
+
+
+
+ Custom Disk Size will now allow values larger than 100GB.
+
+
+
+ CS-14357
+
+
+
+ The ConsoleProxyLoadReportCommand is no longer fired continuously.
+
+
+
+ CS-14421
+
+
+
+ Fixed the issue of virtual router deployments. The DHCP entries can now be assigned to the router.
+
+
+
+ CS-14555
+
+
+
+ Unzipped downloaded template MD5SUM will no longer override the zipped template MD5SUM in the database.
+
+
+
+ CS-14598
+
+
+
+ The complete screen of the running VM is now displayed in the console proxy.
+
+
+
+ CS-14600
+
+
+
+ Windows or Linux based consoles are no longer lost upon rebooting VMs.
+
+
+
+ CS-14784
+
+
+
+ Multiple subnets with the same VLAN now work as expected.
+
+
+
+ CS-13303, 14874, 13897, 13944, 14088, 14190
+
+
+
+ A variety of upgrade issues have been fixed in release 3.0.3.
+
+
+
+ CS-15080
+
+
+
+ Setting a private network on a VLAN for VMWare environment is now supported.
+
+
+
+ CS-15168
+
+
+
+ The console proxy now works as expected and no exception is shown in the log after upgrading from version 2.2.14 to 3.0.2.
+
+
+
+ CS-15172
+
+
+
+ Version 3.0.2 now accepts the valid public key.
+
+ Known Issues in 4.0.0-incubating3.3. Known Issues in 4.0.0-incubating
+
+ Issue ID
+
+
+
+
+ Description
+
+
+
+
+ CLOUDSTACK-301
+
+
+
+ Nexus 1000v DVS integration is not functional
+
+
+ This source code release includes some partial functionality to support the Cisco Nexus 1000v Distributed Virtual Switch within a VMware hypervisor environment. The functionality is not complete at this time.
+
+
+
+
+ CLOUDSTACK-368
+
+
+
+ OVM - cannot create guest VM
+
+
+ This source code release has regressed from the CloudStack 2.2.x code and is unable to support Oracle VM (OVM).
+
+
+
+
+ CLOUDSTACK-279
+
+
+
+ Deleting a project fails when executed by the regular user. This works as expected for root/domain admin. To workaround, perform either of the following:
+
+ •
+ Use the account cleanup thread which will eventually complete the project deletion.
+ •
+ Execute the call as the root/domain admin on behalf of the regular user.
+
+
+
+
+ CS-16067
+
+
+
+ The command=listTags&key=city command does not work as expected. The command does not return tags for the resources of the account with the tag, city
+
+
+
+
+ CS-16063
+
+
+
+ The current values of volumes and snapshots are incorrect when using KVM as a host. To fix this, the database upgrade codes, volumes.size and snapshots.size, should be changed to show the virtual sizes.
+
+
+
+
+ CS-16058
+
+
+
+ Null pointer Exception while deleting the host after moving the host to maintenance state.
+
+
+
+
+ CS-16045
+
+
+
+ Only the root administrator can handle the API keys. The domain administrators are not allowed to create, delete, or retrieve API keys for the users in their domain.
+
+
+
+
+ CS-16019
+
+
+
+ CIDR list in the Add VPN Customer Gateway dialog does not prompt the user that they can provide a comma separated CIDRs if multiple CIDRs have to be supplied.
+
+
+
+
+ CS-16015
+
+
+
+ Deleting a network is not supported when its network providers are disabled.
+
+
+
+
+ CS-16012
+
+
+
+ Unable to delete a zone in the UI because the necessary cleanup cannot be completed. When the hosts are removed, the expunge process fails to delete the volumes as no hosts are present to send the commands to. Therefore, the storage pool removal fails, and zone can't be cleaned and deleted.
+
+
+
+
+ CS-16011
+
+
+
+ Name of network offering might be truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+ CS-15789
+
+
+
+ Invalid global setting prevents management server to restart. For example, if you configure the "project.invite.timeout" parameter to "300" and attempt to restart management server, it fails without throwing a warning or setting the value to the default.
+
+
+
+
+ CS-15749
+
+
+
+ Restarting VPC is resulting in intermittent connection loss to the port forwarding and StaticNAT rules.
+
+
+
+
+ CS-15690
+
+
+
+ The IpAssoc command failed as a part of starting the virtual router, but the final start result is reported as succes.
+
+
+
+
+ CS-15672, CS-15635
+
+
+
+ The FQDN of the VM is not configured if it is deployed as a part of default shared network and isolated guest network (DefaultIsolatedNetworkOfferingWithSourceNatService).
+
+
+
+
+ CS-15634
+
+
+
+ The FQDN of a VM that is deployed as a part of both a shared network and default isolated guest network has the suffix of the shared network instead of the default isolated guest network.
+
+
+
+
+ CS-15576
+
+
+
+ Stopping a VM on XenServer creates a backlog of API commands. For example, the Attach volume calls become delayed while waiting for the stopVirtualMachine command to be executed.
+
+
+
+
+ CS-15569
+
+
+
+ Misleading error message in the exception when creating a StaticNAT rule fails in a VPC.
+
+
+
+
+ CS-15566
+
+
+
+ External device such as Netscaler is not supported in VPC.
+
+
+
+ CS-15557
+
+
+
+ Intermittent traffic loss in the VPN connection if Juniper is the remote router and the life time is 300 seconds.
+
+
+
+
+ CS-15361
+
+
+
+ Egress rules are not working in NetScaler loadbalancer.
+
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+ CS-15105
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+ CS-15092
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+ CS-15037
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+ CS-15009
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+ CS-14939
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+ CS-14780
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+ CS-14756
+
+
+
+ Installing KVM on RHEL 6.2 will result in unreliable network performance. Workaround: blacklist vhost-net. Edit /etc/modprobe.d/blacklist-kvm.conf and include vhost-net.
+
+
+
+ CS-14346
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+ CS-14303 (was 14537)
+
+
+
+ The IP addresses for a shared network are still being consumed even if no services are defined for that network.
+
+
+
+ CS-14296 (was 14530)
+
+
+
+ OVM: Network traffic labels are not supported.
+
+
+
+ CS-14291 (was 14523)
+
+
+
+ The EIP/ELB network offering for basic zones does not support multiple NetScalers.
+
+
+
+ CS-14275 (was 14506)
+
+
+
+ F5: Unable to properly remove a F5 device.
+
+
+
+ CS-14201 (was 14430)
+
+
+
+ VMWare: Template sizes are being reported different depending on whether the primary storage is using ISCSI or NFS.
+
+
+
+ CS-13758 (was 13963)
+
+
+
+ vSphere: template download from templates created off of the root volume does not work properly.
+
+
+
+ CS-13733 (was 13935)
+
+
+
+ vSphere: detaching an ISO from a restored VM instance fails.
+
+
+
+ CS-13682 (was 13883)
+
+
+
+ Multiple NetScalers are not supported in Basic Networking.
+
+
+
+ CS-13599 (was 13359)
+
+
+
+ Programming F5/NetScaler rules can be better optimized.
+
+
+
+ CS-13337 (was 13518)
+
+
+
+ Security Groups are not supported in Advanced Networking
+
+
+
+ CS-13173 (was 13336)
+
+
+
+ vSphere: cross cluster volume migration does not work properly.
+
+
+
+ CS-12714 (was 12840)
+
+
+
+ Capacity view is not available for pods or clusters.
+
+
+
+ CS-12624 (was 12741)
+
+
+
+ vSphere: maintenance mode will not live migrate system VM to another host.
+
+
+
+ CS-15476
+
+
+
+
+ The 2.2.14 to 4.0.0-incubating upgrade fails if multiple untagged physical networks exist before the upgrade.
+
+
+
+
+ CS-15407
+
+
+
+
+ After the 2.2.14 to 4.0.0-incubating upgrade, VLAN allocation on multiple physical networks does not happen as expected.
+
+
+ To workaround this issue, follow the instructions given below:
+
+ 1.
+ Revert to your 2.2.14 setup.
+ 2.
+ Stop all the VMs with the isolated virtual networks in your cloud setup.
+ 3.
+ Run following query to find if any networks still have the NICs allocated:
+ a.
+ Check if any virtual guest networks have the NICs allocated:
+ #SELECT DISTINCT op.id from `cloud`.`op_networks` op JOIN `cloud`.`networks` n on op.id=n.id WHERE nics_count != 0 AND guest_type = 'Virtual';b.
+ If this returns any network IDs, then ensure the following:
+ i.
+ All the VMs are stopped.
+ ii.
+ No new VM is started.
+ iii.
+ Shutdown the Management Server.
+ c.
+ Remove the NICs count for the virtual network IDs returned in step (a), and set the NIC count to 0:
+ UPDATE `cloud`.`op_networks` SET nics_count = 0 WHERE id = enter id of virtual networkd.
+ Restart the Management Server, and wait for all the networks to shut down.
+ Note
+ Networks shutdown is determined by the network.gc.interval and network.gc.wait parameters.
+ 4.
+ Ensure that all the networks are shut down and all the guest VNETs are free.
+ 5.
+ Run the upgrade script.
+
+ This allocates all your guest VNET ranges to the first physical network.
+ 6.
+ By using the updatePhysicalNetwork API, reconfigure the VNET ranges for each physical network as desired.
+ 7.
+ Start all the VMs.
+
+
+
+
+ CS-14680
+
+
+
+
+ CloudStack and LDAP user validation cannot happen simultaneously because the user password is hashed and stored in the database, and LDAP requires the passwords in plain text.
+
+
+ To work with the LDAP user, the MD5 hash should be disabled in the login process by commenting the following variable in sharedFunctions.js file available at /usr/share/cloud/management/webapps/client/scripts, and restart the cloud-management service.
+
+
+var md5HashedLogin = false;
+
+ However, if md5HashedLogin is set to false, the end user can login with the LDAP credentials but not with the CloudStack user credentials.
+
+
+
+
+ CS-14346
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+ CS-15130
+
+
+
+ Data disk volumes are not automatically copied from one cluster to another.
+
+
+
+ CS-14780
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+ CS-14939
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+ CS-15009
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+ CS-15037
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+ CS-15092
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+ CS-15105
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+ CS-15163
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+ Chapter 4.Chapter 4. API Changes from 3.0.2 to 4.0.0-incubatingAPI Changes from 3.0.2 to 4.0.0-incubatingNew API Commands in 4.0.0-incubating4.1. New API Commands in 4.0.0-incubating•
+ createCounter (Adds metric counter)
+ •
+ deleteCounter (Deletes a counter)
+ •
+ listCounters (List the counters)
+ •
+ createCondition (Creates a condition)
+ •
+ deleteCondition (Removes a condition)
+ •
+ listConditions (List Conditions for the specific user)
+ •
+ createTags. Add tags to one or more resources. Example:
+command=createTags
+&resourceIds=1,10,12
+&resourceType=userVm
+&tags[0].key=region
+&tags[0].value=canada
+&tags[1].key=city
+&tags[1].value=Toronto
+ •
+ deleteTags. Remove tags from one or more resources. Example:
+command=deleteTags
+&resourceIds=1,12
+&resourceType=Snapshot
+&tags[0].key=city
+ •
+ listTags (Show currently defined resource tags)
+ •
+ createVPC (Creates a VPC)
+ •
+ listVPCs (Lists VPCs)
+ •
+ deleteVPC (Deletes a VPC)
+ •
+ updateVPC (Updates a VPC)
+ •
+ restartVPC (Restarts a VPC)
+ •
+ createVPCOffering (Creates VPC offering)
+ •
+ updateVPCOffering (Updates VPC offering)
+ •
+ deleteVPCOffering (Deletes VPC offering)
+ •
+ listVPCOfferings (Lists VPC offerings)
+ •
+ createPrivateGateway (Creates a private gateway)
+ •
+ listPrivateGateways (List private gateways)
+ •
+ deletePrivateGateway (Deletes a Private gateway)
+ •
+ createNetworkACL (Creates a ACL rule the given network (the network has to belong to VPC))
+ •
+ deleteNetworkACL (Deletes a Network ACL)
+ •
+ listNetworkACLs (Lists all network ACLs)
+ •
+ createStaticRoute (Creates a static route)
+ •
+ deleteStaticRoute (Deletes a static route)
+ •
+ listStaticRoutes (Lists all static routes)
+ •
+ createVpnCustomerGateway (Creates site to site vpn customer gateway)
+ •
+ createVpnGateway (Creates site to site vpn local gateway)
+ •
+ createVpnConnection (Create site to site vpn connection)
+ •
+ deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
+ •
+ deleteVpnGateway (Delete site to site vpn gateway)
+ •
+ deleteVpnConnection (Delete site to site vpn connection)
+ •
+ updateVpnCustomerGateway (Update site to site vpn customer gateway)
+ •
+ resetVpnConnection (Reset site to site vpn connection)
+ •
+ listVpnCustomerGateways (Lists site to site vpn customer gateways)
+ •
+ listVpnGateways (Lists site 2 site vpn gateways)
+ •
+ listVpnConnections (Lists site to site vpn connection gateways)
+ •
+ markDefaultZoneForAccount (Marks a default zone for the current account)
+ •
+ uploadVolume (Uploads a data disk)
+ Changed API Commands in 4.0.0-incubating4.2. Changed API Commands in 4.0.0-incubating
+
+ API Commands
+
+
+
+ Description
+
+
+
+ copyTemplate
+
+
+ prepareTemplate
+
+
+ registerTemplate
+
+
+ updateTemplate
+
+
+ createProject
+
+
+ activateProject
+
+
+ suspendProject
+
+
+ updateProject
+
+
+ listProjectAccounts
+
+
+ createVolume
+
+
+ migrateVolume
+
+
+ attachVolume
+
+
+ detachVolume
+
+
+ uploadVolume
+
+
+ createSecurityGroup
+
+
+ registerIso
+
+
+ copyIso
+
+
+ updateIso
+
+
+ createIpForwardingRule
+
+
+ listIpForwardingRules
+
+
+ createLoadBalancerRule
+
+
+ updateLoadBalancerRule
+
+
+ createSnapshot
+
+
+
+
+ The commands in this list have a single new response parameter, and no other changes.
+
+
+ New response parameter: tags(*)
+
+ Note
+ Many other commands also have the new tags(*) parameter in addition to other changes; those commands are listed separately.
+
+
+
+ rebootVirtualMachine
+
+
+ attachIso
+
+
+ detachIso
+
+
+ listLoadBalancerRuleInstances
+
+
+ resetPasswordForVirtualMachine
+
+
+ changeServiceForVirtualMachine
+
+
+ recoverVirtualMachine
+
+
+ startVirtualMachine
+
+
+ migrateVirtualMachine
+
+
+ deployVirtualMachine
+
+
+ assignVirtualMachine
+
+
+ updateVirtualMachine
+
+
+ restoreVirtualMachine
+
+
+ stopVirtualMachine
+
+
+ destroyVirtualMachine
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+ listSecurityGroups
+
+
+ listFirewallRules
+
+
+ listPortForwardingRules
+
+
+ listSnapshots
+
+
+ listIsos
+
+
+ listProjects
+
+
+ listTemplates
+
+
+ listLoadBalancerRules
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: tags (optional)
+
+
+ New response parameter: tags(*)
+
+
+
+
+ listF5LoadBalancerNetworks
+
+
+ listNetscalerLoadBalancerNetworks
+
+
+ listSrxFirewallNetworks
+
+
+ updateNetwork
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ createZone
+
+
+ updateZone
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: localstorageenabled (optional)
+
+
+ New response parameter: localstorageenabled
+
+
+
+
+ listZones
+
+
+
+ New response parameter: localstorageenabled
+
+
+
+ rebootRouter
+
+
+ changeServiceForRouter
+
+
+ startRouter
+
+
+ destroyRouter
+
+
+ stopRouter
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+ updateAccount
+
+
+ disableAccount
+
+
+ listAccounts
+
+
+ markDefaultZoneForAccount
+
+
+ enableAccount
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: vpcavailable, vpclimit, vpctotal
+
+
+
+ listRouters
+
+
+
+ New request parameters: forvpc (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+
+ listNetworkOfferings
+
+
+
+ New request parameters: forvpc (optional)
+
+
+ New response parameters: forvpc
+
+
+
+
+ listVolumes
+
+
+
+ New request parameters: details (optional), tags (optional)
+
+
+ New response parameters: tags(*)
+
+
+
+
+ addTrafficMonitor
+
+
+
+ New request parameters: excludezones (optional), includezones (optional)
+
+
+
+
+ createNetwork
+
+
+
+ New request parameters: vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ listPublicIpAddresses
+
+
+
+ New request parameters: tags (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+ listNetworks
+
+
+
+ New request parameters: canusefordeploy (optional), forvpc (optional), tags (optional), vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ restartNetwork
+
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+ enableStaticNat
+
+
+
+ New request parameter: networkid (optional)
+
+
+
+
+ createDiskOffering
+
+
+
+ New request parameter: storagetype (optional)
+
+
+ New response parameter: storagetype
+
+
+
+
+ listDiskOfferings
+
+
+
+ New response parameter: storagetype
+
+
+
+
+ updateDiskOffering
+
+
+
+ New response parameter: storagetype
+
+
+
+
+ createFirewallRule
+
+
+
+ Changed request parameters: ipaddressid (old version - optional, new version - required)
+
+
+ New response parameter: tags(*)
+
+
+
+
+ listVirtualMachines
+
+
+
+ New request parameters: isoid (optional), tags (optional), templateid (optional)
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+ updateStorageNetworkIpRange
+
+
+
+ New response parameters: id, endip, gateway, netmask, networkid, podid, startip, vlan, zoneid
+
+
+
+
+ reconnectHost
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+ addCluster
+
+
+
+ The following request parameters are added:
+
+ •
+ vsmipaddress (optional)
+ •
+ vsmpassword (optional)
+ •
+ vsmusername (optional)
+
+
+ The following parameter is made mandatory: podid
+
+
+
+
+ listVolumes
+
+
+
+ A new response parameter is added: status
+
+
+
+ migrateVolume
+
+
+
+ A new response parameter is added: status
+
+
+
+ prepareHostForMaintenance
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+ addSecondaryStorage
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+ enableAccount
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+ attachVolume
+
+
+
+ A new response parameter is added: status
+
+
+
+ cancelHostMaintenance
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ addSwift
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ listSwifts
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ listExternalLoadBalancers
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ createVolume
+
+
+
+ A new response parameter is added: status
+
+
+
+ listCapabilities
+
+
+
+ A new response parameter is added: customdiskofferingmaxsize
+
+
+
+ disableAccount
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+ deployVirtualMachine
+
+
+
+ A new request parameter is added: startvm (optional)
+
+
+
+ deleteStoragePool
+
+
+
+ A new request parameter is added: forced (optional)
+
+
+
+ updateAccount
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+ addHost
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ updateHost
+
+
+
+ A new response parameter is added: hahost
+
+
+
+ detachVolume
+
+
+
+ A new response parameter is added: status
+
+
+
+ listAccounts
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+ listHosts
+
+
+
+ A new response parameter is added: hahost
+
+
+ A new request parameter is added: hahost (optional)
+
+
diff --git a/docs/tmp/en-US/xml/release-notes.xml b/docs/tmp/en-US/xml/release-notes.xml
new file mode 100644
index 00000000000..b23d188a02d
--- /dev/null
+++ b/docs/tmp/en-US/xml/release-notes.xml
@@ -0,0 +1,5946 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Submitting Feedback and Getting Help
+
+ The Apache CloudStack project has mailing lists for users and developers. These are the official channels of communication for the project and are the best way to get answers about using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users mailing list if you've deployed or are deploying CloudStack into production, and even for test deployments.
+
+
+ The CloudStack developer's mailing list (cloudstack-dev) is for discussions about CloudStack development, and is the best list for discussing possible bugs in CloudStack. Anyone contributing to CloudStack should be on this mailing list.
+
+
+ You can also report bugs in CloudStack using the Apache Defect Tracking System
+
+
+ To posts to the lists, you'll need to be subscribed. See the CloudStack Web site for instructions.
+
+
+
+
+ Upgrade Instructions
+
+ Upgrade from 3.0.2 to 4.0.0-incubating
+
+ Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note that some of the steps here are only required if you're using a specific hypervisor. The steps that are hypervisor-specific are called out with a note.
+
+
+
+
+ Ensure that you query your IP address usage records and process them or make a backup. During the upgrade you will lose the old IP address usage records.
+
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading, any existing IP address usage records in the old format will no longer be available.
+
+
+
+
+
+
+ The following upgrade instructions apply only if you're using VMware hosts. If you're not using VMware hosts, skip this step and move on to step 3: stopping all usage servers.
+
+
+
+
+ In each zone that includes VMware hosts, you need to add a new system VM template.
+
+
+
+
+ While running the existing 3.0.2 system, log in to the UI as root administrator.
+
+
+
+
+
+ In the left navigation bar, click Templates.
+
+
+
+
+
+ In Select view, click Templates.
+
+
+
+
+
+ Click Register template.
+
+
+ The Register template dialog box is displayed.
+
+
+
+
+
+ In the Register template dialog box, specify the following values (do not change these):
+
+
+
+
+
+
+
+
+
+ Field
+
+
+
+
+ Value
+
+
+
+
+
+
+
+
+
+
+ Name
+
+
+
+
+ systemvm-vmware-3.0.5
+
+
+
+
+
+
+
+ Description
+
+
+
+
+ systemvm-vmware-3.0.5
+
+
+
+
+
+
+
+ URL
+
+
+
+
+ http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+
+
+
+
+
+ Zone
+
+
+
+
+ Choose the zone where this hypervisor is used
+
+
+
+
+
+
+
+ Hypervisor
+
+
+
+
+ VMware
+
+
+
+
+
+
+
+ Format
+
+
+
+
+ OVA
+
+
+
+
+
+
+
+ OS Type
+
+
+
+
+ Debian GNU/Linux 5.0 (32-bit)
+
+
+
+
+
+
+
+ Extractable
+
+
+
+
+ no
+
+
+
+
+
+
+
+ Password Enabled
+
+
+
+
+ no
+
+
+
+
+
+
+
+ Public
+
+
+
+
+ no
+
+
+
+
+
+
+
+ Featured
+
+
+
+
+ no
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful.
+
+
+
+
+
+
+
+
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+
+
+# service cloud-usage stop
+
+
+
+
+ Stop the Management Servers. Run this on all Management Server hosts.
+
+
+# service cloud-management stop
+
+
+
+
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+
+ 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.
+
+
+#mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp
+
+
+
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the &PRODUCT; binaries.
+
+
+
+
+
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade &PRODUCT;:
+#yum update cloud-*
+
+#apt-get update
+#apt-get upgrade cloud-*
+
+
+
+
+ If the upgrade output includes a message similar to the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+
+
+warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+
+ Instructions follow in the next step.
+
+
+
+
+
+
+
+ If you have made changes to your copy of /etc/cloud/management/components.xml the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+
+
+
+ Make a backup copy of /etc/cloud/management/components.xml. For example:
+
+
+# mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backup
+
+
+
+
+ Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:
+
+
+# cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xml
+
+
+
+
+ Merge your changes from the backup file into the new components.xml.
+
+
+# vi /etc/cloud/management/components.xml
+
+
+
+
+
+
+ If you have more than one management server node, repeat the upgrade steps on each node.
+
+
+
+
+
+
+
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+
+
+# service cloud-management start
+
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. After confirmation, start the other Management Servers one at a time by running the same command on each node.
+
+
+
+ Failing to restart the Management Server indicates a problem in the upgrade. Having the Management Server restarted without any issues indicates that the upgrade is successfully completed.
+
+
+
+
+
+
+
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
+
+ # service cloud-usage start
+
+
+
+
+
+
+ Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+
+
+
+
+
+
+ Configure a yum or apt respository containing the &PRODUCT; packages as outlined in the Installation Guide.
+
+
+
+
+
+ Stop the running agent.
+
+
+ # service cloud-agent stop
+
+
+
+
+
+ Update the agent software with one of the following command sets as appropriate for your environment.
+
+
+ # yum update cloud-*
+
+
+ # apt-get update
+
+
+ # apt-get upgrade cloud-*
+
+
+
+
+
+ Start the agent.
+
+
+# service cloud-agent start
+
+
+
+
+ Edit /etc/cloud/agent/agent.properties to change the resource parameter from "com.cloud.agent.resource.computing.LibvirtComputingResource" to "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
+
+
+
+
+
+ Start the cloud agent and cloud management services.
+
+
+
+
+
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+
+
+
+
+
+
+
+
+
+ Log in to the CloudStack UI as administrator, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
+
+
+ Troubleshooting: If login fails, clear your browser cache and reload the page.
+
+
+
+
+
+
+ Do not proceed to the next step until the hosts show in Up state.
+
+
+
+
+
+ If you are upgrading from 3.0.2, perform the following:
+
+
+
+
+ Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter.
+
+
+ This port is used by the cloud-sysvmadm script at the end of the upgrade procedure. For information about how to set this parameter, see "Setting Global Configuration Parameters" in the Installation Guide.
+
+
+
+
+
+ Restart the Management Server.
+
+
+
+ If you don't want the admin port to remain open, you can set it to null after the upgrade is done and restart the management server.
+
+
+
+
+
+
+
+
+
+
+
+ Run the cloud-sysvmadm script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the -c and -r arguments. For example:
+
+
+ # nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+
+
+ # tail -f sysvm.log
+
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+
+
+
+
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+
+
+
+
+
+ Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+
+
+
+
+ Disconnect the XenServer cluster from CloudStack.
+
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+
+
+
+
+
+ To clean up the VLAN, log in to one XenServer host and run:
+
+
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+
+
+
+ Now prepare the upgrade by running the following on one XenServer host:
+
+
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+
+
+ If you see a message like "can't eject CD", log in to the VM and unmount the CD, then run this script again.
+
+
+
+
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /tmp.
+
+
+ On the Xen pool master, upload the hotfix with this command:
+
+
+ xe patch-upload file-name=XS602E003.xsupdate
+
+
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+
+
+
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+
+
+
+
+
+
+
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
+
+ # xe vm-list
+
+
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+
+ # xe vm-migrate live=true host=host-name vm=VM-name
+
+
+ Troubleshooting
+
+ If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
+
+
+ /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.
+
+
+
+
+
+
+
+ Apply the hotfix. First, get the UUID of this host:
+
+
+# xe host-list
+
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+
+xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid
+
+
+
+
+ Copy the following files from the CloudStack Management Server to the host.
+
+
+
+
+
+
+
+
+
+ Copy from here...
+
+
+
+
+ ...to here
+
+
+
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
+
+
+
+
+ Download the CSP software onto the XenServer host from one of the following links:
+
+
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+
+
+
+ Extract the file:
+
+
+# tar xf xenserver-cloud-supp.tgz
+
+
+
+
+ Run the following script:
+
+
+# xe-install-supplemental-pack xenserver-cloud-supp.iso
+
+
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
+
+# xe-switch-network-backend bridge
+
+
+
+
+
+
+
+
+ Reboot this XenServer host.
+
+
+
+
+
+ Run the following:
+
+
+/opt/xensource/bin/setupxenserver.sh
+
+
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+
+
+
+
+
+
+
+ Run the following:
+
+
+for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+
+
+
+
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+
+
+
+
+
+
+
+
+
+
+ Troubleshooting Tip
+
+ If passwords which you know to be valid appear not to work after upgrade, or other UI issues are seen, try clearing your browser cache and reloading the UI page.
+
+
+
+
+
+
+
+ Upgrade from 2.2.14 to 4.0.0-incubating
+
+
+
+ Ensure that you query your IPaddress usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.
+
+
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading to 4.0.0-incubating, any existing IP address usage records in the old format will no longer be available.
+
+
+
+
+
+ If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the instructions in the 2.2.14 Release Notes.
+
+
+ KVM Hosts
+
+ If KVM hypervisor is used in your cloud, be sure you completed the step to insert a valid username and password into the host_details table on each KVM node as described in the 2.2.14 Release Notes. This step is critical, as the database will be encrypted after the upgrade to 4.0.0-incubating.
+
+
+
+
+
+
+
+ While running the 2.2.14 system, log in to the UI as root administrator.
+
+
+
+
+
+ Using the UI, add a new System VM template for each hypervisor type that is used in your cloud. In each zone, add a system VM template for each hypervisor used in that zone
+
+
+
+
+ In the left navigation bar, click Templates.
+
+
+
+
+
+ In Select view, click Templates.
+
+
+
+
+
+ Click Register template.
+
+
+ The Register template dialog box is displayed.
+
+
+
+
+
+ In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):
+
+
+
+
+
+
+
+
+
+ Hypervisor
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+ XenServer
+
+
+
+
+ Name: systemvm-xenserver-3.0.0
+
+
+ Description: systemvm-xenserver-3.0.0
+
+
+ URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: XenServer
+
+
+ Format: VHD
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+
+
+
+
+ KVM
+
+
+
+
+ Name: systemvm-kvm-3.0.0
+
+
+ Description: systemvm-kvm-3.0.0
+
+
+ URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: KVM
+
+
+ Format: QCOW2
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+
+
+
+
+ VMware
+
+
+
+
+ Name: systemvm-vmware-3.0.5
+
+
+ Description: systemvm-vmware-3.0.5
+
+
+ URL: http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+ Zone: Choose the zone where this hypervisor is used
+
+
+ Hypervisor: VMware
+
+
+ Format: OVA
+
+
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable: no
+
+
+ Password Enabled: no
+
+
+ Public: no
+
+
+ Featured: no
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful
+
+
+
+
+
+ WARNING: If you use more than one type of hypervisor in your cloud, be sure you have repeated these steps to download the system VM template for each hypervisor type. Otherwise, the upgrade will fail.
+
+
+
+
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+
+
+# service cloud-usage stop
+
+
+
+
+ Stop the Management Servers. Run this on all Management Server hosts.
+
+
+# service cloud-management stop
+
+
+
+
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
+
+
+ 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.
+
+
+#mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp
+
+
+
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the &PRODUCT; binaries.
+
+
+
+
+
+ After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade &PRODUCT;:
+#yum update cloud-*
+
+#apt-get update
+#apt-get upgrade cloud-*
+
+
+
+
+
+
+ If you have made changes to your existing copy of the file components.xml in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+
+
+ How will you know whether you need to do this? If the upgrade output in the previous step included a message like the following, then some custom content was found in your old components.xml, and you need to merge the two files:
+
+
+
+
+warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+
+
+
+ Make a backup copy of your /etc/cloud/management/components.xml file. For example:
+
+
+#mv/etc/cloud/management/components.xml/etc/cloud/management/components.xml-backup
+
+
+
+
+ Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:
+
+
+#cp -ap /etc/cloud/management/components.xml.rpmnew/etc/cloud/management/components.xml
+
+
+
+
+ Merge your changes from the backup file into the new components.xml file.
+
+
+#vi/etc/cloud/management/components.xml
+
+
+
+
+
+
+
+
+
+ If you have made changes to your existing copy of the /etc/cloud/management/db.properties file in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
+
+
+
+
+ Make a backup copy of your file /etc/cloud/management/db.properties. For example:
+
+
+#mv/etc/cloud/management/db.properties/etc/cloud/management/db.properties-backup
+
+
+
+
+ Copy /etc/cloud/management/db.properties.rpmnew to create a new /etc/cloud/management/db.properties:
+
+
+#cp -ap /etc/cloud/management/db.properties.rpmnewetc/cloud/management/db.properties
+
+
+
+
+ Merge your changes from the backup file into the new db.properties file.
+
+
+#vi/etc/cloud/management/db.properties
+
+
+
+
+
+
+
+
+ On the management server node, run the following command. It is recommended that you use the command-line flags to provide your own encryption keys. See Password and Key Encryption in the Installation Guide.
+
+
+#cloud-setup-encryption -e encryption_type -m management_server_key -k database_key
+
+ When used without arguments, as in the following example, the default encryption type and keys will be used:
+
+
+
+
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file.
+
+
+
+
+
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the properties file. Default: password. It is highly recommended that you replace this with a more secure value
+
+
+
+
+
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value.
+
+
+
+
+
+
+
+
+
+ Repeat steps 10 - 14 on every management server node. If you provided your own encryption key in step 14, use the same key on all other management servers.
+
+
+
+
+
+ Start the first Management Server. Do not start any other Management Server nodes yet.
+
+
+# service cloud-management start
+
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete. You should see a message like "Complete! Done." After confirmation, start the other Management Servers one at a time by running the same command on each node.
+
+
+
+
+
+ Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
+
+
+# service cloud-usage start
+
+
+
+
+ (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
+
+
+
+
+ Configure your CloudStack package repositories as outlined in the Installation Guide
+
+
+
+
+
+ Stop the running agent.
+
+
+# service cloud-agent stop
+
+
+
+
+ Update the agent software with one of the following command sets as appropriate.
+
+
+#yum update cloud-*
+
+
+ #apt-get update
+#apt-get upgrade cloud-*
+
+
+
+
+
+ Start the agent.
+
+
+# service cloud-agent start
+
+
+
+
+ Copy the contents of the agent.properties file to the new agent.properties file by using the following command
+
+
+sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.properties
+
+
+
+
+ Start the cloud agent and cloud management services.
+
+
+
+
+
+ When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
+
+
+
+
+
+
+
+
+
+ Log in to the CloudStack UI as admin, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
+
+
+ Do not proceed to the next step until the hosts show in the Up state. If the hosts do not come to the Up state, contact support.
+
+
+
+
+
+ Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers.
+
+
+
+
+ Run the command once on one management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the "-c" and "-r" arguments. For example:
+
+
+#nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+#tail -f sysvm.log
+
+ This might take up to an hour or more to run, depending on the number of accounts in the system.
+
+
+
+
+
+ After the script terminates, check the log to verify correct execution:
+
+
+#tail -f sysvm.log
+
+ The content should be like the following:
+
+
+
+Stopping and starting 1 secondary storage vm(s)...
+Done stopping and starting secondary storage vm(s)
+Stopping and starting 1 console proxy vm(s)...
+Done stopping and starting console proxy vm(s).
+Stopping and starting 4 running routing vm(s)...
+Done restarting router(s).
+
+
+
+
+
+
+
+
+
+ If you would like additional confirmation that the new system VM templates were correctly applied when these system VMs were rebooted, SSH into the System VM and check the version.
+
+
+ Use one of the following techniques, depending on the hypervisor.
+
+
+ XenServer or KVM:
+
+ SSH in by using the link local IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own link local IP.
+
+
+
+
+ Run the following commands on the XenServer or KVM host on which the system VM is present:
+
+
+#ssh -i private-key-pathlink-local-ip -p 3922
+# cat /etc/cloudstack-release
+
+ The output should be like the following:
+
+
+Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+
+ ESXi
+
+ SSH in using the private IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own private IP.
+
+
+
+
+ Run the following commands on the Management Server:
+
+
+#ssh -i private-key-pathprivate-ip -p 3922
+#cat/etc/cloudstack-release
+
+ The output should be like the following:
+
+
+Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+
+
+
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
+
+
+
+
+
+ Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
+
+
+
+
+ Disconnect the XenServer cluster from CloudStack.
+
+
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
+
+
+ This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
+
+
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
+
+
+
+
+
+ To clean up the VLAN, log in to one XenServer host and run:
+
+
+/opt/xensource/bin/cloud-clean-vlan.sh
+
+
+
+
+ Prepare the upgrade by running the following on one XenServer host:
+
+
+/opt/xensource/bin/cloud-prepare-upgrade.sh
+
+ If you see a message like "can't eject CD", log in to the VM and umount the CD, then run this script again.
+
+
+
+
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /root or /tmp.
+
+
+ On the Xen pool master, upload the hotfix with this command:
+
+
+xe patch-upload file-name=XS602E003.xsupdate
+
+ Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
+
+
+
+ (Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
+
+
+
+
+
+
+
+ Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
+
+
+# xe vm-list
+
+ Then use this command to migrate each VM. Replace the example host name and VM name with your own:
+
+
+#xe vm-migrate live=true host=host-name vm=VM-name
+
+ Troubleshooting
+
+ If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
+
+
+ /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.
+
+
+
+
+
+
+
+ Apply the hotfix. First, get the UUID of this host:
+
+
+ # xe host-list
+
+
+ Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
+
+
+ xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid
+
+
+
+
+
+ Copy the following files from the CloudStack Management Server to the host.
+
+
+
+
+
+
+
+
+
+ Copy from here...
+
+
+
+
+ ...to here
+
+
+
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+
+
+
+
+ /opt/xensource/sm/NFSSR.py
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+
+
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+
+
+
+
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
+
+
+
+
+ Download the CSP software onto the XenServer host from one of the following links:
+
+
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+
+
+
+ Extract the file:
+
+
+ # tar xf xenserver-cloud-supp.tgz
+
+
+
+
+
+ Run the following script:
+
+
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso
+
+
+
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
+
+
+ # xe-switch-network-backend bridge
+
+
+
+
+
+
+
+
+
+ Reboot this XenServer host.
+
+
+
+
+
+ Run the following:
+
+
+ /opt/xensource/bin/setupxenserver.sh
+
+
+
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
+
+
+
+
+
+
+
+ Run the following:
+
+
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+
+
+
+
+
+ On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Version 4.0.0-incubating
+
+ What’s New in 4.0.0-incubating
+
+ Apache CloudStack 4.0.0-incubating includes the following new features:
+
+
+ Inter-VLAN Routing
+
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You can provision VLANs to the tiers your create, and VMs can be deployed on different tiers, such as Web, Application, or Database. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device.
+
+
+ This feature is supported on XenServer and VMware hypervisors.
+
+
+
+
+
+ Site-to-Site VPN
+
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+
+ The supported endpoints on the remote datacenters are:
+
+
+
+
+ Cisco ISR with IOS 12.4 or later
+
+
+
+
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
+
+
+
+
+
+
+
+
+ Local Storage Support for Data Volumes
+
+ You can now create data volumes on local storage. The data volume is placed on the same XenServer host as the VM instance that is attached to the data volume. These local data volumes can be attached to virtual machines, detached, re-attached, and deleted just as with the other types of data volume. In earlier releases of CloudStack, only the root disk could be placed in local storage.
+
+
+ Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some of the benefits include reduced disk I/O latency and cost reduction from using inexpensive local disks.
+
+
+ In order for local volumes to be used, the feature must be enabled for the zone.
+
+
+ You can create a data disk offering for local storage. When a user creates a new VM, they can select this disk offering in order to cause the data disk volume to be placed in local storage.
+
+
+ You can not migrate a VM that has a volume in local storage to a different host, nor migrate the volume itself away to a different host. If you want to put a host into maintenance mode, you must first stop any VMs with local data volumes on that host.
+
+
+ Local storage support for volumes is available for XenServer, KVM, and VMware hypervisors.
+
+
+
+
+
+ Tags
+
+ 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 new 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.
+
+
+ A new optional input parameter, "tags," has been added to 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:
+
+
+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 new "tags" input parameter:
+
+
+
+
+ listVirtualMachines
+
+
+
+
+
+ listVolumes
+
+
+
+
+
+ listSnapshots
+
+
+
+
+
+ listNetworks
+
+
+
+
+
+ listTemplates
+
+
+
+
+
+ listIsos
+
+
+
+
+
+ listFirewallRules
+
+
+
+
+
+ listPortForwardingRules
+
+
+
+
+
+ listPublicIpAddresses
+
+
+
+
+
+ listSecurityGroups
+
+
+
+
+
+ listLoadBalancerRules
+
+
+
+
+
+ listProjects
+
+
+
+
+
+ listVPCs
+
+
+
+
+
+ listNetworkACLs
+
+
+
+
+
+ listStaticRoutes
+
+
+
+
+
+
+
+
+
+ AWS API Changes for Tags
+
+ Some changes have been made to the Amazon Web Services API compatibility support in order to accommodate the new tagging feature.
+
+
+ New APIs:
+
+
+
+
+
+
+
+
+
+ New API
+
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+
+ ec2-create-tags
+
+
+
+
+
+ Add tags to one or more resources.
+
+
+
+
+
+
+
+
+ ec2-delete-tags
+
+
+
+
+
+ Remove tags from one or more resources.
+
+
+
+
+
+
+
+ ec2-describe-tags
+
+
+
+ Show currently defined tags.
+
+
+
+
+
+
+
+
+
+
+
+
+ Changed APIs:
+
+
+
+
+
+
+
+
+
+ Changed API
+
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+ ec2-describe-images
+
+
+
+ Output now shows tags defined for each image.
+
+
+
+
+
+
+
+
+ ec2-describe-instances
+
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+
+
+
+
+ ec2-describe-snapshots
+
+
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+
+
+
+ ec2-describe-volumes
+
+
+
+ Output now shows tags defined for each image.
+
+
+ The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Secure Console Access on XenServer
+
+ With the addition of Secure Console feature, users can now securely access the VM consoles on the XenServer hypervisor. You can either SSH or use the View Console option in the Management Server to securely connect to the VMs on the XenServer host. The Management Server uses the xapi API to stream the VM consoles. However, there is no change in the way you can access the console of a VM. This feature is supported on XenServer 5.6 and 6.0 versions.
+
+
+
+
+
+ Stopped VM
+
+ This release supports creating VMs without starting them on the backend. You can determine whether the VM needs to be started as part of the VM deployment. A VM can be deployed in two ways: create and start a VM (the default method); create a VM and leave it in the stopped state.
+
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. The possible values are:
+
+
+
+
+ true - The VM starts as a part of the VM deployment
+
+
+
+
+
+ false - The VM is left in stopped state at the end of the VM deployment
+
+
+
+
+
+
+
+
+
+ Uploading an Existing Volume to a Virtual Machine
+
+ Existing data can now be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs. The upload is performed by using HTTP. The uploaded volume is placed in the zone's secondary storage.
+
+
+ This functionality is supported for the following hypervisors:
+
+
+
+
+ Hypervisor : Disk Image Format
+
+
+
+
+
+ XenServer : VHD
+
+
+
+
+
+ VMware : OVA
+
+
+
+
+
+ KVM : QCOW2
+
+
+
+
+
+
+
+
+
+ Dedicated High-Availability Hosts
+
+ One or more hosts can now be designated for use only by high-availability (HA) enabled VMs that are restarted due to a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HA-enabled VMs make it easier to determine which VMs are restarted as part of the high-availability function. You can designate a host as a dedicated-HA restart node only if the Dedicated HA Hosts feature is enabled by setting the appropriate global configuration parameter.
+
+
+
+
+
+ Support for Amazon Web Services API
+
+ This release supports Amazon Web Services APIs, including Elastic Compute Cloud (EC2) API. Fidelity with the EC2 API and the installation experience for this functionality are both enhanced. In prior releases, users were required to install a separate component called CloudBridge, in addition to installing the Management Server. For new installations of CloudStack 4.0.0-incubating, this software is installed automatically along with CloudStack and runs in a more closely integrated fashion. The feature is disabled by default, but can be easily enabled by setting the appropriate global configuration parameter and performing a few setup steps.
+
+
+
+
+
+ The Nicira NVP Plugin
+
+ The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating this plug-in supports the Connectivity service. This service is responsible for creating Layer 2 networks supporting the networks created by guests. When a tenant creates a new network, instead of a traditional VLAN, a logical network will be created by sending the appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira NVP versions 2.1.0, 2.2.0 and 2.2.1.
+
+
+
+
+
+ Support for CAStor Cluster
+
+ CloudStack 4.0.0-incubating supports using a CAStor cluster as the back-end storage system for a CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends the existing storage classes and allows the storage configuration attribute to point to a CAStor cluster. This feature makes use of the CloudStack server's local disk to spool files before writing them to CAStor when handling the PUT operations. However, a file must be successfully written into the CAStor cluster prior to the return of a success code to the S3 client to ensure that the transaction outcome is correctly reported.
+
+
+ The S3 multipart file upload is not supported in this release. You are prompted with proper error message if a multipart upload is attempted.
+
+
+
+
+
+ Clustered Logical Volume Manager Support for KVM
+
+ This release adds Clustered Logical Volume Manager (CLVM) storage support for KVM hosts. With this support, you can use CLVM as primary storage.
+
+
+ The CLVM support for KVM allows root and data disks (primary storage) to reside on Linux logical volumes. The administrators are required to configure CLVM on the KVM hosts independent of CloudStack. When the volume groups are available, an administrator can simply add primary storage of type CLVM, providing the volume group name. Then CloudStack creates and manages logical volumes as needed.
+
+
+ CLVM also supports Snapshots. CloudStack creates an LVM snapshot, copy the applicable logical volume to the secondary storage in the qcow2 format, and then delete the LVM snapshot.
+
+
+
+
+
+ Rados Block Device Support for KVM
+
+ You can now use Rados Block Device (RBD) to run instances on Apache CloudStack 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least 0.10 with RBD enabled on the KVM host
+
+
+ Create a disk offering for RBD so that you can ensure that StoragePoolAllocator chooses the RBD pool to deploy instances.
+
+
+
+
+
+
+
+
+ Issues Fixed in 4.0.0-incubating
+
+ Many bugs include a defect number that reflects the bug number that was held in the bug tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira to manage its bugs, so some of the bugs that are referenced here may not be available to view. However, we are still including them for completeness.
+
+
+
+
+
+
+
+
+
+ Defect
+
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+
+ Many
+
+
+
+
+ vSphere 5.0 now has GA support. Formerly only Beta support was provided.
+
+
+
+
+
+
+
+ CS-16135
+
+
+
+
+ Creating volumes after upgrading from snapshot taken in 2.2.14 no longer deletes the snapshot physically from the secondary storage.
+
+
+
+
+
+
+
+ CS-16122
+
+
+
+
+ In a site-to-site VPN setup, alerts are generated when the VPC virtual router is rebooted with multiple vpn connections.
+
+
+
+
+
+
+
+ CS-16022
+
+
+
+
+ If host connection fails due to a database error, host now disconnects and the Managerment Server id is removed.
+
+
+
+
+
+
+
+ CS-16011
+
+
+
+
+ Name of network offering is no longer truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+
+
+
+
+ CS-15978
+
+
+
+
+ When the virtual router and its host go down, the high availability mechanism now works for the virtual router.
+
+
+
+
+
+
+
+
+ CS-15921
+
+
+
+
+ The 2.2.x security group script now accounts for the VMs created in the version 2.1 timeframe.
+
+
+
+
+
+
+
+
+ CS-15919
+
+
+
+
+ A level parameter is added to the listVolumes command; therefore queries return the response more quickly.
+
+
+
+
+
+
+
+ CS-15904
+
+
+
+
+ Upgrade from version 2.2.14 to CloudStack-3.0.5-0.2944-rhel5 works as expected. The upgrade script, /usr/share/cloud/setup/db/schema-2214to30-cleanup.sql, works as expected.
+
+
+
+
+
+
+
+ CS-15879
+
+
+
+
+ The database upgrade from version 3.0.4 to 3.0.5 works as expected.
+
+
+
+
+
+
+
+
+ CS-15807
+
+
+
+
+ Network label for OVM now available in UI.
+
+
+
+
+
+
+
+
+ CS-15779
+
+
+
+
+ When the thumbnail is requested, the console session will not be terminated.
+
+
+
+
+
+
+
+
+ CS-15778
+
+
+
+
+ Fetching a VM thumbnail now gets a thumbnail of appropriate visual dimensions.
+
+
+
+
+
+
+
+
+ CS-15734
+
+
+
+
+ KVM Snapshots no longer shows incorrect disk usage.
+
+
+
+
+
+
+
+ CS-15733
+
+
+
+
+ The domainId parameter for the listNetworks command now lists the resources belonging to the domain specified.
+
+
+
+
+
+
+
+ CS-15676
+
+
+
+
+ Stopping the router no longer fails with the null pointer exception.
+
+
+
+
+
+
+
+
+ CS-15648
+
+
+
+
+ If creating a volume from a snapshot fails, the error is reported on the UI but the volume is stuck in the creating state.
+
+
+
+
+
+
+
+
+ CS-15646
+
+
+
+
+ createFirewallRule API no longer causes null pointer exception.
+
+
+
+
+
+
+
+ CS-15628
+
+
+
+
+ In a KVM host, the high availability mechanism no longer takes a long time to migrate VMs to another KVM host if there are multiple storage pools.
+
+
+
+
+
+
+
+ CS-15627
+
+
+
+
+ Metadata instance-id and vm-id for existing VMs stays the same after upgrade.
+
+
+
+
+
+
+
+ CS-15621
+
+
+
+
+ Solved difficulty with allocating disk volumes when running multiple VM deployment in parallel.
+
+
+
+
+
+
+
+ CS-15603
+
+
+
+
+ CloudStack now stop the VMs when destroyVM command is called.
+
+
+
+
+
+
+
+ CS-15586
+
+
+
+
+ Public Vlan for an account no longer fails if multiple physical networks are present.
+
+
+
+
+
+
+
+ CS-15582
+
+
+
+
+ The dns-name filter is now supported for ec2-describe-instances in the Amazon Web Services API compatibility commands. The filter maps to the name of a user VM.
+
+
+
+
+
+
+
+ CS-15503
+
+
+
+
+ An IP address which has static NAT rules can now be released. Subsequently, restarting this network after it was shutdown can succeed.
+
+
+
+
+
+
+
+ CS-15464
+
+
+
+
+ Can now delete static route whose state is set to Revoke.
+
+
+
+
+
+
+
+ CS-15443
+
+
+
+
+ Creating a firewall rule no longer fails with an internal server error.
+
+
+
+
+
+
+
+ CS-15398
+
+
+
+
+ Corrected technique for programming DNS on the user VMs.
+
+
+
+
+
+
+
+ CS-15356
+
+
+
+
+ Internal DNS 2 entry now correctly shown in UI.
+
+
+
+
+
+
+
+ CS-15335
+
+
+
+
+ The CloudBridge S3 Engine now connects to the database by using the deciphered password in the db.properties file.
+
+
+
+
+
+
+
+ CS-15318
+
+
+
+
+ UI now correctly prevents the user from stopping a VM that is in the Starting state.
+
+
+
+
+
+
+
+ CS-15307
+
+
+
+
+ Fixed Japanese localization of instance statuses in the Instances menu.
+
+
+
+
+
+
+
+ CS-15278
+
+
+
+
+ The deployment planner no longer takes long time to locate a suitable host to deploy VMs when large number of clusters are present.
+
+
+
+
+
+
+
+ CS-15274
+
+
+
+
+ Creating a VLAN range using Zone ID without network ID now succeeds.
+
+
+
+
+
+
+
+ CS-15243
+
+
+
+
+ Now check to be sure source NAT and VPN have same provider.
+
+
+
+
+
+
+
+ CS-15232
+
+
+
+
+ Ensure that networks using external load balancer/firewall in 2.2.14 or earlier can properly upgrade.
+
+
+
+
+
+
+
+ CS-15200
+
+
+
+
+ No exception when trying to attach the same volume while attaching the first volume is in progress.
+
+
+
+
+
+
+
+ CS-15173
+
+
+
+
+ Additional cluster can no longer be added with same VSM IP address as another cluster.
+
+
+
+
+
+
+
+ CS-15167
+
+
+
+
+ AWS API calls now honor the admin account's ability to view or act on the resources owned by the regular users.
+
+
+
+
+
+
+
+ CS-15163
+
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+
+
+
+
+ CS-15157
+
+
+
+
+ Can now add/enable service providers for multiple physical networks through the UI.
+
+
+
+
+
+
+
+ CS-15145
+
+
+
+
+ AWS API call ec2-register has better error handling for negative cases.
+
+
+
+
+
+
+
+ CS-15122
+
+
+
+
+ Filters now supported for AWS API call ec2-describe-availability-zones.
+
+
+
+
+
+
+
+ CS-15120
+
+
+
+
+ Actions column in UI of Volume page now shows action links.
+
+
+
+
+
+
+
+ CS-15099
+
+
+
+
+ Buttons no longer overlap text on Account Deletion confirmation page in UI.
+
+
+
+
+
+
+
+ CS-15095
+
+
+
+
+ Ensures you can not create a VM with a CPU frequency greater than the host CPU frequency.
+
+
+
+
+
+
+
+ CS-15094
+
+
+
+
+ CPU cap now set properly in VMware.
+
+
+
+
+
+
+
+ CS-15077
+
+
+
+
+ NullPointerException is no longer observed while executing the command to list the public IP in a basic zone created with the default shared NetScaler EIP and ELB network offering.
+
+
+
+
+
+
+
+ CS-15044
+
+
+
+
+ UI now provides option to view the list of instances which are part of the guest network.
+
+
+
+
+
+
+
+ CS-15026
+
+
+
+
+ UI in Deploy VM dialog now lists only templates or ISOs depending on which is selected in previous dialog.
+
+
+
+
+
+
+
+ CS-14989
+
+
+
+
+ In KVM, the Create Instance wizard now shows only templates from the current (KVM) zone.
+
+
+
+
+
+
+
+ CS-14986, CS-14985
+
+
+
+
+ Listing filters works as expected in the ec2-describe-volumes and ec2-describe-snapshots commands.
+
+
+
+
+
+
+
+ CS-14964
+
+
+
+
+ Automatically starting the Console Proxy no longer fails due to its missing volume on the primary storage
+
+
+
+
+
+
+
+ CS-14907
+
+
+
+
+ User is now correctly prevented from trying to download an uploaded volume which has not yet been moved to primary storage.
+
+
+
+
+
+
+
+ CS-14879
+
+
+
+
+ When a user VM is stopped or terminated, the static NAT associated with this VM is now disabled. This public IP address is no longer owned by this account and can be associated to any other user VM.
+
+
+
+
+
+
+
+ CS-14854
+
+
+
+
+ Only the admin user can change the template permission to Public, so this option is removed from the UI for domain Admins and regular Users.
+
+
+
+
+
+
+
+ CS-14817
+
+
+
+
+ While checking if network has any external provider, CloudStack will consider all providers in the network.
+
+
+
+
+
+
+
+ CS-14796
+
+
+
+
+ When deploying a VM with ec2-run-instances, userdata is now encoded.
+
+
+
+
+
+
+
+ CS-14770
+
+
+
+
+ The API returns the keypair information when a VM is deployed with sshkey. This affects the API commands related to virtual machines (deployVirtualMachine, listVirtualMachines, ... *VirtualMachine), as well as the corresponding AWS APIs.
+
+
+
+
+
+
+
+ CS-14724
+
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+
+
+
+
+ CS-14345
+
+
+
+
+ Logout API returns XML header.
+
+
+
+
+
+
+
+ CS-14724
+
+
+
+
+ Host IPs now associated with appropriate IPs according to traffic type.
+
+
+
+
+
+
+
+ CS-14253
+
+
+
+
+ Can now delete and re-create port forwarding rule on same firewall.
+
+
+
+
+
+
+
+ CS-14724
+
+
+
+
+ UI no longer displays the dropdown list of isolation method choices if sdn.ovs.controller is false.
+
+
+
+
+
+
+
+ CS-14452
+
+
+
+
+ Data disk volumes are now automatically copied from one cluster to another.
+
+
+
+
+
+
+
+ CS-13539
+
+
+
+
+ Windows VM can get IP after reboot.
+
+
+
+
+
+
+
+ CS-13537
+
+
+
+
+ When user tries to delete a domain that contains sub-domains, an error message is now sent to convey the reason for the delete failure.
+
+
+
+
+
+
+
+ CS-13153
+
+
+
+
+ System VMs support HTTP proxy.
+
+
+
+
+
+
+
+ CS-12642
+
+
+
+
+ Added Close button to Select Project list view popup in UI.
+
+
+
+
+
+
+
+ CS-12510
+
+
+
+
+ Deleting and reinserting host_details no longer causes deadlocks.
+
+
+
+
+
+
+
+ CS-12407
+
+
+
+
+ F5 and Netscaler - when dedicated is selected, capacity field is disabled.
+
+
+
+
+
+
+
+ CS-12111
+
+
+
+
+ Email validation for edit user form.
+
+
+
+
+
+
+
+ CS-10928
+
+
+
+
+ Network read/write values now always positive numbers.
+
+
+
+
+
+
+
+ CS-15376, CS-15373
+
+
+
+
+ The AWS APIs (EC2 and S3) now listen on the 7080 port and send request to CloudStack on the 8080 port just as any other clients of CloudStack.
+
+
+
+
+
+
+
+ CS-13944
+
+
+
+
+ The CloudStack 2.2.x to 3.0.x database upgrade for multiple physical networks is now supported.
+
+
+
+
+
+
+
+ CS-15300
+
+
+
+
+ The admin accounts of a domain now honour the limits imposed on that domain just like the regular accounts do. A domain admin now is not allowed to create an unlimited number of instances, volumes, snapshots, and so on.
+
+
+
+
+
+
+
+ CS-15396
+
+
+
+
+ The CloudStack database now contain the UUD information after the 2.2.14 to 3.0.4 upgrade.
+
+
+
+
+
+
+
+ CS-15450
+
+
+
+
+ Upgrade from 2.2.14 to 3.0.4 no longer fails on a VMware host.
+
+
+
+
+
+
+
+ CS-15449
+
+
+
+
+ Running cloudstack-aws-api-register no longer fails with the "User registration failed with error: [Errno 113] No route to host" error.
+
+
+
+
+
+
+
+ CS-15455
+
+
+
+
+ The iptable rules are configured to open the awsapi port (7080) as part of the installation.
+
+
+
+
+
+
+
+ CS-15429
+
+
+
+
+ While creating an instance with data volume, disk offering also is considered while checking the account limit on volume resources.
+
+
+
+
+
+
+
+ CS-15414
+
+
+
+
+ After the 2.2.14 to 3.0.4 upgrade, the value of the global parameter xen.guest.network.device is now decrypted before setting the traffic label.
+
+
+
+
+
+
+
+ CS-15382
+
+
+
+
+ During 2.2.14 to 3.0.4 upgrade, the hosts no longer go to the Alert state if destroyed networks existed with non-existent tags prior to upgrade.
+
+
+
+
+
+
+
+ CS-15323
+
+
+
+
+ CloudStack supports the following Citrix XenServer hotfixes: XS602E003, XS602E004, and XS602E005.
+
+
+
+
+
+
+
+ CS-15430
+
+
+
+
+ Create snapshot now fails if creating a snapshot exceeds the snapshot resource limit for a domain admin or a user account.
+
+
+
+
+
+
+
+ CS-14256
+
+
+
+
+ Virtual Router no longer remains in starting state for subdomain or user on a KVM 3.0.1 prerlease host on RHEL 6.2.
+
+
+
+
+
+
+
+ CS-7495
+
+
+
+
+ Implemented a variety of Xen management host improvements.
+
+
+
+
+
+
+
+ CS-8105
+
+
+
+
+ NFS v4 for primary storage now works as expected on KVM hosts.
+
+
+
+
+
+
+
+ CS-9989
+
+
+
+
+ The error messages returned during VM deployment failure will have much more details than before.
+
+
+
+
+
+
+
+ CS-12584
+
+
+
+
+ You can no longer add security groups not supported by the hypervisor in use.
+
+
+
+
+
+
+
+ CS-12705
+
+
+
+
+ When creating a Network offering by using SRX as the service provider for SourceNAT servcies, an option is given in the CloudStack UI now to set the source_nat type to "per Zone"/"per account".
+
+
+
+
+
+
+
+ CS-12782
+
+
+
+
+ Assigning a VM from Basic to Advanced zone no longer ignores the network ID. A warning message is displayed for VM movements across zones.
+
+
+
+
+
+
+
+ CS-12591
+
+
+
+
+ Broadcast Address on the Second Public IP NIC is now corrected.
+
+
+
+
+
+
+
+ CS-13272
+
+
+
+
+ When a user is deleted, all the associated properties, such as IPs and virtual routers, are now deleted.
+
+
+
+
+
+
+
+ CS-13377
+
+
+
+
+ Creating template from a root disk of a stopped instance now provides an option to make it a "Featured template".
+
+
+
+
+
+
+
+ CS-13500
+
+
+
+
+ Reaching the first guest VM by using its public IP from the second guest VM no longer fails.
+
+
+
+
+
+
+
+ CS-13853
+
+
+
+
+ The default gateway can no longer be 0.0.0.0 in the Secondary Storage VM (SSVM).
+
+
+
+
+
+
+
+ CS-13863
+
+
+
+
+ The queryAsyncJobResult command in XML format now returns the correct UUIDs.
+
+
+
+
+
+
+
+ CS-13867
+
+
+
+
+ Corrected CSP xenserver-cloud-supp.tgz for XenServer 5.6 and 6.0.
+
+
+
+
+
+
+
+ CS-13904
+
+
+
+
+ Labels and values for the service offerings CPU and memory are now consistent.
+
+
+
+
+
+
+
+ CS-13998
+
+
+
+
+ The SSVM kernel panic issue is fixed on XenServer.
+
+
+
+
+
+
+
+ CS-14090
+
+
+
+
+ The issue is fixed where running the VMware snapshots randomly fails with the ArrayIndexOutOfBoundsException error.
+
+
+
+
+
+
+
+ CS-14021
+
+
+
+
+ The java.lang.OutOfMemoryError is fixed on the Management Server.
+
+
+
+
+
+
+
+ CS-14025
+
+
+
+
+ The Python Eggs are provided to easily package the test client for each branch of CloudStack.
+
+
+
+
+
+
+
+ CS-14068
+
+
+
+
+ Resetting the VM password through the CloudStack UI no longer causes any error.
+
+
+
+
+
+
+
+ CS-14156
+
+
+
+
+ The pod which has the administrator's virtual router is no longer selected while creating the virtual routers for guests.
+
+
+
+
+
+
+
+ CS-14182
+
+
+
+
+ The users can now delete their ISOs as normal users.
+
+
+
+
+
+
+
+ CS-14185
+
+
+
+
+ The listOSTypes API now filters out the types of operating system by using the keywords.
+
+
+
+
+
+
+
+ CS-14204
+
+
+
+
+ The cloud-setup-bonding.sh command no longer generates the "command not found" error.
+
+
+
+
+
+
+
+ CS-14214
+
+
+
+
+ The Specify VLAN option cannot be enabled now for an isolated Network offering with SourceNAT enabled.
+
+
+
+
+
+
+
+ CS-14234
+
+
+
+
+ Sending project invite email to an account now requires SMTP configured in CloudStack.
+
+
+
+
+
+
+
+ CS-14237
+
+
+
+
+ The garbage collector of the primary storage no longer fails when the first host in the cluster is not up.
+
+
+
+
+
+
+
+ CS-14241
+
+
+
+
+ Custom Volume Disk Offering is now matching the Global configuration value.
+
+
+
+
+
+
+
+ CS-14270
+
+
+
+
+ The listNetworks API no longer assumes that the broadcast type is always VLAN.
+
+
+
+
+
+
+
+ CS-14319
+
+
+
+
+ The internal name of the VM is no longer present in the error message that is displayed to a domain administrator.
+
+
+
+
+
+
+
+ CS-14321
+
+
+
+
+ The listVolumes API call now returns a valid value for the isExtractable parameter for the ISO-derived disk and data disk volumes.
+
+
+
+
+
+
+
+ CS-14323
+
+
+
+
+ Invalid API calls will now give valid response in json/xml format.
+
+
+
+
+
+
+
+ CS-14339
+
+
+
+
+ Custom Disk Size will now allow values larger than 100GB.
+
+
+
+
+
+
+
+ CS-14357
+
+
+
+
+ The ConsoleProxyLoadReportCommand is no longer fired continuously.
+
+
+
+
+
+
+
+ CS-14421
+
+
+
+
+ Fixed the issue of virtual router deployments. The DHCP entries can now be assigned to the router.
+
+
+
+
+
+
+
+ CS-14555
+
+
+
+
+ Unzipped downloaded template MD5SUM will no longer override the zipped template MD5SUM in the database.
+
+
+
+
+
+
+
+ CS-14598
+
+
+
+
+ The complete screen of the running VM is now displayed in the console proxy.
+
+
+
+
+
+
+
+ CS-14600
+
+
+
+
+ Windows or Linux based consoles are no longer lost upon rebooting VMs.
+
+
+
+
+
+
+
+ CS-14784
+
+
+
+
+ Multiple subnets with the same VLAN now work as expected.
+
+
+
+
+
+
+
+ CS-13303, 14874, 13897, 13944, 14088, 14190
+
+
+
+
+ A variety of upgrade issues have been fixed in release 3.0.3.
+
+
+
+
+
+
+
+ CS-15080
+
+
+
+
+ Setting a private network on a VLAN for VMWare environment is now supported.
+
+
+
+
+
+
+
+ CS-15168
+
+
+
+
+ The console proxy now works as expected and no exception is shown in the log after upgrading from version 2.2.14 to 3.0.2.
+
+
+
+
+
+
+
+ CS-15172
+
+
+
+
+ Version 3.0.2 now accepts the valid public key.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Known Issues in 4.0.0-incubating
+
+
+
+
+
+
+
+
+ Issue ID
+
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+
+ CLOUDSTACK-301
+
+
+
+
+ Nexus 1000v DVS integration is not functional
+
+
+ This source code release includes some partial functionality to support the Cisco Nexus 1000v Distributed Virtual Switch within a VMware hypervisor environment. The functionality is not complete at this time.
+
+
+
+
+
+
+
+
+ CLOUDSTACK-368
+
+
+
+
+ OVM - cannot create guest VM
+
+
+ This source code release has regressed from the CloudStack 2.2.x code and is unable to support Oracle VM (OVM).
+
+
+
+
+
+
+
+
+ CLOUDSTACK-279
+
+
+
+
+ Deleting a project fails when executed by the regular user. This works as expected for root/domain admin. To workaround, perform either of the following:
+
+
+
+
+ Use the account cleanup thread which will eventually complete the project deletion.
+
+
+
+
+
+ Execute the call as the root/domain admin on behalf of the regular user.
+
+
+
+
+
+
+
+
+
+
+
+
+ CS-16067
+
+
+
+
+ The command=listTags&key=city command does not work as expected. The command does not return tags for the resources of the account with the tag, city
+
+
+
+
+
+
+
+
+ CS-16063
+
+
+
+
+ The current values of volumes and snapshots are incorrect when using KVM as a host. To fix this, the database upgrade codes, volumes.size and snapshots.size, should be changed to show the virtual sizes.
+
+
+
+
+
+
+
+
+ CS-16058
+
+
+
+
+ Null pointer Exception while deleting the host after moving the host to maintenance state.
+
+
+
+
+
+
+
+
+ CS-16045
+
+
+
+
+ Only the root administrator can handle the API keys. The domain administrators are not allowed to create, delete, or retrieve API keys for the users in their domain.
+
+
+
+
+
+
+
+
+ CS-16019
+
+
+
+
+ CIDR list in the Add VPN Customer Gateway dialog does not prompt the user that they can provide a comma separated CIDRs if multiple CIDRs have to be supplied.
+
+
+
+
+
+
+
+
+ CS-16015
+
+
+
+
+ Deleting a network is not supported when its network providers are disabled.
+
+
+
+
+
+
+
+
+ CS-16012
+
+
+
+
+ Unable to delete a zone in the UI because the necessary cleanup cannot be completed. When the hosts are removed, the expunge process fails to delete the volumes as no hosts are present to send the commands to. Therefore, the storage pool removal fails, and zone can't be cleaned and deleted.
+
+
+
+
+
+
+
+
+ CS-16011
+
+
+
+
+ Name of network offering might be truncated due to too-narrow field width in Add Guest Network dialog box.
+
+
+
+
+
+
+
+
+ CS-15789
+
+
+
+
+ Invalid global setting prevents management server to restart. For example, if you configure the "project.invite.timeout" parameter to "300" and attempt to restart management server, it fails without throwing a warning or setting the value to the default.
+
+
+
+
+
+
+
+
+ CS-15749
+
+
+
+
+ Restarting VPC is resulting in intermittent connection loss to the port forwarding and StaticNAT rules.
+
+
+
+
+
+
+
+
+ CS-15690
+
+
+
+
+ The IpAssoc command failed as a part of starting the virtual router, but the final start result is reported as succes.
+
+
+
+
+
+
+
+
+ CS-15672, CS-15635
+
+
+
+
+ The FQDN of the VM is not configured if it is deployed as a part of default shared network and isolated guest network (DefaultIsolatedNetworkOfferingWithSourceNatService).
+
+
+
+
+
+
+
+
+ CS-15634
+
+
+
+
+ The FQDN of a VM that is deployed as a part of both a shared network and default isolated guest network has the suffix of the shared network instead of the default isolated guest network.
+
+
+
+
+
+
+
+
+ CS-15576
+
+
+
+
+ Stopping a VM on XenServer creates a backlog of API commands. For example, the Attach volume calls become delayed while waiting for the stopVirtualMachine command to be executed.
+
+
+
+
+
+
+
+
+ CS-15569
+
+
+
+
+ Misleading error message in the exception when creating a StaticNAT rule fails in a VPC.
+
+
+
+
+
+
+
+
+ CS-15566
+
+
+
+
+ External device such as Netscaler is not supported in VPC.
+
+
+
+
+
+
+
+ CS-15557
+
+
+
+
+ Intermittent traffic loss in the VPN connection if Juniper is the remote router and the life time is 300 seconds.
+
+
+
+
+
+
+
+
+ CS-15361
+
+
+
+
+ Egress rules are not working in NetScaler loadbalancer.
+
+
+
+
+
+
+
+
+ CS-15163
+
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+
+
+
+
+ CS-15105
+
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+
+
+
+
+ CS-15092
+
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+
+
+
+
+ CS-15037
+
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+
+
+
+
+ CS-15009
+
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+
+
+
+
+ CS-14939
+
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+
+
+
+
+ CS-14780
+
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+
+
+
+
+ CS-14756
+
+
+
+
+ Installing KVM on RHEL 6.2 will result in unreliable network performance. Workaround: blacklist vhost-net. Edit /etc/modprobe.d/blacklist-kvm.conf and include vhost-net.
+
+
+
+
+
+
+
+ CS-14346
+
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+
+
+
+
+ CS-14303 (was 14537)
+
+
+
+
+ The IP addresses for a shared network are still being consumed even if no services are defined for that network.
+
+
+
+
+
+
+
+ CS-14296 (was 14530)
+
+
+
+
+ OVM: Network traffic labels are not supported.
+
+
+
+
+
+
+
+ CS-14291 (was 14523)
+
+
+
+
+ The EIP/ELB network offering for basic zones does not support multiple NetScalers.
+
+
+
+
+
+
+
+ CS-14275 (was 14506)
+
+
+
+
+ F5: Unable to properly remove a F5 device.
+
+
+
+
+
+
+
+ CS-14201 (was 14430)
+
+
+
+
+ VMWare: Template sizes are being reported different depending on whether the primary storage is using ISCSI or NFS.
+
+
+
+
+
+
+
+ CS-13758 (was 13963)
+
+
+
+
+ vSphere: template download from templates created off of the root volume does not work properly.
+
+
+
+
+
+
+
+ CS-13733 (was 13935)
+
+
+
+
+ vSphere: detaching an ISO from a restored VM instance fails.
+
+
+
+
+
+
+
+ CS-13682 (was 13883)
+
+
+
+
+ Multiple NetScalers are not supported in Basic Networking.
+
+
+
+
+
+
+
+ CS-13599 (was 13359)
+
+
+
+
+ Programming F5/NetScaler rules can be better optimized.
+
+
+
+
+
+
+
+ CS-13337 (was 13518)
+
+
+
+
+ Security Groups are not supported in Advanced Networking
+
+
+
+
+
+
+
+ CS-13173 (was 13336)
+
+
+
+
+ vSphere: cross cluster volume migration does not work properly.
+
+
+
+
+
+
+
+ CS-12714 (was 12840)
+
+
+
+
+ Capacity view is not available for pods or clusters.
+
+
+
+
+
+
+
+ CS-12624 (was 12741)
+
+
+
+
+ vSphere: maintenance mode will not live migrate system VM to another host.
+
+
+
+
+
+
+
+ CS-15476
+
+
+
+
+
+ The 2.2.14 to 4.0.0-incubating upgrade fails if multiple untagged physical networks exist before the upgrade.
+
+
+
+
+
+
+
+
+ CS-15407
+
+
+
+
+
+ After the 2.2.14 to 4.0.0-incubating upgrade, VLAN allocation on multiple physical networks does not happen as expected.
+
+
+ To workaround this issue, follow the instructions given below:
+
+
+
+
+ Revert to your 2.2.14 setup.
+
+
+
+
+
+ Stop all the VMs with the isolated virtual networks in your cloud setup.
+
+
+
+
+
+ Run following query to find if any networks still have the NICs allocated:
+
+
+
+
+ Check if any virtual guest networks have the NICs allocated:
+
+
+#SELECT DISTINCT op.id from `cloud`.`op_networks` op JOIN `cloud`.`networks` n on op.id=n.id WHERE nics_count != 0 AND guest_type = 'Virtual';
+
+
+
+
+ If this returns any network IDs, then ensure the following:
+
+
+
+
+ All the VMs are stopped.
+
+
+
+
+
+ No new VM is started.
+
+
+
+
+
+ Shutdown the Management Server.
+
+
+
+
+
+
+
+
+
+ Remove the NICs count for the virtual network IDs returned in step (a), and set the NIC count to 0:
+
+
+UPDATE `cloud`.`op_networks` SET nics_count = 0 WHERE id = enter id of virtual network
+
+
+
+
+ Restart the Management Server, and wait for all the networks to shut down.
+
+
+
+ Networks shutdown is determined by the network.gc.interval and network.gc.wait parameters.
+
+
+
+
+
+
+
+
+
+
+
+ Ensure that all the networks are shut down and all the guest VNETs are free.
+
+
+
+
+
+ Run the upgrade script.
+
+
+ This allocates all your guest VNET ranges to the first physical network.
+
+
+
+
+
+ By using the updatePhysicalNetwork API, reconfigure the VNET ranges for each physical network as desired.
+
+
+
+
+
+ Start all the VMs.
+
+
+
+
+
+
+
+
+
+
+
+
+ CS-14680
+
+
+
+
+
+ CloudStack and LDAP user validation cannot happen simultaneously because the user password is hashed and stored in the database, and LDAP requires the passwords in plain text.
+
+
+ To work with the LDAP user, the MD5 hash should be disabled in the login process by commenting the following variable in sharedFunctions.js file available at /usr/share/cloud/management/webapps/client/scripts, and restart the cloud-management service.
+
+
+var md5HashedLogin = false;
+
+ However, if md5HashedLogin is set to false, the end user can login with the LDAP credentials but not with the CloudStack user credentials.
+
+
+
+
+
+
+
+
+ CS-14346
+
+
+
+
+ The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.
+
+
+
+
+
+
+
+ CS-15130
+
+
+
+
+ Data disk volumes are not automatically copied from one cluster to another.
+
+
+
+
+
+
+
+ CS-14780
+
+
+
+
+ You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.
+
+
+
+
+
+
+
+ CS-14939
+
+
+
+
+ Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.
+
+
+
+
+
+
+
+ CS-15009
+
+
+
+
+ The port_profile table will not be populated with port profile information. In this release, CloudStack directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.
+
+
+
+
+
+
+
+ CS-15037
+
+
+
+
+ Hairpin NAT is not supported when NetScaler is used for EIP.
+
+
+
+
+
+
+
+ CS-15092
+
+
+
+
+ Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.
+
+
+
+
+
+
+
+ CS-15105
+
+
+
+
+ The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.
+
+
+
+
+
+
+
+ CS-15163
+
+
+
+
+ The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ API Changes from 3.0.2 to 4.0.0-incubating
+
+ New API Commands in 4.0.0-incubating
+
+
+
+ createCounter (Adds metric counter)
+
+
+
+
+
+ deleteCounter (Deletes a counter)
+
+
+
+
+
+ listCounters (List the counters)
+
+
+
+
+
+ createCondition (Creates a condition)
+
+
+
+
+
+ deleteCondition (Removes a condition)
+
+
+
+
+
+ listConditions (List Conditions for the specific user)
+
+
+
+
+
+ createTags. Add tags to one or more resources. Example:
+command=createTags
+&resourceIds=1,10,12
+&resourceType=userVm
+&tags[0].key=region
+&tags[0].value=canada
+&tags[1].key=city
+&tags[1].value=Toronto
+
+
+
+
+
+ deleteTags. Remove tags from one or more resources. Example:
+command=deleteTags
+&resourceIds=1,12
+&resourceType=Snapshot
+&tags[0].key=city
+
+
+
+
+
+ listTags (Show currently defined resource tags)
+
+
+
+
+
+ createVPC (Creates a VPC)
+
+
+
+
+
+ listVPCs (Lists VPCs)
+
+
+
+
+
+ deleteVPC (Deletes a VPC)
+
+
+
+
+
+ updateVPC (Updates a VPC)
+
+
+
+
+
+ restartVPC (Restarts a VPC)
+
+
+
+
+
+ createVPCOffering (Creates VPC offering)
+
+
+
+
+
+ updateVPCOffering (Updates VPC offering)
+
+
+
+
+
+ deleteVPCOffering (Deletes VPC offering)
+
+
+
+
+
+ listVPCOfferings (Lists VPC offerings)
+
+
+
+
+
+ createPrivateGateway (Creates a private gateway)
+
+
+
+
+
+ listPrivateGateways (List private gateways)
+
+
+
+
+
+ deletePrivateGateway (Deletes a Private gateway)
+
+
+
+
+
+ createNetworkACL (Creates a ACL rule the given network (the network has to belong to VPC))
+
+
+
+
+
+ deleteNetworkACL (Deletes a Network ACL)
+
+
+
+
+
+ listNetworkACLs (Lists all network ACLs)
+
+
+
+
+
+ createStaticRoute (Creates a static route)
+
+
+
+
+
+ deleteStaticRoute (Deletes a static route)
+
+
+
+
+
+ listStaticRoutes (Lists all static routes)
+
+
+
+
+
+ createVpnCustomerGateway (Creates site to site vpn customer gateway)
+
+
+
+
+
+ createVpnGateway (Creates site to site vpn local gateway)
+
+
+
+
+
+ createVpnConnection (Create site to site vpn connection)
+
+
+
+
+
+ deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
+
+
+
+
+
+ deleteVpnGateway (Delete site to site vpn gateway)
+
+
+
+
+
+ deleteVpnConnection (Delete site to site vpn connection)
+
+
+
+
+
+ updateVpnCustomerGateway (Update site to site vpn customer gateway)
+
+
+
+
+
+ resetVpnConnection (Reset site to site vpn connection)
+
+
+
+
+
+ listVpnCustomerGateways (Lists site to site vpn customer gateways)
+
+
+
+
+
+ listVpnGateways (Lists site 2 site vpn gateways)
+
+
+
+
+
+ listVpnConnections (Lists site to site vpn connection gateways)
+
+
+
+
+
+ markDefaultZoneForAccount (Marks a default zone for the current account)
+
+
+
+
+
+ uploadVolume (Uploads a data disk)
+
+
+
+
+
+
+
+
+
+ Changed API Commands in 4.0.0-incubating
+
+
+
+
+
+
+
+
+ API Commands
+
+
+
+
+ Description
+
+
+
+
+
+
+
+
+
+
+ copyTemplate
+
+
+ prepareTemplate
+
+
+ registerTemplate
+
+
+ updateTemplate
+
+
+ createProject
+
+
+ activateProject
+
+
+ suspendProject
+
+
+ updateProject
+
+
+ listProjectAccounts
+
+
+ createVolume
+
+
+ migrateVolume
+
+
+ attachVolume
+
+
+ detachVolume
+
+
+ uploadVolume
+
+
+ createSecurityGroup
+
+
+ registerIso
+
+
+ copyIso
+
+
+ updateIso
+
+
+ createIpForwardingRule
+
+
+ listIpForwardingRules
+
+
+ createLoadBalancerRule
+
+
+ updateLoadBalancerRule
+
+
+ createSnapshot
+
+
+
+
+
+ The commands in this list have a single new response parameter, and no other changes.
+
+
+ New response parameter: tags(*)
+
+
+
+ Many other commands also have the new tags(*) parameter in addition to other changes; those commands are listed separately.
+
+
+
+
+
+
+
+
+
+ rebootVirtualMachine
+
+
+ attachIso
+
+
+ detachIso
+
+
+ listLoadBalancerRuleInstances
+
+
+ resetPasswordForVirtualMachine
+
+
+ changeServiceForVirtualMachine
+
+
+ recoverVirtualMachine
+
+
+ startVirtualMachine
+
+
+ migrateVirtualMachine
+
+
+ deployVirtualMachine
+
+
+ assignVirtualMachine
+
+
+ updateVirtualMachine
+
+
+ restoreVirtualMachine
+
+
+ stopVirtualMachine
+
+
+ destroyVirtualMachine
+
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+
+
+
+
+ listSecurityGroups
+
+
+ listFirewallRules
+
+
+ listPortForwardingRules
+
+
+ listSnapshots
+
+
+ listIsos
+
+
+ listProjects
+
+
+ listTemplates
+
+
+ listLoadBalancerRules
+
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: tags (optional)
+
+
+ New response parameter: tags(*)
+
+
+
+
+
+
+
+
+ listF5LoadBalancerNetworks
+
+
+ listNetscalerLoadBalancerNetworks
+
+
+ listSrxFirewallNetworks
+
+
+ updateNetwork
+
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+
+
+
+
+ createZone
+
+
+ updateZone
+
+
+
+
+
+ The commands in this list have the following new parameters, and no other changes.
+
+
+ New request parameter: localstorageenabled (optional)
+
+
+ New response parameter: localstorageenabled
+
+
+
+
+
+
+
+
+ listZones
+
+
+
+
+ New response parameter: localstorageenabled
+
+
+
+
+
+
+
+ rebootRouter
+
+
+ changeServiceForRouter
+
+
+ startRouter
+
+
+ destroyRouter
+
+
+ stopRouter
+
+
+
+
+
+ The commands in this list have two new response parameters, and no other changes.
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+
+
+
+
+ updateAccount
+
+
+ disableAccount
+
+
+ listAccounts
+
+
+ markDefaultZoneForAccount
+
+
+ enableAccount
+
+
+
+
+
+ The commands in this list have three new response parameters, and no other changes.
+
+
+ New response parameters: vpcavailable, vpclimit, vpctotal
+
+
+
+
+
+
+
+ listRouters
+
+
+
+
+ New request parameters: forvpc (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, nic(*)
+
+
+
+
+
+
+
+
+ listNetworkOfferings
+
+
+
+
+ New request parameters: forvpc (optional)
+
+
+ New response parameters: forvpc
+
+
+
+
+
+
+
+
+ listVolumes
+
+
+
+
+ New request parameters: details (optional), tags (optional)
+
+
+ New response parameters: tags(*)
+
+
+
+
+
+
+
+
+ addTrafficMonitor
+
+
+
+
+ New request parameters: excludezones (optional), includezones (optional)
+
+
+
+
+
+
+
+
+ createNetwork
+
+
+
+
+ New request parameters: vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+
+
+
+
+ listPublicIpAddresses
+
+
+
+
+ New request parameters: tags (optional), vpcid (optional)
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+
+
+
+
+ listNetworks
+
+
+
+
+ New request parameters: canusefordeploy (optional), forvpc (optional), tags (optional), vpcid (optional)
+
+
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+
+
+
+
+ restartNetwork
+
+
+
+
+ New response parameters: vpcid, tags(*)
+
+
+
+
+
+
+
+
+ enableStaticNat
+
+
+
+
+ New request parameter: networkid (optional)
+
+
+
+
+
+
+
+
+ createDiskOffering
+
+
+
+
+ New request parameter: storagetype (optional)
+
+
+ New response parameter: storagetype
+
+
+
+
+
+
+
+
+ listDiskOfferings
+
+
+
+
+ New response parameter: storagetype
+
+
+
+
+
+
+
+
+ updateDiskOffering
+
+
+
+
+ New response parameter: storagetype
+
+
+
+
+
+
+
+
+ createFirewallRule
+
+
+
+
+ Changed request parameters: ipaddressid (old version - optional, new version - required)
+
+
+ New response parameter: tags(*)
+
+
+
+
+
+
+
+
+ listVirtualMachines
+
+
+
+
+ New request parameters: isoid (optional), tags (optional), templateid (optional)
+
+
+ New response parameters: keypair, tags(*)
+
+
+
+
+
+
+
+
+ updateStorageNetworkIpRange
+
+
+
+
+ New response parameters: id, endip, gateway, netmask, networkid, podid, startip, vlan, zoneid
+
+
+
+
+
+
+
+
+ reconnectHost
+
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+
+
+
+
+ addCluster
+
+
+
+
+ The following request parameters are added:
+
+
+
+
+ vsmipaddress (optional)
+
+
+
+
+
+ vsmpassword (optional)
+
+
+
+
+
+ vsmusername (optional)
+
+
+
+
+
+
+ The following parameter is made mandatory: podid
+
+
+
+
+
+
+
+
+ listVolumes
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ migrateVolume
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ prepareHostForMaintenance
+
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+
+
+
+
+ addSecondaryStorage
+
+
+
+
+ A new response parameter is added: hahost.
+
+
+
+
+
+
+
+ enableAccount
+
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+
+
+
+
+ attachVolume
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ cancelHostMaintenance
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ addSwift
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ listSwifts
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ listExternalLoadBalancers
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ createVolume
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ listCapabilities
+
+
+
+
+ A new response parameter is added: customdiskofferingmaxsize
+
+
+
+
+
+
+
+ disableAccount
+
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+
+
+
+
+ deployVirtualMachine
+
+
+
+
+ A new request parameter is added: startvm (optional)
+
+
+
+
+
+
+
+ deleteStoragePool
+
+
+
+
+ A new request parameter is added: forced (optional)
+
+
+
+
+
+
+
+ updateAccount
+
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+
+
+
+
+ addHost
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ updateHost
+
+
+
+
+ A new response parameter is added: hahost
+
+
+
+
+
+
+
+ detachVolume
+
+
+
+
+ A new response parameter is added: status
+
+
+
+
+
+
+
+ listAccounts
+
+
+
+
+ A new response parameter is added: defaultzoneid
+
+
+
+
+
+
+
+ listHosts
+
+
+
+
+ A new response parameter is added: hahost
+
+
+ A new request parameter is added: hahost (optional)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/remove-member-from-project.xml b/docs/tmp/en-US/xml/remove-member-from-project.xml
new file mode 100644
index 00000000000..a81f6310318
--- /dev/null
+++ b/docs/tmp/en-US/xml/remove-member-from-project.xml
@@ -0,0 +1,80 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Removing a Member From a Project
+
+ When a member is removed from a project, the member’s resources continue to be owned by the project. The former project member cannot create any new resources within the project or use any of the project’s existing resources.
+
+
+ A member of a project can be removed by the project administrator, the domain administrator of the domain the project belongs to or of its parent domain, or the &PRODUCT; root administrator.
+
+
+
+
+ Log in to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation, click Projects.
+
+
+
+
+ In Select View, choose Projects.
+
+
+
+
+ Click the name of the project.
+
+
+
+
+ Click the Accounts tab.
+
+
+
+
+ Click the name of the member.
+
+
+
+
+ Click the Delete button.
+
+
+
+
+
+ deletebutton.png: Removes a member
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/remove-tier.xml b/docs/tmp/en-US/xml/remove-tier.xml
new file mode 100644
index 00000000000..0b19a9b693f
--- /dev/null
+++ b/docs/tmp/en-US/xml/remove-tier.xml
@@ -0,0 +1,78 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Removing Tiers
+
+ You can remove a tier from a VPC. A removed tier cannot be revoked. When a tier is removed, only the resources of the tier are expunged. All the network rules (port forwarding, load balancing and staticNAT) and the IP addresses associated to the tier are removed. The IP address still be belonging to the same VPC.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPC that you have created for the account is listed in the page.
+
+
+
+
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+
+
+ The Configure VPC page is displayed. Locate the tier you want to work with.
+
+
+
+
+
+ Click the Remove VPC button:
+
+
+
+
+
+
+ remove-tier.png: removing a tier from a vpc.
+
+
+
+
+ Wait for some time for the tier to be removed.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/remove-vpc.xml b/docs/tmp/en-US/xml/remove-vpc.xml
new file mode 100644
index 00000000000..6f843966576
--- /dev/null
+++ b/docs/tmp/en-US/xml/remove-vpc.xml
@@ -0,0 +1,99 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Editing, Restarting, and Removing a Virtual Private Cloud
+
+
+ Ensure that all the tiers are removed before you remove a VPC.
+
+
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+
+
+
+ In the left navigation, choose Network.
+
+
+
+
+
+ In the Select view, select VPC.
+
+
+ All the VPCs that you have created for the account is listed in the page.
+
+
+
+
+
+ Select the VPC you want to work with.
+
+
+
+
+
+ To remove, click the Remove VPC button
+
+
+
+
+
+ remove-vpc.png: button to remove a VPC
+
+
+
+
+
+ You can edit the name and description of a VPC. To do that, select the VPC, then click the Edit button.
+
+
+
+
+
+ edit-icon.png: button to edit a VPC
+
+
+
+
+
+ To restart a VPC, select the VPC, then click the Restart button.
+
+
+
+
+
+ restart-vpc.png: button to restart a VPC
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/removed-API-commands.xml b/docs/tmp/en-US/xml/removed-API-commands.xml
new file mode 100644
index 00000000000..5f540d16cb8
--- /dev/null
+++ b/docs/tmp/en-US/xml/removed-API-commands.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Removed API commands
+
+
+
+ createConfiguration (Adds configuration value)
+
+
+
+
+ configureSimulator (Configures simulator)
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/removing-hosts.xml b/docs/tmp/en-US/xml/removing-hosts.xml
new file mode 100644
index 00000000000..8719796400f
--- /dev/null
+++ b/docs/tmp/en-US/xml/removing-hosts.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Removing Hosts
+
+ Hosts can be removed from the cloud as needed. The procedure to remove a host depends on the hypervisor type.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/removing-vsphere-hosts.xml b/docs/tmp/en-US/xml/removing-vsphere-hosts.xml
new file mode 100644
index 00000000000..7dd85037855
--- /dev/null
+++ b/docs/tmp/en-US/xml/removing-vsphere-hosts.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Removing vSphere Hosts
+
+ To remove this type of host, first place it in maintenance mode, as described in . Then use &PRODUCT; to remove the host. &PRODUCT; will not direct commands to a host that has been removed using &PRODUCT;. However, the host may still exist in the vCenter cluster.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/removing-xenserver-kvm-hosts.xml b/docs/tmp/en-US/xml/removing-xenserver-kvm-hosts.xml
new file mode 100644
index 00000000000..47f01d12b96
--- /dev/null
+++ b/docs/tmp/en-US/xml/removing-xenserver-kvm-hosts.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 .
+
+
+
+
+ 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
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/requirements-templates.xml b/docs/tmp/en-US/xml/requirements-templates.xml
new file mode 100644
index 00000000000..c17b2443fb6
--- /dev/null
+++ b/docs/tmp/en-US/xml/requirements-templates.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Requirements for Templates
+
+
+
+ For XenServer, install PV drivers / Xen tools on each template that you create. This will enable live migration and clean guest shutdown.
+
+
+
+
+ For vSphere, install VMware Tools on each template that you create. This will enable console view to work properly.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/resizing-volumes.xml b/docs/tmp/en-US/xml/resizing-volumes.xml
new file mode 100644
index 00000000000..83434c66aa3
--- /dev/null
+++ b/docs/tmp/en-US/xml/resizing-volumes.xml
@@ -0,0 +1,65 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Resizing Volumes
+
+ &PRODUCT; does not provide the ability to resize root disks or data disks; the disk size is fixed based on the template used to create the VM. However, the tool VHD Resizer), while not officially supported by Cloud.com or Citrix, might provide a workaround. To increase disk size with VHD Resizer:
+
+
+
+
+ Get the VHD from the secondary storage.
+
+
+
+
+ Import it into VHD Resizer.
+
+
+
+
+ Resize the VHD.
+
+
+
+
+ Upload the new VHD.
+
+
+
+
+ Create a new VM.
+
+
+
+
+ Take a snapshot, then create a new template from that snapshot.
+
+
+ For more information, see How to Resize a Provisioning Server 5 Virtual Disk at the Citrix Knowledge Center
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/response-formats.xml b/docs/tmp/en-US/xml/response-formats.xml
new file mode 100644
index 00000000000..015348fec1d
--- /dev/null
+++ b/docs/tmp/en-US/xml/response-formats.xml
@@ -0,0 +1,63 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Response Formats: XML and JSON
+
+ CloudStack supports two formats as the response to an API call. The default response is XML. If you would like the response to be in JSON, add &response=json to the Command String.
+
+
+ Sample XML Response:
+
+
+
+ <listipaddressesresponse>
+ <allocatedipaddress>
+ <ipaddress>192.168.10.141</ipaddress>
+ <allocated>2009-09-18T13:16:10-0700</allocated>
+ <zoneid>4</zoneid>
+ <zonename>WC</zonename>
+ <issourcenat>true</issourcenat>
+ </allocatedipaddress>
+ </listipaddressesresponse>
+
+
+ Sample JSON Response:
+
+
+
+ { "listipaddressesresponse" :
+ { "allocatedipaddress" :
+ [
+ {
+ "ipaddress" : "192.168.10.141",
+ "allocated" : "2009-09-18T13:16:10-0700",
+ "zoneid" : "4",
+ "zonename" : "WC",
+ "issourcenat" : "true"
+ }
+ ]
+ }
+ }
+
+
+
+
diff --git a/docs/tmp/en-US/xml/responses.xml b/docs/tmp/en-US/xml/responses.xml
new file mode 100644
index 00000000000..cde1e77efcc
--- /dev/null
+++ b/docs/tmp/en-US/xml/responses.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Responses
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/roles.xml b/docs/tmp/en-US/xml/roles.xml
new file mode 100644
index 00000000000..24acb772080
--- /dev/null
+++ b/docs/tmp/en-US/xml/roles.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Roles
+
+ The CloudPlatform API supports three access roles:
+
+
+
+
+ Root Admin. Access to all features of the cloud, including both virtual and physical resource management.
+
+
+
+
+ Domain Admin. Access to only the virtual resources of the clouds that belong to the administrator’s domain.
+
+
+
+
+ User. Access to only the features that allow management of the user’s virtual instances, storage, and network.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/root-admin-ui-overview.xml b/docs/tmp/en-US/xml/root-admin-ui-overview.xml
new file mode 100644
index 00000000000..ae3ec641305
--- /dev/null
+++ b/docs/tmp/en-US/xml/root-admin-ui-overview.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Root Administrator's UI Overview
+
+ The &PRODUCT; UI helps the &PRODUCT; 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/runtime-allocation-virtual-network-resources.xml b/docs/tmp/en-US/xml/runtime-allocation-virtual-network-resources.xml
new file mode 100644
index 00000000000..10c206df7bc
--- /dev/null
+++ b/docs/tmp/en-US/xml/runtime-allocation-virtual-network-resources.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Runtime Allocation of Virtual Network Resources
+
+ When you define a new virtual network, all your settings for that network are stored in &PRODUCT;. The actual network resources are activated only when the first virtual machine starts in the network. When all virtual machines have left the virtual network, the network resources are garbage collected so they can be allocated again. This helps to conserve network resources..
+
+
+
+
diff --git a/docs/tmp/en-US/xml/runtime-behavior-of-primary-storage.xml b/docs/tmp/en-US/xml/runtime-behavior-of-primary-storage.xml
new file mode 100644
index 00000000000..1b80c5613b2
--- /dev/null
+++ b/docs/tmp/en-US/xml/runtime-behavior-of-primary-storage.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Runtime Behavior of Primary Storage
+
+ Root volumes are created automatically when a virtual machine is created. Root volumes are deleted when the VM is destroyed. Data volumes can be created and dynamically attached to VMs. Data volumes are not deleted when VMs are destroyed.
+
+
+ Administrators should monitor the capacity of primary storage devices and add additional primary storage as needed. See the Advanced Installation Guide.
+
+
+ Administrators add primary storage to the system by creating a &PRODUCT; storage pool. Each storage pool is associated with a cluster.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/runtime-internal-comm-req.xml b/docs/tmp/en-US/xml/runtime-internal-comm-req.xml
new file mode 100644
index 00000000000..fb7d1f53710
--- /dev/null
+++ b/docs/tmp/en-US/xml/runtime-internal-comm-req.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Runtime Internal Communications Requirements
+
+
+
+ The Management Servers communicate with each other to coordinate tasks. This communication uses TCP on ports 8250 and 9090.
+
+
+
+
+
+ The console proxy VMs connect to all hosts in the zone over the management traffic network. Therefore the management traffic network of any given pod in the zone must have connectivity to the management traffic network of all other pods in the zone.
+
+
+
+
+
+ The secondary storage VMs and console proxy VMs connect to the Management Server on port 8250. If you are using multiple Management Servers, the load balanced IP address of the Management Servers on port 8250 must be reachable.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/scheduled-maintenance-maintenance-mode-hosts.xml b/docs/tmp/en-US/xml/scheduled-maintenance-maintenance-mode-hosts.xml
new file mode 100644
index 00000000000..8fd44668fa6
--- /dev/null
+++ b/docs/tmp/en-US/xml/scheduled-maintenance-maintenance-mode-hosts.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/search-base.xml b/docs/tmp/en-US/xml/search-base.xml
new file mode 100644
index 00000000000..66868382d0d
--- /dev/null
+++ b/docs/tmp/en-US/xml/search-base.xml
@@ -0,0 +1,81 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/search-user-bind-dn.xml b/docs/tmp/en-US/xml/search-user-bind-dn.xml
new file mode 100644
index 00000000000..e2d508fa526
--- /dev/null
+++ b/docs/tmp/en-US/xml/search-user-bind-dn.xml
@@ -0,0 +1,79 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; 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
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/secondary-storage-add.xml b/docs/tmp/en-US/xml/secondary-storage-add.xml
new file mode 100644
index 00000000000..0cd81f2debb
--- /dev/null
+++ b/docs/tmp/en-US/xml/secondary-storage-add.xml
@@ -0,0 +1,95 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Add Secondary Storage
+
+ System Requirements for Secondary Storage
+
+
+
+ NFS storage appliance or Linux NFS server
+
+
+
+
+ (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org)
+
+
+
+
+ 100GB minimum capacity
+
+
+
+
+ A secondary storage device must be located in the same zone as the guest VMs it serves.
+
+
+
+
+ Each Secondary Storage server must be available to all hosts in the zone.
+
+
+
+
+
+
+
+
+ Adding Secondary Storage
+
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+
+
+
+ Be sure there is nothing stored on the server. Adding the server to &PRODUCT; will destroy any existing data.
+
+
+
+
+
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to &PRODUCT; before you add the local zone secondary storage servers. See .
+
+
+
+
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See .See Preparing NFS Shares in the Installation Guide.
+
+
+
+
+ Make sure you prepared the system VM template during Management Server installation. See .See Prepare the System VM Template in the Installation Guide.
+
+
+
+
+ Now that the secondary storage server for per-zone storage is prepared, add it to &PRODUCT;. Secondary storage is added as part of the procedure for adding a new zone. See .
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/secondary-storage-outage-and-data-loss.xml b/docs/tmp/en-US/xml/secondary-storage-outage-and-data-loss.xml
new file mode 100644
index 00000000000..10a97c8e996
--- /dev/null
+++ b/docs/tmp/en-US/xml/secondary-storage-outage-and-data-loss.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Secondary Storage Outage and Data Loss
+
+ For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online.
+
+
+ Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/secondary-storage-vm.xml b/docs/tmp/en-US/xml/secondary-storage-vm.xml
new file mode 100644
index 00000000000..f51ed273538
--- /dev/null
+++ b/docs/tmp/en-US/xml/secondary-storage-vm.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Secondary Storage VM
+
+ In addition to the hosts, &PRODUCT;’s Secondary Storage VM mounts and writes to secondary storage.
+
+
+ Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols.
+
+
+ The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups.
+
+
+ The administrator can log in to the secondary storage VM if needed.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/secondary-storage.xml b/docs/tmp/en-US/xml/secondary-storage.xml
new file mode 100644
index 00000000000..c5228539c25
--- /dev/null
+++ b/docs/tmp/en-US/xml/secondary-storage.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Secondary Storage
+
+ This section gives concepts and technical details about &PRODUCT; secondary storage. For information about how to install and configure secondary storage through the &PRODUCT; UI, see the Advanced Installation Guide.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/security-groups.xml b/docs/tmp/en-US/xml/security-groups.xml
new file mode 100644
index 00000000000..8c58f219269
--- /dev/null
+++ b/docs/tmp/en-US/xml/security-groups.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Security Groups
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/security-req.xml b/docs/tmp/en-US/xml/security-req.xml
new file mode 100644
index 00000000000..789f647c8b8
--- /dev/null
+++ b/docs/tmp/en-US/xml/security-req.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Security Requirements
+
+ The public Internet must not be able to access port 8096 or port 8250 on the Management Server.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/send-projects-membership-invitation.xml b/docs/tmp/en-US/xml/send-projects-membership-invitation.xml
new file mode 100644
index 00000000000..f11c7167950
--- /dev/null
+++ b/docs/tmp/en-US/xml/send-projects-membership-invitation.xml
@@ -0,0 +1,85 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 . If the invitations feature is not turned on, use the procedure in Adding Project Members From the UI.
+
+
+
+
+ Log in to the &PRODUCT; 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 &PRODUCT; when accepting the invitation. Email invitations will work only if the global parameters related to the SMTP server have been set. See .
+
+
+
+
+
+
+
+ Type the user name or email address of the new member you want to add, and click Invite. Type the &PRODUCT; 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.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/separate_storage_network.xml b/docs/tmp/en-US/xml/separate_storage_network.xml
new file mode 100644
index 00000000000..3c10bebe662
--- /dev/null
+++ b/docs/tmp/en-US/xml/separate_storage_network.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Separate Storage Network
+
+ In the large-scale redundant setup described in the previous section, storage traffic can overload the management network. A separate storage network is optional for deployments. Storage protocols such as iSCSI are sensitive to network delays. A separate storage network ensures guest network traffic contention does not impact storage performance.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/service-offerings.xml b/docs/tmp/en-US/xml/service-offerings.xml
new file mode 100644
index 00000000000..58a1cddd57a
--- /dev/null
+++ b/docs/tmp/en-US/xml/service-offerings.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Service Offerings
+
+ vCenter Maintenance Mode
+
+
+ XenServer and Maintenance Mode
+
+
+ vCenter Maintenance Mode
+
+
+ XenServer and Maintenance Mode
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-database-buffer-pool-size.xml b/docs/tmp/en-US/xml/set-database-buffer-pool-size.xml
new file mode 100644
index 00000000000..46ebb50c162
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-database-buffer-pool-size.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Set Database Buffer Pool Size
+
+ It is important to provide enough memory space for the MySQL database to cache data and indexes:
+
+
+
+
+ Edit the Tomcat configuration file:
+
+
+/etc/my.cnf
+
+
+
+ Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM.
+
+
+innodb_buffer_pool_size=700M
+
+
+
+ Restart the MySQL service.
+
+
+# service mysqld restart
+
+
+
+
+ For more information about the buffer pool, see "The InnoDB Buffer Pool" at MySQL Reference Manual.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-global-project-resource-limits.xml b/docs/tmp/en-US/xml/set-global-project-resource-limits.xml
new file mode 100644
index 00000000000..00dbc695acc
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-global-project-resource-limits.xml
@@ -0,0 +1,142 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting the Global Project Resource Limits
+
+
+
+ Log in as administrator to the &PRODUCT; 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.
+
+
+# service cloud-management restart
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-monitor-total-vm-limits-per-host.xml b/docs/tmp/en-US/xml/set-monitor-total-vm-limits-per-host.xml
new file mode 100644
index 00000000000..abee1a48b78
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-monitor-total-vm-limits-per-host.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Set and Monitor Total VM Limits per Host
+
+ The &PRODUCT; administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use &PRODUCT; global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the &PRODUCT; UI to disable allocation of more VMs to the cluster.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-per-project-resource-limits.xml b/docs/tmp/en-US/xml/set-per-project-resource-limits.xml
new file mode 100644
index 00000000000..4fe5fd88cf9
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-per-project-resource-limits.xml
@@ -0,0 +1,75 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Per-Project Resource Limits
+
+ The &PRODUCT; 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 &PRODUCT; administrator (as described in ). 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 &PRODUCT; 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.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-projects-creator-permissions.xml b/docs/tmp/en-US/xml/set-projects-creator-permissions.xml
new file mode 100644
index 00000000000..45f0c4f49cd
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-projects-creator-permissions.xml
@@ -0,0 +1,93 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Project Creator Permissions
+
+ You can configure &PRODUCT; to allow any user to create a new project, or you can restrict that ability to just &PRODUCT; administrators.
+
+
+
+
+ Log in as administrator to the &PRODUCT; 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 &PRODUCT; root administrator and domain administrators to create projects.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Restart the Management Server.
+
+
+# service cloud-management restart
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-resource-limits-for-projects.xml b/docs/tmp/en-US/xml/set-resource-limits-for-projects.xml
new file mode 100644
index 00000000000..c96b5b8a9de
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-resource-limits-for-projects.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Resource Limits for Projects
+
+ The &PRODUCT; 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 &PRODUCT; root administrator. The root administrator can also set lower resource limits for any project in the cloud
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-up-invitations.xml b/docs/tmp/en-US/xml/set-up-invitations.xml
new file mode 100644
index 00000000000..ad983f3cb55
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-up-invitations.xml
@@ -0,0 +1,203 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Up Invitations
+
+ &PRODUCT; 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 &PRODUCT; account. If you want administrators to use invitations to add members to projects, turn on and set up the invitations feature in &PRODUCT;.
+
+
+
+
+ Log in as administrator to the &PRODUCT; UI.
+
+
+
+
+ In the left navigation, click Global Settings.
+
+
+
+
+ In the search box, type project and click the search button.
+
+
+
+
+ In the search box, type project and click the search button.
+
+
+
+
+
+ searchbutton.png: Searches projects
+
+
+
+
+
+
+
+ In the search results, you will 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
+
+
+service cloud-management restart
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-up-network-for-users.xml b/docs/tmp/en-US/xml/set-up-network-for-users.xml
new file mode 100644
index 00000000000..54ae1aa7dca
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-up-network-for-users.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Up Networking for Users
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-usage-limit.xml b/docs/tmp/en-US/xml/set-usage-limit.xml
new file mode 100644
index 00000000000..d46d508d2cd
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-usage-limit.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Usage Limits
+
+ &PRODUCT; provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis.
+
+
+ Aggregate limits may be set on a per-domain basis. For example, you may limit a domain and all subdomains to the creation of 100 VMs.
+
+
+ This section covers the following topics:
+
+
+ Globally Configured Limits
+
+
+ Default Account Resource Limits
+
+
+ Per Domain Limits
+
+
+
+
diff --git a/docs/tmp/en-US/xml/set-zone-vlan-run-vm-max.xml b/docs/tmp/en-US/xml/set-zone-vlan-run-vm-max.xml
new file mode 100644
index 00000000000..71ff23fe898
--- /dev/null
+++ b/docs/tmp/en-US/xml/set-zone-vlan-run-vm-max.xml
@@ -0,0 +1,135 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Zone VLAN and Running VM Maximums
+
+ In the external networking case, every VM in a zone must have a unique guest IP address. There are two variables that you need to consider in determining how to configure &PRODUCT; to support this: how many Zone VLANs do you expect to have and how many VMs do you expect to have running in the Zone at any one time.
+
+
+ Use the following table to determine how to configure &PRODUCT; for your deployment.
+
+
+
+
+
+
+
+ guest.vlan.bits
+
+
+
+
+ Maximum Running VMs per Zone
+
+
+
+
+ Maximum Zone VLANs
+
+
+
+
+
+
+
+
+
+
+ 12
+
+
+
+
+ 4096
+
+
+
+
+ 4094
+
+
+
+
+
+
+
+ 11
+
+
+
+
+ 8192
+
+
+
+
+ 2048
+
+
+
+
+
+
+
+ 10
+
+
+
+
+ 16384
+
+
+
+
+ 1024
+
+
+
+
+
+
+
+ 10
+
+
+
+
+ 32768
+
+
+
+
+ 512
+
+
+
+
+
+
+
+
+
+
+
+ Based on your deployment's needs, choose the appropriate value of guest.vlan.bits. Set it as described in Edit the Global Configuration Settings (Optional) section and restart the Management Server.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/shared-networks.xml b/docs/tmp/en-US/xml/shared-networks.xml
new file mode 100644
index 00000000000..cad1d11fc99
--- /dev/null
+++ b/docs/tmp/en-US/xml/shared-networks.xml
@@ -0,0 +1,57 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Shared Networks
+
+ A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in &PRODUCT; 3.0.3).
+
+
+
+
+ Shared Networks are created by the administrator
+
+
+
+
+ Shared Networks can be designated to a certain domain
+
+
+
+
+ Shared Network resources such as VLAN and physical network that it maps to are designated by the administrator
+
+
+
+
+ Shared Networks are isolated by security groups
+
+
+
+
+ Public Network is a shared network that is not shown to the end users
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/signing-api-requests.xml b/docs/tmp/en-US/xml/signing-api-requests.xml
new file mode 100644
index 00000000000..3b85941c80c
--- /dev/null
+++ b/docs/tmp/en-US/xml/signing-api-requests.xml
@@ -0,0 +1,117 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Signing API Requests
+
+ Whether you access the CloudStack API with HTTP or HTTPS, it must still be signed so that CloudStack can verify the caller has been authenticated and authorized to execute the command. Make sure that you have both the API Key and Secret Key provided by the CloudStack administrator for your account before proceeding with the signing process.
+
+
+ To show how to sign a request, we will re-use the previous example.
+
+
+http://http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+ Breaking this down, we have several distinct parts to this URL.
+
+
+
+
+ Base URL: This is the base URL to the CloudStack Management Server.
+
+
+http://localhost:8080
+
+
+
+
+ API Path: This is the path to the API Servlet that processes the incoming requests.
+
+
+/client/api?
+
+
+
+
+ Command String: This part of the query string comprises of the command, its parameters, and the API Key that identifies the account.
+
+
+
+ As with all query string parameters of field-value pairs, the "field" component is case insensitive while all "value" values are case sensitive.
+
+
+
+command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ
+
+
+
+
+ Signature: This is the hashed signature of the Base URL that is generated using a combination of the user’s Secret Key and the HMAC SHA-1 hashing algorithm.
+
+
+ &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+
+
+
+
+
+ Every API request has the format Base URL+API Path+Command String+Signature.
+
+
+ To generate the signature.
+
+
+
+
+ For each field-value pair (as separated by a '&') in the Command String, URL encode each value so that it can be safely sent via HTTP GET.
+
+
+
+ Make sure all spaces are encoded as "%20" rather than "+".
+
+
+
+
+
+
+ Lower case the entire Command String and sort it alphabetically via the field for each field-value pair. The result of this step would look like the following.
+
+
+apikey=mivr6x7u6bn_sdahobpjnejpgest35exq-jb8cg20yi3yaxxcgpyuairmfi_ejtvwz0nukkjbpmy3y2bcikwfq&command=deployvirtualmachine&diskofferingid=1&serviceofferingid=1&templateid=2&zoneid=4
+
+
+
+
+ Take the sorted Command String and run it through the HMAC SHA-1 hashing algorithm (most programming languages offer a utility method to do this) with the user’s Secret Key. Base64 encode the resulting byte array in UTF-8 so that it can be safely transmitted via HTTP. The final string produced after Base64 encoding should be "Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D".
+
+
+ By reconstructing the final URL in the format Base URL+API Path+Command String+Signature, the final URL should look like:
+
+
+http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/site-to-site-vpn.xml b/docs/tmp/en-US/xml/site-to-site-vpn.xml
new file mode 100644
index 00000000000..01c655d5f91
--- /dev/null
+++ b/docs/tmp/en-US/xml/site-to-site-vpn.xml
@@ -0,0 +1,88 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Setting Up a Site-to-Site VPN Connection
+
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
+
+
+ The supported endpoints on the remote datacenters are:
+
+
+
+
+ Cisco ISR with IOS 12.4 or later
+
+
+
+
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
+
+
+
+
+
+
+ In addition to the specific Cisco and Juniper devices listed above, the expectation is that any Cisco or Juniper device running on the supported operating systems are able to establish VPN connections.
+
+
+
+
+ To set up a Site-to-Site VPN connection, perform the following:
+
+
+
+
+ Create a Virtual Private Cloud (VPC).
+
+
+ See .
+
+
+
+
+
+ Create a VPN Customer Gateway.
+
+
+
+
+
+ Create a VPN gateway for the VPC that you created.
+
+
+
+
+
+ Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/small_scale_deployment.xml b/docs/tmp/en-US/xml/small_scale_deployment.xml
new file mode 100644
index 00000000000..14e7ff1aee6
--- /dev/null
+++ b/docs/tmp/en-US/xml/small_scale_deployment.xml
@@ -0,0 +1,59 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Small-Scale Deployment
+
+
+
+
+
+ Small-Scale Deployment
+
+
+
+
+ This diagram illustrates the network architecture of a small-scale &PRODUCT; deployment.
+
+
+
+
+ A firewall provides a connection to the Internet. The firewall is configured in NAT mode. The firewall forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+
+
+
+
+ A layer-2 switch connects all physical servers and storage.
+
+
+
+
+ A single NFS server functions as both the primary and secondary storage.
+
+
+
+
+ The Management Server is connected to the management network.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/snapshot-restore.xml b/docs/tmp/en-US/xml/snapshot-restore.xml
new file mode 100644
index 00000000000..0d13ea29ca3
--- /dev/null
+++ b/docs/tmp/en-US/xml/snapshot-restore.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Snapshot Restore
+
+ There are two paths to restoring snapshots. Users can create a volume from the snapshot. The volume can then be mounted to a VM and files recovered as needed. Alternatively, a template may be created from the snapshot of a root disk. The user can then boot a VM from this template to effect recovery of the root disk.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/source-prereqs.xml b/docs/tmp/en-US/xml/source-prereqs.xml
new file mode 100644
index 00000000000..8a5af508add
--- /dev/null
+++ b/docs/tmp/en-US/xml/source-prereqs.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Prerequisites for building Apache CloudStack
+
+ There are a number of prerequisites needed to build &PRODUCT;. This document assumes compilation on a Linux system that uses RPMs or DEBs for package management.
+
+
+ The minimum bootstrapped prerequisites for building &PRODUCT; includes the following:
+
+
+
+ ant
+
+
+
+
+ maven (version 3)
+
+
+
+
+ Java (Java 6/OpenJDK 1.6)
+
+
+
+
+ rpmbuild or dpkg-dev
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/source.xml b/docs/tmp/en-US/xml/source.xml
new file mode 100644
index 00000000000..18e4b7f5a12
--- /dev/null
+++ b/docs/tmp/en-US/xml/source.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Building from Source
+
+ The official &PRODUCT; release is always in source code form. While there may exist convenience binaries in various forms from a number of places, the source is the canonical release will be source. In this document we'll cover acquiring the source release, building that into binary, deployable packages.
+
+
+ While building and deploying directly from source is certainly possible, the reality of Infrastructure-as-a-Service cloud computing implies a need to deploy packages on a potentially large number of systems, which RPMs and DEBs fill nicely.
+
+
+ Building and deploying directly from source is thus outside the scope of this document, but is documented in the INSTALL.md file in the release.
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/standard-events.xml b/docs/tmp/en-US/xml/standard-events.xml
new file mode 100644
index 00000000000..2791f9f1adc
--- /dev/null
+++ b/docs/tmp/en-US/xml/standard-events.xml
@@ -0,0 +1,66 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/static-nat.xml b/docs/tmp/en-US/xml/static-nat.xml
new file mode 100644
index 00000000000..589203366b2
--- /dev/null
+++ b/docs/tmp/en-US/xml/static-nat.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Static NAT
+
+ A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/sticky-session-policies-for-lb-rules.xml b/docs/tmp/en-US/xml/sticky-session-policies-for-lb-rules.xml
new file mode 100644
index 00000000000..626193a8114
--- /dev/null
+++ b/docs/tmp/en-US/xml/sticky-session-policies-for-lb-rules.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Sticky Session Policies for Load Balancer Rules
+
+ Sticky sessions are used in Web-based applications to ensure continued availability of information across the multiple requests in a user's session. For example, if a shopper is filling a cart, you need to remember what has been purchased so far. The concept of "stickiness" is also referred to as persistence or maintaining state.
+
+
+ Any load balancer rule defined in &PRODUCT; can have a stickiness policy. The policy consists of a name, stickiness method, and parameters. The parameters are name-value pairs or flags, which are defined by the load balancer vendor. The stickiness method could be load balancer-generated cookie, application-generated cookie, or source-based. In the source-based method, the source IP address is used to identify the user and locate the user’s stored data. In the other methods, cookies are used. The cookie generated by the load balancer or application is included in request and response URLs to create persistence. The cookie name can be specified by the administrator or automatically generated. A variety of options are provided to control the exact behavior of cookies, such as how they are generated and whether they are cached.
+
+
+ For the most up to date list of available stickiness methods, see the &PRODUCT; UI or call listNetworks and check the SupportedStickinessMethods capability.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/stop-restart-management-server.xml b/docs/tmp/en-US/xml/stop-restart-management-server.xml
new file mode 100644
index 00000000000..cba47a5811d
--- /dev/null
+++ b/docs/tmp/en-US/xml/stop-restart-management-server.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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:
+
+
+# service cloud-management stop
+
+ To start the Management Server:
+
+
+# service cloud-management start
+
+ To stop the Management Server:
+
+
+# service cloud-management stop
+
+
+
diff --git a/docs/tmp/en-US/xml/stopped-vm.xml b/docs/tmp/en-US/xml/stopped-vm.xml
new file mode 100644
index 00000000000..2a94e162cc7
--- /dev/null
+++ b/docs/tmp/en-US/xml/stopped-vm.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Stopped VM
+
+ &PRODUCT; now supports creating a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A VM can now be deployed in two ways: create and start a VM (the default method); or create a VM and leave it in the stopped state.
+
+
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature.
+
+
+ The possible values are:
+
+
+
+
+ true - The VM starts as a part of the VM deployment.
+
+
+
+
+ false - The VM is left in the stopped state at the end of the VM deployment.
+
+
+
+
+
+ The default value is true.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/stopping-and-starting-vms.xml b/docs/tmp/en-US/xml/stopping-and-starting-vms.xml
new file mode 100644
index 00000000000..bfbf75e1ff9
--- /dev/null
+++ b/docs/tmp/en-US/xml/stopping-and-starting-vms.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Stopping and Starting VMs
+
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/storage-nw-topology-req.xml b/docs/tmp/en-US/xml/storage-nw-topology-req.xml
new file mode 100644
index 00000000000..ff55ab08e71
--- /dev/null
+++ b/docs/tmp/en-US/xml/storage-nw-topology-req.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Storage Network Topology Requirements
+
+ The secondary storage NFS export is mounted by the secondary storage VM. Secondary storage traffic goes over the management traffic network, even if there is a separate storage network. Primary storage traffic goes over the storage network, if available. If you choose to place secondary storage NFS servers on the storage network, you must make sure there is a route from the management traffic network to the storage network.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/storage-overview.xml b/docs/tmp/en-US/xml/storage-overview.xml
new file mode 100644
index 00000000000..aa799642465
--- /dev/null
+++ b/docs/tmp/en-US/xml/storage-overview.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Storage Overview
+
+ &PRODUCT; defines two types of storage: primary and secondary. Primary storage can be accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary storage. Secondary storage is always accessed using NFS.
+
+
+ There is no ephemeral storage in &PRODUCT;. All volumes on all nodes are persistent.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/storage-tags.xml b/docs/tmp/en-US/xml/storage-tags.xml
new file mode 100644
index 00000000000..7a8c4657885
--- /dev/null
+++ b/docs/tmp/en-US/xml/storage-tags.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Storage Tags
+
+ Storage may be "tagged". A tag is a text string attribute associated with primary storage, a Disk Offering, or a Service Offering. Tags allow administrators to provide additional information about the storage. For example, that is a "SSD" or it is "slow". Tags are not interpreted by &PRODUCT;. They are matched against tags placed on service and disk offerings. &PRODUCT; requires all tags on service and disk offerings to exist on the primary storage before it allocates root or data disks on the primary storage. Service and disk offering tags are used to identify the requirements of the storage that those offerings have. For example, the high end service offering may require "fast" for its root disk volume.
+
+
+ The interaction between tags, allocation, and volume copying across clusters and pods can be complex. To simplify the situation, use the same set of tags on the primary storage for all clusters in a pod. Even if different devices are used to present those tags, the set of exposed tags can be the same.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/storage.xml b/docs/tmp/en-US/xml/storage.xml
new file mode 100644
index 00000000000..44fe0d6e333
--- /dev/null
+++ b/docs/tmp/en-US/xml/storage.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Working With Storage
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/suspend-project.xml b/docs/tmp/en-US/xml/suspend-project.xml
new file mode 100644
index 00000000000..c6904b52ace
--- /dev/null
+++ b/docs/tmp/en-US/xml/suspend-project.xml
@@ -0,0 +1,87 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; root administrator.
+
+
+
+
+ Log in to the &PRODUCT; 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
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/sys-reliability-and-ha.xml b/docs/tmp/en-US/xml/sys-reliability-and-ha.xml
new file mode 100644
index 00000000000..8ff51a23d1d
--- /dev/null
+++ b/docs/tmp/en-US/xml/sys-reliability-and-ha.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ System Reliability and High Availability
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/sysprep-for-windows-server-2003R2.xml b/docs/tmp/en-US/xml/sysprep-for-windows-server-2003R2.xml
new file mode 100644
index 00000000000..97eed88ddd4
--- /dev/null
+++ b/docs/tmp/en-US/xml/sysprep-for-windows-server-2003R2.xml
@@ -0,0 +1,156 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Sysprep for Windows Server 2003 R2
+
+ Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2.
+
+
+
+
+ Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM.
+
+
+
+
+ Run c:\sysprep\setupmgr.exe to create the sysprep.inf file.
+
+
+
+
+ Select Create New to create a new Answer File.
+
+
+
+
+ Enter “Sysprep setup” for the Type of Setup.
+
+
+
+
+ Select the appropriate OS version and edition.
+
+
+
+
+ On the License Agreement screen, select “Yes fully automate the installation”.
+
+
+
+
+ Provide your name and organization.
+
+
+
+
+ Leave display settings at default.
+
+
+
+
+ Set the appropriate time zone.
+
+
+
+
+ Provide your product key.
+
+
+
+
+ Select an appropriate license mode for your deployment
+
+
+
+
+ Select “Automatically generate computer name”.
+
+
+
+
+ Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up.
+
+
+
+
+ Leave Network Components at “Typical Settings”.
+
+
+
+
+ Select the “WORKGROUP” option.
+
+
+
+
+ Leave Telephony options at default.
+
+
+
+
+ Select appropriate Regional Settings.
+
+
+
+
+ Select appropriate language settings.
+
+
+
+
+ Do not install printers.
+
+
+
+
+ Do not specify “Run Once commands”.
+
+
+
+
+ You need not specify an identification string.
+
+
+
+
+ Save the Answer File as c:\sysprep\sysprep.inf.
+
+
+
+
+
+
+
+
+ Run the following command to sysprep the image:
+
+
+c:\sysprep\sysprep.exe -reseal -mini -activated
+
+ After this step the machine will automatically shut down
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/sysprep-windows-server-2008R2.xml b/docs/tmp/en-US/xml/sysprep-windows-server-2008R2.xml
new file mode 100644
index 00000000000..df201e6bdf6
--- /dev/null
+++ b/docs/tmp/en-US/xml/sysprep-windows-server-2008R2.xml
@@ -0,0 +1,160 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ System Preparation for Windows Server 2008 R2
+
+ For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location:
+
+
+ Microsoft Download Center.
+
+
+ Use the following steps to run sysprep for Windows 2008 R2:
+
+
+
+ The steps outlined here are derived from the excellent guide by Charity Shelbourne, originally published at Windows Server 2008 Sysprep Mini-Setup
+
+
+
+
+
+ Download and install the Windows AIK
+
+
+
+ Windows AIK should not be installed on the Windows 2008 R2 VM you just created. Windows AIK should not be part of the template you create. It is only used to create the sysprep answer file.
+
+
+
+
+
+ Copy the install.wim file in the \sources directory of the Windows 2008 R2 installation DVD to the hard disk. This is a very large file and may take a long time to copy. Windows AIK requires the WIM file to be writable.
+
+
+
+
+ Start the Windows System Image Manager, which is part of the Windows AIK.
+
+
+
+
+ In the Windows Image pane, right click “Select a Windows image or catalog file” to load the install.wim file you just copied.
+
+
+
+
+ Select the Windows 2008 R2 Edition
+
+
+ You may be prompted with a warning that the catalog file cannot be opened. Click Yes to create a new catalog file.
+
+
+
+
+ In the Answer File pane, right click to create a new answer file.
+
+
+
+
+ Generate the answer file from the Windows System Image Manager using the following steps:
+
+
+
+
+ The first page you need to automate is the Language and Country or Region Selection page. To automate this, expand Components in your Windows Image pane, right-click and add the Microsoft-Windows-International-Core setting to Pass 7 oobeSystem. In your Answer File pane, configure the InputLocale, SystemLocale, UILanguage, and UserLocale with the appropriate settings for your language and country or region. Should you have a question about any of these settings, you can right-click on the specific setting and select Help. This will open the appropriate CHM help file with more information, including examples on the setting you are attempting to configure.
+
+
+
+
+
+
+ sysmanager.png: System Image Manager
+
+
+
+
+
+
+ You need to automate the Software License Terms Selection page, otherwise known as the End-User License Agreement (EULA). To do this, expand the Microsoft-Windows-Shell-Setup component. High-light the OOBE setting, and add the setting to the Pass 7 oobeSystem. In Settings, set HideEULAPage true.
+
+
+
+
+
+
+ software-license.png: Depicts hiding the EULA page.
+
+
+
+
+
+
+ Make sure the license key is properly set. If you use MAK key, you can just enter the MAK key on the Windows 2008 R2 VM. You need not input the MAK into the Windows System Image Manager. If you use KMS host for activation you need not enter the Product Key. Details of Windows Volume Activation can be found at
+
+
+
+
+ You need to automate is the Change Administrator Password page. Expand the Microsoft-Windows-Shell-Setup component (if it is not still expanded), expand UserAccounts, right-click on AdministratorPassword, and add the setting to the Pass 7 oobeSystem configuration pass of your answer file. Under Settings, specify a password next to Value.
+
+
+
+
+
+
+ change-admin-password.png: Depicts changing the administrator password
+
+
+
+
+ You may read the AIK documentation and set many more options that suit your deployment. The steps above are the minimum needed to make Windows unattended setup work.
+
+
+
+
+
+
+ Save the answer file as unattend.xml. You can ignore the warning messages that appear in the validation window.
+
+
+
+
+ Copy the unattend.xml file into the c:\windows\system32\sysprep directory of the Windows 2008 R2 Virtual Machine
+
+
+
+
+ Once you place the unattend.xml file in c:\windows\system32\sysprep directory, you run the sysprep tool as follows:
+
+
+cd c:\Windows\System32\sysprep
+sysprep.exe /oobe /generalize /shutdown
+
+
+ The Windows 2008 R2 VM will automatically shut down after sysprep is complete.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/system-reserved-ip-addresses.xml b/docs/tmp/en-US/xml/system-reserved-ip-addresses.xml
new file mode 100644
index 00000000000..ae842e8dd20
--- /dev/null
+++ b/docs/tmp/en-US/xml/system-reserved-ip-addresses.xml
@@ -0,0 +1,72 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ System Reserved IP Addresses
+
+ In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the &PRODUCT; Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
+
+
+ The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone.
+
+
+ The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in.
+
+
+ Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. &PRODUCT; can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
+
+
+ In all zones:
+
+
+ Provide private IPs for the system in each pod and provision them in &PRODUCT;.
+
+
+ For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.
+
+
+ In a zone that uses advanced networking:
+
+
+ For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required &PRODUCT; System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.
+
+
+ When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
+
+
+ To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:
+
+
+
+
+ Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than 4,000 IP addresses.
+
+
+
+
+ Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod has 255 IPs, this will provide 2,550 IP addresses.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/system-service-offerings.xml b/docs/tmp/en-US/xml/system-service-offerings.xml
new file mode 100644
index 00000000000..1b37b92be1a
--- /dev/null
+++ b/docs/tmp/en-US/xml/system-service-offerings.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ System Service Offerings
+
+ System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the &PRODUCT; root administrator. &PRODUCT; provides default system service offerings. The &PRODUCT; root administrator can create additional custom system service offerings.
+
+
+ When &PRODUCT; creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/system-vm-template.xml b/docs/tmp/en-US/xml/system-vm-template.xml
new file mode 100644
index 00000000000..f399872fa7c
--- /dev/null
+++ b/docs/tmp/en-US/xml/system-vm-template.xml
@@ -0,0 +1,67 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ The System VM Template
+
+ The System VMs come from a single template. The System VM has the following characteristics:
+
+
+
+
+ Debian 6.0 ("Squeeze"), 2.6.32 kernel with the latest security patches from the Debian security APT repository
+
+
+
+
+ Has a minimal set of packages installed thereby reducing the attack surface
+
+
+
+
+ 32-bit for enhanced performance on Xen/VMWare
+
+
+
+
+ pvops kernel with Xen PV drivers, KVM virtio drivers, and VMware tools for optimum performance on all hypervisors
+
+
+
+
+ Xen tools inclusion allows performance monitoring
+
+
+
+
+ Latest versions of HAProxy, iptables, IPsec, and Apache from debian repository ensures improved security and speed
+
+
+
+
+ Latest version of JRE from Sun/Oracle ensures improved security and speed
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/tagging-resources.xml b/docs/tmp/en-US/xml/tagging-resources.xml
new file mode 100644
index 00000000000..a3fd97a2f0c
--- /dev/null
+++ b/docs/tmp/en-US/xml/tagging-resources.xml
@@ -0,0 +1,126 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 &PRODUCT; 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:
+
+
+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
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/template-iso-snapshot-usage-record-format.xml b/docs/tmp/en-US/xml/template-iso-snapshot-usage-record-format.xml
new file mode 100644
index 00000000000..b4ee12d8622
--- /dev/null
+++ b/docs/tmp/en-US/xml/template-iso-snapshot-usage-record-format.xml
@@ -0,0 +1,94 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Template, ISO, and Snapshot Usage Record Format
+
+
+
+ account – name of the account
+
+
+
+
+ accountid – ID of the account
+
+
+
+
+ domainid – ID of the domain in which this account resides
+
+
+
+
+ zoneid – Zone where the usage occurred
+
+
+
+
+ description – A string describing what the usage record is tracking
+
+
+
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+
+
+
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+
+
+
+ rawusage – A number representing the actual usage in hours
+
+
+
+
+ usageid – The ID of the the template, ISO, or snapshot
+
+
+
+
+ offeringid – The ID of the disk offering
+
+
+
+
+ templateid – – Included only for templates (usage type 7). Source template ID.
+
+
+
+
+ size – Size of the template, ISO, or snapshot
+
+
+
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/templates.xml b/docs/tmp/en-US/xml/templates.xml
new file mode 100644
index 00000000000..36820150faf
--- /dev/null
+++ b/docs/tmp/en-US/xml/templates.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Templates
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/time-zones.xml b/docs/tmp/en-US/xml/time-zones.xml
new file mode 100644
index 00000000000..1249bc52916
--- /dev/null
+++ b/docs/tmp/en-US/xml/time-zones.xml
@@ -0,0 +1,399 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Time Zones
+
+ The following time zone identifiers are accepted by &PRODUCT;. 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/topology-req.xml b/docs/tmp/en-US/xml/topology-req.xml
new file mode 100644
index 00000000000..1221483bf28
--- /dev/null
+++ b/docs/tmp/en-US/xml/topology-req.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Topology Requirements
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/trial-installation.xml b/docs/tmp/en-US/xml/trial-installation.xml
new file mode 100644
index 00000000000..d94e159508c
--- /dev/null
+++ b/docs/tmp/en-US/xml/trial-installation.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Trial Installation
+
+ Coming soon.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/troubleshooting-alerts.xml b/docs/tmp/en-US/xml/troubleshooting-alerts.xml
new file mode 100644
index 00000000000..59148ca76a4
--- /dev/null
+++ b/docs/tmp/en-US/xml/troubleshooting-alerts.xml
@@ -0,0 +1,59 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Alerts
+
+ The following is the list of alert type numbers.
+
+
+
+MEMORY = 0
+CPU = 1
+STORAGE =2
+STORAGE_ALLOCATED = 3
+PUBLIC_IP = 4
+PRIVATE_IP = 5
+HOST = 6
+USERVM = 7
+DOMAIN_ROUTER = 8
+CONSOLE_PROXY = 9
+ROUTING = 10// lost connection to default route (to the gateway)
+STORAGE_MISC = 11 // lost connection to default route (to the gateway)
+USAGE_SERVER = 12 // lost connection to default route (to the gateway)
+MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)
+DOMAIN_ROUTER_MIGRATE = 14
+CONSOLE_PROXY_MIGRATE = 15
+USERVM_MIGRATE = 16
+VLAN = 17
+SSVM = 18
+USAGE_SERVER_RESULT = 19
+STORAGE_DELETE = 20;
+UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource count
+USAGE_SANITY_RESULT = 22;
+DIRECT_ATTACHED_PUBLIC_IP = 23;
+LOCAL_STORAGE = 24;
+RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/troubleshooting-dataloss-on-exported-primary-storage.xml b/docs/tmp/en-US/xml/troubleshooting-dataloss-on-exported-primary-storage.xml
new file mode 100644
index 00000000000..dea2aa974d0
--- /dev/null
+++ b/docs/tmp/en-US/xml/troubleshooting-dataloss-on-exported-primary-storage.xml
@@ -0,0 +1,59 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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:
+
+
+
+
+echo “/export 192.168.1.0/24(rw,async,no_root_squash)” > /etc/exports
+
+ Adjust the above command to suit your deployment needs.
+
+
+ More Information
+
+ See the export procedure in the "Secondary Storage" section of the &PRODUCT; Installation Guide
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/troubleshooting-lb-rules-fails.xml b/docs/tmp/en-US/xml/troubleshooting-lb-rules-fails.xml
new file mode 100644
index 00000000000..d52c8af6e7b
--- /dev/null
+++ b/docs/tmp/en-US/xml/troubleshooting-lb-rules-fails.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 CloudPlatform 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.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/troubleshooting-maintenance-mode-not-working-on-vCenter.xml b/docs/tmp/en-US/xml/troubleshooting-maintenance-mode-not-working-on-vCenter.xml
new file mode 100644
index 00000000000..2518199cff5
--- /dev/null
+++ b/docs/tmp/en-US/xml/troubleshooting-maintenance-mode-not-working-on-vCenter.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Maintenance mode not working on vCenter
+
+ Symptom
+
+ Host was placed in maintenance mode, but still appears live in vCenter.
+
+
+
+
+ Cause
+
+ The CloudPlatform 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
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/troubleshooting-recover-lost-virtual-router.xml b/docs/tmp/en-US/xml/troubleshooting-recover-lost-virtual-router.xml
new file mode 100644
index 00000000000..a3ddc5ea56f
--- /dev/null
+++ b/docs/tmp/en-US/xml/troubleshooting-recover-lost-virtual-router.xml
@@ -0,0 +1,71 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 API Reference.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/troubleshooting-unable-to-deploy-vms.xml b/docs/tmp/en-US/xml/troubleshooting-unable-to-deploy-vms.xml
new file mode 100644
index 00000000000..ce5c9a821ba
--- /dev/null
+++ b/docs/tmp/en-US/xml/troubleshooting-unable-to-deploy-vms.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/troubleshooting-unable-to-power-on-vm.xml b/docs/tmp/en-US/xml/troubleshooting-unable-to-power-on-vm.xml
new file mode 100644
index 00000000000..c23d364773f
--- /dev/null
+++ b/docs/tmp/en-US/xml/troubleshooting-unable-to-power-on-vm.xml
@@ -0,0 +1,68 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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
+
+
+
+
diff --git a/docs/tmp/en-US/xml/troubleshooting-working-with-server-logs.xml b/docs/tmp/en-US/xml/troubleshooting-working-with-server-logs.xml
new file mode 100644
index 00000000000..21ab64c752e
--- /dev/null
+++ b/docs/tmp/en-US/xml/troubleshooting-working-with-server-logs.xml
@@ -0,0 +1,55 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Working with Server Logs
+
+ The &PRODUCT; Management Server logs all web site, middle tier, and database activities for diagnostics purposes in /var/log/cloud/management/. The &PRODUCT; logs a variety of error messages. We recommend this command to find the problematic output in the Management Server log:.
+
+
+
+ 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.
+
+
+
+
+ grep -i -E 'exception|unable|fail|invalid|leak|warn|error' /var/log/cloud/management/management-server.log
+
+
+ The &PRODUCT; 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:
+
+
+
+ 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:
+
+
+
+ grep "job-1076)" management-server.log
+
+
+ The &PRODUCT; Agent Server logs its activities in /var/log/cloud/agent/.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/troubleshooting.xml b/docs/tmp/en-US/xml/troubleshooting.xml
new file mode 100644
index 00000000000..d2899702233
--- /dev/null
+++ b/docs/tmp/en-US/xml/troubleshooting.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Troubleshooting
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/tuning.xml b/docs/tmp/en-US/xml/tuning.xml
new file mode 100644
index 00000000000..2769d09692b
--- /dev/null
+++ b/docs/tmp/en-US/xml/tuning.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Tuning
+
+ This section provides tips on how to improve the performance of your cloud.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/ui.xml b/docs/tmp/en-US/xml/ui.xml
new file mode 100644
index 00000000000..09c600a35c1
--- /dev/null
+++ b/docs/tmp/en-US/xml/ui.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ User Interface
+
+
+
+
diff --git a/docs/tmp/en-US/xml/upgrade-virtual-router-with-service-offering.xml b/docs/tmp/en-US/xml/upgrade-virtual-router-with-service-offering.xml
new file mode 100644
index 00000000000..34e93dccca6
--- /dev/null
+++ b/docs/tmp/en-US/xml/upgrade-virtual-router-with-service-offering.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Upgrading a Virtual Router with System Service Offerings
+
+ When &PRODUCT; creates a virtual router, it uses default settings which are defined in a default system service offering. See . All the virtual routers in a single guest network use the same system service offering. You can upgrade the capabilities of the virtual router by creating and applying a custom system service offering.
+
+
+
+
+ Define your custom system service offering. See . In System VM Type, choose Domain Router.
+
+
+
+
+ Associate the system service offering with a network offering. See
+
+
+
+
+ Apply the network offering to the network where you want the virtual routers to use the new system service offering. If this is a new network, follow the steps in Adding an Additional Guest Network on page 66. To change the service offering for existing virtual routers, follow the steps in .
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/upload-existing-volume-to-vm.xml b/docs/tmp/en-US/xml/upload-existing-volume-to-vm.xml
new file mode 100644
index 00000000000..df322dc7fbf
--- /dev/null
+++ b/docs/tmp/en-US/xml/upload-existing-volume-to-vm.xml
@@ -0,0 +1,170 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Uploading an Existing Volume to a Virtual Machine
+
+ Existing data can be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs.
+
+
+ The upload is performed using HTTP. The uploaded volume is placed in the zone's secondary storage
+
+
+ You cannot upload a volume if the preconfigured volume limit has already been reached. The default limit for the cloud is set in the global configuration parameter max.account.volumes, but administrators can also set per-domain limits that are different from the global default. See Setting Usage Limits
+
+
+ To upload a volume:
+
+
+
+
+ (Optional) Create an MD5 hash (checksum) of the disk image file that you are going to upload. After uploading the data disk, &PRODUCT; will use this value to verify that no data corruption has occurred.
+
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or user
+
+
+
+
+ In the left navigation bar, click Storage.
+
+
+
+
+ Click Upload Volume.
+
+
+
+
+ Provide the following:
+
+
+
+
+ Name and Description. Any desired name and a brief description that can be shown in the UI.
+
+
+
+
+ Availability Zone. Choose the zone where you want to store the volume. VMs running on hosts in this zone can attach the volume.
+
+
+
+
+ Format. Choose one of the following to indicate the disk image format of the volume.
+
+
+
+
+
+
+
+ Hypervisor
+
+
+
+
+ Disk Image Format
+
+
+
+
+
+
+
+
+
+
+ XenServer
+
+
+
+
+ VHD
+
+
+
+
+
+
+
+ VMware
+
+
+
+
+ OVA
+
+
+
+
+
+
+
+ KVM
+
+
+
+
+ QCOW2
+
+
+
+
+
+
+
+
+
+
+
+
+
+ URL. The secure HTTP or HTTPS URL that &PRODUCT; can use to access your disk. The type of file at the URL must match the value chosen in Format. For example, if Format is VHD, the URL might look like the following:
+
+
+ http://yourFileServerIP/userdata/myDataDisk.vhd
+
+
+
+
+ MD5 checksum. (Optional) Use the hash that you created in step 1.
+
+
+
+
+
+
+
+
+ Wait until the status of the volume shows that the upload is complete. Click Instances - Volumes, find the name you specified in step 5, and make sure the status is Uploaded.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/upload-template.xml b/docs/tmp/en-US/xml/upload-template.xml
new file mode 100644
index 00000000000..dbb493edc95
--- /dev/null
+++ b/docs/tmp/en-US/xml/upload-template.xml
@@ -0,0 +1,128 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Uploading Templates
+
+ vSphere Templates and ISOs
+
+ If you are uploading a template that was created using vSphere Client, be sure the OVA file does not contain an ISO. If it does, the deployment of VMs from the template will fail.
+
+
+
+ Templates are uploaded based on a URL. HTTP is the supported access protocol. Templates are frequently large files. You can optionally gzip them to decrease upload times.
+
+
+ To upload a template:
+
+
+
+
+ In the left navigation bar, click Templates.
+
+
+
+
+ Click Create Template.
+
+
+
+
+ Provide the following:
+
+
+
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+
+
+
+
+ URL. The Management Server will download the file from the specified URL, such as http://my.web.server/filename.vhd.gz.
+
+
+
+
+ Zone. Choose the zone where you want the template to be available, or All Zones to make it available throughout &PRODUCT;.
+
+
+
+
+ OS Type: This helps &PRODUCT; and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following:
+
+
+
+
+ If the operating system of the stopped VM is listed, choose it.
+
+
+
+
+ If the OS type of the stopped VM is not listed, choose Other.
+
+
+
+ You should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+
+
+
+
+
+
+
+
+ Hypervisor
+
+
+
+
+ Format. The format of the template upload file, such as VHD or OVA.
+
+
+
+
+ Password Enabled. Choose Yes if your template has the &PRODUCT; password change script installed. See Adding Password Management to Your Templates
+
+
+
+
+ Extractable. Choose Yes if the template is available for extraction. If this option is selected, end users can download a full image of a template.
+
+
+
+
+ Public. Choose Yes to make this template accessible to all users of this &PRODUCT; installation. The template will appear in the Community Templates list. See
+
+
+
+
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. The template will appear in the Featured Templates list. Only an administrator can make a template Featured.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/usage-record-format.xml b/docs/tmp/en-US/xml/usage-record-format.xml
new file mode 100644
index 00000000000..78ed4547b04
--- /dev/null
+++ b/docs/tmp/en-US/xml/usage-record-format.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Usage Record Format
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/usage-types.xml b/docs/tmp/en-US/xml/usage-types.xml
new file mode 100644
index 00000000000..93000b19ba7
--- /dev/null
+++ b/docs/tmp/en-US/xml/usage-types.xml
@@ -0,0 +1,283 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Usage Types
+
+ The following table shows all usage types.
+
+
+
+
+
+
+
+
+
+ Type ID
+
+
+ Type Name
+
+
+ Description
+
+
+
+
+
+
+
+
+ 1
+
+
+ RUNNING_VM
+
+
+ Tracks the total running time of a VM per usage record period. If the VM is upgraded during the usage period, you will get a separate Usage Record for the new upgraded VM.
+
+
+
+
+
+
+ 2
+
+
+
+
+ ALLOCATED_VM
+
+
+
+
+ Tracks the total time the VM has been created to the time when it has been destroyed. This usage type is also useful in determining usage for specific templates such as Windows-based templates.
+
+
+
+
+
+
+
+ 3
+
+
+
+
+ IP_ADDRESS
+
+
+
+
+ Tracks the public IP address owned by the account.
+
+
+
+
+
+
+
+ 4
+
+
+
+
+ NETWORK_BYTES_SENT
+
+
+
+
+ Tracks the total number of bytes sent by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+
+
+
+
+
+ 5
+
+
+
+
+ NETWORK_BYTES_RECEIVED
+
+
+
+
+ Tracks the total number of bytes received by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+
+
+
+
+
+ 6
+
+
+
+
+ VOLUME
+
+
+
+
+ Tracks the total time a disk volume has been created to the time when it has been destroyed.
+
+
+
+
+
+
+
+ 7
+
+
+
+
+ TEMPLATE
+
+
+
+
+ Tracks the total time a template (either created from a snapshot or uploaded to the cloud) has been created to the time it has been destroyed. The size of the template is also returned.
+
+
+
+
+
+
+
+ 8
+
+
+
+
+ ISO
+
+
+
+
+ Tracks the total time an ISO has been uploaded to the time it has been removed from the cloud. The size of the ISO is also returned.
+
+
+
+
+
+
+
+ 9
+
+
+
+
+ SNAPSHOT
+
+
+
+
+ Tracks the total time from when a snapshot has been created to the time it have been destroyed.
+
+
+
+
+
+
+
+ 11
+
+
+
+
+ LOAD_BALANCER_POLICY
+
+
+
+
+ Tracks the total time a load balancer policy has been created to the time it has been removed. Cloud.com does not track whether a VM has been assigned to a policy.
+
+
+
+
+
+
+
+ 12
+
+
+
+
+ PORT_FORWARDING_RULE
+
+
+
+
+ Tracks the time from when a port forwarding rule was created until the time it was removed.
+
+
+
+
+
+
+
+ 13
+
+
+
+
+ NETWORK_OFFERING
+
+
+
+
+ The time from when a network offering was assigned to a VM until it is removed.
+
+
+
+
+
+
+
+ 14
+
+
+
+
+ VPN_USERS
+
+
+
+
+ The time from when a VPN user is created until it is removed.
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/use-project-view.xml b/docs/tmp/en-US/xml/use-project-view.xml
new file mode 100644
index 00000000000..6ac87501da0
--- /dev/null
+++ b/docs/tmp/en-US/xml/use-project-view.xml
@@ -0,0 +1,61 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using the Project View
+
+ If you are a member of a project, you can use &PRODUCT;’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 &PRODUCT; 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.
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/user-data-and-meta-data.xml b/docs/tmp/en-US/xml/user-data-and-meta-data.xml
new file mode 100644
index 00000000000..183c1abaafb
--- /dev/null
+++ b/docs/tmp/en-US/xml/user-data-and-meta-data.xml
@@ -0,0 +1,91 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ User Data and Meta Data
+
+ &PRODUCT; provides API access to attach 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.
+
+
+# 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
+
+
+# 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
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/user-services-overview.xml b/docs/tmp/en-US/xml/user-services-overview.xml
new file mode 100644
index 00000000000..9099fcc25f3
--- /dev/null
+++ b/docs/tmp/en-US/xml/user-services-overview.xml
@@ -0,0 +1,66 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ User Services Overview
+
+ In addition to the physical and logical infrastructure of your cloud, and the &PRODUCT; software and servers, you also need a layer of user services so that people can actually make use of the cloud. This means not just a user UI, but a set of options and resources that users can choose from, such as templates for creating virtual machines, disk storage, and more. If you are running a commercial service, you will be keeping track of what services and resources users are consuming and charging them for that usage. Even if you do not charge anything for people to use your cloud – say, if the users are strictly internal to your organization, or just friends who are sharing your cloud – you can still keep track of what services they use and how much of them.
+
+
+ Service Offerings, Disk Offerings, Network Offerings, and Templates
+
+ A user creating a new instance can make a variety of choices about its characteristics and capabilities. &PRODUCT; provides several ways to present users with choices when creating a new instance:
+
+
+
+
+ Service Offerings, defined by the &PRODUCT; administrator, provide a choice of CPU speed, number of CPUs, RAM size, tags on the root disk, and other choices. See Creating a New Compute Offering.
+
+
+
+
+
+ Disk Offerings, defined by the &PRODUCT; administrator, provide a choice of disk size for primary data storage. See Creating a New Disk Offering.
+
+
+
+
+
+ Network Offerings, defined by the &PRODUCT; administrator, describe the feature set that is available to end users from the virtual router or external networking devices on a given guest network. See Network Offerings.
+
+
+
+
+
+ Templates, defined by the &PRODUCT; administrator or by any &PRODUCT; user, are the base OS images that the user can choose from when creating a new instance. For example, &PRODUCT; includes CentOS as a template. See Working with Templates.
+
+
+
+
+
+
+ In addition to these choices that are provided for users, there is another type of service offering which is available only to the &PRODUCT; root administrator, and is used for configuring virtual infrastructure resources. For more information, see Upgrading a Virtual Router with System Service Offerings.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/using-multiple-guest-networks.xml b/docs/tmp/en-US/xml/using-multiple-guest-networks.xml
new file mode 100644
index 00000000000..a8389f9fc6a
--- /dev/null
+++ b/docs/tmp/en-US/xml/using-multiple-guest-networks.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using Multiple Guest Networks
+
+ In zones that use advanced networking, additional networks for guest traffic may be added at any time after the initial installation. You can also customize the domain name associated with the network by specifying a DNS suffix for each network.
+
+
+ A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has been created, although the user can go into the guest and remove the IP address from the NIC on a particular network.
+
+
+ Each VM has just one default network. The virtual router's DHCP reply will set the guest's default gateway as that for the default network. Multiple non-default networks may be added to a guest in addition to the single, required default network. The administrator can control which networks are available as the default network.
+
+
+ Additional networks can either be available to all accounts or be assigned to a specific account. Networks that are available to all accounts are zone-wide. Any user with access to the zone can create a VM with access to that network. These zone-wide networks provide little or no isolation between guests.Networks that are assigned to a specific account provide strong isolation.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/using-netscaler-load-balancers.xml b/docs/tmp/en-US/xml/using-netscaler-load-balancers.xml
new file mode 100644
index 00000000000..312aa757d91
--- /dev/null
+++ b/docs/tmp/en-US/xml/using-netscaler-load-balancers.xml
@@ -0,0 +1,122 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Using a NetScaler Load Balancer
+
+ Citrix NetScaler is supported as an external network element for load balancing in zones that use advanced networking (also called advanced zones). Set up an external load balancer when you want to provide load balancing through means other than &PRODUCT;’s provided virtual router.
+
+
+ The NetScaler can be set up in direct (outside the firewall) mode. It must be added before any load balancing rules are deployed on guest VMs in the zone.
+
+
+ The functional behavior of the NetScaler with &PRODUCT; is the same as described in the &PRODUCT; documentation for using an F5 external load balancer. The only exception is that the F5 supports routing domains, and NetScaler does not. NetScaler can not yet be used as a firewall.
+
+
+ The Citrix NetScaler comes in three varieties. The following table summarizes how these variants are treated in &PRODUCT;.
+
+
+
+
+
+
+
+ NetScaler ADC Type
+
+
+
+
+ Description of Capabilities
+
+
+
+
+ &PRODUCT; Supported Features
+
+
+
+
+
+
+
+
+
+
+ MPX
+
+
+
+
+ Physical appliance. Capable of deep packet inspection. Can act as application firewall and load balancer
+
+
+
+
+ In advanced zones, load balancer functionality fully supported without limitation. In basic zones, static NAT, elastic IP (EIP), and elastic load balancing (ELB) are also provided
+
+
+
+
+
+
+
+ VPX
+
+
+
+
+ Virtual appliance. Can run as VM on XenServer, ESXi, and Hyper-V hypervisors. Same functionality as MPX
+
+
+
+
+ Supported only on ESXi. Same functional support as for MPX. &PRODUCT; will treat VPX and MPX as the same device type
+
+
+
+
+
+
+
+ SDX
+
+
+
+
+ Physical appliance. Can create multiple fully isolated VPX instances on a single appliance to support multi-tenant usage
+
+
+
+
+ &PRODUCT; will dynamically provision, configure, and manage the lifecycle of VPX instances on the SDX. Provisioned instances are added into &PRODUCT; automatically – no manual configuration by the administrator is required. Once a VPX instance is added into &PRODUCT;, it is treated the same as a VPX on an ESXi host.
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/using-sshkeys.xml b/docs/tmp/en-US/xml/using-sshkeys.xml
new file mode 100644
index 00000000000..0ceba5d7370
--- /dev/null
+++ b/docs/tmp/en-US/xml/using-sshkeys.xml
@@ -0,0 +1,193 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using SSH Keys for Authentication
+
+ In addition to the username and password authentication, &PRODUCT; 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 Scriptto the instance you have created.
+
+
+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.
+
+
+cp cloud-set-guest-sshkey.in /etc/init.d/
+
+
+
+
+ Give the necessary permissions on the script:
+
+
+chmod +x /etc/init.d/cloud-set-guest-sshkey.in
+
+
+
+
+ Run the script while starting up the operating system:
+
+
+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 &PRODUCT; 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:
+
+
+
+ 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:
+
+
+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:
+
+
+<?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:
+
+
+-----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 . Ensure that you use the same SSH key name that you created at .
+
+
+
+ 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:
+
+
+curl --globoff http://localhost:<port numbet>/?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:
+
+
+ssh -i ~/.ssh/keypair-doc <ip address>
+
+ The -i parameter tells the ssh client to use a ssh key found at ~/.ssh/keypair-doc.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/using-swift-for-secondary-storage.xml b/docs/tmp/en-US/xml/using-swift-for-secondary-storage.xml
new file mode 100644
index 00000000000..39ac0a51cef
--- /dev/null
+++ b/docs/tmp/en-US/xml/using-swift-for-secondary-storage.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using Swift for Secondary Storage
+
+ CloudPlatform supports OpenStack Object Storage ( Swift) for secondary storage. When using Swift, you configure Swift storage for the entire CloudPlatform, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere
+
+
+ Swift storage must be set up before you add NFS secondary storage to zones. This is accomplished through some additional configuration steps on a fresh Management Server installation, before you add the first zone. The procedure is described in Adding a Zone in the Advanced Installation Guide.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/using-vpn-with-mac.xml b/docs/tmp/en-US/xml/using-vpn-with-mac.xml
new file mode 100644
index 00000000000..296f180d290
--- /dev/null
+++ b/docs/tmp/en-US/xml/using-vpn-with-mac.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using VPN with Mac OS X
+
+ In Mac OS X, in Network Preferences - Advanced, make sure Send all traffic over VPN connection is not checked.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/using-vpn-with-windows.xml b/docs/tmp/en-US/xml/using-vpn-with-windows.xml
new file mode 100644
index 00000000000..fa30b1f6a64
--- /dev/null
+++ b/docs/tmp/en-US/xml/using-vpn-with-windows.xml
@@ -0,0 +1,92 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using VPN with Windows
+
+ The procedure to use VPN varies by Windows version. Generally, the user must edit the VPN properties and make sure that the default route is not the VPN. The following steps are for Windows L2TP clients on Windows Vista. The commands should be similar for other Windows versions.
+
+
+
+
+ Log in to the &PRODUCT; UI and click on the source NAT IP for the account. The VPN tab should display the IPsec preshared key. Make a note of this and the source NAT IP. The UI also lists one or more users and their passwords. Choose one of these users, or, if none exists, add a user and password.
+
+
+
+
+ On the Windows box, go to Control Panel, then select Network and Sharing center. Click Setup a connection or network.
+
+
+
+
+ In the next dialog, select No, create a new connection.
+
+
+
+
+ In the next dialog, select Use my Internet Connection (VPN).
+
+
+
+
+ In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check Don't connect now.
+
+
+
+
+ In the next dialog, enter the user name and password selected in step 1.
+
+
+
+
+ Click Create.
+
+
+
+
+ Go back to the Control Panel and click Network Connections to see the new connection. The connection is not active yet.
+
+
+
+
+ Right-click the new connection and select Properties. In the Properties dialog, select the Networking tab.
+
+
+
+
+ In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key. Enter the preshared key from Step 1.
+
+
+
+
+ The connection is ready for activation. Go back to Control Panel -> Network Connections and double-click the created connection.
+
+
+
+
+ Enter the user name and password from Step 1.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vcenter-maintenance-mode.xml b/docs/tmp/en-US/xml/vcenter-maintenance-mode.xml
new file mode 100644
index 00000000000..fcce9118ea4
--- /dev/null
+++ b/docs/tmp/en-US/xml/vcenter-maintenance-mode.xml
@@ -0,0 +1,74 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ vCenter and Maintenance Mode
+
+ To enter maintenance mode on a vCenter host, both vCenter and &PRODUCT; must be used in concert. &PRODUCT; and vCenter have separate maintenance modes that work closely together.
+
+
+
+
+ Place the host into &PRODUCT;'s "scheduled maintenance" mode. This does not invoke the vCenter maintenance mode, but only causes VMs to be migrated off the host
+
+
+ When the &PRODUCT; 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 &PRODUCT; to reactivate it.
+
+
+
+
+ Then use &PRODUCT;'s administrator UI to cancel the &PRODUCT; 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.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/verifying-source.xml b/docs/tmp/en-US/xml/verifying-source.xml
new file mode 100644
index 00000000000..fd944a21182
--- /dev/null
+++ b/docs/tmp/en-US/xml/verifying-source.xml
@@ -0,0 +1,81 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Verifying the downloaded release
+
+ There are a number of mechanisms to check the authenticity and validity of a downloaded release.
+
+
+ Getting the KEYS
+
+ To enable you to verify the GPG signature, you will need to download the KEYS file.
+
+
+ You next need to import those keys, which you can do by running the following command:
+#gpg --import KEYS
+
+
+
+
+
+
+ GPG
+
+ The &PRODUCT; project provides a detached GPG signature of the release. To check the signature, run the following command:
+$gpg --verify apache-cloudstack-4.0.0-incubating-src.tar.bz2.asc
+
+
+
+ If the signature is valid you will see a line of output that contains 'Good signature'.
+
+
+
+
+
+ MD5
+
+ In addition to the cryptographic signature, &PRODUCT; has an MD5 checksum that you can use to verify the download matches the release. You can verify this hash by executing the following command:
+$gpg --print-md MD5 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.md5
+
+
+
+ If this successfully completes you should see no output. If there is any output from them, then there is a difference between the hash you generated locally and the hash that has been pulled from the server.
+
+
+
+
+
+ SHA512
+
+ In addition to the MD5 hash, the &PRODUCT; project provides a SHA512 cryptographic hash to aid in assurance of the validity of the downloaded release. You can verify this hash by executing the following command:
+$gpg --print-md SHA512 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.sha
+
+
+
+ If this command successfully completes you should see no output. If there is any output from them, then there is a difference between the hash you generated locally and the hash that has been pulled from the server.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/virtual-machine-usage-record-format.xml b/docs/tmp/en-US/xml/virtual-machine-usage-record-format.xml
new file mode 100644
index 00000000000..019289e59a2
--- /dev/null
+++ b/docs/tmp/en-US/xml/virtual-machine-usage-record-format.xml
@@ -0,0 +1,107 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Virtual Machine Usage Record Format
+
+ For running and allocated virtual machine usage, the following fields exist in a usage record:
+
+
+
+
+ account – name of the account
+
+
+
+
+ accountid – ID of the account
+
+
+
+
+ domainid – ID of the domain in which this account resides
+
+
+
+
+ zoneid – Zone where the usage occurred
+
+
+
+
+ description – A string describing what the usage record is tracking
+
+
+
+
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for VM running time)
+
+
+
+
+ usagetype – A number representing the usage type (see Usage Types)
+
+
+
+
+ rawusage – A number representing the actual usage in hours
+
+
+
+
+ virtualMachineId – The ID of the virtual machine
+
+
+
+
+ name – The name of the virtual machine
+
+
+
+
+ offeringid – The ID of the service offering
+
+
+
+
+ templateid – The ID of the template or the ID of the parent template. The parent template value is present when the current template was created from a volume.
+
+
+
+
+ usageid – Virtual machine
+
+
+
+
+ type – Hypervisor
+
+
+
+
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/virtual-machines.xml b/docs/tmp/en-US/xml/virtual-machines.xml
new file mode 100644
index 00000000000..1acc489e746
--- /dev/null
+++ b/docs/tmp/en-US/xml/virtual-machines.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Working With Virtual Machines
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/virtual-router.xml b/docs/tmp/en-US/xml/virtual-router.xml
new file mode 100644
index 00000000000..4ecab37a986
--- /dev/null
+++ b/docs/tmp/en-US/xml/virtual-router.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Virtual Router
+
+ The virtual router is a type of System Virtual Machine. The virtual router is one of the most frequently used service providers in &PRODUCT;. The end user has no direct access to the virtual router. Users can ping the virtual router and take actions that affect it (such as setting up port forwarding), but users do not have SSH access into the virtual router.
+
+
+ There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be restarted by administrators, but this will interrupt public network access and other services for end users. A basic test in debugging networking issues is to attempt to ping the virtual router from a guest VM. Some of the characteristics of the virtual router are determined by its associated system service offering.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vlan-allocation-eg.xml b/docs/tmp/en-US/xml/vlan-allocation-eg.xml
new file mode 100644
index 00000000000..3b0a96f0ac1
--- /dev/null
+++ b/docs/tmp/en-US/xml/vlan-allocation-eg.xml
@@ -0,0 +1,162 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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.
+
+
+
+
+ &PRODUCT; software can access this, hypervisors, system VMs.
+
+
+
+
+
+
+
+ 500-599
+
+
+
+
+ VLAN carrying public traffic.
+
+
+
+
+ &PRODUCT; accounts.
+
+
+
+
+
+
+
+ 600-799
+
+
+
+
+ VLANs carrying guest traffic.
+
+
+
+
+ &PRODUCT; accounts. Account-specific VLAN is chosen from this pool.
+
+
+
+
+
+
+
+ 800-899
+
+
+
+
+ VLANs carrying guest traffic.
+
+
+
+
+ &PRODUCT; accounts. Account-specific VLAN chosen by &PRODUCT; admin to assign to that account.
+
+
+
+
+
+
+
+ 900-999
+
+
+
+
+ VLAN carrying guest traffic
+
+
+
+
+ &PRODUCT; accounts. Can be scoped by project, domain, or all accounts.
+
+
+
+
+
+
+
+ greater than 1000
+
+
+
+
+ Reserved for future use
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vlan-provisioning.xml b/docs/tmp/en-US/xml/vlan-provisioning.xml
new file mode 100644
index 00000000000..ca768273598
--- /dev/null
+++ b/docs/tmp/en-US/xml/vlan-provisioning.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ VLAN Provisioning
+
+ &PRODUCT; automatically creates and destroys interfaces bridged to VLANs on the hosts. In general the administrator does not need to manage this process.
+
+
+ &PRODUCT; 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vm-lifecycle.xml b/docs/tmp/en-US/xml/vm-lifecycle.xml
new file mode 100644
index 00000000000..95ddbe79ebc
--- /dev/null
+++ b/docs/tmp/en-US/xml/vm-lifecycle.xml
@@ -0,0 +1,62 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ VM Lifecycle
+
+ Virtual machines can be in the following states:
+
+
+
+
+
+
+ basic-deployment.png: Basic two-machine CloudStack deployment
+
+
+
+
+ Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual machine will be reclaimed by the system. This includes the virtual machine’s IP address.
+
+
+ A stop will attempt to gracefully shut down the operating system, which typically involves terminating all the running applications. If the operation system cannot be stopped, it will be forcefully terminated. This has the same effect as pulling the power cord to a physical machine.
+
+
+ A reboot is a stop followed by a start.
+
+
+ CloudPlatform preserves the state of the virtual machine hard disk until the machine is destroyed.
+
+
+ A running virtual machine may fail because of hardware or network issues. A failed virtual machine is in the down state.
+
+
+ The system places the virtual machine into the down state if it does not receive the heartbeat from the hypervisor for three minutes.
+
+
+ The user can manually restart the virtual machine from the down state.
+
+
+ The system will start the virtual machine from the down state automatically if the virtual machine is marked as HA-enabled.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vm-storage-migration.xml b/docs/tmp/en-US/xml/vm-storage-migration.xml
new file mode 100644
index 00000000000..0edc5fc7f15
--- /dev/null
+++ b/docs/tmp/en-US/xml/vm-storage-migration.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ VM Storage Migration
+
+ Supported in XenServer, KVM, and VMware.
+
+
+
+ This procedure is different from moving disk volumes from one VM to another. See Detaching and Moving Volumes .
+
+
+
+ You can migrate a virtual machine’s root disk volume or any additional data disk volume from one storage pool to another in the same zone.
+
+
+ You can use the storage migration feature to achieve some commonly desired administration goals, such as balancing the load on storage pools and increasing the reliability of virtual machines by moving them away from any storage pool that is experiencing issues.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vmware-install.xml b/docs/tmp/en-US/xml/vmware-install.xml
new file mode 100644
index 00000000000..4356ed51d04
--- /dev/null
+++ b/docs/tmp/en-US/xml/vmware-install.xml
@@ -0,0 +1,1047 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ VMware vSphere Installation and Configuration
+
+ If you want to use the VMware vSphere hypervisor to run guest virtual machines, install vSphere on the host(s) in your cloud.
+
+
+
+ Preparation Checklist for VMware
+
+ For a smoother installation, gather the following information before you start:
+
+
+
+
+ Information listed in
+
+
+
+
+ Information listed in
+
+
+
+
+
+ vCenter Checklist
+
+ You will need the following information about vCenter.
+
+
+
+
+
+
+
+
+
+
+ vCenter Requirement
+
+
+
+
+ Value
+
+
+
+
+ Notes
+
+
+
+
+
+
+
+
+
+
+ vCenter User
+
+
+
+
+
+
+
+
+ This user must have admin privileges.
+
+
+
+
+
+
+
+ vCenter User Password
+
+
+
+
+
+
+
+
+ Password for the above user.
+
+
+
+
+
+
+
+ vCenter Datacenter Name
+
+
+
+
+
+
+
+
+ Name of the datacenter.
+
+
+
+
+
+
+
+ vCenter Cluster Name
+
+
+
+
+
+
+
+
+ Name of the cluster.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Networking Checklist for VMware
+
+ You will need the following information about VLAN.
+
+
+
+
+
+
+
+
+
+
+ VLAN Information
+
+
+
+
+ Value
+
+
+
+
+ Notes
+
+
+
+
+
+
+
+
+
+
+ ESXi VLAN
+
+
+
+
+
+
+
+
+ VLAN on which all your ESXi hypervisors reside.
+
+
+
+
+
+
+
+ ESXI VLAN IP Address
+
+
+
+
+
+
+
+
+ IP Address Range in the ESXi VLAN. One address per Virtual Router is used from this range.
+
+
+
+
+
+
+
+ ESXi VLAN IP Gateway
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ESXi VLAN Netmask
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Management Server VLAN
+
+
+
+
+
+
+
+
+ VLAN on which the &PRODUCT; Management server is installed.
+
+
+
+
+
+
+
+ Public VLAN
+
+
+
+
+
+
+
+
+ VLAN for the Public Network.
+
+
+
+
+
+
+
+ Public VLAN Gateway
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Public VLAN Netmask
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Public VLAN IP Address Range
+
+
+
+
+
+
+
+
+ Range of Public IP Addresses available for &PRODUCT; use. These addresses will be used for virtual router on &PRODUCT; to route private traffic to external networks.
+
+
+
+
+
+
+
+ VLAN Range for Customer use
+
+
+
+
+
+
+
+
+ A contiguous range of non-routable VLANs. One VLAN will be assigned for each customer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ vSphere Installation Steps
+
+
+
+ If you haven't already, you'll need to download and purchase vSphere from the VMware Website (https://www.vmware.com/tryvmware/index.php?p=vmware-vsphere&lp=1) and install it by following the VMware vSphere Installation Guide.
+
+
+
+
+ Following installation, perform the following configuration, which are described in the next few sections:
+
+
+
+
+
+
+
+
+
+ Required
+
+
+
+
+ Optional
+
+
+
+
+
+
+
+
+
+
+ ESXi host setup
+
+
+
+
+ NIC bonding
+
+
+
+
+
+
+
+ Configure host physical networking, virtual switch, vCenter Management Network, and extended port range
+
+
+
+
+ Multipath storage
+
+
+
+
+
+
+
+ Prepare storage for iSCSI
+
+
+
+
+
+
+
+
+
+
+
+ Configure clusters in vCenter and add hosts to them, or add hosts without clusters to vCenter
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ ESXi Host setup
+
+ All ESXi hosts should enable CPU hardware virtualization support in BIOS. Please note hardware virtualization support is not enabled by default on most servers.
+
+
+
+
+
+ Physical Host Networking
+
+ You should have a plan for cabling the vSphere hosts. Proper network configuration is required before adding a vSphere host to &PRODUCT;. To configure an ESXi host, you can use vClient to add it as standalone host to vCenter first. Once you see the host appearing in the vCenter inventory tree, click the host node in the inventory tree, and navigate to the Configuration tab.
+
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+ In the host configuration tab, click the "Hardware/Networking" link to bring up the networking configuration page as above.
+
+
+ Configure Virtual Switch
+
+ A default virtual switch vSwitch0 is created. &PRODUCT; requires all ESXi hosts in the cloud to use the same set of virtual switch names. If you change the default virtual switch name, you will need to configure one or more &PRODUCT; configuration variables as well.
+
+
+ Separating Traffic
+
+ &PRODUCT; allows you to use vCenter to configure three separate networks per ESXi host. These networks are identified by the name of the vSwitch they are connected to. The allowed networks for configuration are public (for traffic to/from the public internet), guest (for guest-guest traffic), and private (for management and usually storage traffic). You can use the default virtual switch for all three, or create one or two other vSwitches for those traffic types.
+
+
+ If you want to separate traffic in this way you should first create and configure vSwitches in vCenter according to the vCenter instructions. Take note of the vSwitch names you have used for each traffic type. You will configure &PRODUCT; to use these vSwitches.
+
+
+
+
+
+ Increasing Ports
+
+ By default a virtual switch on ESXi hosts is created with 56 ports. We recommend setting it to 4088, the maximum number of ports allowed. To do that, click the "Properties..." link for virtual switch (note this is not the Properties link for Networking).
+
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+ In vSwitch properties dialog, select the vSwitch and click Edit. You should see the following dialog:
+
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+ In this dialog, you can change the number of switch ports. After you've done that, ESXi hosts are required to reboot in order for the setting to take effect.
+
+
+
+
+
+
+
+
+ Configure vCenter Management Network
+
+ In the vSwitch properties dialog box, you may see a vCenter management network. This same network will also be used as the &PRODUCT; management network. &PRODUCT; requires the vCenter management network to be configured properly. Select the management network item in the dialog, then click Edit.
+
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+ Make sure the following values are set:
+
+
+
+
+ VLAN ID set to the desired ID
+
+
+
+
+ vMotion enabled.
+
+
+
+
+ Management traffic enabled.
+
+
+
+
+
+ If the ESXi hosts have multiple VMKernel ports, and ESXi is not using the default value "Management Network" as the management network name, you must follow these guidelines to configure the management network port group so that &PRODUCT; can find it:
+
+
+
+
+ Use one label for the management network port across all ESXi hosts.
+
+
+
+
+ In the &PRODUCT; UI, go to Configuration - Global Settings and set vmware.management.portgroup to the management network label from the ESXi hosts.
+
+
+
+
+
+
+
+
+ Extend Port Range for &PRODUCT; Console Proxy
+
+ (Applies only to VMware vSphere version 4.x)
+
+
+ You need to extend the range of firewall ports that the console proxy works with on the hosts. This is to enable the console proxy to work with VMware-based VMs. The default additional port range is 59000-60000. To extend the port range, log in to the VMware ESX service console on each host and run the following commands:
+
+
+
+esxcfg-firewall -o 59000-60000,tcp,in,vncextras
+esxcfg-firewall -o 59000-60000,tcp,out,vncextras
+
+
+
+
+
+ Configure NIC Bonding for vSphere
+
+ NIC bonding on vSphere hosts may be done according to the vSphere installation guide.
+
+
+
+
+
+
+
+
+ Storage Preparation for vSphere (iSCSI only)
+
+ Use of iSCSI requires preparatory work in vCenter. You must add an iSCSI target and create an iSCSI datastore.
+
+
+ If you are using NFS, skip this section.
+
+
+ Enable iSCSI initiator for ESXi hosts
+
+
+
+ In vCenter, go to hosts and Clusters/Configuration, and click Storage Adapters link. You will see:
+
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+
+
+
+ Select iSCSI software adapter and click Properties.
+
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+
+
+
+ Click the Configure... button.
+
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+
+
+
+ Check Enabled to enable the initiator.
+
+
+
+
+ Click OK to save.
+
+
+
+
+
+
+
+
+ Add iSCSI target
+
+ Under the properties dialog, add the iSCSI target info:
+
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+ Repeat these steps for all ESXi hosts in the cluster.
+
+
+
+
+
+ Create an iSCSI datastore
+
+ You should now create a VMFS datastore. Follow these steps to do so:
+
+
+
+
+ Select Home/Inventory/Datastores.
+
+
+
+
+ Right click on the datacenter node.
+
+
+
+
+ Choose Add Datastore... command.
+
+
+
+
+ Follow the wizard to create a iSCSI datastore.
+
+
+
+
+
+ This procedure should be done on one host in the cluster. It is not necessary to do this on all hosts.
+
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+
+
+
+ Multipathing for vSphere (Optional)
+
+ Storage multipathing on vSphere nodes may be done according to the vSphere installation guide.
+
+
+
+
+
+
+
+
+ Add Hosts or Configure Clusters (vSphere)
+
+ Use vCenter to create a vCenter cluster and add your desired hosts to the cluster. You will later add the entire cluster to &PRODUCT;. (see ).
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vmware-requirements.xml b/docs/tmp/en-US/xml/vmware-requirements.xml
new file mode 100644
index 00000000000..283811d752e
--- /dev/null
+++ b/docs/tmp/en-US/xml/vmware-requirements.xml
@@ -0,0 +1,209 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ System Requirements for vSphere Hosts
+
+ Software requirements:
+
+
+
+ vSphere and vCenter, both version 4.1 or 5.0.
+
+
+ vSphere Standard is recommended. Note however that customers need to consider the CPU constraints in place with vSphere licensing. See http://www.vmware.com/files/pdf/vsphere_pricing.pdf and discuss with your VMware sales representative.
+
+
+ vCenter Server Standard is recommended.
+
+
+
+
+
+ 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. &PRODUCT; 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.
+
+
+
+
+
+ Apply All Necessary Hotfixes
+
+ The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+
+
+
+
+
+
+ Hardware requirements:
+
+
+
+ The host must be certified as compatible with vSphere. See the VMware Hardware Compatibility Guide at http://www.vmware.com/resources/compatibility/search.php.
+
+
+
+
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled).
+
+
+
+
+ All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+
+
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+
+
+
+ Hardware virtualization support required
+
+
+
+
+ 4 GB of memory
+
+
+
+
+ 36 GB of local disk
+
+
+
+
+ At least 1 NIC
+
+
+
+
+ Statically allocated IP Address
+
+
+
+
+
+
+
+
+ vCenter Server requirements:
+
+
+
+ Processor - 2 CPUs 2.0GHz or higher Intel or AMD x86 processors. Processor requirements may be higher if the database runs on the same machine.
+
+
+
+
+ Memory - 3GB RAM. RAM requirements may be higher if your database runs on the same machine.
+
+
+
+
+ Disk storage - 2GB. Disk requirements may be higher if your database runs on the same machine.
+
+
+
+
+ Microsoft SQL Server 2005 Express disk requirements. The bundled database requires up to 2GB free disk space to decompress the installation archive.
+
+
+
+
+ Networking - 1Gbit or 10Gbit.
+
+
+
+
+
+ For more information, see "vCenter Server and the vSphere Client Hardware Requirements" at http://pubs.vmware.com/vsp40/wwhelp/wwhimpl/js/html/wwhelp.htm#href=install/c_vc_hw.html.
+
+
+
+
+
+ Other requirements:
+
+
+
+ VMware vCenter Standard Edition 4.1 or 5.0 must be installed and available to manage the vSphere hosts.
+
+
+
+
+ vCenter must be configured to use the standard port 443 so that it can communicate with the &PRODUCT; Management Server.
+
+
+
+
+ You must re-install VMware ESXi if you are going to re-use a host from a previous install.
+
+
+
+
+ &PRODUCT; requires VMware vSphere 4.1 or 5.0. VMware vSphere 4.0 is not supported.
+
+
+
+
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled). All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+
+
+
+
+ The &PRODUCT; management network must not be configured as a separate virtual network. The &PRODUCT; management network is the same as the vCenter management network, and will inherit its configuration. See .
+
+
+
+
+ &PRODUCT; requires ESXi. ESX is not supported.
+
+
+
+
+ All resources used for &PRODUCT; must be used for &PRODUCT; only. &PRODUCT; cannot share instance of ESXi or storage with other management consoles. Do not share the same storage volumes that will be used by &PRODUCT; with a different set of ESXi servers that are not managed by &PRODUCT;.
+
+
+
+
+ Put all target ESXi hypervisors in a cluster in a separate Datacenter in vCenter.
+
+
+
+
+ The cluster that will be managed by &PRODUCT; should not contain any VMs. Do not run the management server, vCenter or any other VMs on the cluster that is designated for &PRODUCT; use. Create a separate cluster for use of &PRODUCT; and make sure that they are no VMs in this cluster.
+
+
+
+
+ All the required VLANS must be trunked into all network switches that are connected to the ESXi hypervisor hosts. These would include the VLANS for Management, Storage, vMotion, and guest VLANs. The guest VLAN (used in Advanced Networking; see Network Setup) is a contiguous range of VLANs that will be managed by &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vmware-topology-req.xml b/docs/tmp/en-US/xml/vmware-topology-req.xml
new file mode 100644
index 00000000000..237fa525a47
--- /dev/null
+++ b/docs/tmp/en-US/xml/vmware-topology-req.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ VMware Topology Requirements
+
+
+
+ The Management Server and secondary storage VMs must be able to access vCenter and all ESXi hosts in the zone. To allow the necessary access through the firewall, keep port 443 open.
+
+
+
+
+
+ The Management Servers communicate with VMware vCenter servers on port 443 (HTTPs).
+
+
+
+
+
+ The Management Servers communicate with the System VMs on port 3922 (ssh) on the management traffic network.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/volume-deletion-garbage-collection.xml b/docs/tmp/en-US/xml/volume-deletion-garbage-collection.xml
new file mode 100644
index 00000000000..ce246698f66
--- /dev/null
+++ b/docs/tmp/en-US/xml/volume-deletion-garbage-collection.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Volume Deletion and Garbage Collection
+
+ The deletion of a volume does not delete the snapshots that have been created from the volume
+
+
+ When a VM is destroyed, data disk volumes that are attached to the VM are not deleted.
+
+
+ Volumes are permanently destroyed using a garbage collection process. The global configuration variables expunge.delay and expunge.interval determine when the physical deletion of volumes will occur.
+
+
+
+
+ expunge.delay: determines how old the volume must be before it is destroyed, in seconds
+
+
+
+
+ expunge.interval: determines how often to run the garbage collection check
+
+
+
+
+
+ Administrators should adjust these values depending on site policies around data retention.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/volume-status.xml b/docs/tmp/en-US/xml/volume-status.xml
new file mode 100644
index 00000000000..13ef22ff32a
--- /dev/null
+++ b/docs/tmp/en-US/xml/volume-status.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Volume Status
+
+ When a snapshot operation is triggered by means of a recurring snapshot policy, a snapshot is skipped if a volume has remained inactive since its last snapshot was taken. A volume is considered to be inactive if it is either detached or attached to a VM that is not running. &PRODUCT; ensures that at least one snapshot is taken since the volume last became inactive.
+
+
+ When a snapshot is taken manually, a snapshot is always created regardless of whether a volume has been active or not.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vpc.xml b/docs/tmp/en-US/xml/vpc.xml
new file mode 100644
index 00000000000..b5be8a81e07
--- /dev/null
+++ b/docs/tmp/en-US/xml/vpc.xml
@@ -0,0 +1,265 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ About Virtual Private Clouds
+
+ &PRODUCT; Virtual Private Cloud is a private, isolated part of &PRODUCT;. A VPC can have its own virtual network topology that resembles a traditional physical network. You can launch VMs in the virtual network that can have private addresses in the range of your choice, for example: 10.0.0.0/16. You can define network tiers within your VPC network range, which in turn enables you to group similar kinds of instances based on IP address range.
+
+
+ For example, if a VPC has the private range 10.0.0.0/16, its guest networks can have the network ranges 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on.
+
+
+ Major Components of a VPC:
+
+ A VPC is comprised of the following network components:
+
+
+
+
+
+
+ VPC: A VPC acts as a container for multiple isolated networks that can communicate with each other via its virtual router.
+
+
+
+
+
+ Network Tiers: Each tier acts as an isolated network with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
+
+
+
+
+
+ Virtual Router: A virtual router is automatically created and started when you create a VPC. The virtual router connect the tiers and direct traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and DHCP services through its IP.
+
+
+
+
+
+ Public Gateway: The traffic to and from the Internet routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to the end user; therefore, static routes are not support for the public gateway.
+
+
+
+
+
+ Private Gateway: All the traffic to and from a private network routed to the VPC through the private gateway. For more information, see .
+
+
+
+
+
+ VPN Gateway: The VPC side of a VPN connection.
+
+
+
+
+
+ Site-to-Site VPN Connection: A hardware-based VPN connection between your VPC and your datacenter, home network, or co-location facility. For more information, see .
+
+
+
+
+
+ Customer Gateway: The customer side of a VPN Connection. For more information, see .
+
+
+
+
+
+ NAT Instance: An instance that provides Port Address Translation for instances to access the Internet via the public gateway. For more information, see .
+
+
+
+
+
+
+ Network Architecture in a VPC
+
+ In a VPC, the following four basic options of network architectures are present:
+
+
+
+
+
+
+ VPC with a public gateway only
+
+
+
+
+
+ VPC with public and private gateways
+
+
+
+
+
+ VPC with public and private gateways and site-to-site VPN access
+
+
+
+
+
+ VPC with a private gateway only and site-to-site VPN access
+
+
+
+
+
+
+ Connectivity Options for a VPC
+
+ You can connect your VPC to:
+
+
+
+
+
+
+ The Internet through the public gateway.
+
+
+
+
+
+ The corporate datacenter by using a site-to-site VPN connection through the VPN gateway.
+
+
+
+
+
+ Both the Internet and your corporate datacenter by using both the public gateway and a VPN gateway.
+
+
+
+
+
+
+ VPC Network Considerations
+
+ Consider the following before you create a VPC:
+
+
+
+
+
+
+ A VPC, by default, is created in the enabled state.
+
+
+
+
+
+ A VPC can be created in Advance zone only, and can't belong to more than one zone at a time.
+
+
+
+
+
+ The default number of VPCs an account can create is 20. However, you can change it by using the max.account.vpcs global parameter, which controls the maximum number of VPCs an account is allowed to create.
+
+
+
+
+
+ The default number of tiers an account can create within a VPC is 3. You can configure this number by using the vpc.max.networks parameter.
+
+
+
+
+
+ Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be within the VPC CIDR range.
+
+
+
+
+
+ A tier belongs to only one VPC.
+
+
+
+
+
+ All network tiers inside the VPC should belong to the same account.
+
+
+
+
+
+ When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP is released only when the VPC is removed.
+
+
+
+
+
+ A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it cannot be used for StaticNAT or port forwarding.
+
+
+
+
+
+ The instances only have a private IP address that you provision. To communicate with the Internet, enable NAT to an instance that you launch in your VPC.
+
+
+
+
+
+ Only new networks can be added to a VPC. The maximum number of networks per VPC is limited by the value you specify in the vpc.max.networks parameter. The default value is three.
+
+
+
+
+
+ The load balancing service can be supported by only one tier inside the VPC.
+
+
+
+
+
+ If an IP address is assigned to a tier:
+
+
+
+
+ That IP can't be used by more than one tier at a time in the VPC. For example, if you have tiers A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A or B, but not for both.
+
+
+
+
+
+ That IP can't be used for StaticNAT, load balancing, or port forwarding rules for another guest network inside the VPC.
+
+
+
+
+
+
+
+
+
+ Remote access VPN is not supported in VPC networks.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/vpn.xml b/docs/tmp/en-US/xml/vpn.xml
new file mode 100644
index 00000000000..b9e3d4b1907
--- /dev/null
+++ b/docs/tmp/en-US/xml/vpn.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ VPN
+
+ &PRODUCT; account owners can create virtual private networks (VPN) to access their virtual machines. If the guest network is instantiated from a network offering that offers the Remote Access VPN service, the virtual router (based on the System VM) is used to provide the service. &PRODUCT; provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN. &PRODUCT; does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.
+
+
+
+ Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
+
+
+
+
+
+ Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
+
+
+
+
+ Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/whatis.xml b/docs/tmp/en-US/xml/whatis.xml
new file mode 100644
index 00000000000..8dea9870ad5
--- /dev/null
+++ b/docs/tmp/en-US/xml/whatis.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ What Is &PRODUCT;?
+
+ &PRODUCT; is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. &PRODUCT; manages the network, storage, and compute nodes that make up a cloud infrastructure. Use &PRODUCT; to deploy, manage, and configure cloud computing environments.
+
+
+ Typical users are service providers and enterprises. With &PRODUCT;, you can:
+
+
+
+
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+
+
+
+
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with &PRODUCT; an enterprise can offer self-service virtual machines to users without involving IT departments.
+
+
+
+
+
+
+
+
+
+ 1000-foot-view.png: Overview of &PRODUCT;
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/whats-in-this-adminguide.xml b/docs/tmp/en-US/xml/whats-in-this-adminguide.xml
new file mode 100644
index 00000000000..f2953e5543d
--- /dev/null
+++ b/docs/tmp/en-US/xml/whats-in-this-adminguide.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Who Should Read This
+
+ If you have already installed &PRODUCT; or you want to learn more about the ongoing operation and maintenance of a &PRODUCT;-powered cloud, read this documentation. It will help you start using, configuring, and managing the ongoing operation of your cloud.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/whats-new.xml b/docs/tmp/en-US/xml/whats-new.xml
new file mode 100644
index 00000000000..3427d9d43fe
--- /dev/null
+++ b/docs/tmp/en-US/xml/whats-new.xml
@@ -0,0 +1,46 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ What's New in the API?
+
+ The following describes any new major features of each &PRODUCT; version as it applies to API usage.
+
+
+ What's New in the API for 4.0
+
+
+
+
+
+
+ What's New in the API for 3.0
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/who-should-read-installation.xml b/docs/tmp/en-US/xml/who-should-read-installation.xml
new file mode 100644
index 00000000000..6cfc9559ed3
--- /dev/null
+++ b/docs/tmp/en-US/xml/who-should-read-installation.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Who Should Read This
+
+ For those who have already gone through a design phase and planned a more sophisticated deployment, or those who are ready to start scaling up a trial installation. With the following procedures, you can start using the more powerful features of &PRODUCT;, 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/windows-installation.xml b/docs/tmp/en-US/xml/windows-installation.xml
new file mode 100644
index 00000000000..8d82dc3cda6
--- /dev/null
+++ b/docs/tmp/en-US/xml/windows-installation.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Windows OS Installation
+
+ Download the installer, CloudInstanceManager.msi, from Download page and run the installer in the newly created Windows VM.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/work-with-usage.xml b/docs/tmp/en-US/xml/work-with-usage.xml
new file mode 100644
index 00000000000..0d52d25a11d
--- /dev/null
+++ b/docs/tmp/en-US/xml/work-with-usage.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Working with Usage
+
+ The Usage Server is an optional, separately-installed part of &PRODUCT; that provides aggregated usage records which you can use to create billing integration for &PRODUCT;. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances.
+
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/working-with-hosts.xml b/docs/tmp/en-US/xml/working-with-hosts.xml
new file mode 100644
index 00000000000..7da23a11106
--- /dev/null
+++ b/docs/tmp/en-US/xml/working-with-hosts.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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 .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/working-with-iso.xml b/docs/tmp/en-US/xml/working-with-iso.xml
new file mode 100644
index 00000000000..c37ca51fd85
--- /dev/null
+++ b/docs/tmp/en-US/xml/working-with-iso.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Working with ISOs
+
+ &PRODUCT; supports ISOs and their attachment to guest VMs. An ISO is a read-only file that has an ISO/CD-ROM style file system. Users can upload their own ISOs and mount them on their guest VMs.
+
+
+ ISOs are uploaded based on a URL. HTTP is the supported protocol. Once the ISO is available via HTTP specify an upload URL such as http://my.web.server/filename.iso.
+
+
+ ISOs may be public or private, like templates.ISOs are not hypervisor-specific. That is, a guest on vSphere can mount the exact same image that a guest on KVM can mount.
+
+
+ ISO images may be stored in the system and made available with a privacy level similar to templates. ISO images are classified as either bootable or not bootable. A bootable ISO image is one that contains an OS image. &PRODUCT; allows a user to boot a guest VM off of an ISO image. Users can also attach ISO images to guest VMs. For example, this enables installing PV drivers into Windows. ISO images are not hypervisor-specific.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/working-with-snapshots.xml b/docs/tmp/en-US/xml/working-with-snapshots.xml
new file mode 100644
index 00000000000..06e467f15b2
--- /dev/null
+++ b/docs/tmp/en-US/xml/working-with-snapshots.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Working with Snapshots
+
+ (Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)
+
+
+ &PRODUCT; supports snapshots of disk volumes. Snapshots are a point-in-time capture of virtual machine disks. Memory and CPU states are not captured.
+
+
+ Snapshots may be taken for volumes, including both root and data disks. The administrator places a limit on the number of stored snapshots per user. Users can create new volumes from the snapshot for recovery of particular files and they can create templates from snapshots to boot from a restored disk.
+
+
+ Users can create snapshots manually or by setting up automatic recurring snapshot policies. Users can also create disk volumes from snapshots, which may be attached to a VM like any other disk volume. Snapshots of both root disks and data disks are supported. However, &PRODUCT; does not currently support booting a VM from a recovered root disk. A disk recovered from snapshot of a root disk is treated as a regular data disk; the data on recovered disk can be accessed by attaching the disk to a VM.
+
+
+ A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/working-with-system-vm.xml b/docs/tmp/en-US/xml/working-with-system-vm.xml
new file mode 100644
index 00000000000..a1a8bf26d7e
--- /dev/null
+++ b/docs/tmp/en-US/xml/working-with-system-vm.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Working with System Virtual Machines
+
+ &PRODUCT; uses several types of system virtual machines to perform tasks in the cloud. In general &PRODUCT; manages these system VMs and creates, starts, and stops them as needed based on scale and immediate needs. However, the administrator should be aware of them and their roles to assist in debugging issues.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/working-with-templates.xml b/docs/tmp/en-US/xml/working-with-templates.xml
new file mode 100644
index 00000000000..f540898630d
--- /dev/null
+++ b/docs/tmp/en-US/xml/working-with-templates.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Working with Templates
+
+ A template is a reusable configuration for virtual machines. When users launch VMs, they can choose from a list of templates in &PRODUCT;.
+
+
+ Specifically, a template is a virtual disk image that includes one of a variety of operating systems, optional additional software such as office applications, and settings such as access control to determine who can use the template. Each template is associated with a particular type of hypervisor, which is specified when the template is added to &PRODUCT;.
+
+
+ &PRODUCT; ships with a default template. In order to present more choices to users, &PRODUCT; administrators and users can create templates and add them to &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/working-with-usage-data.xml b/docs/tmp/en-US/xml/working-with-usage-data.xml
new file mode 100644
index 00000000000..38c98f39049
--- /dev/null
+++ b/docs/tmp/en-US/xml/working-with-usage-data.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Working With Usage Data
+
+ The Usage Server provides aggregated usage records which you can use to create billing integration for the &PRODUCT; platform. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+
+
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances. In the special case of bare metal instances, no template storage resources are consumed, but records showing zero usage are still included in the Usage Server's output.
+
+
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day. Its behavior is controlled by configuration settings as described in the &PRODUCT; Administration Guide.
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/working-with-volumes.xml b/docs/tmp/en-US/xml/working-with-volumes.xml
new file mode 100644
index 00000000000..5b78b3a4b3a
--- /dev/null
+++ b/docs/tmp/en-US/xml/working-with-volumes.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Using Swift for Secondary Storage
+
+ A volume provides storage to a guest VM. The volume can provide for a root disk or an additional data disk. &PRODUCT; supports additional volumes for guest VMs.
+
+
+ Volumes are created for a specific hypervisor type. A volume that has been attached to guest using one hypervisor type (e.g, XenServer) may not be attached to a guest that is using another hypervisor type (e.g. vSphere, KVM). This is because the different hypervisors use different disk image formats.
+
+
+ &PRODUCT; defines a volume as a unit of storage available to a guest VM. Volumes are either root disks or data disks. The root disk has "/" in the file system and is usually the boot device. Data disks provide for additional storage (e.g. As "/opt" or "D:"). Every guest VM has a root disk, and VMs can also optionally have a data disk. End users can mount multiple data disks to guest VMs. Users choose data disks from the disk offerings created by administrators. The user can create a template from a volume as well; this is the standard procedure for private template creation. Volumes are hypervisor-specific: a volume from one hypervisor type may not be used on a guest of another hypervisor type.
+
+
+
+
diff --git a/docs/tmp/en-US/xml/xenserver-maintenance-mode.xml b/docs/tmp/en-US/xml/xenserver-maintenance-mode.xml
new file mode 100644
index 00000000000..f2ce554478f
--- /dev/null
+++ b/docs/tmp/en-US/xml/xenserver-maintenance-mode.xml
@@ -0,0 +1,94 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ 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
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml/xenserver-topology-req.xml b/docs/tmp/en-US/xml/xenserver-topology-req.xml
new file mode 100644
index 00000000000..44a3ae31e49
--- /dev/null
+++ b/docs/tmp/en-US/xml/xenserver-topology-req.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ XenServer Topology Requirements
+
+ The Management Servers communicate with XenServer hosts on ports 22 (ssh), 80 (HTTP), and 443 (HTTPs).
+
+
+
+
diff --git a/docs/tmp/en-US/xml/zone-add.xml b/docs/tmp/en-US/xml/zone-add.xml
new file mode 100644
index 00000000000..23f27791e34
--- /dev/null
+++ b/docs/tmp/en-US/xml/zone-add.xml
@@ -0,0 +1,177 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+ Adding a Zone
+
+ These steps assume you have already logged in to the &PRODUCT; UI. See .
+
+
+
+
+ (Optional) If you are going to use Swift for cloud-wide secondary storage, you need to add it before you add zones.
+
+
+
+
+ Log in to the &PRODUCT; UI as administrator.
+
+
+
+
+ If this is your first time visiting the UI, you will see the guided tour splash screen. Choose “Experienced user.” The Dashboard appears.
+
+
+
+
+ In the left navigation bar, click Global Settings.
+
+
+
+
+ In the search box, type swift.enable and click the search button.
+
+
+
+
+ Click the edit button and set swift.enable to true.
+
+
+
+
+
+ edit-icon.png: button to modify data
+
+
+
+
+
+
+
+
+
+ Restart the Management Server.
+
+
+# service cloud-management restart
+
+
+
+
+ Refresh the &PRODUCT; UI browser tab and log back in.
+
+
+
+
+
+
+
+
+ In the left navigation, choose Infrastructure.
+
+
+
+
+ On Zones, click View More.
+
+
+
+
+ (Optional) If you are using Swift storage, click Enable Swift. Provide the following:
+
+
+
+
+ URL. The Swift URL.
+
+
+
+
+ Account. The Swift account.
+
+
+
+
+ Username. The Swift account’s username.
+
+
+
+
+ Key. The Swift key.
+
+
+
+
+
+
+
+
+ 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.
+
+
+
+
+
+ For more information about the network types, see Network Setup.
+
+
+
+
+
+ The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/API_Developers_Guide.ent b/docs/tmp/en-US/xml_tmp/API_Developers_Guide.ent
new file mode 100644
index 00000000000..47a2b6757f8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/API_Developers_Guide.ent
@@ -0,0 +1,21 @@
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/API_Developers_Guide.xml b/docs/tmp/en-US/xml_tmp/API_Developers_Guide.xml
new file mode 100644
index 00000000000..c691ad02cf6
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/API_Developers_Guide.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ &PRODUCT; API Developer's Guide
+ Apache CloudStack
+ 4.0.0-incubating
+
+
+
+
+ How to integrate with &PRODUCT; using the &PRODUCT; API.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Admin_Guide.ent b/docs/tmp/en-US/xml_tmp/Admin_Guide.ent
new file mode 100644
index 00000000000..abb18851bcf
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Admin_Guide.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Admin_Guide.xml b/docs/tmp/en-US/xml_tmp/Admin_Guide.xml
new file mode 100644
index 00000000000..07f5e889fc8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Admin_Guide.xml
@@ -0,0 +1,74 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ &PRODUCT; Administrator's Guide
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Administration Guide for &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Author_Group.xml b/docs/tmp/en-US/xml_tmp/Author_Group.xml
new file mode 100644
index 00000000000..ba9e651f876
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Author_Group.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+ Apache
+ CloudStack
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Book_Info.xml b/docs/tmp/en-US/xml_tmp/Book_Info.xml
new file mode 100644
index 00000000000..c125ab8de2b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Book_Info.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ &PRODUCT; Guide
+ Revised August 9, 2012 10:48 pm Pacific
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Complete technical documentation of &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Book_Info_Release_Notes_4.0.xml b/docs/tmp/en-US/xml_tmp/Book_Info_Release_Notes_4.0.xml
new file mode 100644
index 00000000000..0d57fb6d9a8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Book_Info_Release_Notes_4.0.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Version 4.0.0-incubating Release Notes
+ Revised October 17, 2012 19:49 UTC
+ Apache CloudStack
+
+
+
+ Release notes for the Apache CloudStack 4.0.0-incubating release.
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/CloudStack_Nicira_NVP_Guide.ent b/docs/tmp/en-US/xml_tmp/CloudStack_Nicira_NVP_Guide.ent
new file mode 100644
index 00000000000..abb18851bcf
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/CloudStack_Nicira_NVP_Guide.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/CloudStack_Nicira_NVP_Guide.xml b/docs/tmp/en-US/xml_tmp/CloudStack_Nicira_NVP_Guide.xml
new file mode 100644
index 00000000000..a4c367c26f7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/CloudStack_Nicira_NVP_Guide.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+
+
+
+ &PRODUCT; Plugin Guide for the Nicira NVP Plugin
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Plugin Guide for the Nicira NVP Plugin.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Common_Content/Legal_Notice.xml b/docs/tmp/en-US/xml_tmp/Common_Content/Legal_Notice.xml
new file mode 100644
index 00000000000..d35b5c63af8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Common_Content/Legal_Notice.xml
@@ -0,0 +1,21 @@
+
+
+
+
+ Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
+
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+
+ Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
+
+
+ Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
+
+
+ Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Installation_Guide.ent b/docs/tmp/en-US/xml_tmp/Installation_Guide.ent
new file mode 100644
index 00000000000..abb18851bcf
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Installation_Guide.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Installation_Guide.xml b/docs/tmp/en-US/xml_tmp/Installation_Guide.xml
new file mode 100644
index 00000000000..90f8748046d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Installation_Guide.xml
@@ -0,0 +1,60 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ &PRODUCT; Installation Guide
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Installation Guide for &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/LDAPserver-for-user-authentication.xml b/docs/tmp/en-US/xml_tmp/LDAPserver-for-user-authentication.xml
new file mode 100644
index 00000000000..5fcb300af65
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/LDAPserver-for-user-authentication.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using an LDAP Server for User Authentication
+ You can use an external LDAP server such as Microsoft Active Directory or ApacheDS to authenticate &PRODUCT; end-users. Just map &PRODUCT; 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 &PRODUCT; for matching common values such as the user’s email address and name. &PRODUCT; 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 &PRODUCT;, call the &PRODUCT; 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 &PRODUCT; permission to search on the LDAP server
+ SSL keystore and password, if SSL is used
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Preface.xml b/docs/tmp/en-US/xml_tmp/Preface.xml
new file mode 100644
index 00000000000..3f5cdc6bfcb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Preface.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Preface
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Release_Notes.ent b/docs/tmp/en-US/xml_tmp/Release_Notes.ent
new file mode 100644
index 00000000000..7858ad5f2e0
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Release_Notes.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Release_Notes.xml b/docs/tmp/en-US/xml_tmp/Release_Notes.xml
new file mode 100644
index 00000000000..17f9079cc01
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Release_Notes.xml
@@ -0,0 +1,2923 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Submitting Feedback and Getting Help
+ The Apache CloudStack project has mailing lists for users and developers. These are the
+ official channels of communication for the project and are the best way to get answers about
+ using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users
+ mailing list if you've deployed or are deploying CloudStack into production, and even for test
+ deployments.
+ The CloudStack developer's mailing list (cloudstack-dev) is for discussions about
+ CloudStack development, and is the best list for discussing possible bugs in CloudStack.
+ Anyone contributing to CloudStack should be on this mailing list.
+ You can also report bugs in CloudStack using the Apache Defect Tracking
+ System.
+ To posts to the lists, you'll need to be subscribed. See the CloudStack Web site
+ for instructions.
+
+
+ Upgrade Instructions
+
+ Upgrade from 3.0.2 to 4.0.0-incubating
+ Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note
+ that some of the steps here are only required if you're using a specific hypervisor. The
+ steps that are hypervisor-specific are called out with a note.
+
+
+ Ensure that you query your IP address usage records and process them or make a
+ backup. During the upgrade you will lose the old IP address usage records.
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest
+ of the usage types. Instead of a single record with the assignment and release dates,
+ separate records are generated per aggregation period with start and end dates. After
+ upgrading, any existing IP address usage records in the old format will no longer be
+ available.
+
+
+
+ The following upgrade instructions apply only if you're using VMware hosts. If
+ you're not using VMware hosts, skip this step and move on to step 3: stopping all
+ usage servers.
+
+ In each zone that includes VMware hosts, you need to add a new system VM template.
+
+
+ While running the existing 3.0.2 system, log in to the UI as root
+ administrator.
+
+
+ In the left navigation bar, click Templates.
+
+
+ In Select view, click Templates.
+
+
+ Click Register template.
+ The Register template dialog box is displayed.
+
+
+ In the Register template dialog box, specify the following values (do not change
+ these):
+
+
+
+
+
+
+ Field
+ Value
+
+
+
+
+ Name
+ systemvm-vmware-3.0.0
+
+
+ Description
+ systemvm-vmware-3.0.0
+
+
+ URL
+ http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+ Zone
+ Choose the zone where this hypervisor is used
+
+
+ Hypervisor
+ VMware
+
+
+ Format
+ OVA
+
+
+ OS Type
+ Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable
+ no
+
+
+ Password Enabled
+ no
+
+
+ Public
+ no
+
+
+ Featured
+ no
+
+
+
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters
+ the READY state. Do not proceed until this is successful.
+
+
+
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+ # service cloud-usage stop
+
+
+ Stop the Management Servers. Run this on all Management Server hosts.
+ # service cloud-management stop
+
+
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing
+ this step even in test upgrades. If there is an issue, this will assist with
+ debugging.
+ 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.
+ #mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp
+
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of
+ the community provided yum/apt repositories to gain access to the &PRODUCT;
+ binaries.
+
+
+ After you have configured an appropriate yum or apt repository, you may execute the
+ one of the following commands as appropriate for your environment in order to upgrade
+ &PRODUCT;: #yum update cloud-*
+ #apt-get update
+#apt-get upgrade cloud-*
+
+ You will, of course, have to agree to the changes suggested by Yum or APT.
+
+ If the upgrade output includes a message similar to the following, then some
+ custom content was found in your old components.xml, and you need to merge the two
+ files:
+ warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+ Instructions follow in the next step.
+
+
+
+ If you have made changes to your copy of
+ /etc/cloud/management/components.xml the changes will be
+ preserved in the upgrade. However, you need to do the following steps to place these
+ changes in a new version of the file which is compatible with version
+ 4.0.0-incubating.
+
+
+ Make a backup copy of /etc/cloud/management/components.xml.
+ For example:
+ # mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backup
+
+
+ Copy /etc/cloud/management/components.xml.rpmnew to create
+ a new /etc/cloud/management/components.xml:
+ # cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xml
+
+
+ Merge your changes from the backup file into the new
+ components.xml.
+ # vi /etc/cloud/management/components.xml
+
+
+
+ If you have more than one management server node, repeat the upgrade steps on each
+ node.
+
+
+
+ Start the first Management Server. Do not start any other Management Server nodes
+ yet.
+ # service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete.
+ After confirmation, start the other Management Servers one at a time by running the same
+ command on each node.
+
+ Failing to restart the Management Server indicates a problem in the upgrade.
+ Having the Management Server restarted without any issues indicates that the upgrade
+ is successfully completed.
+
+
+
+ Start all Usage Servers (if they were running on your previous version). Perform
+ this on each Usage Server host.
+ # service cloud-usage start
+
+
+
+ Additional steps are required for each KVM host. These steps will not affect
+ running guests in the cloud. These steps are required only for clouds using KVM as
+ hosts and only on the KVM hosts.
+
+
+
+ Configure a yum or apt respository containing the &PRODUCT; packages as outlined
+ in the Installation Guide.
+
+
+ Stop the running agent.
+ # service cloud-agent stop
+
+
+ Update the agent software with one of the following command sets as appropriate
+ for your environment.
+ # yum update cloud-*
+ # apt-get update
+ # apt-get upgrade cloud-*
+
+
+ Start the agent.
+ # service cloud-agent start
+
+
+ Edit /etc/cloud/agent/agent.properties to change the
+ resource parameter from
+ "com.cloud.agent.resource.computing.LibvirtComputingResource" to
+ "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
+
+
+ Start the cloud agent and cloud management services.
+
+
+ When the Management Server is up and running, log in to the CloudStack UI and
+ restart the virtual router for proper functioning of all the features.
+
+
+
+
+ Log in to the CloudStack UI as administrator, and check the status of the hosts. All
+ hosts should come to Up state (except those that you know to be offline). You may need
+ to wait 20 or 30 minutes, depending on the number of hosts.
+
+ Troubleshooting: If login fails, clear your browser cache and reload the
+ page.
+
+
+ Do not proceed to the next step until the hosts show in Up state.
+
+
+ If you are upgrading from 3.0.2, perform the following:
+
+
+ Ensure that the admin port is set to 8096 by using the "integration.api.port"
+ global parameter.
+ This port is used by the cloud-sysvmadm script at the end of the upgrade
+ procedure. For information about how to set this parameter, see "Setting Global
+ Configuration Parameters" in the Installation Guide.
+
+
+ Restart the Management Server.
+
+ If you don't want the admin port to remain open, you can set it to null after
+ the upgrade is done and restart the management server.
+
+
+
+
+
+ Run the cloud-sysvmadm script to stop, then start, all Secondary
+ Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each
+ management server. Substitute your own IP address of the MySQL instance, the MySQL user
+ to connect as, and the password to use for that user. In addition to those parameters,
+ provide the -c and -r arguments. For
+ example:
+ # nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r >
+ sysvm.log 2>&1 &
+ # tail -f sysvm.log
+ This might take up to an hour or more to run, depending on the number of accounts in
+ the system.
+
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version
+ supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2
+ and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating
+ Installation Guide.
+
+
+ Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to
+ XenServer v6.0.2 hypervisor hosts.
+
+
+ Disconnect the XenServer cluster from CloudStack.
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under
+ Clusters, click View All. Select the XenServer cluster and click Actions -
+ Unmanage.
+ This may fail if there are hosts not in one of the states Up, Down,
+ Disconnected, or Alert. You may need to fix that before unmanaging this
+ cluster.
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack
+ UI to check on the status. When the cluster is in the unmanaged state, there is no
+ connection to the hosts in the cluster.
+
+
+ To clean up the VLAN, log in to one XenServer host and run:
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+ Now prepare the upgrade by running the following on one XenServer host:
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+ If you see a message like "can't eject CD", log in to the VM and unmount the CD,
+ then run this script again.
+
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master,
+ then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the
+ hotfixes to the host. Place them in a temporary folder such as /tmp.
+ On the Xen pool master, upload the hotfix with this command:
+ xe patch-upload file-name=XS602E003.xsupdate
+ Make a note of the output from this command, which is a UUID for the hotfix
+ file. You'll need it in another step later.
+
+ (Optional) If you are applying other hotfixes as well, you can repeat the
+ commands in this section with the appropriate hotfix number. For example,
+ XS602E004.xsupdate.
+
+
+
+ Manually live migrate all VMs on this host to another host. First, get a list of
+ the VMs on this host:
+ # xe vm-list
+ Then use this command to migrate each VM. Replace the example host name and VM
+ name with your own:
+ # xe vm-migrate live=true host=host-name
+ vm=VM-name
+
+ Troubleshooting
+ If you see a message like "You attempted an operation on a VM which requires
+ PV drivers to be installed but the drivers were not detected," run:
+ /opt/xensource/bin/make_migratable.sh
+ b6cf79c8-02ee-050b-922f-49583d9f1a14.
+
+
+
+ Apply the hotfix. First, get the UUID of this host:
+ # xe host-list
+ Then use the following command to apply the hotfix. Replace the example host
+ UUID with the current host ID, and replace the hotfix UUID with the output from the
+ patch-upload command you ran on this machine earlier. You can also get the hotfix
+ UUID by running xe patch-list.
+ xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid
+
+
+ Copy the following files from the CloudStack Management Server to the
+ host.
+
+
+
+
+
+
+ Copy from here...
+ ...to here
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+ /opt/xensource/sm/NFSSR.py
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+ /opt/xensource/bin/setupxenserver.sh
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+
+
+
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud
+ Support Pack.
+
+
+ Download the CSP software onto the XenServer host from one of the following
+ links:
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+ Extract the file:
+ # tar xf xenserver-cloud-supp.tgz
+
+
+ Run the following script:
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable
+ Open vSwitch (OVS):
+ # xe-switch-network-backend bridge
+
+
+
+
+ Reboot this XenServer host.
+
+
+ Run the following:
+ /opt/xensource/bin/setupxenserver.sh
+
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or
+ directory" appears, you can safely ignore it.
+
+
+
+ Run the following:
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+
+
+ On each slave host in the Xen pool, repeat these steps, starting from "manually
+ live migrate VMs."
+
+
+
+
+
+ Troubleshooting Tip
+ If passwords which you know to be valid appear not to work after upgrade, or other UI
+ issues are seen, try clearing your browser cache and reloading the UI page.
+
+
+
+ Upgrade from 2.2.14 to 4.0.0-incubating
+
+
+ Ensure that you query your IPaddress usage records and process them; for example,
+ issue invoices for any usage that you have not yet billed users for.
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest
+ of the usage types. Instead of a single record with the assignment and release dates,
+ separate records are generated per aggregation period with start and end dates. After
+ upgrading to 4.0.0-incubating, any existing IP address usage records in the old format
+ will no longer be available.
+
+
+ If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the
+ instructions in the 2.2.14 Release Notes.
+
+ KVM Hosts
+ If KVM hypervisor is used in your cloud, be sure you completed the step to insert
+ a valid username and password into the host_details table on each KVM node as
+ described in the 2.2.14 Release Notes. This step is critical, as the database will be
+ encrypted after the upgrade to 4.0.0-incubating.
+
+
+
+ While running the 2.2.14 system, log in to the UI as root administrator.
+
+
+ Using the UI, add a new System VM template for each hypervisor type that is used in
+ your cloud. In each zone, add a system VM template for each hypervisor used in that
+ zone
+
+
+ In the left navigation bar, click Templates.
+
+
+ In Select view, click Templates.
+
+
+ Click Register template.
+ The Register template dialog box is displayed.
+
+
+ In the Register template dialog box, specify the following values depending on
+ the hypervisor type (do not change these):
+
+
+
+
+
+
+ Hypervisor
+ Description
+
+
+
+
+ XenServer
+ Name: systemvm-xenserver-3.0.0
+ Description: systemvm-xenserver-3.0.0
+ URL:
+ http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2
+ Zone: Choose the zone where this hypervisor is used
+ Hypervisor: XenServer
+ Format: VHD
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+ Extractable: no
+ Password Enabled: no
+ Public: no
+ Featured: no
+
+
+
+ KVM
+ Name: systemvm-kvm-3.0.0
+ Description: systemvm-kvm-3.0.0
+ URL:
+ http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2
+ Zone: Choose the zone where this hypervisor is used
+ Hypervisor: KVM
+ Format: QCOW2
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+ Extractable: no
+ Password Enabled: no
+ Public: no
+ Featured: no
+
+
+
+ VMware
+ Name: systemvm-vmware-3.0.0
+ Description: systemvm-vmware-3.0.0
+ URL:
+ http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+ Zone: Choose the zone where this hypervisor is used
+ Hypervisor: VMware
+ Format: OVA
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+ Extractable: no
+ Password Enabled: no
+ Public: no
+ Featured: no
+
+
+
+
+
+
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters the
+ READY state. Do not proceed until this is successful
+
+
+ WARNING: If you use more than one type of
+ hypervisor in your cloud, be sure you have repeated these steps to download the system
+ VM template for each hypervisor type. Otherwise, the upgrade will fail.
+
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+ # service cloud-usage stop
+
+
+ Stop the Management Servers. Run this on all Management Server hosts.
+ # service cloud-management stop
+
+
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing
+ this step even in test upgrades. If there is an issue, this will assist with
+ debugging.
+ 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.
+ #mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp
+
+
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of
+ the community provided yum/apt repositories to gain access to the &PRODUCT; binaries.
+
+
+
+ After you have configured an appropriate yum or apt repository, you may execute the
+ one of the following commands as appropriate for your environment in order to upgrade
+ &PRODUCT;: #yum update cloud-*
+ #apt-get update
+#apt-get upgrade cloud-*
+
+ You will, of course, have to agree to the changes suggested by Yum or APT.
+
+
+ If you have made changes to your existing copy of the file components.xml in your
+ previous-version CloudStack installation, the changes will be preserved in the upgrade.
+ However, you need to do the following steps to place these changes in a new version of
+ the file which is compatible with version 4.0.0-incubating.
+
+ How will you know whether you need to do this? If the upgrade output in the
+ previous step included a message like the following, then some custom content was
+ found in your old components.xml, and you need to merge the two files:
+
+ warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+
+
+ Make a backup copy of your
+ /etc/cloud/management/components.xml file. For
+ example:
+ #mv/etc/cloud/management/components.xml/etc/cloud/management/components.xml-backup
+
+
+ Copy /etc/cloud/management/components.xml.rpmnew to create
+ a new /etc/cloud/management/components.xml:
+ #cp -ap /etc/cloud/management/components.xml.rpmnew/etc/cloud/management/components.xml
+
+
+ Merge your changes from the backup file into the new components.xml file.
+ #vi/etc/cloud/management/components.xml
+
+
+
+
+
+ If you have made changes to your existing copy of the
+ /etc/cloud/management/db.properties file in your previous-version
+ CloudStack installation, the changes will be preserved in the upgrade. However, you need
+ to do the following steps to place these changes in a new version of the file which is
+ compatible with version 4.0.0-incubating.
+
+
+ Make a backup copy of your file
+ /etc/cloud/management/db.properties. For example:
+ #mv/etc/cloud/management/db.properties/etc/cloud/management/db.properties-backup
+
+
+ Copy /etc/cloud/management/db.properties.rpmnew to create a
+ new /etc/cloud/management/db.properties:
+ #cp -ap /etc/cloud/management/db.properties.rpmnewetc/cloud/management/db.properties
+
+
+ Merge your changes from the backup file into the new db.properties file.
+ #vi/etc/cloud/management/db.properties
+
+
+
+
+ On the management server node, run the following command. It is recommended that you
+ use the command-line flags to provide your own encryption keys. See Password and Key
+ Encryption in the Installation Guide.
+ #cloud-setup-encryption -e encryption_type -m management_server_key -k database_key
+ When used without arguments, as in the following example, the default encryption
+ type and keys will be used:
+
+
+ (Optional) For encryption_type, use file or web to indicate the technique used
+ to pass in the database encryption password. Default: file.
+
+
+ (Optional) For management_server_key, substitute the default key that is used to
+ encrypt confidential parameters in the properties file. Default: password. It is
+ highly recommended that you replace this with a more secure value
+
+
+ (Optional) For database_key, substitute the default key that is used to encrypt
+ confidential parameters in the CloudStack database. Default: password. It is highly
+ recommended that you replace this with a more secure value.
+
+
+
+
+ Repeat steps 10 - 14 on every management server node. If you provided your own
+ encryption key in step 14, use the same key on all other management servers.
+
+
+ Start the first Management Server. Do not start any other Management Server nodes
+ yet.
+ # service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete.
+ You should see a message like "Complete! Done." After confirmation, start the other
+ Management Servers one at a time by running the same command on each node.
+
+
+ Start all Usage Servers (if they were running on your previous version). Perform
+ this on each Usage Server host.
+ # service cloud-usage start
+
+
+ (KVM only) Additional steps are required for each KVM host. These steps will not
+ affect running guests in the cloud. These steps are required only for clouds using KVM
+ as hosts and only on the KVM hosts.
+
+
+ Configure your CloudStack package repositories as outlined in the Installation
+ Guide
+
+
+ Stop the running agent.
+ # service cloud-agent stop
+
+
+ Update the agent software with one of the following command sets as
+ appropriate.
+ #yum update cloud-*
+
+ #apt-get update
+#apt-get upgrade cloud-*
+
+
+
+ Start the agent.
+ # service cloud-agent start
+
+
+ Copy the contents of the agent.properties file to the new
+ agent.properties file by using the following command
+ sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.properties
+
+
+ Start the cloud agent and cloud management services.
+
+
+ When the Management Server is up and running, log in to the CloudStack UI and
+ restart the virtual router for proper functioning of all the features.
+
+
+
+
+ Log in to the CloudStack UI as admin, and check the status of the hosts. All hosts
+ should come to Up state (except those that you know to be offline). You may need to wait
+ 20 or 30 minutes, depending on the number of hosts.
+ Do not proceed to the next step until the hosts show in the Up state. If the hosts
+ do not come to the Up state, contact support.
+
+
+ Run the following script to stop, then start, all Secondary Storage VMs, Console
+ Proxy VMs, and virtual routers.
+
+
+ Run the command once on one management server. Substitute your own IP address of
+ the MySQL instance, the MySQL user to connect as, and the password to use for that
+ user. In addition to those parameters, provide the "-c" and "-r" arguments. For
+ example:
+ #nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+#tail -f sysvm.log
+ This might take up to an hour or more to run, depending on the number of
+ accounts in the system.
+
+
+ After the script terminates, check the log to verify correct execution:
+ #tail -f sysvm.log
+ The content should be like the following:
+
+Stopping and starting 1 secondary storage vm(s)...
+Done stopping and starting secondary storage vm(s)
+Stopping and starting 1 console proxy vm(s)...
+Done stopping and starting console proxy vm(s).
+Stopping and starting 4 running routing vm(s)...
+Done restarting router(s).
+
+
+
+
+
+ If you would like additional confirmation that the new system VM templates were
+ correctly applied when these system VMs were rebooted, SSH into the System VM and check
+ the version.
+ Use one of the following techniques, depending on the hypervisor.
+
+ XenServer or KVM:
+ SSH in by using the link local IP address of the system VM. For example, in the
+ command below, substitute your own path to the private key used to log in to the
+ system VM and your own link local IP.
+
+ Run the following commands on the XenServer or KVM host on which the system VM is
+ present:
+ #ssh -i private-key-pathlink-local-ip -p 3922
+# cat /etc/cloudstack-release
+ The output should be like the following:
+ Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+
+ ESXi
+ SSH in using the private IP address of the system VM. For example, in the command
+ below, substitute your own path to the private key used to log in to the system VM and
+ your own private IP.
+
+ Run the following commands on the Management Server:
+ #ssh -i private-key-pathprivate-ip -p 3922
+#cat/etc/cloudstack-release
+
+ The output should be like the following:
+ Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version
+ supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2
+ and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating
+ Installation Guide.
+
+
+ Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer
+ v6.0.2 hypervisor hosts.
+
+
+ Disconnect the XenServer cluster from CloudStack.
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under
+ Clusters, click View All. Select the XenServer cluster and click Actions -
+ Unmanage.
+ This may fail if there are hosts not in one of the states Up, Down,
+ Disconnected, or Alert. You may need to fix that before unmanaging this
+ cluster.
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack
+ UI to check on the status. When the cluster is in the unmanaged state, there is no
+ connection to the hosts in the cluster.
+
+
+ To clean up the VLAN, log in to one XenServer host and run:
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+ Prepare the upgrade by running the following on one XenServer host:
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+ If you see a message like "can't eject CD", log in to the VM and umount the CD,
+ then run this script again.
+
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master,
+ then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the
+ hotfixes to the host. Place them in a temporary folder such as /root or /tmp.
+ On the Xen pool master, upload the hotfix with this command:
+ xe patch-upload file-name=XS602E003.xsupdate
+ Make a note of the output from this command, which is a UUID for the hotfix
+ file. You'll need it in another step later.
+
+ (Optional) If you are applying other hotfixes as well, you can repeat the
+ commands in this section with the appropriate hotfix number. For example,
+ XS602E004.xsupdate.
+
+
+
+ Manually live migrate all VMs on this host to another host. First, get a list of
+ the VMs on this host:
+ # xe vm-list
+ Then use this command to migrate each VM. Replace the example host name and VM
+ name with your own:
+ #xe vm-migrate live=true host=host-name vm=VM-name
+
+ Troubleshooting
+ If you see a message like "You attempted an operation on a VM which requires
+ PV drivers to be installed but the drivers were not detected," run:
+ /opt/xensource/bin/make_migratable.sh
+ b6cf79c8-02ee-050b-922f-49583d9f1a14.
+
+
+
+ Apply the hotfix. First, get the UUID of this host:
+ # xe host-list
+ Then use the following command to apply the hotfix. Replace the example host
+ UUID with the current host ID, and replace the hotfix UUID with the output from the
+ patch-upload command you ran on this machine earlier. You can also get the hotfix
+ UUID by running xe patch-list.
+ xe patch-apply host-uuid=host-uuid
+ uuid=hotfix-uuid
+
+
+ Copy the following files from the CloudStack Management Server to the
+ host.
+
+
+
+
+
+
+ Copy from here...
+ ...to here
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+ /opt/xensource/sm/NFSSR.py
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+ /opt/xensource/bin/setupxenserver.sh
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+
+
+
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud
+ Support Pack.
+
+
+ Download the CSP software onto the XenServer host from one of the following
+ links:
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+ Extract the file:
+ # tar xf xenserver-cloud-supp.tgz
+
+
+ Run the following script:
+ # xe-install-supplemental-pack
+ xenserver-cloud-supp.iso
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable
+ Open vSwitch (OVS):
+ # xe-switch-network-backend bridge
+
+
+
+
+ Reboot this XenServer host.
+
+
+ Run the following:
+ /opt/xensource/bin/setupxenserver.sh
+
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or
+ directory" appears, you can safely ignore it.
+
+
+
+ Run the following:
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk
+ '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+
+
+
+ On each slave host in the Xen pool, repeat these steps, starting from "manually
+ live migrate VMs."
+
+
+
+
+
+
+
+ Version 4.0.0-incubating
+
+ What’s New in 4.0.0-incubating
+ Apache CloudStack 4.0.0-incubating includes the following new features:
+
+ Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This
+ feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier
+ applications. These tiers are deployed on different VLANs that can communicate with each
+ other. You can provision VLANs to the tiers your create, and VMs can be deployed on
+ different tiers, such as Web, Application, or Database. The VLANs are connected to a
+ virtual router, which facilitates communication between the VMs. In effect, you can
+ segment VMs by means of VLANs into different networks that can host multi-tier
+ applications. Such segmentation by means of VLANs logically separate application VMs for
+ higher security and lower broadcasts, while remaining physically connected to the same
+ device.
+ This feature is supported on XenServer and VMware hypervisors.
+
+
+ Site-to-Site VPN
+ A Site-to-Site VPN connection helps you establish a secure connection from an
+ enterprise datacenter to the cloud infrastructure. This allows users to access the guest
+ VMs by establishing a VPN connection to the virtual router of the account from a device in
+ the datacenter of the enterprise. Having this facility eliminates the need to establish
+ VPN connections to individual VMs.
+ The supported endpoints on the remote datacenters are:
+
+
+ Cisco ISR with IOS 12.4 or later
+
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
+
+
+
+ Local Storage Support for Data Volumes
+ You can now create data volumes on local storage. The data volume is placed on the
+ same XenServer host as the VM instance that is attached to the data volume. These local
+ data volumes can be attached to virtual machines, detached, re-attached, and deleted just
+ as with the other types of data volume. In earlier releases of CloudStack, only the root
+ disk could be placed in local storage.
+ Local storage is ideal for scenarios where persistence of data volumes and HA is not
+ required. Some of the benefits include reduced disk I/O latency and cost reduction from
+ using inexpensive local disks.
+ In order for local volumes to be used, the feature must be enabled for the
+ zone.
+ You can create a data disk offering for local storage. When a user creates a new VM,
+ they can select this disk offering in order to cause the data disk volume to be placed in
+ local storage.
+ You can not migrate a VM that has a volume in local storage to a different host, nor
+ migrate the volume itself away to a different host. If you want to put a host into
+ maintenance mode, you must first stop any VMs with local data volumes on that host.
+ Local storage support for volumes is available for XenServer, KVM, and VMware
+ hypervisors.
+
+
+ Tags
+ 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 new 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.
+ A new optional input parameter, "tags," has been added to 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:
+ 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 new "tags" input parameter:
+
+
+ listVirtualMachines
+
+
+ listVolumes
+
+
+ listSnapshots
+
+
+ listNetworks
+
+
+ listTemplates
+
+
+ listIsos
+
+
+ listFirewallRules
+
+
+ listPortForwardingRules
+
+
+ listPublicIpAddresses
+
+
+ listSecurityGroups
+
+
+ listLoadBalancerRules
+
+
+ listProjects
+
+
+ listVPCs
+
+
+ listNetworkACLs
+
+
+ listStaticRoutes
+
+
+
+
+ AWS API Changes for Tags
+ Some changes have been made to the Amazon Web Services API compatibility support in
+ order to accommodate the new tagging feature.
+ New APIs:
+
+
+
+
+
+
+
+ New API
+
+
+ Description
+
+
+
+
+
+
+ ec2-create-tags
+
+
+ Add tags to one or more resources.
+
+
+
+
+ ec2-delete-tags
+
+
+ Remove tags from one or more resources.
+
+
+
+ ec2-describe-tags
+
+ Show currently defined tags.
+
+
+
+
+
+ Changed APIs:
+
+
+
+
+
+
+
+ Changed API
+
+
+ Description
+
+
+
+
+
+ ec2-describe-images
+
+ Output now shows tags defined for each image.
+
+
+
+
+ ec2-describe-instances
+
+
+ Output now shows tags defined for each image.
+ The following filters can now be passed in to limit the output result set:
+ tag-key, tag-value and tag:key
+
+
+
+
+ ec2-describe-snapshots
+
+
+ Output now shows tags defined for each image.
+ The following filters can now be passed in to limit the output result set:
+ tag-key, tag-value and tag:key
+
+
+
+ ec2-describe-volumes
+
+ Output now shows tags defined for each image.
+ The following filters can now be passed in to limit the output result set:
+ tag-key, tag-value and tag:key
+
+
+
+
+
+
+
+ Secure Console Access on XenServer
+ With the addition of Secure Console feature, users can now securely access the VM
+ consoles on the XenServer hypervisor. You can either SSH or use the View Console option in
+ the Management Server to securely connect to the VMs on the XenServer host. The Management
+ Server uses the xapi API to stream the VM consoles. However, there is no change in the way
+ you can access the console of a VM. This feature is supported on XenServer 5.6 and 6.0
+ versions.
+
+
+ Stopped VM
+ This release supports creating VMs without starting them on the backend. You can
+ determine whether the VM needs to be started as part of the VM deployment. A VM can be
+ deployed in two ways: create and start a VM (the default method); create a VM and leave it
+ in the stopped state.
+ A new request parameter, startVM, is introduced in the deployVm API to support the
+ stopped VM feature. The possible values are:
+
+
+ true - The VM starts as a part of the VM deployment
+
+
+ false - The VM is left in stopped state at the end of the VM deployment
+
+
+
+
+ Uploading an Existing Volume to a Virtual Machine
+ Existing data can now be made accessible to a virtual machine. This is called
+ uploading a volume to the VM. For example, this is useful to upload data from a local file
+ system and attach it to a VM. Root administrators, domain administrators, and end users
+ can all upload existing volumes to VMs. The upload is performed by using HTTP. The
+ uploaded volume is placed in the zone's secondary storage.
+ This functionality is supported for the following hypervisors:
+
+
+ Hypervisor : Disk Image Format
+
+
+ XenServer : VHD
+
+
+ VMware : OVA
+
+
+ KVM : QCOW2
+
+
+
+
+
+ Dedicated High-Availability Hosts
+ One or more hosts can now be designated for use only by high-availability (HA) enabled
+ VMs that are restarted due to a host failure. Setting up a pool of such dedicated HA hosts
+ as the recovery destination for all HA-enabled VMs make it easier to determine which VMs
+ are restarted as part of the high-availability function. You can designate a host as a
+ dedicated-HA restart node only if the Dedicated HA Hosts feature is enabled by setting the
+ appropriate global configuration parameter.
+
+
+ Support for Amazon Web Services API
+ This release supports Amazon Web Services APIs, including Elastic Compute Cloud (EC2)
+ API. Fidelity with the EC2 API and the installation experience for this functionality are
+ both enhanced. In prior releases, users were required to install a separate component
+ called CloudBridge, in addition to installing the Management Server. For new installations
+ of CloudStack 4.0.0-incubating, this software is installed automatically along with
+ CloudStack and runs in a more closely integrated fashion. The feature is disabled by
+ default, but can be easily enabled by setting the appropriate global configuration
+ parameter and performing a few setup steps.
+
+
+ The Nicira NVP Plugin
+ The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized
+ network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating
+ this plug-in supports the Connectivity service. This service is responsible for creating
+ Layer 2 networks supporting the networks created by guests. When a tenant creates a new
+ network, instead of a traditional VLAN, a logical network will be created by sending the
+ appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira
+ NVP versions 2.1.0, 2.2.0 and 2.2.1.
+
+
+ Support for CAStor Cluster
+ CloudStack 4.0.0-incubating supports using a CAStor cluster as the back-end storage
+ system for a CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends
+ the existing storage classes and allows the storage configuration attribute to point to a
+ CAStor cluster. This feature makes use of the CloudStack server's local disk to spool
+ files before writing them to CAStor when handling the PUT operations. However, a file must
+ be successfully written into the CAStor cluster prior to the return of a success code to
+ the S3 client to ensure that the transaction outcome is correctly reported.
+ The S3 multipart file upload is not supported in this release. You are prompted with
+ proper error message if a multipart upload is attempted.
+
+
+ Clustered Logical Volume Manager Support for KVM
+ This release adds Clustered Logical Volume Manager (CLVM) storage support for KVM
+ hosts. With this support, you can use CLVM as primary storage.
+ The CLVM support for KVM allows root and data disks (primary storage) to reside on
+ Linux logical volumes. The administrators are required to configure CLVM on the KVM hosts
+ independent of CloudStack. When the volume groups are available, an administrator can
+ simply add primary storage of type CLVM, providing the volume group name. Then CloudStack
+ creates and manages logical volumes as needed.
+ CLVM also supports Snapshots. CloudStack creates an LVM snapshot, copy the applicable
+ logical volume to the secondary storage in the qcow2 format, and then delete the LVM
+ snapshot.
+
+
+ Rados Block Device Support for KVM
+ You can now use Rados Block Device (RBD) to run instances on Apache CloudStack
+ 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using
+ RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least
+ 0.10 with RBD enabled on the KVM host
+ Create a disk offering for RBD so that you can ensure that StoragePoolAllocator
+ chooses the RBD pool to deploy instances.
+
+
+
+ Issues Fixed in 4.0.0-incubating
+ Many bugs include a defect number that reflects the bug number that was held in the bug
+ tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira to manage its bugs, so
+ some of the bugs that are referenced here may not be available to view. However, we are
+ still including them for completeness.
+
+
+
+
+
+
+
+ Defect
+
+
+ Description
+
+
+
+
+
+ Many
+ vSphere 5.0 now has GA support. Formerly only Beta support was
+ provided.
+
+
+ CS-16135
+ Creating volumes after upgrading from snapshot taken in 2.2.14 no longer
+ deletes the snapshot physically from the secondary storage.
+
+
+ CS-16122
+ In a site-to-site VPN setup, alerts are generated when the VPC virtual
+ router is rebooted with multiple vpn connections.
+
+
+ CS-16022
+ If host connection fails due to a database error, host now disconnects
+ and the Managerment Server id is removed.
+
+
+ CS-16011
+ Name of network offering is no longer truncated due to too-narrow field
+ width in Add Guest Network dialog box.
+
+
+
+ CS-15978
+ When the virtual router and its host go down, the high availability
+ mechanism now works for the virtual router.
+
+
+
+ CS-15921
+ The 2.2.x security group script now accounts for the VMs created in the
+ version 2.1 timeframe.
+
+
+
+ CS-15919
+ A level parameter is added to the listVolumes command; therefore queries
+ return the response more quickly.
+
+
+ CS-15904
+ Upgrade from version 2.2.14 to CloudStack-3.0.5-0.2944-rhel5 works as
+ expected. The upgrade script,
+ /usr/share/cloud/setup/db/schema-2214to30-cleanup.sql, works as
+ expected.
+
+
+ CS-15879
+ The database upgrade from version 3.0.4 to 3.0.5 works as
+ expected.
+
+
+
+ CS-15807
+ Network label for OVM now available in UI.
+
+
+
+ CS-15779
+ When the thumbnail is requested, the console session will not be
+ terminated.
+
+
+
+ CS-15778
+ Fetching a VM thumbnail now gets a thumbnail of appropriate visual
+ dimensions.
+
+
+
+ CS-15734
+ KVM Snapshots no longer shows incorrect disk usage.
+
+
+ CS-15733
+ The domainId parameter for the listNetworks command now lists the
+ resources belonging to the domain specified.
+
+
+ CS-15676
+ Stopping the router no longer fails with the null pointer
+ exception.
+
+
+
+ CS-15648
+ If creating a volume from a snapshot fails, the error is reported on the
+ UI but the volume is stuck in the creating state.
+
+
+
+ CS-15646
+ createFirewallRule API no longer causes null pointer
+ exception.
+
+
+ CS-15628
+ In a KVM host, the high availability mechanism no longer takes a long
+ time to migrate VMs to another KVM host if there are multiple storage
+ pools.
+
+
+ CS-15627
+ Metadata instance-id and vm-id for existing VMs stays the same after
+ upgrade.
+
+
+ CS-15621
+ Solved difficulty with allocating disk volumes when running multiple VM
+ deployment in parallel.
+
+
+ CS-15603
+ CloudStack now stop the VMs when destroyVM command is
+ called.
+
+
+ CS-15586
+ Public Vlan for an account no longer fails if multiple physical networks
+ are present.
+
+
+ CS-15582
+ The dns-name filter is now supported for ec2-describe-instances in the
+ Amazon Web Services API compatibility commands. The filter maps to the name of a
+ user VM.
+
+
+ CS-15503
+ An IP address which has static NAT rules can now be released.
+ Subsequently, restarting this network after it was shutdown can
+ succeed.
+
+
+ CS-15464
+ Can now delete static route whose state is set to Revoke.
+
+
+ CS-15443
+ Creating a firewall rule no longer fails with an internal server
+ error.
+
+
+ CS-15398
+ Corrected technique for programming DNS on the user VMs.
+
+
+ CS-15356
+ Internal DNS 2 entry now correctly shown in UI.
+
+
+ CS-15335
+ The CloudBridge S3 Engine now connects to the database by using the
+ deciphered password in the db.properties file.
+
+
+ CS-15318
+ UI now correctly prevents the user from stopping a VM that is in the
+ Starting state.
+
+
+ CS-15307
+ Fixed Japanese localization of instance statuses in the Instances
+ menu.
+
+
+ CS-15278
+ The deployment planner no longer takes long time to locate a suitable
+ host to deploy VMs when large number of clusters are present.
+
+
+ CS-15274
+ Creating a VLAN range using Zone ID without network ID now
+ succeeds.
+
+
+ CS-15243
+ Now check to be sure source NAT and VPN have same
+ provider.
+
+
+ CS-15232
+ Ensure that networks using external load balancer/firewall in 2.2.14 or
+ earlier can properly upgrade.
+
+
+ CS-15200
+ No exception when trying to attach the same volume while attaching the
+ first volume is in progress.
+
+
+ CS-15173
+ Additional cluster can no longer be added with same VSM IP address as
+ another cluster.
+
+
+ CS-15167
+ AWS API calls now honor the admin account's ability to view or act on the
+ resources owned by the regular users.
+
+
+ CS-15163
+ The minimum limit is not honored when there is not enough capacity to
+ deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2>
+ option is used to deploy multiple VMs.
+
+
+ CS-15157
+ Can now add/enable service providers for multiple physical networks
+ through the UI.
+
+
+ CS-15145
+ AWS API call ec2-register has better error handling for negative
+ cases.
+
+
+ CS-15122
+ Filters now supported for AWS API call
+ ec2-describe-availability-zones.
+
+
+ CS-15120
+ Actions column in UI of Volume page now shows action
+ links.
+
+
+ CS-15099
+ Buttons no longer overlap text on Account Deletion confirmation page in
+ UI.
+
+
+ CS-15095
+ Ensures you can not create a VM with a CPU frequency greater than the
+ host CPU frequency.
+
+
+ CS-15094
+ CPU cap now set properly in VMware.
+
+
+ CS-15077
+ NullPointerException is no longer observed while executing the command to
+ list the public IP in a basic zone created with the default shared NetScaler EIP
+ and ELB network offering.
+
+
+ CS-15044
+ UI now provides option to view the list of instances which are part of
+ the guest network.
+
+
+ CS-15026
+ UI in Deploy VM dialog now lists only templates or ISOs depending on
+ which is selected in previous dialog.
+
+
+ CS-14989
+ In KVM, the Create Instance wizard now shows only templates from the
+ current (KVM) zone.
+
+
+ CS-14986, CS-14985
+ Listing filters works as expected in the ec2-describe-volumes and
+ ec2-describe-snapshots commands.
+
+
+ CS-14964
+ Automatically starting the Console Proxy no longer fails due to its
+ missing volume on the primary storage
+
+
+ CS-14907
+ User is now correctly prevented from trying to download an uploaded
+ volume which has not yet been moved to primary storage.
+
+
+ CS-14879
+ When a user VM is stopped or terminated, the static NAT associated with
+ this VM is now disabled. This public IP address is no longer owned by this account
+ and can be associated to any other user VM.
+
+
+ CS-14854
+ Only the admin user can change the template permission to Public, so this
+ option is removed from the UI for domain Admins and regular Users.
+
+
+ CS-14817
+ While checking if network has any external provider, CloudStack will
+ consider all providers in the network.
+
+
+ CS-14796
+ When deploying a VM with ec2-run-instances, userdata is now
+ encoded.
+
+
+ CS-14770
+ The API returns the keypair information when a VM is deployed with
+ sshkey. This affects the API commands related to virtual machines
+ (deployVirtualMachine, listVirtualMachines, ... *VirtualMachine), as well as the
+ corresponding AWS APIs.
+
+
+ CS-14724
+ UI no longer displays the dropdown list of isolation method choices if
+ sdn.ovs.controller is false.
+
+
+ CS-14345
+ Logout API returns XML header.
+
+
+ CS-14724
+ Host IPs now associated with appropriate IPs according to traffic
+ type.
+
+
+ CS-14253
+ Can now delete and re-create port forwarding rule on same
+ firewall.
+
+
+ CS-14724
+ UI no longer displays the dropdown list of isolation method choices if
+ sdn.ovs.controller is false.
+
+
+ CS-14452
+ Data disk volumes are now automatically copied from one cluster to
+ another.
+
+
+ CS-13539
+ Windows VM can get IP after reboot.
+
+
+ CS-13537
+ When user tries to delete a domain that contains sub-domains, an error
+ message is now sent to convey the reason for the delete failure.
+
+
+ CS-13153
+ System VMs support HTTP proxy.
+
+
+ CS-12642
+ Added Close button to Select Project list view popup in
+ UI.
+
+
+ CS-12510
+ Deleting and reinserting host_details no longer causes
+ deadlocks.
+
+
+ CS-12407
+ F5 and Netscaler - when dedicated is selected, capacity field is
+ disabled.
+
+
+ CS-12111
+ Email validation for edit user form.
+
+
+ CS-10928
+ Network read/write values now always positive numbers.
+
+
+ CS-15376, CS-15373
+ The AWS APIs (EC2 and S3) now listen on the 7080 port and send request to
+ CloudStack on the 8080 port just as any other clients of
+ CloudStack.
+
+
+ CS-13944
+ The CloudStack 2.2.x to 3.0.x database upgrade for multiple physical
+ networks is now supported.
+
+
+ CS-15300
+ The admin accounts of a domain now honour the limits imposed on that
+ domain just like the regular accounts do. A domain admin now is not allowed to
+ create an unlimited number of instances, volumes, snapshots, and so
+ on.
+
+
+ CS-15396
+ The CloudStack database now contain the UUD information after the 2.2.14
+ to 3.0.4 upgrade.
+
+
+ CS-15450
+ Upgrade from 2.2.14 to 3.0.4 no longer fails on a VMware
+ host.
+
+
+ CS-15449
+ Running cloudstack-aws-api-register no longer fails with the "User
+ registration failed with error: [Errno 113] No route to host"
+ error.
+
+
+ CS-15455
+ The iptable rules are configured to open the awsapi port (7080) as part
+ of the installation.
+
+
+ CS-15429
+ While creating an instance with data volume, disk offering also is
+ considered while checking the account limit on volume resources.
+
+
+ CS-15414
+ After the 2.2.14 to 3.0.4 upgrade, the value of the global parameter
+ xen.guest.network.device is now decrypted before setting the traffic
+ label.
+
+
+ CS-15382
+ During 2.2.14 to 3.0.4 upgrade, the hosts no longer go to the Alert state
+ if destroyed networks existed with non-existent tags prior to
+ upgrade.
+
+
+ CS-15323
+ CloudStack supports the following Citrix XenServer hotfixes: XS602E003,
+ XS602E004, and XS602E005.
+
+
+ CS-15430
+ Create snapshot now fails if creating a snapshot exceeds the snapshot
+ resource limit for a domain admin or a user account.
+
+
+ CS-14256
+ Virtual Router no longer remains in starting state for subdomain or user
+ on a KVM 3.0.1 prerlease host on RHEL 6.2.
+
+
+ CS-7495
+ Implemented a variety of Xen management host improvements.
+
+
+ CS-8105
+ NFS v4 for primary storage now works as expected on KVM
+ hosts.
+
+
+ CS-9989
+ The error messages returned during VM deployment failure will have much
+ more details than before.
+
+
+ CS-12584
+ You can no longer add security groups not supported by the hypervisor in
+ use.
+
+
+ CS-12705
+ When creating a Network offering by using SRX as the service provider for
+ SourceNAT servcies, an option is given in the CloudStack UI now to set the
+ source_nat type to "per Zone"/"per account".
+
+
+ CS-12782
+ Assigning a VM from Basic to Advanced zone no longer ignores the network
+ ID. A warning message is displayed for VM movements across zones.
+
+
+ CS-12591
+ Broadcast Address on the Second Public IP NIC is now
+ corrected.
+
+
+ CS-13272
+ When a user is deleted, all the associated properties, such as IPs and
+ virtual routers, are now deleted.
+
+
+ CS-13377
+ Creating template from a root disk of a stopped instance now provides an
+ option to make it a "Featured template".
+
+
+ CS-13500
+ Reaching the first guest VM by using its public IP from the second guest
+ VM no longer fails.
+
+
+ CS-13853
+ The default gateway can no longer be 0.0.0.0 in the Secondary Storage VM
+ (SSVM).
+
+
+ CS-13863
+ The queryAsyncJobResult command in XML format now returns the correct
+ UUIDs.
+
+
+ CS-13867
+ Corrected CSP xenserver-cloud-supp.tgz for XenServer 5.6 and
+ 6.0.
+
+
+ CS-13904
+ Labels and values for the service offerings CPU and memory are now
+ consistent.
+
+
+ CS-13998
+ The SSVM kernel panic issue is fixed on XenServer.
+
+
+ CS-14090
+ The issue is fixed where running the VMware snapshots randomly fails with
+ the ArrayIndexOutOfBoundsException error.
+
+
+ CS-14021
+ The java.lang.OutOfMemoryError is fixed on the Management
+ Server.
+
+
+ CS-14025
+ The Python Eggs are provided to easily package the test client for each
+ branch of CloudStack.
+
+
+ CS-14068
+ Resetting the VM password through the CloudStack UI no longer causes any
+ error.
+
+
+ CS-14156
+ The pod which has the administrator's virtual router is no longer
+ selected while creating the virtual routers for guests.
+
+
+ CS-14182
+ The users can now delete their ISOs as normal users.
+
+
+ CS-14185
+ The listOSTypes API now filters out the types of operating system by
+ using the keywords.
+
+
+ CS-14204
+ The cloud-setup-bonding.sh command no longer generates the "command not
+ found" error.
+
+
+ CS-14214
+ The Specify VLAN option cannot be enabled now for an isolated Network
+ offering with SourceNAT enabled.
+
+
+ CS-14234
+ Sending project invite email to an account now requires SMTP configured
+ in CloudStack.
+
+
+ CS-14237
+ The garbage collector of the primary storage no longer fails when the
+ first host in the cluster is not up.
+
+
+ CS-14241
+ Custom Volume Disk Offering is now matching the Global configuration
+ value.
+
+
+ CS-14270
+ The listNetworks API no longer assumes that the broadcast type is always
+ VLAN.
+
+
+ CS-14319
+ The internal name of the VM is no longer present in the error message
+ that is displayed to a domain administrator.
+
+
+ CS-14321
+ The listVolumes API call now returns a valid value for the isExtractable
+ parameter for the ISO-derived disk and data disk volumes.
+
+
+ CS-14323
+ Invalid API calls will now give valid response in json/xml
+ format.
+
+
+ CS-14339
+ Custom Disk Size will now allow values larger than 100GB.
+
+
+ CS-14357
+ The ConsoleProxyLoadReportCommand is no longer fired
+ continuously.
+
+
+ CS-14421
+ Fixed the issue of virtual router deployments. The DHCP entries can now
+ be assigned to the router.
+
+
+ CS-14555
+ Unzipped downloaded template MD5SUM will no longer override the zipped
+ template MD5SUM in the database.
+
+
+ CS-14598
+ The complete screen of the running VM is now displayed in the console
+ proxy.
+
+
+ CS-14600
+ Windows or Linux based consoles are no longer lost upon rebooting
+ VMs.
+
+
+ CS-14784
+ Multiple subnets with the same VLAN now work as expected.
+
+
+ CS-13303, 14874, 13897, 13944, 14088, 14190
+ A variety of upgrade issues have been fixed in release
+ 3.0.3.
+
+
+ CS-15080
+ Setting a private network on a VLAN for VMWare environment is now
+ supported.
+
+
+ CS-15168
+ The console proxy now works as expected and no exception is shown in the
+ log after upgrading from version 2.2.14 to 3.0.2.
+
+
+ CS-15172
+ Version 3.0.2 now accepts the valid public key.
+
+
+
+
+
+
+ Known Issues in 4.0.0-incubating
+
+
+
+
+
+
+
+ Issue ID
+
+
+ Description
+
+
+
+
+
+ CLOUDSTACK-301
+ Nexus 1000v DVS integration is not functional
+ This source code release includes some partial functionality to support the
+ Cisco Nexus 1000v Distributed Virtual Switch within a VMware hypervisor
+ environment. The functionality is not complete at this time.
+
+
+
+ CLOUDSTACK-368
+ OVM - cannot create guest VM
+ This source code release has regressed from the CloudStack 2.2.x code
+ and is unable to support Oracle VM (OVM).
+
+
+
+ CLOUDSTACK-279
+ Deleting a project fails when executed by the regular user. This works as
+ expected for root/domain admin. To workaround, perform either of the
+ following:
+
+ Use the account cleanup thread which will eventually complete the project
+ deletion.
+
+
+ Execute the call as the root/domain admin on behalf of the regular
+ user.
+
+
+
+
+
+ CS-16067
+ The command=listTags&key=city command does not work as expected. The
+ command does not return tags for the resources of the account with the tag, city
+
+
+
+
+ CS-16063
+ The current values of volumes and snapshots are incorrect when using KVM
+ as a host. To fix this, the database upgrade codes, volumes.size and
+ snapshots.size, should be changed to show the virtual sizes.
+
+
+
+ CS-16058
+ Null pointer Exception while deleting the host after moving the host to
+ maintenance state.
+
+
+
+ CS-16045
+ Only the root administrator can handle the API keys. The domain
+ administrators are not allowed to create, delete, or retrieve API keys for the
+ users in their domain.
+
+
+
+ CS-16019
+ CIDR list in the Add VPN Customer Gateway dialog does not prompt the user
+ that they can provide a comma separated CIDRs if multiple CIDRs have to be
+ supplied.
+
+
+
+ CS-16015
+ Deleting a network is not supported when its network providers are
+ disabled.
+
+
+
+ CS-16012
+ Unable to delete a zone in the UI because the necessary cleanup cannot be
+ completed. When the hosts are removed, the expunge process fails to delete the
+ volumes as no hosts are present to send the commands to. Therefore, the storage
+ pool removal fails, and zone can't be cleaned and deleted.
+
+
+
+ CS-16011
+ Name of network offering might be truncated due to too-narrow field width
+ in Add Guest Network dialog box.
+
+
+
+ CS-15789
+ Invalid global setting prevents management server to restart. For
+ example, if you configure the "project.invite.timeout" parameter to "300" and
+ attempt to restart management server, it fails without throwing a warning or
+ setting the value to the default.
+
+
+
+ CS-15749
+ Restarting VPC is resulting in intermittent connection loss to the port
+ forwarding and StaticNAT rules.
+
+
+
+ CS-15690
+ The IpAssoc command failed as a part of starting the virtual router, but
+ the final start result is reported as succes.
+
+
+
+ CS-15672, CS-15635
+ The FQDN of the VM is not configured if it is deployed as a part of
+ default shared network and isolated guest network
+ (DefaultIsolatedNetworkOfferingWithSourceNatService).
+
+
+
+ CS-15634
+ The FQDN of a VM that is deployed as a part of both a shared network and
+ default isolated guest network has the suffix of the shared network instead of the
+ default isolated guest network.
+
+
+
+ CS-15576
+ Stopping a VM on XenServer creates a backlog of API commands. For
+ example, the Attach volume calls become delayed while waiting for the
+ stopVirtualMachine command to be executed.
+
+
+
+ CS-15569
+ Misleading error message in the exception when creating a StaticNAT rule
+ fails in a VPC.
+
+
+
+ CS-15566
+ External device such as Netscaler is not supported in VPC.
+
+
+ CS-15557
+ Intermittent traffic loss in the VPN connection if Juniper is the remote
+ router and the life time is 300 seconds.
+
+
+
+ CS-15361
+ Egress rules are not working in NetScaler loadbalancer.
+
+
+
+ CS-15163
+ The minimum limit is not honored when there is not enough capacity to
+ deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2>
+ option is used to deploy multiple VMs.
+
+
+ CS-15105
+ The cloud-sysvmadm script does not work if the integration.api.port
+ parameter is set to any port other than 8096.
+
+
+ CS-15092
+ Connecting to the guest VMs through SSH is extremely slow, and it results
+ in connection timeout.
+
+
+ CS-15037
+ Hairpin NAT is not supported when NetScaler is used for
+ EIP.
+
+
+ CS-15009
+ The port_profile table will not be populated with port profile
+ information. In this release, CloudStack directly connects to the VSM for all the
+ port profile operations; therefore, no port profile information is
+ cached.
+
+
+ CS-14939
+ Adding a VMware cluster is not supported when the Management Network is
+ migrated to the Distributed Virtual Switch environment.
+
+
+ CS-14780
+ You are allowed to ping the elastic IP address of the VM even though no
+ ingress rule is set that allows the ICMP protocol.
+
+
+ CS-14756
+ Installing KVM on RHEL 6.2 will result in unreliable network performance.
+ Workaround: blacklist vhost-net. Edit /etc/modprobe.d/blacklist-kvm.conf and
+ include vhost-net.
+
+
+ CS-14346
+ The UpdateVirtualMachine API call does not check whether the VM is
+ stopped. Therefore, stop the VM manually before issuing this call.
+
+
+ CS-14303 (was 14537)
+ The IP addresses for a shared network are still being consumed even if no
+ services are defined for that network.
+
+
+ CS-14296 (was 14530)
+ OVM: Network traffic labels are not supported.
+
+
+ CS-14291 (was 14523)
+ The EIP/ELB network offering for basic zones does not support multiple
+ NetScalers.
+
+
+ CS-14275 (was 14506)
+ F5: Unable to properly remove a F5 device.
+
+
+ CS-14201 (was 14430)
+ VMWare: Template sizes are being reported different depending on whether
+ the primary storage is using ISCSI or NFS.
+
+
+ CS-13758 (was 13963)
+ vSphere: template download from templates created off of the root volume
+ does not work properly.
+
+
+ CS-13733 (was 13935)
+ vSphere: detaching an ISO from a restored VM instance
+ fails.
+
+
+ CS-13682 (was 13883)
+ Multiple NetScalers are not supported in Basic Networking.
+
+
+ CS-13599 (was 13359)
+ Programming F5/NetScaler rules can be better optimized.
+
+
+ CS-13337 (was 13518)
+ Security Groups are not supported in Advanced Networking
+
+
+ CS-13173 (was 13336)
+ vSphere: cross cluster volume migration does not work
+ properly.
+
+
+ CS-12714 (was 12840)
+ Capacity view is not available for pods or clusters.
+
+
+ CS-12624 (was 12741)
+ vSphere: maintenance mode will not live migrate system VM to another
+ host.
+
+
+
+ CS-15476
+
+
+ The 2.2.14 to 4.0.0-incubating upgrade fails if multiple untagged physical
+ networks exist before the upgrade.
+
+
+
+
+ CS-15407
+
+
+ After the 2.2.14 to 4.0.0-incubating upgrade, VLAN allocation on multiple
+ physical networks does not happen as expected.
+ To workaround this issue, follow the instructions given below:
+
+
+ Revert to your 2.2.14 setup.
+
+
+ Stop all the VMs with the isolated virtual networks in your cloud
+ setup.
+
+
+ Run following query to find if any networks still have the NICs
+ allocated:
+
+
+ Check if any virtual guest networks have the NICs allocated:
+ #SELECT DISTINCT op.id from `cloud`.`op_networks` op JOIN `cloud`.`networks` n on op.id=n.id WHERE nics_count != 0 AND guest_type = 'Virtual';
+
+
+ If this returns any network IDs, then ensure the following:
+
+
+ All the VMs are stopped.
+
+
+ No new VM is started.
+
+
+ Shutdown the Management Server.
+
+
+
+
+ Remove the NICs count for the virtual network IDs returned in step
+ (a), and set the NIC count to 0:
+ UPDATE `cloud`.`op_networks` SET nics_count = 0 WHERE id = enter id of virtual network
+
+
+ Restart the Management Server, and wait for all the networks to shut
+ down.
+
+ Networks shutdown is determined by the network.gc.interval and
+ network.gc.wait parameters.
+
+
+
+
+
+ Ensure that all the networks are shut down and all the guest VNETs are
+ free.
+
+
+ Run the upgrade script.
+ This allocates all your guest VNET ranges to the first physical
+ network.
+
+
+ By using the updatePhysicalNetwork API, reconfigure the VNET ranges for
+ each physical network as desired.
+
+
+ Start all the VMs.
+
+
+
+
+
+
+ CS-14680
+
+
+ CloudStack and LDAP user validation cannot happen simultaneously because the
+ user password is hashed and stored in the database, and LDAP requires the
+ passwords in plain text.
+ To work with the LDAP user, the MD5 hash should be disabled in the login
+ process by commenting the following variable in sharedFunctions.js file available
+ at /usr/share/cloud/management/webapps/client/scripts, and restart the
+ cloud-management service.
+ var md5HashedLogin = false;
+ However, if md5HashedLogin is set to false, the end user can login with the
+ LDAP credentials but not with the CloudStack user credentials.
+
+
+
+ CS-14346
+ The UpdateVirtualMachine API call does not check whether the VM is
+ stopped. Therefore, stop the VM manually before issuing this call.
+
+
+ CS-15130
+ Data disk volumes are not automatically copied from one cluster to
+ another.
+
+
+ CS-14780
+ You are allowed to ping the elastic IP address of the VM even though no
+ ingress rule is set that allows the ICMP protocol.
+
+
+ CS-14939
+ Adding a VMware cluster is not supported when the Management Network is
+ migrated to the Distributed Virtual Switch environment.
+
+
+ CS-15009
+ The port_profile table will not be populated with port profile
+ information. In this release, CloudStack directly connects to the VSM for all the
+ port profile operations; therefore, no port profile information is
+ cached.
+
+
+ CS-15037
+ Hairpin NAT is not supported when NetScaler is used for
+ EIP.
+
+
+ CS-15092
+ Connecting to the guest VMs through SSH is extremely slow, and it results
+ in connection timeout.
+
+
+ CS-15105
+ The cloud-sysvmadm script does not work if the integration.api.port
+ parameter is set to any port other than 8096.
+
+
+ CS-15163
+ The minimum limit is not honored when there is not enough capacity to
+ deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2>
+ option is used to deploy multiple VMs.
+
+
+
+
+
+
+
+ API Changes from 3.0.2 to 4.0.0-incubating
+
+ New API Commands in 4.0.0-incubating
+
+
+ createCounter (Adds metric counter)
+
+
+ deleteCounter (Deletes a counter)
+
+
+ listCounters (List the counters)
+
+
+ createCondition (Creates a condition)
+
+
+ deleteCondition (Removes a condition)
+
+
+ listConditions (List Conditions for the specific user)
+
+
+ createTags. Add tags to one or more resources. Example:
+ command=createTags
+&resourceIds=1,10,12
+&resourceType=userVm
+&tags[0].key=region
+&tags[0].value=canada
+&tags[1].key=city
+&tags[1].value=Toronto
+
+
+ deleteTags. Remove tags from one or more resources. Example:
+ command=deleteTags
+&resourceIds=1,12
+&resourceType=Snapshot
+&tags[0].key=city
+
+
+ listTags (Show currently defined resource tags)
+
+
+ createVPC (Creates a VPC)
+
+
+ listVPCs (Lists VPCs)
+
+
+ deleteVPC (Deletes a VPC)
+
+
+ updateVPC (Updates a VPC)
+
+
+ restartVPC (Restarts a VPC)
+
+
+ createVPCOffering (Creates VPC offering)
+
+
+ updateVPCOffering (Updates VPC offering)
+
+
+ deleteVPCOffering (Deletes VPC offering)
+
+
+ listVPCOfferings (Lists VPC offerings)
+
+
+ createPrivateGateway (Creates a private gateway)
+
+
+ listPrivateGateways (List private gateways)
+
+
+ deletePrivateGateway (Deletes a Private gateway)
+
+
+ createNetworkACL (Creates a ACL rule the given network (the network has to belong to
+ VPC))
+
+
+ deleteNetworkACL (Deletes a Network ACL)
+
+
+ listNetworkACLs (Lists all network ACLs)
+
+
+ createStaticRoute (Creates a static route)
+
+
+ deleteStaticRoute (Deletes a static route)
+
+
+ listStaticRoutes (Lists all static routes)
+
+
+ createVpnCustomerGateway (Creates site to site vpn customer gateway)
+
+
+ createVpnGateway (Creates site to site vpn local gateway)
+
+
+ createVpnConnection (Create site to site vpn connection)
+
+
+ deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
+
+
+ deleteVpnGateway (Delete site to site vpn gateway)
+
+
+ deleteVpnConnection (Delete site to site vpn connection)
+
+
+ updateVpnCustomerGateway (Update site to site vpn customer gateway)
+
+
+ resetVpnConnection (Reset site to site vpn connection)
+
+
+ listVpnCustomerGateways (Lists site to site vpn customer gateways)
+
+
+ listVpnGateways (Lists site 2 site vpn gateways)
+
+
+ listVpnConnections (Lists site to site vpn connection gateways)
+
+
+ markDefaultZoneForAccount (Marks a default zone for the current account)
+
+
+ uploadVolume (Uploads a data disk)
+
+
+
+
+ Changed API Commands in 4.0.0-incubating
+
+
+
+
+
+
+ API Commands
+ Description
+
+
+
+
+
+ copyTemplate
+ prepareTemplate
+ registerTemplate
+ updateTemplate
+ createProject
+ activateProject
+ suspendProject
+ updateProject
+ listProjectAccounts
+ createVolume
+ migrateVolume
+ attachVolume
+ detachVolume
+ uploadVolume
+ createSecurityGroup
+ registerIso
+ copyIso
+ updateIso
+ createIpForwardingRule
+ listIpForwardingRules
+ createLoadBalancerRule
+ updateLoadBalancerRule
+ createSnapshot
+
+
+ The commands in this list have a single new response parameter, and no other
+ changes.
+ New response parameter: tags(*)
+
+ Many other commands also have the new tags(*) parameter in addition to other
+ changes; those commands are listed separately.
+
+
+
+
+ rebootVirtualMachine
+ attachIso
+ detachIso
+ listLoadBalancerRuleInstances
+ resetPasswordForVirtualMachine
+ changeServiceForVirtualMachine
+ recoverVirtualMachine
+ startVirtualMachine
+ migrateVirtualMachine
+ deployVirtualMachine
+ assignVirtualMachine
+ updateVirtualMachine
+ restoreVirtualMachine
+ stopVirtualMachine
+ destroyVirtualMachine
+
+
+ The commands in this list have two new response parameters, and no other
+ changes.
+ New response parameters: keypair, tags(*)
+
+
+
+
+ listSecurityGroups
+ listFirewallRules
+ listPortForwardingRules
+ listSnapshots
+ listIsos
+ listProjects
+ listTemplates
+ listLoadBalancerRules
+
+ The commands in this list have the following new parameters, and no other
+ changes.
+ New request parameter: tags (optional)
+ New response parameter: tags(*)
+
+
+
+
+ listF5LoadBalancerNetworks
+ listNetscalerLoadBalancerNetworks
+ listSrxFirewallNetworks
+ updateNetwork
+
+
+ The commands in this list have three new response parameters, and no other
+ changes.
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ createZone
+ updateZone
+
+ The commands in this list have the following new parameters, and no other
+ changes.
+ New request parameter: localstorageenabled (optional)
+ New response parameter: localstorageenabled
+
+
+
+ listZones
+ New response parameter: localstorageenabled
+
+
+
+ rebootRouter
+ changeServiceForRouter
+ startRouter
+ destroyRouter
+ stopRouter
+
+ The commands in this list have two new response parameters, and no other
+ changes.
+ New response parameters: vpcid, nic(*)
+
+
+
+ updateAccount
+ disableAccount
+ listAccounts
+ markDefaultZoneForAccount
+ enableAccount
+
+ The commands in this list have three new response parameters, and no
+ other changes.
+ New response parameters: vpcavailable, vpclimit, vpctotal
+
+
+ listRouters
+
+ New request parameters: forvpc (optional), vpcid (optional)
+ New response parameters: vpcid, nic(*)
+
+
+
+ listNetworkOfferings
+
+ New request parameters: forvpc (optional)
+ New response parameters: forvpc
+
+
+
+ listVolumes
+
+ New request parameters: details (optional), tags (optional)
+ New response parameters: tags(*)
+
+
+
+ addTrafficMonitor
+
+ New request parameters: excludezones (optional), includezones
+ (optional)
+
+
+
+ createNetwork
+
+ New request parameters: vpcid (optional)
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+ listPublicIpAddresses
+
+ New request parameters: tags (optional), vpcid (optional)
+ New response parameters: vpcid, tags(*)
+
+
+
+ listNetworks
+
+ New request parameters: canusefordeploy (optional), forvpc (optional), tags
+ (optional), vpcid (optional)
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+ restartNetwork
+
+ New response parameters: vpcid, tags(*)
+
+
+
+ enableStaticNat
+
+ New request parameter: networkid (optional)
+
+
+
+ createDiskOffering
+
+ New request parameter: storagetype (optional)
+ New response parameter: storagetype
+
+
+
+ listDiskOfferings
+
+ New response parameter: storagetype
+
+
+
+ updateDiskOffering
+
+ New response parameter: storagetype
+
+
+
+ createFirewallRule
+
+ Changed request parameters: ipaddressid (old version - optional, new version -
+ required)
+ New response parameter: tags(*)
+
+
+
+ listVirtualMachines
+
+ New request parameters: isoid (optional), tags (optional), templateid
+ (optional)
+ New response parameters: keypair, tags(*)
+
+
+
+ updateStorageNetworkIpRange
+
+ New response parameters: id, endip, gateway, netmask, networkid, podid,
+ startip, vlan, zoneid
+
+
+
+ reconnectHost
+ A new response parameter is added: hahost.
+
+
+ addCluster
+ The following request parameters are added:
+
+
+ vsmipaddress (optional)
+
+
+ vsmpassword (optional)
+
+
+ vsmusername (optional)
+
+
+ The following parameter is made mandatory: podid
+
+
+
+ listVolumes
+ A new response parameter is added: status
+
+
+ migrateVolume
+ A new response parameter is added: status
+
+
+ prepareHostForMaintenance
+ A new response parameter is added: hahost.
+
+
+ addSecondaryStorage
+ A new response parameter is added: hahost.
+
+
+ enableAccount
+ A new response parameter is added: defaultzoneid
+
+
+ attachVolume
+ A new response parameter is added: status
+
+
+ cancelHostMaintenance
+ A new response parameter is added: hahost
+
+
+ addSwift
+ A new response parameter is added: hahost
+
+
+ listSwifts
+ A new response parameter is added: hahost
+
+
+ listExternalLoadBalancers
+ A new response parameter is added: hahost
+
+
+ createVolume
+ A new response parameter is added: status
+
+
+ listCapabilities
+ A new response parameter is added:
+ customdiskofferingmaxsize
+
+
+ disableAccount
+ A new response parameter is added: defaultzoneid
+
+
+ deployVirtualMachine
+ A new request parameter is added: startvm (optional)
+
+
+ deleteStoragePool
+ A new request parameter is added: forced (optional)
+
+
+ updateAccount
+ A new response parameter is added: defaultzoneid
+
+
+ addHost
+ A new response parameter is added: hahost
+
+
+ updateHost
+ A new response parameter is added: hahost
+
+
+ detachVolume
+ A new response parameter is added: status
+
+
+ listAccounts
+ A new response parameter is added: defaultzoneid
+
+
+ listHosts
+ A new response parameter is added: hahostA new request
+ parameter is added: hahost (optional)
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Revision_History.xml b/docs/tmp/en-US/xml_tmp/Revision_History.xml
new file mode 100644
index 00000000000..55d741a64f2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Revision_History.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Revision History
+
+
+
+ 0-0
+ Tue May 29 2012
+
+ Jessica
+ Tomechak
+
+
+
+
+ Initial creation of book by publican
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/Revision_History_Install_Guide.xml b/docs/tmp/en-US/xml_tmp/Revision_History_Install_Guide.xml
new file mode 100644
index 00000000000..ee8dd31325a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/Revision_History_Install_Guide.xml
@@ -0,0 +1,55 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Revision History
+
+
+
+ 1-0
+ October 5 2012
+
+ Jessica
+ Tomechak
+
+
+
+ Radhika
+ PC
+
+
+
+ Wido
+ den Hollander
+
+
+
+
+ Initial publication
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/SSL-keystore-path-and-password.xml b/docs/tmp/en-US/xml_tmp/SSL-keystore-path-and-password.xml
new file mode 100644
index 00000000000..f7b7426874d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/SSL-keystore-path-and-password.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/VPN-user-usage-record-format.xml b/docs/tmp/en-US/xml_tmp/VPN-user-usage-record-format.xml
new file mode 100644
index 00000000000..dd66fb4d0d4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/VPN-user-usage-record-format.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ VPN User Usage Record Format
+
+ account – name of the account
+ accountid – ID of the account
+ domainid – ID of the domain in which this account resides
+ zoneid – Zone where the usage occurred
+ description – A string describing what the usage record is tracking
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ usagetype – A number representing the usage type (see Usage Types)
+ rawusage – A number representing the actual usage in hours
+ usageid – VPN user ID
+ usagetype – A number representing the usage type (see Usage Types)
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
diff --git a/docs/tmp/en-US/xml_tmp/about-clusters.xml b/docs/tmp/en-US/xml_tmp/about-clusters.xml
new file mode 100644
index 00000000000..745ad89d118
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-clusters.xml
@@ -0,0 +1,63 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Clusters
+
+ A cluster provides a way to group hosts. To be precise, a cluster is a
+ XenServer server pool, a set of KVM servers, , or a
+ VMware cluster preconfigured in vCenter. The hosts in a cluster all
+ have identical hardware, run the same hypervisor, are on the same subnet,
+ and access the same shared primary storage. Virtual machine instances
+ (VMs) can be live-migrated from one host to another within the same
+ cluster, without interrupting service to the user.
+
+
+ A cluster is the third-largest organizational unit within a &PRODUCT;
+ deployment. Clusters are contained within pods, and pods are contained
+ within zones. Size of the cluster is limited by the underlying hypervisor,
+ although the &PRODUCT; recommends less in most cases; see Best Practices.
+
+
+ A cluster consists of one or more hosts and one or more primary storage
+ servers.
+
+
+
+
+
+ cluster-overview.png: Structure of a simple cluster
+
+ &PRODUCT; allows multiple clusters in a cloud deployment.
+
+ Even when local storage is used exclusively, clusters are still required
+ organizationally, even if there is just one host per cluster.
+
+
+ When VMware is used, every VMware cluster is managed by a vCenter server.
+ Administrator must register the vCenter server with &PRODUCT;. There may
+ be multiple vCenter servers per zone. Each vCenter server may manage
+ multiple VMware clusters.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/about-hosts.xml b/docs/tmp/en-US/xml_tmp/about-hosts.xml
new file mode 100644
index 00000000000..49694b25647
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-hosts.xml
@@ -0,0 +1,46 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Hosts
+ A host is a single computer. Hosts provide the computing resources that run the guest virtual machines. Each host has hypervisor software installed on it to manage the guest VMs. For example, a Linux KVM-enabled server, a Citrix XenServer server, and an ESXi server are hosts.
+ The host is the smallest organizational unit within a &PRODUCT; deployment. Hosts are contained within clusters, clusters are contained within pods, and pods are contained within zones.
+ Hosts in a &PRODUCT; deployment:
+
+ Provide the CPU, memory, storage, and networking resources needed to host the virtual
+ machines
+ Interconnect using a high bandwidth TCP/IP network and connect to the Internet
+ May reside in multiple data centers across different geographic locations
+ May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the hosts within a cluster must all be homogeneous
+
+ Additional hosts can be added at any time to provide more capacity for guest VMs.
+ &PRODUCT; automatically detects the amount of CPU and memory resources provided by the Hosts.
+ Hosts are not visible to the end user. An end user cannot determine which host their guest has been assigned to.
+ For a host to function in &PRODUCT;, you must do the following:
+
+ Install hypervisor software on the host
+ Assign an IP address to the host
+ Ensure the host is connected to the &PRODUCT; Management Server
+
+
diff --git a/docs/tmp/en-US/xml_tmp/about-physical-networks.xml b/docs/tmp/en-US/xml_tmp/about-physical-networks.xml
new file mode 100644
index 00000000000..8edb9e060c2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-physical-networks.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Physical Networks
+ Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical networks can be associated with each zone. The network corresponds to a NIC on the hypervisor host. Each physical network can carry one or more types of network traffic. The choices of traffic type for each network vary depending on whether you are creating a zone with basic networking or advanced networking.
+ A physical network is the actual network hardware and wiring in a zone. A zone can have multiple physical networks. An administrator can:
+
+ Add/Remove/Update physical networks in a zone
+ Configure VLANs on the physical network
+ Configure a name so the network can be recognized by hypervisors
+ Configure the service providers (firewalls, load balancers, etc.) available on a physical network
+ Configure the IP addresses trunked to a physical network
+ Specify what type of traffic is carried on the physical network, as well as other properties like network speed
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/about-pods.xml b/docs/tmp/en-US/xml_tmp/about-pods.xml
new file mode 100644
index 00000000000..ed3520c6451
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-pods.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Pods
+ A pod often represents a single rack. Hosts in the same pod are in the same subnet.
+ A pod is the second-largest organizational unit within a &PRODUCT; deployment. Pods are contained within zones. Each zone can contain one or more pods.
+ Pods are not visible to the end user.
+ A pod consists of one or more clusters of hosts and one or more primary storage servers.
+
+
+
+
+ pod-overview.png: Nested structure of a simple pod
+
+
diff --git a/docs/tmp/en-US/xml_tmp/about-primary-storage.xml b/docs/tmp/en-US/xml_tmp/about-primary-storage.xml
new file mode 100644
index 00000000000..68d7a25ba5a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-primary-storage.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Primary Storage
+ Primary storage is associated with a cluster, and it stores the disk volumes for all the VMs running on hosts in that cluster. You can add multiple primary storage servers to a cluster. At least one is required. It is typically located close to the hosts for increased performance.
+ &PRODUCT; is designed to work with all standards-compliant iSCSI and NFS servers that are supported by the underlying hypervisor, including, for example:
+
+ Dell EqualLogic™ for iSCSI
+ Network Appliances filers for NFS and iSCSI
+ Scale Computing for NFS
+
+ If you intend to use only local disk for your installation, you can skip to Add Secondary Storage.
+
diff --git a/docs/tmp/en-US/xml_tmp/about-secondary-storage.xml b/docs/tmp/en-US/xml_tmp/about-secondary-storage.xml
new file mode 100644
index 00000000000..c4df0b8c6e8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-secondary-storage.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Secondary Storage
+ Secondary storage is associated with a zone, and it stores the following:
+
+ Templates — OS images that can be used to boot VMs and can include additional configuration information, such as installed applications
+ ISO images — disc images containing data or bootable media for operating systems
+ Disk volume snapshots — saved copies of VM data which can be used for data recovery or to create new templates
+
+ The items in zone-based NFS secondary storage are available to all hosts in the zone. &PRODUCT; manages the allocation of guest virtual disks to particular primary storage devices.
+ To make items in secondary storage available to all hosts throughout the cloud, you can add OpenStack Object Storage (Swift, swift.openstack.org) in addition to the zone-based NFS secondary storage. When using Swift, you configure Swift storage for the entire &PRODUCT;, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere.
+
diff --git a/docs/tmp/en-US/xml_tmp/about-security-groups.xml b/docs/tmp/en-US/xml_tmp/about-security-groups.xml
new file mode 100644
index 00000000000..85e8477cfb1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-security-groups.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Security Groups
+ Security groups provide a way to isolate traffic to VMs. A security group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules, called ingress and egress rules. These rules filter network traffic according to the IP address that is attempting to communicate with the VM. Security groups are particularly useful in zones that use basic networking, because there is a single guest network for all guest VMs. In &PRODUCT; 3.0.3 - 3.0.5, security groups are supported only in zones that use basic networking.
+ In a zone that uses advanced networking, you can instead define multiple guest networks to isolate traffic to VMs.
+
+
+ Each &PRODUCT; account comes with a default security group that denies all inbound traffic and allows all outbound traffic. The default security group can be modified so that all new VMs inherit some other desired set of rules.
+ Any &PRODUCT; user can set up any number of additional security groups. When a new VM is launched, it is assigned to the default security group unless another user-defined security group is specified. A VM can be a member of any number of security groups. Once a VM is assigned to a security group, it remains in that group for its entire lifetime; you can not move a running VM from one security group to another.
+ You can modify a security group by deleting or adding any number of ingress and egress rules. When you do, the new rules apply to all VMs in the group, whether running or stopped.
+ If no ingress rules are specified, then no traffic will be allowed in, except for responses to any traffic that has been allowed out through an egress rule.
+
diff --git a/docs/tmp/en-US/xml_tmp/about-virtual-networks.xml b/docs/tmp/en-US/xml_tmp/about-virtual-networks.xml
new file mode 100644
index 00000000000..2797423d24d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-virtual-networks.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Virtual Networks
+ A virtual network is a logical construct that enables multi-tenancy on a single physical network. In &PRODUCT; a virtual network can be shared or isolated.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/about-working-with-vms.xml b/docs/tmp/en-US/xml_tmp/about-working-with-vms.xml
new file mode 100644
index 00000000000..47153e2f374
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-working-with-vms.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Working with Virtual Machines
+ &PRODUCT; provides administrators with complete control over the lifecycle of all guest VMs executing in the cloud. &PRODUCT; provides several guest management operations for end users and administrators. VMs may be stopped, started, rebooted, and destroyed.
+ Guest VMs have a name and group. VM names and groups are opaque to &PRODUCT; and are available for end users to organize their VMs. Each VM can have three names for use in different contexts. Only two of these names can be controlled by the user:
+
+ Instance name – a unique, immutable ID that is generated by &PRODUCT; and can not be modified by the user. This name conforms to the requirements in IETF RFC 1123.
+ Display name – the name displayed in the &PRODUCT; web UI. Can be set by the user. Defaults to instance name.
+ Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to instance name
+
+ Guest VMs can be configured to be Highly Available (HA). An HA-enabled VM is monitored by the system. If the system detects that the VM is down, it will attempt to restart the VM, possibly on a different host. For more information, see HA-Enabled Virtual Machines on
+ Each new VM is allocated one public IP address. When the VM is started, &PRODUCT; automatically creates a static NAT between this public IP address and the private IP address of the VM.
+ If elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new VM is not marked as elastic. The user must replace the automatically configured IP with a specifically acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s private IP. The VM’s original IP address is then released and returned to the pool of available public IPs.
+ &PRODUCT; cannot distinguish a guest VM that was shut down by the user (such as with the “shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut down from inside the VM, &PRODUCT; will restart it. To shut down an HA-enabled VM, you must go through the &PRODUCT; UI or API.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/about-zones.xml b/docs/tmp/en-US/xml_tmp/about-zones.xml
new file mode 100644
index 00000000000..a05a9a6e517
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/about-zones.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Zones
+ A zone is the largest organizational unit within a &PRODUCT; deployment. A zone typically corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter. The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For example, each zone can have its own power supply and network uplink, and the zones can be widely separated geographically (though this is not required).
+ A zone consists of:
+
+ One or more pods. Each pod contains one or more clusters of hosts and one or more primary storage servers.
+ Secondary storage, which is shared by all the pods in the zone.
+
+
+
+
+
+ zone-overview.png: Nested structure of a simple zone
+
+ Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones.
+ Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone.
+ Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels.
+ For each zone, the administrator must decide the following.
+
+ How many pods to place in a zone.
+ How many clusters to place in each pod.
+ How many hosts to place in each cluster.
+ How many primary storage servers to place in each cluster and total capacity for the storage servers.
+ How much secondary storage to deploy in 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/accept-membership-invite.xml b/docs/tmp/en-US/xml_tmp/accept-membership-invite.xml
new file mode 100644
index 00000000000..dc59d00af65
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/accept-membership-invite.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Accepting a Membership Invitation
+ If you have received an invitation to join a &PRODUCT; project, and you want to accept the invitation, follow these steps:
+
+ Log in to the &PRODUCT; 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 &PRODUCT; 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.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/accessing-vms.xml b/docs/tmp/en-US/xml_tmp/accessing-vms.xml
new file mode 100644
index 00000000000..d69d021471b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/accessing-vms.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Accessing VMs
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+ To access a VM through the &PRODUCT; UI:
+
+ Log in to the &PRODUCT; UI as a user or admin.
+ Click Instances, then click the name of a running VM.
+ Click the View Console button .
+
+ To access a VM directly over the network:
+
+ The VM must have some port open to incoming traffic. For example, in a basic zone, a new VM might be assigned to a security group which allows incoming traffic. This depends on what security group you picked when creating the VM. In other cases, you can open a port by setting up a port forwarding policy. See IP Forwarding and Firewalling.
+ If a port is open but you can not access the VM using ssh, it’s possible that ssh is not already enabled on the VM. This will depend on whether ssh is enabled in the template you picked when creating the VM. Access the VM through the &PRODUCT; UI and enable ssh on the machine using the commands for the VM’s operating system.
+ If the network has an external firewall device, you will need to create a firewall rule to allow access. See IP Forwarding and Firewalling.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/accounts-users-domains.xml b/docs/tmp/en-US/xml_tmp/accounts-users-domains.xml
new file mode 100644
index 00000000000..85491295218
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/accounts-users-domains.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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
+
+ The 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/accounts.xml b/docs/tmp/en-US/xml_tmp/accounts.xml
new file mode 100644
index 00000000000..e5056866801
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/accounts.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Accounts
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/acquire-new-ip-address.xml b/docs/tmp/en-US/xml_tmp/acquire-new-ip-address.xml
new file mode 100644
index 00000000000..8af130c9d7e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/acquire-new-ip-address.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Acquiring a New IP Address
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+ In the left navigation, choose Network.
+ Click the name of the network where you want to work with.
+ Click View IP Addresses.
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+ You are prompted for confirmation because, typically, IP addresses are a limited resource. Within a few moments, the new IP address should appear with the state Allocated. You can now use the IP address in port forwarding or static NAT rules.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/acquire-new-ip-for-vpc.xml b/docs/tmp/en-US/xml_tmp/acquire-new-ip-for-vpc.xml
new file mode 100644
index 00000000000..785e80bb874
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/acquire-new-ip-for-vpc.xml
@@ -0,0 +1,73 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Acquiring a New IP Address for a VPC
+ When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest
+ networks within the VPC. The IPs are associated to the guest network only when the first
+ port-forwarding, load balancing, or Static NAT rule is created for the IP or the network. IP
+ can't be associated to more than one network at a time.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+ The VPC page is displayed where all the tiers you created are listed in a
+ diagram.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ACLs
+
+
+
+
+ Select IP Addresses.
+ The IP Addresses page is displayed.
+
+
+ Click Acquire New IP, and click Yes in the confirmation dialog.
+ You are prompted for confirmation because, typically, IP addresses are a limited
+ resource. Within a few moments, the new IP address should appear with the state Allocated.
+ You can now use the IP address in port forwarding, load balancing, and static NAT
+ rules.
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/add-additional-guest-network.xml b/docs/tmp/en-US/xml_tmp/add-additional-guest-network.xml
new file mode 100644
index 00000000000..c684da023da
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-additional-guest-network.xml
@@ -0,0 +1,65 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding an Additional Guest Network
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ Click Add guest network. Provide the following information:
+
+
+ Name: The name of the network. This will be
+ user-visible.
+
+
+ Display Text: The description of the network. This
+ will be user-visible.
+
+
+ Zone. The name of the zone this network applies to.
+ Each zone is a broadcast domain, and therefore each zone has a different IP range for
+ the guest network. The administrator must configure the IP range for each zone.
+
+
+ Network offering: If the administrator has
+ configured multiple network offerings, select the one you want to use for this
+ network.
+
+
+ Guest Gateway: The gateway that the guests should
+ use.
+
+
+ Guest Netmask: The netmask in use on the subnet the
+ guests will use.
+
+
+
+
+ Click Create.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-clusters-kvm-xenserver.xml b/docs/tmp/en-US/xml_tmp/add-clusters-kvm-xenserver.xml
new file mode 100644
index 00000000000..ad5737191fd
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-clusters-kvm-xenserver.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Add Cluster: KVM or XenServer
+ These steps assume you have already installed the hypervisor on the hosts and logged in to
+ the &PRODUCT; 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
+ &PRODUCT;.
+
+
+ Click OK.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-clusters-ovm.xml b/docs/tmp/en-US/xml_tmp/add-clusters-ovm.xml
new file mode 100644
index 00000000000..11e1a13555f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-clusters-ovm.xml
@@ -0,0 +1,43 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Add Cluster: OVM
+ To add a Cluster of hosts that run Oracle VM (OVM):
+
+ Add a companion non-OVM cluster to the Pod. This cluster provides an environment where the CloudPlatform System VMs can run. You should have already installed a non-OVM hypervisor on at least one Host to prepare for this step. Depending on which hypervisor you used:
+
+ For VMWare, follow the steps in Add Cluster: vSphere. When finished, return here and continue with the next step.
+ For KVM or XenServer, follow the steps in . When finished, return here and continue with the next step
+
+
+ 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 Pods node, click View All. Select the same pod you used in step 1.
+ Click View Clusters, then click Add Cluster.
+ The Add Cluster dialog is displayed.
+ In Hypervisor, choose OVM.
+ In Cluster, enter a name for the cluster.
+ Click Add.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-clusters-vsphere.xml b/docs/tmp/en-US/xml_tmp/add-clusters-vsphere.xml
new file mode 100644
index 00000000000..6b2dff2a595
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-clusters-vsphere.xml
@@ -0,0 +1,110 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Add Cluster: vSphere
+ Host management for vSphere is done through a combination of vCenter and the &PRODUCT; admin
+ UI. &PRODUCT; requires that all hosts be in a &PRODUCT; 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 &PRODUCT;. 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 &PRODUCT;.
+
+
+ To add a vSphere cluster to &PRODUCT;:
+
+
+ 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
+ values from vCenter.
+
+
+ Cluster Name. Enter the name of the cluster you created in vCenter. For example,
+ "cloud.cluster.2.2.1"
+
+
+ vCenter Host. Enter the hostname or IP address of the vCenter server.
+
+
+ vCenter Username. Enter the username that &PRODUCT; should use to connect to
+ vCenter. This user must have all administrative privileges.
+
+
+ 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".
+
+
+
+
+
+
+
+ addcluster.png: add cluster
+
+
+ There might be a slight delay while the cluster is provisioned. It will
+ automatically display in the UI
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-gateway-vpc.xml b/docs/tmp/en-US/xml_tmp/add-gateway-vpc.xml
new file mode 100644
index 00000000000..616794a51d1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-gateway-vpc.xml
@@ -0,0 +1,104 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding a Private Gateway to a VPC
+ A private gateway can be added by the root admin only. The VPC private network has 1:1
+ relationship with the NIC of the physical network. No gateways with duplicated VLAN and IP are
+ allowed in the same data center.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC to which you want to configure load balancing
+ rules.
+ The VPC page is displayed where all the tiers you created are listed in a
+ diagram.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Private Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ACLs
+
+
+
+
+ Select Private Gateways.
+ The Gateways page is displayed.
+
+
+ Click Add new gateway:
+
+
+
+
+
+ add-new-gateway-vpc.png: adding a private gateway for the VPC.
+
+
+
+
+ Specify the following:
+
+
+ Physical Network: The physical network you have
+ created in the zone.
+
+
+ IP Address: The IP address associated with the VPC
+ gateway.
+
+
+ Gateway: The gateway through which the traffic is
+ routed to and from the VPC.
+
+
+ Netmask: The netmask associated with the VPC
+ gateway.
+
+
+ VLAN: The VLAN associated with the VPC
+ gateway.
+
+
+ The new gateway appears in the list. You can repeat these steps to add more gateway for
+ this VPC.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-ingress-egress-rules.xml b/docs/tmp/en-US/xml_tmp/add-ingress-egress-rules.xml
new file mode 100644
index 00000000000..2490cec43cc
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-ingress-egress-rules.xml
@@ -0,0 +1,131 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding Ingress and Egress Rules to a Security Group
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network
+
+
+ In Select view, choose Security Groups, then click the security group you want .
+
+
+ To add an ingress rule, click the Ingress Rules tab and fill out the following fields to
+ specify what network traffic is allowed into VM instances in this security group. If no
+ ingress rules are specified, then no traffic will be allowed in, except for responses to any
+ traffic that has been allowed out through an egress rule.
+
+
+ Add by CIDR/Account. Indicate whether the source of
+ the traffic will be defined by IP address (CIDR) or an existing security group in a
+ &PRODUCT; account (Account). Choose Account if you want to allow incoming traffic from
+ all VMs in another security group
+
+
+ Protocol. The networking protocol that sources will
+ use to send traffic to the security group. TCP and UDP are typically used for data
+ exchange and end-user communications. ICMP is typically used to send error messages or
+ network monitoring data.
+
+
+ Start Port, End Port. (TCP, UDP only) A range of
+ listening ports that are the destination for the incoming traffic. If you are opening a
+ single port, use the same number in both fields.
+
+
+ ICMP Type, ICMP Code. (ICMP only) The type of
+ message and error code that will be accepted.
+
+
+ CIDR. (Add by CIDR only) To accept only traffic
+ from IP addresses within a particular address block, enter a CIDR or a comma-separated
+ list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example,
+ 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+
+ Account, Security Group. (Add by Account only) To
+ accept only traffic from another security group, enter the &PRODUCT; account and name of
+ a security group that has already been defined in that account. To allow traffic between
+ VMs within the security group you are editing now, enter the same name you used in step
+ 7.
+
+
+ The following example allows inbound HTTP access from anywhere:
+
+
+
+
+
+ httpaccess.png: allows inbound HTTP access from anywhere
+
+
+
+
+ To add an egress rule, click the Egress Rules tab and fill out the following fields to
+ specify what type of traffic is allowed to be sent out of VM instances in this security
+ group. If no egress rules are specified, then all traffic will be allowed out. Once egress
+ rules are specified, the following types of traffic are allowed out: traffic specified in
+ egress rules; queries to DNS and DHCP servers; and responses to any traffic that has been
+ allowed in through an ingress rule
+
+
+ Add by CIDR/Account. Indicate whether the
+ destination of the traffic will be defined by IP address (CIDR) or an existing security
+ group in a &PRODUCT; account (Account). Choose Account if you want to allow outgoing
+ traffic to all VMs in another security group.
+
+
+ Protocol. The networking protocol that VMs will use
+ to send outgoing traffic. TCP and UDP are typically used for data exchange and end-user
+ communications. ICMP is typically used to send error messages or network monitoring
+ data.
+
+
+ Start Port, End Port. (TCP, UDP only) A range of
+ listening ports that are the destination for the outgoing traffic. If you are opening a
+ single port, use the same number in both fields.
+
+
+ ICMP Type, ICMP Code. (ICMP only) The type of
+ message and error code that will be sent
+
+
+ CIDR. (Add by CIDR only) To send traffic only to IP
+ addresses within a particular address block, enter a CIDR or a comma-separated list of
+ CIDRs. The CIDR is the base IP address of the destination. For example, 192.168.0.0/22.
+ To allow all CIDRs, set to 0.0.0.0/0.
+
+
+ Account, Security Group. (Add by Account only) To
+ allow traffic to be sent to another security group, enter the &PRODUCT; account and name
+ of a security group that has already been defined in that account. To allow traffic
+ between VMs within the security group you are editing now, enter its name.
+
+
+
+
+ Click Add.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-iso.xml b/docs/tmp/en-US/xml_tmp/add-iso.xml
new file mode 100644
index 00000000000..25986e02e92
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-iso.xml
@@ -0,0 +1,151 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding an ISO
+ To make additional operating system or other software available for use with guest VMs, you
+ can add an ISO. The ISO is typically thought of as an operating system image, but you can also
+ add ISOs for other types of software, such as desktop applications that you want to be installed
+ as part of a template.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation bar, click Templates.
+
+
+ In Select View, choose ISOs.
+
+
+ Click Add ISO.
+
+
+ In the Add ISO screen, provide the following:
+
+
+ Name: Short name for the ISO image. For example,
+ CentOS 6.2 64-bit.
+
+
+ Description: Display test for the ISO image. For
+ example, CentOS 6.2 64-bit.
+
+
+ URL: The URL that hosts the ISO image. The
+ Management Server must be able to access this location via HTTP. If needed you can place
+ the ISO image directly on the Management Server
+
+
+ Zone: Choose the zone where you want the ISO to be
+ available, or All Zones to make it available throughout &PRODUCT;.
+
+
+ Bootable: Whether or not a guest could boot off
+ this ISO image. For example, a CentOS ISO is bootable, a Microsoft Office ISO is not
+ bootable.
+
+
+ OS Type: This helps &PRODUCT; and the hypervisor
+ perform certain operations and make assumptions that improve the performance of the
+ guest. Select one of the following.
+
+
+ If the operating system of your desired ISO image is listed, choose it.
+
+
+ If the OS Type of the ISO is not listed or if the ISO is not bootable, choose
+ Other.
+
+
+ (XenServer only) If you want to boot from this ISO in PV mode, choose Other PV
+ (32-bit) or Other PV (64-bit)
+
+
+ (KVM only) If you choose an OS that is PV-enabled, the VMs created from this ISO
+ will have a SCSI (virtio) root disk. If the OS is not PV-enabled, the VMs will have
+ an IDE root disk. The PV-enabled types are:
+
+
+
+
+ Fedora 13
+ Fedora 12
+ Fedora 11
+
+
+ Fedora 10
+ Fedora 9
+ Other PV
+
+
+ Debian GNU/Linux
+ CentOS 5.3
+ CentOS 5.4
+
+
+ CentOS 5.5
+ Red Hat Enterprise Linux 5.3
+ Red Hat Enterprise Linux 5.4
+
+
+ Red Hat Enterprise Linux 5.5
+ Red Hat Enterprise Linux 6
+
+
+
+
+
+
+
+
+ It is not recommended to choose an older version of the OS than the version in the
+ image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will usually not
+ work. In these cases, choose Other.
+
+
+
+ Extractable: Choose Yes if the ISO should be
+ available for extraction.
+
+
+ Public: Choose Yes if this ISO should be available
+ to other users.
+
+
+ Featured: Choose Yes if you would like this ISO to
+ be more prominent for users to select. The ISO will appear in the Featured ISOs list.
+ Only an administrator can make an ISO Featured.
+
+
+
+
+ Click OK.
+ The Management Server will download the ISO. Depending on the size of the ISO, this may
+ take a long time. The ISO status column will display Ready once it has been successfully
+ downloaded into secondary storage. Clicking Refresh updates the download percentage.
+
+
+ Important: Wait for the ISO to finish downloading. If
+ you move on to the next task and try to use the ISO right away, it will appear to fail. The
+ entire ISO must be available before &PRODUCT; can work with it.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-load-balancer-rule.xml b/docs/tmp/en-US/xml_tmp/add-load-balancer-rule.xml
new file mode 100644
index 00000000000..8cd0da4b7da
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-load-balancer-rule.xml
@@ -0,0 +1,82 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding a Load Balancer Rule
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ Click the name of the network where you want to load balance the traffic.
+
+
+ Click View IP Addresses.
+
+
+ Click the IP address for which you want to create the rule, then click the Configuration
+ tab.
+
+
+ In the Load Balancing node of the diagram, click View All.
+ In a Basic zone, you can also create a load balancing rule without acquiring or
+ selecting an IP address. &PRODUCT; internally assign an IP when you create the load
+ balancing rule, which is listed in the IP Addresses page when the rule is created.
+ To do that, select the name of the network, then click Add Load Balancer tab. Continue
+ with .
+
+
+ Fill in the following:
+
+
+ Name: A name for the load balancer rule.
+
+
+ Public Port: The port receiving incoming traffic to
+ be balanced.
+
+
+ Private Port: The port that the VMs will use to
+ receive the traffic.
+
+
+ Algorithm: Choose the load balancing algorithm you
+ want &PRODUCT; to use. &PRODUCT; supports a variety of well-known algorithms. If you are
+ not familiar with these choices, you will find plenty of information about them on the
+ Internet.
+
+
+ Stickiness: (Optional) Click Configure and choose
+ the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer
+ Rules.
+
+
+
+
+ Click Add VMs, then select two or more VMs that will divide the load of incoming
+ traffic, and click Apply.
+ The new load balancer rule appears in the list. You can repeat these steps to add more
+ load balancer rules for this IP address.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-loadbalancer-rule-vpc.xml b/docs/tmp/en-US/xml_tmp/add-loadbalancer-rule-vpc.xml
new file mode 100644
index 00000000000..bba3e5ad134
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-loadbalancer-rule-vpc.xml
@@ -0,0 +1,123 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Adding Load Balancing Rules on a VPC
+ A &PRODUCT; user or administrator may create load balancing rules that balance traffic
+ received at a public IP to one or more VMs that belong to a network tier that provides load
+ balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule
+ to a set of VMs within a VPC.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC to which you want to configure load balancing
+ rules.
+ The VPC page is displayed where all the tiers you created are listed in a
+ diagram.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ACLs
+
+
+
+
+ Select IP Addresses.
+ The IP Addresses page is displayed.
+
+
+ Click the IP address for which you want to create the rule, then click the Configuration
+ tab.
+
+
+ In the Load Balancing node of the diagram, click View All.
+
+
+ Select the tier to which you want to apply the rule.
+
+ In a VPC, the load balancing service is supported only on a single tier.
+
+
+
+ Specify the following:
+
+
+ Name: A name for the load balancer rule.
+
+
+ Public Port: The port that receives the incoming
+ traffic to be balanced.
+
+
+ Private Port: The port that the VMs will use to
+ receive the traffic.
+
+
+ Algorithm. Choose the load balancing algorithm you
+ want &PRODUCT; to use. &PRODUCT; supports the following well-known algorithms:
+
+
+ Round-robin
+
+
+ Least connections
+
+
+ Source
+
+
+
+
+ Stickiness. (Optional) Click Configure and choose
+ the algorithm for the stickiness policy. See Sticky Session Policies for Load Balancer
+ Rules.
+
+
+ Add VMs: Click Add VMs, then select two or more VMs
+ that will divide the load of incoming traffic, and click Apply.
+
+
+
+
+ The new load balancing rule appears in the list. You can repeat these steps to add more load
+ balancing rules for this IP address.
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/add-members-to-projects.xml b/docs/tmp/en-US/xml_tmp/add-members-to-projects.xml
new file mode 100644
index 00000000000..39c3edfb2c3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-members-to-projects.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 &PRODUCT; root administrator. There are two ways to add members in &PRODUCT;, 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.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-more-clusters.xml b/docs/tmp/en-US/xml_tmp/add-more-clusters.xml
new file mode 100644
index 00000000000..894b4d80737
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-more-clusters.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Add More Clusters (Optional)
+ You need to tell &PRODUCT; 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.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-password-management-to-templates.xml b/docs/tmp/en-US/xml_tmp/add-password-management-to-templates.xml
new file mode 100644
index 00000000000..581e564f59a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-password-management-to-templates.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Adding Password Management to Your Templates
+ &PRODUCT; provides an optional password reset feature that allows users to set a temporary admin or root password as well as reset the existing admin or root password from the &PRODUCT; UI.
+ To enable the Reset Password feature, you will need to download an additional script to patch your template. When you later upload the template into &PRODUCT;, you can specify whether reset admin/root password feature should be enabled for this template.
+ The password management feature works always resets the account password on instance boot. The script does an HTTP call to the virtual router to retrieve the account password that should be set. As long as the virtual router is accessible the guest will have access to the account password that should be used. When the user requests a password reset the management server generates and sends a new password to the virtual router for the account. Thus an instance reboot is necessary to effect any password changes.
+ If the script is unable to contact the virtual router during instance boot it will not set the password but boot will continue normally.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-portforward-rule-vpc.xml b/docs/tmp/en-US/xml_tmp/add-portforward-rule-vpc.xml
new file mode 100644
index 00000000000..c3dbc39bb19
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-portforward-rule-vpc.xml
@@ -0,0 +1,103 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding a Port Forwarding Rule on a VPC
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+ The VPC page is displayed where all the tiers you created are listed in a
+ diagram.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ACLs
+
+
+
+
+ Choose an existing IP address or acquire a new IP address. Click the name of the IP
+ address in the list.
+ The IP Addresses page is displayed.
+
+
+ Click the IP address for which you want to create the rule, then click the Configuration
+ tab.
+
+
+ In the Port Forwarding node of the diagram, click View All.
+
+
+ Select the tier to which you want to apply the rule.
+
+
+ Specify the following:
+
+
+ Public Port: The port to which public traffic will
+ be addressed on the IP address you acquired in the previous step.
+
+
+ Private Port: The port on which the instance is
+ listening for forwarded public traffic.
+
+
+ Protocol: The communication protocol in use between
+ the two ports.
+
+
+ TCP
+
+
+ UDP
+
+
+
+
+ Add VM: Click Add VM. Select the name of the
+ instance to which this rule applies, and click Apply.
+ You can test the rule by opening an ssh session to the instance.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-primary-storage.xml b/docs/tmp/en-US/xml_tmp/add-primary-storage.xml
new file mode 100644
index 00000000000..a43567f5562
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-primary-storage.xml
@@ -0,0 +1,108 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding Primary Storage
+
+ Ensure that nothing stored on the server. Adding the server to CloudStack will destroy any
+ existing data.
+
+ When you create a new zone, the first primary storage is added as part of that procedure.
+ You can add primary storage servers at any time, such as when adding a new cluster or adding
+ more servers to an existing cluster.
+
+
+ Log in to the &PRODUCT; UI.
+
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the
+ zone in which you want to add the primary storage.
+
+
+ Click the Compute tab.
+
+
+ In the Primary Storage node of the diagram, click View All.
+
+
+ Click Add Primary Storage.
+
+
+ Provide the following information in the dialog. The information required varies
+ depending on your choice in Protocol.
+
+
+ Pod. The pod for the storage device.
+
+
+ Cluster. The cluster for the storage device.
+
+
+ Name. The name of the storage device
+
+
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS
+ or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or
+ NFS
+
+
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage
+ device
+
+
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+
+
+ Path (for NFS). In NFS this is the exported path from the server.
+
+
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the
+ datastore name. The format is "/" datacenter name "/" datastore name. For example,
+ "/cloud.dc.VM/cluster1datastore".
+
+
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where
+ this primary storage is mounted. For example, "/mnt/primary".
+
+
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up
+ outside &PRODUCT;.
+
+
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example,
+ iqn.1986-03.com.sun:02:01ec9bb549-1271378984
+
+
+ Lun # (for iSCSI). In iSCSI this is 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.
+
+
+ Click OK.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-projects-members-from-ui.xml b/docs/tmp/en-US/xml_tmp/add-projects-members-from-ui.xml
new file mode 100644
index 00000000000..670a0ec75ab
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-projects-members-from-ui.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 , use the procedure in .
+
+ Log in to the &PRODUCT; 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.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-secondary-storage.xml b/docs/tmp/en-US/xml_tmp/add-secondary-storage.xml
new file mode 100644
index 00000000000..318a6ea79b6
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-secondary-storage.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding Secondary Storage
+
+ Be sure there is nothing stored on the server. Adding the server to CloudStack will
+ destroy any existing data.
+
+ When you create a new zone, the first secondary storage is added as part of that procedure.
+ You can add secondary storage servers at any time to add more servers to an existing
+ zone.
+
+
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift
+ storage to &PRODUCT; before you add the local zone secondary storage servers.
+
+
+ To prepare for local zone secondary storage, you should have created and mounted an NFS
+ share during Management Server installation.
+
+
+ Make sure you prepared the system VM template during Management Server
+ installation.
+
+
+ 4. Now that the secondary storage server for per-zone storage is prepared, add it to
+ &PRODUCT;. Secondary storage is added as part of the procedure for adding a new zone.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-security-group.xml b/docs/tmp/en-US/xml_tmp/add-security-group.xml
new file mode 100644
index 00000000000..85a6ba0b38a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-security-group.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding a Security Group
+ A user or administrator can define a new security group.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network
+
+
+ In Select view, choose Security Groups.
+
+
+ Click Add Security Group.
+
+
+ Provide a name and description.
+
+
+ Click OK.
+ The new security group appears in the Security Groups Details tab.
+
+
+ To make the security group useful, continue to Adding Ingress and Egress Rules to a
+ Security Group.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-tier.xml b/docs/tmp/en-US/xml_tmp/add-tier.xml
new file mode 100644
index 00000000000..6beaab2a151
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-tier.xml
@@ -0,0 +1,89 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding Tiers
+ Tiers are distinct locations within a VPC that act as isolated networks, which do not have
+ access to other tiers by default. Tiers are set up on different VLANs that can communicate with
+ each other by using a virtual router. Tiers provide inexpensive, low latency network
+ connectivity to other tiers within the VPC.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPC that you have created for the account is listed in the page.
+
+ The end users can see their own VPCs, while root and domain admin can see any VPC they
+ are authorized to see.
+
+
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+ The Add new tier dialog is displayed, as follows:
+
+
+
+
+
+ add-tier.png: adding a tier to a vpc.
+
+
+ If you have already created tiers, the VPC diagram is displayed. Click Create Tier to
+ add a new tier.
+
+
+ Specify the following:
+ All the fields are mandatory.
+
+
+ Name: A unique name for the tier you create.
+
+
+ Network Offering: The following default network
+ offerings are listed: DefaultIsolatedNetworkOfferingForVpcNetworksNoLB,
+ DefaultIsolatedNetworkOfferingForVpcNetworks
+ In a VPC, only one tier can be created by using LB-enabled network offering.
+
+
+ Gateway: The gateway for the tier you create.
+ Ensure that the gateway is within the Super CIDR range that you specified while creating
+ the VPC, and is not overlapped with the CIDR of any existing tier within the VPC.
+
+
+ Netmask: The netmask for the tier you create.
+ For example, if the VPC CIDR is 10.0.0.0/16 and the network tier CIDR is
+ 10.0.1.0/24, the gateway of the tier is 10.0.1.1, and the netmask of the tier is
+ 255.255.255.0.
+
+
+
+
+ Click OK.
+
+
+ Continue with configuring access control list for the tier.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-vm-to-tier.xml b/docs/tmp/en-US/xml_tmp/add-vm-to-tier.xml
new file mode 100644
index 00000000000..e401eed2656
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-vm-to-tier.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Deploying VMs to the Tier
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+ The VPC page is displayed where all the tiers you created are listed.
+
+
+ Click the Add VM button of the tier for which you want to add a VM.
+ The Add Instance page is displayed.
+ Follow the on-screen instruction to add an instance. For information on adding an
+ instance, see Adding Instances section in the Installation Guide.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/add-vpc.xml b/docs/tmp/en-US/xml_tmp/add-vpc.xml
new file mode 100644
index 00000000000..8c088a0e1fd
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/add-vpc.xml
@@ -0,0 +1,75 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Adding a Virtual Private Cloud
+ When creating the VPC, you simply provide the zone and a set of IP addresses for the VPC
+ network address space. You specify this set of addresses in the form of a Classless Inter-Domain
+ Routing (CIDR) block.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+
+
+ Click Add VPC. The Add VPC page is displayed as follows:
+
+
+
+
+
+ add-vpc.png: adding a vpc.
+
+
+ Provide the following information:
+
+
+ Name: A short name for the VPC that you are
+ creating.
+
+
+ Description: A brief description of the VPC.
+
+
+ Zone: Choose the zone where you want the VPC to be
+ available.
+
+
+ Super CIDR for Guest Networks: Defines the CIDR
+ range for all the tiers (guest networks) within a VPC. When you create a tier, ensure
+ that its CIDR is within the Super CIDR value you enter. The CIDR must be RFC1918
+ compliant.
+
+
+ DNS domain for Guest Networks: If you want to
+ assign a special domain name, specify the DNS suffix. This parameter is applied to all
+ the tiers within the VPC. That implies, all the tiers you create in the VPC belong to
+ the same DNS domain. If the parameter is not specified, a DNS domain name is generated
+ automatically.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/added-API-commands-4.0.xml b/docs/tmp/en-US/xml_tmp/added-API-commands-4.0.xml
new file mode 100644
index 00000000000..2d86ba4d6dc
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/added-API-commands-4.0.xml
@@ -0,0 +1,164 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Added API Commands in 4.0.0-incubating
+
+
+ createCounter (Adds metric counter)
+
+
+ deleteCounter (Deletes a counter)
+
+
+ listCounters (List the counters)
+
+
+ createCondition (Creates a condition)
+
+
+ deleteCondition (Removes a condition)
+
+
+ listConditions (List Conditions for the specific user)
+
+
+ createTags. Add tags to one or more resources. Example:
+ command=createTags
+&resourceIds=1,10,12
+&resourceType=userVm
+&tags[0].key=region
+&tags[0].value=canada
+&tags[1].key=city
+&tags[1].value=Toronto
+
+
+ deleteTags. Remove tags from one or more resources. Example:
+ command=deleteTags
+&resourceIds=1,12
+&resourceType=Snapshot
+&tags[0].key=city
+
+
+ listTags (Show currently defined resource tags)
+
+
+ createVPC (Creates a VPC)
+
+
+ listVPCs (Lists VPCs)
+
+
+ deleteVPC (Deletes a VPC)
+
+
+ updateVPC (Updates a VPC)
+
+
+ restartVPC (Restarts a VPC)
+
+
+ createVPCOffering (Creates VPC offering)
+
+
+ updateVPCOffering (Updates VPC offering)
+
+
+ deleteVPCOffering (Deletes VPC offering)
+
+
+ listVPCOfferings (Lists VPC offerings)
+
+
+ createPrivateGateway (Creates a private gateway)
+
+
+ listPrivateGateways (List private gateways)
+
+
+ deletePrivateGateway (Deletes a Private gateway)
+
+
+ createNetworkACL (Creates a ACL rule the given network (the network has to belong to
+ VPC))
+
+
+ deleteNetworkACL (Deletes a Network ACL)
+
+
+ listNetworkACLs (Lists all network ACLs)
+
+
+ createStaticRoute (Creates a static route)
+
+
+ deleteStaticRoute (Deletes a static route)
+
+
+ listStaticRoutes (Lists all static routes)
+
+
+ createVpnCustomerGateway (Creates site to site vpn customer gateway)
+
+
+ createVpnGateway (Creates site to site vpn local gateway)
+
+
+ createVpnConnection (Create site to site vpn connection)
+
+
+ deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
+
+
+ deleteVpnGateway (Delete site to site vpn gateway)
+
+
+ deleteVpnConnection (Delete site to site vpn connection)
+
+
+ updateVpnCustomerGateway (Update site to site vpn customer gateway)
+
+
+ resetVpnConnection (Reset site to site vpn connection)
+
+
+ listVpnCustomerGateways (Lists site to site vpn customer gateways)
+
+
+ listVpnGateways (Lists site 2 site vpn gateways)
+
+
+ listVpnConnections (Lists site to site vpn connection gateways)
+
+
+ enableCiscoNexusVSM (Enables Nexus 1000v dvSwitch in &PRODUCT;.)
+
+
+ disableCiscoNexusVSM (Disables Nexus 1000v dvSwitch in &PRODUCT;.)
+
+
+ deleteCiscoNexusVSM (Deletes Nexus 1000v dvSwitch in &PRODUCT;.)
+
+
+ listCiscoNexusVSMs (Lists the control VLAN ID, packet VLAN ID, and data VLAN ID, as well
+ as the IP address of the Nexus 1000v dvSwitch.)
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/added-API-commands.xml b/docs/tmp/en-US/xml_tmp/added-API-commands.xml
new file mode 100644
index 00000000000..208aac29dc2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/added-API-commands.xml
@@ -0,0 +1,195 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Added API commands in 3.0
+
+ Added in 3.0.2
+
+
+ changeServiceForSystemVm
+ Changes the service offering for a system VM (console proxy or secondary storage). The
+ system VM must be in a "Stopped" state for this command to take effect.
+
+
+
+
+ Added in 3.0.1
+
+
+ changeServiceForSystemVm
+ Changes the service offering for a system VM (console proxy or secondary storage). The
+ system VM must be in a "Stopped" state for this command to take effect.
+
+
+
+
+ Added in 3.0.0
+
+
+
+
+
+
+
+ assignVirtualMachine (Move a user VM to another user under same
+ domain.)
+ restoreVirtualMachine (Restore a VM to original template or specific
+ snapshot)
+ createLBStickinessPolicy (Creates a Load Balancer stickiness policy
+ )
+
+
+ deleteLBStickinessPolicy (Deletes a LB stickiness policy.)
+ listLBStickinessPolicies (Lists LBStickiness policies.)
+ ldapConfig (Configure the LDAP context for this site.)
+
+
+ addSwift (Adds Swift.)
+ listSwifts (List Swift.)
+ migrateVolume (Migrate volume)
+
+
+ updateStoragePool (Updates a storage pool.)
+ authorizeSecurityGroupEgress (Authorizes a particular egress rule for this
+ security group)
+ revokeSecurityGroupEgress (Deletes a particular egress rule from this
+ security group)
+
+
+ createNetworkOffering (Creates a network offering.)
+ deleteNetworkOffering (Deletes a network offering.)
+ createProject (Creates a project)
+
+
+ deleteProject (Deletes a project)
+ updateProject (Updates a project)
+ activateProject (Activates a project)
+
+
+ suspendProject (Suspends a project)
+ listProjects (Lists projects and provides detailed information for listed
+ projects)
+ addAccountToProject (Adds acoount to a project)
+
+
+ deleteAccountFromProject (Deletes account from the project)
+ listProjectAccounts (Lists project's accounts)
+ listProjectInvitations (Lists an account's invitations to join
+ projects)
+
+
+ updateProjectInvitation (Accepts or declines project
+ invitation)
+ deleteProjectInvitation (Deletes a project invitation)
+ updateHypervisorCapabilities (Updates a hypervisor
+ capabilities.)
+
+
+ listHypervisorCapabilities (Lists all hypervisor
+ capabilities.)
+ createPhysicalNetwork (Creates a physical network)
+ deletePhysicalNetwork (Deletes a Physical Network.)
+
+
+ listPhysicalNetworks (Lists physical networks)
+ updatePhysicalNetwork (Updates a physical network)
+ listSupportedNetworkServices (Lists all network services provided by
+ &PRODUCT; or for the given Provider.)
+
+
+ addNetworkServiceProvider (Adds a network serviceProvider to a physical
+ network)
+ deleteNetworkServiceProvider (Deletes a Network Service
+ Provider.)
+ listNetworkServiceProviders (Lists network serviceproviders for a given
+ physical network.)
+
+
+ updateNetworkServiceProvider (Updates a network serviceProvider of a physical
+ network)
+ addTrafficType (Adds traffic type to a physical network)
+ deleteTrafficType (Deletes traffic type of a physical network)
+
+
+ listTrafficTypes (Lists traffic types of a given physical
+ network.)
+ updateTrafficType (Updates traffic type of a physical network)
+ listTrafficTypeImplementors (Lists implementors of implementor of a network
+ traffic type or implementors of all network traffic types)
+
+
+ createStorageNetworkIpRange (Creates a Storage network IP
+ range.)
+ deleteStorageNetworkIpRange (Deletes a storage network IP
+ Range.)
+ listStorageNetworkIpRange (List a storage network IP range.)
+
+
+ updateStorageNetworkIpRange (Update a Storage network IP range, only allowed
+ when no IPs in this range have been allocated.)
+ listUsageTypes (List Usage Types)
+ addF5LoadBalancer (Adds a F5 BigIP load balancer device)
+
+
+ configureF5LoadBalancer (configures a F5 load balancer device)
+ deleteF5LoadBalancer ( delete a F5 load balancer device)
+ listF5LoadBalancers (lists F5 load balancer devices)
+
+
+ listF5LoadBalancerNetworks (lists network that are using a F5 load balancer
+ device)
+ addSrxFirewall (Adds a SRX firewall device)
+ deleteSrxFirewall ( delete a SRX firewall device)
+
+
+ listSrxFirewalls (lists SRX firewall devices in a physical
+ network)
+ listSrxFirewallNetworks (lists network that are using SRX firewall
+ device)
+ addNetscalerLoadBalancer (Adds a netscaler load balancer
+ device)
+
+
+ deleteNetscalerLoadBalancer ( delete a netscaler load balancer
+ device)
+ configureNetscalerLoadBalancer (configures a netscaler load balancer
+ device)
+ listNetscalerLoadBalancers (lists netscaler load balancer
+ devices)
+
+
+ listNetscalerLoadBalancerNetworks (lists network that are using a netscaler
+ load balancer device)
+ createVirtualRouterElement (Create a virtual router element.)
+ configureVirtualRouterElement (Configures a virtual router
+ element.)
+
+
+ listVirtualRouterElements (Lists all available virtual router
+ elements.)
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/added-cloudPlatform-error-codes.xml b/docs/tmp/en-US/xml_tmp/added-cloudPlatform-error-codes.xml
new file mode 100644
index 00000000000..6b1e6a355ca
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/added-cloudPlatform-error-codes.xml
@@ -0,0 +1,138 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Added &PRODUCT; Error Codes
+ You can now find the &PRODUCT;-specific error code in the exception response for each type of exception. The following list of error codes is added to the new class named CSExceptionErrorCode. These codes are applicable in &PRODUCT; 3.0.3 and later versions.
+
+
+
+
+
+
+
+ 4250 : "com.cloud.utils.exception.CloudRuntimeException"
+ 4255 : "com.cloud.utils.exception.ExceptionUtil"
+ 4260 : "com.cloud.utils.exception.ExecutionException"
+
+
+ 4265 : "com.cloud.utils.exception.HypervisorVersionChangedException"
+ 4270 : "com.cloud.utils.exception.RuntimeCloudException"
+ 4275 : "com.cloud.exception.CloudException"
+
+
+ 4280 : "com.cloud.exception.AccountLimitException"
+ 4285 : "com.cloud.exception.AgentUnavailableException"
+ 4290 : "com.cloud.exception.CloudAuthenticationException"
+
+
+ 4295 : "com.cloud.exception.CloudExecutionException"
+ 4300 : "com.cloud.exception.ConcurrentOperationException"
+ 4305 : "com.cloud.exception.ConflictingNetworkSettingsException"
+
+
+ 4310 : "com.cloud.exception.DiscoveredWithErrorException"
+ 4315 : "com.cloud.exception.HAStateException"
+ 4320 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+ 4325 : "com.cloud.exception.InsufficientCapacityException"
+ 4330 : "com.cloud.exception.InsufficientNetworkCapacityException"
+ 4335 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+ 4340 : "com.cloud.exception.InsufficientStorageCapacityException"
+ 4345 : "com.cloud.exception.InternalErrorException"
+ 4350 : "com.cloud.exception.InvalidParameterValueException"
+
+
+ 4355 : "com.cloud.exception.ManagementServerException"
+ 4360 : "com.cloud.exception.NetworkRuleConflictException"
+ 4365 : "com.cloud.exception.PermissionDeniedException"
+
+
+ 4370 : "com.cloud.exception.ResourceAllocationException"
+ 4375 : "com.cloud.exception.ResourceInUseException"
+ 4380 : "com.cloud.exception.ResourceUnavailableException"
+
+
+ 4385 : "com.cloud.exception.StorageUnavailableException"
+ 4390 : "com.cloud.exception.UnsupportedServiceException"
+ 4395 : "com.cloud.exception.VirtualMachineMigrationException"
+
+
+ 4400 : "com.cloud.exception.AccountLimitException"
+ 4405 : "com.cloud.exception.AgentUnavailableException"
+ 4410 : "com.cloud.exception.CloudAuthenticationException"
+
+
+ 4415 : "com.cloud.exception.CloudException"
+ 4420 : "com.cloud.exception.CloudExecutionException"
+ 4425 : "com.cloud.exception.ConcurrentOperationException"
+
+
+ 4430 : "com.cloud.exception.ConflictingNetworkSettingsException"
+ 4435 : "com.cloud.exception.ConnectionException"
+ 4440 : "com.cloud.exception.DiscoveredWithErrorException"
+
+
+ 4445 : "com.cloud.exception.DiscoveryException"
+ 4450 : "com.cloud.exception.HAStateException"
+ 4455 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+ 4460 : "com.cloud.exception.InsufficientCapacityException"
+ 4465 : "com.cloud.exception.InsufficientNetworkCapacityException"
+ 4470 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+ 4475 : "com.cloud.exception.InsufficientStorageCapacityException"
+ 4480 : "com.cloud.exception.InsufficientVirtualNetworkCapcityException"
+ 4485 : "com.cloud.exception.InternalErrorException"
+
+
+ 4490 : "com.cloud.exception.InvalidParameterValueException"
+ 4495 : "com.cloud.exception.ManagementServerException"
+ 4500 : "com.cloud.exception.NetworkRuleConflictException"
+
+
+ 4505 : "com.cloud.exception.PermissionDeniedException"
+ 4510 : "com.cloud.exception.ResourceAllocationException"
+ 4515 : "com.cloud.exception.ResourceInUseException"
+
+
+ 4520 : "com.cloud.exception.ResourceUnavailableException"
+ 4525 : "com.cloud.exception.StorageUnavailableException"
+ 4530 : "com.cloud.exception.UnsupportedServiceException"
+
+
+ 4535 : "com.cloud.exception.VirtualMachineMigrationException"
+ 9999 : "com.cloud.api.ServerApiException"
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/added-error-codes.xml b/docs/tmp/en-US/xml_tmp/added-error-codes.xml
new file mode 100644
index 00000000000..4436bf381e0
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/added-error-codes.xml
@@ -0,0 +1,138 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Added &PRODUCT; Error Codes
+ You can now find the &PRODUCT;-specific error code in the exception response for each type of exception. The following list of error codes is added to the new class named CSExceptionErrorCode. These codes are applicable in &PRODUCT; 3.0.3 and later versions.
+
+
+
+
+
+
+
+ 4250 : "com.cloud.utils.exception.CloudRuntimeException"
+ 4255 : "com.cloud.utils.exception.ExceptionUtil"
+ 4260 : "com.cloud.utils.exception.ExecutionException"
+
+
+ 4265 : "com.cloud.utils.exception.HypervisorVersionChangedException"
+ 4270 : "com.cloud.utils.exception.RuntimeCloudException"
+ 4275 : "com.cloud.exception.CloudException"
+
+
+ 4280 : "com.cloud.exception.AccountLimitException"
+ 4285 : "com.cloud.exception.AgentUnavailableException"
+ 4290 : "com.cloud.exception.CloudAuthenticationException"
+
+
+ 4295 : "com.cloud.exception.CloudExecutionException"
+ 4300 : "com.cloud.exception.ConcurrentOperationException"
+ 4305 : "com.cloud.exception.ConflictingNetworkSettingsException"
+
+
+ 4310 : "com.cloud.exception.DiscoveredWithErrorException"
+ 4315 : "com.cloud.exception.HAStateException"
+ 4320 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+ 4325 : "com.cloud.exception.InsufficientCapacityException"
+ 4330 : "com.cloud.exception.InsufficientNetworkCapacityException"
+ 4335 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+ 4340 : "com.cloud.exception.InsufficientStorageCapacityException"
+ 4345 : "com.cloud.exception.InternalErrorException"
+ 4350 : "com.cloud.exception.InvalidParameterValueException"
+
+
+ 4355 : "com.cloud.exception.ManagementServerException"
+ 4360 : "com.cloud.exception.NetworkRuleConflictException"
+ 4365 : "com.cloud.exception.PermissionDeniedException"
+
+
+ 4370 : "com.cloud.exception.ResourceAllocationException"
+ 4375 : "com.cloud.exception.ResourceInUseException"
+ 4380 : "com.cloud.exception.ResourceUnavailableException"
+
+
+ 4385 : "com.cloud.exception.StorageUnavailableException"
+ 4390 : "com.cloud.exception.UnsupportedServiceException"
+ 4395 : "com.cloud.exception.VirtualMachineMigrationException"
+
+
+ 4400 : "com.cloud.exception.AccountLimitException"
+ 4405 : "com.cloud.exception.AgentUnavailableException"
+ 4410 : "com.cloud.exception.CloudAuthenticationException"
+
+
+ 4415 : "com.cloud.exception.CloudException"
+ 4420 : "com.cloud.exception.CloudExecutionException"
+ 4425 : "com.cloud.exception.ConcurrentOperationException"
+
+
+ 4430 : "com.cloud.exception.ConflictingNetworkSettingsException"
+ 4435 : "com.cloud.exception.ConnectionException"
+ 4440 : "com.cloud.exception.DiscoveredWithErrorException"
+
+
+ 4445 : "com.cloud.exception.DiscoveryException"
+ 4450 : "com.cloud.exception.HAStateException"
+ 4455 : "com.cloud.exception.InsufficientAddressCapacityException"
+
+
+ 4460 : "com.cloud.exception.InsufficientCapacityException"
+ 4465 : "com.cloud.exception.InsufficientNetworkCapacityException"
+ 4470 : "com.cloud.exception.InsufficientServerCapacityException"
+
+
+ 4475 : "com.cloud.exception.InsufficientStorageCapacityException"
+ 4480 : "com.cloud.exception.InsufficientVirtualNetworkCapcityException"
+ 4485 : "com.cloud.exception.InternalErrorException"
+
+
+ 4490 : "com.cloud.exception.InvalidParameterValueException"
+ 4495 : "com.cloud.exception.ManagementServerException"
+ 4500 : "com.cloud.exception.NetworkRuleConflictException"
+
+
+ 4505 : "com.cloud.exception.PermissionDeniedException"
+ 4510 : "com.cloud.exception.ResourceAllocationException"
+ 4515 : "com.cloud.exception.ResourceInUseException"
+
+
+ 4520 : "com.cloud.exception.ResourceUnavailableException"
+ 4525 : "com.cloud.exception.StorageUnavailableException"
+ 4530 : "com.cloud.exception.UnsupportedServiceException"
+
+
+ 4535 : "com.cloud.exception.VirtualMachineMigrationException"
+ 9999 : "com.cloud.api.ServerApiException"
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/adding-IP-addresses-for-the-public-network.xml b/docs/tmp/en-US/xml_tmp/adding-IP-addresses-for-the-public-network.xml
new file mode 100644
index 00000000000..abf4d0233cc
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/adding-IP-addresses-for-the-public-network.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Adding IP Addresses for the Public Network
+ These instructions assume you have already logged in to the &PRODUCT; UI.
+
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the desired zone .
+ Click the Network tab.
+ In the Public node of the diagram, click Configure.
+ Click the IP Ranges tab.
+ Provide the following information:
+
+ 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.
+
+
+ Click Add.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/admin-alerts.xml b/docs/tmp/en-US/xml_tmp/admin-alerts.xml
new file mode 100644
index 00000000000..4e47032c77a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/admin-alerts.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/admin-guide.xml b/docs/tmp/en-US/xml_tmp/admin-guide.xml
new file mode 100644
index 00000000000..512f7a9846a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/admin-guide.xml
@@ -0,0 +1,92 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Administrator Guide
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/adv-zone-topology-req.xml b/docs/tmp/en-US/xml_tmp/adv-zone-topology-req.xml
new file mode 100644
index 00000000000..3764e926ebe
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/adv-zone-topology-req.xml
@@ -0,0 +1,25 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Advanced Zone Topology Requirements
+ With Advanced Networking, separate subnets must be used for private and public
+ networks.
+
diff --git a/docs/tmp/en-US/xml_tmp/advanced-zone-configuration.xml b/docs/tmp/en-US/xml_tmp/advanced-zone-configuration.xml
new file mode 100644
index 00000000000..03a082f21ac
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/advanced-zone-configuration.xml
@@ -0,0 +1,376 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ 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 &PRODUCT; 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 . 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.
+
+
+ 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, &PRODUCT; adds the first pod for you. You can always add more pods later.
+ For an overview of what a pod is, see .
+ 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 &PRODUCT; uses to manage various system VMs, such as Secondary
+ Storage VMs, Console Proxy VMs, and DHCP. For more information, see .
+
+
+
+
+ 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, &PRODUCT; adds the first cluster for you. You can always add more clusters
+ later. For an overview of what a cluster is, see .
+ 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 &PRODUCT;. See Add
+ Cluster: vSphere .
+
+
+ Cluster name. Enter a name for the cluster. This
+ can be text of your choosing and is not used by &PRODUCT;.
+
+
+
+
+ In a new cluster, &PRODUCT; adds the first host for you. You can always add more hosts
+ later. For an overview of what a host is, see .
+
+ When you deploy &PRODUCT;, 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
+ &PRODUCT; and what additional configuration is required to ensure the host will work with
+ &PRODUCT;. To find these installation details, see:
+
+
+ Citrix XenServer Installation for &PRODUCT;
+
+
+ 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, &PRODUCT; adds the first primary storage server for you. You can
+ always add more servers later. For an overview of what primary storage is, see .
+ 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 &PRODUCT;.
+
+
+ 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, &PRODUCT; adds the first secondary storage server for you. For an
+ overview of what secondary storage is, see .
+ Before you can fill out this screen, you need to prepare the secondary storage by
+ setting up NFS shares and installing the latest &PRODUCT; System VM template. See Adding
+ Secondary Storage :
+
+
+ NFS Server. The IP address of the server.
+
+
+ Path. The exported path from the server.
+
+
+
+
+ Click Launch.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/advanced-zone-guest-ip-addresses.xml b/docs/tmp/en-US/xml_tmp/advanced-zone-guest-ip-addresses.xml
new file mode 100644
index 00000000000..b5d10a02d05
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/advanced-zone-guest-ip-addresses.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Advanced Zone Guest IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
diff --git a/docs/tmp/en-US/xml_tmp/advanced-zone-network-traffic-types.xml b/docs/tmp/en-US/xml_tmp/advanced-zone-network-traffic-types.xml
new file mode 100644
index 00000000000..9f475cf3f80
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/advanced-zone-network-traffic-types.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Advanced Zone Network Traffic Types
+ When advanced networking is used, there can be multiple physical networks in the zone. Each physical network can carry one or more traffic types, and you need to let &PRODUCT; know which type of network traffic you want each network to carry. The traffic types in an advanced zone are:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each &PRODUCT; account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network.
+ Management. When &PRODUCT;’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by &PRODUCT; to perform various tasks in the cloud), and any other component that communicates directly with the &PRODUCT; Management Server. You must configure the IP range for the system VMs to use.
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the &PRODUCT; UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide.
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. &PRODUCT; uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices.
+
diff --git a/docs/tmp/en-US/xml_tmp/advanced-zone-physical-network-configuration.xml b/docs/tmp/en-US/xml_tmp/advanced-zone-physical-network-configuration.xml
new file mode 100644
index 00000000000..2c3d9b3542a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/advanced-zone-physical-network-configuration.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Advanced Zone Physical Network Configuration
+ Within a zone that uses advanced networking, you need to tell the Management Server how the
+ physical network is set up to carry different kinds of traffic in isolation.
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/advanced-zone-public-ip-addresses.xml b/docs/tmp/en-US/xml_tmp/advanced-zone-public-ip-addresses.xml
new file mode 100644
index 00000000000..eeb94045e08
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/advanced-zone-public-ip-addresses.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Advanced Zone Public IP Addresses
+ When advanced networking is used, the administrator can create additional networks for use by the guests. These networks can span the zone and be available to all accounts, or they can be scoped to a single account, in which case only the named account may create guests that attach to these networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may provision thousands of these networks if desired.
+
diff --git a/docs/tmp/en-US/xml_tmp/alerts.xml b/docs/tmp/en-US/xml_tmp/alerts.xml
new file mode 100644
index 00000000000..b7f34d02a56
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/alerts.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Alerts
+ The following is the list of alert type numbers. The current alerts can be found by calling listAlerts.
+ MEMORY = 0
+ CPU = 1
+ STORAGE =2
+ STORAGE_ALLOCATED = 3
+ PUBLIC_IP = 4
+ PRIVATE_IP = 5
+ HOST = 6
+ USERVM = 7
+ DOMAIN_ROUTER = 8
+ CONSOLE_PROXY = 9
+ ROUTING = 10// lost connection to default route (to the gateway)
+ STORAGE_MISC = 11 // lost connection to default route (to the gateway)
+ USAGE_SERVER = 12 // lost connection to default route (to the gateway)
+ MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)
+ DOMAIN_ROUTER_MIGRATE = 14
+ CONSOLE_PROXY_MIGRATE = 15
+ USERVM_MIGRATE = 16
+ VLAN = 17
+ SSVM = 18
+ USAGE_SERVER_RESULT = 19
+ STORAGE_DELETE = 20;
+ UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource count
+ USAGE_SANITY_RESULT = 22;
+ DIRECT_ATTACHED_PUBLIC_IP = 23;
+ LOCAL_STORAGE = 24;
+ RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/allocators.xml b/docs/tmp/en-US/xml_tmp/allocators.xml
new file mode 100644
index 00000000000..d8ce2b8612b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/allocators.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Allocators
+ &PRODUCT; enables administrators to write custom allocators that will choose the Host to place a new guest and the storage host from which to allocate guest virtual disk images.
+
diff --git a/docs/tmp/en-US/xml_tmp/api-calls.xml b/docs/tmp/en-US/xml_tmp/api-calls.xml
new file mode 100644
index 00000000000..1fe6f02678b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/api-calls.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Calling the &PRODUCT; API
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/api-overview.xml b/docs/tmp/en-US/xml_tmp/api-overview.xml
new file mode 100644
index 00000000000..a541049e116
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/api-overview.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ &PRODUCT; API
+ The &PRODUCT; API is a low level API that has been used to implement the &PRODUCT; web UIs.
+ It is also a good basis for implementing other popular APIs such as EC2/S3 and emerging DMTF
+ standards.
+ Many &PRODUCT; 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 and the API
+ Reference.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/api-reference.xml b/docs/tmp/en-US/xml_tmp/api-reference.xml
new file mode 100644
index 00000000000..cab3adadfab
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/api-reference.xml
@@ -0,0 +1,26 @@
+
+
+
+ API Reference Documentation
+ 2.2 API Reference:
+ http://download.cloud.com/support/downloads.html/
+ 3.0 API Reference:
+ http://download.cloud.com/releases/3.0.0/api_3.0.0/TOC_Root_Admin.html/
+
+
diff --git a/docs/tmp/en-US/xml_tmp/appendix-a-time-zones.xml b/docs/tmp/en-US/xml_tmp/appendix-a-time-zones.xml
new file mode 100644
index 00000000000..595e7b5cbf5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/appendix-a-time-zones.xml
@@ -0,0 +1,143 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Appendix A—Time Zones
+ The following time zone identifiers are accepted by &PRODUCT;. 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
+ America/La_Paz
+ Asia/Jerusalem
+
+
+
+ Etc/GMT+11
+ America/Santiago
+ Europe/Minsk
+
+
+
+ Pacific/Samoa
+ America/St_Johns
+ Europe/Moscow
+
+
+ Pacific/Honolulu
+ America/Araguaina
+ Africa/Nairobi
+
+
+ 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/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/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
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/asynchronous-commands-example.xml b/docs/tmp/en-US/xml_tmp/asynchronous-commands-example.xml
new file mode 100644
index 00000000000..330f1255679
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/asynchronous-commands-example.xml
@@ -0,0 +1,106 @@
+
+
+
+ Example
+
+ The following shows an example of using an asynchronous command. Assume the API command:
+ command=deployVirtualMachine&zoneId=1&serviceOfferingId=1&diskOfferingId=1&templateId=1
+
+ CloudStack will immediately return a job ID and any other additional data.
+
+ <deployvirtualmachineresponse>
+ <jobid>1</jobid>
+ <id>100</id>
+ </deployvirtualmachineresponse>
+
+ Using the job ID, you can periodically poll for the results by using the queryAsyncJobResult command.
+ command=queryAsyncJobResult&jobId=1
+ Three possible results could come from this query.
+ Job is still pending:
+
+ <queryasyncjobresult>
+ <jobid>1</jobid>
+ <jobstatus>0</jobstatus>
+ <jobprocstatus>1</jobprocstatus>
+ </queryasyncjobresult>
+
+ Job has succeeded:
+
+ <queryasyncjobresultresponse cloud-stack-version="3.0.1.6">
+ <jobid>1</jobid>
+ <jobstatus>1</jobstatus>
+ <jobprocstatus>0</jobprocstatus>
+ <jobresultcode>0</jobresultcode>
+ <jobresulttype>object</jobresulttype>
+ <jobresult>
+ <virtualmachine>
+ <id>450</id>
+ <name>i-2-450-VM</name>
+ <displayname>i-2-450-VM</displayname>
+ <account>admin</account>
+ <domainid>1</domainid>
+ <domain>ROOT</domain>
+ <created>2011-03-10T18:20:25-0800</created>
+ <state>Running</state>
+ <haenable>false</haenable>
+ <zoneid>1</zoneid>
+ <zonename>San Jose 1</zonename>
+ <hostid>2</hostid>
+ <hostname>905-13.sjc.lab.vmops.com</hostname>
+ <templateid>1</templateid>
+ <templatename>CentOS 5.3 64bit LAMP</templatename>
+ <templatedisplaytext>CentOS 5.3 64bit LAMP</templatedisplaytext>
+ <passwordenabled>false</passwordenabled>
+ <serviceofferingid>1</serviceofferingid>
+ <serviceofferingname>Small Instance</serviceofferingname>
+ <cpunumber>1</cpunumber>
+ <cpuspeed>500</cpuspeed>
+ <memory>512</memory>
+ <guestosid>12</guestosid>
+ <rootdeviceid>0</rootdeviceid>
+ <rootdevicetype>NetworkFilesystem</rootdevicetype>
+ <nic>
+ <id>561</id>
+ <networkid>205</networkid>
+ <netmask>255.255.255.0</netmask>
+ <gateway>10.1.1.1</gateway>
+ <ipaddress>10.1.1.225</ipaddress>
+ <isolationuri>vlan://295</isolationuri>
+ <broadcasturi>vlan://295</broadcasturi>
+ <traffictype>Guest</traffictype>
+ <type>Virtual</type>
+ <isdefault>true</isdefault>
+ </nic>
+ <hypervisor>XenServer</hypervisor>
+ </virtualmachine>
+ </jobresult>
+ </queryasyncjobresultresponse>
+
+ Job has failed:
+
+ <queryasyncjobresult>
+ <jobid>1</jobid>
+ <jobstatus>2</jobstatus>
+ <jobprocstatus>0</jobprocstatus>
+ <jobresultcode>551</jobresultcode>
+ <jobresulttype>text</jobresulttype>
+ <jobresult>Unable to deploy virtual machine id = 100 due to not enough capacity</jobresult>
+ </queryasyncjobresult>
+
+
diff --git a/docs/tmp/en-US/xml_tmp/asynchronous-commands.xml b/docs/tmp/en-US/xml_tmp/asynchronous-commands.xml
new file mode 100644
index 00000000000..4c9b59cbc43
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/asynchronous-commands.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Asynchronous Commands
+ Asynchronous commands were introduced in &PRODUCT; 2.x. Commands are designated as asynchronous when they can potentially take a long period of time to complete such as creating a snapshot or disk volume. They differ from synchronous commands by the following:
+
+
+ They are identified in the API Reference by an (A).
+ They will immediately return a job ID to refer to the job that will be responsible in processing the command.
+ If executed as a "create" resource command, it will return the resource ID as well as the job ID.
+ You can periodically check the status of the job by making a simple API call to the command, queryAsyncJobResult and passing in the job ID.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/attach-iso-to-vm.xml b/docs/tmp/en-US/xml_tmp/attach-iso-to-vm.xml
new file mode 100644
index 00000000000..30e5d51947d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/attach-iso-to-vm.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Attaching an ISO to a VM
+
+ In the left navigation, click Instances.
+ Choose the virtual machine you want to work with.
+ Click the Attach ISO button
+
+
+
+ iso.png: Depicts adding an iso image
+
+ In the Attach ISO dialog box, select the desired ISO.
+ Click OK
+
+
diff --git a/docs/tmp/en-US/xml_tmp/attaching-volume.xml b/docs/tmp/en-US/xml_tmp/attaching-volume.xml
new file mode 100644
index 00000000000..360555eac06
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/attaching-volume.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Attaching a Volume
+ You can attach a volume to a guest VM to provide extra disk storage. Attach a volume when you first create a new volume, when you are moving an existing volume from one VM to another, or after you have migrated a volume from one storage pool to another.
+
+ Log in to the &PRODUCT; UI as a user or admin.
+ In the left navigation, click Storage.
+ In Select View, choose Volumes.
+ 4. Click the volume name in the Volumes list, then click the Attach Disk button
+
+
+
+ AttachDiskButton.png: button to attach a volume
+
+
+ In the Instance popup, choose the VM to which you want to attach the volume. You will only see instances to which you are allowed to attach volumes; for example, a user will see only instances created by that user, but the administrator will have more choices.
+
+
+ When the volume has been attached, you should be able to see it by clicking Instances, the instance name, and View Volumes.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/automatic-snapshot-creation-retention.xml b/docs/tmp/en-US/xml_tmp/automatic-snapshot-creation-retention.xml
new file mode 100644
index 00000000000..54fbe68e5bb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/automatic-snapshot-creation-retention.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Automatic Snapshot Creation and Retention
+ (Supported for the following hypervisors: XenServer,
+ VMware vSphere, and KVM)
+ Users can set up a recurring snapshot policy to automatically create multiple snapshots of a
+ disk at regular intervals. Snapshots can be created on an hourly, daily, weekly, or monthly
+ interval. One snapshot policy can be set up per disk volume. For example, a user can set up a
+ daily snapshot at 02:30.
+ With each snapshot schedule, users can also specify the number of scheduled snapshots to be
+ retained. Older snapshots that exceed the retention limit are automatically deleted. This
+ user-defined limit must be equal to or lower than the global limit set by the &PRODUCT;
+ administrator. See . The limit applies only to those
+ snapshots that are taken as part of an automatic recurring snapshot policy. Additional manual
+ snapshots can be created and retained.
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/aws-ec2-configuration.xml b/docs/tmp/en-US/xml_tmp/aws-ec2-configuration.xml
new file mode 100644
index 00000000000..b8966c12495
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/aws-ec2-configuration.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Enabling the AWS API Compatible Interface
+
+ The software that provides AWS API compatibility is installed along with CloudPlatform. However, you must enable the feature and perform some setup steps.
+
+
+ Set the global configuration parameter enable.ec2.api to true. See .
+ Create a set of &PRODUCT; service offerings with names that match the Amazon service offerings.
+ You can do this through the &PRODUCT; UI as described in the Administration Guide.
+ Be sure you have included the Amazon default service offering, m1.small.
+ If you did not already do so when you set the configuration parameter in step 1, restart the Management Server.
+ # service cloud-management restart
+ (Optional) The AWS API listens for requests on port 7080. If you prefer AWS API to listen on another port, you can change it as follows:
+
+ Edit the files /etc/cloud/management/server.xml, /etc/cloud/management/server-nonssl.xml, and /etc/cloud/management/server-ssl.xml.
+ In each file, find the tag <Service name="Catalina7080">. Under this tag, locate <Connector executor="tomcatThreadPool-internal" port= ....<.
+ Change the port to whatever port you want to use, then save the files.
+ Restart the Management Server.
+ If you re-install CloudStack, you will have to make these changes again.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/aws-ec2-introduction.xml b/docs/tmp/en-US/xml_tmp/aws-ec2-introduction.xml
new file mode 100644
index 00000000000..a4df086d465
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/aws-ec2-introduction.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Amazon Web Services EC2 Compatible Interface
+ &PRODUCT; can translate Amazon Web Services (AWS) API calls to native &PRODUCT; API calls
+ so that users can continue using existing AWS-compatible tools. This translation service runs as
+ a separate web application in the same tomcat server as the management server of &PRODUCT;,
+ listening on the same port. This Amazon EC2-compatible API is accessible through a SOAP web
+ service.
+
+ This service was previously enabled by separate software called CloudBridge. It is now
+ fully integrated with the &PRODUCT; management server.
+
+ Limitations
+
+
+ Supported only in zones that use basic networking.
+
+
+ Available in fresh installations of &PRODUCT;. Not available through upgrade of previous versions.
+
+
+ If you need to support features such as elastic IP, set up a Citrix NetScaler to provide this service. The commands such as ec2-associate-address will not work without EIP setup. Users running VMs in this zone will be using the NetScaler-enabled network offering (DefaultSharedNetscalerEIP and ELBNetworkOffering).
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/aws-ec2-requirements.xml b/docs/tmp/en-US/xml_tmp/aws-ec2-requirements.xml
new file mode 100644
index 00000000000..59fb5b6f5ab
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/aws-ec2-requirements.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ System Requirements
+
+ This interface complies with Amazon's WDSL version dated November 15, 2010, available at
+ http://ec2.amazonaws.com/doc/2010-11-15/.
+ Compatible with the EC2 command-line
+ tools EC2 tools v. 1.3.6230, which can be downloaded at http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-62308.zip.
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/aws-ec2-supported-commands.xml b/docs/tmp/en-US/xml_tmp/aws-ec2-supported-commands.xml
new file mode 100644
index 00000000000..9494218cd1c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/aws-ec2-supported-commands.xml
@@ -0,0 +1,396 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Supported AWS API Calls
+ The following Amazon EC2 commands are supported by &PRODUCT; when the AWS API compatibility feature is enabled.
+ For a few commands, there are differences between the &PRODUCT; and Amazon EC2 versions, and these differences are noted. The underlying SOAP call for each command is also given, for those who have built tools using those calls.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/aws-ec2-timeouts.xml b/docs/tmp/en-US/xml_tmp/aws-ec2-timeouts.xml
new file mode 100644
index 00000000000..c8b3ec6465f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/aws-ec2-timeouts.xml
@@ -0,0 +1,50 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using Timeouts to Ensure AWS API Command Completion
+ The Amazon EC2 command-line tools have a default connection timeout. When used with &PRODUCT;, a longer timeout might be needed for some commands. If you find that commands are not completing due to timeouts, you can gain more time for commands to finish by overriding the default timeouts on individual commands. You can add the following optional command-line parameters to any &PRODUCT;-supported EC2 command:
+
+
+
+
+
+
+ --connection-timeout TIMEOUT
+ Specifies a connection timeout (in seconds).
+ Example: --connection-timeout 30
+
+
+
+ --request-timeout TIMEOUT
+ Specifies a request timeout (in seconds).
+ Example: --request-timeout 45
+
+
+
+
+
+ Example:
+ ec2-run-instances 2 –z us-test1 –n 1-3 --connection-timeout 120 --request-timeout 120
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/aws-ec2-user-setup.xml b/docs/tmp/en-US/xml_tmp/aws-ec2-user-setup.xml
new file mode 100644
index 00000000000..8607378d88c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/aws-ec2-user-setup.xml
@@ -0,0 +1,97 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ AWS API User Setup Steps
+ In general, users need not be aware that they are using a translation service provided by &PRODUCT;.
+ They need only send AWS API calls to &PRODUCT;'s endpoint, and it will translate the calls to the native API.
+ Users of the Amazon EC2 compatible interface will be able to keep their existing EC2 tools
+ and scripts and use them with their &PRODUCT; deployment, by specifying the endpoint of the
+ management server and using the proper user credentials. In order to do this, each user must
+ perform the following configuration steps:
+
+
+
+ Generate user credentials and register with the service.
+
+
+ Set up the environment variables for the EC2 command-line tools.
+
+
+ For SOAP access, use the endpoint http://&PRODUCT;-management-server:7080/awsapi.
+ The &PRODUCT;-management-server can be specified by a fully-qualified domain name or IP address.
+
+
+
+
+ AWS API User Registration
+ Each user must perform a one-time registration. The user follows these steps:
+
+
+ Obtain the following by looking in the &PRODUCT; UI, using the API, or asking the cloud administrator:
+
+ The &PRODUCT; server's publicly available DNS name or IP address
+ The user account's API key and Secret key
+
+
+
+
+ Generate a private key and a self-signed X.509 certificate. The user substitutes their own desired storage location for /path/to/… below.
+
+ $ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /path/to/private_key.pem -out /path/to/cert.pem
+
+
+
+
+ Register the mapping from the X.509 certificate to the API/Secret keys.
+ Download the following script from http://download.cloud.com/releases/3.0.3/cloudstack-aws-api-register and run it.
+ Substitute the values that were obtained in step 1 in the URL below.
+
+
+$ cloudstack-aws-api-register --apikey=User’s &PRODUCT; API key --secretkey=User’s &PRODUCT; Secret key --cert=/path/to/cert.pem --url=http://&PRODUCT;.server:7080/awsapi
+
+
+
+
+
+ A user with an existing AWS certificate could choose to use the same certificate with &PRODUCT;, but the public key would be uploaded to the &PRODUCT; management server database.
+
+
+
+
+ AWS API Command-Line Tools Setup
+ To use the EC2 command-line tools, the user must perform these steps:
+
+ Be sure you have the right version of EC2 Tools.
+ The supported version is available at http://s3.amazonaws.com/ec2-downloads/ec2-api-tools-1.3-62308.zip.
+
+
+ Set up the environment variables that will direct the tools to the server. As a best practice, you may wish to place these commands in a script that may be sourced before using the AWS API translation feature.
+ $ export EC2_CERT=/path/to/cert.pem
+$ export EC2_PRIVATE_KEY=/path/to/private_key.pem
+$ export EC2_URL=http://&PRODUCT;.server:7080/awsapi
+$ export EC2_HOME=/path/to/EC2_tools_directory
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/aws-interface-compatibility.xml b/docs/tmp/en-US/xml_tmp/aws-interface-compatibility.xml
new file mode 100644
index 00000000000..a03d447b50d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/aws-interface-compatibility.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Amazon Web Service Interface Compatibility
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/basic-adv-networking.xml b/docs/tmp/en-US/xml_tmp/basic-adv-networking.xml
new file mode 100644
index 00000000000..46f0650e69f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/basic-adv-networking.xml
@@ -0,0 +1,113 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Basic and Advanced Networking
+ &PRODUCT; provides two styles of networking:.
+
+ Basic
+ For AWS-style networking. Provides a single network where guest isolation can be provided
+ through layer-3 means such as security groups (IP address source filtering).
+
+
+ Advanced
+ For more sophisticated network topologies. This network model provides the most
+ flexibility in defining guest networks, but requires more configuration steps than basic
+ networking.
+
+ Each zone has either basic or advanced networking. Once the choice of networking model for a
+ zone has been made and configured in &PRODUCT;, it can not be changed. A zone is either
+ basic or advanced for its entire lifetime.
+ The following table compares the networking features in the two networking models.
+
+
+
+
+ Networking Feature
+ Basic Network
+ Advanced Network
+
+
+
+
+ Number of networks
+ Single network
+ Multiple networks
+
+
+ Firewall type
+ Physical
+ Physical and Virtual
+
+
+ Load balancer
+ Physical
+ Physical and Virtual
+
+
+ Isolation type
+ Layer 3
+ Layer 2 and Layer 3
+
+
+ VPN support
+ No
+ Yes
+
+
+ Port forwarding
+ Physical
+ Physical and Virtual
+
+
+ 1:1 NAT
+ Physical
+ Physical and Virtual
+
+
+ Source NAT
+ No
+ Physical and Virtual
+
+
+ Userdata
+ Yes
+ Yes
+
+
+ Network usage monitoring
+ sFlow / netFlow at physical router
+ Hypervisor and Virtual Router
+
+
+ DNS and DHCP
+ Yes
+ Yes
+
+
+
+
+ The two types of networking may be in use in the same cloud. However, a given zone must use
+ either Basic Networking or Advanced Networking.
+ Different types of network traffic can be segmented on the same physical network. Guest
+ traffic can also be segmented by account. To isolate traffic, you can use separate VLANs. If you
+ are using separate VLANs on a single physical network, make sure the VLAN tags are in separate
+ numerical ranges.
+
diff --git a/docs/tmp/en-US/xml_tmp/basic-zone-configuration.xml b/docs/tmp/en-US/xml_tmp/basic-zone-configuration.xml
new file mode 100644
index 00000000000..e27c91493fa
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/basic-zone-configuration.xml
@@ -0,0 +1,146 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 &PRODUCT; 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.
+
+ (Introduced in version 3.0.1) 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. &PRODUCT; 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, &PRODUCT; adds the first pod for you. You can always add more pods later. For an overview of what a pod is, see .
+ 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 &PRODUCT; 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 &PRODUCT; 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, &PRODUCT; 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 &PRODUCT;. See Add Cluster: vSphere.
+ Cluster name. Enter a name for the cluster. This can be text of your choosing and is not used by &PRODUCT;.
+
+
+ In a new cluster, &PRODUCT; adds the first host for you. You can always add more hosts later. For an overview of what a host is, see About Hosts.
+ When you add a hypervisor host to &PRODUCT;, 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 &PRODUCT; and what additional configuration is required to ensure the host will work with &PRODUCT;. 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, CloudPlatform 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/basic-zone-guest-ip-addresses.xml b/docs/tmp/en-US/xml_tmp/basic-zone-guest-ip-addresses.xml
new file mode 100644
index 00000000000..d1d9135b4c6
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/basic-zone-guest-ip-addresses.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Basic Zone Guest IP Addresses
+ When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the guests in that pod. The administrator must add a Direct IP range on the pod for this purpose. These IPs are in the same VLAN as the hosts.
+
diff --git a/docs/tmp/en-US/xml_tmp/basic-zone-network-traffic-types.xml b/docs/tmp/en-US/xml_tmp/basic-zone-network-traffic-types.xml
new file mode 100644
index 00000000000..fa3be0f442b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/basic-zone-network-traffic-types.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Basic Zone Network Traffic Types
+ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types:
+
+ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod.
+ Management. When &PRODUCT;’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by &PRODUCT; to perform various tasks in the cloud), and any other component that communicates directly with the &PRODUCT; Management Server. You must configure the IP range for the system VMs to use.
+ We strongly recommend the use of separate NICs for management traffic and guest traffic.
+ Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the &PRODUCT; UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address.
+ Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. &PRODUCT; uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network.
+
+ In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. &PRODUCT; takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.
+
diff --git a/docs/tmp/en-US/xml_tmp/basic-zone-physical-network-configuration.xml b/docs/tmp/en-US/xml_tmp/basic-zone-physical-network-configuration.xml
new file mode 100644
index 00000000000..83833a73e78
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/basic-zone-physical-network-configuration.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Basic Zone Physical Network Configuration
+ In a basic network, configuring the physical network is fairly straightforward. You only need to configure one guest network to carry traffic that is generated by guest VMs. When you first add a zone to CloudPlatform, you set up the guest network through the Add Zone screens.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/best-practices-for-vms.xml b/docs/tmp/en-US/xml_tmp/best-practices-for-vms.xml
new file mode 100644
index 00000000000..04c3c0aa276
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/best-practices-for-vms.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Best Practices for Virtual Machines
+ The &PRODUCT; administrator should monitor the total number of VM instances in each
+ cluster, and disable allocation to the cluster if the total is approaching the maximum that
+ the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of
+ one or more hosts failing, which would increase the VM load on the other hosts as the VMs
+ are automatically redeployed. Consult the documentation for your chosen hypervisor to find
+ the maximum permitted number of VMs per host, then use &PRODUCT; global configuration
+ settings to set this as the default limit. Monitor the VM activity in each cluster at all
+ times. Keep the total number of VMs below a safe level that allows for the occasional host
+ failure. For example, if there are N hosts in the cluster, and you want to allow for one
+ host in the cluster to be down at any given time, the total number of VM instances you can
+ permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this
+ number of VMs, use the &PRODUCT; UI to disable allocation of more VMs to the
+ cluster.
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/best-practices-primary-storage.xml b/docs/tmp/en-US/xml_tmp/best-practices-primary-storage.xml
new file mode 100644
index 00000000000..2f639b130cb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/best-practices-primary-storage.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Best Practices for Primary Storage
+
+ The speed of primary storage will impact guest performance. If possible, choose smaller, higher RPM drives for primary storage.
+ Ensure that nothing is stored on the server. Adding the server to CloudPlatform will destroy any existing data
+
+
diff --git a/docs/tmp/en-US/xml_tmp/best-practices-secondary-storage.xml b/docs/tmp/en-US/xml_tmp/best-practices-secondary-storage.xml
new file mode 100644
index 00000000000..c2da7d8be2d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/best-practices-secondary-storage.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Best Practices for Secondary Storage
+
+ Each Zone can have one or more secondary storage servers. Multiple secondary storage servers provide increased scalability to the system.
+ Secondary storage has a high read:write ratio and is expected to consist of larger drives with lower IOPS than primary storage.
+ Ensure that nothing is stored on the server. Adding the server to CloudPlatform will destroy any existing data.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/best-practices-templates.xml b/docs/tmp/en-US/xml_tmp/best-practices-templates.xml
new file mode 100644
index 00000000000..4e2992c021d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/best-practices-templates.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Best Practices for Templates
+ If you plan to use large templates (100 GB or larger), be sure you have a 10-gigabit network to support the large templates. A slower network can lead to timeouts and other errors when large templates are used.
+
diff --git a/docs/tmp/en-US/xml_tmp/best-practices-virtual-router.xml b/docs/tmp/en-US/xml_tmp/best-practices-virtual-router.xml
new file mode 100644
index 00000000000..060d8680992
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/best-practices-virtual-router.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Best Practices for Virtual Routers
+
+ WARNING: Restarting a virtual router from a hypervisor console deletes all the iptables rules. To work around this issue, stop the virtual router and start it from the &PRODUCT; UI.
+ WARNING: Do not use the destroyRouter API when only one router is available in the network, because restartNetwork API with the cleanup=false parameter can't recreate it later. If you want to destroy and recreate the single router available in the network, use the restartNetwork API with the cleanup=true parameter.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/build-deb.xml b/docs/tmp/en-US/xml_tmp/build-deb.xml
new file mode 100644
index 00000000000..deee3ceb1de
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/build-deb.xml
@@ -0,0 +1,123 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Building DEB packages
+
+ In addition to the bootstrap dependencies, you'll also need to install
+ several other dependencies. Note that we recommend using Maven 3, which
+ is not currently available in 12.04.1 LTS. So, you'll also need to add a
+ PPA repository that includes Maven 3. After running the command
+ add-apt-repository, you will be prompted to continue and
+ a GPG key will be added.
+
+
+$ sudo apt-get update
+$ sudo apt-get install python-software-properties
+$ sudo add-apt-repository ppa:natecarlson/maven3
+$ sudo apt-get update
+$ sudo apt-get install ant debhelper openjdk-6-jdk tomcat6 libws-commons-util-java genisoimage python-mysqldb libcommons-codec-java libcommons-httpclient-java liblog4j1.2-java maven3
+
+
+ While we have defined, and you have presumably already installed the
+ bootstrap prerequisites, there are a number of build time prerequisites
+ that need to be resolved. &PRODUCT; uses maven for dependency resolution.
+ You can resolve the buildtime depdencies for CloudStack by running:
+
+$ mvn3 -P deps
+
+ Now that we have resolved the dependencies we can move on to building &PRODUCT;
+ and packaging them into DEBs by issuing the following command.
+
+
+$ dpkg-buildpackge -uc -us
+
+
+
+ This command will build 16 Debian packages. You should have all of the following:
+
+
+cloud-agent_4.0.0-incubating_amd64.deb
+cloud-agent-deps_4.0.0-incubating_amd64.deb
+cloud-agent-libs_4.0.0-incubating_amd64.deb
+cloud-awsapi_4.0.0-incubating_amd64.deb
+cloud-cli_4.0.0-incubating_amd64.deb
+cloud-client_4.0.0-incubating_amd64.deb
+cloud-client-ui_4.0.0-incubating_amd64.deb
+cloud-core_4.0.0-incubating_amd64.deb
+cloud-deps_4.0.0-incubating_amd64.deb
+cloud-python_4.0.0-incubating_amd64.deb
+cloud-scripts_4.0.0-incubating_amd64.deb
+cloud-server_4.0.0-incubating_amd64.deb
+cloud-setup_4.0.0-incubating_amd64.deb
+cloud-system-iso_4.0.0-incubating_amd64.deb
+cloud-usage_4.0.0-incubating_amd64.deb
+cloud-utils_4.0.0-incubating_amd64.deb
+
+
+
+ Setting up an APT repo
+
+ After you've created the packages, you'll want to copy them to a system where you can serve the packages over HTTP. You'll create a directory for the packages and then use dpkg-scanpackages to create Packages.gz, which holds information about the archive structure. Finally, you'll add the repository to your system(s) so you can install the packages using APT.
+
+ The first step is to make sure that you have the dpkg-dev package installed. This should have been installed when you pulled in the debhelper application previously, but if you're generating Packages.gz on a different system, be sure that it's installed there as well.
+
+$ sudo apt-get install dpkg-dev
+
+The next step is to copy the DEBs to the directory where they can be served over HTTP. We'll use /var/www/cloudstack/repo in the examples, but change the directory to whatever works for you.
+
+
+sudo mkdir -p /var/www/cloudstack/repo/binary
+sudo cp *.deb /var/www/cloudstack/repo/binary
+sudo cd /var/www/cloudstack/repo/binary
+sudo dpkg-scanpackages . /dev/null | tee Packages | gzip -9 > Packages.gz
+
+
+Note: Override Files
+ You can safely ignore the warning about a missing override file.
+
+
+Now you should have all of the DEB packages and Packages.gz in the binary directory and available over HTTP. (You may want to use wget or curl to test this before moving on to the next step.)
+
+
+
+ Configuring your machines to use the APT repository
+
+ Now that we have created the repository, you need to configure your machine
+ to make use of the APT repository. You can do this by adding a repository file
+ under /etc/apt/sources.list.d. Use your preferred editor to
+ create /etc/apt/sources.list.d/cloudstack.list with this
+ line:
+
+ deb http://server.url/cloudstack/repo binary/
+
+ Now that you have the repository info in place, you'll want to run another
+ update so that APT knows where to find the &PRODUCT; packages.
+
+$ sudo apt-get update
+
+You can now move on to the instructions under Install on Ubuntu.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/build-rpm.xml b/docs/tmp/en-US/xml_tmp/build-rpm.xml
new file mode 100644
index 00000000000..e983aba8fe5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/build-rpm.xml
@@ -0,0 +1,82 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Building RPMs
+
+ While we have defined, and you have presumably already installed the
+ bootstrap prerequisites, there are a number of build time prerequisites
+ that need to be resolved. &PRODUCT; uses maven for dependency resolution.
+ You can resolve the buildtime depdencies for CloudStack by running the
+ following command:
+ $mvn -P deps
+
+
+ Now that we have resolved the dependencies we can move on to building &PRODUCT;
+ and packaging them into RPMs by issuing the following command.
+ $./waf rpm
+
+
+ Once this completes, you should find assembled RPMs in
+ artifacts/rpmbuild/RPMS/x86_64
+
+
+ Creating a yum repo
+
+ While RPMs is an ideal packaging format - it's most easily consumed from
+ yum repositories over a network. We'll move into the directory with the
+ newly created RPMs by issuing the following command:
+ $cd artifacts/rpmbuild/RPMS/x86_64
+
+
+ Next we'll issue a command to create the repository metadata by
+ issuing the following command:
+ $createrepo ./
+
+
+ The files and directories within our current working directory can now
+ be uploaded to a web server and serve as a yum repository
+
+
+
+ Configuring your systems to use your new yum repository
+
+ Now that your yum repository is populated with RPMs and metadata
+ we need to configure our machines that need to install CloudStack.
+ We will create a file at /etc/yum.repos.d/cloudstack.repo
+ with the following content:
+
+[apache-cloudstack]
+name=Apache CloudStack
+baseurl=http://webserver.tld/path/to/repo
+enabled=1
+gpgcheck=0
+
+
+
+ Completing this step will allow you to easily install CloudStack on a number of
+ machines across the network.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/castor-with-cs.xml b/docs/tmp/en-US/xml_tmp/castor-with-cs.xml
new file mode 100644
index 00000000000..5049d33d638
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/castor-with-cs.xml
@@ -0,0 +1,87 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Using the CAStor Back-end Storage with &PRODUCT;
+ This section describes how to use a CAStor cluster as the back-end storage system for a
+ &PRODUCT; S3 front-end. The CAStor back-end storage for &PRODUCT; extends the existing storage
+ classes and allows the storage configuration attribute to point to a CAStor cluster.
+ This feature makes use of the &PRODUCT; server's local disk to spool files before writing
+ them to CAStor when handling the PUT operations. However, a file must be successfully written
+ into the CAStor cluster prior to the return of a success code to the S3 client to ensure that
+ the transaction outcome is correctly reported.
+
+ The S3 multipart file upload is not supported in this release. You are prompted with
+ proper error message if a multipart upload is attempted.
+
+ To configure CAStor:
+
+
+ Install &PRODUCT; 4.0.0-incubating by following the instructions given in the INSTALL.txt
+ file.
+
+ You can use the S3 storage system in &PRODUCT; without setting up and installing the
+ compute components.
+
+
+
+ Enable the S3 API by setting "enable.s3.api = true" in the Global parameter section in
+ the UI and register a user.
+ For more information, see S3 API in
+ &PRODUCT;.
+
+
+ Edit the cloud-bridge.properties file and modify the "storage.root" parameter.
+
+
+ Set "storage.root" to the key word "castor".
+
+
+ Specify a CAStor tenant domain to which content is written. If the domain is not
+ specified, the CAStor default domain, specified by the "cluster" parameter in CAStor's
+ node.cfg file, will be used.
+
+
+ Specify a list of node IP addresses, or set "zeroconf" and the cluster
+ name. When using a static IP list with a large cluster, it is not necessary to include
+ every node, only a few is required to initialize the client software.
+ For example:
+ storage.root=castor domain=cloudstack 10.1.1.51 10.1.1.52 10.1.1.53
+ In this example, the configuration file directs &PRODUCT; to write the S3 files to
+ CAStor instead of to a file system, where the CAStor domain name is cloudstack, and the
+ CAStor node IP addresses are those listed.
+
+
+ (Optional) The last value is a port number on which to communicate with the CAStor
+ cluster. If not specified, the default is 80.
+ #Static IP list with optional port
+storage.root=castor domain=cloudstack 10.1.1.51 10.1.1.52 10.1.1.53 80
+#Zeroconf locator for cluster named "castor.example.com"
+storage.root=castor domain=cloudstack zeroconf=castor.example.com
+
+
+
+
+ Create the tenant domain within the CAStor storage cluster. If you omit this step before
+ attempting to store content, you will get HTTP 412 errors in the awsapi.log.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/change-console-proxy-ssl-certificate-domain.xml b/docs/tmp/en-US/xml_tmp/change-console-proxy-ssl-certificate-domain.xml
new file mode 100644
index 00000000000..46ceaae1a19
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/change-console-proxy-ssl-certificate-domain.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Changing the Console Proxy SSL Certificate and Domain
+ If the administrator prefers, it is possible for the URL of the customer's console session to show a domain other than realhostip.com. The administrator can customize the displayed domain by selecting a different domain and uploading a new SSL certificate and private key. The domain must run a DNS service that is capable of resolving queries for addresses of the form aaa-bbb-ccc-ddd.your.domain to an IPv4 IP address in the form aaa.bbb.ccc.ddd, for example, 202.8.44.1. To change the console proxy domain, SSL certificate, and private key:
+
+ Set up dynamic name resolution or populate all possible DNS names in your public IP range into your existing DNS server with the format aaa-bbb-ccc-ddd.company.com -> aaa.bbb.ccc.ddd.
+ Generate the private key and certificate signing request (CSR). When you are using openssl to generate private/public key pairs and CSRs, for the private key that you are going to paste into the &PRODUCT; UI, be sure to convert it into PKCS#8 format.
+
+ Generate a new 2048-bit private keyopenssl genrsa -des3 -out yourprivate.key 2048
+ Generate a new certificate CSRopenssl req -new -key yourprivate.key -out yourcertificate.csr
+ Head to the website of your favorite trusted Certificate Authority, purchase an SSL certificate, and submit the CSR. You should receive a valid certificate in return
+ Convert your private key format into PKCS#8 encrypted format.openssl pkcs8 -topk8 -in yourprivate.key -out yourprivate.pkcs8.encryped.key
+ Convert your PKCS#8 encrypted private key into the PKCS#8 format that is compliant with &PRODUCT;openssl pkcs8 -in yourprivate.pkcs8.encrypted.key -out yourprivate.pkcs8.key
+
+
+ In the Update SSL Certificate screen of the &PRODUCT; UI, paste the following
+
+ Certificate from step 1(c).
+ Private key from step 1(e).
+ The desired new domain name; for example, company.com
+
+
+ The desired new domain name; for example, company.comThis stops all currently running console proxy VMs, then restarts them with the new certificate and key. Users might notice a brief interruption in console availability
+
+ The Management Server will generate URLs of the form "aaa-bbb-ccc-ddd.company.com" after this change is made. New console requests will be served with the new DNS domain name, certificate, and key
+
diff --git a/docs/tmp/en-US/xml_tmp/change-database-config.xml b/docs/tmp/en-US/xml_tmp/change-database-config.xml
new file mode 100644
index 00000000000..fadb64c27e7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/change-database-config.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Changing the Database Configuration
+ The &PRODUCT; Management Server stores database configuration information (e.g., hostname, port, credentials) in the file /etc/cloud/management/db.properties. To effect a change, edit this file on each Management Server, then restart the Management Server.
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/change-host-password.xml b/docs/tmp/en-US/xml_tmp/change-host-password.xml
new file mode 100644
index 00000000000..7221fe62417
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/change-host-password.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 &PRODUCT; 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:
+ 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".
+ mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;
+
+
diff --git a/docs/tmp/en-US/xml_tmp/change-network-offering-on-guest-network.xml b/docs/tmp/en-US/xml_tmp/change-network-offering-on-guest-network.xml
new file mode 100644
index 00000000000..98f1b63f484
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/change-network-offering-on-guest-network.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Changing the Network Offering on a Guest Network
+ A user or administrator can change the network offering that is associated with an existing guest network.
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+ If you are changing from a network offering that uses the &PRODUCT; virtual router to one that uses external devices as network service providers, you must first stop all the VMs on the network. See Stopping and Starting VMs. Then return here and continue to the next step
+ In the left navigation, choose Network
+ Click the name of the network you want to modify
+
+
+
+ AttachDiskButton.png: button to attach a volume
+ .
+ In Network Offering, choose the new network offering, then click Apply.
+ A prompt appears asking whether you want to keep the existing CIDR. This is to let you know that if you change the network offering, the CIDR will be affected. Choose No to proceed with the change.
+ Wait for the update to complete. Don’t try to restart VMs until after the network change is complete.
+ If you stopped any VMs in step 2, restart them.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/change-to-behavior-of-list-commands.xml b/docs/tmp/en-US/xml_tmp/change-to-behavior-of-list-commands.xml
new file mode 100644
index 00000000000..69b9e4d2beb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/change-to-behavior-of-list-commands.xml
@@ -0,0 +1,108 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Change to Behavior of List Commands
+ There was a major change in how our List* API commands work in CloudStack 3.0 compared to
+ 2.2.x. The rules below apply only for managed resources – those that belong to an account,
+ domain, or project. They are irrelevant for the List* commands displaying unmanaged (system)
+ resources, such as hosts, clusters, and external network resources.
+ When no parameters are passed in to the call, the caller sees only resources owned by the
+ caller (even when the caller is the administrator). Previously, the administrator saw everyone
+ else's resources by default.
+ When accountName and domainId are passed in:
+
+
+ The caller sees the resources dedicated to the account specified.
+
+
+ If the call is executed by a regular user, the user is authorized to specify only the
+ user's own account and domainId.
+
+
+ If the caller is a domain administrator, CloudStack performs an authorization check to
+ see whether the caller is permitted to view resources for the given account and
+ domainId.
+
+
+ When projectId is passed in, only resources belonging to that project are listed.
+ When domainId is passed in, the call returns only resources belonging to the domain
+ specified. To see the resources of subdomains, use the parameter isRecursive=true. Again, the
+ regular user can see only resources owned by that user, the root administrator can list
+ anything, and a domain administrator is authorized to see only resources of the administrator's
+ own domain and subdomains.
+ To see all resources the caller is authorized to see, except for Project resources, use the
+ parameter listAll=true.
+ To see all Project resources the caller is authorized to see, use the parameter
+ projectId=-1.
+ There is one API command that doesn't fall under the rules above completely: the
+ listTemplates command. This command has its own flags defining the list rules:
+
+
+
+
+
+
+ listTemplates Flag
+ Description
+
+
+
+
+ featured
+ Returns templates that have been marked as featured and
+ public.
+
+
+ self
+ Returns templates that have been registered or created by the calling
+ user.
+
+
+ selfexecutable
+ Same as self, but only returns templates that are ready to be deployed
+ with.
+
+
+ sharedexecutable
+ Ready templates that have been granted to the calling user by another
+ user.
+
+
+ executable
+ Templates that are owned by the calling user, or public templates, that can
+ be used to deploy a new VM.
+
+
+ community
+ Returns templates that have been marked as public but not
+ featured.
+
+
+ all
+ Returns all templates (only usable by admins).
+
+
+
+
+ The &PRODUCT; UI on a general view will display all resources that the logged-in user is
+ authorized to see, except for project resources. To see the project resources, select the
+ project view.
+
diff --git a/docs/tmp/en-US/xml_tmp/changed-apicommands-4.0.xml b/docs/tmp/en-US/xml_tmp/changed-apicommands-4.0.xml
new file mode 100644
index 00000000000..042d5e2611e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/changed-apicommands-4.0.xml
@@ -0,0 +1,268 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Changed API Commands in 4.0.0-incubating
+
+
+
+
+
+
+ API Commands
+ Description
+
+
+
+
+
+ copyTemplate
+ prepareTemplate
+ registerTemplate
+ updateTemplate
+ createProject
+ activateProject
+ suspendProject
+ updateProject
+ listProjectAccounts
+ createVolume
+ migrateVolume
+ attachVolume
+ detachVolume
+ uploadVolume
+ createSecurityGroup
+ registerIso
+ copyIso
+ updateIso
+ createIpForwardingRule
+ listIpForwardingRules
+ createLoadBalancerRule
+ updateLoadBalancerRule
+ createSnapshot
+
+
+ The commands in this list have a single new response parameter, and no other
+ changes.
+ New response parameter: tags(*)
+
+ Many other commands also have the new tags(*) parameter in addition to other
+ changes; those commands are listed separately.
+
+
+
+
+ rebootVirtualMachine
+ attachIso
+ detachIso
+ listLoadBalancerRuleInstances
+ resetPasswordForVirtualMachine
+ changeServiceForVirtualMachine
+ recoverVirtualMachine
+ startVirtualMachine
+ migrateVirtualMachine
+ deployVirtualMachine
+ assignVirtualMachine
+ updateVirtualMachine
+ restoreVirtualMachine
+ stopVirtualMachine
+ destroyVirtualMachine
+
+
+ The commands in this list have two new response parameters, and no other
+ changes.
+ New response parameters: keypair, tags(*)
+
+
+
+
+ listSecurityGroups
+ listFirewallRules
+ listPortForwardingRules
+ listSnapshots
+ listIsos
+ listProjects
+ listTemplates
+ listLoadBalancerRules
+
+ The commands in this list have the following new parameters, and no other
+ changes.
+ New request parameter: tags (optional)
+ New response parameter: tags(*)
+
+
+
+
+ listF5LoadBalancerNetworks
+ listNetscalerLoadBalancerNetworks
+ listSrxFirewallNetworks
+ updateNetwork
+
+
+ The commands in this list have three new response parameters, and no other
+ changes.
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ createZone
+ updateZone
+
+ The commands in this list have the following new parameters, and no other
+ changes.
+ New request parameter: localstorageenabled (optional)
+ New response parameter: localstorageenabled
+
+
+
+ listZones
+ New response parameter: localstorageenabled
+
+
+
+ rebootRouter
+ changeServiceForRouter
+ startRouter
+ destroyRouter
+ stopRouter
+
+ The commands in this list have two new response parameters, and no other
+ changes.
+ New response parameters: vpcid, nic(*)
+
+
+
+ updateAccount
+ disableAccount
+ listAccounts
+ markDefaultZoneForAccount
+ enableAccount
+
+ The commands in this list have three new response parameters, and no other
+ changes.
+ New response parameters: vpcavailable, vpclimit, vpctotal
+
+
+ listRouters
+
+ New request parameters: forvpc (optional), vpcid (optional)
+ New response parameters: vpcid, nic(*)
+
+
+
+ listNetworkOfferings
+
+ New request parameters: forvpc (optional)
+ New response parameters: forvpc
+
+
+
+ listVolumes
+
+ New request parameters: details (optional), tags (optional)
+ New response parameters: tags(*)
+
+
+
+ addTrafficMonitor
+
+ New request parameters: excludezones (optional), includezones (optional)
+
+
+
+ createNetwork
+
+ New request parameters: vpcid (optional)
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+ listPublicIpAddresses
+
+ New request parameters: tags (optional), vpcid (optional)
+ New response parameters: vpcid, tags(*)
+
+
+
+ listNetworks
+
+ New request parameters: canusefordeploy (optional), forvpc (optional), tags
+ (optional), vpcid (optional)
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+ restartNetwork
+
+ New response parameters: vpcid, tags(*)
+
+
+
+ enableStaticNat
+
+ New request parameter: networkid (optional)
+
+
+
+ createDiskOffering
+
+ New request parameter: storagetype (optional)
+ New response parameter: storagetype
+
+
+
+ listDiskOfferings
+
+ New response parameter: storagetype
+
+
+
+ updateDiskOffering
+
+ New response parameter: storagetype
+
+
+
+ createFirewallRule
+
+ Changed request parameters: ipaddressid (old version - optional, new version -
+ required)
+ New response parameter: tags(*)
+
+
+
+ listVirtualMachines
+
+ New request parameters: isoid (optional), tags (optional), templateid
+ (optional)
+ New response parameters: keypair, tags(*)
+
+
+
+ updateStorageNetworkIpRange
+
+ New response parameters: id, endip, gateway, netmask, networkid, podid, startip,
+ vlan, zoneid
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/changing-root-password.xml b/docs/tmp/en-US/xml_tmp/changing-root-password.xml
new file mode 100644
index 00000000000..0d2333a2a67
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/changing-root-password.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 &PRODUCT; 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 &PRODUCT;, 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:
+ 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.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/changing-secondary-storage-ip.xml b/docs/tmp/en-US/xml_tmp/changing-secondary-storage-ip.xml
new file mode 100644
index 00000000000..7e146de812f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/changing-secondary-storage-ip.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Making API Requests
+ You can change the secondary storage IP address after it has been provisioned. After changing the IP address on the host, log in to your management server and execute the following commands. Replace HOSTID below with your own value, and change the URL to use the appropriate IP address and path for your server:
+
+ # mysql -p
+ mysql> use cloud;
+ mysql> select id from host where type = 'SecondaryStorage';
+ mysql> update host_details set value = 'nfs://192.168.160.20/export/mike-ss1'
+ where host_id = HOSTID and name = 'orig.url';
+ mysql> update host set name = 'nfs://192.168.160.20/export/mike-ss1' where type
+ = 'SecondaryStorage' and id = #;
+ mysql> update host set url = 'nfs://192.168.160.20/export/mike-ss1' where type
+ = 'SecondaryStorage' and id = #;
+ mysql> update host set guid = 'nfs://192.168.160.20/export/mike-ss1' where type
+ = 'SecondaryStorage' and id = #;
+
+ 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.
+ Then log in to the cloud console UI and stop and start (not reboot) the Secondary Storage VM for that Zone.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/changing-secondary-storage-servers.xml b/docs/tmp/en-US/xml_tmp/changing-secondary-storage-servers.xml
new file mode 100644
index 00000000000..62ad65015a3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/changing-secondary-storage-servers.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Changing Secondary Storage Servers
+ You can change the secondary storage NFS mount. Perform the following steps to do so:
+
+ Stop all running Management Servers.
+ Wait 30 minutes. This allows any writes to secondary storage to complete.
+ Copy all files from the old secondary storage mount to the new.
+ Use the procedure above to change the IP address for secondary storage if required.
+ Start the Management Server.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/changing-secondary-storage-serversp.xml b/docs/tmp/en-US/xml_tmp/changing-secondary-storage-serversp.xml
new file mode 100644
index 00000000000..62ad65015a3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/changing-secondary-storage-serversp.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Changing Secondary Storage Servers
+ You can change the secondary storage NFS mount. Perform the following steps to do so:
+
+ Stop all running Management Servers.
+ Wait 30 minutes. This allows any writes to secondary storage to complete.
+ Copy all files from the old secondary storage mount to the new.
+ Use the procedure above to change the IP address for secondary storage if required.
+ Start the Management Server.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/changing-service-offering-for-vm.xml b/docs/tmp/en-US/xml_tmp/changing-service-offering-for-vm.xml
new file mode 100644
index 00000000000..5a42912e130
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/changing-service-offering-for-vm.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Changing the Service Offering for a VM
+ To upgrade or downgrade the level of compute resources available to a virtual machine, you can change the VM's compute offering.
+
+ Log in to the &PRODUCT; UI as a user or admin.
+ In the left navigation, click Instances.
+ Choose the VM that you want to work with.
+ Click the Stop button to stop the VM
+
+
+
+ StopButton.png: button to stop a VM
+
+
+ Click the Change Service button
+
+
+
+ ChangeServiceButton.png: button to change the service of a VM
+ . The Change service dialog box is displayed.
+ Select the offering you want.
+ Click OK.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/changing-vm-name-os-group.xml b/docs/tmp/en-US/xml_tmp/changing-vm-name-os-group.xml
new file mode 100644
index 00000000000..f16ffdab059
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/changing-vm-name-os-group.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Changing the VM Name, OS, or Group
+ After a VM is created, you can modify the display name, operating system, and the group it belongs to.
+ To access a VM through the &PRODUCT; UI:
+
+ Log in to the &PRODUCT; UI as a user or admin.
+ In the left navigation, click Instances.
+ Select the VM that you want to modify.
+ Click the Stop button to stop the VM
+
+
+
+ StopButton.png: button to stop a VM
+
+
+ Click Edit
+
+
+
+ StopButton.png: button to edit the properties of a VM
+ .
+ Make the desired changes to the following:
+
+ Display name: Enter a new display name if you want to change the name of the VM.
+ OS Type: Select the desired operating system.
+ Group: Enter the group name for the VM.
+
+ Click Apply.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/choosing-a-deployment-architecture.xml b/docs/tmp/en-US/xml_tmp/choosing-a-deployment-architecture.xml
new file mode 100644
index 00000000000..0503d8c7597
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/choosing-a-deployment-architecture.xml
@@ -0,0 +1,29 @@
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Choosing a Deployment Architecture
+ The architecture used in a deployment will vary depending on the size and purpose of the deployment. This section contains examples of deployment architecture, including a small-scale deployment useful for test and trial deployments and a fully-redundant large-scale setup for production deployments.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cisco3750-hardware.xml b/docs/tmp/en-US/xml_tmp/cisco3750-hardware.xml
new file mode 100644
index 00000000000..b5266105074
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cisco3750-hardware.xml
@@ -0,0 +1,52 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Cisco 3750
+ The following steps show how a Cisco 3750 is configured for zone-level layer-3 switching.
+ These steps assume VLAN 201 is used to route untagged private IPs for pod 1, and pod 1’s layer-2
+ switch is connected to GigabitEthernet1/0/1.
+
+
+ Setting VTP mode to transparent allows us to utilize VLAN IDs above 1000. Since we only
+ use VLANs up to 999, vtp transparent mode is not strictly required.
+ vtp mode transparent
+vlan 200-999
+exit
+
+
+ Configure GigabitEthernet1/0/1.
+ interface GigabitEthernet1/0/1
+switchport trunk encapsulation dot1q
+switchport mode trunk
+switchport trunk native vlan 201
+exit
+
+
+ The statements configure GigabitEthernet1/0/1 as follows:
+
+
+ VLAN 201 is the native untagged VLAN for port GigabitEthernet1/0/1.
+
+
+ Cisco passes all VLANs by default. As a result, all VLANs (300-999) are passed to all the pod-level layer-2 switches.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cisco3750-layer2.xml b/docs/tmp/en-US/xml_tmp/cisco3750-layer2.xml
new file mode 100644
index 00000000000..e4fe1422056
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cisco3750-layer2.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Cisco 3750
+ The following steps show how a Cisco 3750 is configured for pod-level layer-2
+ switching.
+
+
+ Setting VTP mode to transparent allows us to utilize VLAN IDs above 1000. Since we only
+ use VLANs up to 999, vtp transparent mode is not strictly required.
+ vtp mode transparent
+vlan 300-999
+exit
+
+
+ Configure all ports to dot1q and set 201 as the native VLAN.
+ interface range GigabitEthernet 1/0/1-24
+switchport trunk encapsulation dot1q
+switchport mode trunk
+switchport trunk native vlan 201
+exit
+
+
+ By default, Cisco passes all VLANs. Cisco switches complain of the native VLAN IDs are
+ different when 2 ports are connected together. That’s why you must specify VLAN 201 as the
+ native VLAN on the layer-2 switch.
+
diff --git a/docs/tmp/en-US/xml_tmp/citrix-xenserver-installation.xml b/docs/tmp/en-US/xml_tmp/citrix-xenserver-installation.xml
new file mode 100644
index 00000000000..867d36e1b10
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/citrix-xenserver-installation.xml
@@ -0,0 +1,748 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Citrix XenServer Installation for &PRODUCT;
+ If you want to use the Citrix XenServer hypervisor to run guest virtual machines, install
+ XenServer 6.0 or XenServer 6.0.2 on the host(s) in your cloud. For an initial installation,
+ follow the steps below. If you have previously installed XenServer and want to upgrade to
+ another version, see .
+
+ System Requirements for XenServer Hosts
+
+
+ The host must be certified as compatible with one of the following. See the Citrix
+ Hardware Compatibility Guide: http://hcl.xensource.com
+
+
+ XenServer 5.6 SP2
+
+
+ XenServer 6.0
+
+
+ XenServer 6.0.2
+
+
+
+
+ You must re-install Citrix XenServer if you are going to re-use a host from a previous
+ install.
+
+
+ Must support HVM (Intel-VT or AMD-V enabled)
+
+
+ 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. &PRODUCT; 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.
+
+
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type,
+ count, and feature flags.
+
+
+ Must support HVM (Intel-VT or AMD-V enabled in BIOS)
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+
+
+ Hardware virtualization support required
+
+
+ 4 GB of memory
+
+
+ 36 GB of local disk
+
+
+ At least 1 NIC
+
+
+ Statically allocated IP Address
+
+
+ When you deploy &PRODUCT;, the hypervisor host must not have any VMs already
+ running
+
+
+
+ The lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+
+
+
+ XenServer Installation Steps
+
+
+ From https://www.citrix.com/English/ss/downloads/, download the appropriate version
+ of XenServer for your &PRODUCT; version (see ). Install it using the Citrix XenServer
+ Installation Guide.
+
+
+ After installation, perform the following configuration steps, which are described in
+ the next few sections:
+
+
+
+
+
+
+ Required
+ Optional
+
+
+
+
+
+
+
+
+
+ Set up SR if not using NFS, iSCSI, or local disk; see
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Configure XenServer dom0 Memory
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable
+ XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for
+ XenServer dom0. For instructions on how to do this, see http://support.citrix.com/article/CTX126531. The article refers to XenServer 5.6,
+ but the same information applies to XenServer 6.0.
+
+
+ Username and Password
+ All XenServers in a cluster must have the same username and password as configured in
+ &PRODUCT;.
+
+
+ Time Synchronization
+ The host must be set to use NTP. All hosts in a pod must have the same time.
+
+
+ Install NTP.
+ # yum install ntp
+
+
+ Edit the NTP configuration file to point to your NTP server.
+ # vi /etc/ntp.conf
+ Add one or more server lines in this file with the names of the NTP servers you want
+ to use. For example:
+ server 0.xenserver.pool.ntp.org
+server 1.xenserver.pool.ntp.org
+server 2.xenserver.pool.ntp.org
+server 3.xenserver.pool.ntp.org
+
+
+
+ Restart the NTP client.
+ # service ntpd restart
+
+
+ Make sure NTP will start again upon reboot.
+ # chkconfig ntpd on
+
+
+
+
+ Licensing
+ Citrix XenServer Free version provides 30 days usage without a license. Following the 30
+ day trial, XenServer requires a free activation and license. You can choose to install a
+ license now or skip this step. If you skip this step, you will need to install a license when
+ you activate and license the XenServer.
+
+ Getting and Deploying a License
+ If you choose to install a license now you will need to use the XenCenter to activate
+ and get a license.
+
+
+ In XenCenter, click Tools > License manager.
+
+
+ Select your XenServer and select Activate Free XenServer.
+
+
+ Request a license.
+
+
+ You can install the license with XenCenter or using the xe command line tool.
+
+
+
+ Install &PRODUCT; XenServer Support Package (CSP)
+ (Optional)
+ To enable security groups, elastic load balancing, and elastic IP on XenServer, download
+ and install the &PRODUCT; XenServer Support Package (CSP). After installing XenServer, perform
+ the following additional steps on each XenServer host.
+
+
+ Download the CSP software onto the XenServer host from one of the following
+ links:
+ For XenServer 6.0.2:
+ http://download.cloud.com/releases/3.0.1/XS-6.0.2/xenserver-cloud-supp.tgz
+ For XenServer 5.6 SP2:
+ http://download.cloud.com/releases/2.2.0/xenserver-cloud-supp.tgz
+ For XenServer 6.0:
+ http://download.cloud.com/releases/3.0/xenserver-cloud-supp.tgz
+
+
+ Extract the file:
+ # tar xf xenserver-cloud-supp.tgz
+
+
+ Run the following script:
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable Open
+ vSwitch (OVS):
+ # xe-switch-network-backend bridge
+ Restart the host machine when prompted.
+
+
+ The XenServer host is now ready to be added to &PRODUCT;.
+
+
+ Primary Storage Setup for XenServer
+ &PRODUCT; natively supports NFS, iSCSI and local storage. If you are using one of these
+ storage types, there is no need to create the XenServer Storage Repository ("SR").
+ If, however, you would like to use storage connected via some other technology, such as
+ FiberChannel, you must set up the SR yourself. To do so, perform the following steps. If you
+ have your hosts in a XenServer pool, perform the steps on the master node. If you are working
+ with a single XenServer which is not part of a cluster, perform the steps on that
+ XenServer.
+
+
+ Connect FiberChannel cable to all hosts in the cluster and to the FiberChannel storage
+ host.
+
+
+ Rescan the SCSI bus. Either use the following command or use XenCenter to perform an
+ HBA rescan.
+ # scsi-rescan
+
+
+ Repeat step 2 on every host.
+
+
+ Check to be sure you see the new SCSI disk.
+ # ls /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -l
+ The output should look like this, although the specific file name will be different
+ (scsi-<scsiID>):
+ lrwxrwxrwx 1 root root 9 Mar 16 13:47
+/dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -> ../../sdc
+
+
+
+ Repeat step 4 on every host.
+
+
+ On the storage server, run this command to get a unique ID for the new SR.
+ # uuidgen
+ The output should look like this, although the specific ID will be different:
+ e6849e96-86c3-4f2c-8fcc-350cc711be3d
+
+
+ Create the FiberChannel SR. In name-label, use the unique ID you just
+ generated.
+
+# xe sr-create type=lvmohba shared=true
+device-config:SCSIid=360a98000503365344e6f6177615a516b
+name-label="e6849e96-86c3-4f2c-8fcc-350cc711be3d"
+
+ This command returns a unique ID for the SR, like the following example (your ID will
+ be different):
+ 7a143820-e893-6c6a-236e-472da6ee66bf
+
+
+ To create a human-readable description for the SR, use the following command. In uuid,
+ use the SR ID returned by the previous command. In name-description, set whatever friendly
+ text you prefer.
+ # xe sr-param-set uuid=7a143820-e893-6c6a-236e-472da6ee66bf name-description="Fiber Channel storage repository"
+ Make note of the values you will need when you add this storage to &PRODUCT; later
+ (see ). In the Add Primary Storage dialog, in
+ Protocol, you will choose PreSetup. In SR Name-Label, you will enter the name-label you
+ set earlier (in this example, e6849e96-86c3-4f2c-8fcc-350cc711be3d).
+
+
+ (Optional) If you want to enable multipath I/O on a FiberChannel SAN, refer to the
+ documentation provided by the SAN vendor.
+
+
+
+
+ iSCSI Multipath Setup for XenServer (Optional)
+ When setting up the storage repository on a Citrix XenServer, you can enable multipath
+ I/O, which uses redundant physical components to provide greater reliability in the connection
+ between the server and the SAN. To enable multipathing, use a SAN solution that is supported
+ for Citrix servers and follow the procedures in Citrix documentation. The following links
+ provide a starting point:
+
+
+ http://support.citrix.com/article/CTX118791
+
+
+ http://support.citrix.com/article/CTX125403
+
+
+ You can also ask your SAN vendor for advice about setting up your Citrix repository for
+ multipathing.
+ Make note of the values you will need when you add this storage to the &PRODUCT; later
+ (see ). In the Add Primary Storage dialog, in Protocol,
+ you will choose PreSetup. In SR Name-Label, you will enter the same name used to create the
+ SR.
+ If you encounter difficulty, address the support team for the SAN provided by your vendor.
+ If they are not able to solve your issue, see Contacting Support.
+
+
+ Physical Networking Setup for XenServer
+ Once XenServer has been installed, you may need to do some additional network
+ configuration. At this point in the installation, you should have a plan for what NICs the
+ host will have and what traffic each NIC will carry. The NICs should be cabled as necessary to
+ implement your plan.
+ If you plan on using NIC bonding, the NICs on all hosts in the cluster must be cabled
+ exactly the same. For example, if eth0 is in the private bond on one host in a cluster, then
+ eth0 must be in the private bond on all hosts in the cluster.
+ The IP address assigned for the management network interface must be static. It can be set
+ on the host itself or obtained via static DHCP.
+ &PRODUCT; configures network traffic of various types to use different NICs or bonds on
+ the XenServer host. You can control this process and provide input to the Management Server
+ through the use of XenServer network name labels. The name labels are placed on physical
+ interfaces or bonds and configured in &PRODUCT;. In some simple cases the name labels are not
+ required.
+
+ Configuring Public Network with a Dedicated NIC for XenServer (Optional)
+ &PRODUCT; supports the use of a second NIC (or bonded pair of NICs, described in ) for the public network. If bonding is not used, the
+ public network can be on any NIC and can be on different NICs on the hosts in a cluster. For
+ example, the public network can be on eth0 on node A and eth1 on node B. However, the
+ XenServer name-label for the public network must be identical across all hosts. The
+ following examples set the network label to "cloud-public". After the management
+ server is installed and running you must configure it with the name of the chosen network
+ label (e.g. "cloud-public"); this is discussed in .
+ If you are using two NICs bonded together to create a public network, see .
+ If you are using a single dedicated NIC to provide public network access, follow this
+ procedure on each new host that is added to &PRODUCT; before adding the host.
+
+
+ Run xe network-list and find the public network. This is usually attached to the NIC
+ that is public. Once you find the network make note of its UUID. Call this
+ <UUID-Public>.
+
+
+ Run the following command.
+ # xe network-param-set name-label=cloud-public uuid=<UUID-Public>
+
+
+
+
+ Configuring Multiple Guest Networks for XenServer (Optional)
+ &PRODUCT; supports the use of multiple guest networks with the XenServer hypervisor.
+ Each network is assigned a name-label in XenServer. For example, you might have two networks
+ with the labels "cloud-guest" and "cloud-guest2". After the management
+ server is installed and running, you must add the networks and use these labels so that
+ &PRODUCT; is aware of the networks.
+ Follow this procedure on each new host before adding the host to &PRODUCT;:
+
+
+ Run xe network-list and find one of the guest networks. Once you find the network
+ make note of its UUID. Call this <UUID-Guest>.
+
+
+ Run the following command, substituting your own name-label and uuid values.
+ # xe network-param-set name-label=<cloud-guestN> uuid=<UUID-Guest>
+
+
+ Repeat these steps for each additional guest network, using a different name-label
+ and uuid each time.
+
+
+
+
+ Separate Storage Network for XenServer (Optional)
+ You can optionally set up a separate storage network. This should be done first on the
+ host, before implementing the bonding steps below. This can be done using one or two
+ available NICs. With two NICs bonding may be done as above. It is the administrator's
+ responsibility to set up a separate storage network.
+ Give the storage network a different name-label than what will be given for other
+ networks.
+ For the separate storage network to work correctly, it must be the only interface that
+ can ping the primary storage device's IP address. For example, if eth0 is the
+ management network NIC, ping -I eth0 <primary storage device IP> must fail. In all
+ deployments, secondary storage devices must be pingable from the management network NIC or
+ bond. If a secondary storage device has been placed on the storage network, it must also be
+ pingable via the storage network NIC or bond on the hosts as well.
+ You can set up two separate storage networks as well. For example, if you intend to
+ implement iSCSI multipath, dedicate two non-bonded NICs to multipath. Each of the two
+ networks needs a unique name-label.
+ If no bonding is done, the administrator must set up and name-label the separate storage
+ network on all hosts (masters and slaves).
+ Here is an example to set up eth5 to access a storage network on 172.16.0.0/24.
+
+# xe pif-list host-name-label='hostname' device=eth5
+uuid(RO): ab0d3dd4-5744-8fae-9693-a022c7a3471d
+device ( RO): eth5
+#xe pif-reconfigure-ip DNS=172.16.3.3 gateway=172.16.0.1 IP=172.16.0.55 mode=static netmask=255.255.255.0 uuid=ab0d3dd4-5744-8fae-9693-a022c7a3471d
+
+
+ NIC Bonding for XenServer (Optional)
+ XenServer supports Source Level Balancing (SLB) NIC bonding. Two NICs can be bonded
+ together to carry public, private, and guest traffic, or some combination of these. Separate
+ storage networks are also possible. Here are some example supported configurations:
+
+
+ 2 NICs on private, 2 NICs on public, 2 NICs on storage
+
+
+ 2 NICs on private, 1 NIC on public, storage uses management network
+
+
+ 2 NICs on private, 2 NICs on public, storage uses management network
+
+
+ 1 NIC for private, public, and storage
+
+
+ All NIC bonding is optional.
+ XenServer expects all nodes in a cluster will have the same network cabling and same
+ bonds implemented. In an installation the master will be the first host that was added to
+ the cluster and the slave hosts will be all subsequent hosts added to the cluster. The bonds
+ present on the master set the expectation for hosts added to the cluster later. The
+ procedure to set up bonds on the master and slaves are different, and are described below.
+ There are several important implications of this:
+
+
+ You must set bonds on the first host added to a cluster. Then you must use xe
+ commands as below to establish the same bonds in the second and subsequent hosts added
+ to a cluster.
+
+
+ Slave hosts in a cluster must be cabled exactly the same as the master. For example,
+ if eth0 is in the private bond on the master, it must be in the management network for
+ added slave hosts.
+
+
+
+ Management Network Bonding
+ The administrator must bond the management network NICs prior to adding the host to
+ &PRODUCT;.
+
+
+ Creating a Private Bond on the First Host in the Cluster
+ Use the following steps to create a bond in XenServer. These steps should be run on
+ only the first host in a cluster. This example creates the cloud-private network with two
+ physical NICs (eth0 and eth1) bonded into it.
+
+
+ Find the physical NICs that you want to bond together.
+ # xe pif-list host-name-label='hostname' device=eth0
+# xe pif-list host-name-label='hostname' device=eth1
+ These command shows the eth0 and eth1 NICs and their UUIDs. Substitute the ethX
+ devices of your choice. Call the UUID's returned by the above command slave1-UUID
+ and slave2-UUID.
+
+
+ Create a new network for the bond. For example, a new network with name
+ "cloud-private".
+ This label is important. &PRODUCT; looks for a network by a
+ name you configure. You must use the same name-label for all hosts in the cloud for
+ the management network.
+ # xe network-create name-label=cloud-private
+# xe bond-create network-uuid=[uuid of cloud-private created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+
+
+ Now you have a bonded pair that can be recognized by &PRODUCT; as the management
+ network.
+
+
+ Public Network Bonding
+ Bonding can be implemented on a separate, public network. The administrator is
+ responsible for creating a bond for the public network if that network will be bonded and
+ will be separate from the management network.
+
+
+ Creating a Public Bond on the First Host in the Cluster
+ These steps should be run on only the first host in a cluster. This example creates
+ the cloud-public network with two physical NICs (eth2 and eth3) bonded into it.
+
+
+ Find the physical NICs that you want to bond together.
+ #xe pif-list host-name-label='hostname' device=eth2
+# xe pif-list host-name-label='hostname' device=eth3
+ These command shows the eth2 and eth3 NICs and their UUIDs. Substitute the ethX
+ devices of your choice. Call the UUID's returned by the above command slave1-UUID
+ and slave2-UUID.
+
+
+ Create a new network for the bond. For example, a new network with name
+ "cloud-public".
+ This label is important. &PRODUCT; looks for a network by a
+ name you configure. You must use the same name-label for all hosts in the cloud for
+ the public network.
+ # xe network-create name-label=cloud-public
+# xe bond-create network-uuid=[uuid of cloud-public created above]
+pif-uuids=[slave1-uuid],[slave2-uuid]
+
+
+ Now you have a bonded pair that can be recognized by &PRODUCT; as the public
+ network.
+
+
+ Adding More Hosts to the Cluster
+ With the bonds (if any) established on the master, you should add additional, slave
+ hosts. Run the following command for all additional hosts to be added to the cluster. This
+ will cause the host to join the master in a single XenServer pool.
+ # xe pool-join master-address=[master IP] master-username=root
+master-password=[your password]
+
+
+ Complete the Bonding Setup Across the Cluster
+ With all hosts added to the pool, run the cloud-setup-bond script. This script will
+ complete the configuration and set up of the bonds across all hosts in the cluster.
+
+
+ Copy the script from the Management Server in
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the
+ master host and ensure it is executable.
+
+
+ Run the script:
+ # ./cloud-setup-bonding.sh
+
+
+ Now the bonds are set up and configured properly across the cluster.
+
+
+
+
+ Upgrading XenServer Versions
+ This section tells how to upgrade XenServer software on &PRODUCT; hosts. The actual
+ upgrade is described in XenServer documentation, but there are some additional steps you must
+ perform before and after the upgrade.
+
+ Be sure the hardware is certified compatible with the new version of XenServer.
+
+ To upgrade XenServer:
+
+
+ Upgrade the database. On the Management Server node:
+
+
+ Back up the database:
+ # mysqldump --user=root --databases cloud > cloud.backup.sql
+# mysqldump --user=root --databases cloud_usage > cloud_usage.backup.sql
+
+
+ You might need to change the OS type settings for VMs running on the upgraded
+ hosts.
+
+
+ If you upgraded from XenServer 5.6 GA to XenServer 5.6 SP2, change any VMs
+ that have the OS type CentOS 5.5 (32-bit), Oracle Enterprise Linux 5.5 (32-bit),
+ or Red Hat Enterprise Linux 5.5 (32-bit) to Other Linux (32-bit). Change any VMs
+ that have the 64-bit versions of these same OS types to Other Linux
+ (64-bit).
+
+
+ If you upgraded from XenServer 5.6 SP2 to XenServer 6.0.2, change any VMs that
+ have the OS type CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux
+ 5.6 (32-bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.6
+ (32-bit) , or Red Hat Enterprise Linux 5.7 (32-bit) to Other Linux (32-bit).
+ Change any VMs that have the 64-bit versions of these same OS types to Other Linux
+ (64-bit).
+
+
+ If you upgraded from XenServer 5.6 to XenServer 6.0.2, do all of the
+ above.
+
+
+
+
+ Restart the Management Server and Usage Server. You only need to do this once for
+ all clusters.
+ # service cloud-management start
+# service cloud-usage start
+
+
+
+
+ Disconnect the XenServer cluster from &PRODUCT;.
+
+
+ Log in to the &PRODUCT; UI as root.
+
+
+ Navigate to the XenServer cluster, and click Actions – Unmanage.
+
+
+ Watch the cluster status until it shows Unmanaged.
+
+
+
+
+ Log in to one of the hosts in the cluster, and run this command to clean up the
+ VLAN:
+ # . /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+ Still logged in to the host, run the upgrade preparation script:
+ # /opt/xensource/bin/cloud-prepare-upgrade.sh
+ Troubleshooting: If you see the error "can't eject CD," log in to the
+ VM and umount the CD, then run the script again.
+
+
+ Upgrade the XenServer software on all hosts in the cluster. Upgrade the master
+ first.
+
+
+ Live migrate all VMs on this host to other hosts. See the instructions for live
+ migration in the Administrator's Guide.
+ Troubleshooting: You might see the following error when you migrate a VM:
+ [root@xenserver-qa-2-49-4 ~]# xe vm-migrate live=true host=xenserver-qa-2-49-5 vm=i-2-8-VM
+You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected.
+vm: b6cf79c8-02ee-050b-922f-49583d9f1a14 (i-2-8-VM)
+ To solve this issue, run the following:
+ # /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14
+
+
+ Reboot the host.
+
+
+ Upgrade to the newer version of XenServer. Use the steps in XenServer
+ documentation.
+
+
+ After the upgrade is complete, copy the following files from the management server
+ to this host, in the directory locations shown below:
+
+
+
+
+
+
+ Copy this Management Server file...
+ ...to this location on the XenServer host
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+ /opt/xensource/sm/NFSSR.py
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+ /opt/xensource/bin/setupxenserver.sh
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+ /opt/xensource/bin/make_migratable.sh
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-clean-vlan.sh
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+
+
+
+
+ Run the following script:
+ # /opt/xensource/bin/setupxenserver.sh
+ Troubleshooting: If you see the following error message, you can safely ignore
+ it.
+ mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory
+
+
+ Plug in the storage repositories (physical block devices) to the XenServer
+ host:
+ # for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; done
+ Note: If you add a host to this XenServer pool, you need to migrate all VMs on
+ this host to other hosts, and eject this host from XenServer pool.
+
+
+
+
+ Repeat these steps to upgrade every host in the cluster to the same version of
+ XenServer.
+
+
+ Run the following command on one host in the XenServer cluster to clean up the host
+ tags:
+ # for host in $(xe host-list | grep ^uuid | awk '{print $NF}') ; do xe host-param-clear uuid=$host param-name=tags; done;
+
+ 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.
+
+
+
+ Reconnect the XenServer cluster to &PRODUCT;.
+
+
+ Log in to the &PRODUCT; UI as root.
+
+
+ Navigate to the XenServer cluster, and click Actions – Manage.
+
+
+ Watch the status to see that all the hosts come up.
+
+
+
+
+ After all hosts are up, run the following on one host in the cluster:
+ # /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloud-infrastructure-concepts.xml b/docs/tmp/en-US/xml_tmp/cloud-infrastructure-concepts.xml
new file mode 100644
index 00000000000..1e1865e04f4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloud-infrastructure-concepts.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Cloud Infrastructure Concepts
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloud-infrastructure-overview.xml b/docs/tmp/en-US/xml_tmp/cloud-infrastructure-overview.xml
new file mode 100644
index 00000000000..49a413871a5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloud-infrastructure-overview.xml
@@ -0,0 +1,79 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Cloud Infrastructure Overview
+
+ The Management Server manages one or more zones (typically,
+ datacenters) containing host computers where guest virtual
+ machines will run. The cloud infrastructure is organized as follows:
+
+
+
+
+ Zone: Typically, a zone is equivalent to a single
+ datacenter. A zone consists of one or more pods and secondary
+ storage.
+
+
+
+
+ Pod: A pod is usually one rack of hardware that includes a
+ layer-2 switch and one or more clusters.
+
+
+
+
+ Cluster: A cluster consists of one or more hosts and primary
+ storage.
+
+
+
+
+ Host: A single compute node within a cluster. The hosts are
+ where the actual cloud services run in the form of guest
+ virtual machines.
+
+
+
+
+ Primary storage is associated with a cluster, and it stores
+ the disk volumes for all the VMs running on hosts in that cluster.
+
+
+
+ Secondary storage is associated with a zone, and it stores
+ templates, ISO images, and disk volume snapshots.
+
+
+
+
+
+
+
+ infrastructure_overview.png: Nested organization of a zone
+
+ More Information
+ For more information, see documentation on cloud infrastructure concepts.
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudplatform-api.xml b/docs/tmp/en-US/xml_tmp/cloudplatform-api.xml
new file mode 100644
index 00000000000..3c4a91481d0
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudplatform-api.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ &PRODUCT; API
+ The &PRODUCT; API is a low level API that has been used to implement the &PRODUCT; web UIs. It is also a good basis for implementing other popular APIs such as EC2/S3 and emerging DMTF standards.
+ Many &PRODUCT; 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 and the API Reference.
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack-admin.xml b/docs/tmp/en-US/xml_tmp/cloudstack-admin.xml
new file mode 100644
index 00000000000..c1537638bd8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack-admin.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack.ent b/docs/tmp/en-US/xml_tmp/cloudstack.ent
new file mode 100644
index 00000000000..abb18851bcf
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack.xml b/docs/tmp/en-US/xml_tmp/cloudstack.xml
new file mode 100644
index 00000000000..c745bc95fe7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack.xml
@@ -0,0 +1,79 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ &PRODUCT; Complete Documentation
+ Apache CloudStack
+ 4.0.0-incubating
+ 1
+
+
+
+ Complete documentation for &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack_admin.xml b/docs/tmp/en-US/xml_tmp/cloudstack_admin.xml
new file mode 100644
index 00000000000..c80c94f5ff5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack_admin.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack_developers.xml b/docs/tmp/en-US/xml_tmp/cloudstack_developers.xml
new file mode 100644
index 00000000000..e847f6a0474
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack_developers.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack_features.xml b/docs/tmp/en-US/xml_tmp/cloudstack_features.xml
new file mode 100644
index 00000000000..95825aa2758
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack_features.xml
@@ -0,0 +1,66 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ What Can &PRODUCT; Do?
+
+
+ Multiple Hypervisor Support
+
+
+ &PRODUCT; works with a variety of hypervisors. A single cloud deployment can contain multiple hypervisor implementations. You have the complete freedom to choose the right hypervisor for your workload. &PRODUCT; is designed to work with open source Xen and KVM hypervisors as well as enterprise-grade hypervisors such as Citrix XenServer, VMware vSphere, and Oracle VM (OVM). You can also provision “bare metal” hosts with no hypervisor (Beta feature. Untested in &PRODUCT; 3.0.x0.)
+
+
+ Massively Scalable Infrastructure Management
+
+
+ &PRODUCT; can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+
+ Automatic Configuration Management
+
+ &PRODUCT; automatically configures each guest virtual machine’s networking and storage settings.
+
+ &PRODUCT; internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+
+ Graphical User Interface
+
+ &PRODUCT; offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+
+ API and Extensibility
+
+
+ &PRODUCT; provides an API that gives programmatic access to all the management features available in the UI. The API is maintained and documented. This API enables the creation of command line tools and new user interfaces to suit particular needs. See the Developer’s Guide and API Reference, both available at http://docs.cloud.com/CloudStack_Documentation.
+
+
+ The &PRODUCT; platform pluggable allocation architecture allows the creation of new types of allocators for the selection of storage and Hosts. See the Allocator Implementation Guide (http://docs.cloud.com/CloudStack_Documentation/Allocator_Implementation_Guide).
+
+
+ High Availability
+
+ The &PRODUCT; platform has a number of features to increase the availability of the system. The Management Server itself may be deployed in a multi-node installation where the servers are load balanced. MySQL may be configured to use replication to provide for a manual failover in the event of database loss. For the Hosts, the &PRODUCT; platform supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack_installation.xml b/docs/tmp/en-US/xml_tmp/cloudstack_installation.xml
new file mode 100644
index 00000000000..f6ef3cf7c4d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack_installation.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack_system_requirements.xml b/docs/tmp/en-US/xml_tmp/cloudstack_system_requirements.xml
new file mode 100644
index 00000000000..8b5d709c441
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack_system_requirements.xml
@@ -0,0 +1,68 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Minimum System Requirements
+
+ The machines that will run the Management Server and MySQL database must meet the following requirements. The same machines can also be used to provide primary and secondary storage, such as via localdisk or NFS. The Management Server may be placed on a virtual machine.
+
+
+ Operating system:
+
+ Commercial users: Preferred: RHEL 6.2+ 64-bit (https://access.redhat.com/downloads) or CentOS 6.2+ 64-bit (http://isoredirect.centos.org/centos/6/isos/x86_64/). Also supported (v3.0.3 and greater): RHEL and CentOS 5.4-5.x 64-bit
+ Open-source community users: RHEL 5.4-5.x 64-bit or 6.2+ 64-bit; CentOS 5.4-5.x 64-bit or 6.2+ 64-bit; Ubuntu 10.04 LTS
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+ 4 GB of memory
+ 250 GB of local disk (more results in better capability; 500 GB recommended)
+ At least 1 NIC
+ Statically allocated IP address
+ Fully qualified domain name as returned by the hostname command
+
+ The host is where the cloud services run in the form of guest virtual machines. Each host is one machine that meets the following requirements:
+
+ Must be 64-bit and must support HVM (Intel-VT or AMD-V enabled).
+ 64-bit x86 CPU (more cores results in better performance)
+ Hardware virtualization support required
+ 4 GB of memory
+ 36 GB of local disk
+ At least 1 NIC
+ Statically allocated IP Address
+ Latest hotfixes applied to hypervisor software
+ When you deploy &PRODUCT;, the hypervisor host must not have any VMs already running
+
+ Hosts have additional requirements depending on the hypervisor. See the requirements listed at the top of the Installation section for your chosen hypervisor:
+
+ Citrix XenServer Installation for &PRODUCT;
+ VMware vSphere Installation and Configuration
+ KVM Installation and Configuration
+ Oracle VM (OVM) Installation and Configuration
+
+
+
+ Be sure you fulfill the additional hypervisor requirements and installation steps provided in this Guide. Hypervisor hosts must be properly prepared to work with &PRODUCT;. For example, the requirements for XenServer are listed under Citrix XenServer Installation for &PRODUCT;.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack_trial_installation.xml b/docs/tmp/en-US/xml_tmp/cloudstack_trial_installation.xml
new file mode 100644
index 00000000000..24a1699d1d7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack_trial_installation.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cloudstack_whatis.xml b/docs/tmp/en-US/xml_tmp/cloudstack_whatis.xml
new file mode 100644
index 00000000000..5fea7d40199
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cloudstack_whatis.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ What Is &PRODUCT;?
+ Who Should Read This
+ If you are new to &PRODUCT; or you want to learn more about concepts before installing and running &PRODUCT;, read this overview. If you just want to get started, you can skip to Overview of Installation Steps.
+ &PRODUCT; is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. &PRODUCT; manages the network, storage, and compute nodes that make up a cloud infrastructure. Use &PRODUCT; to deploy, manage, and configure cloud computing environments. Typical users are service providers and enterprises. With &PRODUCT;, you can:
+
+
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with &PRODUCT; an enterprise can offer self-service virtual machines to users without involving IT departments.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/cluster-add.xml b/docs/tmp/en-US/xml_tmp/cluster-add.xml
new file mode 100644
index 00000000000..3046c5e0dfd
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/cluster-add.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Adding a Cluster
+ You need to tell &PRODUCT; 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/compatibility-matrix.xml b/docs/tmp/en-US/xml_tmp/compatibility-matrix.xml
new file mode 100644
index 00000000000..8576f71e781
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/compatibility-matrix.xml
@@ -0,0 +1,116 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Compatibility Matrix
+
+
+
+
+ Hypervisor
+ CloudStack 2.1.x
+ CloudStack 2.2.x
+ CloudStack 3.0.0
+ CloudStack 3.0.1
+ CloudStack 3.0.2
+ CloudStack 3.0.3
+
+
+
+
+ XenServer 5.6
+ Yes
+ Yes
+ No
+ No
+ No
+ No
+
+
+ XenServer 5.6 FP1
+ Yes
+ Yes
+ No
+ No
+ No
+ No
+
+
+ XenServer 5.6 SP2
+ Yes
+ Yes
+ No
+ No
+ Yes
+ Yes
+
+
+ XenServer 6.0.0
+ No
+ No
+ No
+ No
+ No
+ Yes
+
+
+ XenServer 6.0.2
+ No
+ No
+ Yes
+ Yes
+ Yes
+ Yes
+
+
+ XenServer 6.1
+ No
+ No
+ No
+ No
+ No
+ No
+
+
+ KVM (RHEL 6.0 or 6.1)
+ Yes
+ Yes
+ Yes
+ Yes
+ Yes
+ Yes
+
+
+ VMware (vSphere and vCenter, both version 4.1)
+ Yes
+ Yes
+ Yes
+ Yes
+ Yes
+ Yes
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/compute-disk-service-offerings.xml b/docs/tmp/en-US/xml_tmp/compute-disk-service-offerings.xml
new file mode 100644
index 00000000000..1fd2a91a38b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/compute-disk-service-offerings.xml
@@ -0,0 +1,50 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Compute and Disk Service Offerings
+ A service offering is a set of virtual hardware features such as CPU core count and speed, memory, and disk size. The &PRODUCT; administrator can set up various offerings, and then end users choose from the available offerings when they create a new VM. A service offering includes the following elements:
+
+ CPU, memory, and network resource guarantees
+ How resources are metered
+ How the resource usage is charged
+ How often the charges are generated
+
+ For example, one service offering might allow users to create a virtual machine instance that is equivalent to a 1 GHz Intel® Core™ 2 CPU, with 1 GB memory at $0.20/hour, with network traffic metered at $0.10/GB. Based on the user’s selected offering, &PRODUCT; emits usage records that can be integrated with billing systems. &PRODUCT; separates service offerings into compute offerings and disk offerings. The computing service offering specifies:
+
+ Guest CPU
+ Guest RAM
+ Guest Networking type (virtual or direct)
+ Tags on the root disk
+
+ The disk offering specifies:
+
+ Disk size (optional). An offering without a disk size will allow users to pick their own
+ Tags on the data disk
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/concepts.xml b/docs/tmp/en-US/xml_tmp/concepts.xml
new file mode 100644
index 00000000000..1912c23a8c9
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/concepts.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Concepts
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/configure-acl.xml b/docs/tmp/en-US/xml_tmp/configure-acl.xml
new file mode 100644
index 00000000000..299196c5502
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-acl.xml
@@ -0,0 +1,139 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Configuring Access Control List
+ Define Network Access Control List (ACL) on the VPC virtual router to control incoming
+ (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By
+ default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports,
+ you must create a new network ACL. The network ACLs can be created for the tiers only if the
+ NetworkACL service is supported.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ACLs
+
+
+
+
+ Select Network ACLs.
+ The Network ACLs page is displayed.
+
+
+ Click Add Network ACLs.
+ To add an ACL rule, fill in the following fields to specify what kind of network traffic
+ is allowed in this tier.
+
+
+ CIDR: The CIDR acts as the Source CIDR for the
+ Ingress rules, and Destination CIDR for the Egress rules. To accept traffic only from or
+ to the IP addresses within a particular address block, enter a CIDR or a comma-separated
+ list of CIDRs. The CIDR is the base IP address of the incoming traffic. For example,
+ 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
+
+
+ Protocol: The networking protocol that sources use
+ to send traffic to the tier. The TCP and UDP protocols are typically used for data
+ exchange and end-user communications. The ICMP protocol is typically used to send error
+ messages or network monitoring data.
+
+
+ Start Port, End
+ Port (TCP, UDP only): A range of listening ports that are the destination
+ for the incoming traffic. If you are opening a single port, use the same number in both
+ fields.
+
+
+ Select Tier: Select the tier for which you want to
+ add this ACL rule.
+
+
+ ICMP Type, ICMP
+ Code (ICMP only): The type of message and error code that will be
+ sent.
+
+
+ Traffic Type: Select the traffic type you want to
+ apply.
+
+
+ Egress: To add an egress rule, select Egress
+ from the Traffic type drop-down box and click Add. This specifies what type of
+ traffic is allowed to be sent out of VM instances in this tier. If no egress rules
+ are specified, all traffic from the tier is allowed out at the VPC virtual router.
+ Once egress rules are specified, only the traffic specified in egress rules and the
+ responses to any traffic that has been allowed in through an ingress rule are
+ allowed out. No egress rule is required for the VMs in a tier to communicate with
+ each other.
+
+
+ Ingress: To add an ingress rule, select Ingress
+ from the Traffic type drop-down box and click Add. This specifies what network
+ traffic is allowed into the VM instances in this tier. If no ingress rules are
+ specified, then no traffic will be allowed in, except for responses to any traffic
+ that has been allowed out through an egress rule.
+
+
+
+ By default, all incoming and outgoing traffic to the guest networks is blocked. To
+ open the ports, create a new network ACL.
+
+
+
+
+
+ Click Add. The ACL rule is added.
+ To view the list of ACL rules you have added, click the desired tier from the Network
+ ACLs page, then select the Network ACL tab.
+
+
+
+
+
+ network-acl.png: adding, editing, deleting an ACL rule.
+
+
+ You can edit the tags assigned to the ACL rules and delete the ACL rules you have
+ created. Click the appropriate button in the Actions column.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/configure-guest-traffic-in-advanced-zone.xml b/docs/tmp/en-US/xml_tmp/configure-guest-traffic-in-advanced-zone.xml
new file mode 100644
index 00000000000..fb6685091a5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-guest-traffic-in-advanced-zone.xml
@@ -0,0 +1,79 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Configure Guest Traffic in an Advanced Zone
+ These steps assume you have already logged in to the &PRODUCT; UI. To configure the base
+ guest network:
+
+
+ In the left navigation, choose Infrastructure. On Zones, click View More, then click the
+ zone to which you want to add a network.
+
+
+ Click the Network tab.
+
+
+ Click Add guest network.
+ The Add guest network window is displayed:
+
+
+
+
+
+ networksetupzone.png: Depicts network setup in a single zone
+
+
+
+
+ Provide the following information:
+
+
+ Name. The name of the network. This will be
+ user-visible
+
+
+ Display Text: The description of the network. This
+ will be user-visible
+
+
+ Zone: The zone in which you are configuring the
+ guest network.
+
+
+ Network offering: If the administrator has
+ configured multiple network offerings, select the one you want to use for this
+ network
+
+
+ Guest Gateway: The gateway that the guests should
+ use
+
+
+ Guest Netmask: The netmask in use on the subnet the
+ guests will use
+
+
+
+
+ Click OK.
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/configure-package-repository.xml b/docs/tmp/en-US/xml_tmp/configure-package-repository.xml
new file mode 100644
index 00000000000..9ef2307b105
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-package-repository.xml
@@ -0,0 +1,69 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configure package repository
+ &PRODUCT; is only distributed from source from the official mirrors.
+ However, members of the CloudStack community may build convenience binaries
+ so that users can install Apache CloudStack without needing to build from
+ source.
+
+
+ If you didn't follow the steps to build your own packages from source
+ in the sections for or
+ you may find pre-built
+ DEB and RPM packages for your convience linked from the
+ downloads
+ page.
+
+
+ These repositories contain both the Management Server and KVM Hypervisor packages.
+
+
+ DEB package repository
+ You can add a DEB package repository to your apt sources with the following commands. Please note that only packages for Ubuntu 12.04 LTS (precise) are being built at this time.
+ Use your preferred editor and open (or create) /etc/apt/sources.list.d/cloudstack.list. Add the community provided repository to the file:
+deb http://cloudstack.apt-get.eu/ubuntu precise 4.0
+ We now have to add the public key to the trusted keys.
+ $wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
+ Now update your local apt cache.
+ $apt-get update
+ Your DEB package repository should now be configured and ready for use.
+
+
+ RPM package repository
+ There is a RPM package repository for &PRODUCT; so you can easily install on RHEL based platforms.
+ If you're using an RPM-based system, you'll want to add the Yum repository so that you can install &PRODUCT; with Yum.
+ Yum repository information is found under /etc/yum.repos.d. You'll see several .repo files in this directory, each one denoting a specific repository.
+ To add the &PRODUCT; repository, create /etc/yum.repos.d/cloudstack.repo and insert the following information.
+
+[cloudstack]
+name=cloudstack
+baseurl=http://cloudstack.apt-get.eu/rhel/4.0/
+enabled=1
+gpgcheck=0
+
+ Now you should be able to install CloudStack using Yum.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/configure-public-traffic-in-an-advanced-zone.xml b/docs/tmp/en-US/xml_tmp/configure-public-traffic-in-an-advanced-zone.xml
new file mode 100644
index 00000000000..7a61cd380af
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-public-traffic-in-an-advanced-zone.xml
@@ -0,0 +1,25 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Configure Public Traffic in an Advanced Zone
+ In a zone that uses advanced networking, you need to configure at least one range of IP
+ addresses for Internet traffic.
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/configure-usage-server.xml b/docs/tmp/en-US/xml_tmp/configure-usage-server.xml
new file mode 100644
index 00000000000..af7bd4522f6
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-usage-server.xml
@@ -0,0 +1,101 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configuring the Usage Server
+ To configure the usage server:
+
+ Be sure the Usage Server has been installed. This requires extra steps beyond just installing the &PRODUCT; software. See Installing the Usage Server (Optional) in the Advanced Installation Guide.
+ Log in to the &PRODUCT; UI as administrator.
+ Click Global Settings.
+ In Search, type usage. Find the configuration parameter that controls the behavior you want to set. See the table below for a description of the available parameters.
+ In Actions, click the Edit icon.
+ Type the desired value and click the Save icon.
+ Restart the Management Server (as usual with any global configuration change) and also the Usage Server:
+ # service cloud-management restart
+# service cloud-usage restart
+
+
+ The following table shows the global configuration settings that control the behavior of the Usage Server.
+
+
+
+
+ Parameter Name
+ Description
+
+
+
+
+ enable.usage.server
+ Whether the Usage Server is active.
+
+
+ usage.aggregation.timezone
+ Time zone of usage records. Set this if the usage records and daily job execution are in different time zones. For example, with the following settings, the usage job will run at PST 00:15 and generate usage records for the 24 hours from 00:00:00 GMT to 23:59:59 GMT:
+ usage.stats.job.exec.time = 00:15
+usage.execution.timezone = PST
+usage.aggregation.timezone = GMT
+
+ Valid values for the time zone are specified in
+ Default: GMT
+
+
+
+ usage.execution.timezone
+ The time zone of usage.stats.job.exec.time. Valid values for the time zone are specified in
+ Default: The time zone of the management server.
+
+
+
+ usage.sanity.check.interval
+ The number of days between sanity checks. Set this in order to periodically search for records with erroneous data before issuing customer invoices. For example, this checks for VM usage records created after the VM was destroyed, and similar checks for templates, volumes, and so on. It also checks for usage times longer than the aggregation range. If any issue is found, the alert ALERT_TYPE_USAGE_SANITY_RESULT = 21 is sent.
+
+
+ usage.stats.job.aggregation.range
+ The time period in minutes between Usage Server processing jobs. For example, if you set it to 1440, the Usage Server will run once per day. If you set it to 600, it will run every ten hours. In general, when a Usage Server job runs, it processes all events generated since usage was last run.
+ There is special handling for the case of 1440 (once per day). In this case the Usage Server does not necessarily process all records since Usage was last run. &PRODUCT; assumes that you require processing once per day for the previous, complete day’s records. For example, if the current day is October 7, then it is assumed you would like to process records for October 6, from midnight to midnight. &PRODUCT; assumes this "midnight to midnight" is relative to the usage.execution.timezone.
+ Default: 1440
+
+
+
+ usage.stats.job.exec.time
+ The time when the Usage Server processing will start. It is specified in 24-hour format (HH:MM) in the time zone of the server, which should be GMT. For example, to start the Usage job at 10:30 GMT, enter "10:30".
+ If usage.stats.job.aggregation.range is also set, and its value is not 1440, then its value will be added to usage.stats.job.exec.time to get the time to run the Usage Server job again. This is repeated until 24 hours have elapsed, and the next day's processing begins again at usage.stats.job.exec.time.
+ Default: 00:15.
+
+
+
+
+
+ For example, suppose that your server is in GMT, your user population is predominantly in the East Coast of the United States, and you would like to process usage records every night at 2 AM local (EST) time. Choose these settings:
+
+ enable.usage.server = true
+ usage.execution.timezone = America/New_York
+ usage.stats.job.exec.time = 07:00. This will run the Usage job at 2:00 AM EST. Note that this will shift by an hour as the East Coast of the U.S. enters and exits Daylight Savings Time.
+ usage.stats.job.aggregation.range = 1440
+
+ With this configuration, the Usage job will run every night at 2 AM EST and will process records for the previous day’s midnight-midnight as defined by the EST (America/New_York) time zone.
+ Because the special value 1440 has been used for usage.stats.job.aggregation.range, the Usage Server will ignore the data between midnight and 2 AM. That data will be included in the next day's run
+
diff --git a/docs/tmp/en-US/xml_tmp/configure-virtual-router.xml b/docs/tmp/en-US/xml_tmp/configure-virtual-router.xml
new file mode 100644
index 00000000000..8740c0cef8b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-virtual-router.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configuring the Virtual Router
+ You can set the following:
+
+ IP range
+ Supported network services
+ Default domain name for the network serviced by the virtual router
+ Gateway IP address
+ How often &PRODUCT; fetches network usage statistics from &PRODUCT; virtual routers. If you want to collect traffic metering data from the virtual router, set the global configuration parameter router.stats.interval. If you are not using the virtual router to gather network usage statistics, set it to 0.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/configure-vpc.xml b/docs/tmp/en-US/xml_tmp/configure-vpc.xml
new file mode 100644
index 00000000000..45237d21cbb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-vpc.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Configuring a Virtual Private Cloud
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/configure-vpn.xml b/docs/tmp/en-US/xml_tmp/configure-vpn.xml
new file mode 100644
index 00000000000..9e059f7aaba
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-vpn.xml
@@ -0,0 +1,52 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configuring VPN
+ To set up VPN for the cloud:
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+ In the left navigation, click Global Settings.
+ Set the following global configuration parameters.
+
+ remote.access.vpn.client.ip.range – The range of IP addressess to be allocated to remote access VPN clients. The first IP in the range is used by the VPN server.
+ remote.access.vpn.psk.length – Length of the IPSec key.
+ remote.access.vpn.user.limit – Maximum number of VPN users per account.
+
+ To enable VPN for a particular network:
+
+ Log in as a user or administrator to the &PRODUCT; UI.
+ In the left navigation, click Network.
+ Click the name of the network you want to work with.
+ Click View IP Addresses.
+ Click one of the displayed IP address names.
+ Click the Enable VPN button
+
+
+
+ AttachDiskButton.png: button to attach a volume
+ .
+ The IPsec key is displayed in a popup window.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/configure-xenserver-dom-memory.xml b/docs/tmp/en-US/xml_tmp/configure-xenserver-dom-memory.xml
new file mode 100644
index 00000000000..0a02d3e3818
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-xenserver-dom-memory.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configure XenServer dom0 Memory
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+
+
diff --git a/docs/tmp/en-US/xml_tmp/configure-xenserver-dom0-memory.xml b/docs/tmp/en-US/xml_tmp/configure-xenserver-dom0-memory.xml
new file mode 100644
index 00000000000..0a02d3e3818
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configure-xenserver-dom0-memory.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configure XenServer dom0 Memory
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see Citrix Knowledgebase Article.The article refers to XenServer 5.6, but the same information applies to XenServer 6
+
+
diff --git a/docs/tmp/en-US/xml_tmp/configuring-projects.xml b/docs/tmp/en-US/xml_tmp/configuring-projects.xml
new file mode 100644
index 00000000000..0f84dd81454
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/configuring-projects.xml
@@ -0,0 +1,32 @@
+
+
+
+%BOOK_ENTITIES;
+]>
+
+ Configuring Projects
+ Before CloudPlatform users start using projects, the CloudPlatform administrator must set
+ up various systems to support them, including membership invitations, limits on project
+ resources, and controls on who can create projects.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/console-proxy.xml b/docs/tmp/en-US/xml_tmp/console-proxy.xml
new file mode 100644
index 00000000000..df29c428ad2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/console-proxy.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Console Proxy
+ The Console Proxy is a type of System Virtual Machine that has a role in presenting a console view via the web UI. It connects the user’s browser to the VNC port made available via the hypervisor for the console of the guest. Both the administrator and end user web UIs offer a console connection.
+ Clicking on a console icon brings up a new window. The AJAX code downloaded into that window refers to the public IP address of a console proxy VM. There is exactly one public IP address allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then proxies the connection to the VNC port for the requested VM on the Host hosting the guest. .
+ The hypervisors will have many ports assigned to VNC usage so that multiple VNC sessions can occur simultaneously.
+ There is never any traffic to the guest virtual IP, and there is no need to enable VNC within the guest.
+ The console proxy VM will periodically report its active session count to the Management Server. The default reporting interval is five seconds. This can be changed through standard Management Server configuration with the parameter consoleproxy.loadscan.interval.
+ Assignment of guest VM to console proxy is determined by first determining if the guest VM has a previous session associated with a console proxy. If it does, the Management Server will assign the guest VM to the target Console Proxy VM regardless of the load on the proxy VM. Failing that, the first available running Console Proxy VM that has the capacity to handle new sessions is used.
+ Console proxies can be restarted by administrators but this will interrupt existing console sessions for users.
+ The console viewing functionality uses a dynamic DNS service under the domain name realhostip.com to assist in providing SSL security to console sessions. The console proxy is assigned a public IP address. In order to avoid browser warnings for mismatched SSL certificates, the URL for the new console window is set to the form of https://aaa-bbb-ccc-ddd.realhostip.com. Customers will see this URL during console session creation. &PRODUCT; includes the realhostip.com SSL certificate in the console proxy VM. Of course, &PRODUCT; cannot know about DNS A records for our customers' public IPs prior to shipping the software. &PRODUCT; therefore runs a dynamic DNS server that is authoritative for the realhostip.com domain. It maps the aaa-bbb-ccc-ddd part of the DNS name to the IP address aaa.bbb.ccc.ddd on lookups. This allows the browser to correctly connect to the console proxy's public IP, where it then expects and receives a SSL certificate for realhostip.com, and SSL is set up without browser warnings.
+
diff --git a/docs/tmp/en-US/xml_tmp/convert-hyperv-vm-to-template.xml b/docs/tmp/en-US/xml_tmp/convert-hyperv-vm-to-template.xml
new file mode 100644
index 00000000000..c6294d4443c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/convert-hyperv-vm-to-template.xml
@@ -0,0 +1,68 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Converting a Hyper-V VM to a Template
+ To convert a Hyper-V VM to a XenServer-compatible &PRODUCT; template, you will need a standalone XenServer host with an attached NFS VHD SR. Use whatever XenServer version you are using with &PRODUCT;, but use XenCenter 5.6 FP1 or SP2 (it is backwards compatible to 5.6). Additionally, it may help to have an attached NFS ISO SR.
+ For Linux VMs, you may need to do some preparation in Hyper-V before trying to get the VM to work in XenServer. Clone the VM and work on the clone if you still want to use the VM in Hyper-V. Uninstall Hyper-V Integration Components and check for any references to device names in /etc/fstab:
+
+ From the linux_ic/drivers/dist directory, run make uninstall (where "linux_ic" is the path to the copied Hyper-V Integration Components files).
+ Restore the original initrd from backup in /boot/ (the backup is named *.backup0).
+ Remove the "hdX=noprobe" entries from /boot/grub/menu.lst.
+ Check /etc/fstab for any partitions mounted by device name. Change those entries (if any) to mount by LABEL or UUID (get that information with the "blkid" command)..
+
+ The next step is make sure the VM is not running in Hyper-V, then get the VHD into XenServer. There are two options for doing this.
+ Option one:
+
+ Import the VHD using XenCenter. In XenCenter, go to Tools>Virtual Appliance Tools>Disk Image Import.
+ Choose the VHD, then click Next.
+ Name the VM, choose the NFS VHD SR under Storage, enable "Run Operating System Fixups" and choose the NFS ISO SR.
+ Click Next, then Finish. A VM should be created.
+
+ Option two
+
+ Run XenConvert, under From choose VHD, under To choose XenServer. Click Next.
+ Choose the VHD, then click Next.
+ Input the XenServer host info, then click Next.
+ Name the VM, then click Next, then Convert. A VM should be created
+
+ Once you have a VM created from the Hyper-V VHD, prepare it using the following steps:
+
+ Boot the VM, uninstall Hyper-V Integration Services, and reboot.
+ Install XenServer Tools, then reboot.
+ Prepare the VM as desired. For example, run sysprep on Windows VMs. See
+
+ Either option above will create a VM in HVM mode. This is fine for Windows VMs, but Linux VMs may not perform optimally. Converting a Linux VM to PV mode will require additional steps and will vary by distribution.
+
+ Shut down the VM and copy the VHD from the NFS storage to a web server; for example, mount the NFS share on the web server and copy it, or from the XenServer host use sftp or scp to upload it to the web server.
+ In &PRODUCT;, create a new template using the following values:
+
+ URL. Give the URL for the VHD
+ OS Type. Use the appropriate OS. For PV mode on CentOS, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServer.
+ Hypervisor. XenServer
+ Format. VHD
+
+
+ The template will be created, and you can create instances from it.
+
diff --git a/docs/tmp/en-US/xml_tmp/create-bare-metal-template.xml b/docs/tmp/en-US/xml_tmp/create-bare-metal-template.xml
new file mode 100644
index 00000000000..19db2ed5f30
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-bare-metal-template.xml
@@ -0,0 +1,46 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating a Bare Metal Template
+ Beta feature. Untested in &PRODUCT; 3.0.3. Provided without guarantee of performance.
+ Before you can create a bare metal template, you must have performed several other installation and setup steps to create a bare metal cluster and environment. See Bare Metal Installation in the Installation Guide. It is assumed you already have a directory named "win7_64bit" on your CIFS server, containing the image for the bare metal instance. This directory and image are set up as part of the Bare Metal Installation procedure.
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+ In the left navigation bar, click Templates.
+ Click Create Template.
+ In the dialog box, enter the following values.
+
+ Name. Short name for the template.
+ Display Text. Description of the template.
+ URL. The directory name which contains image file on your CIFS server. For example, win7_64bit.
+ Zone. All Zones.
+ OS Type. Select the OS type of the ISO image. Choose other if the OS Type of the ISO is not listed or if the ISO is not bootable.
+ Hypervisor. BareMetal.
+ Format. BareMetal.
+ Password Enabled. No.
+ Public. No.
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. Only administrators may make templates featured.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/create-new-projects.xml b/docs/tmp/en-US/xml_tmp/create-new-projects.xml
new file mode 100644
index 00000000000..7696c9ee00f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-new-projects.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating a New Project
+ &PRODUCT; 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 &PRODUCT; 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.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/create-template-from-existing-vm.xml b/docs/tmp/en-US/xml_tmp/create-template-from-existing-vm.xml
new file mode 100644
index 00000000000..c22b7ec7f5c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-template-from-existing-vm.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating a Template from an Existing Virtual Machine
+ Once you have at least one VM set up in the way you want, you can use it as the prototype for other VMs.
+
+ Create and start a virtual machine using any of the techniques given in .
+ Make any desired configuration changes on the running VM, then click Stop.
+ Wait for the VM to stop. When the status shows Stopped, go to the next step.
+ Click Create Template and provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+ OS Type. This helps &PRODUCT; and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following.
+
+ If the operating system of the stopped VM is listed, choose it.
+ If the OS type of the stopped VM is not listed, choose Other.
+ If you want to boot from this template in PV mode, choose Other PV (32-bit) or Other PV (64-bit). This choice is available only for XenServere:
+ Note: Generally you should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+
+ Public. Choose Yes to make this template accessible to all users of this &PRODUCT; installation. The template will appear in the Community Templates list. See .
+ Password Enabled. Choose Yes if your template has the &PRODUCT; password change script installed. See Adding Password Management to Your Templates.
+
+ Click Add.
+
+ The new template will be visible in the Templates section when the template creation process has been completed. The template is then available when creating a new VM
+
diff --git a/docs/tmp/en-US/xml_tmp/create-template-from-snapshot.xml b/docs/tmp/en-US/xml_tmp/create-template-from-snapshot.xml
new file mode 100644
index 00000000000..80e660fe7c1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-template-from-snapshot.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating a Template from a Snapshot
+
+ If you do not want to stop the VM in order to use the Create Template menu item (as described in ), you can create a template directly from any snapshot through the &PRODUCT; UI.
+
diff --git a/docs/tmp/en-US/xml_tmp/create-templates-overview.xml b/docs/tmp/en-US/xml_tmp/create-templates-overview.xml
new file mode 100644
index 00000000000..818b42d1068
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-templates-overview.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating Templates: Overview
+ &PRODUCT; ships with a default template for the CentOS operating system. There are a variety of ways to add more templates. Administrators and end users can add templates. The typical sequence of events is:
+
+ Launch a VM instance that has the operating system you want. Make any other desired configuration changes to the VM.
+ Stop the VM.
+ Convert the volume into a template.
+
+ There are other ways to add templates to &PRODUCT;. For example, you can take a snapshot of the VM's volume and create a template from the snapshot, or import a VHD from another system into &PRODUCT;
+ The various techniques for creating templates are described in the next few sections.
+
diff --git a/docs/tmp/en-US/xml_tmp/create-vpn-connection-vpc.xml b/docs/tmp/en-US/xml_tmp/create-vpn-connection-vpc.xml
new file mode 100644
index 00000000000..1fba09e18fb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-vpn-connection-vpc.xml
@@ -0,0 +1,103 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Creating a VPN Connection
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you create for the account are listed in the page.
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+ The VPC page is displayed where all the tiers you created are listed in a
+ diagram.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ASLs
+
+
+
+
+ Select Site-to-Site VPN.
+ The Site-to-Site VPN page is displayed.
+
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+
+
+ Click Create VPN Connection.
+ The Create VPN Connection dialog is displayed:
+
+
+
+
+
+ createvpnconnection.png: creating a vpn connection to the customer
+ gateway.
+
+
+
+
+ Select the desired customer gateway, then click OK to confirm.
+ Within a few moments, the VPN Connection is displayed.
+ The following information on the VPN connection is displayed:
+
+
+ IP Address
+
+
+ Gateway
+
+
+ State
+
+
+ IPSec Preshared Key
+
+
+ IKE Policy
+
+
+ ESP Policy
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/create-vpn-customer-gateway.xml b/docs/tmp/en-US/xml_tmp/create-vpn-customer-gateway.xml
new file mode 100644
index 00000000000..8bcd488160c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-vpn-customer-gateway.xml
@@ -0,0 +1,191 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Creating and Updating a VPN Customer Gateway
+
+ A VPN customer gateway can be connected to only one VPN gateway at a time.
+
+ To add a VPN Customer Gateway:
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPN Customer Gateway.
+
+
+ Click Add site-to-site VPN.
+
+
+
+
+
+ addvpncustomergateway.png: adding a customer gateway.
+
+
+ Provide the following information:
+
+
+ Name: A unique name for the VPN customer gateway
+ you create.
+
+
+ Gateway: The IP address for the remote
+ gateway.
+
+
+ CIDR list: The guest CIDR list of the remote
+ subnets. Enter a CIDR or a comma-separated list of CIDRs. Ensure that a guest CIDR list
+ is not overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be
+ RFC1918-compliant.
+
+
+ IPsec Preshared Key: Preshared keying is a method
+ where the endpoints of the VPN share a secret key. This key value is used to
+ authenticate the customer gateway and the VPC VPN gateway to each other.
+
+ The IKE peers (VPN end points) authenticate each other by computing and sending a
+ keyed hash of data that includes the Preshared key. If the receiving peer is able to
+ create the same hash independently by using its Preshared key, it knows that both
+ peers must share the same secret, thus authenticating the customer gateway.
+
+
+
+ IKE Encryption: The Internet Key Exchange (IKE)
+ policy for phase-1. The supported encryption algorithms are AES128, AES192, AES256, and
+ 3DES. Authentication is accomplished through the Preshared Keys.
+
+ The phase-1 is the first phase in the IKE process. In this initial negotiation
+ phase, the two VPN endpoints agree on the methods to be used to provide security for
+ the underlying IP traffic. The phase-1 authenticates the two VPN gateways to each
+ other, by confirming that the remote gateway has a matching Preshared Key.
+
+
+
+ IKE Hash: The IKE hash for phase-1. The supported
+ hash algorithms are SHA1 and MD5.
+
+
+ IKE DH: A public-key cryptography protocol which
+ allows two parties to establish a shared secret over an insecure communications channel.
+ The 1536-bit Diffie-Hellman group is used within IKE to establish session keys. The
+ supported options are None, Group-5 (1536-bit) and Group-2 (1024-bit).
+
+
+ ESP Encryption: Encapsulating Security Payload
+ (ESP) algorithm within phase-2. The supported encryption algorithms are AES128, AES192,
+ AES256, and 3DES.
+
+ The phase-2 is the second phase in the IKE process. The purpose of IKE phase-2 is
+ to negotiate IPSec security associations (SA) to set up the IPSec tunnel. In phase-2,
+ new keying material is extracted from the Diffie-Hellman key exchange in phase-1, to
+ provide session keys to use in protecting the VPN data flow.
+
+
+
+ ESP Hash: Encapsulating Security Payload (ESP) hash
+ for phase-2. Supported hash algorithms are SHA1 and MD5.
+
+
+ Perfect Forward Secrecy: Perfect Forward Secrecy
+ (or PFS) is the property that ensures that a session key derived from a set of long-term
+ public and private keys will not be compromised. This property enforces a new
+ Diffie-Hellman key exchange. It provides the keying material that has greater key
+ material life and thereby greater resistance to cryptographic attacks. The available
+ options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the key
+ exchanges increase as the DH groups grow larger, as does the time of the
+ exchanges.
+
+ When PFS is turned on, for every negotiation of a new phase-2 SA the two gateways
+ must generate a new set of phase-1 keys. This adds an extra layer of protection that
+ PFS adds, which ensures if the phase-2 SA’s have expired, the keys used for new
+ phase-2 SA’s have not been generated from the current phase-1 keying material.
+
+
+
+ IKE Lifetime (seconds): The phase-1 lifetime of the
+ security association in seconds. Default is 86400 seconds (1 day). Whenever the time
+ expires, a new phase-1 exchange is performed.
+
+
+ ESP Lifetime (seconds): The phase-2 lifetime of the
+ security association in seconds. Default is 3600 seconds (1 hour). Whenever the value is
+ exceeded, a re-key is initiated to provide a new IPsec encryption and authentication
+ session keys.
+
+
+ Dead Peer Detection: A method to detect an
+ unavailable Internet Key Exchange (IKE) peer. Select this option if you want the virtual
+ router to query the liveliness of its IKE peer at regular intervals. It’s recommended to
+ have the same configuration of DPD on both side of VPN connection.
+
+
+
+
+ Click OK.
+
+
+
+ Updating and Removing a VPN Customer Gateway
+ You can update a customer gateway either with no VPN connection, or related VPN connection
+ is in error state.
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPN Customer Gateway.
+
+
+ Select the VPN customer gateway you want to work with.
+
+
+ To modify the required parameters, click the Edit VPN Customer Gateway button
+
+
+
+
+ edit.png: button to edit a VPN customer gateway
+
+
+
+
+ To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
+
+
+
+
+ delete.png: button to remove a VPN customer gateway
+
+
+
+
+ Click OK.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/create-vpn-gateway-for-vpc.xml b/docs/tmp/en-US/xml_tmp/create-vpn-gateway-for-vpc.xml
new file mode 100644
index 00000000000..396a7d9d174
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-vpn-gateway-for-vpc.xml
@@ -0,0 +1,80 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Creating a VPN gateway for the VPC
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+ The VPC page is displayed where all the tiers you created are listed in a
+ diagram.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ACLs
+
+
+
+
+ Select Site-to-Site VPN.
+ If you are creating the VPN gateway for the first time, selecting Site-to-Site VPN
+ prompts you to create a VPN gateway.
+
+
+ In the confirmation dialog, click Yes to confirm.
+ Within a few moments, the VPN gateway is created. You will be prompted to view the
+ details of the VPN gateway you have created. Click Yes to confirm.
+ The following details are displayed in the VPN Gateway page:
+
+
+ IP Address
+
+
+ Account
+
+
+ Domain
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/create-vr-network-offering.xml b/docs/tmp/en-US/xml_tmp/create-vr-network-offering.xml
new file mode 100644
index 00000000000..317e3c200a1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-vr-network-offering.xml
@@ -0,0 +1,108 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Creating and Changing a Virtual Router Network Offering
+ To create the network offering in association with a virtual router system service
+ offering:
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+
+
+ First, create a system service offering, for example: VRsystemofferingHA.
+ For more information on creating a system service offering, see .
+
+
+ From the Select Offering drop-down, choose Network Offering.
+
+
+ Click Add Network Offering.
+
+
+ In the dialog, make the following choices:
+
+
+ Name. Any desired name for the network
+ offering.
+
+
+ Description. A short description of the offering
+ that can be displayed to users.
+
+
+ Network Rate. Allowed data transfer rate in MB per
+ second.
+
+
+ Traffic Type. The type of network traffic that will
+ be carried on the network.
+
+
+ Guest Type. Choose whether the guest network is
+ isolated or shared. For a description of these terms, see .
+
+
+ Specify VLAN. (Isolated guest networks only)
+ Indicate whether a VLAN should be specified when this offering is used.
+
+
+ Supported Services. Select one or more of the
+ possible network services. For some services, you must also choose the service provider;
+ for example, if you select Load Balancer, you can choose the &PRODUCT; virtual router or
+ any other load balancers that have been configured in the cloud. Depending on which
+ services you choose, additional fields may appear in the rest of the dialog box. For
+ more information, see
+
+
+ System Offering. Choose the system service offering
+ that you want virtual routers to use in this network. In this case, the default “System
+ Offering For Software Router” and the custom “VRsystemofferingHA” are available and
+ displayed.
+
+
+
+
+ Click OK and the network offering is created.
+
+
+ To change the network offering of a guest network to the virtual router service
+ offering:
+
+
+ Select Network from the left navigation pane.
+
+
+ Select the guest network that you want to offer this network service to.
+
+
+ Click the Edit button.
+
+
+ From the Network Offering drop-down, select the virtual router network offering you have
+ just created.
+
+
+ Click OK.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/create-windows-template.xml b/docs/tmp/en-US/xml_tmp/create-windows-template.xml
new file mode 100644
index 00000000000..f8dbc79bce9
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/create-windows-template.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating a Windows Template
+ Windows templates must be prepared with Sysprep before they can be provisioned on multiple machines. Sysprep allows you to create a generic Windows template and avoid any possible SID conflicts.
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+ An overview of the procedure is as follows:
+
+ Upload your Windows ISO.For more information, see
+ Create a VM Instance with this ISO. For more information, see
+ Follow the steps in Sysprep for Windows Server 2008 R2 (below) or Sysprep for Windows Server 2003 R2, depending on your version of Windows Server
+ The preparation steps are complete. Now you can actually create the template as described in Creating the Windows Template.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/creating-compute-offerings.xml b/docs/tmp/en-US/xml_tmp/creating-compute-offerings.xml
new file mode 100644
index 00000000000..31f974196fb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/creating-compute-offerings.xml
@@ -0,0 +1,66 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Creating a New Compute Offering
+ To create a new compute offering:
+
+ Log in with admin privileges to the &PRODUCT; UI.
+ In the left navigation bar, click Service Offerings.
+ In Select Offering, choose Compute Offering.
+ Click Add Compute Offering.
+ In the dialog, make the following choices:
+
+ Name: Any desired name for the service offering.
+ Description: A short description of the offering that can be
+ displayed to users
+ Storage type: The type of disk that should be allocated.
+ Local allocates from storage attached directly to the host where the system
+ VM is running. Shared allocates from storage accessible via NFS.
+ # of CPU cores: The number of cores which should be allocated
+ to a system VM with this offering
+ CPU (in MHz): The CPU speed of the cores that the system VM
+ is allocated. For example, “2000” would provide for a 2 GHz clock.
+ Memory (in MB): The amount of memory in megabytes that the
+ system VM should be allocated. For example, “2048” would provide for a 2 GB
+ RAM allocation.
+ Network Rate: Allowed data transfer rate in MB per
+ second.
+ Offer HA: If yes, the administrator can choose to have the
+ system VM be monitored and as highly available as possible.
+ Storage Tags: The tags that should be associated with the
+ primary storage used by the system VM.
+ Host Tags: (Optional) Any tags that you use to organize your
+ hosts
+ CPU cap: Whether to limit the level of CPU usage even if
+ spare capacity is available.
+ Public: Indicate whether the service offering should be
+ available all domains or only some domains. Choose Yes to make it available
+ to all domains. Choose No to limit the scope to a subdomain; &PRODUCT;
+ will then prompt for the subdomain's name.
+
+ Click Add.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/creating-disk-offerings.xml b/docs/tmp/en-US/xml_tmp/creating-disk-offerings.xml
new file mode 100644
index 00000000000..12bb2aca785
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/creating-disk-offerings.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating a New Disk Offering
+ To create a system service offering:
+
+ Log in with admin privileges to the &PRODUCT; UI.
+ In the left navigation bar, click Service Offerings.
+ In Select Offering, choose Disk Offering.
+ Click Add Disk Offering.
+ In the dialog, make the following choices:
+
+ Name. Any desired name for the system offering.
+ Description. A short description of the offering that can be displayed to users
+ Custom Disk Size. If checked, the user can set their own disk size. If not checked, the root administrator must define a value in Disk Size.
+ Disk Size. Appears only if Custom Disk Size is not selected. Define the volume size in GB.
+ (Optional)Storage Tags. The tags that should be associated with the primary storage for this disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue". Tags are also added on Primary Storage. &PRODUCT; matches tags on a disk offering to tags on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation from the disk offering will fail..
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; &PRODUCT; will then prompt for the subdomain's name.
+
+ Click Add.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/creating-network-offerings.xml b/docs/tmp/en-US/xml_tmp/creating-network-offerings.xml
new file mode 100644
index 00000000000..ab569200641
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/creating-network-offerings.xml
@@ -0,0 +1,117 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating a New Network Offering
+ To create a network offering:
+
+ Log in with admin privileges to the &PRODUCT; UI.
+ In the left navigation bar, click Service Offerings.
+ In Select Offering, choose Network Offering.
+ Click Add Network Offering.
+ In the dialog, make the following choices:
+
+ Name. Any desired name for the network offering
+ Description. A short description of the offering that can be displayed to users
+ Network Rate. Allowed data transfer rate in MB per second
+ Traffic Type. The type of network traffic that will be carried on the network
+ Guest Type. Choose whether the guest network is isolated or shared. For a description of these terms, see
+ Specify VLAN. (Isolated guest networks only) Indicate whether a VLAN should be specified when this offering is used
+ Supported Services. Select one or more of the possible network services. For some services, you must also choose the service provider; for example, if you select Load Balancer, you can choose the &PRODUCT; virtual router or any other load balancers that have been configured in the cloud. Depending on which services you choose, additional fields may appear in the rest of the dialog box.Based on the guest network type selected, you can see the following supported services:
+
+
+
+ Supported Services
+ Description
+ Isolated
+ Shared
+
+
+
+
+ DHCP
+
+ Supported
+ Supported
+
+
+ DNS
+
+ Supported
+ Supported
+
+
+ Load Balancer
+ If you select Load Balancer, you can choose the &PRODUCT; virtual router or any other load balancers that have been configured in the cloud.
+ Supported
+ Supported
+
+
+ Source NAT
+ If you select Source NAT, you can choose the &PRODUCT; virtual router or any other Source NAT providers that have been configured in the cloud.
+ Supported
+ Supported
+
+
+ Static NAT
+ If you select Static NAT, you can choose the &PRODUCT; virtual router or any other Static NAT providers that have been configured in the cloud.
+ Supported
+ Supported
+
+
+ Port Forwarding
+ If you select Port Forwarding, you can choose the &PRODUCT; virtual router or any other Port Forwarding providers that have been configured in the cloud.
+ Supported
+ Not Supported
+
+
+ VPN
+
+ Supported
+ Not Supported
+
+
+ User Data
+
+ Not Supported
+ Supported
+
+
+ Security Groups
+ See .
+ Not Supported
+ Supported
+
+
+
+
+
+ System Offering. If the service provider for any of the services selected in Supported Services is a virtual router, the System Offering field appears. Choose the system service offering that you want virtual routers to use in this network. For example, if you selected Load Balancer in Supported Services and selected a virtual router to provide load balancing, the System Offering field appears so you can choose between the &PRODUCT; default system service offering and any custom system service offerings that have been defined by the &PRODUCT; root administrator. For more information, see System Service Offerings.
+ Redundant router capability. (v3.0.3 and greater) Available only when Virtual Router is selected as the Source NAT provider. Select this option if you want to use two virtual routers in the network for uninterrupted connection: one operating as the master virtual router and the other as the backup. The master virtual router receives requests from and sends responses to the user’s VM. The backup virtual router is activated only when the master is down. After the failover, the backup becomes the master virtual router. &PRODUCT; deploys the routers on different hosts to ensure reliability if one host is down.
+ Conserve mode. Indicate whether to use conserve mode. In this mode, network resources are allocated only when the first virtual machine starts in the network
+ Tags. Network tag to specify which physical network to use
+
+ Click Add.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/creating-new-volumes.xml b/docs/tmp/en-US/xml_tmp/creating-new-volumes.xml
new file mode 100644
index 00000000000..62181b9ea36
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/creating-new-volumes.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating a New Volume
+ You can add more data disk volumes to a guest VM at any time, up to the limits of your storage capacity. Both &PRODUCT; administrators and users can add volumes to VM instances. When you create a new volume, it is stored as an entity in &PRODUCT;, but the actual storage resources are not allocated on the physical storage device until you attach the volume. This optimization allows the &PRODUCT; to provision the volume nearest to the guest that will use it when the first attachment is made.
+
+ Log in to the &PRODUCT; UI as a user or admin.
+ In the left navigation bar, click Storage.
+ In Select View, choose Volumes.
+ To create a new volume, click Add Volume, provide the following details, and click OK.
+
+ Name. Give the volume a unique name so you can find it later.
+ Availability Zone. Where do you want the storage to reside? This should be close to the VM that will use the volume.
+ Disk Offering. Choose the characteristics of the storage.
+
+ The new volume appears in the list of volumes with the state “Allocated.” The volume data is stored in &PRODUCT;, but the volume is not yet ready for use
+ To start using the volume, continue to Attaching a Volume
+
+
diff --git a/docs/tmp/en-US/xml_tmp/creating-system-service-offerings.xml b/docs/tmp/en-US/xml_tmp/creating-system-service-offerings.xml
new file mode 100644
index 00000000000..e33d9d07767
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/creating-system-service-offerings.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating a New System Service Offering
+ To create a system service offering:
+
+ Log in with admin privileges to the &PRODUCT; UI.
+ In the left navigation bar, click Service Offerings.
+ In Select Offering, choose System Offering.
+ Click Add System Service Offering.
+ In the dialog, make the following choices:
+
+ Name. Any desired name for the system offering.
+ Description. A short description of the offering that can be displayed to users
+ System VM Type. Select the type of system virtual machine that this offering is intended to support.
+ Storage type. The type of disk that should be allocated. Local allocates from storage attached directly to the host where the system VM is running. Shared allocates from storage accessible via NFS.
+ # of CPU cores. The number of cores which should be allocated to a system VM with this offering
+ CPU (in MHz). The CPU speed of the cores that the system VM is allocated. For example, "2000" would provide for a 2 GHz clock.
+ Memory (in MB). The amount of memory in megabytes that the system VM should be allocated. For example, "2048" would provide for a 2 GB RAM allocation.
+ Network Rate. Allowed data transfer rate in MB per second.
+ Offer HA. If yes, the administrator can choose to have the system VM be monitored and as highly available as possible.
+ Storage Tags. The tags that should be associated with the primary storage used by the system VM.
+ Host Tags. (Optional) Any tags that you use to organize your hosts
+ CPU cap. Whether to limit the level of CPU usage even if spare capacity is available.
+ Public. Indicate whether the service offering should be available all domains or only some domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a subdomain; &PRODUCT; will then prompt for the subdomain's name.
+
+ Click Add.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/creating-vms.xml b/docs/tmp/en-US/xml_tmp/creating-vms.xml
new file mode 100644
index 00000000000..9da4aea94ea
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/creating-vms.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Creating VMs
+ Virtual machines are usually created from a template. Users can also create blank virtual machines. A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and install the OS from the CD/DVD-ROM.
+ To create a VM from a template:
+
+ Log in to the &PRODUCT; UI as an administrator or user.
+ In the left navigation bar, click Instances.
+ Click Add Instance.
+ Select a template, then follow the steps in the wizard. (For more information about how the templates came to be in this list, see Working with Templates.
+ Be sure that the hardware you have allows starting the selected service offering.
+ Click Submit and your VM will be created and started.
+ For security reason, the internal name of the VM is visible only to the root admin.
+
+ Starting with v3.0.3, you can create a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A new request parameter, startVM, is introduced in the deployVm API to support this feature. For more information, see the Developer's Guide
+ To create a VM from an ISO:
+ (XenServer) Windows VMs running on XenServer require PV drivers, which may be provided in the template or added after the VM is created. The PV drivers are necessary for essential management functions such as mounting additional volumes and ISO images, live migration, and graceful shutdown.
+
+ Log in to the &PRODUCT; UI as an administrator or user.
+ In the left navigation bar, click Instances.
+ Click Add Instance.
+ Select ISO Boot, and follow the steps in the wizard.
+ Click Submit and your VM will be created and started.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/customizing-dns.xml b/docs/tmp/en-US/xml_tmp/customizing-dns.xml
new file mode 100644
index 00000000000..c24bad895f4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/customizing-dns.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 &PRODUCT; 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 or with the updateNetwork command in the &PRODUCT; API.
+ At the account, domain, or zone level, the DNS suffix can be assigned with the appropriate &PRODUCT; 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 &PRODUCT; 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 &PRODUCT; 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.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/dates-in-usage-record.xml b/docs/tmp/en-US/xml_tmp/dates-in-usage-record.xml
new file mode 100644
index 00000000000..dc2f07221be
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/dates-in-usage-record.xml
@@ -0,0 +1,26 @@
+
+
+
+ Dates in the Usage Record
+ Usage records include a start date and an end date. These dates define the period of time for which the raw usage number was calculated. If daily aggregation is used, the start date is midnight on the day in question and the end date is 23:59:59 on the day in question (with one exception; see below). A virtual machine could have been deployed at noon on that day, stopped at 6pm on that day, then started up again at 11pm. When usage is calculated on that day, there will be 7 hours of running VM usage (usage type 1) and 12 hours of allocated VM usage (usage type 2). If the same virtual machine runs for the entire next day, there will 24 hours of both running VM usage (type 1) and allocated VM usage (type 2).
+ Note: The start date is not the time a virtual machine was started, and the end date is not the time when a virtual machine was stopped. The start and end dates give the time range within which usage was calculated.
+ For network usage, the start date and end date again define the range in which the number of bytes transferred was calculated. If a user downloads 10 MB and uploads 1 MB in one day, there will be two records, one showing the 10 megabytes received and one showing the 1 megabyte sent.
+ There is one case where the start date and end date do not correspond to midnight and 11:59:59pm when daily aggregation is used. This occurs only for network usage records. When the usage server has more than one day's worth of unprocessed data, the old data will be included in the aggregation period. The start date in the usage record will show the date and time of the earliest event. For other types of usage, such as IP addresses and VMs, the old unprocessed data is not included in daily aggregation.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/dedicated-ha-hosts.xml b/docs/tmp/en-US/xml_tmp/dedicated-ha-hosts.xml
new file mode 100644
index 00000000000..ab50700197a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/dedicated-ha-hosts.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Dedicated HA Hosts
+ (v3.0.3 and greater) One or more hosts can be designated for use only by HA-enabled VMs that are restarting due to a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HA-enabled VMs is useful to:
+
+ Make it easier to determine which VMs have been restarted as part of the &PRODUCT; high-availability function. If a VM is running on a dedicated HA host, then it must be an HA-enabled VM whose original host failed. (With one exception: It is possible for an administrator to manually migrate any VM to a dedicated HA host.).
+ Keep HA-enabled VMs from restarting on hosts which may be reserved for other purposes.
+
+ The dedicated HA option is set through a special host tag when the host is created. To allow the administrator to dedicate hosts to only HA-enabled VMs, set the global configuration variable ha.tag to the desired tag (for example, "ha_host"), and restart the Management Server. Enter the value in the Host Tags field when adding the host(s) that you want to dedicate to HA-enabled VMs.
+ If you set ha.tag, be sure to actually use that tag on at least one host in your cloud. If the tag specified in ha.tag is not set for any host in the cloud, the HA-enabled VMs will fail to restart after a crash.
+
diff --git a/docs/tmp/en-US/xml_tmp/default-account-resource-limit.xml b/docs/tmp/en-US/xml_tmp/default-account-resource-limit.xml
new file mode 100644
index 00000000000..abc313f46bf
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/default-account-resource-limit.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Default Account Resource Limits
+ You can limit resource use by accounts. The default limits are set using global configuration parameters, and they affect all accounts within a cloud. The relevant parameters are those beginning with max.account (max.account.snapshots, etc.)..
+ To override a default limit for a particular account, set a per-account resource limit.
+
+ Log in to the &PRODUCT; UI.
+ In the left navigation tree, click Accounts.
+ Select the account you want to modify. The current limits are displayed. A value of -1 shows that there is no limit in place
+ Click the Edit button
+
+
+
+ editbutton.png: edits the settings.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/default-template.xml b/docs/tmp/en-US/xml_tmp/default-template.xml
new file mode 100644
index 00000000000..16442c38f47
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/default-template.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ The Default Template
+ &PRODUCT; includes a CentOS template. This template is downloaded by the Secondary Storage VM after the primary and secondary storage are configured. You can use this template in your production deployment or you can delete it and use custom templates.
+ The root password for the default template is "password".
+ A default template is provided for each of XenServer, KVM, and vSphere. The templates that are downloaded depend on the hypervisor type that is available in your cloud. Each template is approximately 2.5 GB physical size.
+ The default template includes the standard iptables rules, which will block most access to the template excluding ssh.
+ # iptables --list
+Chain INPUT (policy ACCEPT)
+target prot opt source destination
+RH-Firewall-1-INPUT all -- anywhere anywhere
+
+Chain FORWARD (policy ACCEPT)
+target prot opt source destination
+RH-Firewall-1-INPUT all -- anywhere anywhere
+
+Chain OUTPUT (policy ACCEPT)
+target prot opt source destination
+
+Chain RH-Firewall-1-INPUT (2 references)
+target prot opt source destination
+ACCEPT all -- anywhere anywhere
+ACCEPT icmp -- anywhere anywhere icmp any
+ACCEPT esp -- anywhere anywhere
+ACCEPT ah -- anywhere anywhere
+ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
+ACCEPT udp -- anywhere anywhere udp dpt:ipp
+ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
+ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
+ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
+REJECT all -- anywhere anywhere reject-with icmp-host-
+
+
diff --git a/docs/tmp/en-US/xml_tmp/delete-reset-vpn.xml b/docs/tmp/en-US/xml_tmp/delete-reset-vpn.xml
new file mode 100644
index 00000000000..318e5fe321e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/delete-reset-vpn.xml
@@ -0,0 +1,89 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Restarting and Removing a VPN Connection
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+ The VPC page is displayed where all the tiers you created are listed in a
+ diagram.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ASLs
+
+
+
+
+ Select Site-to-Site VPN.
+ The Site-to-Site VPN page is displayed.
+
+
+ From the Select View drop-down, ensure that VPN Connection is selected.
+ All the VPN connections you created are displayed.
+
+
+ Select the VPN connection you want to work with.
+ The Details tab is displayed.
+
+
+ To remove a VPN connection, click the Delete VPN connection button
+
+
+
+
+ remove-vpn.png: button to remove a VPN connection
+
+
+ To restart a VPN connection, click the Reset VPN connection button present in the
+ Details tab.
+
+
+
+
+ reset-vpn.png: button to reset a VPN connection
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/delete-templates.xml b/docs/tmp/en-US/xml_tmp/delete-templates.xml
new file mode 100644
index 00000000000..f9351da844f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/delete-templates.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Deleting Templates
+ Templates may be deleted. In general, when a template spans multiple Zones, only the copy that is selected for deletion will be deleted; the same template in other Zones will not be deleted. The provided CentOS template is an exception to this. If the provided CentOS template is deleted, it will be deleted from all Zones.
+ When templates are deleted, the VMs instantiated from them will continue to run. However, new VMs cannot be created based on the deleted template.
+
diff --git a/docs/tmp/en-US/xml_tmp/deleting-vms.xml b/docs/tmp/en-US/xml_tmp/deleting-vms.xml
new file mode 100644
index 00000000000..1f1ee959f57
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/deleting-vms.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Deleting VMs
+ Users can delete their own virtual machines. A running virtual machine will be abruptly stopped before it is deleted. Administrators can delete any virtual machines.
+ To delete a virtual machine:
+
+ Log in to the &PRODUCT; UI as a user or admin.
+ In the left navigation, click Instances.
+ Choose the VM that you want to delete.
+ Click the Destroy Instance button
+
+
+
+ Destroyinstance.png: button to destroy an instance
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/dell62xx-hardware.xml b/docs/tmp/en-US/xml_tmp/dell62xx-hardware.xml
new file mode 100644
index 00000000000..8bc7770ce86
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/dell62xx-hardware.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Dell 62xx
+ The following steps show how a Dell 62xx is configured for zone-level layer-3 switching.
+ These steps assume VLAN 201 is used to route untagged private IPs for pod 1, and pod 1’s layer-2
+ switch is connected to Ethernet port 1/g1.
+ The Dell 62xx Series switch supports up to 1024 VLANs.
+
+
+ Configure all the VLANs in the database.
+ vlan database
+vlan 200-999
+exit
+
+
+ Configure Ethernet port 1/g1.
+ interface ethernet 1/g1
+switchport mode general
+switchport general pvid 201
+switchport general allowed vlan add 201 untagged
+switchport general allowed vlan add 300-999 tagged
+exit
+
+
+ The statements configure Ethernet port 1/g1 as follows:
+
+
+ VLAN 201 is the native untagged VLAN for port 1/g1.
+
+
+ All VLANs (300-999) are passed to all the pod-level layer-2 switches.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/dell62xx-layer2.xml b/docs/tmp/en-US/xml_tmp/dell62xx-layer2.xml
new file mode 100644
index 00000000000..1c0eea07203
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/dell62xx-layer2.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Dell 62xx
+ The following steps show how a Dell 62xx is configured for pod-level layer-2
+ switching.
+
+
+ Configure all the VLANs in the database.
+ vlan database
+vlan 300-999
+exit
+
+
+ VLAN 201 is used to route untagged private IP addresses for pod 1, and pod 1 is connected to this layer-2 switch.
+ interface range ethernet all
+switchport mode general
+switchport general allowed vlan add 300-999 tagged
+exit
+
+
+ The statements configure all Ethernet ports to function as follows:
+
+
+ All ports are configured the same way.
+
+
+ All VLANs (300-999) are passed through all the ports of the layer-2 switch.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/deployment-architecture-overview.xml b/docs/tmp/en-US/xml_tmp/deployment-architecture-overview.xml
new file mode 100644
index 00000000000..2c5f30ec06b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/deployment-architecture-overview.xml
@@ -0,0 +1,57 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Deployment Architecture Overview
+
+ A &PRODUCT; installation consists of two parts: the Management Server
+ and the cloud infrastructure that it manages. When you set up and
+ manage a &PRODUCT; cloud, you provision resources such as hosts,
+ storage devices, and IP addresses into the Management Server, and
+ the Management Server manages those resources.
+
+
+ The minimum production installation consists of one machine running
+ the &PRODUCT; Management Server and another machine to act as the
+ cloud infrastructure (in this case, a very simple infrastructure
+ consisting of one host running hypervisor software). In its smallest
+ deployment, a single machine can act as both the Management Server
+ and the hypervisor host (using the KVM hypervisor).
+
+
+
+
+
+ basic-deployment.png: Basic two-machine deployment
+
+
+ A more full-featured installation consists of a highly-available
+ multi-node Management Server installation and up to tens of thousands of
+ hosts using any of several advanced networking setups. For
+ information about deployment options, see Choosing a Deployment Architecture.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/detach-move-volumes.xml b/docs/tmp/en-US/xml_tmp/detach-move-volumes.xml
new file mode 100644
index 00000000000..25323c928ee
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/detach-move-volumes.xml
@@ -0,0 +1,43 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Attaching a Volume
+ This procedure is different from moving disk volumes from one storage pool to another. See VM Storage Migration
+ A volume can be detached from a guest VM and attached to another guest. Both &PRODUCT; administrators and users can detach volumes from VMs and move them to other VMs.
+ If the two VMs are in different clusters, and the volume is large, it may take several minutes for the volume to be moved to the new VM.
+
+
+ Log in to the &PRODUCT; UI as a user or admin.
+ In the left navigation bar, click Storage, and choose Volumes in Select View. Alternatively, if you know which VM the volume is attached to, you can click Instances, click the VM name, and click View Volumes.
+ Click the name of the volume you want to detach, then click the Detach Disk button
+
+
+
+ DetachDiskButton.png: button to detach a volume
+
+
+ To move the volume to another VM, follow the steps in Attaching a Volume .
+
+
diff --git a/docs/tmp/en-US/xml_tmp/developer-getting-started.xml b/docs/tmp/en-US/xml_tmp/developer-getting-started.xml
new file mode 100644
index 00000000000..14560280909
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/developer-getting-started.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+
+ Getting Started
+
+ To get started using the &PRODUCT; API, you should have the following:
+
+ URL of the &PRODUCT; server you wish to integrate with.
+ Both the API Key and Secret Key for an account. This should have been generated by the administrator of the cloud instance and given to you.
+ Familiarity with HTTP GET/POST and query strings.
+ Knowledge of either XML or JSON.
+ Knowledge of a programming language that can generate HTTP requests; for example, Java or PHP.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/developer-guide.xml b/docs/tmp/en-US/xml_tmp/developer-guide.xml
new file mode 100644
index 00000000000..c4bdf39d6fc
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/developer-guide.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using the API
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/developer-introduction.xml b/docs/tmp/en-US/xml_tmp/developer-introduction.xml
new file mode 100644
index 00000000000..bb5251b4f26
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/developer-introduction.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Introduction for Developers
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/developer_guide.xml b/docs/tmp/en-US/xml_tmp/developer_guide.xml
new file mode 100644
index 00000000000..18ef88a4c68
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/developer_guide.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Developer Guide
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/disable-enable-zones-pods-clusters.xml b/docs/tmp/en-US/xml_tmp/disable-enable-zones-pods-clusters.xml
new file mode 100644
index 00000000000..7d52ae7c7a9
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/disable-enable-zones-pods-clusters.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 &PRODUCT; 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.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/disk-volume-usage-record-format.xml b/docs/tmp/en-US/xml_tmp/disk-volume-usage-record-format.xml
new file mode 100644
index 00000000000..c15d979e113
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/disk-volume-usage-record-format.xml
@@ -0,0 +1,38 @@
+
+
+
+ Disk Volume Usage Record Format
+ For disk volumes, the following fields exist in a usage record.
+
+ account – name of the account
+ accountid – ID of the account
+ domainid – ID of the domain in which this account resides
+ zoneid – Zone where the usage occurred
+ description – A string describing what the usage record is tracking
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ usagetype – A number representing the usage type (see Usage Types)
+ rawusage – A number representing the actual usage in hours
+ usageid – The volume ID
+ offeringid – The ID of the disk offering
+ type – Hypervisor
+ templateid – ROOT template ID
+ size – The amount of storage allocated
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
diff --git a/docs/tmp/en-US/xml_tmp/dns-dhcp.xml b/docs/tmp/en-US/xml_tmp/dns-dhcp.xml
new file mode 100644
index 00000000000..2359e8380cd
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/dns-dhcp.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ DNS and DHCP
+ The Virtual Router provides DNS and DHCP services to the guests. It proxies DNS requests to the DNS server configured on the Availability Zone.
+
diff --git a/docs/tmp/en-US/xml_tmp/domains.xml b/docs/tmp/en-US/xml_tmp/domains.xml
new file mode 100644
index 00000000000..f348fe88998
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/domains.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Domains
+ 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/enable-disable-static-nat-vpc.xml b/docs/tmp/en-US/xml_tmp/enable-disable-static-nat-vpc.xml
new file mode 100644
index 00000000000..17f0c10540f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/enable-disable-static-nat-vpc.xml
@@ -0,0 +1,97 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Enabling or Disabling Static NAT on a VPC
+ A static NAT rule maps a public IP address to the private IP address of a VM in a VPC to
+ allow Internet traffic to it. This section tells how to enable or disable static NAT for a
+ particular IP address in a VPC.
+ If port forwarding rules are already in effect for an IP address, you cannot enable static
+ NAT to that IP.
+ If a guest VM is part of more than one network, static NAT rules will function only if they
+ are defined on the default network.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC to which you want to deploy the VMs.
+ The VPC page is displayed where all the tiers you created are listed in a
+ diagram.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ACLs
+
+
+
+
+ Select IP Addresses.
+ The IP Addresses page is displayed.
+
+
+ Click the IP you want to work with.
+
+
+ In the Details tab,click the Static NAT button.
+
+
+
+
+ enable-disable.png: button to enable Statid NAT.
+
+ The button toggles between Enable and Disable, depending on whether
+ static NAT is currently enabled for the IP address.
+
+
+ If you are enabling static NAT, a dialog appears as follows:
+
+
+
+
+
+ select-vmstatic-nat.png: selecting a tier to apply staticNAT.
+
+
+
+
+ Select the tier and the destination VM, then click Apply.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/enable-disable-static-nat.xml b/docs/tmp/en-US/xml_tmp/enable-disable-static-nat.xml
new file mode 100644
index 00000000000..f25327a54b3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/enable-disable-static-nat.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Enabling or Disabling Static NAT
+ If port forwarding rules are already in effect for an IP address, you cannot enable static NAT to that IP.
+ If a guest VM is part of more than one network, static NAT rules will function only if they are defined on the default network.
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+ In the left navigation, choose Network.
+ Click the name of the network where you want to work with.
+ Click View IP Addresses.
+ Click the IP address you want to work with.
+
+ Click the Static NAT button.
+
+
+
+ ReleaseIPButton.png: button to release an IP
+ The button toggles between Enable and Disable, depending on whether static NAT is currently enabled for the IP address.
+ If you are enabling static NAT, a dialog appears where you can choose the destination VM and click Apply
+
+
diff --git a/docs/tmp/en-US/xml_tmp/enable-security-groups.xml b/docs/tmp/en-US/xml_tmp/enable-security-groups.xml
new file mode 100644
index 00000000000..27f69d2cef2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/enable-security-groups.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Enabling Security Groups
+ In order for security groups to function in a zone, the security groups feature must first be enabled for the zone. The administrator can do this when creating a new zone, by selecting a network offering that includes security groups. The procedure is described in Basic Zone Configuration in the Advanced Installation Guide.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/enabling-api-call-expiration.xml b/docs/tmp/en-US/xml_tmp/enabling-api-call-expiration.xml
new file mode 100644
index 00000000000..cd82d3d1141
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/enabling-api-call-expiration.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Enabling API Call Expiration
+
+ You can set an expiry timestamp on API calls to prevent replay attacks over non-secure channels, such as HTTP. The server tracks the expiry timestamp you have specified and rejects all the subsequent API requests that come in after this validity period.
+
+ To enable this feature, add the following parameters to the API request:
+
+ signatureVersion=3: If the signatureVersion parameter is missing or is not equal to 3, the expires parameter is ignored in the API request.
+ expires=YYYY-MM-DDThh:mm:ssZ: Specifies the date and time at which the signature included in the request is expired. The timestamp is expressed in the YYYY-MM-DDThh:mm:ssZ format, as specified in the ISO 8601 standard.
+
+ For example:
+ expires=2011-10-10T12:00:00+0530
+ A sample API request with expiration is given below:
+ http://<IPAddress>:8080/client/api?command=listZones&signatureVersion=3&expires=2011-10-10T12:00:00+0530&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+
diff --git a/docs/tmp/en-US/xml_tmp/enabling-port-8096.xml b/docs/tmp/en-US/xml_tmp/enabling-port-8096.xml
new file mode 100644
index 00000000000..57c492edcd5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/enabling-port-8096.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Enabling Port 8096
+
+ Port 8096, which allows API calls without authentication, is closed and disabled by default on any fresh 3.0.1 installations. You can enable 8096 (or another port) for this purpose as follows:
+
+
+ Ensure that the first Management Server is installed and running.
+ Set the global configuration parameter integration.api.port to the desired port.
+ Restart the Management Server.
+ On the Management Server host machine, create an iptables rule allowing access to that port.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/end-user-ui-overview.xml b/docs/tmp/en-US/xml_tmp/end-user-ui-overview.xml
new file mode 100644
index 00000000000..dc95ce064b9
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/end-user-ui-overview.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ End User's UI Overview
+ The &PRODUCT; 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 &PRODUCT; projects, the UI can provide a project-oriented view.
+
diff --git a/docs/tmp/en-US/xml_tmp/error-handling.xml b/docs/tmp/en-US/xml_tmp/error-handling.xml
new file mode 100644
index 00000000000..3f119bf4d93
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/error-handling.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Error Handling
+ If an error occurs while processing an API request, the appropriate response in the format specified is returned. Each error response consists of an error code and an error text describing what possibly can go wrong. For an example error response, see page 12.
+ An HTTP error code of 401 is always returned if API request was rejected due to bad signatures, missing API Keys, or the user simply did not have the permissions to execute the command.
+
diff --git a/docs/tmp/en-US/xml_tmp/event-log-queries.xml b/docs/tmp/en-US/xml_tmp/event-log-queries.xml
new file mode 100644
index 00000000000..32a1612ce6c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/event-log-queries.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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
+
+
diff --git a/docs/tmp/en-US/xml_tmp/event-types.xml b/docs/tmp/en-US/xml_tmp/event-types.xml
new file mode 100644
index 00000000000..2ccd55335df
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/event-types.xml
@@ -0,0 +1,220 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Event Types
+
+
+
+
+
+
+ VM.CREATE
+ TEMPLATE.EXTRACT
+ SG.REVOKE.INGRESS
+
+
+ VM.DESTROY
+ TEMPLATE.UPLOAD
+ HOST.RECONNECT
+
+
+ VM.START
+ TEMPLATE.CLEANUP
+ MAINT.CANCEL
+
+
+ VM.STOP
+ VOLUME.CREATE
+ MAINT.CANCEL.PS
+
+
+ VM.REBOOT
+ VOLUME.DELETE
+ MAINT.PREPARE
+
+
+ VM.UPGRADE
+ VOLUME.ATTACH
+ MAINT.PREPARE.PS
+
+
+ VM.RESETPASSWORD
+ VOLUME.DETACH
+ VPN.REMOTE.ACCESS.CREATE
+
+
+ ROUTER.CREATE
+ VOLUME.UPLOAD
+ VPN.USER.ADD
+
+
+ ROUTER.DESTROY
+ SERVICEOFFERING.CREATE
+ VPN.USER.REMOVE
+
+
+ ROUTER.START
+ SERVICEOFFERING.UPDATE
+ NETWORK.RESTART
+
+
+ ROUTER.STOP
+ SERVICEOFFERING.DELETE
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+ ROUTER.REBOOT
+ DOMAIN.CREATE
+ UPLOAD.CUSTOM.CERTIFICATE
+
+
+ ROUTER.HA
+ DOMAIN.DELETE
+ STATICNAT.DISABLE
+
+
+ PROXY.CREATE
+ DOMAIN.UPDATE
+ SSVM.CREATE
+
+
+ PROXY.DESTROY
+ SNAPSHOT.CREATE
+ SSVM.DESTROY
+
+
+ PROXY.START
+ SNAPSHOT.DELETE
+ SSVM.START
+
+
+ PROXY.STOP
+ SNAPSHOTPOLICY.CREATE
+ SSVM.STOP
+
+
+ PROXY.REBOOT
+ SNAPSHOTPOLICY.UPDATE
+ SSVM.REBOOT
+
+
+ PROXY.HA
+ SNAPSHOTPOLICY.DELETE
+ SSVM.H
+
+
+ VNC.CONNECT
+ VNC.DISCONNECT
+ NET.IPASSIGN
+
+
+ NET.IPRELEASE
+ NET.RULEADD
+ NET.RULEDELETE
+
+
+ NET.RULEMODIFY
+ NETWORK.CREATE
+ NETWORK.DELETE
+
+
+ LB.ASSIGN.TO.RULE
+ LB.REMOVE.FROM.RULE
+ LB.CREATE
+
+
+ LB.DELETE
+ LB.UPDATE
+ USER.LOGIN
+
+
+ USER.LOGOUT
+ USER.CREATE
+ USER.DELETE
+
+
+ USER.UPDATE
+ USER.DISABLE
+ TEMPLATE.CREATE
+
+
+ TEMPLATE.DELETE
+ TEMPLATE.UPDATE
+ TEMPLATE.COPY
+
+
+ TEMPLATE.DOWNLOAD.START
+ TEMPLATE.DOWNLOAD.SUCCESS
+ TEMPLATE.DOWNLOAD.FAILED
+
+
+ ISO.CREATE
+ ISO.DELETE
+ ISO.COPY
+
+
+ ISO.ATTACH
+ ISO.DETACH
+ ISO.EXTRACT
+
+
+ ISO.UPLOAD
+ SERVICE.OFFERING.CREATE
+ SERVICE.OFFERING.EDIT
+
+
+ SERVICE.OFFERING.DELETE
+ DISK.OFFERING.CREATE
+ DISK.OFFERING.EDIT
+
+
+ DISK.OFFERING.DELETE
+ NETWORK.OFFERING.CREATE
+ NETWORK.OFFERING.EDIT
+
+
+ NETWORK.OFFERING.DELETE
+ POD.CREATE
+ POD.EDIT
+
+
+ POD.DELETE
+ ZONE.CREATE
+ ZONE.EDIT
+
+
+ ZONE.DELETE
+ VLAN.IP.RANGE.CREATE
+ VLAN.IP.RANGE.DELETE
+
+
+ CONFIGURATION.VALUE.EDIT
+ SG.AUTH.INGRESS
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/events-log.xml b/docs/tmp/en-US/xml_tmp/events-log.xml
new file mode 100644
index 00000000000..9de679ea130
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/events-log.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Event Logs
+ There are two types of events logged in the &PRODUCT; 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..
+
diff --git a/docs/tmp/en-US/xml_tmp/events.xml b/docs/tmp/en-US/xml_tmp/events.xml
new file mode 100644
index 00000000000..9b6d75cfbba
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/events.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Events
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/example-LDAP-configuration-commands.xml b/docs/tmp/en-US/xml_tmp/example-LDAP-configuration-commands.xml
new file mode 100644
index 00000000000..e557386c3ca
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/example-LDAP-configuration-commands.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Example LDAP Configuration Commands
+ To understand the examples in this section, you need to know the basic concepts behind calling the &PRODUCT; API, which are explained in the Developer’s Guide.
+ The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
+ 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:
+ 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.
+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.
+
diff --git a/docs/tmp/en-US/xml_tmp/example-response-from-listUsageRecords.xml b/docs/tmp/en-US/xml_tmp/example-response-from-listUsageRecords.xml
new file mode 100644
index 00000000000..e0d79240e09
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/example-response-from-listUsageRecords.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Example response from listUsageRecords
+
+ All &PRODUCT; API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+
+
+ <listusagerecordsresponse>
+ <count>1816</count>
+ <usagerecord>
+ <account>user5</account>
+ <accountid>10004</accountid>
+ <domainid>1</domainid>
+ <zoneid>1</zoneid>
+ <description>i-3-4-WC running time (ServiceOffering: 1) (Template: 3)</description>
+ <usage>2.95288 Hrs</usage>
+ <usagetype>1</usagetype>
+ <rawusage>2.95288</rawusage>
+ <virtualmachineid>4</virtualmachineid>
+ <name>i-3-4-WC</name>
+ <offeringid>1</offeringid>
+ <templateid>3</templateid>
+ <usageid>245554</usageid>
+ <type>XenServer</type>
+ <startdate>2009-09-15T00:00:00-0700</startdate>
+ <enddate>2009-09-18T16:14:26-0700</enddate>
+ </usagerecord>
+
+ … (1,815 more usage records)
+ </listusagerecordsresponse>
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/export-template.xml b/docs/tmp/en-US/xml_tmp/export-template.xml
new file mode 100644
index 00000000000..c225e360344
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/export-template.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Exporting Templates
+ End users and Administrators may export templates from the &PRODUCT;. Navigate to the template in the UI and choose the Download function from the Actions menu.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/external-firewalls-and-load-balancers.xml b/docs/tmp/en-US/xml_tmp/external-firewalls-and-load-balancers.xml
new file mode 100644
index 00000000000..1452804885d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/external-firewalls-and-load-balancers.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ External Firewalls and Load Balancers
+ &PRODUCT; is capable of replacing its Virtual Router with an external Juniper SRX device and an optional external NetScaler or F5 load balancer for gateway and load balancing services. In this case, the VMs use the SRX as their gateway.
+
diff --git a/docs/tmp/en-US/xml_tmp/external-fw-topology-req.xml b/docs/tmp/en-US/xml_tmp/external-fw-topology-req.xml
new file mode 100644
index 00000000000..ab81496a30a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/external-fw-topology-req.xml
@@ -0,0 +1,25 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ External Firewall Topology Requirements
+ When external firewall integration is in place, the public IP VLAN must still be trunked to
+ the Hosts. This is required to support the Secondary Storage VM and Console Proxy VM.
+
diff --git a/docs/tmp/en-US/xml_tmp/external-guest-firewall-integration.xml b/docs/tmp/en-US/xml_tmp/external-guest-firewall-integration.xml
new file mode 100644
index 00000000000..0b34dca1065
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/external-guest-firewall-integration.xml
@@ -0,0 +1,201 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ External Guest Firewall Integration for Juniper SRX (Optional)
+
+ Available only for guests using advanced networking.
+
+ &PRODUCT; provides for direct management of the Juniper SRX series of firewalls. This
+ enables &PRODUCT; to establish static NAT mappings from public IPs to guest VMs, and to use
+ the Juniper device in place of the virtual router for firewall services. You can have one or
+ more Juniper SRX per zone. This feature is optional. If Juniper integration is not provisioned,
+ &PRODUCT; will use the virtual router for these services.
+ The Juniper SRX can optionally be used in conjunction with an external load balancer.
+ External Network elements can be deployed in a side-by-side or inline configuration.
+
+
+
+
+
+ parallel-mode.png: adding a firewall and load balancer in parallel mode.
+
+
+ &PRODUCT; requires the Juniper to be configured as follows:
+
+ Supported SRX software version is 10.3 or higher.
+
+
+
+ Install your SRX appliance according to the vendor's instructions.
+
+
+ Connect one interface to the management network and one interface to the public network.
+ Alternatively, you can connect the same interface to both networks and a use a VLAN for the
+ public network.
+
+
+ Make sure "vlan-tagging" is enabled on the private interface.
+
+
+ Record the public and private interface names. If you used a VLAN for the public
+ interface, add a ".[VLAN TAG]" after the interface name. For example, if you are using
+ ge-0/0/3 for your public interface and VLAN tag 301, your public interface name would be
+ "ge-0/0/3.301". Your private interface name should always be untagged because the
+ &PRODUCT; software automatically creates tagged logical interfaces.
+
+
+ Create a public security zone and a private security zone. By default, these will
+ already exist and will be called "untrust" and "trust". Add the public interface to the
+ public zone and the private interface to the private zone. Note down the security zone
+ names.
+
+
+ Make sure there is a security policy from the private zone to the public zone that
+ allows all traffic.
+
+
+ Note the username and password of the account you want the &PRODUCT; software to log
+ in to when it is programming rules.
+
+
+ Make sure the "ssh" and "xnm-clear-text" system services are enabled.
+
+
+ If traffic metering is desired:
+
+
+ a. Create an incoming firewall filter and an outgoing firewall filter. These filters
+ should be the same names as your public security zone name and private security zone
+ name respectively. The filters should be set to be "interface-specific". For example,
+ here is the configuration where the public zone is "untrust" and the private zone is
+ "trust":
+ root@cloud-srx# show firewall
+filter trust {
+ interface-specific;
+}
+filter untrust {
+ interface-specific;
+}
+
+
+ Add the firewall filters to your public interface. For example, a sample
+ configuration output (for public interface ge-0/0/3.0, public security zone untrust, and
+ private security zone trust) is:
+ ge-0/0/3 {
+ unit 0 {
+ family inet {
+ filter {
+ input untrust;
+ output trust;
+ }
+ address 172.25.0.252/16;
+ }
+ }
+}
+
+
+
+
+ Make sure all VLANs are brought to the private interface of the SRX.
+
+
+ After the &PRODUCT; Management Server is installed, log in to the &PRODUCT; UI as
+ administrator.
+
+
+ In the left navigation bar, click Infrastructure.
+
+
+ In Zones, click View More.
+
+
+ Choose the zone you want to work with.
+
+
+ Click the Network tab.
+
+
+ In the Network Service Providers node of the diagram, click Configure. (You might have
+ to scroll down to see this.)
+
+
+ Click SRX.
+
+
+ Click the Add New SRX button (+) and provide the following:
+
+
+ IP Address: The IP address of the SRX.
+
+
+ Username: The user name of the account on the SRX that &PRODUCT; should use.
+
+
+ Password: The password of the account.
+
+
+ Public Interface. The name of the public interface on the SRX. For example,
+ ge-0/0/2. A ".x" at the end of the interface indicates the VLAN that is in use.
+
+
+ Private Interface: The name of the private interface on the SRX. For example,
+ ge-0/0/1.
+
+
+ Usage Interface: (Optional) Typically, the public interface is used to meter
+ traffic. If you want to use a different interface, specify its name here
+
+
+ Number of Retries: The number of times to attempt a command on the SRX before
+ failing. The default value is 2.
+
+
+ Timeout (seconds): The time to wait for a command on the SRX before considering it
+ failed. Default is 300 seconds.
+
+
+ Public Network: The name of the public network on the SRX. For example,
+ trust.
+
+
+ Private Network: The name of the private network on the SRX. For example,
+ untrust.
+
+
+ Capacity: The number of networks the device can handle
+
+
+ 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
+
+
+
+
+ Click OK.
+
+
+ Click Global Settings. Set the parameter external.network.stats.interval to indicate how
+ often you want &PRODUCT; to fetch network usage statistics from the Juniper SRX. If you
+ are not using the SRX to gather network usage statistics, set to 0.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/external-guest-lb-integration.xml b/docs/tmp/en-US/xml_tmp/external-guest-lb-integration.xml
new file mode 100644
index 00000000000..5760f9559e6
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/external-guest-lb-integration.xml
@@ -0,0 +1,109 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ External Guest Load Balancer Integration (Optional)
+ &PRODUCT; can optionally use a Citrix NetScaler or BigIP F5 load balancer to provide load
+ balancing services to guests. If this is not enabled, &PRODUCT; will use the software load
+ balancer in the virtual router.
+ To install and enable an external load balancer for &PRODUCT; management:
+
+
+ Set up the appliance according to the vendor's directions.
+
+
+ Connect it to the networks carrying public traffic and management traffic (these could
+ be the same network).
+
+
+ Record the IP address, username, password, public interface name, and private interface
+ name. The interface names will be something like "1.1" or "1.2".
+
+
+ Make sure that the VLANs are trunked to the management network interface.
+
+
+ After the &PRODUCT; Management Server is installed, log in as administrator to the
+ &PRODUCT; UI.
+
+
+ In the left navigation bar, click Infrastructure.
+
+
+ In Zones, click View More.
+
+
+ Choose the zone you want to work with.
+
+
+ Click the Network tab.
+
+
+ In the Network Service Providers node of the diagram, click Configure. (You might have
+ to scroll down to see this.)
+
+
+ Click NetScaler or F5.
+
+
+ Click the Add button (+) and provide the following:
+ For NetScaler:
+
+
+ IP Address: The IP address of the SRX.
+
+
+ Username/Password: The authentication credentials to access the device. &PRODUCT;
+ uses these credentials to access the device.
+
+
+ Type: The type of device that is being added. It could be F5 Big Ip Load Balancer,
+ NetScaler VPX, NetScaler MPX, or NetScaler SDX. For a comparison of the NetScaler types,
+ see the &PRODUCT; Administration Guide.
+
+
+ Public interface: Interface of device that is configured to be part of the public
+ network.
+
+
+ Private interface: Interface of device 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: The number of networks the device can handle.
+
+
+ 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.
+
+
+
+
+ Click OK.
+
+
+ The installation and provisioning of the external load balancer is finished. You can proceed
+ to add VMs and NAT or load balancing rules.
+
diff --git a/docs/tmp/en-US/xml_tmp/extracting-source.xml b/docs/tmp/en-US/xml_tmp/extracting-source.xml
new file mode 100644
index 00000000000..97a40b66213
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/extracting-source.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Extracting source
+
+ Extracting the &PRODUCT; release is relatively simple and can be done
+ with a single command as follows:
+ $tar -jxvf apache-cloudstack-4.0.0-incubating-src.tar.bz2
+
+
+ You can now move into the directory:
+ $cd ./apache-cloudstack-4.0.0-incubating-src
+
+
diff --git a/docs/tmp/en-US/xml_tmp/feature-overview.xml b/docs/tmp/en-US/xml_tmp/feature-overview.xml
new file mode 100644
index 00000000000..501bca88c2f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/feature-overview.xml
@@ -0,0 +1,82 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ What Can &PRODUCT; Do?
+
+ Multiple Hypervisor Support
+
+
+ &PRODUCT; works with a variety of hypervisors, and a single cloud deployment can contain multiple hypervisor implementations. The current release of &PRODUCT; supports pre-packaged enterprise solutions like Citrix XenServer and VMware vSphere, as well as KVM or Xen running on Ubuntu or CentOS.
+
+
+ Massively Scalable Infrastructure Management
+
+
+ &PRODUCT; can manage tens of thousands of servers installed in multiple geographically distributed datacenters. The centralized management server scales linearly, eliminating the need for intermediate cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic maintenance of the management server can be performed without affecting the functioning of virtual machines running in the cloud.
+
+
+ Automatic Configuration Management
+
+ &PRODUCT; automatically configures each guest virtual machine’s networking and storage settings.
+
+ &PRODUCT; internally manages a pool of virtual appliances to support the cloud itself. These appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage access, and storage replication. The extensive use of virtual appliances simplifies the installation, configuration, and ongoing management of a cloud deployment.
+
+
+ Graphical User Interface
+
+ &PRODUCT; offers an administrator's Web interface, used for provisioning and managing the cloud, as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI can be customized to reflect the desired service provider or enterprise look and feel.
+
+
+ API and Extensibility
+
+
+ &PRODUCT; provides an API that gives programmatic access to all the
+ management features available in the UI. The API is maintained and
+ documented. This API enables the creation of command line tools and
+ new user interfaces to suit particular needs. See the Developer’s
+ Guide and API Reference, both available at
+ Apache CloudStack Guides
+ and
+ Apache CloudStack API Reference
+ respectively.
+
+
+ The &PRODUCT; pluggable allocation architecture allows the creation
+ of new types of allocators for the selection of storage and Hosts.
+ See the Allocator Implementation Guide
+ (http://docs.cloudstack.org/CloudStack_Documentation/Allocator_Implementation_Guide).
+
+
+ High Availability
+
+
+ &PRODUCT; has a number of features to increase the availability of the
+ system. The Management Server itself may be deployed in a multi-node
+ installation where the servers are load balanced. MySQL may be configured
+ to use replication to provide for a manual failover in the event of
+ database loss. For the hosts, &PRODUCT; supports NIC bonding and the use
+ of separate networks for storage as well as iSCSI Multipath.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/firewall-rules.xml b/docs/tmp/en-US/xml_tmp/firewall-rules.xml
new file mode 100644
index 00000000000..388bf7e2885
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/firewall-rules.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Firewall Rules
+ By default, all incoming traffic to the public IP address is rejected by the firewall. To allow external traffic, you can open firewall ports by specifying firewall rules. You can optionally specify one or more CIDRs to filter the source IPs. This is useful when you want to allow only incoming requests from certain IP addresses.
+ You cannot use firewall rules to open ports for an elastic IP address. When elastic IP is used, outside access is instead controlled through the use of security groups. See .
+ Firewall rules can be created using the Firewall tab in the Management Server UI. This tab is not displayed by default when &PRODUCT; is installed. To display the Firewall tab, the &PRODUCT; administrator must set the global configuration parameter firewall.rule.ui.enabled to "true."
+ To create a firewall rule:
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+ In the left navigation, choose Network.
+ Click the name of the network where you want to work with.
+ Click View IP Addresses.
+ Click the IP address you want to work with.
+
+ Click the Configuration tab and fill in the following values.
+
+ Source CIDR. (Optional) To accept only traffic from IP
+ addresses within a particular address block, enter a CIDR or a
+ comma-separated list of CIDRs. Example: 192.168.0.0/22. Leave empty to allow
+ all CIDRs.
+ Protocol. The communication protocol in use on the opened
+ port(s).
+ Start Port and End Port. The port(s) you want to open on the
+ firewall. If you are opening a single port, use the same number in both
+ fields
+ ICMP Type and ICMP Code. Used only if Protocol is set to
+ ICMP. Provide the type and code required by the ICMP protocol to fill out
+ the ICMP header. Refer to ICMP documentation for more details if you are not
+ sure what to enter
+
+ Click Add
+
+
diff --git a/docs/tmp/en-US/xml_tmp/first_ms_node_install.xml b/docs/tmp/en-US/xml_tmp/first_ms_node_install.xml
new file mode 100644
index 00000000000..3c3e51acca1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/first_ms_node_install.xml
@@ -0,0 +1,57 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Install the First Management Server
+
+
+
+ Ensure you have configured your machine according to
+
+ or
+
+ as appropriate for your platform.
+
+
+
+
+ Install the &PRODUCT; management server packages by
+ issuing one of the following commands as appropriate:
+ #yum install cloud-client
+ #apt-get install cloud-client
+
+
+
+
+ (RPM-based distributions) When the installation is
+ finished, run the following commands to start essential
+ services:
+ #service rpcbind start
+#service nfs start
+#chkconfig nfs on
+#chkconfig rpcbind on
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/generic-firewall-provisions.xml b/docs/tmp/en-US/xml_tmp/generic-firewall-provisions.xml
new file mode 100644
index 00000000000..53ae45a09e0
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/generic-firewall-provisions.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Generic Firewall Provisions
+ The hardware firewall is required to serve two purposes:
+
+
+ Protect the Management Servers. NAT and port forwarding should be configured to direct
+ traffic from the public Internet to the Management Servers.
+
+
+ Route management network traffic between multiple zones. Site-to-site VPN should be
+ configured between multiple zones.
+
+
+ To achieve the above purposes you must set up fixed configurations for the firewall.
+ Firewall rules and policies need not change as users are provisioned into the cloud. Any brand
+ of hardware firewall that supports NAT and site-to-site VPN can be used.
+
diff --git a/docs/tmp/en-US/xml_tmp/getting-release.xml b/docs/tmp/en-US/xml_tmp/getting-release.xml
new file mode 100644
index 00000000000..09f0a7b08fe
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/getting-release.xml
@@ -0,0 +1,63 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Getting the release
+
+ You can download the latest &PRODUCT; release from the
+
+ Apache CloudStack project download page.
+
+
+ You'll notice several links under the 'Latest release' section.
+
+
+
+
+
+ apache-cloudstack-4.0.0-incubating-src.tar.bz2
+ - This is the link to the release itself.
+
+
+
+
+ PGP
+ - This is a detached cryptographic signature that can be used to help
+ verify the authenticity of the release.
+
+
+
+
+ MD5
+ - An MD5 hash of the release to aid in verify the validity of the release download.
+
+
+
+
+ SHA512
+ - A SHA512 hash of the release to aid in verify the validity of the release download.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/global-config.xml b/docs/tmp/en-US/xml_tmp/global-config.xml
new file mode 100644
index 00000000000..2f6ad105c0d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/global-config.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Setting Global Configuration Parameters
+ &PRODUCT; provides parameters that you can set to control many aspects of the cloud. When
+ &PRODUCT; is first installed, and periodically thereafter, you might need to modify these
+ settings.
+
+
+ Log in to the UI as administrator.
+
+
+ In the left navigation bar, click Global Settings.
+
+
+ In Select View, choose one of the following:
+
+
+ Global Settings. This displays a list of the parameters with brief descriptions and
+ current values.
+
+
+ Hypervisor Capabilities. This displays a list of hypervisor versions with the
+ maximum number of guests supported for each.
+
+
+
+
+ Use the search box to narrow down the list to those you are interested in.
+
+
+ Click the Edit icon to modify a value. If you are viewing Hypervisor Capabilities, you
+ must click the name of the hypervisor first to display the editing screen.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/globally-configured-limit.xml b/docs/tmp/en-US/xml_tmp/globally-configured-limit.xml
new file mode 100644
index 00000000000..ac71112b310
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/globally-configured-limit.xml
@@ -0,0 +1,100 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Globally Configured Limits
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+ The following table lists limits set in the Global Configuration:
+
+
+
+
+ Parameter Name
+ Definition
+
+
+
+
+
+ max.account.public.ips
+ Number of public IP addresses that can be owned by an account
+
+
+
+ max.account.snapshots
+ Number of snapshots that can exist for an account
+
+
+
+
+ max.account.templates
+ Number of templates that can exist for an account
+
+
+
+ max.account.user.vms
+ Number of virtual machine instances that can exist for an account
+
+
+
+ max.account.volumes
+ Number of disk volumes that can exist for an account
+
+
+
+ max.template.iso.size
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+ max.volume.size.gb
+ Maximum size for a volume in GB
+
+
+ network.throttling.rate
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+ snapshot.max.hourly
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+ snapshot.max.daily
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+ snapshot.max.weekly
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+ snapshot.max.monthly
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+
+
+ To modify global configuration parameters, use the global configuration screen in the &PRODUCT; UI. See Setting Global Configuration Parameters
+
diff --git a/docs/tmp/en-US/xml_tmp/globally-configured-limits.xml b/docs/tmp/en-US/xml_tmp/globally-configured-limits.xml
new file mode 100644
index 00000000000..48a91f1b01e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/globally-configured-limits.xml
@@ -0,0 +1,100 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Globally Configured Limits
+ In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network to 254 running instances. It can be adjusted as needed, but this must be done before any instances are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
+ The following table lists limits set in the Global Configuration:
+
+
+
+
+ Parameter Name
+ Definition
+
+
+
+
+
+ max.account.public.ips
+ Number of public IP addresses that can be owned by an account
+
+
+
+ max.account.snapshots
+ Number of snapshots that can exist for an account
+
+
+
+
+ max.account.templates
+ Number of templates that can exist for an account
+
+
+
+ max.account.user.vms
+ Number of virtual machine instances that can exist for an account
+
+
+
+ max.account.volumes
+ Number of disk volumes that can exist for an account
+
+
+
+ max.template.iso.size
+ Maximum size for a downloaded template or ISO in GB
+
+
+
+ max.volume.size.gb
+ Maximum size for a volume in GB
+
+
+ network.throttling.rate
+ Default data transfer rate in megabits per second allowed per user (supported on XenServer)
+
+
+ snapshot.max.hourly
+ Maximum recurring hourly snapshots to be retained for a volume. If the limit is reached, early snapshots from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring hourly snapshots can not be scheduled
+
+
+
+ snapshot.max.daily
+ Maximum recurring daily snapshots to be retained for a volume. If the limit is reached, snapshots from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring daily snapshots can not be scheduled
+
+
+ snapshot.max.weekly
+ Maximum recurring weekly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring weekly snapshots can not be scheduled
+
+
+
+ snapshot.max.monthly
+ Maximum recurring monthly snapshots to be retained for a volume. If the limit is reached, snapshots from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual snapshots. If set to 0, recurring monthly snapshots can not be scheduled.
+
+
+
+
+ To modify global configuration parameters, use the global configuration screen in the &PRODUCT; UI. See Setting Global Configuration Parameters
+
diff --git a/docs/tmp/en-US/xml_tmp/guest-ip-ranges.xml b/docs/tmp/en-US/xml_tmp/guest-ip-ranges.xml
new file mode 100644
index 00000000000..1f8c8a1a4b1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/guest-ip-ranges.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Guest IP Ranges
+ The IP ranges for guest network traffic are set on a per-account basis by the user. This allows the users to configure their network in a fashion that will enable VPN linking between their guest network and their clients.
+
diff --git a/docs/tmp/en-US/xml_tmp/guest-network.xml b/docs/tmp/en-US/xml_tmp/guest-network.xml
new file mode 100644
index 00000000000..692eb29f525
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/guest-network.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Guest Network
+ In a &PRODUCT; cloud, guest VMs can communicate with each other using shared infrastructure with the security and user perception that the guests have a private LAN.
+ The &PRODUCT; virtual router is the main component providing networking features for guest traffic.
+
diff --git a/docs/tmp/en-US/xml_tmp/guest-nw-usage-with-traffic-sentinel.xml b/docs/tmp/en-US/xml_tmp/guest-nw-usage-with-traffic-sentinel.xml
new file mode 100644
index 00000000000..eb42d641c4b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/guest-nw-usage-with-traffic-sentinel.xml
@@ -0,0 +1,73 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Guest Network Usage Integration for Traffic Sentinel
+ To collect usage data for a guest network, &PRODUCT; needs to pull the data from an external
+ network statistics collector installed on the network. Metering statistics for guest networks
+ are available through &PRODUCT;’s integration with inMon Traffic Sentinel.
+ Traffic Sentinel is a network traffic usage data collection package. &PRODUCT; can feed
+ statistics from Traffic Sentinel into its own usage records, providing a basis for billing users
+ of cloud infrastructure. Traffic Sentinel uses the traffic monitoring protocol sFlow. Routers
+ and switches generate sFlow records and provide them for collection by Traffic Sentinel, then
+ &PRODUCT; queries the Traffic Sentinel database to obtain this information
+ To construct the query, &PRODUCT; determines what guest IPs were in use during the current
+ query interval. This includes both newly assigned IPs and IPs that were assigned in a previous
+ time period and continued to be in use. &PRODUCT; queries Traffic Sentinel for network
+ statistics that apply to these IPs during the time period they remained allocated in &PRODUCT;.
+ The returned data is correlated with the customer account that owned each IP and the timestamps
+ when IPs were assigned and released in order to create billable metering records in &PRODUCT;.
+ When the Usage Server runs, it collects this data.
+ To set up the integration between &PRODUCT; and Traffic Sentinel:
+
+
+ On your network infrastructure, install Traffic Sentinel and configure it to gather
+ traffic data. For installation and configuration steps, see inMon documentation at Traffic Sentinel Documentation.
+
+
+ In the Traffic Sentinel UI, configure Traffic Sentinel to accept script querying from
+ guest users. &PRODUCT; will be the guest user performing the remote queries to gather
+ network usage for one or more IP addresses.
+ Click File > Users > Access Control > Reports Query, then select Guest from the
+ drop-down list.
+
+
+ On &PRODUCT;, add the Traffic Sentinel host by calling the &PRODUCT; API command
+ addTrafficMonitor. Pass in the URL of the Traffic Sentinel as protocol + host + port
+ (optional); for example, http://10.147.28.100:8080. For the addTrafficMonitor command
+ syntax, see the API Reference at API
+ Documentation.
+ For information about how to call the &PRODUCT; API, see the Developer’s Guide at
+ CloudStack API Developer's Guide.
+
+
+ Log in to the &PRODUCT; UI as administrator.
+
+
+ Select Configuration from the Global Settings page, and set the following:
+ direct.network.stats.interval: How often you want &PRODUCT; to query Traffic
+ Sentinel.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/guest-traffic.xml b/docs/tmp/en-US/xml_tmp/guest-traffic.xml
new file mode 100644
index 00000000000..96f9c062db8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/guest-traffic.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Guest Traffic
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+ Figure 1 illustrates a typical guest traffic setup:
+
+
+
+
+ guesttraffic.png: Depicts a guest traffic setup
+
+ The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+ The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
+ Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
+
diff --git a/docs/tmp/en-US/xml_tmp/ha-enabled-vm.xml b/docs/tmp/en-US/xml_tmp/ha-enabled-vm.xml
new file mode 100644
index 00000000000..19666a4db27
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ha-enabled-vm.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ HA-Enabled Virtual Machines
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, &PRODUCT; detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. &PRODUCT; has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
diff --git a/docs/tmp/en-US/xml_tmp/ha-for-hosts.xml b/docs/tmp/en-US/xml_tmp/ha-for-hosts.xml
new file mode 100644
index 00000000000..e395d22e58a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ha-for-hosts.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ HA for Hosts
+ The user can specify a virtual machine as HA-enabled. By default, all virtual router VMs and Elastic Load Balancing VMs are automatically configured as HA-enabled. When an HA-enabled VM crashes, &PRODUCT; detects the crash and restarts the VM automatically within the same Availability Zone. HA is never performed across different Availability Zones. &PRODUCT; has a conservative policy towards restarting VMs and ensures that there will never be two instances of the same VM running at the same time. The Management Server attempts to start the VM on another Host in the same cluster.
+ HA features work with iSCSI or NFS primary storage. HA with local storage is not supported.
+
diff --git a/docs/tmp/en-US/xml_tmp/ha-management-server.xml b/docs/tmp/en-US/xml_tmp/ha-management-server.xml
new file mode 100644
index 00000000000..1afebce3bf3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ha-management-server.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ HA for Management Server
+ The &PRODUCT; Management Server should be deployed in a multi-node configuration such that it is not susceptible to individual server failures. The Management Server itself (as distinct from the MySQL database) is stateless and may be placed behind a load balancer.
+ Normal operation of Hosts is not impacted by an outage of all Management Serves. All guest VMs will continue to work.
+ When the Management Server is down, no new VMs can be created, and the end user and admin UI, API, dynamic load distribution, and HA will cease to work.
+
diff --git a/docs/tmp/en-US/xml_tmp/hardware-config-eg.xml b/docs/tmp/en-US/xml_tmp/hardware-config-eg.xml
new file mode 100644
index 00000000000..3174bfa8576
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hardware-config-eg.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Example Hardware Configuration
+ This section contains an example configuration of specific switch models for zone-level
+ layer-3 switching. It assumes VLAN management protocols, such as VTP or GVRP, have been
+ disabled. The example scripts must be changed appropriately if you choose to use VTP or
+ GVRP.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/hardware-firewall.xml b/docs/tmp/en-US/xml_tmp/hardware-firewall.xml
new file mode 100644
index 00000000000..df0568aa2c2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hardware-firewall.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Hardware Firewall
+ All deployments should have a firewall protecting the management server; see Generic
+ Firewall Provisions. Optionally, some deployments may also have a Juniper SRX firewall that will
+ be the default gateway for the guest networks; see .
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/host-add-vsphere.xml b/docs/tmp/en-US/xml_tmp/host-add-vsphere.xml
new file mode 100644
index 00000000000..b47846448d7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/host-add-vsphere.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Adding a Host (vSphere)
+ For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the entire cluster to &PRODUCT;. See Add Cluster: vSphere.
+
diff --git a/docs/tmp/en-US/xml_tmp/host-add-xenserver-kvm-ovm.xml b/docs/tmp/en-US/xml_tmp/host-add-xenserver-kvm-ovm.xml
new file mode 100644
index 00000000000..4bbeefcbed4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/host-add-xenserver-kvm-ovm.xml
@@ -0,0 +1,152 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ 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
+
+ Make sure the hypervisor host does not have any VMs already running before you add it to
+ &PRODUCT;.
+
+ 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
+ &PRODUCT; 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.
+ # xe pool-join master-address=[master IP] master-username=root master-password=[your password]
+
+ 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/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the
+ master host and ensure it is executable.
+
+
+ Run the script:
+ # ./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.
+
+
+
+
+
+
+ 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 &PRODUCT;
+ and what additional configuration is required to ensure the host will work with &PRODUCT;.
+ To find these installation details, see the appropriate section for your hypervisor in the
+ &PRODUCT; Installation Guide.
+
+
+ Log in to the &PRODUCT; 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 delay while the host is provisioned. It should automatically
+ display in the UI.
+
+
+ Repeat for additional hosts.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/host-add.xml b/docs/tmp/en-US/xml_tmp/host-add.xml
new file mode 100644
index 00000000000..74509d69be7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/host-add.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Adding a Host
+
+ Before adding a host to the &PRODUCT; configuration, you must first install your chosen hypervisor on the host. &PRODUCT; can manage hosts running VMs under a variety of hypervisors.
+ The &PRODUCT; Installation Guide provides instructions on how to install each supported hypervisor
+ and configure it for use with &PRODUCT;. 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 &PRODUCT;.
+ Be sure you have performed the additional &PRODUCT;-specific configuration steps described in the hypervisor installation section for your particular hypervisor.
+
+ Now add the hypervisor host to &PRODUCT;. The technique to use varies depending on the hypervisor.
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/host-allocation.xml b/docs/tmp/en-US/xml_tmp/host-allocation.xml
new file mode 100644
index 00000000000..8a362e6e99c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/host-allocation.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Host Allocation
+ The system automatically picks the most appropriate host to run each virtual machine. End users may specify the zone in which the virtual machine will be created. End users do not have control over which host will run the virtual machine instance.
+ &PRODUCT; administrators can specify that certain hosts should have a preference for particular types of guest instances. For example, an administrator could state that a host should have a preference to run Windows guests. The default host allocator will attempt to place guests of that OS type on such hosts first. If no such host is available, the allocator will place the instance wherever there is sufficient physical capacity.
+ Both vertical and horizontal allocation is allowed. Vertical allocation consumes all the resources of a given host before allocating any guests on a second host. This reduces power consumption in the cloud. Horizontal allocation places a guest on each host in a round-robin fashion. This may yield better performance to the guests in some cases. &PRODUCT; also allows an element of CPU over-provisioning as configured by the administrator. Over-provisioning allows the administrator to commit more CPU cycles to the allocated guests than are actually available from the hardware.
+ &PRODUCT; also provides a pluggable interface for adding new allocators. These custom allocators can provide any policy the administrator desires.
+
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-host-install-agent.xml b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-agent.xml
new file mode 100644
index 00000000000..e5bfa37fb6d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-agent.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Install and configure the Agent
+ To manage KVM instances on the host &PRODUCT; uses a Agent. This Agent communicates with the Management server and controls all the instances on the host.
+ First we start by installing the agent:
+ In RHEL or CentOS:
+ $ yum install cloud-agent
+ In Ubuntu:
+ $ apt-get install cloud-agent
+ The host is now ready to be added to a cluster. This is covered in a later section, see . It is recommended that you continue to read the documentation before adding the host!
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-host-install-finish.xml b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-finish.xml
new file mode 100644
index 00000000000..ff530c79038
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-finish.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Add the host to CloudStack
+ The host is now ready to be added to a cluster. This is covered in a later section, see . It is recommended that you continue to read the documentation before adding the host!
+
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-host-install-firewall.xml b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-firewall.xml
new file mode 100644
index 00000000000..ae82fc47afa
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-firewall.xml
@@ -0,0 +1,59 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configuring the firewall
+ The hypervisor needs to be able to communicate with other hypervisors and the management server needs to be able to reach the hypervisor.
+ In order to do so we have to open the following TCP ports (if you are using a firewall):
+
+ 22 (SSH)
+ 1798
+ 16509 (libvirt)
+ 5900 - 6100 (VNC consoles)
+ 49152 - 49216 (libvirt live migration)
+
+ It depends on the firewall you are using how to open these ports. Below you'll find examples how to open these ports in RHEL/CentOS and Ubuntu.
+
+ Open ports in RHEL/CentOS
+ RHEL and CentOS use iptables for firewalling the system, you can open extra ports by executing the following iptable commands:
+ $ iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT
+ $ iptables -I INPUT -p tcp -m tcp --dport 1798 -j ACCEPT
+ $ iptables -I INPUT -p tcp -m tcp --dport 16509 -j ACCEPT
+ $ iptables -I INPUT -p tcp -m tcp --dport 5900:6100 -j ACCEPT
+ $ iptables -I INPUT -p tcp -m tcp --dport 49152:49216 -j ACCEPT
+ These iptable settings are not persistent accross reboots, we have to save them first.
+ $ iptables-save > /etc/sysconfig/iptables
+
+
+ Open ports in Ubuntu
+ The default firewall under Ubuntu is UFW (Uncomplicated FireWall), which is a Python wrapper around iptables.
+ To open the required ports, execute the following commands:
+ $ ufw allow proto tcp from any to any port 22
+ $ ufw allow proto tcp from any to any port 1798
+ $ ufw allow proto tcp from any to any port 16509
+ $ ufw allow proto tcp from any to any port 5900:6100
+ $ ufw allow proto tcp from any to any port 49152:49216
+ By default UFW is not enabled on Ubuntu. Executing these commands with the firewall disabled does not enable the firewall.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-host-install-flow.xml b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-flow.xml
new file mode 100644
index 00000000000..5badfde8888
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-flow.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Hypervisor Host installation
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-host-install-libvirt.xml b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-libvirt.xml
new file mode 100644
index 00000000000..34e66783600
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-libvirt.xml
@@ -0,0 +1,57 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Install and Configure libvirt
+ &PRODUCT; uses libvirt for managing virtual machines. Therefore it is vital that libvirt is configured correctly. Libvirt is a dependency of cloud-agent and should already be installed.
+
+
+ In order to have live migration working libvirt has to listen for unsecured TCP connections. We also need to turn off libvirts attempt to use Multicast DNS advertising. Both of these settings are in /etc/libvirt/libvirtd.conf
+ Set the following paramaters:
+ listen_tls = 0
+ listen_tcp = 1
+ tcp_port = 16059
+ auth_tcp = "none"
+ mdns_adv = 0
+
+
+ Turning on "listen_tcp" in libvirtd.conf is not enough, we have to change the parameters as well:
+ On RHEL or CentOS modify /etc/sysconfig/libvirtd:
+ Uncomment the following line:
+ #LIBVIRTD_ARGS="--listen"
+ On Ubuntu: modify /etc/init/libvirt-bin.conf
+ Change the following line (at the end of the file):
+ exec /usr/sbin/libvirtd -d
+ to (just add -l)
+ exec /usr/sbin/libvirtd -d -l
+
+
+ Restart libvirt
+ In RHEL or CentOS:
+ $ service libvirtd restart
+ In Ubuntu:
+ $ service libvirt-bin restart
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-host-install-network.xml b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-network.xml
new file mode 100644
index 00000000000..8f6a10cdd69
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-network.xml
@@ -0,0 +1,149 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configure the network bridges
+ This is a very important section, please make sure you read this thoroughly.
+ In order to forward traffic to your instances you will need at least two bridges: public and private.
+ By default these bridges are called cloudbr0 and cloudbr1, but you do have to make sure they are available on each hypervisor.
+ The most important factor is that you keep the configuration consistent on all your hypervisors.
+
+ Network example
+ There are many ways to configure your network. In the Basic networking mode you should have two (V)LAN's, one for your private network and one for the public network.
+ We assume that the hypervisor has one NIC (eth0) with three tagged VLAN's:
+
+ VLAN 100 for management of the hypervisor
+ VLAN 200 for public network of the instances (cloudbr0)
+ VLAN 300 for private network of the instances (cloudbr1)
+
+ On VLAN 100 we give the Hypervisor the IP-Address 192.168.42.11/24 with the gateway 192.168.42.1
+ The Hypervisor and Management server don't have to be in the same subnet!
+
+
+ Configuring the network bridges
+ It depends on the distribution you are using how to configure these, below you'll find examples for RHEL/CentOS and Ubuntu.
+ The goal is to have two bridges called 'cloudbr0' and 'cloudbr1' after this section. This should be used as a guideline only. The exact configuration will depend on your network layout.
+
+ Configure in RHEL or CentOS
+ The required packages were installed when libvirt was installed, we can proceed to configuring the network.
+ First we configure eth0
+ vi /etc/sysconfig/network-scripts/ifcfg-eth0
+ Make sure it looks similair to:
+
+ We now have to configure the three VLAN interfaces:
+ vi /etc/sysconfig/network-scripts/ifcfg-eth0.100
+
+ vi /etc/sysconfig/network-scripts/ifcfg-eth0.200
+
+ vi /etc/sysconfig/network-scripts/ifcfg-eth0.300
+
+ Now we have the VLAN interfaces configured we can add the bridges on top of them.
+ vi /etc/sysconfig/network-scripts/ifcfg-cloudbr0
+ Now we just configure it is a plain bridge without an IP-Adress
+
+ We do the same for cloudbr1
+ vi /etc/sysconfig/network-scripts/ifcfg-cloudbr1
+
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+
+
+ Configure in Ubuntu
+ All the required packages were installed when you installed libvirt, so we only have to configure the network.
+ vi /etc/network/interfaces
+ Modify the interfaces file to look like this:
+
+ With this configuration you should be able to restart the network, although a reboot is recommended to see if everything works properly.
+ Make sure you have an alternative way like IPMI or ILO to reach the machine in case you made a configuration error and the network stops functioning!
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-host-install-overview.xml b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-overview.xml
new file mode 100644
index 00000000000..716b43ddf91
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-overview.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ KVM Installation Overview
+ If you want to use the Linux Kernel Virtual Machine (KVM) hypervisor to run guest virtual machines, install KVM on the host(s) in your cloud. The material in this section doesn't duplicate KVM installation docs. It provides the &PRODUCT;-specific steps that are needed to prepare a KVM host to work with &PRODUCT;.
+ Before continuing, make sure that you have applied the latest updates to your host.
+ It is NOT recommended to run services on this host not controlled by &PRODUCT;.
+ The procedure for installing a KVM Hypervisor Host is:
+
+ Prepare the Operating System
+ Install and configure libvirt
+ Configure Security Policies (AppArmor and SELinux)
+ Install and configure the Agent
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-host-install-prepare-os.xml b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-prepare-os.xml
new file mode 100644
index 00000000000..44852f21c2d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-prepare-os.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Prepare the Operating System
+ The OS of the Host must be prepared to host the &PRODUCT; Agent and run KVM instances.
+
+ Log in to your OS as root.
+
+ Check for a fully qualified hostname.
+ $ hostname --fqdn
+ This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+
+ Make sure that the machine can reach the Internet.
+ $ ping www.cloudstack.org
+
+
+ Turn on NTP for time synchronization.
+ NTP is required to synchronize the clocks of the servers in your cloud. Unsynchronized clocks can cause unexpected problems.
+
+ Install NTP
+ On RHEL or CentOS:
+ $ yum install ntp
+ On Ubuntu:
+ $ apt-get install openntpd
+
+
+
+ Repeat all of these steps on every hypervisor host.
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-host-install-security-policies.xml b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-security-policies.xml
new file mode 100644
index 00000000000..03da04b6eb3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-host-install-security-policies.xml
@@ -0,0 +1,70 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configure the Security Policies
+ &PRODUCT; does various things which can be blocked by security mechanisms like AppArmor and SELinux. These have to be disabled to ensure the Agent has all the required permissions.
+
+
+ Configure SELinux (RHEL and CentOS)
+
+
+ Check to see whether SELinux is installed on your machine. If not, you can skip this section.
+ In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
+ $ rpm -qa | grep selinux
+
+
+ Set the SELINUX variable in /etc/selinux/config to "permissive". This ensures that the permissive setting will be maintained after a system reboot.
+ In RHEL or CentOS:
+ vi /etc/selinux/config
+ Change the following line
+ SELINUX=enforcing
+ to this
+ SELINUX=permissive
+
+
+ Then set SELinux to permissive starting immediately, without requiring a system reboot.
+ $ setenforce permissive
+
+
+
+
+ Configure Apparmor (Ubuntu)
+
+
+ Check to see whether AppArmor is installed on your machine. If not, you can skip this section.
+ In Ubuntu AppArmor is installed and enabled by default. You can verify this with:
+ $ dpkg --list 'apparmor'
+
+
+ Disable the AppArmor profiles for libvirt
+ $ ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
+ $ ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
+ $ apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
+ $ apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-installation.xml b/docs/tmp/en-US/xml_tmp/hypervisor-installation.xml
new file mode 100644
index 00000000000..b0fc9f46ddb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-installation.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Hypervisor Installation
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-kvm-install-flow.xml b/docs/tmp/en-US/xml_tmp/hypervisor-kvm-install-flow.xml
new file mode 100644
index 00000000000..76e03ef7919
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-kvm-install-flow.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ KVM Hypervisor Host Installation
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-kvm-requirements.xml b/docs/tmp/en-US/xml_tmp/hypervisor-kvm-requirements.xml
new file mode 100644
index 00000000000..c42db86a2b8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-kvm-requirements.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ System Requirements for KVM Hypervisor Hosts
+ KVM is included with a variety of Linux-based operating systems. Although you are not required to run these distributions, the following are recommended:
+
+ CentOS / RHEL: 6.3
+ Ubuntu: 12.04(.1)
+
+ The main requirement for KVM hypervisors is the libvirt and Qemu version. No matter what
+ Linux distribution you are using, make sure the following requirements are met:
+
+ libvirt: 0.9.4 or higher
+ Qemu/KVM: 1.0 or higher
+
+ In addition, the following hardware requirements apply:
+
+ Within a single cluster, the hosts must be of the same distribution version.
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+ Must support HVM (Intel-VT or AMD-V enabled)
+ 64-bit x86 CPU (more cores results in better performance)
+ 4 GB of memory
+ At least 1 NIC
+ When you deploy &PRODUCT;, the hypervisor host must not have any VMs already running
+
+
diff --git a/docs/tmp/en-US/xml_tmp/hypervisor-support-for-primarystorage.xml b/docs/tmp/en-US/xml_tmp/hypervisor-support-for-primarystorage.xml
new file mode 100644
index 00000000000..055c1826169
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/hypervisor-support-for-primarystorage.xml
@@ -0,0 +1,95 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Hypervisor Support for Primary Storage
+ The following table shows storage options and parameters for different hypervisors.
+
+
+
+
+
+
+
+
+
+
+
+
+ VMware vSphere
+ Citrix XenServer
+ KVM
+
+
+
+
+ Format for Disks, Templates, and
+ Snapshots
+ VMDK
+ VHD
+ QCOW2
+
+
+ iSCSI support
+ VMFS
+ Clustered LVM
+ Yes, via Shared Mountpoint
+
+
+ Fiber Channel support
+ VMFS
+ Yes, via Existing SR
+ Yes, via Shared Mountpoint
+
+
+ NFS support
+ Y
+ Y
+ Y
+
+
+
+ Local storage support
+ Y
+ Y
+ Y
+
+
+
+ Storage over-provisioning
+ NFS and iSCSI
+ NFS
+ NFS
+
+
+
+
+
+ XenServer uses a clustered LVM system to store VM images on iSCSI and Fiber Channel volumes and does not support over-provisioning in the hypervisor. The storage server itself, however, can support thin-provisioning. As a result the &PRODUCT; can still support storage over-provisioning by running on thin-provisioned storage volumes.
+ KVM supports "Shared Mountpoint" storage. A shared mountpoint is a file system path local to each server in a given cluster. The path must be the same across all Hosts in the cluster, for example /mnt/primary1. This shared mountpoint is assumed to be a clustered filesystem such as OCFS2. In this case the &PRODUCT; does not attempt to mount or unmount the storage as is done with NFS. The &PRODUCT; requires that the administrator insure that the storage is available
+
+ With NFS storage, &PRODUCT; manages the overprovisioning. In this case the global configuration parameter storage.overprovisioning.factor controls the degree of overprovisioning. This is independent of hypervisor type.
+ Local storage is an option for primary storage for vSphere, XenServer, and KVM. When the local disk option is enabled, a local disk storage pool is automatically created on each host. To use local storage for the System Virtual Machines (such as the Virtual Router), set system.vm.use.local.storage to true in global configuration.
+ &PRODUCT; supports multiple primary storage pools in a Cluster. For example, you could provision 2 NFS servers in primary storage. Or you could provision 1 iSCSI LUN initially and then add a second iSCSI LUN when the first approaches capacity.
+
diff --git a/docs/tmp/en-US/xml_tmp/images/1000-foot-view.png b/docs/tmp/en-US/xml_tmp/images/1000-foot-view.png
new file mode 100644
index 00000000000..2fe3c1658b3
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/1000-foot-view.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/add-cluster.png b/docs/tmp/en-US/xml_tmp/images/add-cluster.png
new file mode 100644
index 00000000000..383f375ebed
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/add-cluster.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/add-gateway.png b/docs/tmp/en-US/xml_tmp/images/add-gateway.png
new file mode 100644
index 00000000000..da8eed955f5
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/add-gateway.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/add-guest-network.png b/docs/tmp/en-US/xml_tmp/images/add-guest-network.png
new file mode 100644
index 00000000000..5740ab58d32
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/add-guest-network.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/add-new-gateway-vpc.png b/docs/tmp/en-US/xml_tmp/images/add-new-gateway-vpc.png
new file mode 100644
index 00000000000..f15b778e0f2
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/add-new-gateway-vpc.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/add-tier.png b/docs/tmp/en-US/xml_tmp/images/add-tier.png
new file mode 100644
index 00000000000..881671e2133
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/add-tier.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/add-vpc.png b/docs/tmp/en-US/xml_tmp/images/add-vpc.png
new file mode 100644
index 00000000000..6b9c6379d9f
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/add-vpc.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/add-vpn-customer-gateway.png b/docs/tmp/en-US/xml_tmp/images/add-vpn-customer-gateway.png
new file mode 100644
index 00000000000..fdc3177e9eb
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/add-vpn-customer-gateway.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/attach-disk-icon.png b/docs/tmp/en-US/xml_tmp/images/attach-disk-icon.png
new file mode 100644
index 00000000000..5e81d04fda2
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/attach-disk-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/autoscale-config.png b/docs/tmp/en-US/xml_tmp/images/autoscale-config.png
new file mode 100644
index 00000000000..735ae961f81
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/autoscale-config.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/basic-deployment.png b/docs/tmp/en-US/xml_tmp/images/basic-deployment.png
new file mode 100644
index 00000000000..894a05327bf
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/basic-deployment.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/change-admin-password.png b/docs/tmp/en-US/xml_tmp/images/change-admin-password.png
new file mode 100644
index 00000000000..938e8616a35
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/change-admin-password.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/change-password.png b/docs/tmp/en-US/xml_tmp/images/change-password.png
new file mode 100644
index 00000000000..fbb203a5e25
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/change-password.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/change-service-icon.png b/docs/tmp/en-US/xml_tmp/images/change-service-icon.png
new file mode 100644
index 00000000000..780e235f2f5
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/change-service-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/cluster-overview.png b/docs/tmp/en-US/xml_tmp/images/cluster-overview.png
new file mode 100644
index 00000000000..33f1a0477ef
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/cluster-overview.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/console-icon.png b/docs/tmp/en-US/xml_tmp/images/console-icon.png
new file mode 100644
index 00000000000..bf288869745
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/console-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/create-vpn-connection.png b/docs/tmp/en-US/xml_tmp/images/create-vpn-connection.png
new file mode 100644
index 00000000000..cd5515f53c7
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/create-vpn-connection.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/delete-button.png b/docs/tmp/en-US/xml_tmp/images/delete-button.png
new file mode 100644
index 00000000000..27145cebbc7
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/delete-button.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/destroy-instance.png b/docs/tmp/en-US/xml_tmp/images/destroy-instance.png
new file mode 100644
index 00000000000..aa9846cfd9b
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/destroy-instance.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/detach-disk-icon.png b/docs/tmp/en-US/xml_tmp/images/detach-disk-icon.png
new file mode 100644
index 00000000000..536a4f8d001
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/detach-disk-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/edit-icon.png b/docs/tmp/en-US/xml_tmp/images/edit-icon.png
new file mode 100644
index 00000000000..42417e278d3
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/edit-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/enable-disable-autoscale.png b/docs/tmp/en-US/xml_tmp/images/enable-disable-autoscale.png
new file mode 100644
index 00000000000..ee02ef21c69
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/enable-disable-autoscale.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/enable-disable.png b/docs/tmp/en-US/xml_tmp/images/enable-disable.png
new file mode 100644
index 00000000000..cab31ae3d59
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/enable-disable.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/guest-traffic-setup.png b/docs/tmp/en-US/xml_tmp/images/guest-traffic-setup.png
new file mode 100644
index 00000000000..52508194ac1
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/guest-traffic-setup.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/http-access.png b/docs/tmp/en-US/xml_tmp/images/http-access.png
new file mode 100644
index 00000000000..817f197985a
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/http-access.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/icon.svg b/docs/tmp/en-US/xml_tmp/images/icon.svg
new file mode 100644
index 00000000000..37f94c06c1b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/images/icon.svg
@@ -0,0 +1,37 @@
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/images/infrastructure-overview.png b/docs/tmp/en-US/xml_tmp/images/infrastructure-overview.png
new file mode 100644
index 00000000000..24aeecfcd1e
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/infrastructure-overview.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/installation-complete.png b/docs/tmp/en-US/xml_tmp/images/installation-complete.png
new file mode 100644
index 00000000000..4626f86d133
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/installation-complete.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/iso-icon.png b/docs/tmp/en-US/xml_tmp/images/iso-icon.png
new file mode 100644
index 00000000000..8d547fb397e
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/iso-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/large-scale-redundant-setup.png b/docs/tmp/en-US/xml_tmp/images/large-scale-redundant-setup.png
new file mode 100644
index 00000000000..5d2581afb43
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/large-scale-redundant-setup.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/migrate-instance.png b/docs/tmp/en-US/xml_tmp/images/migrate-instance.png
new file mode 100644
index 00000000000..25ff57245b3
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/migrate-instance.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/multi-node-management-server.png b/docs/tmp/en-US/xml_tmp/images/multi-node-management-server.png
new file mode 100644
index 00000000000..5cf5ed5456f
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/multi-node-management-server.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/multi-site-deployment.png b/docs/tmp/en-US/xml_tmp/images/multi-site-deployment.png
new file mode 100644
index 00000000000..f3ae5bb6b5c
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/multi-site-deployment.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/multi-tier-app.png b/docs/tmp/en-US/xml_tmp/images/multi-tier-app.png
new file mode 100644
index 00000000000..cec11228e26
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/multi-tier-app.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/network-acl.png b/docs/tmp/en-US/xml_tmp/images/network-acl.png
new file mode 100644
index 00000000000..5602827f415
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/network-acl.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/network-setup-zone.png b/docs/tmp/en-US/xml_tmp/images/network-setup-zone.png
new file mode 100644
index 00000000000..8324ff8beaa
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/network-setup-zone.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/network-singlepod.png b/docs/tmp/en-US/xml_tmp/images/network-singlepod.png
new file mode 100644
index 00000000000..e1214ea7f69
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/network-singlepod.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/networking-in-a-pod.png b/docs/tmp/en-US/xml_tmp/images/networking-in-a-pod.png
new file mode 100644
index 00000000000..bf731712042
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/networking-in-a-pod.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/networking-in-a-zone.png b/docs/tmp/en-US/xml_tmp/images/networking-in-a-zone.png
new file mode 100644
index 00000000000..fb740da448e
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/networking-in-a-zone.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/nic-bonding-and-multipath-io.png b/docs/tmp/en-US/xml_tmp/images/nic-bonding-and-multipath-io.png
new file mode 100644
index 00000000000..0fe60b66ed6
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/nic-bonding-and-multipath-io.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/parallel-mode.png b/docs/tmp/en-US/xml_tmp/images/parallel-mode.png
new file mode 100644
index 00000000000..3b67a17af9d
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/parallel-mode.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/pod-overview.png b/docs/tmp/en-US/xml_tmp/images/pod-overview.png
new file mode 100644
index 00000000000..c180060ba48
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/pod-overview.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/provisioning-overview.png b/docs/tmp/en-US/xml_tmp/images/provisioning-overview.png
new file mode 100644
index 00000000000..25cc97e3557
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/provisioning-overview.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/release-ip-icon.png b/docs/tmp/en-US/xml_tmp/images/release-ip-icon.png
new file mode 100644
index 00000000000..aa9846cfd9b
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/release-ip-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/remove-tier.png b/docs/tmp/en-US/xml_tmp/images/remove-tier.png
new file mode 100644
index 00000000000..e14d08f8052
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/remove-tier.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/remove-vpc.png b/docs/tmp/en-US/xml_tmp/images/remove-vpc.png
new file mode 100644
index 00000000000..aa9846cfd9b
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/remove-vpc.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/remove-vpn.png b/docs/tmp/en-US/xml_tmp/images/remove-vpn.png
new file mode 100644
index 00000000000..27145cebbc7
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/remove-vpn.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/reset-vpn.png b/docs/tmp/en-US/xml_tmp/images/reset-vpn.png
new file mode 100644
index 00000000000..04655dc37ad
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/reset-vpn.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/restart-vpc.png b/docs/tmp/en-US/xml_tmp/images/restart-vpc.png
new file mode 100644
index 00000000000..04655dc37ad
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/restart-vpc.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/search-button.png b/docs/tmp/en-US/xml_tmp/images/search-button.png
new file mode 100644
index 00000000000..f329aef4a25
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/search-button.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/select-vm-staticnat-vpc.png b/docs/tmp/en-US/xml_tmp/images/select-vm-staticnat-vpc.png
new file mode 100644
index 00000000000..12fde26d883
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/select-vm-staticnat-vpc.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/separate-storage-network.png b/docs/tmp/en-US/xml_tmp/images/separate-storage-network.png
new file mode 100644
index 00000000000..24dbbefc5b4
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/separate-storage-network.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/small-scale-deployment.png b/docs/tmp/en-US/xml_tmp/images/small-scale-deployment.png
new file mode 100644
index 00000000000..1c88520e7b4
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/small-scale-deployment.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/software-license.png b/docs/tmp/en-US/xml_tmp/images/software-license.png
new file mode 100644
index 00000000000..67aa2555341
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/software-license.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/stop-instance-icon.png b/docs/tmp/en-US/xml_tmp/images/stop-instance-icon.png
new file mode 100644
index 00000000000..209afce5086
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/stop-instance-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/suspend-icon.png b/docs/tmp/en-US/xml_tmp/images/suspend-icon.png
new file mode 100644
index 00000000000..cab31ae3d59
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/suspend-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/sysmanager.png b/docs/tmp/en-US/xml_tmp/images/sysmanager.png
new file mode 100644
index 00000000000..5b9df347a60
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/sysmanager.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vm-lifecycle.png b/docs/tmp/en-US/xml_tmp/images/vm-lifecycle.png
new file mode 100644
index 00000000000..97823fc568a
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vm-lifecycle.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-increase-ports.png b/docs/tmp/en-US/xml_tmp/images/vmware-increase-ports.png
new file mode 100644
index 00000000000..fe968153262
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-increase-ports.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-datastore.png b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-datastore.png
new file mode 100644
index 00000000000..9f6b33f01ed
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-datastore.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-general.png b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-general.png
new file mode 100644
index 00000000000..863602b9eb7
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-general.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-initiator-properties.png b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-initiator-properties.png
new file mode 100644
index 00000000000..1fab03143b1
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-initiator-properties.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-initiator.png b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-initiator.png
new file mode 100644
index 00000000000..a9a8301d74d
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-initiator.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-target-add.png b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-target-add.png
new file mode 100644
index 00000000000..f016da7956d
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-iscsi-target-add.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-mgt-network-properties.png b/docs/tmp/en-US/xml_tmp/images/vmware-mgt-network-properties.png
new file mode 100644
index 00000000000..9141af9c42f
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-mgt-network-properties.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-nexus-add-cluster.png b/docs/tmp/en-US/xml_tmp/images/vmware-nexus-add-cluster.png
new file mode 100644
index 00000000000..7c1dd73f775
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-nexus-add-cluster.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-nexus-port-profile.png b/docs/tmp/en-US/xml_tmp/images/vmware-nexus-port-profile.png
new file mode 100644
index 00000000000..19b264f7a0a
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-nexus-port-profile.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-physical-network.png b/docs/tmp/en-US/xml_tmp/images/vmware-physical-network.png
new file mode 100644
index 00000000000..a7495c77b14
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-physical-network.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vmware-vswitch-properties.png b/docs/tmp/en-US/xml_tmp/images/vmware-vswitch-properties.png
new file mode 100644
index 00000000000..bc247d276d6
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vmware-vswitch-properties.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vpc-setting.png b/docs/tmp/en-US/xml_tmp/images/vpc-setting.png
new file mode 100644
index 00000000000..782299e9f54
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vpc-setting.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vpn-icon.png b/docs/tmp/en-US/xml_tmp/images/vpn-icon.png
new file mode 100644
index 00000000000..2ac12f77c40
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vpn-icon.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/vsphere-client.png b/docs/tmp/en-US/xml_tmp/images/vsphere-client.png
new file mode 100644
index 00000000000..2acc8b802ad
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/vsphere-client.png differ
diff --git a/docs/tmp/en-US/xml_tmp/images/zone-overview.png b/docs/tmp/en-US/xml_tmp/images/zone-overview.png
new file mode 100644
index 00000000000..24aeecfcd1e
Binary files /dev/null and b/docs/tmp/en-US/xml_tmp/images/zone-overview.png differ
diff --git a/docs/tmp/en-US/xml_tmp/import-ami.xml b/docs/tmp/en-US/xml_tmp/import-ami.xml
new file mode 100644
index 00000000000..2f093b178c8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/import-ami.xml
@@ -0,0 +1,112 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Importing Amazon Machine Images
+ The following procedures describe how to import an Amazon Machine Image (AMI) into &PRODUCT; when using the XenServer hypervisor.
+ Assume you have an AMI file and this file is called CentOS_6.2_x64. Assume further that you are working on a CentOS host. If the AMI is a Fedora image, you need to be working on a Fedora host initially.
+ You need to have a XenServer host with a file-based storage repository (either a local ext3 SR or an NFS SR) to convert to a VHD once the image file has been customized on the Centos/Fedora host.
+ 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.
+
+ Set up loopback on image file:# mkdir -p /mnt/loop/centos62
+# mount -o loop CentOS_6.2_x64 /mnt/loop/centos54
+
+ Install the kernel-xen package into the image. This downloads the PV kernel and ramdisk to the image.# yum -c /mnt/loop/centos54/etc/yum.conf --installroot=/mnt/loop/centos62/ -y install kernel-xen
+ Create a grub entry in /boot/grub/grub.conf.# mkdir -p /mnt/loop/centos62/boot/grub
+# touch /mnt/loop/centos62/boot/grub/grub.conf
+# echo "" > /mnt/loop/centos62/boot/grub/grub.conf
+
+ Determine the name of the PV kernel that has been installed into the image.
+ # cd /mnt/loop/centos62
+# ls lib/modules/
+2.6.16.33-xenU 2.6.16-xenU 2.6.18-164.15.1.el5xen 2.6.18-164.6.1.el5.centos.plus 2.6.18-xenU-ec2-v1.0 2.6.21.7-2.fc8xen 2.6.31-302-ec2
+# ls boot/initrd*
+boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
+# ls boot/vmlinuz*
+boot/vmlinuz-2.6.18-164.15.1.el5xen boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus boot/vmlinuz-2.6.18-xenU-ec2-v1.0 boot/vmlinuz-2.6.21-2952.fc8xen
+
+ Xen kernels/ramdisk always end with "xen". For the kernel version you choose, there has to be an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.
+ Based on your findings, create an entry in the grub.conf file. Below is an example entry.default=0
+timeout=5
+hiddenmenu
+title CentOS (2.6.18-164.15.1.el5xen)
+ root (hd0,0)
+ kernel /boot/vmlinuz-2.6.18-164.15.1.el5xen ro root=/dev/xvda
+ initrd /boot/initrd-2.6.18-164.15.1.el5xen.img
+
+ Edit etc/fstab, changing “sda1” to “xvda” and changing “sdb” to “xvdb”.
+ # cat etc/fstab
+/dev/xvda / ext3 defaults 1 1
+/dev/xvdb /mnt ext3 defaults 0 0
+none /dev/pts devpts gid=5,mode=620 0 0
+none /proc proc defaults 0 0
+none /sys sysfs defaults 0 0
+
+ Enable login via the console. The default console device in a XenServer system is xvc0. Ensure that etc/inittab and etc/securetty have the following lines respectively:
+ # grep xvc0 etc/inittab
+co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
+# grep xvc0 etc/securetty
+xvc0
+
+ Ensure the ramdisk supports PV disk and PV network. Customize this for the kernel version you have determined above.
+ # chroot /mnt/loop/centos54
+# cd /boot/
+# mv initrd-2.6.18-164.15.1.el5xen.img initrd-2.6.18-164.15.1.el5xen.img.bak
+# mkinitrd -f /boot/initrd-2.6.18-164.15.1.el5xen.img --with=xennet --preload=xenblk --omit-scsi-modules 2.6.18-164.15.1.el5xen
+
+ Change the password.
+ # passwd
+Changing password for user root.
+New UNIX password:
+Retype new UNIX password:
+passwd: all authentication tokens updated successfully.
+
+ Exit out of chroot.# exit
+ Check etc/ssh/sshd_config for lines allowing ssh login using a password.
+ # egrep "PermitRootLogin|PasswordAuthentication" /mnt/loop/centos54/etc/ssh/sshd_config
+PermitRootLogin yes
+PasswordAuthentication yes
+
+ If you need the template to be enabled to reset passwords from the &PRODUCT; UI or API,
+ install the password change script into the image at this point. See
+ .
+ Unmount and delete loopback mount.# umount /mnt/loop/centos54
+# losetup -d /dev/loop0
+
+ Copy the image file to your XenServer host's file-based storage repository. In the example below, the Xenserver is "xenhost". This XenServer has an NFS repository whose uuid is a9c5b8c8-536b-a193-a6dc-51af3e5ff799.
+ # scp CentOS_6.2_x64 xenhost:/var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799/
+ Log in to the Xenserver and create a VDI the same size as the image.
+ [root@xenhost ~]# cd /var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# ls -lh CentOS_6.2_x64
+-rw-r--r-- 1 root root 10G Mar 16 16:49 CentOS_6.2_x64
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-create virtual-size=10GiB sr-uuid=a9c5b8c8-536b-a193-a6dc-51af3e5ff799 type=user name-label="Centos 6.2 x86_64"
+cad7317c-258b-4ef7-b207-cdf0283a7923
+
+ Import the image file into the VDI. This may take 10–20 minutes.[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-import filename=CentOS_6.2_x64 uuid=cad7317c-258b-4ef7-b207-cdf0283a7923
+ Locate a the VHD file. This is the file with the VDI’s UUID as its name. Compress it and upload it to your web server.
+ [root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# bzip2 -c cad7317c-258b-4ef7-b207-cdf0283a7923.vhd > CentOS_6.2_x64.vhd.bz2
+[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# scp CentOS_6.2_x64.vhd.bz2 webserver:/var/www/html/templates/
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/increase-management-server-max-memory.xml b/docs/tmp/en-US/xml_tmp/increase-management-server-max-memory.xml
new file mode 100644
index 00000000000..16d18e75830
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/increase-management-server-max-memory.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Increase Management Server Maximum Memory
+ If the Management Server is subject to high demand, the default maximum JVM memory allocation can be insufficient. To increase the memory:
+
+ Edit the Tomcat configuration file:/etc/cloud/management/tomcat6.conf
+ Change the command-line parameter -XmxNNNm to a higher value of N.For example, if the current value is -Xmx128m, change it to -Xmx1024m or higher.
+ To put the new setting into effect, restart the Management Server.# service cloud-management restart
+
+ For more information about memory issues, see "FAQ: Memory" at Tomcat Wiki.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/incremental-snapshots-backup.xml b/docs/tmp/en-US/xml_tmp/incremental-snapshots-backup.xml
new file mode 100644
index 00000000000..ade00c90c17
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/incremental-snapshots-backup.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Incremental Snapshots and Backup
+ Snapshots are created on primary storage where a disk resides. After a snapshot is created, it is immediately backed up to secondary storage and removed from primary storage for optimal utilization of space on primary storage.
+ &PRODUCT; does incremental backups for some hypervisors. When incremental backups are supported, every N backup is a full backup.
+
+
+
+
+
+
+ VMware vSphere
+ Citrix XenServer
+ KVM
+
+
+
+
+ Support incremental backup
+ N
+ Y
+ N
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/initial-setup-of-external-firewalls-loadbalancers.xml b/docs/tmp/en-US/xml_tmp/initial-setup-of-external-firewalls-loadbalancers.xml
new file mode 100644
index 00000000000..332afa04ebb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/initial-setup-of-external-firewalls-loadbalancers.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Initial Setup of External Firewalls and Load Balancers
+ When the first VM is created for a new account, &PRODUCT; programs the external firewall and load balancer to work with the VM. The following objects are created on the firewall:
+
+ A new logical interface to connect to the account's private VLAN. The interface IP is always the first IP of the account's private subnet (e.g. 10.1.1.1).
+ A source NAT rule that forwards all outgoing traffic from the account's private VLAN to the public Internet, using the account's public IP address as the source address
+ A firewall filter counter that measures the number of bytes of outgoing traffic for the account
+
+ The following objects are created on the load balancer:
+
+ A new VLAN that matches the account's provisioned Zone VLAN
+ A self IP for the VLAN. This is always the second IP of the account's private subnet (e.g. 10.1.1.2).
+
+
diff --git a/docs/tmp/en-US/xml_tmp/initialize-and-test.xml b/docs/tmp/en-US/xml_tmp/initialize-and-test.xml
new file mode 100644
index 00000000000..cf0c04ecea6
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/initialize-and-test.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Initialize and Test
+ After everything is configured, &PRODUCT; will perform its initialization. This can take 30 minutes or more, depending on the speed of your network. When the initialization has completed successfully, the administrator's Dashboard should be displayed in the &PRODUCT; UI.
+
+ Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS 5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do not proceed to the next step until this status is displayed.
+ Go to the Instances tab, and filter by My Instances.
+ Click Add Instance and follow the steps in the wizard.
+
+ Choose the zone you just added.
+ In the template selection, choose the template to use in the VM. If this is a fresh installation, likely only the provided CentOS template is available.
+ Select a service offering. Be sure that the hardware you have allows starting the selected service offering.
+ In data disk offering, if desired, add another data disk. This is a second volume that will be available to but not mounted in the guest. For example, in Linux on XenServer you will see /dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PV-enabled OS kernel in use.
+ In default network, choose the primary network for the guest. In a trial installation, you would have only one option here.
+ Optionally give your VM a name and a group. Use any descriptive text you would like.
+ Click Launch VM. Your VM will be created and started. It might take some time to download the template and complete the VM startup. You can watch the VM’s progress in the Instances screen.
+
+
+
+ To use the VM, click the View Console button.
+
+
+ ConsoleButton.png: button to launch a console
+
+
+
+
+ Congratulations! You have successfully completed a &PRODUCT; Installation.
+ If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and clusters.
+
diff --git a/docs/tmp/en-US/xml_tmp/install-database-on-management-server-node.xml b/docs/tmp/en-US/xml_tmp/install-database-on-management-server-node.xml
new file mode 100644
index 00000000000..238f9dee629
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/install-database-on-management-server-node.xml
@@ -0,0 +1,98 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Install the Database on the Management Server Node
+ This section describes how to install MySQL on the same machine with the Management Server. This technique is intended for a simple deployment that has a single Management Server node. If you have a multi-node Management Server deployment, you will typically use a separate node for MySQL. See .
+
+
+ If you already have a version of MySQL installed on the Management Server node, make one of the following choices, depending on what version of MySQL it is. The most recent version tested is 5.1.58.
+
+ If you already have installed MySQL version 5.1.58 or later, skip to step 4.
+
+ If you have installed a version of MySQL earlier than 5.1.58, you can either skip to step 4 or uninstall MySQL and proceed to step 2 to install a more recent version.
+
+ It is important that you choose the right database version. Never downgrade a MySQL installation.
+
+ On the same computer where you installed the Management Server, re-run install.sh.
+ # ./install.sh
+ You should see a few messages as the installer prepares, followed by a list of choices.
+
+ Choose D to install the MySQL server from the distribution’s repo.
+ > D
+ Troubleshooting: If you do not see the D option, you already have MySQL installed. Please go back to step 1.
+
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes one Management Server.
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=350
+log-bin=mysql-bin
+binlog-format = 'ROW'
+
+ The binlog-format variable is supported in MySQL versions 5.1 and greater. It is not supported in MySQL 5.0. In some versions of MySQL, an underscore character is used in place of the hyphen in the variable name. For the exact syntax and spelling of each variable, consult the documentation for your version of MySQL.
+
+ Restart the MySQL service, then invoke MySQL as the root user.
+
+# service mysqld restart
+# mysql -u root
+
+
+ Best Practice: On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password.
+ mysql> SET PASSWORD = PASSWORD('password');
+ From now on, start MySQL with mysql -p so it will prompt you for the password.
+
+ To grant access privileges to remote users, perform the following steps.
+
+ Run the following commands from the mysql prompt:
+
+mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
+mysql> exit
+
+
+ Restart the MySQL service.
+ # service mysqld restart
+ Open the MySQL server port (3306) in the firewall to allow remote clients to connect.
+ # iptables -I INPUT -p tcp --dport 3306 -j ACCEPT
+ Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the INPUT chain.
+ -A INPUT -p tcp --dport 3306 -j ACCEPT
+
+
+ Set up the database. The following command creates the cloud user on the database.
+
+ In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password.
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ # cloud-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m <management_server_key> -k <database_key>
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
+ Now that the database is set up, you can finish configuring the OS for the Management Server. This command will set up iptables, sudoers, and start the Management Server.
+ # cloud-setup-management
+ You should see the message “Management Server setup is done.”
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/install-database-on-separate-node.xml b/docs/tmp/en-US/xml_tmp/install-database-on-separate-node.xml
new file mode 100644
index 00000000000..bc768290ce3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/install-database-on-separate-node.xml
@@ -0,0 +1,105 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Install the Database on a Separate Node
+ This section describes how to install MySQL on a standalone machine, separate from the Management Server.
+ This technique is intended for a deployment that includes several Management Server nodes.
+ If you have a single-node Management Server deployment, you will typically use the same node for MySQL.
+ See .
+
+
+ If you already have a version of MySQL installed on the Management Server node, make one of the following choices, depending on what version of MySQL it is. The most recent version tested is 5.1.58.
+
+ If you already have installed MySQL version 5.1.58 or later, skip to step 3.
+
+ If you have installed a version of MySQL earlier than 5.1.58, you can either skip to step 3 or uninstall MySQL and proceed to step 2 to install a more recent version.
+
+ It is important that you choose the right database version. Never downgrade a MySQL installation.
+
+ Log in as root to your Database Node and run the following commands. If you are going to install a replica database, then log in to the master.
+
+# yum install mysql-server
+# chkconfig --level 35 mysqld on
+
+
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS)
+ and insert the following lines in the [mysqld] section. You can put these lines below the datadir
+ line. The max_connections parameter should be set to 350 multiplied by the number of Management
+ Servers you are deploying. This example assumes two Management Servers.
+
+innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=700
+log-bin=mysql-bin
+binlog-format = 'ROW'
+
+ The binlog-format variable is supported in MySQL versions 5.1 and greater. It is not supported in MySQL 5.0. In some versions of MySQL, an underscore character is used in place of the hyphen in the variable name. For the exact syntax and spelling of each variable, consult the documentation for your version of MySQL.
+
+ Restart the MySQL service, then invoke MySQL as the root user.
+
+# service mysqld restart
+# mysql -u root
+
+
+ Best Practice: On RHEL and CentOS, MySQL does not set a root password by default. It is very strongly recommended that you set a root password as a security precaution. Run the following commands, and substitute your own desired root password.
+ mysql> SET PASSWORD = PASSWORD('password');
+ From now on, start MySQL with mysql -p so it will prompt you for the password.
+
+ To grant access privileges to remote users, perform the following steps.
+
+ Run the following commands from the mysql prompt:
+
+mysql> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
+mysql> exit
+
+
+ Restart the MySQL service.
+ # service mysqld restart
+
+ Open the MySQL server port (3306) in the firewall to allow remote clients to connect.
+ # iptables -I INPUT -p tcp --dport 3306 -j ACCEPT
+
+ Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the INPUT chain.
+ -A INPUT -p tcp --dport 3306 -j ACCEPT
+
+
+
+ Set up the database. The following command creates the cloud user on the database.
+
+ In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password.
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ # cloud-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m <management_server_key> -k <database_key>
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
+ Now that the database is set up, you can finish configuring the OS for the Management Server. This command will set up iptables, sudoers, and start the Management Server.
+ # cloud-setup-management
+ You should see the message “Management Server setup is done.”
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/install-management-server-multi-nodes.xml b/docs/tmp/en-US/xml_tmp/install-management-server-multi-nodes.xml
new file mode 100644
index 00000000000..17d0f868b3c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/install-management-server-multi-nodes.xml
@@ -0,0 +1,74 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Prepare and Start Additional Management Servers
+ For your second and subsequent Management Servers, you will install the Management Server software, connect it to the database, and set up the OS for the Management Server.
+
+
+ Perform the steps in .
+
+ Download the Management Server onto the additional host where it will run. Get the software from the following link.
+ https://www.citrix.com/English/ss/downloads/
+FIXME
+ You will need a MyCitrix account.
+
+ Install the packages. You should have a file in the form of “&PRODUCT;-VERSION-N-OSVERSION.tar.gz”. Untar the file and then run the install.sh script inside it. Replace the file and directory names below with those you are using:
+
+# tar xzf &PRODUCT;-VERSION-N-OSVERSION.tar.gz
+# cd &PRODUCT;-VERSION-N-OSVERSION
+# ./install.sh
+
+ You should see a few messages as the installer prepares, followed by a list of choices.
+
+ Choose M to install the Management Server software.
+ > M
+
+ Wait for a message like “Complete! Done,” which indicates that the software was installed successfully.
+
+ (RHEL or CentOS) When the installation is finished, run the following commands to start essential services (the commands might be different depending on your OS):
+
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+
+
+ Configure the database client. Note the absence of the --deploy-as argument in this case.
+ (For more details about the arguments to this command, see .)
+
+ # cloud-setup-databases cloud:<dbpassword>@<dbhost> -e <encryption_type> -m <management_server_key> -k <database_key>
+
+
+ (Trial installations only) If you are running the hypervisor on the same machine with the Management Server, edit /etc/sudoers and add the following line:
+ Defaults:cloud !requiretty
+
+ Configure the OS and start the Management Server:
+ # cloud-setup-management
+ The Management Server on this node should now be running.
+
+ Repeat these steps on each additional Management Server.
+ Be sure to configure a load balancer for the Management Servers. See Management Server Load Balancing.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/install-management-server.xml b/docs/tmp/en-US/xml_tmp/install-management-server.xml
new file mode 100644
index 00000000000..d8eb1e5d4eb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/install-management-server.xml
@@ -0,0 +1,58 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Install the Management Server on the First Host
+ The first step in installation, whether you are installing the Management Server on one host or many, is to install the software on a single node.
+
+ If you are planning to install the Management Server on multiple nodes for high availability, do not proceed to the additional nodes yet. That step will come later.
+
+ Download the Management Server onto the host where it will run. Get the software from the following link.
+ https://www.citrix.com/English/ss/downloads/
+ FIXME
+ You will need a MyCitrix account.
+
+ Install the packages. You should have a file in the form of “&PRODUCT;-VERSION-N-OSVERSION.tar.gz”. Untar the file and then run the install.sh script inside it. Replace the file and directory names below with those you are using:
+
+# tar xzf &PRODUCT;-VERSION-N-OSVERSION.tar.gz
+# cd &PRODUCT;-VERSION-N-OSVERSION
+# ./install.sh
+
+ You should see a few messages as the installer prepares, followed by a list of choices.
+
+ Choose M to install the Management Server software.
+ > M
+
+ Wait for a message like “Complete! Done,” which indicates that the software was installed successfully.
+
+ (RHEL or CentOS) When the installation is finished, run the following commands to start essential services (the commands might be different depending on your OS):
+
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/installation-complete.xml b/docs/tmp/en-US/xml_tmp/installation-complete.xml
new file mode 100644
index 00000000000..b39040ba0cf
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/installation-complete.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Installation Complete! Next Steps
+ Congratulations! You have now installed &PRODUCT; Management Server and the database it uses to persist system data.
+
+
+
+
+ installation-complete.png: Finished installs with single Management Server and multiple Management Servers
+
+ What should you do next?
+
+ Even without adding any cloud infrastructure, you can run the UI to get a feel for what's offered and how you will interact with &PRODUCT; on an ongoing basis. See .
+ When you're ready, add the cloud infrastructure and try running some virtual machines on it, so you can watch how &PRODUCT; manages the infrastructure. See .
+
+
diff --git a/docs/tmp/en-US/xml_tmp/installation-steps-overview.xml b/docs/tmp/en-US/xml_tmp/installation-steps-overview.xml
new file mode 100644
index 00000000000..ea00057bab3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/installation-steps-overview.xml
@@ -0,0 +1,67 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Overview of Installation Steps
+ For anything more than a simple trial installation, you will need guidance for a variety of configuration choices. It is strongly recommended that you read the following:
+
+ Choosing a Deployment Architecture
+ Choosing a Hypervisor: Supported Features
+ Network Setup
+ Storage Setup
+ Best Practices
+
+
+
+ Make sure you have the required hardware ready. See
+
+
+ Install the Management Server (choose single-node or multi-node). See
+
+
+ Log in to the UI. See
+
+
+ Add a zone. Includes the first pod, cluster, and host. See
+
+
+ Add more pods (optional). See
+
+
+ Add more clusters (optional). See
+
+
+ Add more hosts (optional). See
+
+
+ Add more primary storage (optional). See
+
+
+ Add more secondary storage (optional). See
+
+
+ Try using the cloud. See
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/installation.xml b/docs/tmp/en-US/xml_tmp/installation.xml
new file mode 100644
index 00000000000..5fc550edad6
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/installation.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Installation
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/installation_overview.xml b/docs/tmp/en-US/xml_tmp/installation_overview.xml
new file mode 100644
index 00000000000..eee444e571e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/installation_overview.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Installation Overview
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/installation_steps_overview.xml b/docs/tmp/en-US/xml_tmp/installation_steps_overview.xml
new file mode 100644
index 00000000000..2632a4d6243
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/installation_steps_overview.xml
@@ -0,0 +1,84 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Overview of Installation Steps
+ For anything more than a simple trial installation, you will need
+ guidance for a variety of configuration choices. It is strongly
+ recommended that you read the following:
+
+ Choosing a Deployment Architecture
+ Choosing a Hypervisor: Supported Features
+ Network Setup
+ Storage Setup
+ Best Practices
+
+
+
+
+ Prepare
+
+ Make sure you have the required hardware ready
+
+
+ (Optional) Fill out the preparation checklists
+
+
+ Install the &PRODUCT; software
+
+
+ Install the Management Server (choose single-node or multi-node)
+
+
+ Log in to the UI
+
+
+ Provision your cloud infrastructure
+
+
+ Add a zone. Includes the first pod, cluster, and host
+
+
+ Add more pods
+
+
+ Add more clusters
+
+
+ Add more hosts
+
+
+ Add more primary storage
+
+
+ Add more secondary storage
+
+
+ Try using the cloud
+
+
+ Initialization and testing
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/inter-vlan-routing.xml b/docs/tmp/en-US/xml_tmp/inter-vlan-routing.xml
new file mode 100644
index 00000000000..49a833cdb5d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/inter-vlan-routing.xml
@@ -0,0 +1,107 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ About Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature
+ enables you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can
+ hold multi-tier applications. These tiers are deployed on different VLANs that can communicate
+ with each other. You provision VLANs to the tiers your create, and VMs can be deployed on
+ different tiers. The VLANs are connected to a virtual router, which facilitates communication
+ between the VMs. In effect, you can segment VMs by means of VLANs into different networks that
+ can host multi-tier applications, such as Web, Application, or Database. Such segmentation by
+ means of VLANs logically separate application VMs for higher security and lower broadcasts,
+ while remaining physically connected to the same device.
+ This feature is supported on XenServer and VMware hypervisors.
+ The major advantages are:
+
+
+ The administrator can deploy a set of VLANs and allow users to deploy VMs on these
+ VLANs. A guest VLAN is randomly alloted to an account from a pre-specified set of guest
+ VLANs. All the VMs of a certain tier of an account reside on the guest VLAN allotted to that
+ account.
+
+ A VLAN allocated for an account cannot be shared between multiple accounts.
+
+
+
+ The administrator can allow users create their own VPC and deploy the application. In
+ this scenario, the VMs that belong to the account are deployed on the VLANs allotted to that
+ account.
+
+
+ Both administrators and users can create multiple VPCs. The guest network NIC is plugged
+ to the VPC virtual router when the first VM is deployed in a tier.
+
+
+ The administrator can create the following gateways to send to or receive traffic from
+ the VMs:
+
+
+ VPN Gateway: For more information, see .
+
+
+ Public Gateway: The public gateway for a VPC is
+ added to the virtual router when the virtual router is created for VPC. The public
+ gateway is not exposed to the end users. You are not allowed to list it, nor allowed to
+ create any static routes.
+
+
+ Private Gateway: For more information, see .
+
+
+
+
+ Both administrators and users can create various possible destinations-gateway
+ combinations. However, only one gateway of each type can be used in a deployment.
+ For example:
+
+
+ VLANs and Public Gateway: For example, an
+ application is deployed in the cloud, and the Web application VMs communicate with the
+ Internet.
+
+
+ VLANs, VPN Gateway, and Public Gateway: For
+ example, an application is deployed in the cloud; the Web application VMs communicate
+ with the Internet; and the database VMs communicate with the on-premise devices.
+
+
+
+
+ The administrator can define Access Control List (ACL) on the virtual router to filter
+ the traffic among the VLANs or between the Internet and a VLAN. You can define ACL based on
+ CIDR, port range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress
+ type.
+
+
+ The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
+
+
+
+
+
+ mutltier.png: a multi-tier setup.
+
+
+ To set up a multi-tier Inter-VLAN deployment, see .
+
diff --git a/docs/tmp/en-US/xml_tmp/introduction.xml b/docs/tmp/en-US/xml_tmp/introduction.xml
new file mode 100644
index 00000000000..9aca8bdfc93
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/introduction.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Introduction
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/ip-forwarding-firewalling.xml b/docs/tmp/en-US/xml_tmp/ip-forwarding-firewalling.xml
new file mode 100644
index 00000000000..61aa6ad7e71
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ip-forwarding-firewalling.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ IP Forwarding and Firewalling
+ By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the guests is translated via NAT to the public IP address and is allowed.
+ To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example, you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44. Then use port forwarding rules to direct traffic from individual ports within that range to specific ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public IP's port 33 to port 100 on one user VM's private IP.
+ For the steps to implement these rules, see Firewall Rules and Port Forwarding.
+
diff --git a/docs/tmp/en-US/xml_tmp/ip-load-balancing.xml b/docs/tmp/en-US/xml_tmp/ip-load-balancing.xml
new file mode 100644
index 00000000000..ae569e7d969
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ip-load-balancing.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ IP Load Balancing
+ The user may choose to associate the same public IP for multiple guests. &PRODUCT; implements a TCP-level load balancer with the following policies.
+
+ Round-robin
+ Least connection
+ Source IP
+
+ This is similar to port forwarding but the destination may be multiple IP addresses.
+
diff --git a/docs/tmp/en-US/xml_tmp/ipaddress-usage-record-format.xml b/docs/tmp/en-US/xml_tmp/ipaddress-usage-record-format.xml
new file mode 100644
index 00000000000..1a0385b999e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ipaddress-usage-record-format.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ IP Address Usage Record Format
+ For IP address usage the following fields exist in a usage record.
+
+ account - name of the account
+ accountid - ID of the account
+ domainid - ID of the domain in which this account resides
+ zoneid - Zone where the usage occurred
+ description - A string describing what the usage record is tracking
+ usage - String representation of the usage, including the units of usage
+ usagetype - A number representing the usage type (see Usage Types)
+ rawusage - A number representing the actual usage in hours
+ usageid - IP address ID
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+ issourcenat - Whether source NAT is enabled for the IP address
+ iselastic - True if the IP address is elastic.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/isolated-networks.xml b/docs/tmp/en-US/xml_tmp/isolated-networks.xml
new file mode 100644
index 00000000000..13f8aa1d4ca
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/isolated-networks.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Isolated Networks
+ An isolated network can be accessed only by virtual machines of a single account. Isolated networks have the following properties.
+
+ Resources such as VLAN are allocated and garbage collected dynamically
+ There is one network offering for the entire network
+ The network offering can be upgraded or downgraded but it is for the entire network
+
+
diff --git a/docs/tmp/en-US/xml_tmp/job-status.xml b/docs/tmp/en-US/xml_tmp/job-status.xml
new file mode 100644
index 00000000000..da0f76c5dff
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/job-status.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Job Status
+ The key to using an asynchronous command is the job ID that is returned immediately once the command has been executed. With the job ID, you can periodically check the job status by making calls to queryAsyncJobResult command. The command will return three possible job status integer values:
+
+ 0 - Job is still in progress. Continue to periodically poll for any status changes.
+ 1 - Job has successfully completed. The job will return any successful response values associated with command that was originally executed.
+ 2 - Job has failed to complete. Please check the "jobresultcode" tag for failure reason code and "jobresult" for the failure reason.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/kvm-topology-req.xml b/docs/tmp/en-US/xml_tmp/kvm-topology-req.xml
new file mode 100644
index 00000000000..0dff491b364
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/kvm-topology-req.xml
@@ -0,0 +1,24 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ KVM Topology Requirements
+ The Management Servers communicate with KVM hosts on port 22 (ssh).
+
diff --git a/docs/tmp/en-US/xml_tmp/large_scale_redundant_setup.xml b/docs/tmp/en-US/xml_tmp/large_scale_redundant_setup.xml
new file mode 100644
index 00000000000..427a42d9182
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/large_scale_redundant_setup.xml
@@ -0,0 +1,42 @@
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Large-Scale Redundant Setup
+
+
+
+
+ Large-Scale Redundant Setup
+
+ This diagram illustrates the network architecture of a large-scale &PRODUCT; deployment.
+
+ A layer-3 switching layer is at the core of the data center. A router redundancy protocol like VRRP should be deployed. Typically high-end core switches also include firewall modules. Separate firewall appliances may also be used if the layer-3 switch does not have integrated firewall capabilities. The firewalls are configured in NAT mode. The firewalls provide the following functions:
+
+ Forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+ When the cloud spans multiple zones, the firewalls should enable site-to-site VPN such that servers in different zones can directly reach each other.
+
+
+ A layer-2 access switch layer is established for each pod. Multiple switches can be stacked to increase port count. In either case, redundant pairs of layer-2 switches should be deployed.
+ The Management Server cluster (including front-end load balancers, Management Server nodes, and the MySQL database) is connected to the management network through a pair of load balancers.
+ Secondary storage servers are connected to the management network.
+ Each pod contains storage and computing servers. Each storage and computing server should have redundant NICs connected to separate layer-2 access switches.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/layer2-switch.xml b/docs/tmp/en-US/xml_tmp/layer2-switch.xml
new file mode 100644
index 00000000000..acef5a7c207
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/layer2-switch.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Layer-2 Switch
+ The layer-2 switch is the access switching layer inside the pod.
+
+
+ It should trunk all VLANs into every computing host.
+
+
+ It should switch traffic for the management network containing computing and storage
+ hosts. The layer-3 switch will serve as the gateway for the management network.
+
+
+
+ Example Configurations
+ This section contains example configurations for specific switch models for pod-level
+ layer-2 switching. It assumes VLAN management protocols such as VTP or GVRP have been
+ disabled. The scripts must be changed appropriately if you choose to use VTP or GVRP.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/linux-installation.xml b/docs/tmp/en-US/xml_tmp/linux-installation.xml
new file mode 100644
index 00000000000..60d389c0ef4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/linux-installation.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Linux OS Installation
+ Use the following steps to begin the Linux OS installation:
+
+ Download the script file cloud-set-guest-password:
+
+ Linux:
+ Windows:
+
+
+ Copy this file to /etc/init.d.
+ On some Linux distributions, copy the file to /etc/rc.d/init.d.
+
+ Run the following command to make the script executable:chmod +x /etc/init.d/cloud-set-guest-password
+
+ Depending on the Linux distribution, continue with the appropriate step.On Fedora, CentOS/RHEL, and Debian, run:chkconfig --add cloud-set-guest-password
+ On Ubuntu with VMware tools, link the script file to the /etc/network/if-up and /etc/network/if-down folders, and run the script:
+ #ln -s /etc/init.d/cloud-set-guest-password /etc/network/if-up/cloud-set-guest-password
+ #ln -s /etc/init.d/cloud-set-guest-password /etc/network/if-down/cloud-set-guest-password
+ If you are using Ubuntu 11.04, start by creating a directory called /var/lib/dhcp3 on your Ubuntu machine (works around a known issue with this version of Ubuntu). On all Ubuntu versions: Run “sudo update-rc.d cloud-set-guest-password defaults 98”. To test, run "mkpasswd" and check that it is generating a new password. If the “mkpasswd” command does not exist, run "sudo apt-get install whois" (or sudo apt-get install mkpasswd, depending on your Ubuntu version) and repeat.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/load-balancer-rules.xml b/docs/tmp/en-US/xml_tmp/load-balancer-rules.xml
new file mode 100644
index 00000000000..8dd7d3b47ba
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/load-balancer-rules.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Load Balancer Rules
+ A &PRODUCT; user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs.
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the &PRODUCT; virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+
diff --git a/docs/tmp/en-US/xml_tmp/loadbalancer-policy-port-forwarding-rule-usage-record-format.xml b/docs/tmp/en-US/xml_tmp/loadbalancer-policy-port-forwarding-rule-usage-record-format.xml
new file mode 100644
index 00000000000..e27a49d6b96
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/loadbalancer-policy-port-forwarding-rule-usage-record-format.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Load Balancer Policy or Port Forwarding Rule Usage Record Format
+
+ account - name of the account
+ accountid - ID of the account
+ domainid - ID of the domain in which this account resides
+ zoneid - Zone where the usage occurred
+ description - A string describing what the usage record is tracking
+ usage - String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ usagetype - A number representing the usage type (see Usage Types)
+ rawusage - A number representing the actual usage in hours
+ usageid - ID of the load balancer policy or port forwarding rule
+ usagetype - A number representing the usage type (see Usage Types)
+ startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
diff --git a/docs/tmp/en-US/xml_tmp/log-in-root-admin.xml b/docs/tmp/en-US/xml_tmp/log-in-root-admin.xml
new file mode 100644
index 00000000000..bf499d6fe95
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/log-in-root-admin.xml
@@ -0,0 +1,46 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Logging In as the Root Administrator
+ After the Management Server software is installed and running, you can run the &PRODUCT; 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:
+ 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 &PRODUCT;, 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 &PRODUCT; 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 &PRODUCT; 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 CloudPlatform, 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 .
+
+ You are logging in as the root administrator. This account manages the &PRODUCT; 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/log-in.xml b/docs/tmp/en-US/xml_tmp/log-in.xml
new file mode 100644
index 00000000000..84328ce4d45
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/log-in.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Log In to the UI
+ &PRODUCT; 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)
+ 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.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/long-running-job-events.xml b/docs/tmp/en-US/xml_tmp/long-running-job-events.xml
new file mode 100644
index 00000000000..cae2b747586
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/long-running-job-events.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/maintain-hypervisors-on-hosts.xml b/docs/tmp/en-US/xml_tmp/maintain-hypervisors-on-hosts.xml
new file mode 100644
index 00000000000..213f078ea2b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/maintain-hypervisors-on-hosts.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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. &PRODUCT; 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.
+ 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 &PRODUCT; Knowledge Base
+
diff --git a/docs/tmp/en-US/xml_tmp/maintenance-mode-for-primary-storage.xml b/docs/tmp/en-US/xml_tmp/maintenance-mode-for-primary-storage.xml
new file mode 100644
index 00000000000..54c3a0d8901
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/maintenance-mode-for-primary-storage.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Maintenance Mode for Primary Storage
+ Primary storage may be placed into maintenance mode. This is useful, for example, to replace faulty RAM in a storage device. Maintenance mode for a storage device will first stop any new guests from being provisioned on the storage device. Then it will stop all guests that have any volume on that storage device. When all such guests are stopped the storage device is in maintenance mode and may be shut down. When the storage device is online again you may cancel maintenance mode for the device. The &PRODUCT; will bring the device back online and attempt to start all guests that were running at the time of the entry into maintenance mode.
+
diff --git a/docs/tmp/en-US/xml_tmp/making-api-request.xml b/docs/tmp/en-US/xml_tmp/making-api-request.xml
new file mode 100644
index 00000000000..49ea158bb21
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/making-api-request.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Making API Requests
+ All &PRODUCT; API requests are submitted in the form of a HTTP GET/POST with an associated command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
+
+
+ &PRODUCT; API URL: This is the web services API entry point(for example, http://www.cloud.com:8080/client/api)
+ Command: The web services command you wish to execute, such as start a virtual machine or create a disk volume
+ Parameters: Any additional required or optional parameters for the command
+
+ A sample API GET request looks like the following:
+ http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+ Or in a more readable format:
+
+1. http://localhost:8080/client/api
+2. ?command=deployVirtualMachine
+3. &serviceOfferingId=1
+4. &diskOfferingId=1
+5. &templateId=2
+6. &zoneId=4
+7. &apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ
+8. &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+ The first line is the &PRODUCT; API URL. This is the Cloud instance you wish to interact with.
+ The second line refers to the command you wish to execute. In our example, we are attempting to deploy a fresh new virtual machine. It is preceded by a (?) to separate itself from the &PRODUCT; API URL.
+ Lines 3-6 are the parameters for this given command. To see the command and its request parameters, please refer to the appropriate section in the &PRODUCT; API documentation. Each parameter field-value pair (field=value) is preceded by an ampersand character (&).
+ Line 7 is the user API Key that uniquely identifies the account. See Signing API Requests on page 7.
+ Line 8 is the signature hash created to authenticate the user account executing the API command. See Signing API Requests on page 7.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/manage-cloud.xml b/docs/tmp/en-US/xml_tmp/manage-cloud.xml
new file mode 100644
index 00000000000..3e29d09cdc1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/manage-cloud.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Managing the Cloud
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-client.xml b/docs/tmp/en-US/xml_tmp/management-server-install-client.xml
new file mode 100644
index 00000000000..7e81ec735fc
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-client.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Install the Management Server on the First Host
+ The first step in installation, whether you are installing the Management Server on one host
+ or many, is to install the software on a single node.
+
+ If you are planning to install the Management Server on multiple nodes for high
+ availability, do not proceed to the additional nodes yet. That step will come later.
+
+ The &PRODUCT; Management server can be installed using either RPM or DEB packages. These
+ packages will depend on everything you need to run the Management server.
+
+ Downloading vhd-util
+ This procedure is required only for installations where XenServer is installed on the hypervisor hosts.
+ Before setting up the Management Server, download vhd-util from vhd-util.
+ If the Management Server is RHEL or CentOS, copy vhd-util to
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver.
+ If the Management Server is Ubuntu, copy vhd-util to
+ /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util.
+
+
+ Install on CentOS/RHEL
+ We start by installing the required packages:
+ yum install cloud-client
+
+
+ Install on Ubuntu
+ apt-get install cloud-client
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-complete.xml b/docs/tmp/en-US/xml_tmp/management-server-install-complete.xml
new file mode 100644
index 00000000000..8f4aa6f68de
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-complete.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Installation Complete! Next Steps
+ Congratulations! You have now installed &PRODUCT; Management Server and the database it uses to persist system data.
+
+
+
+
+ installation-complete.png: Finished installs with single Management Server and multiple Management Servers
+
+ What should you do next?
+
+ Even without adding any cloud infrastructure, you can run the UI to get a feel for what's offered and how you will interact with &PRODUCT; on an ongoing basis. See Log In to the UI.
+ When you're ready, add the cloud infrastructure and try running some virtual machines on it, so you can watch how &PRODUCT; manages the infrastructure. See Provision Your Cloud Infrastructure.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-db-external.xml b/docs/tmp/en-US/xml_tmp/management-server-install-db-external.xml
new file mode 100644
index 00000000000..a749dc76c0d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-db-external.xml
@@ -0,0 +1,115 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Install the Database on a Separate Node
+ This section describes how to install MySQL on a standalone machine, separate from the Management Server.
+ This technique is intended for a deployment that includes several Management Server nodes.
+ If you have a single-node Management Server deployment, you will typically use the same node for MySQL.
+ See .
+
+
+ The management server doesn't require a specific distribution for the MySQL node.
+ You can use a distribution or Operating System of your choice.
+ Using the same distribution as the management server is recommended, but not required.
+ See .
+
+
+
+
+ Install MySQL from the package repository from your distribution:
+ On RHEL or CentOS:
+ yum install mysql-server
+ On Ubuntu:
+ apt-get install mysql-server
+
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS)
+ and insert the following lines in the [mysqld] section. You can put these lines below the datadir
+ line. The max_connections parameter should be set to 350 multiplied by the number of Management
+ Servers you are deploying. This example assumes two Management Servers.
+
+ On Ubuntu, you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add
+ these directives there. Don't forget to add [mysqld] on the first line of the
+ file.
+
+ innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=700
+log-bin=mysql-bin
+binlog-format = 'ROW'
+bind-address = 0.0.0.0
+
+
+ Start or restart MySQL to put the new configuration into effect.
+ On RHEL/CentOS,
+ MySQL doesn't automatically start after installation. Start it manually.
+ service mysqld start
+ On Ubuntu, restart MySQL.
+ service mysqld restart
+
+
+ (CentOS and RHEL only; not required on Ubuntu)
+
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very
+ strongly recommended that you set a root password as a security precaution.
+
+ Run the following command to secure your installation. You can answer "Y" to all
+ questions except "Disallow root login remotely?". Remote root login is required to
+ set up the databases.
+ mysql_secure_installation
+
+ If a firewall is present on the system, open TCP port 3306 so external MySQL connections can be established.
+ On Ubuntu, UFW is the default firewall. Open the port with this command:
+ ufw allow mysql
+ On RHEL/CentOS:
+
+
+ Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the INPUT chain.
+ -A INPUT -p tcp --dport 3306 -j ACCEPT
+
+
+ Now reload the iptables rules.
+ service iptables restart
+
+
+
+ Return to the root shell on your first Management Server.
+
+ Set up the database. The following command creates the cloud user on the database.
+
+ In dbpassword, specify the password to be assigned to the cloud user. You can choose to provide no password.
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the cloud user.
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ cloud-setup-databases cloud:<dbpassword>@<ip address mysql server> \
+ --deploy-as=root:<password> \
+ -e <encryption_type> \
+ -m <management_server_key> \
+ -k <database_key>
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-db-local.xml b/docs/tmp/en-US/xml_tmp/management-server-install-db-local.xml
new file mode 100644
index 00000000000..9880c54571b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-db-local.xml
@@ -0,0 +1,89 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Install the Database on the Management Server Node
+ This section describes how to install MySQL on the same machine with the Management Server. This technique is intended for a simple deployment that has a single Management Server node. If you have a multi-node Management Server deployment, you will typically use a separate node for MySQL. See .
+
+
+ Install MySQL from the package repository from your distribution:
+ On RHEL or CentOS:
+ yum install mysql-server
+ On Ubuntu:
+ apt-get install mysql-server
+
+
+ Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and insert the following lines in the [mysqld] section. You can put these lines below the datadir line. The max_connections parameter should be set to 350 multiplied by the number of Management Servers you are deploying. This example assumes one Management Server.
+
+ On Ubuntu, you can also create a file /etc/mysql/conf.d/cloudstack.cnf and add these directives there. Don't forget to add [mysqld] on the first line of the file.
+
+ innodb_rollback_on_timeout=1
+innodb_lock_wait_timeout=600
+max_connections=350
+log-bin=mysql-bin
+binlog-format = 'ROW'
+
+
+ Start or restart MySQL to put the new configuration into effect.
+ On RHEL/CentOS,
+ MySQL doesn't automatically start after installation. Start it manually.
+ service mysqld start
+ On Ubuntu, restart MySQL.
+ service mysqld restart
+
+
+ (CentOS and RHEL only; not required on Ubuntu)
+
+ On RHEL and CentOS, MySQL does not set a root password by default. It is very
+ strongly recommended that you set a root password as a security precaution.
+
+ Run the following command to secure your installation. You can answer "Y" to all
+ questions.
+ mysql_secure_installation
+
+ Set up the database. The following command creates the "cloud" user on the database.
+
+ In dbpassword, specify the password to be assigned to the "cloud" user. You can choose to provide no password although that is not recommended.
+ In deploy-as, specify the username and password of the user deploying the database. In the following command, it is assumed the root user is deploying the database and creating the "cloud" user.
+ (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file. See About Password and Key Encryption.
+ (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; properties file. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+ (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; database. Default: password. It is highly recommended that you replace this with a more secure value. See About Password and Key Encryption.
+
+ cloud-setup-databases cloud:<dbpassword>@localhost \
+ --deploy-as=root:<password> \
+ -e <encryption_type> \
+ -m <management_server_key> \
+ -k <database_key>
+ When this script is finished, you should see a message like “Successfully initialized the database.”
+
+ If you are running the KVM hypervisor on the same machine with the Management Server, edit /etc/sudoers and add the following line:
+ Defaults:cloud !requiretty
+ This type of single-machine setup is recommended only for a trial installation.
+
+ Now that the database is set up, you can finish configuring the OS for the Management Server. This command will set up iptables, sudoers, and start the Management Server.
+ # cloud-setup-management
+ You should see the message “&PRODUCT; Management Server setup is done.”
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-db.xml b/docs/tmp/en-US/xml_tmp/management-server-install-db.xml
new file mode 100644
index 00000000000..9d41af2562b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-db.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Install the database server
+ The &PRODUCT; management server uses a MySQL database server to store its data.
+ When you are installing the management server on a single node, you can install the MySQL server locally.
+ For an installation that has multiple management server nodes, we assume the MySQL database also runs on a separate node.
+
+ &PRODUCT; has been tested with MySQL 5.1 and 5.5. These versions are included in RHEL/CentOS and Ubuntu.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-flow.xml b/docs/tmp/en-US/xml_tmp/management-server-install-flow.xml
new file mode 100644
index 00000000000..33bcac9c85b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-flow.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Management Server Installation
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-multi-node.xml b/docs/tmp/en-US/xml_tmp/management-server-install-multi-node.xml
new file mode 100644
index 00000000000..e61f6230ff0
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-multi-node.xml
@@ -0,0 +1,72 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Prepare and Start Additional Management Servers
+ For your second and subsequent Management Servers, you will install the Management Server
+ software, connect it to the database, and set up the OS for the Management Server.
+
+
+ Perform the steps in and or as
+ appropriate.
+
+
+ This step is required only for installations where XenServer is installed on the hypervisor hosts.
+ Download vhd-util from vhd-util
+ If the Management Server is RHEL or CentOS, copy vhd-util to
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver.
+ If the Management Server is Ubuntu, copy vhd-util to
+ /usr/lib/cloud/common/scripts/vm/hypervisor/xenserver/vhd-util.
+
+
+ Ensure that necessary services are started and set to start on boot.
+ # service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+
+
+
+
+ Configure the database client. Note the absence of the --deploy-as argument in this
+ case. (For more details about the arguments to this command, see .)
+ # cloud-setup-databases cloud:dbpassword@dbhost -e encryption_type -m management_server_key -k database_key
+
+
+
+ Configure the OS and start the Management Server:
+ # cloud-setup-management
+ The Management Server on this node should now be running.
+
+
+ Repeat these steps on each additional Management Server.
+
+
+ Be sure to configure a load balancer for the Management Servers. See Management Server
+ Load Balancing.
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-nfs-shares.xml b/docs/tmp/en-US/xml_tmp/management-server-install-nfs-shares.xml
new file mode 100644
index 00000000000..28e3fa30de1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-nfs-shares.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Prepare NFS Shares
+ &PRODUCT; needs a place to keep primary and secondary storage (see Cloud Infrastructure Overview). Both of these can be NFS shares. This section tells how to set up the NFS shares before adding the storage to &PRODUCT;.
+ For primary storage, you can use iSCSI instead.
+ The requirements for primary and secondary storage are described in:
+
+ About Primary Storage
+ About Secondary Storage
+
+ A production installation typically uses a separate NFS server. See .
+ You can also use the Management Server node as the NFS server. This is more typical of a trial installation, but is technically possible in a larger deployment. See .
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-overview.xml b/docs/tmp/en-US/xml_tmp/management-server-install-overview.xml
new file mode 100644
index 00000000000..5f46b0099bd
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-overview.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Management Server Installation Overview
+ This section describes installing the Management Server. There are two slightly different installation flows, depending on how many Management Server nodes will be in your cloud:
+
+ A single Management Server node, with MySQL on the same node.
+ Multiple Management Server nodes, with MySQL on a node separate from the Management Servers.
+
+ In either case, each machine must meet the system requirements described in System Requirements.
+ For the sake of security, be sure the public Internet can not access port 8096 or port 8250 on the Management Server.
+ The procedure for installing the Management Server is:
+
+
+ Prepare the Operating System
+
+
+ (XenServer only) Download and install vhd-util.
+
+ Install the First Management Server
+ Install and Configure the MySQL database
+ Prepare NFS Shares
+ Prepare and Start Additional Management Servers (optional)
+ Prepare the System VM Template
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-prepare-os.xml b/docs/tmp/en-US/xml_tmp/management-server-install-prepare-os.xml
new file mode 100644
index 00000000000..ef78731e81a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-prepare-os.xml
@@ -0,0 +1,54 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Prepare the Operating System
+ The OS must be prepared to host the Management Server using the following steps. These steps must be performed on each Management Server node.
+
+ Log in to your OS as root.
+
+ Check for a fully qualified hostname.
+ hostname --fqdn
+ This should return a fully qualified hostname such as "managament1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+
+ Make sure that the machine can reach the Internet.
+ ping www.cloudstack.org
+
+
+ Turn on NTP for time synchronization.
+ NTP is required to synchronize the clocks of the servers in your cloud.
+
+
+ Install NTP.
+ On RHEL or CentOS:
+ yum install ntp
+ On Ubuntu:
+ apt-get install openntpd
+
+
+
+ Repeat all of these steps on every host where the Management Server will be installed.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-install-systemvm.xml b/docs/tmp/en-US/xml_tmp/management-server-install-systemvm.xml
new file mode 100644
index 00000000000..6cd1ef7a0ff
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-install-systemvm.xml
@@ -0,0 +1,71 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Prepare the System VM Template
+ Secondary storage must be seeded with a template that is used for &PRODUCT; system
+ VMs.
+
+ When copying and pasting a command, be sure the command has pasted as a single line before
+ executing. Some document viewers may introduce unwanted line breaks in copied text.
+
+
+
+ On the Management Server, run one or more of the following cloud-install-sys-tmplt
+ commands to retrieve and decompress the system VM template. Run the command for each
+ hypervisor type that you expect end users to run in this Zone.
+ If your secondary storage mount point is not named /mnt/secondary, substitute your own
+ mount point name.
+ If you set the &PRODUCT; database encryption type to "web" when you set up the database,
+ you must now add the parameter -s <management-server-secret-key>. See About Password
+ and Key Encryption.
+ This process will require approximately 5 GB of free space on the local file system and
+ up to 30 minutes each time it runs.
+
+
+ For XenServer:
+ # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 -h xenserver -s <optional-management-server-secret-key> -F
+
+
+ For vSphere:
+ # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova -h vmware -s <optional-management-server-secret-key> -F
+
+
+ For KVM:
+ # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -s <optional-management-server-secret-key> -F
+
+
+
+
+ If you are using a separate NFS server, perform this step. If you are using the
+ Management Server as the NFS server, you MUST NOT perform this step.
+ When the script has finished, unmount secondary storage and remove the created
+ directory.
+ # umount /mnt/secondary
+# rmdir /mnt/secondary
+
+
+ Repeat these steps for each secondary storage server.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-installation-overview.xml b/docs/tmp/en-US/xml_tmp/management-server-installation-overview.xml
new file mode 100644
index 00000000000..3ccbdccfc9b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-installation-overview.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Management Server Installation Overview
+ This section describes installing the Management Server. There are two slightly different installation flows, depending on how many Management Server nodes will be in your cloud:
+
+ A single Management Server node, with MySQL on the same node.
+ Multiple Management Server nodes, with MySQL on a node separate from the Management Servers.
+
+ In either case, each machine must meet the system requirements described in System Requirements.
+ For the sake of security, be sure the public Internet can not access port 8096 or port 8250 on the Management Server.
+
+ The procedure for installing the Management Server is:
+
+
+ Prepare the Operating System
+ Install the First Management Server
+ Install and Configure the Database
+ Prepare NFS Shares
+ Prepare and Start Additional Management Servers (optional)
+ Prepare the System VM Template
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-lb.xml b/docs/tmp/en-US/xml_tmp/management-server-lb.xml
new file mode 100644
index 00000000000..c62e1efc0a0
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-lb.xml
@@ -0,0 +1,61 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Setting Zone VLAN and Running VM Maximums
+ CloudPlatform can use a load balancer to provide a virtual IP for multiple Management
+ Servers. The administrator is responsible for creating the load balancer rules for the
+ Management Servers. The application requires persistence or stickiness across multiple sessions.
+ The following chart lists the ports that should be load balanced and whether or not persistence
+ is required.
+ Even if persistence is not required, enabling it is permitted.
+
+
+
+
+ Source Port
+ Destination Port
+ Protocol
+ Persistence Required?
+
+
+
+
+ 80 or 443
+ 8080 (or 20400 with AJP)
+ HTTP (or AJP)
+ Yes
+
+
+ 8250
+ 8250
+ TCP
+ Yes
+
+
+ 8096
+ 8096
+ HTTP
+ No
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management-server-overview.xml b/docs/tmp/en-US/xml_tmp/management-server-overview.xml
new file mode 100644
index 00000000000..b8e2d53f052
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management-server-overview.xml
@@ -0,0 +1,76 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Management Server Overview
+
+ The Management Server is the &PRODUCT; software that manages cloud
+ resources. By interacting with the Management Server through its UI or
+ API, you can configure and manage your cloud infrastructure.
+
+
+ The Management Server runs on a dedicated server or VM. It controls
+ allocation of virtual machines to hosts and assigns storage and IP
+ addresses to the virtual machine instances. The Management Server
+ runs in a Tomcat container and requires a MySQL database for persistence.
+
+
+ The machine must meet the system requirements described in System
+ Requirements.
+
+ The Management Server:
+
+
+
+
+ Provides the web user interface for the administrator and a
+ reference user interface for end users.
+
+
+
+ Provides the APIs for &PRODUCT;.
+
+
+ Manages the assignment of guest VMs to particular hosts.
+
+
+
+ Manages the assignment of public and private IP addresses to
+ particular accounts.
+
+
+
+ Manages the allocation of storage to guests as virtual disks.
+
+
+
+ Manages snapshots, templates, and ISO images, possibly
+ replicating them across data centers.
+
+
+
+ Provides a single point of configuration for the cloud.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management_server_multi_node_install.xml b/docs/tmp/en-US/xml_tmp/management_server_multi_node_install.xml
new file mode 100644
index 00000000000..30f6af9f6a7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management_server_multi_node_install.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Management Server Multi-Node Installation
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/management_server_overview.xml b/docs/tmp/en-US/xml_tmp/management_server_overview.xml
new file mode 100644
index 00000000000..b5d74f38a8b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/management_server_overview.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Management Server Overview
+ The Management Server is the &PRODUCT; software that manages cloud resources. By interacting with the Management Server through its UI or API, you can configure and manage your cloud infrastructure.
+ The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines to hosts and assigns storage and IP addresses to the virtual machine instances. The &PRODUCT; Management Server runs in a Tomcat container and requires a MySQL database for persistence.
+ The machine must meet the system requirements described in System Requirements.
+ The Management Server:
+
+
+ Provides the web user interface for the administrator and a reference user interface for end users.
+
+
+ Provides the APIs for the &PRODUCT; platform.
+
+
+ Manages the assignment of guest VMs to particular hosts.
+
+
+ Manages the assignment of public and private IP addresses to particular accounts.
+
+
+ Manages the allocation of storage to guests as virtual disks.
+
+
+ Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
+
+
+ Provides a single point of configuration for the cloud.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/manual-live-migration.xml b/docs/tmp/en-US/xml_tmp/manual-live-migration.xml
new file mode 100644
index 00000000000..30a5c11a07f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/manual-live-migration.xml
@@ -0,0 +1,52 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Moving VMs Between Hosts (Manual Live Migration)
+ The CloudPlatform administrator can move a running VM from one host to another without interrupting service to users or going into maintenance mode. This is called manual live migration, and can be done under the following conditions:
+
+ The root administrator is logged in. Domain admins and users can not perform manual live migration of VMs.
+ The VM is running. Stopped VMs can not be live migrated.
+ The destination host must be in the same cluster as the original host.
+ The VM must not be using local disk storage.
+ The destination host must have enough available capacity. If not, the VM will remain in the "migrating" state until memory becomes available.
+
+
+ To manually live migrate a virtual machine
+
+ Log in to the CloudPlatform UI as a user or admin.
+ In the left navigation, click Instances.
+ Choose the VM that you want to migrate.
+ Click the Migrate Instance button
+
+
+
+ Migrateinstance.png: button to migrate an instance
+
+
+ From the list of hosts, choose the one to which you want to move the VM.
+ Click OK.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/max-result-page-returned.xml b/docs/tmp/en-US/xml_tmp/max-result-page-returned.xml
new file mode 100644
index 00000000000..fdbf63962d4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/max-result-page-returned.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Maximum Result Pages Returned
+
+ For each cloud, there is a default upper limit on the number of results that any API command will return in a single page. This is to help prevent overloading the cloud servers and prevent DOS attacks. For example, if the page size limit is 500 and a command returns 10,000 results, the command will return 20 pages.
+
+ The default page size limit can be different for each cloud. It is set in the global configuration parameter default.page.size. If your cloud has many users with lots of VMs, you might need to increase the value of this parameter. At the same time, be careful not to set it so high that your site can be taken down by an enormous return from an API call. For more information about how to set global configuration parameters, see "Describe Your Deployment" in the Installation Guide.
+ To decrease the page size limit for an individual API command, override the global setting with the page and pagesize parameters, which are available in any list* command (listCapabilities, listDiskOfferings, etc.).
+
+ Both parameters must be specified together.
+ The value of the pagesize parameter must be smaller than the value of default.page.size. That is, you can not increase the number of possible items in a result page, only decrease it.
+
+ For syntax information on the list* commands, see the API Reference.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/migrate-datadisk-volume-new-storage-pool.xml b/docs/tmp/en-US/xml_tmp/migrate-datadisk-volume-new-storage-pool.xml
new file mode 100644
index 00000000000..552fb319341
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/migrate-datadisk-volume-new-storage-pool.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Migrating a Data Disk Volume to a New Storage Pool
+
+ Log in to the &PRODUCT; UI as a user or admin.
+ Detach the data disk from the VM. See Detaching and Moving Volumes (but skip the “reattach” step at the end. You will do that after migrating to new storage).
+ Call the &PRODUCT; API command migrateVolume and pass in the volume ID and the ID of any storage pool in the zone.
+ Watch for the volume status to change to Migrating, then back to Ready.
+ Attach the volume to any desired VM running in the same cluster as the new storage server. See Attaching a Volume
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/migrate-vm-rootvolume-volume-new-storage-pool.xml b/docs/tmp/en-US/xml_tmp/migrate-vm-rootvolume-volume-new-storage-pool.xml
new file mode 100644
index 00000000000..67fe2f58920
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/migrate-vm-rootvolume-volume-new-storage-pool.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Migrating a VM Root Volume to a New Storage Pool
+ When migrating the root disk volume, the VM must first be stopped, and users can not access the VM. After migration is complete, the VM can be restarted.
+
+ Log in to the &PRODUCT; UI as a user or admin.
+ Detach the data disk from the VM. See Detaching and Moving Volumes (but skip the “reattach” step at the end. You will do that after migrating to new storage).
+ Stop the VM.
+ Call the &PRODUCT; API command migrateVirtualMachine with the ID of the VM to migrate and the IDs of a destination host and destination storage pool in the same zone.
+ Watch for the VM status to change to Migrating, then back to Stopped.
+ Restart the VM.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/minimum-system-requirements.xml b/docs/tmp/en-US/xml_tmp/minimum-system-requirements.xml
new file mode 100644
index 00000000000..dcab0398dc7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/minimum-system-requirements.xml
@@ -0,0 +1,70 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Minimum System Requirements
+
+ Management Server, Database, and Storage System Requirements
+ The machines that will run the Management Server and MySQL database must meet the following requirements. The same machines can also be used to provide primary and secondary storage, such as via localdisk or NFS. The Management Server may be placed on a virtual machine.
+
+ Operating system:
+
+ Preferred: CentOS/RHEL 6.3+ or Ubuntu 12.04(.1)
+
+
+ 64-bit x86 CPU (more cores results in better performance)
+ 4 GB of memory
+ 50 GB of local disk (When running secondary storage on the management server 500GB is recommended)
+ At least 1 NIC
+ Statically allocated IP address
+ Fully qualified domain name as returned by the hostname command
+
+
+
+ Host/Hypervisor System Requirements
+ The host is where the cloud services run in the form of guest virtual machines. Each host is one machine that meets the following requirements:
+
+ Must support HVM (Intel-VT or AMD-V enabled).
+ 64-bit x86 CPU (more cores results in better performance)
+ Hardware virtualization support required
+ 4 GB of memory
+ 36 GB of local disk
+ At least 1 NIC
+ If DHCP is used for hosts, ensure that no conflict occurs between DHCP server used for these hosts and the DHCP router created by &PRODUCT;.
+ Latest hotfixes applied to hypervisor software
+ When you deploy &PRODUCT;, the hypervisor host must not have any VMs already running
+ All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags.
+
+ Hosts have additional requirements depending on the hypervisor. See the requirements listed at the top of the Installation section for your chosen hypervisor:
+
+ Be sure you fulfill the additional hypervisor requirements and installation steps provided in this Guide. Hypervisor hosts must be properly prepared to work with CloudStack. For example, the requirements for XenServer are listed under Citrix XenServer Installation.
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/modify-delete-service-offerings.xml b/docs/tmp/en-US/xml_tmp/modify-delete-service-offerings.xml
new file mode 100644
index 00000000000..b917af48252
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/modify-delete-service-offerings.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Modifying or Deleting a Service Offering
+ Service offerings cannot be changed once created. This applies to both compute offerings and disk offerings.
+ A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently. If the service offering is still in use, it will remain in the database until all the virtual machines referencing it have been deleted. After deletion by the administrator, a service offering will not be available to end users that are creating new instances.
+
diff --git a/docs/tmp/en-US/xml_tmp/multi_node_management_server.xml b/docs/tmp/en-US/xml_tmp/multi_node_management_server.xml
new file mode 100644
index 00000000000..1ff713dbd16
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/multi_node_management_server.xml
@@ -0,0 +1,36 @@
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Multi-Node Management Server
+ The &PRODUCT; Management Server is deployed on one or more front-end servers connected to a single MySQL database. Optionally a pair of hardware load balancers distributes requests from the web. A backup management server set may be deployed using MySQL replication at a remote site to add DR capabilities.
+
+
+
+
+ Multi-Node Management Server
+
+ The administrator must decide the following.
+
+ Whether or not load balancers will be used.
+ How many Management Servers will be deployed.
+ Whether MySQL replication will be deployed to enable disaster recovery.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/multi_node_overview.xml b/docs/tmp/en-US/xml_tmp/multi_node_overview.xml
new file mode 100644
index 00000000000..1eee0377ba9
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/multi_node_overview.xml
@@ -0,0 +1,43 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Management Server Multi-Node Installation Overview
+
+ This section describes installing multiple Management Servers and installing MySQL on a node separate from the Management Servers. The machines must meet the system requirements described in System Requirements.
+
+ For the sake of security, be sure the public Internet can not access port 8096 or port 8250 on the Management Server.
+
+ The procedure for a multi-node installation is:
+
+
+ Prepare the Operating System
+ Install the First Management Server
+ Install and Configure the Database
+ Prepare NFS Shares
+ Prepare and Start Additional Management Servers
+ Prepare the System VM Template
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/multi_site_deployment.xml b/docs/tmp/en-US/xml_tmp/multi_site_deployment.xml
new file mode 100644
index 00000000000..8ad94aa2a70
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/multi_site_deployment.xml
@@ -0,0 +1,50 @@
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Multi-Site Deployment
+ The &PRODUCT; platform scales well into multiple sites through the use of zones. The following diagram shows an example of a multi-site deployment.
+
+
+
+
+ Example Of A Multi-Site Deployment
+
+ Data Center 1 houses the primary Management Server as well as zone 1. The MySQL database is replicated in real time to the secondary Management Server installation in Data Center 2.
+
+
+
+
+ Separate Storage Network
+
+ This diagram illustrates a setup with a separate storage network. Each server has four NICs, two connected to pod-level network switches and two connected to storage network switches.
+ There are two ways to configure the storage network:
+
+ Bonded NIC and redundant switches can be deployed for NFS. In NFS deployments, redundant switches and bonded NICs still result in one network (one CIDR block+ default gateway address).
+ iSCSI can take advantage of two separate storage networks (two CIDR blocks each with its own default gateway). Multipath iSCSI client can failover and load balance between separate storage networks.
+
+
+
+
+
+ NIC Bonding And Multipath I/O
+
+ This diagram illustrates the differences between NIC bonding and Multipath I/O (MPIO). NIC bonding configuration involves only one network. MPIO involves two separate networks.
+
diff --git a/docs/tmp/en-US/xml_tmp/multiple-system-vm-vmware.xml b/docs/tmp/en-US/xml_tmp/multiple-system-vm-vmware.xml
new file mode 100644
index 00000000000..014dfa1f329
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/multiple-system-vm-vmware.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Multiple System VM Support for VMware
+ Every &PRODUCT; zone has single System VM for template processing tasks such as downloading templates, uploading templates, and uploading ISOs. In a zone where VMware is being used, additional System VMs can be launched to process VMware-specific tasks such as taking snapshots and creating private templates. The &PRODUCT; management server launches additional System VMs for VMware-specific tasks as the load increases. The management server monitors and weights all commands sent to these System VMs and performs dynamic load balancing and scaling-up of more System VMs.
+
diff --git a/docs/tmp/en-US/xml_tmp/network-offering-usage-record-format.xml b/docs/tmp/en-US/xml_tmp/network-offering-usage-record-format.xml
new file mode 100644
index 00000000000..a1b0da96221
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/network-offering-usage-record-format.xml
@@ -0,0 +1,43 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Network Offering Usage Record Format
+
+ account – name of the account
+ accountid – ID of the account
+ domainid – ID of the domain in which this account resides
+ zoneid – Zone where the usage occurred
+ description – A string describing what the usage record is tracking
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ usagetype – A number representing the usage type (see Usage Types)
+ rawusage – A number representing the actual usage in hours
+ usageid – ID of the network offering
+ usagetype – A number representing the usage type (see Usage Types)
+ offeringid – Network offering ID
+ virtualMachineId – The ID of the virtual machine
+ virtualMachineId – The ID of the virtual machine
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
diff --git a/docs/tmp/en-US/xml_tmp/network-offerings.xml b/docs/tmp/en-US/xml_tmp/network-offerings.xml
new file mode 100644
index 00000000000..ccfb93cc4cc
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/network-offerings.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Network Offerings
+ For the most up-to-date list of supported network services, see the CloudPlatform UI or call listNetworkServices.
+ A network offering is a named set of network services, such as:
+
+ DHCP
+ DNS
+ Source NAT
+ Static NAT
+ Port Forwarding
+ Load Balancing
+ Firewall
+ VPN
+ Optional) Name one of several available providers to use for a given service, such as Juniper for the firewall
+ (Optional) Network tag to specify which physical network to use
+
+ When creating a new VM, the user chooses one of the available network offerings, and that determines which network services the VM can use.
+ The CloudPlatform administrator can create any number of custom network offerings, in addition to the default network offerings provided by CloudPlatform. By creating multiple custom network offerings, you can set up your cloud to offer different classes of service on a single multi-tenant physical network. For example, while the underlying physical wiring may be the same for two tenants, tenant A may only need simple firewall protection for their website, while tenant B may be running a web server farm and require a scalable firewall solution, load balancing solution, and alternate networks for accessing the database backend.
+ If you create load balancing rules while using a network service offering that includes an external load balancer device such as NetScaler, and later change the network service offering to one that uses the CloudPlatform virtual router, you must create a firewall rule on the virtual router for each of your existing load balancing rules so that they continue to function.
+ When creating a new virtual network, the CloudPlatform administrator chooses which network offering to enable for that network. Each virtual network is associated with one network offering. A virtual network can be upgraded or downgraded by changing its associated network offering. If you do this, be sure to reprogram the physical network to match.
+ CloudPlatform also has internal network offerings for use by CloudPlatform system VMs. These network offerings are not visible to users but can be modified by administrators.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/network-service-providers.xml b/docs/tmp/en-US/xml_tmp/network-service-providers.xml
new file mode 100644
index 00000000000..af570977259
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/network-service-providers.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Network Service Providers
+ For the most up-to-date list of supported network service providers, see the CloudPlatform UI or call listNetworkServiceProviders.
+ A service provider (also called a network element) is hardware or virtual appliance that makes a network service possible; for example, a firewall appliance can be installed in the cloud to provide firewall service. On a single network, multiple providers can provide the same network service. For example, a firewall service may be provided by Cisco or Juniper devices in the same physical network.
+ You can have multiple instances of the same service provider in a network (say, more than one Juniper SRX device).
+ If different providers are set up to provide the same service on the network, the administrator can create network offerings so users can specify which network service provider they prefer (along with the other choices offered in network offerings). Otherwise, CloudPlatform will choose which provider to use whenever the service is called for.
+
+ Supported Network Service Providers
+ CloudPlatform ships with an internal list of the supported service providers, and you can choose from this list when creating a network offering.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/network-setup.xml b/docs/tmp/en-US/xml_tmp/network-setup.xml
new file mode 100644
index 00000000000..153227df83f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/network-setup.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Network Setup
+ Achieving the correct networking setup is crucial to a successful &PRODUCT;
+ installation. This section contains information to help you make decisions and follow the right
+ procedures to get your network set up correctly.
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/network-usage-record-format.xml b/docs/tmp/en-US/xml_tmp/network-usage-record-format.xml
new file mode 100644
index 00000000000..34b8f2d4955
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/network-usage-record-format.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Network Usage Record Format
+ For network usage (bytes sent/received), the following fields exist in a usage record.
+
+ account – name of the account
+ accountid – ID of the account
+ domainid – ID of the domain in which this account resides
+ zoneid – Zone where the usage occurred
+ description – A string describing what the usage record is tracking
+ usagetype – A number representing the usage type (see Usage Types)
+ rawusage – A number representing the actual usage in hours
+ usageid – Device ID (virtual router ID or external device ID)
+ type – Device type (domain router, external load balancer, etc.)
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
diff --git a/docs/tmp/en-US/xml_tmp/networking-in-a-pod.xml b/docs/tmp/en-US/xml_tmp/networking-in-a-pod.xml
new file mode 100644
index 00000000000..81f08271874
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/networking-in-a-pod.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Networking in a Pod
+ Figure 2 illustrates network setup within a single pod. The hosts are connected to a pod-level switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
+
+
+
+
+ networking-in-a-pod.png: Network setup in a pod
+
+ Servers are connected as follows:
+
+ Storage devices are connected to only the network that carries management traffic.
+ Hosts are connected to networks for both management traffic and public traffic.
+ Hosts are also connected to one or more networks carrying guest traffic.
+
+ We recommend the use of multiple physical Ethernet cards to implement each network interface as well as redundant switch fabric in order to maximize throughput and improve reliability.
+
diff --git a/docs/tmp/en-US/xml_tmp/networking-in-a-zone.xml b/docs/tmp/en-US/xml_tmp/networking-in-a-zone.xml
new file mode 100644
index 00000000000..c380c33dd94
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/networking-in-a-zone.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Networking in a Zone
+ Figure 3 illustrates the network setup within a single zone.
+
+
+
+
+ networking-in-a-zone.png: Network setup in a single zone
+
+ A firewall for management traffic operates in the NAT mode. The network typically is assigned IP addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses in the 192.168.*.0/24 Class C private address space.
+ Each zone has its own set of public IP addresses. Public IP addresses from different zones do not overlap.
+
diff --git a/docs/tmp/en-US/xml_tmp/networking-overview.xml b/docs/tmp/en-US/xml_tmp/networking-overview.xml
new file mode 100644
index 00000000000..798fd7a8bd8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/networking-overview.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Networking Overview
+
+ &PRODUCT; offers two types of networking scenario:
+
+
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+ For more details, see Network Setup.
+
diff --git a/docs/tmp/en-US/xml_tmp/networking_overview.xml b/docs/tmp/en-US/xml_tmp/networking_overview.xml
new file mode 100644
index 00000000000..a5f27c31402
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/networking_overview.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Networking Overview
+
+ CloudStack offers two types of networking scenario:
+
+
+ Basic. For AWS-style networking. Provides a single network where guest isolation can be provided through layer-3 means such as security groups (IP address source filtering).
+ Advanced. For more sophisticated network topologies. This network model provides the most flexibility in defining guest networks.
+
+ For more details, see Network Setup.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/networks-for-users-overview.xml b/docs/tmp/en-US/xml_tmp/networks-for-users-overview.xml
new file mode 100644
index 00000000000..19602c48b2a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/networks-for-users-overview.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Overview of Setting Up Networking for Users
+ People using cloud infrastructure have a variety of needs and preferences when it comes to the networking services provided by the cloud. As a &PRODUCT; administrator, you can do the following things to set up networking for your users:
+
+ Set up physical networks in zones
+ Set up several different providers for the same service on a single physical network (for example, both Cisco and Juniper firewalls)
+ Bundle different types of network services into network offerings, so users can choose the desired network services for any given virtual machine
+ Add new network offerings as time goes on so end users can upgrade to a better class of service on their network
+ Provide more ways for a network to be accessed by a user, such as through a project of which the user is a member
+
+
diff --git a/docs/tmp/en-US/xml_tmp/networks.xml b/docs/tmp/en-US/xml_tmp/networks.xml
new file mode 100644
index 00000000000..a7b9ea12466
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/networks.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Managing Networks and Traffic
+ In a &PRODUCT;, guest VMs can communicate with each other using shared infrastructure with
+ the security and user perception that the guests have a private LAN. The &PRODUCT; virtual
+ router is the main component providing networking features for guest traffic.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/nfs-shares-on-management-server.xml b/docs/tmp/en-US/xml_tmp/nfs-shares-on-management-server.xml
new file mode 100644
index 00000000000..2c9b324d1a2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/nfs-shares-on-management-server.xml
@@ -0,0 +1,112 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using the Management Server As the NFS Server
+ This section tells how to set up NFS shares for primary and secondary storage on the same node with the Management Server. This is more typical of a trial installation, but is technically possible in a larger deployment. It is assumed that you will have less than 16TB of storage on the host.
+ The exact commands for the following steps may vary depending on your operating system version.
+
+ On the Management Server host, create two directories that you will use for primary and secondary storage. For example:
+
+# mkdir -p /export/primary
+# mkdir -p /export/secondary
+
+
+ To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s) with rw,async,no_root_squash. For example:
+ # vi /etc/exports
+ Insert the following line.
+ /export *(rw,async,no_root_squash)
+
+ Export the /export directory.
+ # exportfs -a
+
+ Edit the /etc/sysconfig/nfs file.
+ # vi /etc/sysconfig/nfs
+ Uncomment the following lines:
+
+LOCKD_TCPPORT=32803
+LOCKD_UDPPORT=32769
+MOUNTD_PORT=892
+RQUOTAD_PORT=875
+STATD_PORT=662
+STATD_OUTGOING_PORT=2020
+
+
+ Edit the /etc/sysconfig/iptables file.
+ # vi /etc/sysconfig/iptables
+ Add the following lines at the beginning of the INPUT chain where <NETWORK> is the network that you'll be using:
+
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 111 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 2049 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 32803 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 32769 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 892 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 875 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p tcp --dport 662 -j ACCEPT
+-A INPUT -s <NETWORK> -m state --state NEW -p udp --dport 662 -j ACCEPT
+
+
+ Run the following commands:
+
+# service iptables restart
+# service iptables save
+
+
+ If NFS v4 communication is used between client and server, add your domain to /etc/idmapd.conf on both the hypervisor host and Management Server.
+ # vi /etc/idmapd.conf
+ Remove the character # from the beginning of the Domain line in idmapd.conf and replace the value in the file with your own domain. In the example below, the domain is company.com.
+ Domain = company.com
+
+ Reboot the Management Server host.
+ Two NFS shares called /export/primary and /export/secondary are now set up.
+
+ It is recommended that you test to be sure the previous steps have been successful.
+
+ Log in to the hypervisor host.
+ Be sure NFS and rpcbind are running. The commands might be different depending on your OS. For example:
+
+# service rpcbind start
+# service nfs start
+# chkconfig nfs on
+# chkconfig rpcbind on
+# reboot
+
+
+ Log back in to the hypervisor host and try to mount the /export directories. For example (substitute your own management server name):
+
+# mkdir /primarymount
+# mount -t nfs <management-server-name>:/export/primary /primarymount
+# umount /primarymount
+# mkdir /secondarymount
+# mount -t nfs <management-server-name>:/export/secondary /secondarymount
+# umount /secondarymount
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/nfs-shares-on-separate-server.xml b/docs/tmp/en-US/xml_tmp/nfs-shares-on-separate-server.xml
new file mode 100644
index 00000000000..947106dcd4f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/nfs-shares-on-separate-server.xml
@@ -0,0 +1,52 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using a Separate NFS Server
+ This section tells how to set up NFS shares for secondary and (optionally) primary storage on an NFS server running on a separate node from the Management Server.
+ The exact commands for the following steps may vary depending on your operating system version.
+ (KVM only) Ensure that no volume is already mounted at your NFS mount point.
+
+ On the storage server, create an NFS share for secondary storage and, if you are using NFS for primary storage as well, create a second NFS share. For example:
+
+# mkdir -p /export/primary
+# mkdir -p /export/secondary
+
+
+ To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s) with rw,async,no_root_squash. For example:
+ # vi /etc/exports
+ Insert the following line.
+ /export *(rw,async,no_root_squash)
+
+ Export the /export directory.
+ # exportfs -a
+
+ On the management server, create a mount point for secondary storage. For example:
+ # mkdir -p /mnt/secondary
+
+ Mount the secondary storage on your Management Server. Replace the example NFS server name and NFS share paths below with your own.
+ # mount -t nfs nfsservername:/nfs/share/secondary /mnt/secondary
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/offerings.xml b/docs/tmp/en-US/xml_tmp/offerings.xml
new file mode 100644
index 00000000000..10252fd8af4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/offerings.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Service Offerings
+ In this chapter we discuss compute, disk, and system service offerings. Network offerings
+ are discussed in the section on setting up networking for users.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/ongoing-configuration-of-external-firewalls-loadbalancer.xml b/docs/tmp/en-US/xml_tmp/ongoing-configuration-of-external-firewalls-loadbalancer.xml
new file mode 100644
index 00000000000..6a02d27fb7b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ongoing-configuration-of-external-firewalls-loadbalancer.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Ongoing Configuration of External Firewalls and Load Balancers
+ Additional user actions (e.g. setting a port forward) will cause further programming of the firewall and load balancer. A user may request additional public IP addresses and forward traffic received at these IPs to specific VMs. This is accomplished by enabling static NAT for a public IP address, assigning the IP to a VM, and specifying a set of protocols and port ranges to open. When a static NAT rule is created, &PRODUCT; programs the zone's external firewall with the following objects:
+
+ A static NAT rule that maps the public IP address to the private IP address of a VM.
+ A security policy that allows traffic within the set of protocols and port ranges that are specified.
+ A firewall filter counter that measures the number of bytes of incoming traffic to the public IP.
+
+ The number of incoming and outgoing bytes through source NAT, static NAT, and load balancing rules is measured and saved on each external element. This data is collected on a regular basis and stored in the &PRODUCT; database.
+
diff --git a/docs/tmp/en-US/xml_tmp/over-provisioning-service-offering-limits.xml b/docs/tmp/en-US/xml_tmp/over-provisioning-service-offering-limits.xml
new file mode 100644
index 00000000000..64a162745e5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/over-provisioning-service-offering-limits.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Over-Provisioning and Service Offering Limits
+ &PRODUCT; performs CPU over-provisioning based on an over-provisioning ratio configured by the administrator. This is defined by the cpu.overprovisioning.factor global configuration variable.
+ &PRODUCT; performs CPU over-provisioning based on an over-provisioning ratio configured by the administrator. This is defined by the cpu.overprovisioning.factor global configuration variable
+ Service offerings 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. &PRODUCT; does not perform memory over-provisioning.
+
diff --git a/docs/tmp/en-US/xml_tmp/ovm-install.xml b/docs/tmp/en-US/xml_tmp/ovm-install.xml
new file mode 100644
index 00000000000..fa4a86b0776
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ovm-install.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Installing OVM for &PRODUCT;
+ TODO
+
+
diff --git a/docs/tmp/en-US/xml_tmp/ovm-requirements.xml b/docs/tmp/en-US/xml_tmp/ovm-requirements.xml
new file mode 100644
index 00000000000..70a8920a8ac
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ovm-requirements.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ System Requirements for OVM
+ TODO
+
diff --git a/docs/tmp/en-US/xml_tmp/per-domain-limits.xml b/docs/tmp/en-US/xml_tmp/per-domain-limits.xml
new file mode 100644
index 00000000000..c20e84d4a58
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/per-domain-limits.xml
@@ -0,0 +1,40 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Per-Domain Limits
+ &PRODUCT; allows the configuration of limits on a domain basis. With a domain limit in place, all users still have their account limits. They are additionally limited, as a group, to not exceed the resource limits set on their domain. Domain limits aggregate the usage of all accounts in the domain as well as all accounts in all subdomains of that domain. Limits set at the root domain level apply to the sum of resource usage by the accounts in all domains and sub-domains below that root domain.
+ To set a domain limit:
+
+ Log in to the &PRODUCT; UI.
+ In the left navigation tree, click Domains.
+ Select the domain you want to modify. The current domain limits are displayed. A value of -1 shows that there is no limit in place.
+ Click the Edit button
+
+
+
+ editbutton.png: edits the settings.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/performance-monitoring.xml b/docs/tmp/en-US/xml_tmp/performance-monitoring.xml
new file mode 100644
index 00000000000..70efbf783df
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/performance-monitoring.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Performance Monitoring
+ Host and guest performance monitoring is available to end users and administrators. This allows the user to monitor their utilization of resources and determine when it is appropriate to choose a more powerful service offering or larger disk.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/physical-network-configuration-settings.xml b/docs/tmp/en-US/xml_tmp/physical-network-configuration-settings.xml
new file mode 100644
index 00000000000..4ab18b01d30
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/physical-network-configuration-settings.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Configurable Characteristics of Physical Networks
+ &PRODUCT; provides configuration settings you can use to set up a physical network in a zone, including:
+
+ What type of network traffic it carries (guest, public, management, storage)
+ VLANs
+ Unique name that the hypervisor can use to find that particular network
+ Enabled or disabled. When a network is first set up, it is disabled – not in use yet. The administrator sets the physical network to enabled, and it begins to be used. The administrator can later disable the network again, which prevents any new virtual networks from being created on that physical network; the existing network traffic continues even though the state is disabled.
+ Speed
+ Tags, so network offerings can be matched to physical networks
+ Isolation method
+
+
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-about.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-about.xml
new file mode 100644
index 00000000000..8d2e20e7756
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-about.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ The Nicira NVP Plugin
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-devicemanagement.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-devicemanagement.xml
new file mode 100644
index 00000000000..2423ce3925d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-devicemanagement.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ Device-management
+ In CloudStack 4.0.x each Nicira NVP setup is considered a "device" that can be added and removed from a physical network. To complete the configuration of the Nicira NVP plugin a device needs to be added to the physical network using the "addNiciraNVPDevice" API call. The plugin is now enabled on the physical network and any guest networks created on that network will be provisioned using the Nicra NVP Controller.
+ The plugin introduces a set of new API calls to manage the devices, see below or refer to the API reference.
+
+ addNiciraNvpDevice
+
+
+ physicalnetworkid: the UUID of the physical network on which the device is configured
+ hostname: the IP address of the NVP controller
+ username: the username for access to the NVP API
+ password: the password for access to the NVP API
+ transportzoneuuid: the UUID of the transportzone
+
+
+ deleteNiciraNVPDevice
+
+
+ nvpdeviceid: the UUID of the device
+
+
+ listNiciraNVPDevices
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-features.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-features.xml
new file mode 100644
index 00000000000..b67323d56d2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-features.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ Features of the Nicira NVP Plugin
+ In CloudStack release 4.0.0-incubating this plugin supports the Connectivity service. This service is responsible for creating Layer 2 networks supporting the networks created by Guests. In other words when an tennant creates a new network, instead of the traditional VLAN a logical network will be created by sending the appropriate calls to the Nicira NVP Controller.
+ The plugin has been tested with Nicira NVP versions 2.1.0, 2.2.0 and 2.2.1
+ In CloudStack 4.0.0-incubating only the XenServer hypervisor is supported for use in combination with Nicira NVP
+ In CloudStack 4.0.0-incubating the UI components for this plugin are not complete, configuration is done by sending commands to the API
+
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-guide.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-guide.xml
new file mode 100644
index 00000000000..89c9871021d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-guide.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+
+ Plugin Guide for the Nicira NVP Plugin
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-introduction.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-introduction.xml
new file mode 100644
index 00000000000..9c1d42df32d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-introduction.xml
@@ -0,0 +1,26 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ Introduction to the Nicira NVP Plugin
+ The Nicira NVP plugin allows CloudStack to use the Nicira solution for virtualized network as a provider for CloudStack networks and services.
+
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-preparations.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-preparations.xml
new file mode 100644
index 00000000000..95a25bdca26
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-preparations.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ Prerequisites
+ Before enabling the Nicira NVP plugin the NVP Controller needs to be configured. Please review the NVP User Guide on how to do that.
+ CloudStack needs to have at least one physical network with the isolation method set to "STT". This network should be enabled for the Guest traffic type.
+ The Guest traffic type should be configured with the traffic label that matches the name of the Integration Bridge on XenServer. See the Nicira NVP User Guide for more details on how to set this up in XenServer.
+ Make sure you have the following information ready:
+
+ The IP address of the NVP Controller
+ The username to access the API
+ The password to access the API
+ The UUID of the Transport Zone that contains the hypervisors in this Zone
+ The UUID of the Physical Network that will used for the Guest networks
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-provider.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-provider.xml
new file mode 100644
index 00000000000..80fb2273238
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-provider.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ Enabling the service provider
+ To allow CloudStack to use the Nicira NVP Plugin the network service provider needs to be enabled on the physical network. The following sequence of API calls will enable the network service provider
+
+ addNetworkServiceProvider
+
+
+ name = "NiciraNvp"
+ physicalnetworkid = <the uuid of the physical network>
+
+
+ updateNetworkServiceProvider
+
+
+ id = <the provider uuid returned by the previous call>
+ state = "Enabled"
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-revisions.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-revisions.xml
new file mode 100644
index 00000000000..b8e6935c5d1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-revisions.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Revision History
+
+
+
+ 0-0
+ Wed Oct 03 2012
+
+ Hugo
+ Trippaers
+ hugo@apache.org
+
+
+
+ Documentation created for 4.0.0-incubating version of the NVP Plugin
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-tables.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-tables.xml
new file mode 100644
index 00000000000..4f816550b30
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-tables.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ Database tables
+ The following tables are added to the cloud database for the Nicira NVP Plugin
+
+ nicira_nvp_nic_map, contains a mapping from nic to logical switch port
+
+
+ id
+ logicalswitch, uuid of the logical switch this port is connected to
+ logicalswitchport, uuid of the logical switch port for this nic
+ nic, the CloudStack uuid for this nic, reference to the nics table
+
+
+
+
+ external_nicira_nvp_devices, contains all configured devices
+
+
+ id
+ uuid
+ physical_network_id, the physical network this device is configured on
+ provider_name, set to "NiciraNvp"
+ device_name, display name for this device
+ host_id, reference to the host table with the device configuration
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-troubleshooting.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-troubleshooting.xml
new file mode 100644
index 00000000000..02b06555914
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-troubleshooting.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ Troubleshooting the Nicira NVP Plugin
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-usage.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-usage.xml
new file mode 100644
index 00000000000..17413387ea4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-usage.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ Using the Nicira NVP Plugin
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/plugin-niciranvp-uuidreferences.xml b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-uuidreferences.xml
new file mode 100644
index 00000000000..c912971736b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/plugin-niciranvp-uuidreferences.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+
+%xinclude;
+]>
+
+
+ UUID References
+ The plugin maintains several references in the CloudStack database to items created on the NVP Controller.
+ Every guest network this is created will have its broadcast type set to Lswitch and if the network is in state "Implemented", the broadcast URI will have the UUID of the Logical Switch that was created for this network on the NVP Controller.
+ The Nics that are connected to one of the Logical Switches will have their Logical Switch Port UUID listed in the nicira_nvp_nic_map table
+ All devices created on the NVP Controller will have a tag set to domain-account of the owner of the network, this string can be used to search for items in the NVP Controller.
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/pod-add.xml b/docs/tmp/en-US/xml_tmp/pod-add.xml
new file mode 100644
index 00000000000..2a2b08753a9
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/pod-add.xml
@@ -0,0 +1,43 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Adding a Pod
+ When you created a new zone, &PRODUCT; adds the first pod for you. You can add more pods at any time using the procedure in this section.
+
+ Log in to the &PRODUCT; UI. See .
+ 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 &PRODUCT; 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.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/port-forwarding.xml b/docs/tmp/en-US/xml_tmp/port-forwarding.xml
new file mode 100644
index 00000000000..b7786936c4b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/port-forwarding.xml
@@ -0,0 +1,49 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Port Forwarding
+ A port forward service is a set of port forwarding rules that define a policy. A port forward service is then applied to one or more guest VMs. The guest VM then has its inbound network access managed according to the policy defined by the port forwarding service. You can optionally specify one or more CIDRs to filter the source IPs. This is useful when you want to allow only incoming requests from certain IP addresses to be forwarded.
+ A guest VM can be in any number of port forward services. Port forward services can be defined but have no members. If a guest VM is part of more than one network, port forwarding rules will function only if they are defined on the default network
+ You cannot use port forwarding to open ports for an elastic IP address. When elastic IP is used, outside access is instead controlled through the use of security groups. See Security Groups.
+ To set up port forwarding:
+
+ Log in to the CloudPlatform UI as an administrator or end user.
+ If you have not already done so, add a public IP address range to a zone in CloudPlatform. See Adding a Zone and Pod in the Installation Guide.
+ Add one or more VM instances to CloudPlatform.
+ In the left navigation bar, click Network.
+ Click the name of the guest network where the VMs are running.
+
+ Choose an existing IP address or acquire a new IP address. (See Acquiring a New IP Address on page 73.) Click the name of the IP address in the list.
+ Click the Configuration tab.
+ In the Port Forwarding node of the diagram, click View All.
+ Fill in the following:
+
+ Public Port. The port to which public traffic will be addressed on the IP address you acquired in the previous step.
+ Private Port. The port on which the instance is listening for forwarded public traffic.
+ Protocol. The communication protocol in use between the two ports.
+
+ Click Add.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/prepare-nfs-shares.xml b/docs/tmp/en-US/xml_tmp/prepare-nfs-shares.xml
new file mode 100644
index 00000000000..28e3fa30de1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/prepare-nfs-shares.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Prepare NFS Shares
+ &PRODUCT; needs a place to keep primary and secondary storage (see Cloud Infrastructure Overview). Both of these can be NFS shares. This section tells how to set up the NFS shares before adding the storage to &PRODUCT;.
+ For primary storage, you can use iSCSI instead.
+ The requirements for primary and secondary storage are described in:
+
+ About Primary Storage
+ About Secondary Storage
+
+ A production installation typically uses a separate NFS server. See .
+ You can also use the Management Server node as the NFS server. This is more typical of a trial installation, but is technically possible in a larger deployment. See .
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/prepare-os.xml b/docs/tmp/en-US/xml_tmp/prepare-os.xml
new file mode 100644
index 00000000000..677ae43d4b8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/prepare-os.xml
@@ -0,0 +1,110 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Prepare the Operating System
+
+ The OS must be prepared to host the Management Server using the following steps. These steps must be performed on each Management Server node.
+
+
+ Log in to your OS as root.
+ Check for a fully qualified hostname.
+ # hostname --fqdn
+ This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+ Set SELinux to be permissive by default.
+
+ Check to see whether SELinux is installed on your machine. If not, you can skip to step 4.
+ In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
+ # rpm -qa | grep selinux
+ In Ubuntu, SELinux is not installed by default. You can verify this with:
+ # dpkg --list 'selinux'
+
+ Set the SELINUX variable in /etc/selinux/config to “permissive”. This ensures that the permissive setting will be maintained after a system reboot.
+ In RHEL or CentOS:
+ # vi /etc/selinux/config
+ In Ubuntu (do this step only if SELinux was found on the machine in the previous step):
+ # selinux-config-enforcing permissive
+
+ Then set SELinux to permissive starting immediately, without requiring a system reboot.
+ In CentOS:
+ # setenforce permissive
+ In RHEL:
+ # setenforce 0
+ In Ubuntu (do this step only if SELinux was found on the machine):
+ # setenforce permissive
+
+
+
+ Make sure that the machine can reach the Internet.
+ # ping www.google.com
+
+ (RHEL 6.2) If you do not have a Red Hat Network account, you need to prepare a local Yum repository.
+
+ If you are working with a physical host, insert the RHEL 6.2 installation CD. If you are using a VM, attach the RHEL6 ISO.
+ Mount the CDROM to /media.
+ Create a repo file at /etc/yum.repos.d/rhel6.repo. In the file, insert the following lines:
+
+[rhel]
+name=rhel6
+baseurl=file:///media
+enabled=1
+gpgcheck=0
+
+
+
+
+ Turn on NTP for time synchronization.
+ NTP is required to synchronize the clocks of the servers in your cloud.
+
+ Install NTP.
+ On RHEL or CentOS:
+ # yum install ntp
+ On Ubuntu:
+ # apt-get install ntp
+
+ Edit the NTP configuration file to point to your NTP server.
+ # vi /etc/ntp.conf
+ Add one or more server lines in this file with the names of the NTP servers
+ you want to use. For example:
+ server 0.xenserver.pool.ntp.org
+server 1.xenserver.pool.ntp.org
+server 2.xenserver.pool.ntp.org
+server 3.xenserver.pool.ntp.org
+
+
+ Restart the NTP client.
+ # service ntpd restart
+
+ Make sure NTP will start again upon reboot.
+ On RHEL or CentOS:
+ # chkconfig ntpd on
+ On Ubuntu:
+ # chkconfig ntp on
+
+
+
+ Repeat all of these steps on every host where the Management Server will be installed.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/prepare-system-vm-template.xml b/docs/tmp/en-US/xml_tmp/prepare-system-vm-template.xml
new file mode 100644
index 00000000000..5ed78f7d5a3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/prepare-system-vm-template.xml
@@ -0,0 +1,71 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Prepare the System VM Template
+ Secondary storage must be seeded with a template that is used for &PRODUCT; system
+ VMs.
+
+ When copying and pasting a command, be sure the command has pasted as a single line before
+ executing. Some document viewers may introduce unwanted line breaks in copied text.
+
+
+
+ On the Management Server, run one or more of the following cloud-install-sys-tmplt
+ commands to retrieve and decompress the system VM template. Run the command for each
+ hypervisor type that you expect end users to run in this Zone.
+ If your secondary storage mount point is not named /mnt/secondary, substitute your own
+ mount point name.
+ If you set the &PRODUCT; database encryption type to "web" when you set up the database,
+ you must now add the parameter -s <management-server-secret-key>. See About Password
+ and Key Encryption.
+ This process will require approximately 5 GB of free space on the local file system and
+ up to 30 minutes each time it runs.
+
+
+ For XenServer:
+ # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 -h xenserver -s <optional-management-server-secret-key> -F
+
+
+ For vSphere:
+ # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.ova -h vmware -s <optional-management-server-secret-key> -F
+
+
+ For KVM:
+ # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -s <optional-management-server-secret-key> -F
+
+
+
+
+ If you are using a separate NFS server, perform this step. If you are using the
+ Management Server as the NFS server, you MUST NOT perform this step.
+ When the script has finished, unmount secondary storage and remove the created
+ directory.
+ # umount /mnt/secondary
+# rmdir /mnt/secondary
+
+
+ Repeat these steps for each secondary storage server.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/prepare_os.xml b/docs/tmp/en-US/xml_tmp/prepare_os.xml
new file mode 100644
index 00000000000..f0fc201cde7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/prepare_os.xml
@@ -0,0 +1,106 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Prepare the Operating System
+ The OS must be prepared to host the Management Server using the following steps. These steps must be performed on each Management Server node.
+
+ Log in to your OS as root.
+ Check for a fully qualified hostname.
+ # hostname --fqdn
+ This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not, edit /etc/hosts so that it does.
+
+ Set SELinux to be permissive by default.
+
+ Check to see whether SELinux is installed on your machine. If not, you can skip to step 4.
+ In RHEL or CentOS, SELinux are installed and enabled by default. You can verify this with:
+ # rpm -qa | grep selinux
+ In Ubuntu, SELinux is not installed by default. You can verify this with:
+ # dpkg --list 'selinux'
+
+ Set the SELINUX variable in /etc/selinux/config to “permissive”. This ensures that the permissive setting will be maintained after a system reboot.
+ In RHEL or CentOS:
+ # vi /etc/selinux/config
+ In Ubuntu (do this step only if SELinux was found on the machine in the previous step):
+ # selinux-config-enforcing permissive
+
+ Then set SELinux to permissive starting immediately, without requiring a system reboot.
+ In CentOS:
+ # setenforce permissive
+ In RHEL:
+ # setenforce 0
+ In Ubuntu (do this step only if SELinux was found on the machine):
+ # setenforce permissive
+
+
+
+ Make sure that the Management Server can reach the Internet.
+ # ping www.google.com
+
+ (RHEL 6.2) If you do not have a Red Hat Network account, you need to prepare a local Yum repository.
+
+ If you are working with a physical host, insert the RHEL 6.2 installation CD. If you are using a VM, attach the RHEL6 ISO.
+ Mount the CDROM to /media.
+ Create a repo file at /etc/yum.repos.d/rhel6.repo. In the file, insert the following lines:
+
+[rhel]
+name=rhel6
+baseurl=file:///media
+enabled=1
+gpgcheck=0
+
+
+
+
+ Turn on NTP for time synchronization.
+ NTP is required to synchronize the clocks of the servers in your cloud.
+
+ Install NTP.
+ On RHEL or CentOS:
+ # yum install ntp
+ On Ubuntu:
+ # apt-get install ntp
+
+ Edit the NTP configuration file to point to your NTP server.
+ # vi /etc/ntp.conf
+ For example, you can use one of the following:
+ 0.xenserver.pool.ntp.org
+1.xenserver.pool.ntp.org
+2.xenserver.pool.ntp.org
+3.xenserver.pool.ntp.org
+
+
+ Restart the NTP client.
+ # service ntpd restart
+
+ Make sure NTP will start again upon reboot.
+ On RHEL or CentOS:
+ # chkconfig ntpd on
+ On Ubuntu:
+ # chkconfig ntp on
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/primary-storage-add.xml b/docs/tmp/en-US/xml_tmp/primary-storage-add.xml
new file mode 100644
index 00000000000..5581e9e79b1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/primary-storage-add.xml
@@ -0,0 +1,74 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Add Primary Storage
+
+ System Requirements for Primary Storage
+ Hardware requirements:
+
+ Any standards-compliant iSCSI or NFS server that is supported by the underlying hypervisor.
+ The storage server should be a machine with a large number of disks. The disks should ideally be managed by a hardware RAID controller.
+ Minimum required capacity depends on your needs.
+
+ When setting up primary storage, follow these restrictions:
+
+ Primary storage cannot be added until a host has been added to the cluster.
+ If you do not provision shared primary storage, you must set the global configuration parameter system.vm.local.storage.required to true, or else you will not be able to start VMs.
+
+
+
+ Adding Primary Stroage
+ When you create a new zone, the first primary storage is added as part of that procedure. You can add primary storage servers at any time, such as when adding a new cluster or adding more servers to an existing cluster.
+ Be sure there is nothing stored on the server. Adding the server to &PRODUCT; will destroy any existing data.
+
+ Log in to the &PRODUCT; UI (see ).
+ In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the primary storage.
+ Click the Compute tab.
+ In the Primary Storage node of the diagram, click View All.
+ Click Add Primary Storage.
+
+ Provide the following information in the dialog. The information required varies depending on your choice in Protocol.
+
+ Pod. The pod for the storage device.
+ Cluster. The cluster for the storage device.
+ Name. The name of the storage device.
+ Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS.
+ Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device.
+ Server (for VMFS). The IP address or DNS name of the vCenter server.
+ Path (for NFS). In NFS this is the exported path from the server.
+ Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/cluster1datastore".
+ Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary storage is mounted. For example, "/mnt/primary".
+ SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside &PRODUCT;.
+ Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example, iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
+ Lun # (for iSCSI). In iSCSI this is 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.
+
+ Click OK.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/primary-storage-outage-and-data-loss.xml b/docs/tmp/en-US/xml_tmp/primary-storage-outage-and-data-loss.xml
new file mode 100644
index 00000000000..e68d1d98e1b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/primary-storage-outage-and-data-loss.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Primary Storage Outage and Data Loss
+ When a primary storage outage occurs the hypervisor immediately stops all VMs stored on that storage device. Guests that are marked for HA will be restarted as soon as practical when the primary storage comes back on line. With NFS, the hypervisor may allow the virtual machines to continue running depending on the nature of the issue. For example, an NFS hang will cause the guest VMs to be suspended until storage connectivity is restored.Primary storage is not designed to be backed up. Individual volumes in primary storage can be backed up using snapshots.
+
diff --git a/docs/tmp/en-US/xml_tmp/primary-storage.xml b/docs/tmp/en-US/xml_tmp/primary-storage.xml
new file mode 100644
index 00000000000..4cefa83c190
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/primary-storage.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Primary Storage
+ This section gives concepts and technical details about CloudPlatform primary storage. For information about how to install and configure primary storage through the CloudPlatform UI, see the Advanced Installation Guide.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/private-public-template.xml b/docs/tmp/en-US/xml_tmp/private-public-template.xml
new file mode 100644
index 00000000000..85565833f03
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/private-public-template.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Private and Public Templates
+ When a user creates a template, it can be designated private or public.
+ Private templates are only available to the user who created them. By default, an uploaded template is private.
+ When a user marks a template as “public,” the template becomes available to all users in all accounts in the user's domain, as well as users in any other domains that have access to the Zone where the template is stored. This depends on whether the Zone, in turn, was defined as private or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any domain. If a public template is created in a private Zone, it is available only to users in the domain assigned to that Zone. If a public template is created in a public Zone, it is available to all users in all domains.
+
diff --git a/docs/tmp/en-US/xml_tmp/projects-overview.xml b/docs/tmp/en-US/xml_tmp/projects-overview.xml
new file mode 100644
index 00000000000..4f9a833b5ed
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/projects-overview.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Overview of Projects
+ Projects are used to organize people and resources. &PRODUCT; 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. &PRODUCT; 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 &PRODUCT; to allow any user to create a new project, or you can restrict that ability to just &PRODUCT; administrators. Once you have created a project, you become that project’s administrator, and you can add others within your domain to the project. &PRODUCT; 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 &PRODUCT; 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 &PRODUCT; 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 &PRODUCT; 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..
+
+
diff --git a/docs/tmp/en-US/xml_tmp/projects.xml b/docs/tmp/en-US/xml_tmp/projects.xml
new file mode 100644
index 00000000000..39ce96bd3bc
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/projects.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using Projects to Organize Users and Resources
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/provisioning-auth-api.xml b/docs/tmp/en-US/xml_tmp/provisioning-auth-api.xml
new file mode 100644
index 00000000000..0f28b1f3421
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/provisioning-auth-api.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Provisioning and Authentication API
+ &PRODUCT; 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 &PRODUCT; to add/remove users..
+ &PRODUCT; supports pluggable authenticators. By default, &PRODUCT; 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/provisioning-steps-overview.xml b/docs/tmp/en-US/xml_tmp/provisioning-steps-overview.xml
new file mode 100644
index 00000000000..1da4485ff39
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/provisioning-steps-overview.xml
@@ -0,0 +1,46 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 &PRODUCT; cloud infrastructure is organized, see .
+ To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
+
+ Change the root password. See .
+ Add a zone. See .
+ Add more pods (optional). See .
+ Add more clusters (optional). See .
+ Add more hosts (optional). See .
+ Add primary storage. See .
+ Add secondary storage. See .
+ Initialize and test the new cloud. See .
+
+ 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
+
+
diff --git a/docs/tmp/en-US/xml_tmp/provisioning-steps.xml b/docs/tmp/en-US/xml_tmp/provisioning-steps.xml
new file mode 100644
index 00000000000..98717435c62
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/provisioning-steps.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Steps to Provisioning Your Cloud Infrastructure
+ This section tells how to add zones, pods, clusters, hosts, storage, and networks to your cloud. If you are unfamiliar with these entities, please begin by looking through .
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/provisioning-steps.xml.orig b/docs/tmp/en-US/xml_tmp/provisioning-steps.xml.orig
new file mode 100644
index 00000000000..b532783b2d2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/provisioning-steps.xml.orig
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Steps to Provisioning Your Cloud Infrastructure
+ This section tells how to add zones, pods, clusters, hosts, storage, and networks to your cloud. If you are unfamiliar with these entities, please begin by looking through .
+
+
+
+
+
+
+
+
+
+<<<<<<< HEAD
+
+
+=======
+
+>>>>>>> Promote sections to chapters: Cloud Infrastructure Concepts and Provisioning Steps.
diff --git a/docs/tmp/en-US/xml_tmp/provisioning.xml b/docs/tmp/en-US/xml_tmp/provisioning.xml
new file mode 100644
index 00000000000..8a5b44af8e5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/provisioning.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Provisioning Your Cloud Infrastructure
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/query-filter.xml b/docs/tmp/en-US/xml_tmp/query-filter.xml
new file mode 100644
index 00000000000..fa5ea6344c1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/query-filter.xml
@@ -0,0 +1,60 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+Query Filter
+The query filter is used to find a mapped user in the external LDAP server. The query filter should uniquely map the CloudPlatform user to LDAP user for a meaningful authentication. For more information about query filter syntax, consult the documentation for your LDAP server.
+The CloudPlatform 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 CloudPlatform user name is the same as the LDAP user ID:
+(uid=%u)
+If the CloudPlatform user name is the LDAP display name:
+(displayName=%u)
+To find a user by email address:
+(mail=%e)
+
diff --git a/docs/tmp/en-US/xml_tmp/re-install-hosts.xml b/docs/tmp/en-US/xml_tmp/re-install-hosts.xml
new file mode 100644
index 00000000000..b8092adb44a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/re-install-hosts.xml
@@ -0,0 +1,26 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/release-ip-address.xml b/docs/tmp/en-US/xml_tmp/release-ip-address.xml
new file mode 100644
index 00000000000..87b53007cdb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/release-ip-address.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Releasing an IP Address
+
+ Log in to the CloudPlatform UI as an administrator or end user.
+ In the left navigation, choose Network.
+ Click the name of the network where you want to work with.
+ Click View IP Addresses.
+ Click the IP address you want to release.
+
+ Click the Release IP button
+
+
+
+ ReleaseIPButton.png: button to release an IP
+ .
+
+
diff --git a/docs/tmp/en-US/xml_tmp/release-ip-for-vpc.xml b/docs/tmp/en-US/xml_tmp/release-ip-for-vpc.xml
new file mode 100644
index 00000000000..466ec663a17
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/release-ip-for-vpc.xml
@@ -0,0 +1,80 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Releasing an IP Address Alloted to a VPC
+ The IP address is a limited resource. If you no longer need a particular IP, you can
+ disassociate it from its VPC and return it to the pool of available addresses. An IP address can
+ be released from its tier, only when all the networking ( port forwarding, load balancing, or
+ StaticNAT ) rules are removed for this IP address. The released IP address will still belongs to
+ the same VPC.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC whose IP you want to release.
+ The VPC page is displayed where all the tiers you created are listed in a
+ diagram.
+
+
+ Click the Settings icon.
+ The following options are displayed.
+
+
+ IP Addresses
+
+
+ Gateways
+
+
+ Site-to-Site VPN
+
+
+ Network ACLs
+
+
+
+
+ Select IP Addresses.
+ The IP Addresses page is displayed.
+
+
+ Click the IP you want to release.
+
+
+ In the Details tab, click the Release IP button
+
+
+
+
+ release-ip-icon.png: button to release an IP.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/release-notes-3.0.4.ent b/docs/tmp/en-US/xml_tmp/release-notes-3.0.4.ent
new file mode 100644
index 00000000000..65ecebd8c7a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/release-notes-3.0.4.ent
@@ -0,0 +1,4 @@
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/release-notes.ent b/docs/tmp/en-US/xml_tmp/release-notes.ent
new file mode 100644
index 00000000000..7858ad5f2e0
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/release-notes.ent
@@ -0,0 +1,22 @@
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/release-notes.xml b/docs/tmp/en-US/xml_tmp/release-notes.xml
new file mode 100644
index 00000000000..849dc5af911
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/release-notes.xml
@@ -0,0 +1,2921 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Submitting Feedback and Getting Help
+ The Apache CloudStack project has mailing lists for users and developers. These are the
+ official channels of communication for the project and are the best way to get answers about
+ using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users
+ mailing list if you've deployed or are deploying CloudStack into production, and even for test
+ deployments.
+ The CloudStack developer's mailing list (cloudstack-dev) is for discussions about
+ CloudStack development, and is the best list for discussing possible bugs in CloudStack.
+ Anyone contributing to CloudStack should be on this mailing list.
+ You can also report bugs in CloudStack using the Apache Defect Tracking
+ System
+ To posts to the lists, you'll need to be subscribed. See the CloudStack Web site
+ for instructions.
+
+
+ Upgrade Instructions
+
+ Upgrade from 3.0.2 to 4.0.0-incubating
+ Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note
+ that some of the steps here are only required if you're using a specific hypervisor. The
+ steps that are hypervisor-specific are called out with a note.
+
+
+ Ensure that you query your IP address usage records and process them or make a
+ backup. During the upgrade you will lose the old IP address usage records.
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest
+ of the usage types. Instead of a single record with the assignment and release dates,
+ separate records are generated per aggregation period with start and end dates. After
+ upgrading, any existing IP address usage records in the old format will no longer be
+ available.
+
+
+
+ The following upgrade instructions apply only if you're using VMware hosts. If
+ you're not using VMware hosts, skip this step and move on to step 3: stopping all
+ usage servers.
+
+ In each zone that includes VMware hosts, you need to add a new system VM template.
+
+
+ While running the existing 3.0.2 system, log in to the UI as root
+ administrator.
+
+
+ In the left navigation bar, click Templates.
+
+
+ In Select view, click Templates.
+
+
+ Click Register template.
+ The Register template dialog box is displayed.
+
+
+ In the Register template dialog box, specify the following values (do not change
+ these):
+
+
+
+
+
+
+ Field
+ Value
+
+
+
+
+ Name
+ systemvm-vmware-3.0.5
+
+
+ Description
+ systemvm-vmware-3.0.5
+
+
+ URL
+ http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+
+
+ Zone
+ Choose the zone where this hypervisor is used
+
+
+ Hypervisor
+ VMware
+
+
+ Format
+ OVA
+
+
+ OS Type
+ Debian GNU/Linux 5.0 (32-bit)
+
+
+ Extractable
+ no
+
+
+ Password Enabled
+ no
+
+
+ Public
+ no
+
+
+ Featured
+ no
+
+
+
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters
+ the READY state. Do not proceed until this is successful.
+
+
+
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+ # service cloud-usage stop
+
+
+ Stop the Management Servers. Run this on all Management Server hosts.
+ # service cloud-management stop
+
+
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing
+ this step even in test upgrades. If there is an issue, this will assist with
+ debugging.
+ 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.
+ #mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp
+
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of
+ the community provided yum/apt repositories to gain access to the &PRODUCT;
+ binaries.
+
+
+ After you have configured an appropriate yum or apt repository, you may execute the
+ one of the following commands as appropriate for your environment in order to upgrade
+ &PRODUCT;: #yum update cloud-*
+ #apt-get update
+#apt-get upgrade cloud-*
+
+
+ If the upgrade output includes a message similar to the following, then some
+ custom content was found in your old components.xml, and you need to merge the two
+ files:
+ warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+ Instructions follow in the next step.
+
+
+
+ If you have made changes to your copy of
+ /etc/cloud/management/components.xml the changes will be
+ preserved in the upgrade. However, you need to do the following steps to place these
+ changes in a new version of the file which is compatible with version
+ 4.0.0-incubating.
+
+
+ Make a backup copy of /etc/cloud/management/components.xml.
+ For example:
+ # mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backup
+
+
+ Copy /etc/cloud/management/components.xml.rpmnew to create
+ a new /etc/cloud/management/components.xml:
+ # cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xml
+
+
+ Merge your changes from the backup file into the new
+ components.xml.
+ # vi /etc/cloud/management/components.xml
+
+
+
+ If you have more than one management server node, repeat the upgrade steps on each
+ node.
+
+
+
+ Start the first Management Server. Do not start any other Management Server nodes
+ yet.
+ # service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete.
+ After confirmation, start the other Management Servers one at a time by running the same
+ command on each node.
+
+ Failing to restart the Management Server indicates a problem in the upgrade.
+ Having the Management Server restarted without any issues indicates that the upgrade
+ is successfully completed.
+
+
+
+ Start all Usage Servers (if they were running on your previous version). Perform
+ this on each Usage Server host.
+ # service cloud-usage start
+
+
+
+ Additional steps are required for each KVM host. These steps will not affect
+ running guests in the cloud. These steps are required only for clouds using KVM as
+ hosts and only on the KVM hosts.
+
+
+
+ Configure a yum or apt respository containing the &PRODUCT; packages as outlined
+ in the Installation Guide.
+
+
+ Stop the running agent.
+ # service cloud-agent stop
+
+
+ Update the agent software with one of the following command sets as appropriate
+ for your environment.
+ # yum update cloud-*
+ # apt-get update
+ # apt-get upgrade cloud-*
+
+
+ Start the agent.
+ # service cloud-agent start
+
+
+ Edit /etc/cloud/agent/agent.properties to change the
+ resource parameter from
+ "com.cloud.agent.resource.computing.LibvirtComputingResource" to
+ "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
+
+
+ Start the cloud agent and cloud management services.
+
+
+ When the Management Server is up and running, log in to the CloudStack UI and
+ restart the virtual router for proper functioning of all the features.
+
+
+
+
+ Log in to the CloudStack UI as administrator, and check the status of the hosts. All
+ hosts should come to Up state (except those that you know to be offline). You may need
+ to wait 20 or 30 minutes, depending on the number of hosts.
+
+ Troubleshooting: If login fails, clear your browser cache and reload the
+ page.
+
+
+ Do not proceed to the next step until the hosts show in Up state.
+
+
+ If you are upgrading from 3.0.2, perform the following:
+
+
+ Ensure that the admin port is set to 8096 by using the "integration.api.port"
+ global parameter.
+ This port is used by the cloud-sysvmadm script at the end of the upgrade
+ procedure. For information about how to set this parameter, see "Setting Global
+ Configuration Parameters" in the Installation Guide.
+
+
+ Restart the Management Server.
+
+ If you don't want the admin port to remain open, you can set it to null after
+ the upgrade is done and restart the management server.
+
+
+
+
+
+ Run the cloud-sysvmadm script to stop, then start, all Secondary
+ Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each
+ management server. Substitute your own IP address of the MySQL instance, the MySQL user
+ to connect as, and the password to use for that user. In addition to those parameters,
+ provide the -c and -r arguments. For
+ example:
+ # nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r >
+ sysvm.log 2>&1 &
+ # tail -f sysvm.log
+ This might take up to an hour or more to run, depending on the number of accounts in
+ the system.
+
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version
+ supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2
+ and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating
+ Installation Guide.
+
+
+ Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to
+ XenServer v6.0.2 hypervisor hosts.
+
+
+ Disconnect the XenServer cluster from CloudStack.
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under
+ Clusters, click View All. Select the XenServer cluster and click Actions -
+ Unmanage.
+ This may fail if there are hosts not in one of the states Up, Down,
+ Disconnected, or Alert. You may need to fix that before unmanaging this
+ cluster.
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack
+ UI to check on the status. When the cluster is in the unmanaged state, there is no
+ connection to the hosts in the cluster.
+
+
+ To clean up the VLAN, log in to one XenServer host and run:
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+ Now prepare the upgrade by running the following on one XenServer host:
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+ If you see a message like "can't eject CD", log in to the VM and unmount the CD,
+ then run this script again.
+
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master,
+ then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the
+ hotfixes to the host. Place them in a temporary folder such as /tmp.
+ On the Xen pool master, upload the hotfix with this command:
+ xe patch-upload file-name=XS602E003.xsupdate
+ Make a note of the output from this command, which is a UUID for the hotfix
+ file. You'll need it in another step later.
+
+ (Optional) If you are applying other hotfixes as well, you can repeat the
+ commands in this section with the appropriate hotfix number. For example,
+ XS602E004.xsupdate.
+
+
+
+ Manually live migrate all VMs on this host to another host. First, get a list of
+ the VMs on this host:
+ # xe vm-list
+ Then use this command to migrate each VM. Replace the example host name and VM
+ name with your own:
+ # xe vm-migrate live=true host=host-name
+ vm=VM-name
+
+ Troubleshooting
+ If you see a message like "You attempted an operation on a VM which requires
+ PV drivers to be installed but the drivers were not detected," run:
+ /opt/xensource/bin/make_migratable.sh
+ b6cf79c8-02ee-050b-922f-49583d9f1a14.
+
+
+
+ Apply the hotfix. First, get the UUID of this host:
+ # xe host-list
+ Then use the following command to apply the hotfix. Replace the example host
+ UUID with the current host ID, and replace the hotfix UUID with the output from the
+ patch-upload command you ran on this machine earlier. You can also get the hotfix
+ UUID by running xe patch-list.
+ xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid
+
+
+ Copy the following files from the CloudStack Management Server to the
+ host.
+
+
+
+
+
+
+ Copy from here...
+ ...to here
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+ /opt/xensource/sm/NFSSR.py
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+ /opt/xensource/bin/setupxenserver.sh
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+
+
+
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud
+ Support Pack.
+
+
+ Download the CSP software onto the XenServer host from one of the following
+ links:
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+ Extract the file:
+ # tar xf xenserver-cloud-supp.tgz
+
+
+ Run the following script:
+ # xe-install-supplemental-pack xenserver-cloud-supp.iso
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable
+ Open vSwitch (OVS):
+ # xe-switch-network-backend bridge
+
+
+
+
+ Reboot this XenServer host.
+
+
+ Run the following:
+ /opt/xensource/bin/setupxenserver.sh
+
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or
+ directory" appears, you can safely ignore it.
+
+
+
+ Run the following:
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+
+
+ On each slave host in the Xen pool, repeat these steps, starting from "manually
+ live migrate VMs."
+
+
+
+
+
+ Troubleshooting Tip
+ If passwords which you know to be valid appear not to work after upgrade, or other UI
+ issues are seen, try clearing your browser cache and reloading the UI page.
+
+
+
+ Upgrade from 2.2.14 to 4.0.0-incubating
+
+
+ Ensure that you query your IPaddress usage records and process them; for example,
+ issue invoices for any usage that you have not yet billed users for.
+ Starting in 3.0.2, the usage record format for IP addresses is the same as the rest
+ of the usage types. Instead of a single record with the assignment and release dates,
+ separate records are generated per aggregation period with start and end dates. After
+ upgrading to 4.0.0-incubating, any existing IP address usage records in the old format
+ will no longer be available.
+
+
+ If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the
+ instructions in the 2.2.14 Release Notes.
+
+ KVM Hosts
+ If KVM hypervisor is used in your cloud, be sure you completed the step to insert
+ a valid username and password into the host_details table on each KVM node as
+ described in the 2.2.14 Release Notes. This step is critical, as the database will be
+ encrypted after the upgrade to 4.0.0-incubating.
+
+
+
+ While running the 2.2.14 system, log in to the UI as root administrator.
+
+
+ Using the UI, add a new System VM template for each hypervisor type that is used in
+ your cloud. In each zone, add a system VM template for each hypervisor used in that
+ zone
+
+
+ In the left navigation bar, click Templates.
+
+
+ In Select view, click Templates.
+
+
+ Click Register template.
+ The Register template dialog box is displayed.
+
+
+ In the Register template dialog box, specify the following values depending on
+ the hypervisor type (do not change these):
+
+
+
+
+
+
+ Hypervisor
+ Description
+
+
+
+
+ XenServer
+ Name: systemvm-xenserver-3.0.0
+ Description: systemvm-xenserver-3.0.0
+ URL:
+ http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2
+ Zone: Choose the zone where this hypervisor is used
+ Hypervisor: XenServer
+ Format: VHD
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+ Extractable: no
+ Password Enabled: no
+ Public: no
+ Featured: no
+
+
+
+ KVM
+ Name: systemvm-kvm-3.0.0
+ Description: systemvm-kvm-3.0.0
+ URL:
+ http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2
+ Zone: Choose the zone where this hypervisor is used
+ Hypervisor: KVM
+ Format: QCOW2
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+ Extractable: no
+ Password Enabled: no
+ Public: no
+ Featured: no
+
+
+
+ VMware
+ Name: systemvm-vmware-3.0.5
+ Description: systemvm-vmware-3.0.5
+ URL:
+ http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
+ Zone: Choose the zone where this hypervisor is used
+ Hypervisor: VMware
+ Format: OVA
+ OS Type: Debian GNU/Linux 5.0 (32-bit)
+ Extractable: no
+ Password Enabled: no
+ Public: no
+ Featured: no
+
+
+
+
+
+
+
+
+
+ Watch the screen to be sure that the template downloads successfully and enters the
+ READY state. Do not proceed until this is successful
+
+
+ WARNING: If you use more than one type of
+ hypervisor in your cloud, be sure you have repeated these steps to download the system
+ VM template for each hypervisor type. Otherwise, the upgrade will fail.
+
+
+ Stop all Usage Servers if running. Run this on all Usage Server hosts.
+ # service cloud-usage stop
+
+
+ Stop the Management Servers. Run this on all Management Server hosts.
+ # service cloud-management stop
+
+
+ On the MySQL master, take a backup of the MySQL databases. We recommend performing
+ this step even in test upgrades. If there is an issue, this will assist with
+ debugging.
+ 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.
+ #mysqldump -u root -pmysql_password cloud > cloud-backup.dmp
+#mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp
+
+
+
+ Either build RPM/DEB packages as detailed in the Installation Guide, or use one of
+ the community provided yum/apt repositories to gain access to the &PRODUCT; binaries.
+
+
+
+ After you have configured an appropriate yum or apt repository, you may execute the
+ one of the following commands as appropriate for your environment in order to upgrade
+ &PRODUCT;: #yum update cloud-*
+ #apt-get update
+#apt-get upgrade cloud-*
+
+
+
+ If you have made changes to your existing copy of the file components.xml in your
+ previous-version CloudStack installation, the changes will be preserved in the upgrade.
+ However, you need to do the following steps to place these changes in a new version of
+ the file which is compatible with version 4.0.0-incubating.
+
+ How will you know whether you need to do this? If the upgrade output in the
+ previous step included a message like the following, then some custom content was
+ found in your old components.xml, and you need to merge the two files:
+
+ warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew
+
+
+ Make a backup copy of your
+ /etc/cloud/management/components.xml file. For
+ example:
+ #mv/etc/cloud/management/components.xml/etc/cloud/management/components.xml-backup
+
+
+ Copy /etc/cloud/management/components.xml.rpmnew to create
+ a new /etc/cloud/management/components.xml:
+ #cp -ap /etc/cloud/management/components.xml.rpmnew/etc/cloud/management/components.xml
+
+
+ Merge your changes from the backup file into the new components.xml file.
+ #vi/etc/cloud/management/components.xml
+
+
+
+
+
+ If you have made changes to your existing copy of the
+ /etc/cloud/management/db.properties file in your previous-version
+ CloudStack installation, the changes will be preserved in the upgrade. However, you need
+ to do the following steps to place these changes in a new version of the file which is
+ compatible with version 4.0.0-incubating.
+
+
+ Make a backup copy of your file
+ /etc/cloud/management/db.properties. For example:
+ #mv/etc/cloud/management/db.properties/etc/cloud/management/db.properties-backup
+
+
+ Copy /etc/cloud/management/db.properties.rpmnew to create a
+ new /etc/cloud/management/db.properties:
+ #cp -ap /etc/cloud/management/db.properties.rpmnewetc/cloud/management/db.properties
+
+
+ Merge your changes from the backup file into the new db.properties file.
+ #vi/etc/cloud/management/db.properties
+
+
+
+
+ On the management server node, run the following command. It is recommended that you
+ use the command-line flags to provide your own encryption keys. See Password and Key
+ Encryption in the Installation Guide.
+ #cloud-setup-encryption -e encryption_type -m management_server_key -k database_key
+ When used without arguments, as in the following example, the default encryption
+ type and keys will be used:
+
+
+ (Optional) For encryption_type, use file or web to indicate the technique used
+ to pass in the database encryption password. Default: file.
+
+
+ (Optional) For management_server_key, substitute the default key that is used to
+ encrypt confidential parameters in the properties file. Default: password. It is
+ highly recommended that you replace this with a more secure value
+
+
+ (Optional) For database_key, substitute the default key that is used to encrypt
+ confidential parameters in the CloudStack database. Default: password. It is highly
+ recommended that you replace this with a more secure value.
+
+
+
+
+ Repeat steps 10 - 14 on every management server node. If you provided your own
+ encryption key in step 14, use the same key on all other management servers.
+
+
+ Start the first Management Server. Do not start any other Management Server nodes
+ yet.
+ # service cloud-management start
+ Wait until the databases are upgraded. Ensure that the database upgrade is complete.
+ You should see a message like "Complete! Done." After confirmation, start the other
+ Management Servers one at a time by running the same command on each node.
+
+
+ Start all Usage Servers (if they were running on your previous version). Perform
+ this on each Usage Server host.
+ # service cloud-usage start
+
+
+ (KVM only) Additional steps are required for each KVM host. These steps will not
+ affect running guests in the cloud. These steps are required only for clouds using KVM
+ as hosts and only on the KVM hosts.
+
+
+ Configure your CloudStack package repositories as outlined in the Installation
+ Guide
+
+
+ Stop the running agent.
+ # service cloud-agent stop
+
+
+ Update the agent software with one of the following command sets as
+ appropriate.
+ #yum update cloud-*
+
+ #apt-get update
+#apt-get upgrade cloud-*
+
+
+
+ Start the agent.
+ # service cloud-agent start
+
+
+ Copy the contents of the agent.properties file to the new
+ agent.properties file by using the following command
+ sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.properties
+
+
+ Start the cloud agent and cloud management services.
+
+
+ When the Management Server is up and running, log in to the CloudStack UI and
+ restart the virtual router for proper functioning of all the features.
+
+
+
+
+ Log in to the CloudStack UI as admin, and check the status of the hosts. All hosts
+ should come to Up state (except those that you know to be offline). You may need to wait
+ 20 or 30 minutes, depending on the number of hosts.
+ Do not proceed to the next step until the hosts show in the Up state. If the hosts
+ do not come to the Up state, contact support.
+
+
+ Run the following script to stop, then start, all Secondary Storage VMs, Console
+ Proxy VMs, and virtual routers.
+
+
+ Run the command once on one management server. Substitute your own IP address of
+ the MySQL instance, the MySQL user to connect as, and the password to use for that
+ user. In addition to those parameters, provide the "-c" and "-r" arguments. For
+ example:
+ #nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 &
+#tail -f sysvm.log
+ This might take up to an hour or more to run, depending on the number of
+ accounts in the system.
+
+
+ After the script terminates, check the log to verify correct execution:
+ #tail -f sysvm.log
+ The content should be like the following:
+
+Stopping and starting 1 secondary storage vm(s)...
+Done stopping and starting secondary storage vm(s)
+Stopping and starting 1 console proxy vm(s)...
+Done stopping and starting console proxy vm(s).
+Stopping and starting 4 running routing vm(s)...
+Done restarting router(s).
+
+
+
+
+
+ If you would like additional confirmation that the new system VM templates were
+ correctly applied when these system VMs were rebooted, SSH into the System VM and check
+ the version.
+ Use one of the following techniques, depending on the hypervisor.
+
+ XenServer or KVM:
+ SSH in by using the link local IP address of the system VM. For example, in the
+ command below, substitute your own path to the private key used to log in to the
+ system VM and your own link local IP.
+
+ Run the following commands on the XenServer or KVM host on which the system VM is
+ present:
+ #ssh -i private-key-pathlink-local-ip -p 3922
+# cat /etc/cloudstack-release
+ The output should be like the following:
+ Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+
+ ESXi
+ SSH in using the private IP address of the system VM. For example, in the command
+ below, substitute your own path to the private key used to log in to the system VM and
+ your own private IP.
+
+ Run the following commands on the Management Server:
+ #ssh -i private-key-pathprivate-ip -p 3922
+#cat/etc/cloudstack-release
+
+ The output should be like the following:
+ Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012
+
+
+ If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version
+ supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2
+ and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating
+ Installation Guide.
+
+
+ Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer
+ v6.0.2 hypervisor hosts.
+
+
+ Disconnect the XenServer cluster from CloudStack.
+ In the left navigation bar of the CloudStack UI, select Infrastructure. Under
+ Clusters, click View All. Select the XenServer cluster and click Actions -
+ Unmanage.
+ This may fail if there are hosts not in one of the states Up, Down,
+ Disconnected, or Alert. You may need to fix that before unmanaging this
+ cluster.
+ Wait until the status of the cluster has reached Unmanaged. Use the CloudStack
+ UI to check on the status. When the cluster is in the unmanaged state, there is no
+ connection to the hosts in the cluster.
+
+
+ To clean up the VLAN, log in to one XenServer host and run:
+ /opt/xensource/bin/cloud-clean-vlan.sh
+
+
+ Prepare the upgrade by running the following on one XenServer host:
+ /opt/xensource/bin/cloud-prepare-upgrade.sh
+ If you see a message like "can't eject CD", log in to the VM and umount the CD,
+ then run this script again.
+
+
+ Upload the hotfix to the XenServer hosts. Always start with the Xen pool master,
+ then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the
+ hotfixes to the host. Place them in a temporary folder such as /root or /tmp.
+ On the Xen pool master, upload the hotfix with this command:
+ xe patch-upload file-name=XS602E003.xsupdate
+ Make a note of the output from this command, which is a UUID for the hotfix
+ file. You'll need it in another step later.
+
+ (Optional) If you are applying other hotfixes as well, you can repeat the
+ commands in this section with the appropriate hotfix number. For example,
+ XS602E004.xsupdate.
+
+
+
+ Manually live migrate all VMs on this host to another host. First, get a list of
+ the VMs on this host:
+ # xe vm-list
+ Then use this command to migrate each VM. Replace the example host name and VM
+ name with your own:
+ #xe vm-migrate live=true host=host-name vm=VM-name
+
+ Troubleshooting
+ If you see a message like "You attempted an operation on a VM which requires
+ PV drivers to be installed but the drivers were not detected," run:
+ /opt/xensource/bin/make_migratable.sh
+ b6cf79c8-02ee-050b-922f-49583d9f1a14.
+
+
+
+ Apply the hotfix. First, get the UUID of this host:
+ # xe host-list
+ Then use the following command to apply the hotfix. Replace the example host
+ UUID with the current host ID, and replace the hotfix UUID with the output from the
+ patch-upload command you ran on this machine earlier. You can also get the hotfix
+ UUID by running xe patch-list.
+ xe patch-apply host-uuid=host-uuid
+ uuid=hotfix-uuid
+
+
+ Copy the following files from the CloudStack Management Server to the
+ host.
+
+
+
+
+
+
+ Copy from here...
+ ...to here
+
+
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
+ /opt/xensource/sm/NFSSR.py
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
+ /opt/xensource/bin/setupxenserver.sh
+
+
+ /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
+ /opt/xensource/bin/make_migratable.sh
+
+
+
+
+
+
+ (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud
+ Support Pack.
+
+
+ Download the CSP software onto the XenServer host from one of the following
+ links:
+ For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz
+ For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz
+
+
+ Extract the file:
+ # tar xf xenserver-cloud-supp.tgz
+
+
+ Run the following script:
+ # xe-install-supplemental-pack
+ xenserver-cloud-supp.iso
+
+
+ If the XenServer host is part of a zone that uses basic networking, disable
+ Open vSwitch (OVS):
+ # xe-switch-network-backend bridge
+
+
+
+
+ Reboot this XenServer host.
+
+
+ Run the following:
+ /opt/xensource/bin/setupxenserver.sh
+
+ If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or
+ directory" appears, you can safely ignore it.
+
+
+
+ Run the following:
+ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk
+ '{print $NF}'`; do xe pbd-plug uuid=$pbd ;
+
+
+
+ On each slave host in the Xen pool, repeat these steps, starting from "manually
+ live migrate VMs."
+
+
+
+
+
+
+
+ Version 4.0.0-incubating
+
+ What’s New in 4.0.0-incubating
+ Apache CloudStack 4.0.0-incubating includes the following new features:
+
+ Inter-VLAN Routing
+ Inter-VLAN Routing is the capability to route network traffic between VLANs. This
+ feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier
+ applications. These tiers are deployed on different VLANs that can communicate with each
+ other. You can provision VLANs to the tiers your create, and VMs can be deployed on
+ different tiers, such as Web, Application, or Database. The VLANs are connected to a
+ virtual router, which facilitates communication between the VMs. In effect, you can
+ segment VMs by means of VLANs into different networks that can host multi-tier
+ applications. Such segmentation by means of VLANs logically separate application VMs for
+ higher security and lower broadcasts, while remaining physically connected to the same
+ device.
+ This feature is supported on XenServer and VMware hypervisors.
+
+
+ Site-to-Site VPN
+ A Site-to-Site VPN connection helps you establish a secure connection from an
+ enterprise datacenter to the cloud infrastructure. This allows users to access the guest
+ VMs by establishing a VPN connection to the virtual router of the account from a device in
+ the datacenter of the enterprise. Having this facility eliminates the need to establish
+ VPN connections to individual VMs.
+ The supported endpoints on the remote datacenters are:
+
+
+ Cisco ISR with IOS 12.4 or later
+
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
+
+
+
+ Local Storage Support for Data Volumes
+ You can now create data volumes on local storage. The data volume is placed on the
+ same XenServer host as the VM instance that is attached to the data volume. These local
+ data volumes can be attached to virtual machines, detached, re-attached, and deleted just
+ as with the other types of data volume. In earlier releases of CloudStack, only the root
+ disk could be placed in local storage.
+ Local storage is ideal for scenarios where persistence of data volumes and HA is not
+ required. Some of the benefits include reduced disk I/O latency and cost reduction from
+ using inexpensive local disks.
+ In order for local volumes to be used, the feature must be enabled for the
+ zone.
+ You can create a data disk offering for local storage. When a user creates a new VM,
+ they can select this disk offering in order to cause the data disk volume to be placed in
+ local storage.
+ You can not migrate a VM that has a volume in local storage to a different host, nor
+ migrate the volume itself away to a different host. If you want to put a host into
+ maintenance mode, you must first stop any VMs with local data volumes on that host.
+ Local storage support for volumes is available for XenServer, KVM, and VMware
+ hypervisors.
+
+
+ Tags
+ 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 new 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.
+ A new optional input parameter, "tags," has been added to 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:
+ 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 new "tags" input parameter:
+
+
+ listVirtualMachines
+
+
+ listVolumes
+
+
+ listSnapshots
+
+
+ listNetworks
+
+
+ listTemplates
+
+
+ listIsos
+
+
+ listFirewallRules
+
+
+ listPortForwardingRules
+
+
+ listPublicIpAddresses
+
+
+ listSecurityGroups
+
+
+ listLoadBalancerRules
+
+
+ listProjects
+
+
+ listVPCs
+
+
+ listNetworkACLs
+
+
+ listStaticRoutes
+
+
+
+
+ AWS API Changes for Tags
+ Some changes have been made to the Amazon Web Services API compatibility support in
+ order to accommodate the new tagging feature.
+ New APIs:
+
+
+
+
+
+
+
+ New API
+
+
+ Description
+
+
+
+
+
+
+ ec2-create-tags
+
+
+ Add tags to one or more resources.
+
+
+
+
+ ec2-delete-tags
+
+
+ Remove tags from one or more resources.
+
+
+
+ ec2-describe-tags
+
+ Show currently defined tags.
+
+
+
+
+
+ Changed APIs:
+
+
+
+
+
+
+
+ Changed API
+
+
+ Description
+
+
+
+
+
+ ec2-describe-images
+
+ Output now shows tags defined for each image.
+
+
+
+
+ ec2-describe-instances
+
+
+ Output now shows tags defined for each image.
+ The following filters can now be passed in to limit the output result set:
+ tag-key, tag-value and tag:key
+
+
+
+
+ ec2-describe-snapshots
+
+
+ Output now shows tags defined for each image.
+ The following filters can now be passed in to limit the output result set:
+ tag-key, tag-value and tag:key
+
+
+
+ ec2-describe-volumes
+
+ Output now shows tags defined for each image.
+ The following filters can now be passed in to limit the output result set:
+ tag-key, tag-value and tag:key
+
+
+
+
+
+
+
+ Secure Console Access on XenServer
+ With the addition of Secure Console feature, users can now securely access the VM
+ consoles on the XenServer hypervisor. You can either SSH or use the View Console option in
+ the Management Server to securely connect to the VMs on the XenServer host. The Management
+ Server uses the xapi API to stream the VM consoles. However, there is no change in the way
+ you can access the console of a VM. This feature is supported on XenServer 5.6 and 6.0
+ versions.
+
+
+ Stopped VM
+ This release supports creating VMs without starting them on the backend. You can
+ determine whether the VM needs to be started as part of the VM deployment. A VM can be
+ deployed in two ways: create and start a VM (the default method); create a VM and leave it
+ in the stopped state.
+ A new request parameter, startVM, is introduced in the deployVm API to support the
+ stopped VM feature. The possible values are:
+
+
+ true - The VM starts as a part of the VM deployment
+
+
+ false - The VM is left in stopped state at the end of the VM deployment
+
+
+
+
+ Uploading an Existing Volume to a Virtual Machine
+ Existing data can now be made accessible to a virtual machine. This is called
+ uploading a volume to the VM. For example, this is useful to upload data from a local file
+ system and attach it to a VM. Root administrators, domain administrators, and end users
+ can all upload existing volumes to VMs. The upload is performed by using HTTP. The
+ uploaded volume is placed in the zone's secondary storage.
+ This functionality is supported for the following hypervisors:
+
+
+ Hypervisor : Disk Image Format
+
+
+ XenServer : VHD
+
+
+ VMware : OVA
+
+
+ KVM : QCOW2
+
+
+
+
+
+ Dedicated High-Availability Hosts
+ One or more hosts can now be designated for use only by high-availability (HA) enabled
+ VMs that are restarted due to a host failure. Setting up a pool of such dedicated HA hosts
+ as the recovery destination for all HA-enabled VMs make it easier to determine which VMs
+ are restarted as part of the high-availability function. You can designate a host as a
+ dedicated-HA restart node only if the Dedicated HA Hosts feature is enabled by setting the
+ appropriate global configuration parameter.
+
+
+ Support for Amazon Web Services API
+ This release supports Amazon Web Services APIs, including Elastic Compute Cloud (EC2)
+ API. Fidelity with the EC2 API and the installation experience for this functionality are
+ both enhanced. In prior releases, users were required to install a separate component
+ called CloudBridge, in addition to installing the Management Server. For new installations
+ of CloudStack 4.0.0-incubating, this software is installed automatically along with
+ CloudStack and runs in a more closely integrated fashion. The feature is disabled by
+ default, but can be easily enabled by setting the appropriate global configuration
+ parameter and performing a few setup steps.
+
+
+ The Nicira NVP Plugin
+ The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized
+ network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating
+ this plug-in supports the Connectivity service. This service is responsible for creating
+ Layer 2 networks supporting the networks created by guests. When a tenant creates a new
+ network, instead of a traditional VLAN, a logical network will be created by sending the
+ appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira
+ NVP versions 2.1.0, 2.2.0 and 2.2.1.
+
+
+ Support for CAStor Cluster
+ CloudStack 4.0.0-incubating supports using a CAStor cluster as the back-end storage
+ system for a CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends
+ the existing storage classes and allows the storage configuration attribute to point to a
+ CAStor cluster. This feature makes use of the CloudStack server's local disk to spool
+ files before writing them to CAStor when handling the PUT operations. However, a file must
+ be successfully written into the CAStor cluster prior to the return of a success code to
+ the S3 client to ensure that the transaction outcome is correctly reported.
+ The S3 multipart file upload is not supported in this release. You are prompted with
+ proper error message if a multipart upload is attempted.
+
+
+ Clustered Logical Volume Manager Support for KVM
+ This release adds Clustered Logical Volume Manager (CLVM) storage support for KVM
+ hosts. With this support, you can use CLVM as primary storage.
+ The CLVM support for KVM allows root and data disks (primary storage) to reside on
+ Linux logical volumes. The administrators are required to configure CLVM on the KVM hosts
+ independent of CloudStack. When the volume groups are available, an administrator can
+ simply add primary storage of type CLVM, providing the volume group name. Then CloudStack
+ creates and manages logical volumes as needed.
+ CLVM also supports Snapshots. CloudStack creates an LVM snapshot, copy the applicable
+ logical volume to the secondary storage in the qcow2 format, and then delete the LVM
+ snapshot.
+
+
+ Rados Block Device Support for KVM
+ You can now use Rados Block Device (RBD) to run instances on Apache CloudStack
+ 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using
+ RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least
+ 0.10 with RBD enabled on the KVM host
+ Create a disk offering for RBD so that you can ensure that StoragePoolAllocator
+ chooses the RBD pool to deploy instances.
+
+
+
+ Issues Fixed in 4.0.0-incubating
+ Many bugs include a defect number that reflects the bug number that was held in the bug
+ tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira to manage its bugs, so
+ some of the bugs that are referenced here may not be available to view. However, we are
+ still including them for completeness.
+
+
+
+
+
+
+
+ Defect
+
+
+ Description
+
+
+
+
+
+ Many
+ vSphere 5.0 now has GA support. Formerly only Beta support was
+ provided.
+
+
+ CS-16135
+ Creating volumes after upgrading from snapshot taken in 2.2.14 no longer
+ deletes the snapshot physically from the secondary storage.
+
+
+ CS-16122
+ In a site-to-site VPN setup, alerts are generated when the VPC virtual
+ router is rebooted with multiple vpn connections.
+
+
+ CS-16022
+ If host connection fails due to a database error, host now disconnects
+ and the Managerment Server id is removed.
+
+
+ CS-16011
+ Name of network offering is no longer truncated due to too-narrow field
+ width in Add Guest Network dialog box.
+
+
+
+ CS-15978
+ When the virtual router and its host go down, the high availability
+ mechanism now works for the virtual router.
+
+
+
+ CS-15921
+ The 2.2.x security group script now accounts for the VMs created in the
+ version 2.1 timeframe.
+
+
+
+ CS-15919
+ A level parameter is added to the listVolumes command; therefore queries
+ return the response more quickly.
+
+
+ CS-15904
+ Upgrade from version 2.2.14 to CloudStack-3.0.5-0.2944-rhel5 works as
+ expected. The upgrade script,
+ /usr/share/cloud/setup/db/schema-2214to30-cleanup.sql, works as
+ expected.
+
+
+ CS-15879
+ The database upgrade from version 3.0.4 to 3.0.5 works as
+ expected.
+
+
+
+ CS-15807
+ Network label for OVM now available in UI.
+
+
+
+ CS-15779
+ When the thumbnail is requested, the console session will not be
+ terminated.
+
+
+
+ CS-15778
+ Fetching a VM thumbnail now gets a thumbnail of appropriate visual
+ dimensions.
+
+
+
+ CS-15734
+ KVM Snapshots no longer shows incorrect disk usage.
+
+
+ CS-15733
+ The domainId parameter for the listNetworks command now lists the
+ resources belonging to the domain specified.
+
+
+ CS-15676
+ Stopping the router no longer fails with the null pointer
+ exception.
+
+
+
+ CS-15648
+ If creating a volume from a snapshot fails, the error is reported on the
+ UI but the volume is stuck in the creating state.
+
+
+
+ CS-15646
+ createFirewallRule API no longer causes null pointer
+ exception.
+
+
+ CS-15628
+ In a KVM host, the high availability mechanism no longer takes a long
+ time to migrate VMs to another KVM host if there are multiple storage
+ pools.
+
+
+ CS-15627
+ Metadata instance-id and vm-id for existing VMs stays the same after
+ upgrade.
+
+
+ CS-15621
+ Solved difficulty with allocating disk volumes when running multiple VM
+ deployment in parallel.
+
+
+ CS-15603
+ CloudStack now stop the VMs when destroyVM command is
+ called.
+
+
+ CS-15586
+ Public Vlan for an account no longer fails if multiple physical networks
+ are present.
+
+
+ CS-15582
+ The dns-name filter is now supported for ec2-describe-instances in the
+ Amazon Web Services API compatibility commands. The filter maps to the name of a
+ user VM.
+
+
+ CS-15503
+ An IP address which has static NAT rules can now be released.
+ Subsequently, restarting this network after it was shutdown can
+ succeed.
+
+
+ CS-15464
+ Can now delete static route whose state is set to Revoke.
+
+
+ CS-15443
+ Creating a firewall rule no longer fails with an internal server
+ error.
+
+
+ CS-15398
+ Corrected technique for programming DNS on the user VMs.
+
+
+ CS-15356
+ Internal DNS 2 entry now correctly shown in UI.
+
+
+ CS-15335
+ The CloudBridge S3 Engine now connects to the database by using the
+ deciphered password in the db.properties file.
+
+
+ CS-15318
+ UI now correctly prevents the user from stopping a VM that is in the
+ Starting state.
+
+
+ CS-15307
+ Fixed Japanese localization of instance statuses in the Instances
+ menu.
+
+
+ CS-15278
+ The deployment planner no longer takes long time to locate a suitable
+ host to deploy VMs when large number of clusters are present.
+
+
+ CS-15274
+ Creating a VLAN range using Zone ID without network ID now
+ succeeds.
+
+
+ CS-15243
+ Now check to be sure source NAT and VPN have same
+ provider.
+
+
+ CS-15232
+ Ensure that networks using external load balancer/firewall in 2.2.14 or
+ earlier can properly upgrade.
+
+
+ CS-15200
+ No exception when trying to attach the same volume while attaching the
+ first volume is in progress.
+
+
+ CS-15173
+ Additional cluster can no longer be added with same VSM IP address as
+ another cluster.
+
+
+ CS-15167
+ AWS API calls now honor the admin account's ability to view or act on the
+ resources owned by the regular users.
+
+
+ CS-15163
+ The minimum limit is not honored when there is not enough capacity to
+ deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2>
+ option is used to deploy multiple VMs.
+
+
+ CS-15157
+ Can now add/enable service providers for multiple physical networks
+ through the UI.
+
+
+ CS-15145
+ AWS API call ec2-register has better error handling for negative
+ cases.
+
+
+ CS-15122
+ Filters now supported for AWS API call
+ ec2-describe-availability-zones.
+
+
+ CS-15120
+ Actions column in UI of Volume page now shows action
+ links.
+
+
+ CS-15099
+ Buttons no longer overlap text on Account Deletion confirmation page in
+ UI.
+
+
+ CS-15095
+ Ensures you can not create a VM with a CPU frequency greater than the
+ host CPU frequency.
+
+
+ CS-15094
+ CPU cap now set properly in VMware.
+
+
+ CS-15077
+ NullPointerException is no longer observed while executing the command to
+ list the public IP in a basic zone created with the default shared NetScaler EIP
+ and ELB network offering.
+
+
+ CS-15044
+ UI now provides option to view the list of instances which are part of
+ the guest network.
+
+
+ CS-15026
+ UI in Deploy VM dialog now lists only templates or ISOs depending on
+ which is selected in previous dialog.
+
+
+ CS-14989
+ In KVM, the Create Instance wizard now shows only templates from the
+ current (KVM) zone.
+
+
+ CS-14986, CS-14985
+ Listing filters works as expected in the ec2-describe-volumes and
+ ec2-describe-snapshots commands.
+
+
+ CS-14964
+ Automatically starting the Console Proxy no longer fails due to its
+ missing volume on the primary storage
+
+
+ CS-14907
+ User is now correctly prevented from trying to download an uploaded
+ volume which has not yet been moved to primary storage.
+
+
+ CS-14879
+ When a user VM is stopped or terminated, the static NAT associated with
+ this VM is now disabled. This public IP address is no longer owned by this account
+ and can be associated to any other user VM.
+
+
+ CS-14854
+ Only the admin user can change the template permission to Public, so this
+ option is removed from the UI for domain Admins and regular Users.
+
+
+ CS-14817
+ While checking if network has any external provider, CloudStack will
+ consider all providers in the network.
+
+
+ CS-14796
+ When deploying a VM with ec2-run-instances, userdata is now
+ encoded.
+
+
+ CS-14770
+ The API returns the keypair information when a VM is deployed with
+ sshkey. This affects the API commands related to virtual machines
+ (deployVirtualMachine, listVirtualMachines, ... *VirtualMachine), as well as the
+ corresponding AWS APIs.
+
+
+ CS-14724
+ UI no longer displays the dropdown list of isolation method choices if
+ sdn.ovs.controller is false.
+
+
+ CS-14345
+ Logout API returns XML header.
+
+
+ CS-14724
+ Host IPs now associated with appropriate IPs according to traffic
+ type.
+
+
+ CS-14253
+ Can now delete and re-create port forwarding rule on same
+ firewall.
+
+
+ CS-14724
+ UI no longer displays the dropdown list of isolation method choices if
+ sdn.ovs.controller is false.
+
+
+ CS-14452
+ Data disk volumes are now automatically copied from one cluster to
+ another.
+
+
+ CS-13539
+ Windows VM can get IP after reboot.
+
+
+ CS-13537
+ When user tries to delete a domain that contains sub-domains, an error
+ message is now sent to convey the reason for the delete failure.
+
+
+ CS-13153
+ System VMs support HTTP proxy.
+
+
+ CS-12642
+ Added Close button to Select Project list view popup in
+ UI.
+
+
+ CS-12510
+ Deleting and reinserting host_details no longer causes
+ deadlocks.
+
+
+ CS-12407
+ F5 and Netscaler - when dedicated is selected, capacity field is
+ disabled.
+
+
+ CS-12111
+ Email validation for edit user form.
+
+
+ CS-10928
+ Network read/write values now always positive numbers.
+
+
+ CS-15376, CS-15373
+ The AWS APIs (EC2 and S3) now listen on the 7080 port and send request to
+ CloudStack on the 8080 port just as any other clients of
+ CloudStack.
+
+
+ CS-13944
+ The CloudStack 2.2.x to 3.0.x database upgrade for multiple physical
+ networks is now supported.
+
+
+ CS-15300
+ The admin accounts of a domain now honour the limits imposed on that
+ domain just like the regular accounts do. A domain admin now is not allowed to
+ create an unlimited number of instances, volumes, snapshots, and so
+ on.
+
+
+ CS-15396
+ The CloudStack database now contain the UUD information after the 2.2.14
+ to 3.0.4 upgrade.
+
+
+ CS-15450
+ Upgrade from 2.2.14 to 3.0.4 no longer fails on a VMware
+ host.
+
+
+ CS-15449
+ Running cloudstack-aws-api-register no longer fails with the "User
+ registration failed with error: [Errno 113] No route to host"
+ error.
+
+
+ CS-15455
+ The iptable rules are configured to open the awsapi port (7080) as part
+ of the installation.
+
+
+ CS-15429
+ While creating an instance with data volume, disk offering also is
+ considered while checking the account limit on volume resources.
+
+
+ CS-15414
+ After the 2.2.14 to 3.0.4 upgrade, the value of the global parameter
+ xen.guest.network.device is now decrypted before setting the traffic
+ label.
+
+
+ CS-15382
+ During 2.2.14 to 3.0.4 upgrade, the hosts no longer go to the Alert state
+ if destroyed networks existed with non-existent tags prior to
+ upgrade.
+
+
+ CS-15323
+ CloudStack supports the following Citrix XenServer hotfixes: XS602E003,
+ XS602E004, and XS602E005.
+
+
+ CS-15430
+ Create snapshot now fails if creating a snapshot exceeds the snapshot
+ resource limit for a domain admin or a user account.
+
+
+ CS-14256
+ Virtual Router no longer remains in starting state for subdomain or user
+ on a KVM 3.0.1 prerlease host on RHEL 6.2.
+
+
+ CS-7495
+ Implemented a variety of Xen management host improvements.
+
+
+ CS-8105
+ NFS v4 for primary storage now works as expected on KVM
+ hosts.
+
+
+ CS-9989
+ The error messages returned during VM deployment failure will have much
+ more details than before.
+
+
+ CS-12584
+ You can no longer add security groups not supported by the hypervisor in
+ use.
+
+
+ CS-12705
+ When creating a Network offering by using SRX as the service provider for
+ SourceNAT servcies, an option is given in the CloudStack UI now to set the
+ source_nat type to "per Zone"/"per account".
+
+
+ CS-12782
+ Assigning a VM from Basic to Advanced zone no longer ignores the network
+ ID. A warning message is displayed for VM movements across zones.
+
+
+ CS-12591
+ Broadcast Address on the Second Public IP NIC is now
+ corrected.
+
+
+ CS-13272
+ When a user is deleted, all the associated properties, such as IPs and
+ virtual routers, are now deleted.
+
+
+ CS-13377
+ Creating template from a root disk of a stopped instance now provides an
+ option to make it a "Featured template".
+
+
+ CS-13500
+ Reaching the first guest VM by using its public IP from the second guest
+ VM no longer fails.
+
+
+ CS-13853
+ The default gateway can no longer be 0.0.0.0 in the Secondary Storage VM
+ (SSVM).
+
+
+ CS-13863
+ The queryAsyncJobResult command in XML format now returns the correct
+ UUIDs.
+
+
+ CS-13867
+ Corrected CSP xenserver-cloud-supp.tgz for XenServer 5.6 and
+ 6.0.
+
+
+ CS-13904
+ Labels and values for the service offerings CPU and memory are now
+ consistent.
+
+
+ CS-13998
+ The SSVM kernel panic issue is fixed on XenServer.
+
+
+ CS-14090
+ The issue is fixed where running the VMware snapshots randomly fails with
+ the ArrayIndexOutOfBoundsException error.
+
+
+ CS-14021
+ The java.lang.OutOfMemoryError is fixed on the Management
+ Server.
+
+
+ CS-14025
+ The Python Eggs are provided to easily package the test client for each
+ branch of CloudStack.
+
+
+ CS-14068
+ Resetting the VM password through the CloudStack UI no longer causes any
+ error.
+
+
+ CS-14156
+ The pod which has the administrator's virtual router is no longer
+ selected while creating the virtual routers for guests.
+
+
+ CS-14182
+ The users can now delete their ISOs as normal users.
+
+
+ CS-14185
+ The listOSTypes API now filters out the types of operating system by
+ using the keywords.
+
+
+ CS-14204
+ The cloud-setup-bonding.sh command no longer generates the "command not
+ found" error.
+
+
+ CS-14214
+ The Specify VLAN option cannot be enabled now for an isolated Network
+ offering with SourceNAT enabled.
+
+
+ CS-14234
+ Sending project invite email to an account now requires SMTP configured
+ in CloudStack.
+
+
+ CS-14237
+ The garbage collector of the primary storage no longer fails when the
+ first host in the cluster is not up.
+
+
+ CS-14241
+ Custom Volume Disk Offering is now matching the Global configuration
+ value.
+
+
+ CS-14270
+ The listNetworks API no longer assumes that the broadcast type is always
+ VLAN.
+
+
+ CS-14319
+ The internal name of the VM is no longer present in the error message
+ that is displayed to a domain administrator.
+
+
+ CS-14321
+ The listVolumes API call now returns a valid value for the isExtractable
+ parameter for the ISO-derived disk and data disk volumes.
+
+
+ CS-14323
+ Invalid API calls will now give valid response in json/xml
+ format.
+
+
+ CS-14339
+ Custom Disk Size will now allow values larger than 100GB.
+
+
+ CS-14357
+ The ConsoleProxyLoadReportCommand is no longer fired
+ continuously.
+
+
+ CS-14421
+ Fixed the issue of virtual router deployments. The DHCP entries can now
+ be assigned to the router.
+
+
+ CS-14555
+ Unzipped downloaded template MD5SUM will no longer override the zipped
+ template MD5SUM in the database.
+
+
+ CS-14598
+ The complete screen of the running VM is now displayed in the console
+ proxy.
+
+
+ CS-14600
+ Windows or Linux based consoles are no longer lost upon rebooting
+ VMs.
+
+
+ CS-14784
+ Multiple subnets with the same VLAN now work as expected.
+
+
+ CS-13303, 14874, 13897, 13944, 14088, 14190
+ A variety of upgrade issues have been fixed in release
+ 3.0.3.
+
+
+ CS-15080
+ Setting a private network on a VLAN for VMWare environment is now
+ supported.
+
+
+ CS-15168
+ The console proxy now works as expected and no exception is shown in the
+ log after upgrading from version 2.2.14 to 3.0.2.
+
+
+ CS-15172
+ Version 3.0.2 now accepts the valid public key.
+
+
+
+
+
+
+ Known Issues in 4.0.0-incubating
+
+
+
+
+
+
+
+ Issue ID
+
+
+ Description
+
+
+
+
+
+ CLOUDSTACK-301
+ Nexus 1000v DVS integration is not functional
+ This source code release includes some partial functionality to support the
+ Cisco Nexus 1000v Distributed Virtual Switch within a VMware hypervisor
+ environment. The functionality is not complete at this time.
+
+
+
+ CLOUDSTACK-368
+ OVM - cannot create guest VM
+ This source code release has regressed from the CloudStack 2.2.x code
+ and is unable to support Oracle VM (OVM).
+
+
+
+ CLOUDSTACK-279
+ Deleting a project fails when executed by the regular user. This works as
+ expected for root/domain admin. To workaround, perform either of the
+ following:
+
+ Use the account cleanup thread which will eventually complete the project
+ deletion.
+
+
+ Execute the call as the root/domain admin on behalf of the regular
+ user.
+
+
+
+
+
+ CS-16067
+ The command=listTags&key=city command does not work as expected. The
+ command does not return tags for the resources of the account with the tag, city
+
+
+
+
+ CS-16063
+ The current values of volumes and snapshots are incorrect when using KVM
+ as a host. To fix this, the database upgrade codes, volumes.size and
+ snapshots.size, should be changed to show the virtual sizes.
+
+
+
+ CS-16058
+ Null pointer Exception while deleting the host after moving the host to
+ maintenance state.
+
+
+
+ CS-16045
+ Only the root administrator can handle the API keys. The domain
+ administrators are not allowed to create, delete, or retrieve API keys for the
+ users in their domain.
+
+
+
+ CS-16019
+ CIDR list in the Add VPN Customer Gateway dialog does not prompt the user
+ that they can provide a comma separated CIDRs if multiple CIDRs have to be
+ supplied.
+
+
+
+ CS-16015
+ Deleting a network is not supported when its network providers are
+ disabled.
+
+
+
+ CS-16012
+ Unable to delete a zone in the UI because the necessary cleanup cannot be
+ completed. When the hosts are removed, the expunge process fails to delete the
+ volumes as no hosts are present to send the commands to. Therefore, the storage
+ pool removal fails, and zone can't be cleaned and deleted.
+
+
+
+ CS-16011
+ Name of network offering might be truncated due to too-narrow field width
+ in Add Guest Network dialog box.
+
+
+
+ CS-15789
+ Invalid global setting prevents management server to restart. For
+ example, if you configure the "project.invite.timeout" parameter to "300" and
+ attempt to restart management server, it fails without throwing a warning or
+ setting the value to the default.
+
+
+
+ CS-15749
+ Restarting VPC is resulting in intermittent connection loss to the port
+ forwarding and StaticNAT rules.
+
+
+
+ CS-15690
+ The IpAssoc command failed as a part of starting the virtual router, but
+ the final start result is reported as succes.
+
+
+
+ CS-15672, CS-15635
+ The FQDN of the VM is not configured if it is deployed as a part of
+ default shared network and isolated guest network
+ (DefaultIsolatedNetworkOfferingWithSourceNatService).
+
+
+
+ CS-15634
+ The FQDN of a VM that is deployed as a part of both a shared network and
+ default isolated guest network has the suffix of the shared network instead of the
+ default isolated guest network.
+
+
+
+ CS-15576
+ Stopping a VM on XenServer creates a backlog of API commands. For
+ example, the Attach volume calls become delayed while waiting for the
+ stopVirtualMachine command to be executed.
+
+
+
+ CS-15569
+ Misleading error message in the exception when creating a StaticNAT rule
+ fails in a VPC.
+
+
+
+ CS-15566
+ External device such as Netscaler is not supported in VPC.
+
+
+ CS-15557
+ Intermittent traffic loss in the VPN connection if Juniper is the remote
+ router and the life time is 300 seconds.
+
+
+
+ CS-15361
+ Egress rules are not working in NetScaler loadbalancer.
+
+
+
+ CS-15163
+ The minimum limit is not honored when there is not enough capacity to
+ deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2>
+ option is used to deploy multiple VMs.
+
+
+ CS-15105
+ The cloud-sysvmadm script does not work if the integration.api.port
+ parameter is set to any port other than 8096.
+
+
+ CS-15092
+ Connecting to the guest VMs through SSH is extremely slow, and it results
+ in connection timeout.
+
+
+ CS-15037
+ Hairpin NAT is not supported when NetScaler is used for
+ EIP.
+
+
+ CS-15009
+ The port_profile table will not be populated with port profile
+ information. In this release, CloudStack directly connects to the VSM for all the
+ port profile operations; therefore, no port profile information is
+ cached.
+
+
+ CS-14939
+ Adding a VMware cluster is not supported when the Management Network is
+ migrated to the Distributed Virtual Switch environment.
+
+
+ CS-14780
+ You are allowed to ping the elastic IP address of the VM even though no
+ ingress rule is set that allows the ICMP protocol.
+
+
+ CS-14756
+ Installing KVM on RHEL 6.2 will result in unreliable network performance.
+ Workaround: blacklist vhost-net. Edit /etc/modprobe.d/blacklist-kvm.conf and
+ include vhost-net.
+
+
+ CS-14346
+ The UpdateVirtualMachine API call does not check whether the VM is
+ stopped. Therefore, stop the VM manually before issuing this call.
+
+
+ CS-14303 (was 14537)
+ The IP addresses for a shared network are still being consumed even if no
+ services are defined for that network.
+
+
+ CS-14296 (was 14530)
+ OVM: Network traffic labels are not supported.
+
+
+ CS-14291 (was 14523)
+ The EIP/ELB network offering for basic zones does not support multiple
+ NetScalers.
+
+
+ CS-14275 (was 14506)
+ F5: Unable to properly remove a F5 device.
+
+
+ CS-14201 (was 14430)
+ VMWare: Template sizes are being reported different depending on whether
+ the primary storage is using ISCSI or NFS.
+
+
+ CS-13758 (was 13963)
+ vSphere: template download from templates created off of the root volume
+ does not work properly.
+
+
+ CS-13733 (was 13935)
+ vSphere: detaching an ISO from a restored VM instance
+ fails.
+
+
+ CS-13682 (was 13883)
+ Multiple NetScalers are not supported in Basic Networking.
+
+
+ CS-13599 (was 13359)
+ Programming F5/NetScaler rules can be better optimized.
+
+
+ CS-13337 (was 13518)
+ Security Groups are not supported in Advanced Networking
+
+
+ CS-13173 (was 13336)
+ vSphere: cross cluster volume migration does not work
+ properly.
+
+
+ CS-12714 (was 12840)
+ Capacity view is not available for pods or clusters.
+
+
+ CS-12624 (was 12741)
+ vSphere: maintenance mode will not live migrate system VM to another
+ host.
+
+
+
+ CS-15476
+
+
+ The 2.2.14 to 4.0.0-incubating upgrade fails if multiple untagged physical
+ networks exist before the upgrade.
+
+
+
+
+ CS-15407
+
+
+ After the 2.2.14 to 4.0.0-incubating upgrade, VLAN allocation on multiple
+ physical networks does not happen as expected.
+ To workaround this issue, follow the instructions given below:
+
+
+ Revert to your 2.2.14 setup.
+
+
+ Stop all the VMs with the isolated virtual networks in your cloud
+ setup.
+
+
+ Run following query to find if any networks still have the NICs
+ allocated:
+
+
+ Check if any virtual guest networks have the NICs allocated:
+ #SELECT DISTINCT op.id from `cloud`.`op_networks` op JOIN `cloud`.`networks` n on op.id=n.id WHERE nics_count != 0 AND guest_type = 'Virtual';
+
+
+ If this returns any network IDs, then ensure the following:
+
+
+ All the VMs are stopped.
+
+
+ No new VM is started.
+
+
+ Shutdown the Management Server.
+
+
+
+
+ Remove the NICs count for the virtual network IDs returned in step
+ (a), and set the NIC count to 0:
+ UPDATE `cloud`.`op_networks` SET nics_count = 0 WHERE id = enter id of virtual network
+
+
+ Restart the Management Server, and wait for all the networks to shut
+ down.
+
+ Networks shutdown is determined by the network.gc.interval and
+ network.gc.wait parameters.
+
+
+
+
+
+ Ensure that all the networks are shut down and all the guest VNETs are
+ free.
+
+
+ Run the upgrade script.
+ This allocates all your guest VNET ranges to the first physical
+ network.
+
+
+ By using the updatePhysicalNetwork API, reconfigure the VNET ranges for
+ each physical network as desired.
+
+
+ Start all the VMs.
+
+
+
+
+
+
+ CS-14680
+
+
+ CloudStack and LDAP user validation cannot happen simultaneously because the
+ user password is hashed and stored in the database, and LDAP requires the
+ passwords in plain text.
+ To work with the LDAP user, the MD5 hash should be disabled in the login
+ process by commenting the following variable in sharedFunctions.js file available
+ at /usr/share/cloud/management/webapps/client/scripts, and restart the
+ cloud-management service.
+ var md5HashedLogin = false;
+ However, if md5HashedLogin is set to false, the end user can login with the
+ LDAP credentials but not with the CloudStack user credentials.
+
+
+
+ CS-14346
+ The UpdateVirtualMachine API call does not check whether the VM is
+ stopped. Therefore, stop the VM manually before issuing this call.
+
+
+ CS-15130
+ Data disk volumes are not automatically copied from one cluster to
+ another.
+
+
+ CS-14780
+ You are allowed to ping the elastic IP address of the VM even though no
+ ingress rule is set that allows the ICMP protocol.
+
+
+ CS-14939
+ Adding a VMware cluster is not supported when the Management Network is
+ migrated to the Distributed Virtual Switch environment.
+
+
+ CS-15009
+ The port_profile table will not be populated with port profile
+ information. In this release, CloudStack directly connects to the VSM for all the
+ port profile operations; therefore, no port profile information is
+ cached.
+
+
+ CS-15037
+ Hairpin NAT is not supported when NetScaler is used for
+ EIP.
+
+
+ CS-15092
+ Connecting to the guest VMs through SSH is extremely slow, and it results
+ in connection timeout.
+
+
+ CS-15105
+ The cloud-sysvmadm script does not work if the integration.api.port
+ parameter is set to any port other than 8096.
+
+
+ CS-15163
+ The minimum limit is not honored when there is not enough capacity to
+ deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2>
+ option is used to deploy multiple VMs.
+
+
+
+
+
+
+
+ API Changes from 3.0.2 to 4.0.0-incubating
+
+ New API Commands in 4.0.0-incubating
+
+
+ createCounter (Adds metric counter)
+
+
+ deleteCounter (Deletes a counter)
+
+
+ listCounters (List the counters)
+
+
+ createCondition (Creates a condition)
+
+
+ deleteCondition (Removes a condition)
+
+
+ listConditions (List Conditions for the specific user)
+
+
+ createTags. Add tags to one or more resources. Example:
+ command=createTags
+&resourceIds=1,10,12
+&resourceType=userVm
+&tags[0].key=region
+&tags[0].value=canada
+&tags[1].key=city
+&tags[1].value=Toronto
+
+
+ deleteTags. Remove tags from one or more resources. Example:
+ command=deleteTags
+&resourceIds=1,12
+&resourceType=Snapshot
+&tags[0].key=city
+
+
+ listTags (Show currently defined resource tags)
+
+
+ createVPC (Creates a VPC)
+
+
+ listVPCs (Lists VPCs)
+
+
+ deleteVPC (Deletes a VPC)
+
+
+ updateVPC (Updates a VPC)
+
+
+ restartVPC (Restarts a VPC)
+
+
+ createVPCOffering (Creates VPC offering)
+
+
+ updateVPCOffering (Updates VPC offering)
+
+
+ deleteVPCOffering (Deletes VPC offering)
+
+
+ listVPCOfferings (Lists VPC offerings)
+
+
+ createPrivateGateway (Creates a private gateway)
+
+
+ listPrivateGateways (List private gateways)
+
+
+ deletePrivateGateway (Deletes a Private gateway)
+
+
+ createNetworkACL (Creates a ACL rule the given network (the network has to belong to
+ VPC))
+
+
+ deleteNetworkACL (Deletes a Network ACL)
+
+
+ listNetworkACLs (Lists all network ACLs)
+
+
+ createStaticRoute (Creates a static route)
+
+
+ deleteStaticRoute (Deletes a static route)
+
+
+ listStaticRoutes (Lists all static routes)
+
+
+ createVpnCustomerGateway (Creates site to site vpn customer gateway)
+
+
+ createVpnGateway (Creates site to site vpn local gateway)
+
+
+ createVpnConnection (Create site to site vpn connection)
+
+
+ deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
+
+
+ deleteVpnGateway (Delete site to site vpn gateway)
+
+
+ deleteVpnConnection (Delete site to site vpn connection)
+
+
+ updateVpnCustomerGateway (Update site to site vpn customer gateway)
+
+
+ resetVpnConnection (Reset site to site vpn connection)
+
+
+ listVpnCustomerGateways (Lists site to site vpn customer gateways)
+
+
+ listVpnGateways (Lists site 2 site vpn gateways)
+
+
+ listVpnConnections (Lists site to site vpn connection gateways)
+
+
+ markDefaultZoneForAccount (Marks a default zone for the current account)
+
+
+ uploadVolume (Uploads a data disk)
+
+
+
+
+ Changed API Commands in 4.0.0-incubating
+
+
+
+
+
+
+ API Commands
+ Description
+
+
+
+
+
+ copyTemplate
+ prepareTemplate
+ registerTemplate
+ updateTemplate
+ createProject
+ activateProject
+ suspendProject
+ updateProject
+ listProjectAccounts
+ createVolume
+ migrateVolume
+ attachVolume
+ detachVolume
+ uploadVolume
+ createSecurityGroup
+ registerIso
+ copyIso
+ updateIso
+ createIpForwardingRule
+ listIpForwardingRules
+ createLoadBalancerRule
+ updateLoadBalancerRule
+ createSnapshot
+
+
+ The commands in this list have a single new response parameter, and no other
+ changes.
+ New response parameter: tags(*)
+
+ Many other commands also have the new tags(*) parameter in addition to other
+ changes; those commands are listed separately.
+
+
+
+
+ rebootVirtualMachine
+ attachIso
+ detachIso
+ listLoadBalancerRuleInstances
+ resetPasswordForVirtualMachine
+ changeServiceForVirtualMachine
+ recoverVirtualMachine
+ startVirtualMachine
+ migrateVirtualMachine
+ deployVirtualMachine
+ assignVirtualMachine
+ updateVirtualMachine
+ restoreVirtualMachine
+ stopVirtualMachine
+ destroyVirtualMachine
+
+
+ The commands in this list have two new response parameters, and no other
+ changes.
+ New response parameters: keypair, tags(*)
+
+
+
+
+ listSecurityGroups
+ listFirewallRules
+ listPortForwardingRules
+ listSnapshots
+ listIsos
+ listProjects
+ listTemplates
+ listLoadBalancerRules
+
+ The commands in this list have the following new parameters, and no other
+ changes.
+ New request parameter: tags (optional)
+ New response parameter: tags(*)
+
+
+
+
+ listF5LoadBalancerNetworks
+ listNetscalerLoadBalancerNetworks
+ listSrxFirewallNetworks
+ updateNetwork
+
+
+ The commands in this list have three new response parameters, and no other
+ changes.
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+
+ createZone
+ updateZone
+
+ The commands in this list have the following new parameters, and no other
+ changes.
+ New request parameter: localstorageenabled (optional)
+ New response parameter: localstorageenabled
+
+
+
+ listZones
+ New response parameter: localstorageenabled
+
+
+
+ rebootRouter
+ changeServiceForRouter
+ startRouter
+ destroyRouter
+ stopRouter
+
+ The commands in this list have two new response parameters, and no other
+ changes.
+ New response parameters: vpcid, nic(*)
+
+
+
+ updateAccount
+ disableAccount
+ listAccounts
+ markDefaultZoneForAccount
+ enableAccount
+
+ The commands in this list have three new response parameters, and no
+ other changes.
+ New response parameters: vpcavailable, vpclimit, vpctotal
+
+
+ listRouters
+
+ New request parameters: forvpc (optional), vpcid (optional)
+ New response parameters: vpcid, nic(*)
+
+
+
+ listNetworkOfferings
+
+ New request parameters: forvpc (optional)
+ New response parameters: forvpc
+
+
+
+ listVolumes
+
+ New request parameters: details (optional), tags (optional)
+ New response parameters: tags(*)
+
+
+
+ addTrafficMonitor
+
+ New request parameters: excludezones (optional), includezones
+ (optional)
+
+
+
+ createNetwork
+
+ New request parameters: vpcid (optional)
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+ listPublicIpAddresses
+
+ New request parameters: tags (optional), vpcid (optional)
+ New response parameters: vpcid, tags(*)
+
+
+
+ listNetworks
+
+ New request parameters: canusefordeploy (optional), forvpc (optional), tags
+ (optional), vpcid (optional)
+ New response parameters: canusefordeploy, vpcid, tags(*)
+
+
+
+ restartNetwork
+
+ New response parameters: vpcid, tags(*)
+
+
+
+ enableStaticNat
+
+ New request parameter: networkid (optional)
+
+
+
+ createDiskOffering
+
+ New request parameter: storagetype (optional)
+ New response parameter: storagetype
+
+
+
+ listDiskOfferings
+
+ New response parameter: storagetype
+
+
+
+ updateDiskOffering
+
+ New response parameter: storagetype
+
+
+
+ createFirewallRule
+
+ Changed request parameters: ipaddressid (old version - optional, new version -
+ required)
+ New response parameter: tags(*)
+
+
+
+ listVirtualMachines
+
+ New request parameters: isoid (optional), tags (optional), templateid
+ (optional)
+ New response parameters: keypair, tags(*)
+
+
+
+ updateStorageNetworkIpRange
+
+ New response parameters: id, endip, gateway, netmask, networkid, podid,
+ startip, vlan, zoneid
+
+
+
+ reconnectHost
+ A new response parameter is added: hahost.
+
+
+ addCluster
+ The following request parameters are added:
+
+
+ vsmipaddress (optional)
+
+
+ vsmpassword (optional)
+
+
+ vsmusername (optional)
+
+
+ The following parameter is made mandatory: podid
+
+
+
+ listVolumes
+ A new response parameter is added: status
+
+
+ migrateVolume
+ A new response parameter is added: status
+
+
+ prepareHostForMaintenance
+ A new response parameter is added: hahost.
+
+
+ addSecondaryStorage
+ A new response parameter is added: hahost.
+
+
+ enableAccount
+ A new response parameter is added: defaultzoneid
+
+
+ attachVolume
+ A new response parameter is added: status
+
+
+ cancelHostMaintenance
+ A new response parameter is added: hahost
+
+
+ addSwift
+ A new response parameter is added: hahost
+
+
+ listSwifts
+ A new response parameter is added: hahost
+
+
+ listExternalLoadBalancers
+ A new response parameter is added: hahost
+
+
+ createVolume
+ A new response parameter is added: status
+
+
+ listCapabilities
+ A new response parameter is added:
+ customdiskofferingmaxsize
+
+
+ disableAccount
+ A new response parameter is added: defaultzoneid
+
+
+ deployVirtualMachine
+ A new request parameter is added: startvm (optional)
+
+
+ deleteStoragePool
+ A new request parameter is added: forced (optional)
+
+
+ updateAccount
+ A new response parameter is added: defaultzoneid
+
+
+ addHost
+ A new response parameter is added: hahost
+
+
+ updateHost
+ A new response parameter is added: hahost
+
+
+ detachVolume
+ A new response parameter is added: status
+
+
+ listAccounts
+ A new response parameter is added: defaultzoneid
+
+
+ listHosts
+ A new response parameter is added: hahostA new request
+ parameter is added: hahost (optional)
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/remove-member-from-project.xml b/docs/tmp/en-US/xml_tmp/remove-member-from-project.xml
new file mode 100644
index 00000000000..dcd3746158c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/remove-member-from-project.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Removing a Member From a Project
+ When a member is removed from a project, the member’s resources continue to be owned by the project. The former project member cannot create any new resources within the project or use any of the project’s existing resources.
+ A member of a project can be removed by the project administrator, the domain administrator of the domain the project belongs to or of its parent domain, or the &PRODUCT; root administrator.
+
+ Log in to the &PRODUCT; UI.
+ In the left navigation, click Projects.
+ In Select View, choose Projects.
+ Click the name of the project.
+ Click the Accounts tab.
+ Click the name of the member.
+ Click the Delete button.
+
+
+
+ deletebutton.png: Removes a member
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/remove-tier.xml b/docs/tmp/en-US/xml_tmp/remove-tier.xml
new file mode 100644
index 00000000000..b5996eb2de3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/remove-tier.xml
@@ -0,0 +1,55 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Removing Tiers
+ You can remove a tier from a VPC. A removed tier cannot be revoked. When a tier is removed,
+ only the resources of the tier are expunged. All the network rules (port forwarding, load
+ balancing and staticNAT) and the IP addresses associated to the tier are removed. The IP address
+ still be belonging to the same VPC.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPC that you have created for the account is listed in the page.
+
+
+ Click the Configure button of the VPC for which you want to set up tiers.
+ The Configure VPC page is displayed. Locate the tier you want to work with.
+
+
+ Click the Remove VPC button:
+
+
+
+
+
+ remove-tier.png: removing a tier from a vpc.
+
+
+ Wait for some time for the tier to be removed.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/remove-vpc.xml b/docs/tmp/en-US/xml_tmp/remove-vpc.xml
new file mode 100644
index 00000000000..c5eff850fd3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/remove-vpc.xml
@@ -0,0 +1,68 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Editing, Restarting, and Removing a Virtual Private Cloud
+
+ Ensure that all the tiers are removed before you remove a VPC.
+
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ In the left navigation, choose Network.
+
+
+ In the Select view, select VPC.
+ All the VPCs that you have created for the account is listed in the page.
+
+
+ Select the VPC you want to work with.
+
+
+ To remove, click the Remove VPC button
+
+
+
+
+ remove-vpc.png: button to remove a VPC
+
+
+ You can edit the name and description of a VPC. To do that, select the VPC, then click
+ the Edit button.
+
+
+
+
+ edit-icon.png: button to edit a VPC
+
+
+ To restart a VPC, select the VPC, then click the Restart button.
+
+
+
+
+ restart-vpc.png: button to restart a VPC
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/removed-API-commands.xml b/docs/tmp/en-US/xml_tmp/removed-API-commands.xml
new file mode 100644
index 00000000000..51bb7cf4828
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/removed-API-commands.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Removed API commands
+
+ createConfiguration (Adds configuration value)
+ configureSimulator (Configures simulator)
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/removing-hosts.xml b/docs/tmp/en-US/xml_tmp/removing-hosts.xml
new file mode 100644
index 00000000000..468f36ecd3f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/removing-hosts.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Removing Hosts
+ Hosts can be removed from the cloud as needed. The procedure to remove a host depends on the hypervisor type.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/removing-vsphere-hosts.xml b/docs/tmp/en-US/xml_tmp/removing-vsphere-hosts.xml
new file mode 100644
index 00000000000..16830b7c17e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/removing-vsphere-hosts.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Removing vSphere Hosts
+ To remove this type of host, first place it in maintenance mode, as described in . Then use &PRODUCT; to remove the host. &PRODUCT; will not direct commands to a host that has been removed using &PRODUCT;. However, the host may still exist in the vCenter cluster.
+
diff --git a/docs/tmp/en-US/xml_tmp/removing-xenserver-kvm-hosts.xml b/docs/tmp/en-US/xml_tmp/removing-xenserver-kvm-hosts.xml
new file mode 100644
index 00000000000..c7043723ff6
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/removing-xenserver-kvm-hosts.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 .
+ 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
+
+
diff --git a/docs/tmp/en-US/xml_tmp/requirements-templates.xml b/docs/tmp/en-US/xml_tmp/requirements-templates.xml
new file mode 100644
index 00000000000..f434dbe871c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/requirements-templates.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Requirements for Templates
+
+ For XenServer, install PV drivers / Xen tools on each template that you create. This will enable live migration and clean guest shutdown.
+ For vSphere, install VMware Tools on each template that you create. This will enable console view to work properly.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/resizing-volumes.xml b/docs/tmp/en-US/xml_tmp/resizing-volumes.xml
new file mode 100644
index 00000000000..471411df5fe
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/resizing-volumes.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Resizing Volumes
+ &PRODUCT; does not provide the ability to resize root disks or data disks; the disk size is fixed based on the template used to create the VM. However, the tool VHD Resizer), while not officially supported by Cloud.com or Citrix, might provide a workaround. To increase disk size with VHD Resizer:
+
+ Get the VHD from the secondary storage.
+ Import it into VHD Resizer.
+ Resize the VHD.
+ Upload the new VHD.
+ Create a new VM.
+ Take a snapshot, then create a new template from that snapshot.
+ For more information, see How to Resize a Provisioning Server 5 Virtual Disk at the Citrix Knowledge Center
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/response-formats.xml b/docs/tmp/en-US/xml_tmp/response-formats.xml
new file mode 100644
index 00000000000..7b3f93ac636
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/response-formats.xml
@@ -0,0 +1,56 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Response Formats: XML and JSON
+ CloudStack supports two formats as the response to an API call. The default response is XML. If you would like the response to be in JSON, add &response=json to the Command String.
+ Sample XML Response:
+
+ <listipaddressesresponse>
+ <allocatedipaddress>
+ <ipaddress>192.168.10.141</ipaddress>
+ <allocated>2009-09-18T13:16:10-0700</allocated>
+ <zoneid>4</zoneid>
+ <zonename>WC</zonename>
+ <issourcenat>true</issourcenat>
+ </allocatedipaddress>
+ </listipaddressesresponse>
+
+ Sample JSON Response:
+
+ { "listipaddressesresponse" :
+ { "allocatedipaddress" :
+ [
+ {
+ "ipaddress" : "192.168.10.141",
+ "allocated" : "2009-09-18T13:16:10-0700",
+ "zoneid" : "4",
+ "zonename" : "WC",
+ "issourcenat" : "true"
+ }
+ ]
+ }
+ }
+
+
diff --git a/docs/tmp/en-US/xml_tmp/responses.xml b/docs/tmp/en-US/xml_tmp/responses.xml
new file mode 100644
index 00000000000..9f70c871932
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/responses.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Responses
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/roles.xml b/docs/tmp/en-US/xml_tmp/roles.xml
new file mode 100644
index 00000000000..473e37b77f9
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/roles.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Roles
+
+ The CloudPlatform API supports three access roles:
+
+ Root Admin. Access to all features of the cloud, including both virtual and physical resource management.
+ Domain Admin. Access to only the virtual resources of the clouds that belong to the administrator’s domain.
+ User. Access to only the features that allow management of the user’s virtual instances, storage, and network.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/root-admin-ui-overview.xml b/docs/tmp/en-US/xml_tmp/root-admin-ui-overview.xml
new file mode 100644
index 00000000000..f59aaea55ab
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/root-admin-ui-overview.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Root Administrator's UI Overview
+ The &PRODUCT; UI helps the &PRODUCT; 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/runtime-allocation-virtual-network-resources.xml b/docs/tmp/en-US/xml_tmp/runtime-allocation-virtual-network-resources.xml
new file mode 100644
index 00000000000..696ea9b9d6d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/runtime-allocation-virtual-network-resources.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Runtime Allocation of Virtual Network Resources
+ When you define a new virtual network, all your settings for that network are stored in &PRODUCT;. The actual network resources are activated only when the first virtual machine starts in the network. When all virtual machines have left the virtual network, the network resources are garbage collected so they can be allocated again. This helps to conserve network resources..
+
diff --git a/docs/tmp/en-US/xml_tmp/runtime-behavior-of-primary-storage.xml b/docs/tmp/en-US/xml_tmp/runtime-behavior-of-primary-storage.xml
new file mode 100644
index 00000000000..479ebce1ce1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/runtime-behavior-of-primary-storage.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Runtime Behavior of Primary Storage
+ Root volumes are created automatically when a virtual machine is created. Root volumes are deleted when the VM is destroyed. Data volumes can be created and dynamically attached to VMs. Data volumes are not deleted when VMs are destroyed.
+ Administrators should monitor the capacity of primary storage devices and add additional primary storage as needed. See the Advanced Installation Guide.
+ Administrators add primary storage to the system by creating a &PRODUCT; storage pool. Each storage pool is associated with a cluster.
+
diff --git a/docs/tmp/en-US/xml_tmp/runtime-internal-comm-req.xml b/docs/tmp/en-US/xml_tmp/runtime-internal-comm-req.xml
new file mode 100644
index 00000000000..f4539dd0307
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/runtime-internal-comm-req.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Runtime Internal Communications Requirements
+
+
+ The Management Servers communicate with each other to coordinate tasks. This
+ communication uses TCP on ports 8250 and 9090.
+
+
+ The console proxy VMs connect to all hosts in the zone over the management traffic
+ network. Therefore the management traffic network of any given pod in the zone must have
+ connectivity to the management traffic network of all other pods in the zone.
+
+
+ The secondary storage VMs and console proxy VMs connect to the Management Server on
+ port 8250. If you are using multiple Management Servers, the load balanced IP address of the
+ Management Servers on port 8250 must be reachable.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/scheduled-maintenance-maintenance-mode-hosts.xml b/docs/tmp/en-US/xml_tmp/scheduled-maintenance-maintenance-mode-hosts.xml
new file mode 100644
index 00000000000..6364e8b0c78
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/scheduled-maintenance-maintenance-mode-hosts.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/scratch.txt b/docs/tmp/en-US/xml_tmp/scratch.txt
new file mode 100644
index 00000000000..e69de29bb2d
diff --git a/docs/tmp/en-US/xml_tmp/search-base.xml b/docs/tmp/en-US/xml_tmp/search-base.xml
new file mode 100644
index 00000000000..b8fc0920158
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/search-base.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/search-user-bind-dn.xml b/docs/tmp/en-US/xml_tmp/search-user-bind-dn.xml
new file mode 100644
index 00000000000..a2d8b6a339c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/search-user-bind-dn.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 &PRODUCT; 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
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/secondary-storage-add.xml b/docs/tmp/en-US/xml_tmp/secondary-storage-add.xml
new file mode 100644
index 00000000000..e1f45cdec66
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/secondary-storage-add.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Add Secondary Storage
+
+ System Requirements for Secondary Storage
+
+ NFS storage appliance or Linux NFS server
+ (Optional) OpenStack Object Storage (Swift) (see http://swift.openstack.org)
+ 100GB minimum capacity
+ A secondary storage device must be located in the same zone as the guest VMs it serves.
+ Each Secondary Storage server must be available to all hosts in the zone.
+
+
+
+ Adding Secondary Storage
+ When you create a new zone, the first secondary storage is added as part of that procedure. You can add secondary storage servers at any time to add more servers to an existing zone.
+ Be sure there is nothing stored on the server. Adding the server to &PRODUCT; will destroy any existing data.
+
+ If you are going to use Swift for cloud-wide secondary storage, you must add the Swift storage to &PRODUCT; before you add the local zone secondary storage servers. See .
+ To prepare for local zone secondary storage, you should have created and mounted an NFS share during Management Server installation. See .See Preparing NFS Shares in the Installation Guide.
+ Make sure you prepared the system VM template during Management Server installation. See .See Prepare the System VM Template in the Installation Guide.
+ Now that the secondary storage server for per-zone storage is prepared, add it to &PRODUCT;. Secondary storage is added as part of the procedure for adding a new zone. See .
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/secondary-storage-outage-and-data-loss.xml b/docs/tmp/en-US/xml_tmp/secondary-storage-outage-and-data-loss.xml
new file mode 100644
index 00000000000..42ab7d47188
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/secondary-storage-outage-and-data-loss.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Secondary Storage Outage and Data Loss
+ For a Zone that has only one secondary storage server, a secondary storage outage will have feature level impact to the system but will not impact running guest VMs. It may become impossible to create a VM with the selected template for a user. A user may also not be able to save snapshots or examine/restore saved snapshots. These features will automatically be available when the secondary storage comes back online.
+ Secondary storage data loss will impact recently added user data including templates, snapshots, and ISO images. Secondary storage should be backed up periodically. Multiple secondary storage servers can be provisioned within each zone to increase the scalability of the system.
+
diff --git a/docs/tmp/en-US/xml_tmp/secondary-storage-vm.xml b/docs/tmp/en-US/xml_tmp/secondary-storage-vm.xml
new file mode 100644
index 00000000000..792644432d2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/secondary-storage-vm.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Secondary Storage VM
+ In addition to the hosts, &PRODUCT;’s Secondary Storage VM mounts and writes to secondary storage.
+ Submissions to secondary storage go through the Secondary Storage VM. The Secondary Storage VM can retrieve templates and ISO images from URLs using a variety of protocols.
+ The secondary storage VM provides a background task that takes care of a variety of secondary storage activities: downloading a new template to a Zone, copying templates between Zones, and snapshot backups.
+ The administrator can log in to the secondary storage VM if needed.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/secondary-storage.xml b/docs/tmp/en-US/xml_tmp/secondary-storage.xml
new file mode 100644
index 00000000000..e755b56734d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/secondary-storage.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Secondary Storage
+ This section gives concepts and technical details about &PRODUCT; secondary storage. For information about how to install and configure secondary storage through the &PRODUCT; UI, see the Advanced Installation Guide.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/security-groups.xml b/docs/tmp/en-US/xml_tmp/security-groups.xml
new file mode 100644
index 00000000000..3c08965c8d3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/security-groups.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Security Groups
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/security-req.xml b/docs/tmp/en-US/xml_tmp/security-req.xml
new file mode 100644
index 00000000000..a4869b43a70
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/security-req.xml
@@ -0,0 +1,24 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Security Requirements
+ The public Internet must not be able to access port 8096 or port 8250 on the Management Server.
+
diff --git a/docs/tmp/en-US/xml_tmp/send-projects-membership-invitation.xml b/docs/tmp/en-US/xml_tmp/send-projects-membership-invitation.xml
new file mode 100644
index 00000000000..164235f2abe
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/send-projects-membership-invitation.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 . If the invitations feature is not turned on, use the procedure in Adding Project Members From the UI.
+
+ Log in to the &PRODUCT; 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 &PRODUCT; when accepting the invitation. Email invitations will work only if the global parameters related to the SMTP server have been set. See .
+
+ Type the user name or email address of the new member you want to add, and click Invite. Type the &PRODUCT; 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.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/separate_storage_network.xml b/docs/tmp/en-US/xml_tmp/separate_storage_network.xml
new file mode 100644
index 00000000000..c3f6330cb14
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/separate_storage_network.xml
@@ -0,0 +1,24 @@
+
+%BOOK_ENTITIES;
+]>
+
+
+
+ Separate Storage Network
+ In the large-scale redundant setup described in the previous section, storage traffic can overload the management network. A separate storage network is optional for deployments. Storage protocols such as iSCSI are sensitive to network delays. A separate storage network ensures guest network traffic contention does not impact storage performance.
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/service-offerings.xml b/docs/tmp/en-US/xml_tmp/service-offerings.xml
new file mode 100644
index 00000000000..5283c05afa7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/service-offerings.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Service Offerings
+ vCenter Maintenance Mode
+ XenServer and Maintenance Mode
+ vCenter Maintenance Mode
+ XenServer and Maintenance Mode
+
diff --git a/docs/tmp/en-US/xml_tmp/set-database-buffer-pool-size.xml b/docs/tmp/en-US/xml_tmp/set-database-buffer-pool-size.xml
new file mode 100644
index 00000000000..1c7503101ca
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-database-buffer-pool-size.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Set Database Buffer Pool Size
+ It is important to provide enough memory space for the MySQL database to cache data and indexes:
+
+ Edit the Tomcat configuration file:/etc/my.cnf
+ Insert the following line in the [mysqld] section, below the datadir line. Use a value that is appropriate for your situation. We recommend setting the buffer pool at 40% of RAM if MySQL is on the same server as the management server or 70% of RAM if MySQL has a dedicated server. The following example assumes a dedicated server with 1024M of RAM.
+ innodb_buffer_pool_size=700M
+ Restart the MySQL service.# service mysqld restart
+
+ For more information about the buffer pool, see "The InnoDB Buffer Pool" at MySQL Reference Manual.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/set-global-project-resource-limits.xml b/docs/tmp/en-US/xml_tmp/set-global-project-resource-limits.xml
new file mode 100644
index 00000000000..d91942ad8db
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-global-project-resource-limits.xml
@@ -0,0 +1,82 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Setting the Global Project Resource Limits
+
+
+ Log in as administrator to the &PRODUCT; 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.
+ # service cloud-management restart
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/set-monitor-total-vm-limits-per-host.xml b/docs/tmp/en-US/xml_tmp/set-monitor-total-vm-limits-per-host.xml
new file mode 100644
index 00000000000..0cc247505af
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-monitor-total-vm-limits-per-host.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Set and Monitor Total VM Limits per Host
+ The &PRODUCT; administrator should monitor the total number of VM instances in each cluster, and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the documentation for your chosen hypervisor to find the maximum permitted number of VMs per host, then use &PRODUCT; global configuration settings to set this as the default limit. Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for one host in the cluster to be down at any given time, the total number of VM instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the &PRODUCT; UI to disable allocation of more VMs to the cluster.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/set-per-project-resource-limits.xml b/docs/tmp/en-US/xml_tmp/set-per-project-resource-limits.xml
new file mode 100644
index 00000000000..a0f64ea5a38
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-per-project-resource-limits.xml
@@ -0,0 +1,55 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Setting Per-Project Resource Limits
+ The &PRODUCT; 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 &PRODUCT; administrator
+ (as described in ). 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 &PRODUCT; 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.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/set-projects-creator-permissions.xml b/docs/tmp/en-US/xml_tmp/set-projects-creator-permissions.xml
new file mode 100644
index 00000000000..9b272f6bc7e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-projects-creator-permissions.xml
@@ -0,0 +1,62 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Setting Project Creator Permissions
+ You can configure &PRODUCT; to allow any user to create a new project, or you can restrict
+ that ability to just &PRODUCT; administrators.
+
+
+ Log in as administrator to the &PRODUCT; 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 &PRODUCT; root administrator and domain administrators to create
+ projects.
+
+
+
+
+
+
+ Restart the Management Server.
+ # service cloud-management restart
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/set-resource-limits-for-projects.xml b/docs/tmp/en-US/xml_tmp/set-resource-limits-for-projects.xml
new file mode 100644
index 00000000000..669ca259372
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-resource-limits-for-projects.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Setting Resource Limits for Projects
+ The &PRODUCT; 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 &PRODUCT; root administrator. The root
+ administrator can also set lower resource limits for any project in the cloud
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/set-up-invitations.xml b/docs/tmp/en-US/xml_tmp/set-up-invitations.xml
new file mode 100644
index 00000000000..e6a22dba1af
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-up-invitations.xml
@@ -0,0 +1,87 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Setting Up Invitations
+ &PRODUCT; 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 &PRODUCT; account. If you want administrators to use invitations to add members to projects, turn on and set up the invitations feature in &PRODUCT;.
+
+ Log in as administrator to the &PRODUCT; UI.
+ In the left navigation, click Global Settings.
+ In the search box, type project and click the search button.
+ In the search box, type project and click the search button.
+
+
+
+ searchbutton.png: Searches projects
+
+ In the search results, you will 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
+ service cloud-management restart
+
+
diff --git a/docs/tmp/en-US/xml_tmp/set-up-network-for-users.xml b/docs/tmp/en-US/xml_tmp/set-up-network-for-users.xml
new file mode 100644
index 00000000000..2b409232037
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-up-network-for-users.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Setting Up Networking for Users
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/set-usage-limit.xml b/docs/tmp/en-US/xml_tmp/set-usage-limit.xml
new file mode 100644
index 00000000000..3ef528a690c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-usage-limit.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Setting Usage Limits
+ &PRODUCT; provides several administrator control points for capping resource usage by users. Some of these limits are global configuration parameters. Others are applied at the ROOT domain and may be overridden on a per-account basis.
+ Aggregate limits may be set on a per-domain basis. For example, you may limit a domain and all subdomains to the creation of 100 VMs.
+ This section covers the following topics:
+ Globally Configured Limits
+ Default Account Resource Limits
+ Per Domain Limits
+
diff --git a/docs/tmp/en-US/xml_tmp/set-zone-vlan-run-vm-max.xml b/docs/tmp/en-US/xml_tmp/set-zone-vlan-run-vm-max.xml
new file mode 100644
index 00000000000..2159b753ce7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/set-zone-vlan-run-vm-max.xml
@@ -0,0 +1,65 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Setting Zone VLAN and Running VM Maximums
+ In the external networking case, every VM in a zone must have a unique guest IP address.
+ There are two variables that you need to consider in determining how to configure &PRODUCT;
+ to support this: how many Zone VLANs do you expect to have and how many VMs do you expect to
+ have running in the Zone at any one time.
+ Use the following table to determine how to configure &PRODUCT; for your
+ deployment.
+
+
+
+
+ guest.vlan.bits
+ Maximum Running VMs per Zone
+ Maximum Zone VLANs
+
+
+
+
+ 12
+ 4096
+ 4094
+
+
+ 11
+ 8192
+ 2048
+
+
+ 10
+ 16384
+ 1024
+
+
+ 10
+ 32768
+ 512
+
+
+
+
+ Based on your deployment's needs, choose the appropriate value of guest.vlan.bits. Set it as
+ described in Edit the Global Configuration Settings (Optional) section and restart the
+ Management Server.
+
diff --git a/docs/tmp/en-US/xml_tmp/shared-networks.xml b/docs/tmp/en-US/xml_tmp/shared-networks.xml
new file mode 100644
index 00000000000..d505fed97b1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/shared-networks.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Shared Networks
+ A shared network can be accessed by virtual machines that belong to many different accounts. Network Isolation on shared networks is accomplished using techniques such as security groups (supported only in basic zones in &PRODUCT; 3.0.3).
+
+ Shared Networks are created by the administrator
+ Shared Networks can be designated to a certain domain
+ Shared Network resources such as VLAN and physical network that it maps to are designated by the administrator
+ Shared Networks are isolated by security groups
+ Public Network is a shared network that is not shown to the end users
+
+
diff --git a/docs/tmp/en-US/xml_tmp/signing-api-requests.xml b/docs/tmp/en-US/xml_tmp/signing-api-requests.xml
new file mode 100644
index 00000000000..581b32a41ba
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/signing-api-requests.xml
@@ -0,0 +1,60 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Signing API Requests
+ Whether you access the CloudStack API with HTTP or HTTPS, it must still be signed so that CloudStack can verify the caller has been authenticated and authorized to execute the command. Make sure that you have both the API Key and Secret Key provided by the CloudStack administrator for your account before proceeding with the signing process.
+ To show how to sign a request, we will re-use the previous example.
+ http://http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+ Breaking this down, we have several distinct parts to this URL.
+
+ Base URL: This is the base URL to the CloudStack Management Server.
+ http://localhost:8080
+
+ API Path: This is the path to the API Servlet that processes the incoming requests.
+ /client/api?
+
+ Command String: This part of the query string comprises of the command, its parameters, and the API Key that identifies the account.
+ As with all query string parameters of field-value pairs, the "field" component is case insensitive while all "value" values are case sensitive.
+ command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ
+
+ Signature: This is the hashed signature of the Base URL that is generated using a combination of the user’s Secret Key and the HMAC SHA-1 hashing algorithm.
+ &signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+
+ Every API request has the format Base URL+API Path+Command String+Signature.
+ To generate the signature.
+
+ For each field-value pair (as separated by a '&') in the Command String, URL encode each value so that it can be safely sent via HTTP GET.
+ Make sure all spaces are encoded as "%20" rather than "+".
+
+ Lower case the entire Command String and sort it alphabetically via the field for each field-value pair. The result of this step would look like the following.
+ apikey=mivr6x7u6bn_sdahobpjnejpgest35exq-jb8cg20yi3yaxxcgpyuairmfi_ejtvwz0nukkjbpmy3y2bcikwfq&command=deployvirtualmachine&diskofferingid=1&serviceofferingid=1&templateid=2&zoneid=4
+
+ Take the sorted Command String and run it through the HMAC SHA-1 hashing algorithm (most programming languages offer a utility method to do this) with the user’s Secret Key. Base64 encode the resulting byte array in UTF-8 so that it can be safely transmitted via HTTP. The final string produced after Base64 encoding should be "Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D".
+ By reconstructing the final URL in the format Base URL+API Path+Command String+Signature, the final URL should look like:
+ http://localhost:8080/client/api?command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXq-jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/site-to-site-vpn.xml b/docs/tmp/en-US/xml_tmp/site-to-site-vpn.xml
new file mode 100644
index 00000000000..a102ebe1bb4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/site-to-site-vpn.xml
@@ -0,0 +1,62 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Setting Up a Site-to-Site VPN Connection
+ A Site-to-Site VPN connection helps you establish a secure connection from an enterprise
+ datacenter to the cloud infrastructure. This allows users to access the guest VMs by
+ establishing a VPN connection to the virtual router of the account from a device in the
+ datacenter of the enterprise. Having this facility eliminates the need to establish VPN
+ connections to individual VMs.
+ The supported endpoints on the remote datacenters are:
+
+
+ Cisco ISR with IOS 12.4 or later
+
+
+ Juniper J-Series routers with JunOS 9.5 or later
+
+
+
+ In addition to the specific Cisco and Juniper devices listed above, the expectation is
+ that any Cisco or Juniper device running on the supported operating systems are able to
+ establish VPN connections.
+
+ To set up a Site-to-Site VPN connection, perform the following:
+
+
+ Create a Virtual Private Cloud (VPC).
+ See .
+
+
+ Create a VPN Customer Gateway.
+
+
+ Create a VPN gateway for the VPC that you created.
+
+
+ Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/small_scale_deployment.xml b/docs/tmp/en-US/xml_tmp/small_scale_deployment.xml
new file mode 100644
index 00000000000..bba2b9a7573
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/small_scale_deployment.xml
@@ -0,0 +1,37 @@
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Small-Scale Deployment
+
+
+
+
+ Small-Scale Deployment
+
+ This diagram illustrates the network architecture of a small-scale &PRODUCT; deployment.
+
+ A firewall provides a connection to the Internet. The firewall is configured in NAT mode. The firewall forwards HTTP requests and API calls from the Internet to the Management Server. The Management Server resides on the management network.
+ A layer-2 switch connects all physical servers and storage.
+ A single NFS server functions as both the primary and secondary storage.
+ The Management Server is connected to the management network.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/snapshot-restore.xml b/docs/tmp/en-US/xml_tmp/snapshot-restore.xml
new file mode 100644
index 00000000000..b2f60f4b1e9
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/snapshot-restore.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Snapshot Restore
+ There are two paths to restoring snapshots. Users can create a volume from the snapshot. The volume can then be mounted to a VM and files recovered as needed. Alternatively, a template may be created from the snapshot of a root disk. The user can then boot a VM from this template to effect recovery of the root disk.
+
diff --git a/docs/tmp/en-US/xml_tmp/source-prereqs.xml b/docs/tmp/en-US/xml_tmp/source-prereqs.xml
new file mode 100644
index 00000000000..6c2bc2a3cb8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/source-prereqs.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Prerequisites for building Apache CloudStack
+
+ There are a number of prerequisites needed to build &PRODUCT;. This
+ document assumes compilation on a Linux system that uses RPMs or DEBs
+ for package management.
+
+
+ The minimum bootstrapped prerequisites for building &PRODUCT; includes
+ the following:
+
+ ant
+ maven (version 3)
+ Java (Java 6/OpenJDK 1.6)
+ rpmbuild or dpkg-dev
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/source.xml b/docs/tmp/en-US/xml_tmp/source.xml
new file mode 100644
index 00000000000..3cb4af2321f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/source.xml
@@ -0,0 +1,47 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Building from Source
+ The official &PRODUCT; release is always in source code form. While there may
+ exist convenience binaries in various forms from a number of places, the
+ source is the canonical release will be source. In this document we'll cover
+ acquiring the source release, building that into binary, deployable packages.
+
+
+ While building and deploying directly from source is certainly possible, the reality
+ of Infrastructure-as-a-Service cloud computing implies a need to deploy packages on
+ a potentially large number of systems, which RPMs and DEBs fill nicely.
+
+
+ Building and deploying directly from source is thus outside the scope of this
+ document, but is documented in the INSTALL.md file in the release.
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/standard-events.xml b/docs/tmp/en-US/xml_tmp/standard-events.xml
new file mode 100644
index 00000000000..b4a4c68a6cb
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/standard-events.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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
+
+
diff --git a/docs/tmp/en-US/xml_tmp/static-nat.xml b/docs/tmp/en-US/xml_tmp/static-nat.xml
new file mode 100644
index 00000000000..ef9e2fc9167
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/static-nat.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Static NAT
+ A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet traffic into the VM. The public IP address always remains the same, which is why it is called "static" NAT. This section tells how to enable or disable static NAT for a particular IP address.
+
diff --git a/docs/tmp/en-US/xml_tmp/sticky-session-policies-for-lb-rules.xml b/docs/tmp/en-US/xml_tmp/sticky-session-policies-for-lb-rules.xml
new file mode 100644
index 00000000000..a8acfa087d2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/sticky-session-policies-for-lb-rules.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Sticky Session Policies for Load Balancer Rules
+ Sticky sessions are used in Web-based applications to ensure continued availability of information across the multiple requests in a user's session. For example, if a shopper is filling a cart, you need to remember what has been purchased so far. The concept of "stickiness" is also referred to as persistence or maintaining state.
+ Any load balancer rule defined in &PRODUCT; can have a stickiness policy. The policy consists of a name, stickiness method, and parameters. The parameters are name-value pairs or flags, which are defined by the load balancer vendor. The stickiness method could be load balancer-generated cookie, application-generated cookie, or source-based. In the source-based method, the source IP address is used to identify the user and locate the user’s stored data. In the other methods, cookies are used. The cookie generated by the load balancer or application is included in request and response URLs to create persistence. The cookie name can be specified by the administrator or automatically generated. A variety of options are provided to control the exact behavior of cookies, such as how they are generated and whether they are cached.
+ For the most up to date list of available stickiness methods, see the &PRODUCT; UI or call listNetworks and check the SupportedStickinessMethods capability.
+
diff --git a/docs/tmp/en-US/xml_tmp/stop-restart-management-server.xml b/docs/tmp/en-US/xml_tmp/stop-restart-management-server.xml
new file mode 100644
index 00000000000..2edc23332c0
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/stop-restart-management-server.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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:
+ # service cloud-management stop
+ To start the Management Server:
+ # service cloud-management start
+ To stop the Management Server:
+ # service cloud-management stop
+
diff --git a/docs/tmp/en-US/xml_tmp/stopped-vm.xml b/docs/tmp/en-US/xml_tmp/stopped-vm.xml
new file mode 100644
index 00000000000..7024be7a0b2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/stopped-vm.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Stopped VM
+ &PRODUCT; now supports creating a VM without starting it. You can determine whether the VM needs to be started as part of the VM deployment. A VM can now be deployed in two ways: create and start a VM (the default method); or create a VM and leave it in the stopped state.
+ A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature.
+ The possible values are:
+
+ true - The VM starts as a part of the VM deployment.
+ false - The VM is left in the stopped state at the end of the VM deployment.
+
+ The default value is true.
+
diff --git a/docs/tmp/en-US/xml_tmp/stopping-and-starting-vms.xml b/docs/tmp/en-US/xml_tmp/stopping-and-starting-vms.xml
new file mode 100644
index 00000000000..8b294af0b90
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/stopping-and-starting-vms.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Stopping and Starting VMs
+ Any user can access their own virtual machines. The administrator can access all VMs running in the cloud.
+
diff --git a/docs/tmp/en-US/xml_tmp/storage-nw-topology-req.xml b/docs/tmp/en-US/xml_tmp/storage-nw-topology-req.xml
new file mode 100644
index 00000000000..a594babea37
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/storage-nw-topology-req.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Storage Network Topology Requirements
+ The secondary storage NFS export is mounted by the secondary storage VM. Secondary storage
+ traffic goes over the management traffic network, even if there is a separate storage network.
+ Primary storage traffic goes over the storage network, if available. If you choose to place
+ secondary storage NFS servers on the storage network, you must make sure there is a route from
+ the management traffic network to the storage network.
+
diff --git a/docs/tmp/en-US/xml_tmp/storage-overview.xml b/docs/tmp/en-US/xml_tmp/storage-overview.xml
new file mode 100644
index 00000000000..bebf441ab60
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/storage-overview.xml
@@ -0,0 +1,27 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Storage Overview
+ &PRODUCT; defines two types of storage: primary and secondary. Primary storage can be
+ accessed by either iSCSI or NFS. Additionally, direct attached storage may be used for primary
+ storage. Secondary storage is always accessed using NFS.
+ There is no ephemeral storage in &PRODUCT;. All volumes on all nodes are persistent.
+
diff --git a/docs/tmp/en-US/xml_tmp/storage-tags.xml b/docs/tmp/en-US/xml_tmp/storage-tags.xml
new file mode 100644
index 00000000000..39b55a65fdd
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/storage-tags.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Storage Tags
+ Storage may be "tagged". A tag is a text string attribute associated with primary storage, a Disk Offering, or a Service Offering. Tags allow administrators to provide additional information about the storage. For example, that is a "SSD" or it is "slow". Tags are not interpreted by &PRODUCT;. They are matched against tags placed on service and disk offerings. &PRODUCT; requires all tags on service and disk offerings to exist on the primary storage before it allocates root or data disks on the primary storage. Service and disk offering tags are used to identify the requirements of the storage that those offerings have. For example, the high end service offering may require "fast" for its root disk volume.
+ The interaction between tags, allocation, and volume copying across clusters and pods can be complex. To simplify the situation, use the same set of tags on the primary storage for all clusters in a pod. Even if different devices are used to present those tags, the set of exposed tags can be the same.
+
diff --git a/docs/tmp/en-US/xml_tmp/storage.xml b/docs/tmp/en-US/xml_tmp/storage.xml
new file mode 100644
index 00000000000..86d3f53e766
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/storage.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Working With Storage
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/suspend-project.xml b/docs/tmp/en-US/xml_tmp/suspend-project.xml
new file mode 100644
index 00000000000..b4f821b2c26
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/suspend-project.xml
@@ -0,0 +1,52 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 &PRODUCT; root administrator.
+
+ Log in to the &PRODUCT; 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
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/sys-reliability-and-ha.xml b/docs/tmp/en-US/xml_tmp/sys-reliability-and-ha.xml
new file mode 100644
index 00000000000..5c544af0e10
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/sys-reliability-and-ha.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ System Reliability and High Availability
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/sysprep-for-windows-server-2003R2.xml b/docs/tmp/en-US/xml_tmp/sysprep-for-windows-server-2003R2.xml
new file mode 100644
index 00000000000..86e1667a1c5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/sysprep-for-windows-server-2003R2.xml
@@ -0,0 +1,57 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Sysprep for Windows Server 2003 R2
+ Earlier versions of Windows have a different sysprep tool. Follow these steps for Windows Server 2003 R2.
+
+ Extract the content of \support\tools\deploy.cab on the Windows installation CD into a directory called c:\sysprep on the Windows 2003 R2 VM.
+ Run c:\sysprep\setupmgr.exe to create the sysprep.inf file.
+
+ Select Create New to create a new Answer File.
+ Enter “Sysprep setup” for the Type of Setup.
+ Select the appropriate OS version and edition.
+ On the License Agreement screen, select “Yes fully automate the installation”.
+ Provide your name and organization.
+ Leave display settings at default.
+ Set the appropriate time zone.
+ Provide your product key.
+ Select an appropriate license mode for your deployment
+ Select “Automatically generate computer name”.
+ Type a default administrator password. If you enable the password reset feature, the users will not actually use this password. This password will be reset by the instance manager after the guest boots up.
+ Leave Network Components at “Typical Settings”.
+ Select the “WORKGROUP” option.
+ Leave Telephony options at default.
+ Select appropriate Regional Settings.
+ Select appropriate language settings.
+ Do not install printers.
+ Do not specify “Run Once commands”.
+ You need not specify an identification string.
+ Save the Answer File as c:\sysprep\sysprep.inf.
+
+
+ Run the following command to sysprep the image:c:\sysprep\sysprep.exe -reseal -mini -activated
+ After this step the machine will automatically shut down
+
+
diff --git a/docs/tmp/en-US/xml_tmp/sysprep-windows-server-2008R2.xml b/docs/tmp/en-US/xml_tmp/sysprep-windows-server-2008R2.xml
new file mode 100644
index 00000000000..af36d15a2c1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/sysprep-windows-server-2008R2.xml
@@ -0,0 +1,67 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ System Preparation for Windows Server 2008 R2
+ For Windows 2008 R2, you run Windows System Image Manager to create a custom sysprep response XML file. Windows System Image Manager is installed as part of the Windows Automated Installation Kit (AIK). Windows AIK can be downloaded from the Microsoft Download Center at the following location:
+ Microsoft Download Center.
+ Use the following steps to run sysprep for Windows 2008 R2:The steps outlined here are derived from the excellent guide by Charity Shelbourne, originally published at Windows Server 2008 Sysprep Mini-Setup
+
+ Download and install the Windows AIKWindows AIK should not be installed on the Windows 2008 R2 VM you just created. Windows AIK should not be part of the template you create. It is only used to create the sysprep answer file.
+ Copy the install.wim file in the \sources directory of the Windows 2008 R2 installation DVD to the hard disk. This is a very large file and may take a long time to copy. Windows AIK requires the WIM file to be writable.
+ Start the Windows System Image Manager, which is part of the Windows AIK.
+ In the Windows Image pane, right click “Select a Windows image or catalog file” to load the install.wim file you just copied.
+ Select the Windows 2008 R2 EditionYou may be prompted with a warning that the catalog file cannot be opened. Click Yes to create a new catalog file.
+ In the Answer File pane, right click to create a new answer file.
+ Generate the answer file from the Windows System Image Manager using the following steps:
+
+ The first page you need to automate is the Language and Country or Region Selection page. To automate this, expand Components in your Windows Image pane, right-click and add the Microsoft-Windows-International-Core setting to Pass 7 oobeSystem. In your Answer File pane, configure the InputLocale, SystemLocale, UILanguage, and UserLocale with the appropriate settings for your language and country or region. Should you have a question about any of these settings, you can right-click on the specific setting and select Help. This will open the appropriate CHM help file with more information, including examples on the setting you are attempting to configure.
+
+
+
+
+ sysmanager.png: System Image Manager
+
+ You need to automate the Software License Terms Selection page, otherwise known as the End-User License Agreement (EULA). To do this, expand the Microsoft-Windows-Shell-Setup component. High-light the OOBE setting, and add the setting to the Pass 7 oobeSystem. In Settings, set HideEULAPage true.
+
+
+
+ software-license.png: Depicts hiding the EULA page.
+
+ Make sure the license key is properly set. If you use MAK key, you can just enter the MAK key on the Windows 2008 R2 VM. You need not input the MAK into the Windows System Image Manager. If you use KMS host for activation you need not enter the Product Key. Details of Windows Volume Activation can be found at
+ You need to automate is the Change Administrator Password page. Expand the Microsoft-Windows-Shell-Setup component (if it is not still expanded), expand UserAccounts, right-click on AdministratorPassword, and add the setting to the Pass 7 oobeSystem configuration pass of your answer file. Under Settings, specify a password next to Value.
+
+
+
+
+ change-admin-password.png: Depicts changing the administrator password
+ You may read the AIK documentation and set many more options that suit your deployment. The steps above are the minimum needed to make Windows unattended setup work.
+ Save the answer file as unattend.xml. You can ignore the warning messages that appear in the validation window.
+ Copy the unattend.xml file into the c:\windows\system32\sysprep directory of the Windows 2008 R2 Virtual Machine
+ Once you place the unattend.xml file in c:\windows\system32\sysprep directory, you run the sysprep tool as follows:
+ cd c:\Windows\System32\sysprep
+sysprep.exe /oobe /generalize /shutdown
+The Windows 2008 R2 VM will automatically shut down after sysprep is complete.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/system-reserved-ip-addresses.xml b/docs/tmp/en-US/xml_tmp/system-reserved-ip-addresses.xml
new file mode 100644
index 00000000000..1270378d38c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/system-reserved-ip-addresses.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ System Reserved IP Addresses
+ In each zone, you need to configure a range of reserved IP addresses for the management network. This network carries communication between the &PRODUCT; Management Server and various system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
+ The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in one zone which has the same private IP address as a host in another zone.
+ The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the CIDR of the pod that they are created in.
+ Make sure computing servers and Management Servers use IP addresses outside of the System Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and ends at 192.168.154.7. &PRODUCT; can use .2 to .7 for System VMs. This leaves the rest of the pod CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
+ In all zones:
+ Provide private IPs for the system in each pod and provision them in &PRODUCT;.
+ For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.
+ In a zone that uses advanced networking:
+ For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required &PRODUCT; System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.
+ When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
+ To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:
+
+ Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than 4,000 IP addresses.
+ Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod has 255 IPs, this will provide 2,550 IP addresses.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/system-service-offerings.xml b/docs/tmp/en-US/xml_tmp/system-service-offerings.xml
new file mode 100644
index 00000000000..c41aa2e293b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/system-service-offerings.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ System Service Offerings
+ System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just as other service offerings do. But rather than being used for virtual machine instances and exposed to users, system service offerings are used to change the default properties of virtual routers, console proxies, and other system VMs. System service offerings are visible only to the &PRODUCT; root administrator. &PRODUCT; provides default system service offerings. The &PRODUCT; root administrator can create additional custom system service offerings.
+ When &PRODUCT; creates a virtual router for a guest network, it uses default settings which are defined in the system service offering associated with the network offering. You can upgrade the capabilities of the virtual router by applying a new network offering that contains a different system service offering. All virtual routers in that network will begin using the settings from the new service offering.
+
diff --git a/docs/tmp/en-US/xml_tmp/system-vm-template.xml b/docs/tmp/en-US/xml_tmp/system-vm-template.xml
new file mode 100644
index 00000000000..a9477f3a61d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/system-vm-template.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ The System VM Template
+ The System VMs come from a single template. The System VM has the following characteristics:
+
+ Debian 6.0 ("Squeeze"), 2.6.32 kernel with the latest security patches from the Debian security APT repository
+ Has a minimal set of packages installed thereby reducing the attack surface
+ 32-bit for enhanced performance on Xen/VMWare
+ pvops kernel with Xen PV drivers, KVM virtio drivers, and VMware tools for optimum performance on all hypervisors
+ Xen tools inclusion allows performance monitoring
+ Latest versions of HAProxy, iptables, IPsec, and Apache from debian repository ensures improved security and speed
+ Latest version of JRE from Sun/Oracle ensures improved security and speed
+
+
diff --git a/docs/tmp/en-US/xml_tmp/tagging-resources.xml b/docs/tmp/en-US/xml_tmp/tagging-resources.xml
new file mode 100644
index 00000000000..31ee3825e4a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/tagging-resources.xml
@@ -0,0 +1,69 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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
+ &PRODUCT; 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:
+ 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
+
+
diff --git a/docs/tmp/en-US/xml_tmp/template-iso-snapshot-usage-record-format.xml b/docs/tmp/en-US/xml_tmp/template-iso-snapshot-usage-record-format.xml
new file mode 100644
index 00000000000..3f34f362d70
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/template-iso-snapshot-usage-record-format.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Template, ISO, and Snapshot Usage Record Format
+
+ account – name of the account
+ accountid – ID of the account
+ domainid – ID of the domain in which this account resides
+ zoneid – Zone where the usage occurred
+ description – A string describing what the usage record is tracking
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
+ usagetype – A number representing the usage type (see Usage Types)
+ rawusage – A number representing the actual usage in hours
+ usageid – The ID of the the template, ISO, or snapshot
+ offeringid – The ID of the disk offering
+ templateid – – Included only for templates (usage type 7). Source template ID.
+ size – Size of the template, ISO, or snapshot
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
diff --git a/docs/tmp/en-US/xml_tmp/templates.xml b/docs/tmp/en-US/xml_tmp/templates.xml
new file mode 100644
index 00000000000..faecf1b76dc
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/templates.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Templates
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/time-zones.xml b/docs/tmp/en-US/xml_tmp/time-zones.xml
new file mode 100644
index 00000000000..aa8eefb7c59
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/time-zones.xml
@@ -0,0 +1,137 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Time Zones
+ The following time zone identifiers are accepted by &PRODUCT;. 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
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/topology-req.xml b/docs/tmp/en-US/xml_tmp/topology-req.xml
new file mode 100644
index 00000000000..65c9c2ea5c6
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/topology-req.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Topology Requirements
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/trial-installation.xml b/docs/tmp/en-US/xml_tmp/trial-installation.xml
new file mode 100644
index 00000000000..8270e579b17
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/trial-installation.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Trial Installation
+ Coming soon.
+
diff --git a/docs/tmp/en-US/xml_tmp/troubleshooting-alerts.xml b/docs/tmp/en-US/xml_tmp/troubleshooting-alerts.xml
new file mode 100644
index 00000000000..0efeb81dd1e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/troubleshooting-alerts.xml
@@ -0,0 +1,57 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Alerts
+ The following is the list of alert type numbers.
+
+MEMORY = 0
+CPU = 1
+STORAGE =2
+STORAGE_ALLOCATED = 3
+PUBLIC_IP = 4
+PRIVATE_IP = 5
+HOST = 6
+USERVM = 7
+DOMAIN_ROUTER = 8
+CONSOLE_PROXY = 9
+ROUTING = 10// lost connection to default route (to the gateway)
+STORAGE_MISC = 11 // lost connection to default route (to the gateway)
+USAGE_SERVER = 12 // lost connection to default route (to the gateway)
+MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)
+DOMAIN_ROUTER_MIGRATE = 14
+CONSOLE_PROXY_MIGRATE = 15
+USERVM_MIGRATE = 16
+VLAN = 17
+SSVM = 18
+USAGE_SERVER_RESULT = 19
+STORAGE_DELETE = 20;
+UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource count
+USAGE_SANITY_RESULT = 22;
+DIRECT_ATTACHED_PUBLIC_IP = 23;
+LOCAL_STORAGE = 24;
+RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/troubleshooting-dataloss-on-exported-primary-storage.xml b/docs/tmp/en-US/xml_tmp/troubleshooting-dataloss-on-exported-primary-storage.xml
new file mode 100644
index 00000000000..4a94f60fbd3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/troubleshooting-dataloss-on-exported-primary-storage.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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:
+
+ echo “/export 192.168.1.0/24(rw,async,no_root_squash)” > /etc/exports
+ Adjust the above command to suit your deployment needs.
+
+ More Information
+ See the export procedure in the "Secondary Storage" section of the &PRODUCT; Installation Guide
+
+
diff --git a/docs/tmp/en-US/xml_tmp/troubleshooting-lb-rules-fails.xml b/docs/tmp/en-US/xml_tmp/troubleshooting-lb-rules-fails.xml
new file mode 100644
index 00000000000..c507178e831
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/troubleshooting-lb-rules-fails.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 CloudPlatform 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.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/troubleshooting-maintenance-mode-not-working-on-vCenter.xml b/docs/tmp/en-US/xml_tmp/troubleshooting-maintenance-mode-not-working-on-vCenter.xml
new file mode 100644
index 00000000000..c4bf37f6bbe
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/troubleshooting-maintenance-mode-not-working-on-vCenter.xml
@@ -0,0 +1,43 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Maintenance mode not working on vCenter
+
+ Symptom
+ Host was placed in maintenance mode, but still appears live in vCenter.
+
+
+ Cause
+ The CloudPlatform 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
+
+
diff --git a/docs/tmp/en-US/xml_tmp/troubleshooting-recover-lost-virtual-router.xml b/docs/tmp/en-US/xml_tmp/troubleshooting-recover-lost-virtual-router.xml
new file mode 100644
index 00000000000..12a51501379
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/troubleshooting-recover-lost-virtual-router.xml
@@ -0,0 +1,46 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 API Reference.
+
diff --git a/docs/tmp/en-US/xml_tmp/troubleshooting-unable-to-deploy-vms.xml b/docs/tmp/en-US/xml_tmp/troubleshooting-unable-to-deploy-vms.xml
new file mode 100644
index 00000000000..412b9bfc0d8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/troubleshooting-unable-to-deploy-vms.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/troubleshooting-unable-to-power-on-vm.xml b/docs/tmp/en-US/xml_tmp/troubleshooting-unable-to-power-on-vm.xml
new file mode 100644
index 00000000000..e037eda08f1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/troubleshooting-unable-to-power-on-vm.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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
+
diff --git a/docs/tmp/en-US/xml_tmp/troubleshooting-working-with-server-logs.xml b/docs/tmp/en-US/xml_tmp/troubleshooting-working-with-server-logs.xml
new file mode 100644
index 00000000000..1017bf57252
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/troubleshooting-working-with-server-logs.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Working with Server Logs
+ The &PRODUCT; Management Server logs all web site, middle tier, and database activities for diagnostics purposes in /var/log/cloud/management/. The &PRODUCT; logs a variety of error messages. We recommend this command to find the problematic output in the Management Server log:.
+ 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.
+
+ grep -i -E 'exception|unable|fail|invalid|leak|warn|error' /var/log/cloud/management/management-server.log
+
+ The &PRODUCT; 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:
+
+ 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:
+
+ grep "job-1076)" management-server.log
+
+ The &PRODUCT; Agent Server logs its activities in /var/log/cloud/agent/.
+
diff --git a/docs/tmp/en-US/xml_tmp/troubleshooting.xml b/docs/tmp/en-US/xml_tmp/troubleshooting.xml
new file mode 100644
index 00000000000..dd736fe18e0
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/troubleshooting.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Troubleshooting
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/tuning.xml b/docs/tmp/en-US/xml_tmp/tuning.xml
new file mode 100644
index 00000000000..18d83ee40bc
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/tuning.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Tuning
+ This section provides tips on how to improve the performance of your cloud.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/ui.xml b/docs/tmp/en-US/xml_tmp/ui.xml
new file mode 100644
index 00000000000..94ea4eaf95c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/ui.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ User Interface
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/upgrade-virtual-router-with-service-offering.xml b/docs/tmp/en-US/xml_tmp/upgrade-virtual-router-with-service-offering.xml
new file mode 100644
index 00000000000..8291c3af46c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/upgrade-virtual-router-with-service-offering.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Upgrading a Virtual Router with System Service Offerings
+ When &PRODUCT; creates a virtual router, it uses default settings which are defined in a default system service offering. See . All the virtual routers in a single guest network use the same system service offering. You can upgrade the capabilities of the virtual router by creating and applying a custom system service offering.
+
+ Define your custom system service offering. See . In System VM Type, choose Domain Router.
+ Associate the system service offering with a network offering. See
+ Apply the network offering to the network where you want the virtual routers to use the new system service offering. If this is a new network, follow the steps in Adding an Additional Guest Network on page 66. To change the service offering for existing virtual routers, follow the steps in .
+
+
diff --git a/docs/tmp/en-US/xml_tmp/upload-existing-volume-to-vm.xml b/docs/tmp/en-US/xml_tmp/upload-existing-volume-to-vm.xml
new file mode 100644
index 00000000000..86dc8e54758
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/upload-existing-volume-to-vm.xml
@@ -0,0 +1,76 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Uploading an Existing Volume to a Virtual Machine
+ Existing data can be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs.
+ The upload is performed using HTTP. The uploaded volume is placed in the zone's secondary storage
+ You cannot upload a volume if the preconfigured volume limit has already been reached. The default limit for the cloud is set in the global configuration parameter max.account.volumes, but administrators can also set per-domain limits that are different from the global default. See Setting Usage Limits
+ To upload a volume:
+
+ (Optional) Create an MD5 hash (checksum) of the disk image file that you are going to upload. After uploading the data disk, &PRODUCT; will use this value to verify that no data corruption has occurred.
+ Log in to the &PRODUCT; UI as an administrator or user
+ In the left navigation bar, click Storage.
+ Click Upload Volume.
+ Provide the following:
+
+ Name and Description. Any desired name and a brief description that can be shown in the UI.
+ Availability Zone. Choose the zone where you want to store the volume. VMs running on hosts in this zone can attach the volume.
+ Format. Choose one of the following to indicate the disk image format of the volume.
+
+
+
+
+ Hypervisor
+ Disk Image Format
+
+
+
+
+ XenServer
+ VHD
+
+
+ VMware
+ OVA
+
+
+ KVM
+ QCOW2
+
+
+
+
+
+ URL. The secure HTTP or HTTPS URL that &PRODUCT; can use to access your disk. The type of file at the URL must match the value chosen in Format. For example, if Format is VHD, the URL might look like the following:
+ http://yourFileServerIP/userdata/myDataDisk.vhd
+ MD5 checksum. (Optional) Use the hash that you created in step 1.
+
+
+ Wait until the status of the volume shows that the upload is complete. Click Instances - Volumes, find the name you specified in step 5, and make sure the status is Uploaded.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/upload-template.xml b/docs/tmp/en-US/xml_tmp/upload-template.xml
new file mode 100644
index 00000000000..40b64bbe8aa
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/upload-template.xml
@@ -0,0 +1,53 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Uploading Templates
+ vSphere Templates and ISOsIf you are uploading a template that was created using vSphere Client, be sure the OVA file does not contain an ISO. If it does, the deployment of VMs from the template will fail.
+ Templates are uploaded based on a URL. HTTP is the supported access protocol. Templates are frequently large files. You can optionally gzip them to decrease upload times.
+ To upload a template:
+
+ In the left navigation bar, click Templates.
+ Click Create Template.
+ Provide the following:
+
+ Name and Display Text. These will be shown in the UI, so choose something descriptive.
+ URL. The Management Server will download the file from the specified URL, such as http://my.web.server/filename.vhd.gz.
+ Zone. Choose the zone where you want the template to be available, or All Zones to make it available throughout &PRODUCT;.
+ OS Type: This helps &PRODUCT; and the hypervisor perform certain operations and make assumptions that improve the performance of the guest. Select one of the following:
+
+ If the operating system of the stopped VM is listed, choose it.
+ If the OS type of the stopped VM is not listed, choose Other.
+ You should not choose an older version of the OS than the version in the image. For example, choosing CentOS 5.4 to support a CentOS 6.2 image will in general not work. In those cases you should choose Other.
+
+
+ Hypervisor
+ Format. The format of the template upload file, such as VHD or OVA.
+ Password Enabled. Choose Yes if your template has the &PRODUCT; password change script installed. See Adding Password Management to Your Templates
+ Extractable. Choose Yes if the template is available for extraction. If this option is selected, end users can download a full image of a template.
+ Public. Choose Yes to make this template accessible to all users of this &PRODUCT; installation. The template will appear in the Community Templates list. See
+ Featured. Choose Yes if you would like this template to be more prominent for users to select. The template will appear in the Featured Templates list. Only an administrator can make a template Featured.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/usage-record-format.xml b/docs/tmp/en-US/xml_tmp/usage-record-format.xml
new file mode 100644
index 00000000000..d40bd63a91e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/usage-record-format.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Usage Record Format
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/usage-types.xml b/docs/tmp/en-US/xml_tmp/usage-types.xml
new file mode 100644
index 00000000000..5a189028ad2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/usage-types.xml
@@ -0,0 +1,109 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Usage Types
+ The following table shows all usage types.
+
+
+
+
+
+
+
+ Type ID
+ Type Name
+ Description
+
+
+
+
+ 1
+ RUNNING_VM
+ Tracks the total running time of a VM per usage record period. If the VM is upgraded during the usage period, you will get a separate Usage Record for the new upgraded VM.
+
+
+ 2
+ ALLOCATED_VM
+ Tracks the total time the VM has been created to the time when it has been destroyed. This usage type is also useful in determining usage for specific templates such as Windows-based templates.
+
+
+ 3
+ IP_ADDRESS
+ Tracks the public IP address owned by the account.
+
+
+ 4
+ NETWORK_BYTES_SENT
+ Tracks the total number of bytes sent by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+ 5
+ NETWORK_BYTES_RECEIVED
+ Tracks the total number of bytes received by all the VMs for an account. Cloud.com does not currently track network traffic per VM.
+
+
+ 6
+ VOLUME
+ Tracks the total time a disk volume has been created to the time when it has been destroyed.
+
+
+ 7
+ TEMPLATE
+ Tracks the total time a template (either created from a snapshot or uploaded to the cloud) has been created to the time it has been destroyed. The size of the template is also returned.
+
+
+ 8
+ ISO
+ Tracks the total time an ISO has been uploaded to the time it has been removed from the cloud. The size of the ISO is also returned.
+
+
+ 9
+ SNAPSHOT
+ Tracks the total time from when a snapshot has been created to the time it have been destroyed.
+
+
+ 11
+ LOAD_BALANCER_POLICY
+ Tracks the total time a load balancer policy has been created to the time it has been removed. Cloud.com does not track whether a VM has been assigned to a policy.
+
+
+ 12
+ PORT_FORWARDING_RULE
+ Tracks the time from when a port forwarding rule was created until the time it was removed.
+
+
+ 13
+ NETWORK_OFFERING
+ The time from when a network offering was assigned to a VM until it is removed.
+
+
+ 14
+ VPN_USERS
+ The time from when a VPN user is created until it is removed.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/use-project-view.xml b/docs/tmp/en-US/xml_tmp/use-project-view.xml
new file mode 100644
index 00000000000..df874d82409
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/use-project-view.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using the Project View
+ If you are a member of a project, you can use &PRODUCT;’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 &PRODUCT; 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.
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/user-data-and-meta-data.xml b/docs/tmp/en-US/xml_tmp/user-data-and-meta-data.xml
new file mode 100644
index 00000000000..3f03449554a
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/user-data-and-meta-data.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ User Data and Meta Data
+ &PRODUCT; provides API access to attach 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.
+ # 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# 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
+
+
diff --git a/docs/tmp/en-US/xml_tmp/user-services-overview.xml b/docs/tmp/en-US/xml_tmp/user-services-overview.xml
new file mode 100644
index 00000000000..12504e6ca4e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/user-services-overview.xml
@@ -0,0 +1,72 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ User Services Overview
+ In addition to the physical and logical infrastructure of your cloud,
+ and the &PRODUCT; software and servers, you also need a layer of user
+ services so that people can actually make use of the cloud. This means
+ not just a user UI, but a set of options and resources that users can
+ choose from, such as templates for creating virtual machines, disk
+ storage, and more. If you are running a commercial service, you will be
+ keeping track of what services and resources users are consuming and
+ charging them for that usage. Even if you do not charge anything for
+ people to use your cloud – say, if the users are strictly internal to your
+ organization, or just friends who are sharing your cloud – you can still
+ keep track of what services they use and how much of them.
+
+
+ Service Offerings, Disk Offerings, Network Offerings, and Templates
+ A user creating a new instance can make a variety of choices about
+ its characteristics and capabilities. &PRODUCT; provides several ways to
+ present users with choices when creating a new instance:
+
+
+ Service Offerings, defined by the &PRODUCT; administrator,
+ provide a choice of CPU speed, number of CPUs, RAM size, tags on the
+ root disk, and other choices. See Creating a New Compute Offering.
+
+ Disk Offerings, defined by the &PRODUCT; administrator,
+ provide a choice of disk size for primary data storage. See Creating a
+ New Disk Offering.
+
+ Network Offerings, defined by the &PRODUCT; administrator,
+ describe the feature set that is available to end users from the virtual
+ router or external networking devices on a given guest network. See
+ Network Offerings.
+
+ Templates, defined by the &PRODUCT; administrator or by
+ any &PRODUCT; user, are the base OS images that the user can choose
+ from when creating a new instance. For example, &PRODUCT; includes
+ CentOS as a template. See Working with Templates.
+
+
+ In addition to these choices that are provided for users, there is
+ another type of service offering which is available only to the &PRODUCT;
+ root administrator, and is used for configuring virtual infrastructure
+ resources. For more information, see Upgrading a Virtual Router with
+ System Service Offerings.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/using-multiple-guest-networks.xml b/docs/tmp/en-US/xml_tmp/using-multiple-guest-networks.xml
new file mode 100644
index 00000000000..9076a816640
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/using-multiple-guest-networks.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using Multiple Guest Networks
+ In zones that use advanced networking, additional networks for guest traffic may be added at any time after the initial installation. You can also customize the domain name associated with the network by specifying a DNS suffix for each network.
+ A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has been created, although the user can go into the guest and remove the IP address from the NIC on a particular network.
+ Each VM has just one default network. The virtual router's DHCP reply will set the guest's default gateway as that for the default network. Multiple non-default networks may be added to a guest in addition to the single, required default network. The administrator can control which networks are available as the default network.
+ Additional networks can either be available to all accounts or be assigned to a specific account. Networks that are available to all accounts are zone-wide. Any user with access to the zone can create a VM with access to that network. These zone-wide networks provide little or no isolation between guests.Networks that are assigned to a specific account provide strong isolation.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/using-netscaler-load-balancers.xml b/docs/tmp/en-US/xml_tmp/using-netscaler-load-balancers.xml
new file mode 100644
index 00000000000..c2044de527b
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/using-netscaler-load-balancers.xml
@@ -0,0 +1,60 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ About Using a NetScaler Load Balancer
+ Citrix NetScaler is supported as an external network element for load balancing in zones that use advanced networking (also called advanced zones). Set up an external load balancer when you want to provide load balancing through means other than &PRODUCT;’s provided virtual router.
+ The NetScaler can be set up in direct (outside the firewall) mode. It must be added before any load balancing rules are deployed on guest VMs in the zone.
+ The functional behavior of the NetScaler with &PRODUCT; is the same as described in the &PRODUCT; documentation for using an F5 external load balancer. The only exception is that the F5 supports routing domains, and NetScaler does not. NetScaler can not yet be used as a firewall.
+ The Citrix NetScaler comes in three varieties. The following table summarizes how these variants are treated in &PRODUCT;.
+
+
+
+
+ NetScaler ADC Type
+ Description of Capabilities
+ &PRODUCT; Supported Features
+
+
+
+
+ MPX
+ Physical appliance. Capable of deep packet inspection. Can act as application firewall and load balancer
+ In advanced zones, load balancer functionality fully supported without limitation. In basic zones, static NAT, elastic IP (EIP), and elastic load balancing (ELB) are also provided
+
+
+
+ VPX
+ Virtual appliance. Can run as VM on XenServer, ESXi, and Hyper-V hypervisors. Same functionality as MPX
+ Supported only on ESXi. Same functional support as for MPX. &PRODUCT; will treat VPX and MPX as the same device type
+
+
+ SDX
+ Physical appliance. Can create multiple fully isolated VPX instances on a single appliance to support multi-tenant usage
+ &PRODUCT; will dynamically provision, configure, and manage the lifecycle of VPX instances on the SDX. Provisioned instances are added into &PRODUCT; automatically – no manual configuration by the administrator is required. Once a VPX instance is added into &PRODUCT;, it is treated the same as a VPX on an ESXi host.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/using-sshkeys.xml b/docs/tmp/en-US/xml_tmp/using-sshkeys.xml
new file mode 100644
index 00000000000..1e98eb699ad
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/using-sshkeys.xml
@@ -0,0 +1,105 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using SSH Keys for Authentication
+ In addition to the username and password authentication, &PRODUCT; 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 Scriptto the instance you have created.
+ 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.
+ cp cloud-set-guest-sshkey.in /etc/init.d/
+
+ Give the necessary permissions on the script:
+ chmod +x /etc/init.d/cloud-set-guest-sshkey.in
+
+ Run the script while starting up the operating system:
+ 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 &PRODUCT; 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:
+ 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:
+ 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:
+ <?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:
+ -----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 . Ensure that you use the same SSH key name that you created at .
+ 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:
+ curl --globoff http://localhost:<port numbet>/?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:
+ ssh -i ~/.ssh/keypair-doc <ip address>
+ The -i parameter tells the ssh client to use a ssh key found at ~/.ssh/keypair-doc.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/using-swift-for-secondary-storage.xml b/docs/tmp/en-US/xml_tmp/using-swift-for-secondary-storage.xml
new file mode 100644
index 00000000000..bf238ca6466
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/using-swift-for-secondary-storage.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using Swift for Secondary Storage
+ CloudPlatform supports OpenStack Object Storage ( Swift) for secondary storage. When using Swift, you configure Swift storage for the entire CloudPlatform, then set up NFS secondary storage for each zone as usual. The NFS storage in each zone acts as a staging area through which all templates and other secondary storage data pass before being forwarded to Swift. The Swift storage acts as a cloud-wide resource, making templates and other data available to any zone in the cloud. There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary storage in the whole cloud can pull a container from Swift at need. It is not necessary to copy templates and snapshots from one zone to another, as would be required when using zone NFS alone. Everything is available everywhere
+ Swift storage must be set up before you add NFS secondary storage to zones. This is accomplished through some additional configuration steps on a fresh Management Server installation, before you add the first zone. The procedure is described in Adding a Zone in the Advanced Installation Guide.
+
diff --git a/docs/tmp/en-US/xml_tmp/using-vpn-with-mac.xml b/docs/tmp/en-US/xml_tmp/using-vpn-with-mac.xml
new file mode 100644
index 00000000000..718ebc777a9
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/using-vpn-with-mac.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using VPN with Mac OS X
+ In Mac OS X, in Network Preferences - Advanced, make sure Send all traffic over VPN connection is not checked.
+
diff --git a/docs/tmp/en-US/xml_tmp/using-vpn-with-windows.xml b/docs/tmp/en-US/xml_tmp/using-vpn-with-windows.xml
new file mode 100644
index 00000000000..e0e15692d35
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/using-vpn-with-windows.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using VPN with Windows
+ The procedure to use VPN varies by Windows version. Generally, the user must edit the VPN properties and make sure that the default route is not the VPN. The following steps are for Windows L2TP clients on Windows Vista. The commands should be similar for other Windows versions.
+
+ Log in to the &PRODUCT; UI and click on the source NAT IP for the account. The VPN tab should display the IPsec preshared key. Make a note of this and the source NAT IP. The UI also lists one or more users and their passwords. Choose one of these users, or, if none exists, add a user and password.
+ On the Windows box, go to Control Panel, then select Network and Sharing center. Click Setup a connection or network.
+ In the next dialog, select No, create a new connection.
+ In the next dialog, select Use my Internet Connection (VPN).
+ In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check Don't connect now.
+ In the next dialog, enter the user name and password selected in step 1.
+ Click Create.
+ Go back to the Control Panel and click Network Connections to see the new connection. The connection is not active yet.
+ Right-click the new connection and select Properties. In the Properties dialog, select the Networking tab.
+ In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key. Enter the preshared key from Step 1.
+ The connection is ready for activation. Go back to Control Panel -> Network Connections and double-click the created connection.
+ Enter the user name and password from Step 1.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/vcenter-maintenance-mode.xml b/docs/tmp/en-US/xml_tmp/vcenter-maintenance-mode.xml
new file mode 100644
index 00000000000..fb896b2b166
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vcenter-maintenance-mode.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ vCenter and Maintenance Mode
+ To enter maintenance mode on a vCenter host, both vCenter and &PRODUCT; must be used in concert. &PRODUCT; and vCenter have separate maintenance modes that work closely together.
+
+ Place the host into &PRODUCT;'s "scheduled maintenance" mode. This does not invoke the vCenter maintenance mode, but only causes VMs to be migrated off the host
+ When the &PRODUCT; 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 &PRODUCT; to reactivate it.
+ Then use &PRODUCT;'s administrator UI to cancel the &PRODUCT; 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.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/verifying-source.xml b/docs/tmp/en-US/xml_tmp/verifying-source.xml
new file mode 100644
index 00000000000..f8bd102379d
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/verifying-source.xml
@@ -0,0 +1,82 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Verifying the downloaded release
+
+ There are a number of mechanisms to check the authenticity and validity of a
+ downloaded release.
+
+
+ Getting the KEYS
+
+ To enable you to verify the GPG signature, you will need to download the
+ KEYS
+ file.
+
+
+ You next need to import those keys, which you can do by running the following command:
+ #gpg --import KEYS
+
+
+
+ GPG
+
+ The &PRODUCT; project provides a detached GPG signature of the release.
+ To check the signature, run the following command:
+ $gpg --verify apache-cloudstack-4.0.0-incubating-src.tar.bz2.asc
+
+
+ If the signature is valid you will see a line of output that contains 'Good signature'.
+
+
+
+ MD5
+
+ In addition to the cryptographic signature, &PRODUCT; has an MD5 checksum
+ that you can use to verify the download matches the release.
+ You can verify this hash by executing the following command:
+ $gpg --print-md MD5 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.md5
+
+
+ If this successfully completes you should see no output. If there is any output from them,
+ then there is a difference between the hash you generated locally and the hash that has been
+ pulled from the server.
+
+
+
+ SHA512
+
+ In addition to the MD5 hash, the &PRODUCT; project provides a SHA512
+ cryptographic hash to aid in assurance of the validity of the downloaded
+ release. You can verify this hash by executing the following command:
+ $gpg --print-md SHA512 apache-cloudstack-4.0.0-incubating-src.tar.bz2 | diff - apache-cloudstack-4.0.0-incubating-src.tar.bz2.sha
+
+
+ If this command successfully completes you should see no output. If there is any output from them,
+ then there is a difference between the hash you generated locally and the hash that has been
+ pulled from the server.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/virtual-machine-usage-record-format.xml b/docs/tmp/en-US/xml_tmp/virtual-machine-usage-record-format.xml
new file mode 100644
index 00000000000..ac8fec9a9d2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/virtual-machine-usage-record-format.xml
@@ -0,0 +1,45 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Virtual Machine Usage Record Format
+ For running and allocated virtual machine usage, the following fields exist in a usage record:
+
+ account – name of the account
+ accountid – ID of the account
+ domainid – ID of the domain in which this account resides
+ zoneid – Zone where the usage occurred
+ description – A string describing what the usage record is tracking
+ usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for VM running time)
+ usagetype – A number representing the usage type (see Usage Types)
+ rawusage – A number representing the actual usage in hours
+ virtualMachineId – The ID of the virtual machine
+ name – The name of the virtual machine
+ offeringid – The ID of the service offering
+ templateid – The ID of the template or the ID of the parent template. The parent template value is present when the current template was created from a volume.
+ usageid – Virtual machine
+ type – Hypervisor
+ startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage Record
+
+
diff --git a/docs/tmp/en-US/xml_tmp/virtual-machines.xml b/docs/tmp/en-US/xml_tmp/virtual-machines.xml
new file mode 100644
index 00000000000..7c74932b649
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/virtual-machines.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ Working With Virtual Machines
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/virtual-router.xml b/docs/tmp/en-US/xml_tmp/virtual-router.xml
new file mode 100644
index 00000000000..775d4740a91
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/virtual-router.xml
@@ -0,0 +1,29 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Virtual Router
+ The virtual router is a type of System Virtual Machine. The virtual router is one of the most frequently used service providers in &PRODUCT;. The end user has no direct access to the virtual router. Users can ping the virtual router and take actions that affect it (such as setting up port forwarding), but users do not have SSH access into the virtual router.
+ There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be restarted by administrators, but this will interrupt public network access and other services for end users. A basic test in debugging networking issues is to attempt to ping the virtual router from a guest VM. Some of the characteristics of the virtual router are determined by its associated system service offering.
+
diff --git a/docs/tmp/en-US/xml_tmp/vlan-allocation-eg.xml b/docs/tmp/en-US/xml_tmp/vlan-allocation-eg.xml
new file mode 100644
index 00000000000..3ffd1666730
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vlan-allocation-eg.xml
@@ -0,0 +1,71 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ 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.
+ &PRODUCT; software can access this, hypervisors, system VMs.
+
+
+ 500-599
+ VLAN carrying public traffic.
+ &PRODUCT; accounts.
+
+
+ 600-799
+ VLANs carrying guest traffic.
+ &PRODUCT; accounts. Account-specific VLAN is chosen from this
+ pool.
+
+
+ 800-899
+ VLANs carrying guest traffic.
+ &PRODUCT; accounts. Account-specific VLAN chosen by &PRODUCT; admin to assign
+ to that account.
+
+
+ 900-999
+ VLAN carrying guest traffic
+ &PRODUCT; accounts. Can be scoped by project, domain, or all
+ accounts.
+
+
+ greater than 1000
+ Reserved for future use
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/vlan-provisioning.xml b/docs/tmp/en-US/xml_tmp/vlan-provisioning.xml
new file mode 100644
index 00000000000..8abd5da0a75
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vlan-provisioning.xml
@@ -0,0 +1,30 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ VLAN Provisioning
+ &PRODUCT; automatically creates and destroys interfaces bridged to VLANs on the hosts. In general the administrator does not need to manage this process.
+ &PRODUCT; 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/vm-lifecycle.xml b/docs/tmp/en-US/xml_tmp/vm-lifecycle.xml
new file mode 100644
index 00000000000..f5696ced12c
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vm-lifecycle.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ VM Lifecycle
+ Virtual machines can be in the following states:
+
+
+
+
+ basic-deployment.png: Basic two-machine CloudStack deployment
+
+ Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual machine will be reclaimed by the system. This includes the virtual machine’s IP address.
+ A stop will attempt to gracefully shut down the operating system, which typically involves terminating all the running applications. If the operation system cannot be stopped, it will be forcefully terminated. This has the same effect as pulling the power cord to a physical machine.
+ A reboot is a stop followed by a start.
+ CloudPlatform preserves the state of the virtual machine hard disk until the machine is destroyed.
+ A running virtual machine may fail because of hardware or network issues. A failed virtual machine is in the down state.
+ The system places the virtual machine into the down state if it does not receive the heartbeat from the hypervisor for three minutes.
+ The user can manually restart the virtual machine from the down state.
+ The system will start the virtual machine from the down state automatically if the virtual machine is marked as HA-enabled.
+
diff --git a/docs/tmp/en-US/xml_tmp/vm-storage-migration.xml b/docs/tmp/en-US/xml_tmp/vm-storage-migration.xml
new file mode 100644
index 00000000000..4b09ffdb220
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vm-storage-migration.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ VM Storage Migration
+ Supported in XenServer, KVM, and VMware.
+ This procedure is different from moving disk volumes from one VM to another. See Detaching and Moving Volumes .
+ You can migrate a virtual machine’s root disk volume or any additional data disk volume from one storage pool to another in the same zone.
+ You can use the storage migration feature to achieve some commonly desired administration goals, such as balancing the load on storage pools and increasing the reliability of virtual machines by moving them away from any storage pool that is experiencing issues.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/vmware-install.xml b/docs/tmp/en-US/xml_tmp/vmware-install.xml
new file mode 100644
index 00000000000..736b122fd0f
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vmware-install.xml
@@ -0,0 +1,631 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ VMware vSphere Installation and Configuration
+ If you want to use the VMware vSphere hypervisor to run guest virtual machines, install vSphere on the host(s) in your cloud.
+
+
+ Preparation Checklist for VMware
+ For a smoother installation, gather the following information before you start:
+
+ Information listed in
+ Information listed in
+
+
+ vCenter Checklist
+ You will need the following information about vCenter.
+
+
+
+
+
+
+
+ vCenter Requirement
+ Value
+ Notes
+
+
+
+
+ vCenter User
+
+ This user must have admin privileges.
+
+
+ vCenter User Password
+
+ Password for the above user.
+
+
+ vCenter Datacenter Name
+
+ Name of the datacenter.
+
+
+ vCenter Cluster Name
+
+ Name of the cluster.
+
+
+
+
+
+
+ Networking Checklist for VMware
+ You will need the following information about VLAN.
+
+
+
+
+
+
+
+ VLAN Information
+ Value
+ Notes
+
+
+
+
+ ESXi VLAN
+
+ VLAN on which all your ESXi hypervisors reside.
+
+
+ ESXI VLAN IP Address
+
+ IP Address Range in the ESXi VLAN. One address per Virtual Router is used from this range.
+
+
+ ESXi VLAN IP Gateway
+
+
+
+
+ ESXi VLAN Netmask
+
+
+
+
+ Management Server VLAN
+
+ VLAN on which the &PRODUCT; Management server is installed.
+
+
+ Public VLAN
+
+ VLAN for the Public Network.
+
+
+ Public VLAN Gateway
+
+
+
+
+ Public VLAN Netmask
+
+
+
+
+ Public VLAN IP Address Range
+
+ Range of Public IP Addresses available for &PRODUCT; use. These addresses will be used for virtual router on &PRODUCT; to route private traffic to external networks.
+
+
+ VLAN Range for Customer use
+
+ A contiguous range of non-routable VLANs. One VLAN will be assigned for each customer.
+
+
+
+
+
+
+
+ vSphere Installation Steps
+
+ If you haven't already, you'll need to download and purchase vSphere from the VMware Website (https://www.vmware.com/tryvmware/index.php?p=vmware-vsphere&lp=1) and install it by following the VMware vSphere Installation Guide.
+
+ Following installation, perform the following configuration, which are described in the next few sections:
+
+
+
+
+
+
+ Required
+ Optional
+
+
+
+
+ ESXi host setup
+ NIC bonding
+
+
+ Configure host physical networking, virtual switch, vCenter Management Network, and extended port range
+ Multipath storage
+
+
+ Prepare storage for iSCSI
+
+
+
+ Configure clusters in vCenter and add hosts to them, or add hosts without clusters to vCenter
+
+
+
+
+
+
+
+
+
+ ESXi Host setup
+ All ESXi hosts should enable CPU hardware virtualization support in BIOS. Please note hardware virtualization support is not enabled by default on most servers.
+
+
+ Physical Host Networking
+ You should have a plan for cabling the vSphere hosts. Proper network configuration is required before adding a vSphere host to &PRODUCT;. To configure an ESXi host, you can use vClient to add it as standalone host to vCenter first. Once you see the host appearing in the vCenter inventory tree, click the host node in the inventory tree, and navigate to the Configuration tab.
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+ In the host configuration tab, click the "Hardware/Networking" link to bring up the networking configuration page as above.
+
+ Configure Virtual Switch
+ A default virtual switch vSwitch0 is created. &PRODUCT; requires all ESXi hosts in the cloud to use the same set of virtual switch names. If you change the default virtual switch name, you will need to configure one or more &PRODUCT; configuration variables as well.
+
+ Separating Traffic
+ &PRODUCT; allows you to use vCenter to configure three separate networks per ESXi host. These networks are identified by the name of the vSwitch they are connected to. The allowed networks for configuration are public (for traffic to/from the public internet), guest (for guest-guest traffic), and private (for management and usually storage traffic). You can use the default virtual switch for all three, or create one or two other vSwitches for those traffic types.
+ If you want to separate traffic in this way you should first create and configure vSwitches in vCenter according to the vCenter instructions. Take note of the vSwitch names you have used for each traffic type. You will configure &PRODUCT; to use these vSwitches.
+
+
+ Increasing Ports
+ By default a virtual switch on ESXi hosts is created with 56 ports. We recommend setting it to 4088, the maximum number of ports allowed. To do that, click the "Properties..." link for virtual switch (note this is not the Properties link for Networking).
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+ In vSwitch properties dialog, select the vSwitch and click Edit. You should see the following dialog:
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+ In this dialog, you can change the number of switch ports. After you've done that, ESXi hosts are required to reboot in order for the setting to take effect.
+
+
+
+ Configure vCenter Management Network
+ In the vSwitch properties dialog box, you may see a vCenter management network. This same network will also be used as the &PRODUCT; management network. &PRODUCT; requires the vCenter management network to be configured properly. Select the management network item in the dialog, then click Edit.
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+ Make sure the following values are set:
+
+ VLAN ID set to the desired ID
+ vMotion enabled.
+ Management traffic enabled.
+
+ If the ESXi hosts have multiple VMKernel ports, and ESXi is not using the default value "Management Network" as the management network name, you must follow these guidelines to configure the management network port group so that &PRODUCT; can find it:
+
+ Use one label for the management network port across all ESXi hosts.
+ In the &PRODUCT; UI, go to Configuration - Global Settings and set vmware.management.portgroup to the management network label from the ESXi hosts.
+
+
+
+ Extend Port Range for &PRODUCT; Console Proxy
+ (Applies only to VMware vSphere version 4.x)
+ You need to extend the range of firewall ports that the console proxy works with on the hosts. This is to enable the console proxy to work with VMware-based VMs. The default additional port range is 59000-60000. To extend the port range, log in to the VMware ESX service console on each host and run the following commands:
+
+esxcfg-firewall -o 59000-60000,tcp,in,vncextras
+esxcfg-firewall -o 59000-60000,tcp,out,vncextras
+
+
+
+ Configure NIC Bonding for vSphere
+ NIC bonding on vSphere hosts may be done according to the vSphere installation guide.
+
+
+
+
+ Storage Preparation for vSphere (iSCSI only)
+ Use of iSCSI requires preparatory work in vCenter. You must add an iSCSI target and create an iSCSI datastore.
+ If you are using NFS, skip this section.
+
+ Enable iSCSI initiator for ESXi hosts
+
+
+ In vCenter, go to hosts and Clusters/Configuration, and click Storage Adapters link. You will see:
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+ Select iSCSI software adapter and click Properties.
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+ Click the Configure... button.
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+ Check Enabled to enable the initiator.
+ Click OK to save.
+
+
+
+ Add iSCSI target
+ Under the properties dialog, add the iSCSI target info:
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+ Repeat these steps for all ESXi hosts in the cluster.
+
+
+ Create an iSCSI datastore
+ You should now create a VMFS datastore. Follow these steps to do so:
+
+ Select Home/Inventory/Datastores.
+ Right click on the datacenter node.
+ Choose Add Datastore... command.
+ Follow the wizard to create a iSCSI datastore.
+
+ This procedure should be done on one host in the cluster. It is not necessary to do this on all hosts.
+
+
+
+
+
+ vsphereclient.png: vSphere client
+
+
+
+
+ Multipathing for vSphere (Optional)
+ Storage multipathing on vSphere nodes may be done according to the vSphere installation guide.
+
+
+
+ Add Hosts or Configure Clusters (vSphere)
+ Use vCenter to create a vCenter cluster and add your desired hosts to the cluster. You will later add the entire cluster to &PRODUCT;. (see ).
+
+
diff --git a/docs/tmp/en-US/xml_tmp/vmware-requirements.xml b/docs/tmp/en-US/xml_tmp/vmware-requirements.xml
new file mode 100644
index 00000000000..207a4566de8
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vmware-requirements.xml
@@ -0,0 +1,80 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ System Requirements for vSphere Hosts
+
+ Software requirements:
+
+
+ vSphere and vCenter, both version 4.1 or 5.0.
+ vSphere Standard is recommended. Note however that customers need to consider the CPU constraints in place with vSphere licensing. See http://www.vmware.com/files/pdf/vsphere_pricing.pdf and discuss with your VMware sales representative.
+ vCenter Server Standard is recommended.
+
+ 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. &PRODUCT; 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.
+
+ Apply All Necessary HotfixesThe lack of up-do-date hotfixes can lead to data corruption and lost VMs.
+
+
+ Hardware requirements:
+
+ The host must be certified as compatible with vSphere. See the VMware Hardware Compatibility Guide at http://www.vmware.com/resources/compatibility/search.php.
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled).
+ All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+ 64-bit x86 CPU (more cores results in better performance)
+ Hardware virtualization support required
+ 4 GB of memory
+ 36 GB of local disk
+ At least 1 NIC
+ Statically allocated IP Address
+
+
+
+ vCenter Server requirements:
+
+ Processor - 2 CPUs 2.0GHz or higher Intel or AMD x86 processors. Processor requirements may be higher if the database runs on the same machine.
+ Memory - 3GB RAM. RAM requirements may be higher if your database runs on the same machine.
+ Disk storage - 2GB. Disk requirements may be higher if your database runs on the same machine.
+ Microsoft SQL Server 2005 Express disk requirements. The bundled database requires up to 2GB free disk space to decompress the installation archive.
+ Networking - 1Gbit or 10Gbit.
+
+ For more information, see "vCenter Server and the vSphere Client Hardware Requirements" at http://pubs.vmware.com/vsp40/wwhelp/wwhimpl/js/html/wwhelp.htm#href=install/c_vc_hw.html.
+
+
+ Other requirements:
+
+ VMware vCenter Standard Edition 4.1 or 5.0 must be installed and available to manage the vSphere hosts.
+ vCenter must be configured to use the standard port 443 so that it can communicate with the &PRODUCT; Management Server.
+ You must re-install VMware ESXi if you are going to re-use a host from a previous install.
+ &PRODUCT; requires VMware vSphere 4.1 or 5.0. VMware vSphere 4.0 is not supported.
+ All hosts must be 64-bit and must support HVM (Intel-VT or AMD-V enabled). All hosts within a cluster must be homogenous. That means the CPUs must be of the same type, count, and feature flags.
+ The &PRODUCT; management network must not be configured as a separate virtual network. The &PRODUCT; management network is the same as the vCenter management network, and will inherit its configuration. See .
+ &PRODUCT; requires ESXi. ESX is not supported.
+ All resources used for &PRODUCT; must be used for &PRODUCT; only. &PRODUCT; cannot share instance of ESXi or storage with other management consoles. Do not share the same storage volumes that will be used by &PRODUCT; with a different set of ESXi servers that are not managed by &PRODUCT;.
+ Put all target ESXi hypervisors in a cluster in a separate Datacenter in vCenter.
+ The cluster that will be managed by &PRODUCT; should not contain any VMs. Do not run the management server, vCenter or any other VMs on the cluster that is designated for &PRODUCT; use. Create a separate cluster for use of &PRODUCT; and make sure that they are no VMs in this cluster.
+ All the required VLANS must be trunked into all network switches that are connected to the ESXi hypervisor hosts. These would include the VLANS for Management, Storage, vMotion, and guest VLANs. The guest VLAN (used in Advanced Networking; see Network Setup) is a contiguous range of VLANs that will be managed by &PRODUCT;.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/vmware-topology-req.xml b/docs/tmp/en-US/xml_tmp/vmware-topology-req.xml
new file mode 100644
index 00000000000..cf6ae4d455e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vmware-topology-req.xml
@@ -0,0 +1,38 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ VMware Topology Requirements
+
+
+ The Management Server and secondary storage VMs must be able to access vCenter and all
+ ESXi hosts in the zone. To allow the necessary access through the firewall, keep port 443
+ open.
+
+
+ The Management Servers communicate with VMware vCenter servers on port 443
+ (HTTPs).
+
+
+ The Management Servers communicate with the System VMs on port 3922 (ssh) on the
+ management traffic network.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/volume-deletion-garbage-collection.xml b/docs/tmp/en-US/xml_tmp/volume-deletion-garbage-collection.xml
new file mode 100644
index 00000000000..d162d848cc3
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/volume-deletion-garbage-collection.xml
@@ -0,0 +1,35 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Volume Deletion and Garbage Collection
+ The deletion of a volume does not delete the snapshots that have been created from the volume
+ When a VM is destroyed, data disk volumes that are attached to the VM are not deleted.
+ Volumes are permanently destroyed using a garbage collection process. The global configuration variables expunge.delay and expunge.interval determine when the physical deletion of volumes will occur.
+
+ expunge.delay: determines how old the volume must be before it is destroyed, in seconds
+ expunge.interval: determines how often to run the garbage collection check
+
+ Administrators should adjust these values depending on site policies around data retention.
+
diff --git a/docs/tmp/en-US/xml_tmp/volume-status.xml b/docs/tmp/en-US/xml_tmp/volume-status.xml
new file mode 100644
index 00000000000..35802f98253
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/volume-status.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Volume Status
+ When a snapshot operation is triggered by means of a recurring snapshot
+ policy, a snapshot is skipped if a volume has remained inactive since its
+ last snapshot was taken. A volume is considered to be inactive if it is
+ either detached or attached to a VM that is not running. &PRODUCT; ensures
+ that at least one snapshot is taken since the volume last became inactive.
+
+ When a snapshot is taken manually, a snapshot is always created
+ regardless of whether a volume has been active or not.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/vpc.xml b/docs/tmp/en-US/xml_tmp/vpc.xml
new file mode 100644
index 00000000000..cfa5fe1dd02
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vpc.xml
@@ -0,0 +1,183 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ About Virtual Private Clouds
+ &PRODUCT; Virtual Private Cloud is a private, isolated part of &PRODUCT;. A VPC can have its
+ own virtual network topology that resembles a traditional physical network. You can launch VMs
+ in the virtual network that can have private addresses in the range of your choice, for example:
+ 10.0.0.0/16. You can define network tiers within your VPC network range, which in turn enables
+ you to group similar kinds of instances based on IP address range.
+ For example, if a VPC has the private range 10.0.0.0/16, its guest networks can have the
+ network ranges 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and so on.
+
+ Major Components of a VPC:
+ A VPC is comprised of the following network components:
+
+
+
+ VPC: A VPC acts as a container for multiple isolated
+ networks that can communicate with each other via its virtual router.
+
+
+ Network Tiers: Each tier acts as an isolated network
+ with its own VLANs and CIDR list, where you can place groups of resources, such as VMs. The
+ tiers are segmented by means of VLANs. The NIC of each tier acts as its gateway.
+
+
+ Virtual Router: A virtual router is automatically
+ created and started when you create a VPC. The virtual router connect the tiers and direct
+ traffic among the public gateway, the VPN gateways, and the NAT instances. For each tier, a
+ corresponding NIC and IP exist in the virtual router. The virtual router provides DNS and
+ DHCP services through its IP.
+
+
+ Public Gateway: The traffic to and from the Internet
+ routed to the VPC through the public gateway. In a VPC, the public gateway is not exposed to
+ the end user; therefore, static routes are not support for the public gateway.
+
+
+ Private Gateway: All the traffic to and from a private
+ network routed to the VPC through the private gateway. For more information, see .
+
+
+ VPN Gateway: The VPC side of a VPN connection.
+
+
+ Site-to-Site VPN Connection: A hardware-based VPN
+ connection between your VPC and your datacenter, home network, or co-location facility. For
+ more information, see .
+
+
+ Customer Gateway: The customer side of a VPN
+ Connection. For more information, see .
+
+
+ NAT Instance: An instance that provides Port Address
+ Translation for instances to access the Internet via the public gateway. For more
+ information, see .
+
+
+
+ Network Architecture in a VPC
+ In a VPC, the following four basic options of network architectures are present:
+
+
+
+ VPC with a public gateway only
+
+
+ VPC with public and private gateways
+
+
+ VPC with public and private gateways and site-to-site VPN access
+
+
+ VPC with a private gateway only and site-to-site VPN access
+
+
+
+ Connectivity Options for a VPC
+ You can connect your VPC to:
+
+
+
+ The Internet through the public gateway.
+
+
+ The corporate datacenter by using a site-to-site VPN connection through the VPN
+ gateway.
+
+
+ Both the Internet and your corporate datacenter by using both the public gateway and a
+ VPN gateway.
+
+
+
+ VPC Network Considerations
+ Consider the following before you create a VPC:
+
+
+
+ A VPC, by default, is created in the enabled state.
+
+
+ A VPC can be created in Advance zone only, and can't belong to more than one zone at a
+ time.
+
+
+ The default number of VPCs an account can create is 20. However, you can change it by
+ using the max.account.vpcs global parameter, which controls the maximum number of VPCs an
+ account is allowed to create.
+
+
+ The default number of tiers an account can create within a VPC is 3. You can configure
+ this number by using the vpc.max.networks parameter.
+
+
+ Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be
+ within the VPC CIDR range.
+
+
+ A tier belongs to only one VPC.
+
+
+ All network tiers inside the VPC should belong to the same account.
+
+
+ When a VPC is created, by default, a SourceNAT IP is allocated to it. The Source NAT IP
+ is released only when the VPC is removed.
+
+
+ A public IP can be used for only one purpose at a time. If the IP is a sourceNAT, it
+ cannot be used for StaticNAT or port forwarding.
+
+
+ The instances only have a private IP address that you provision. To communicate with the
+ Internet, enable NAT to an instance that you launch in your VPC.
+
+
+ Only new networks can be added to a VPC. The maximum number of networks per VPC is
+ limited by the value you specify in the vpc.max.networks parameter. The default value is
+ three.
+
+
+ The load balancing service can be supported by only one tier inside the VPC.
+
+
+ If an IP address is assigned to a tier:
+
+
+ That IP can't be used by more than one tier at a time in the VPC. For example, if
+ you have tiers A and B, and a public IP1, you can create a port forwarding rule by using
+ the IP either for A or B, but not for both.
+
+
+ That IP can't be used for StaticNAT, load balancing, or port forwarding rules for
+ another guest network inside the VPC.
+
+
+
+
+ Remote access VPN is not supported in VPC networks.
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/vpn.xml b/docs/tmp/en-US/xml_tmp/vpn.xml
new file mode 100644
index 00000000000..724e4800f94
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/vpn.xml
@@ -0,0 +1,37 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ VPN
+ &PRODUCT; account owners can create virtual private networks (VPN) to access their virtual machines. If the guest network is instantiated from a network offering that offers the Remote Access VPN service, the virtual router (based on the System VM) is used to provide the service. &PRODUCT; provides a L2TP-over-IPsec-based remote access VPN service to guest virtual networks. Since each network gets its own virtual router, VPNs are not shared across the networks. VPN clients native to Windows, Mac OS X and iOS can be used to connect to the guest networks. The account owner can create and manage users for their VPN. &PRODUCT; does not use its account database for this purpose but uses a separate table. The VPN user database is shared across all the VPNs created by the account owner. All VPN users get access to all VPNs created by the account owner.
+ Make sure that not all traffic goes through the VPN. That is, the route installed by the VPN should be only for the guest network and not for all traffic.
+
+ Road Warrior / Remote Access. Users want to be able to connect securely from a home or office to a private network in the cloud. Typically, the IP address of the connecting client is dynamic and cannot be preconfigured on the VPN server.
+ Site to Site. In this scenario, two private subnets are connected over the public Internet with a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected through a gateway to the network in the cloud. The address of the user’s gateway must be preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used to set up Site-to-Site VPNs, this is not the primary intent of this feature.
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/whatis.xml b/docs/tmp/en-US/xml_tmp/whatis.xml
new file mode 100644
index 00000000000..5103b2ec583
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/whatis.xml
@@ -0,0 +1,41 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ What Is &PRODUCT;?
+ &PRODUCT; is an open source software platform that pools computing resources to build public, private, and hybrid Infrastructure as a Service (IaaS) clouds. &PRODUCT; manages the network, storage, and compute nodes that make up a cloud infrastructure. Use &PRODUCT; to deploy, manage, and configure cloud computing environments.
+ Typical users are service providers and enterprises. With &PRODUCT;, you can:
+
+
+ Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual machine instances, storage volumes, and networking configurations over the Internet.
+
+ Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in the same way as physical machines, with &PRODUCT; an enterprise can offer self-service virtual machines to users without involving IT departments.
+
+
+
+
+
+ 1000-foot-view.png: Overview of &PRODUCT;
+
+
diff --git a/docs/tmp/en-US/xml_tmp/whats-in-this-adminguide.xml b/docs/tmp/en-US/xml_tmp/whats-in-this-adminguide.xml
new file mode 100644
index 00000000000..68717dd596e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/whats-in-this-adminguide.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Who Should Read This
+ If you have already installed &PRODUCT; or you want to learn more about the ongoing operation and maintenance of a &PRODUCT;-powered cloud, read this documentation. It will help you start using, configuring, and managing the ongoing operation of your cloud.
+
diff --git a/docs/tmp/en-US/xml_tmp/whats-new.xml b/docs/tmp/en-US/xml_tmp/whats-new.xml
new file mode 100644
index 00000000000..5f13db3a854
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/whats-new.xml
@@ -0,0 +1,42 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ What's New in the API?
+ The following describes any new major features of each &PRODUCT; version as it applies to API usage.
+
+ What's New in the API for 4.0
+
+
+
+
+ What's New in the API for 3.0
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/who-should-read-installation.xml b/docs/tmp/en-US/xml_tmp/who-should-read-installation.xml
new file mode 100644
index 00000000000..eb55ee476ec
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/who-should-read-installation.xml
@@ -0,0 +1,28 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Who Should Read This
+ For those who have already gone through a design phase and planned a more sophisticated deployment, or those who are ready to start scaling up a trial installation. With the following procedures, you can start using the more powerful features of &PRODUCT;, 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.
+
diff --git a/docs/tmp/en-US/xml_tmp/windows-installation.xml b/docs/tmp/en-US/xml_tmp/windows-installation.xml
new file mode 100644
index 00000000000..541f8ddd4e5
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/windows-installation.xml
@@ -0,0 +1,31 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Windows OS Installation
+ Download the installer, CloudInstanceManager.msi, from
+ Download page
+ and run the installer in the newly created Windows VM.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/work-with-usage.xml b/docs/tmp/en-US/xml_tmp/work-with-usage.xml
new file mode 100644
index 00000000000..939ba6378a4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/work-with-usage.xml
@@ -0,0 +1,36 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Working with Usage
+ The Usage Server is an optional, separately-installed part of &PRODUCT; that provides aggregated usage records which you can use to create billing integration for &PRODUCT;. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+ The usage records show the amount of resources, such as VM run time or template storage
+ space, consumed by guest instances.
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/working-with-hosts.xml b/docs/tmp/en-US/xml_tmp/working-with-hosts.xml
new file mode 100644
index 00000000000..4dcb8521ae2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/working-with-hosts.xml
@@ -0,0 +1,39 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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 .
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/working-with-iso.xml b/docs/tmp/en-US/xml_tmp/working-with-iso.xml
new file mode 100644
index 00000000000..efe5fb50e5e
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/working-with-iso.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Working with ISOs
+ &PRODUCT; supports ISOs and their attachment to guest VMs. An ISO is a read-only file that has an ISO/CD-ROM style file system. Users can upload their own ISOs and mount them on their guest VMs.
+ ISOs are uploaded based on a URL. HTTP is the supported protocol. Once the ISO is available via HTTP specify an upload URL such as http://my.web.server/filename.iso.
+ ISOs may be public or private, like templates.ISOs are not hypervisor-specific. That is, a guest on vSphere can mount the exact same image that a guest on KVM can mount.
+ ISO images may be stored in the system and made available with a privacy level similar to templates. ISO images are classified as either bootable or not bootable. A bootable ISO image is one that contains an OS image. &PRODUCT; allows a user to boot a guest VM off of an ISO image. Users can also attach ISO images to guest VMs. For example, this enables installing PV drivers into Windows. ISO images are not hypervisor-specific.
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/working-with-snapshots.xml b/docs/tmp/en-US/xml_tmp/working-with-snapshots.xml
new file mode 100644
index 00000000000..d6b145875d4
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/working-with-snapshots.xml
@@ -0,0 +1,32 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Working with Snapshots
+ (Supported for the following hypervisors: XenServer, VMware vSphere, and KVM)
+ &PRODUCT; supports snapshots of disk volumes. Snapshots are a point-in-time capture of virtual machine disks. Memory and CPU states are not captured.
+ Snapshots may be taken for volumes, including both root and data disks. The administrator places a limit on the number of stored snapshots per user. Users can create new volumes from the snapshot for recovery of particular files and they can create templates from snapshots to boot from a restored disk.
+ Users can create snapshots manually or by setting up automatic recurring snapshot policies. Users can also create disk volumes from snapshots, which may be attached to a VM like any other disk volume. Snapshots of both root disks and data disks are supported. However, &PRODUCT; does not currently support booting a VM from a recovered root disk. A disk recovered from snapshot of a root disk is treated as a regular data disk; the data on recovered disk can be accessed by attaching the disk to a VM.
+ A completed snapshot is copied from primary storage to secondary storage, where it is stored until deleted or purged by newer snapshot.
+
diff --git a/docs/tmp/en-US/xml_tmp/working-with-system-vm.xml b/docs/tmp/en-US/xml_tmp/working-with-system-vm.xml
new file mode 100644
index 00000000000..ed2bdcded41
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/working-with-system-vm.xml
@@ -0,0 +1,33 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Working with System Virtual Machines
+ &PRODUCT; uses several types of system virtual machines to perform tasks in the cloud. In general &PRODUCT; manages these system VMs and creates, starts, and stops them as needed based on scale and immediate needs. However, the administrator should be aware of them and their roles to assist in debugging issues.
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tmp/en-US/xml_tmp/working-with-templates.xml b/docs/tmp/en-US/xml_tmp/working-with-templates.xml
new file mode 100644
index 00000000000..a01c1814a21
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/working-with-templates.xml
@@ -0,0 +1,44 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Working with Templates
+ A template is a reusable configuration for virtual machines. When users launch VMs, they can choose from a list of templates in &PRODUCT;.
+ Specifically, a template is a virtual disk image that includes one of a variety of operating systems, optional additional software such as office applications, and settings such as access control to determine who can use the template. Each template is associated with a particular type of hypervisor, which is specified when the template is added to &PRODUCT;.
+ &PRODUCT; ships with a default template. In order to present more choices to users, &PRODUCT; administrators and users can create templates and add them to &PRODUCT;.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/working-with-usage-data.xml b/docs/tmp/en-US/xml_tmp/working-with-usage-data.xml
new file mode 100644
index 00000000000..56a929fd6c1
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/working-with-usage-data.xml
@@ -0,0 +1,34 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Working With Usage Data
+ The Usage Server provides aggregated usage records which you can use to create billing integration for the &PRODUCT; platform. The Usage Server works by taking data from the events log and creating summary usage records that you can access using the listUsageRecords API call.
+ The usage records show the amount of resources, such as VM run time or template storage space, consumed by guest instances. In the special case of bare metal instances, no template storage resources are consumed, but records showing zero usage are still included in the Usage Server's output.
+ The Usage Server runs at least once per day. It can be configured to run multiple times per day. Its behavior is controlled by configuration settings as described in the &PRODUCT; Administration Guide.
+
+
+
+
+
diff --git a/docs/tmp/en-US/xml_tmp/working-with-volumes.xml b/docs/tmp/en-US/xml_tmp/working-with-volumes.xml
new file mode 100644
index 00000000000..117912015d2
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/working-with-volumes.xml
@@ -0,0 +1,48 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Using Swift for Secondary Storage
+ A volume provides storage to a guest VM. The volume can provide for
+ a root disk or an additional data disk. &PRODUCT; supports additional
+ volumes for guest VMs.
+
+ Volumes are created for a specific hypervisor type. A volume that has
+ been attached to guest using one hypervisor type (e.g, XenServer) may not
+ be attached to a guest that is using another hypervisor type (e.g.
+ vSphere, KVM). This is because the different hypervisors use
+ different disk image formats.
+
+ &PRODUCT; defines a volume as a unit of storage available to a guest
+ VM. Volumes are either root disks or data disks. The root disk has "/"
+ in the file system and is usually the boot device. Data disks provide
+ for additional storage (e.g. As "/opt" or "D:"). Every guest VM has a root
+ disk, and VMs can also optionally have a data disk. End users can mount
+ multiple data disks to guest VMs. Users choose data disks from the disk
+ offerings created by administrators. The user can create a template from
+ a volume as well; this is the standard procedure for private template
+ creation. Volumes are hypervisor-specific: a volume from one hypervisor
+ type may not be used on a guest of another hypervisor type.
+
+
diff --git a/docs/tmp/en-US/xml_tmp/xenserver-maintenance-mode.xml b/docs/tmp/en-US/xml_tmp/xenserver-maintenance-mode.xml
new file mode 100644
index 00000000000..4dfa43ebe05
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/xenserver-maintenance-mode.xml
@@ -0,0 +1,51 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ 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
+
+
diff --git a/docs/tmp/en-US/xml_tmp/xenserver-topology-req.xml b/docs/tmp/en-US/xml_tmp/xenserver-topology-req.xml
new file mode 100644
index 00000000000..12b9b077fe7
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/xenserver-topology-req.xml
@@ -0,0 +1,24 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+ XenServer Topology Requirements
+ The Management Servers communicate with XenServer hosts on ports 22 (ssh), 80 (HTTP), and 443 (HTTPs).
+
diff --git a/docs/tmp/en-US/xml_tmp/zone-add.xml b/docs/tmp/en-US/xml_tmp/zone-add.xml
new file mode 100644
index 00000000000..2a85bb0b432
--- /dev/null
+++ b/docs/tmp/en-US/xml_tmp/zone-add.xml
@@ -0,0 +1,77 @@
+
+
+%BOOK_ENTITIES;
+]>
+
+
+
+
+ Adding a Zone
+ These steps assume you have already logged in to the &PRODUCT; UI. See .
+
+ (Optional) If you are going to use Swift for cloud-wide secondary storage, you need to add it before you add zones.
+
+ Log in to the &PRODUCT; UI as administrator.
+ If this is your first time visiting the UI, you will see the guided tour splash screen. Choose “Experienced user.” The Dashboard appears.
+ In the left navigation bar, click Global Settings.
+ In the search box, type swift.enable and click the search button.
+ Click the edit button and set swift.enable to true.
+
+
+
+
+ edit-icon.png: button to modify data
+
+
+
+ Restart the Management Server.
+ # service cloud-management restart
+
+ Refresh the &PRODUCT; UI browser tab and log back in.
+
+
+ In the left navigation, choose Infrastructure.
+ On Zones, click View More.
+ (Optional) If you are using Swift storage, click Enable Swift. Provide the following:
+
+ URL. The Swift URL.
+ Account. The Swift account.
+ Username. The Swift account’s username.
+ Key. The Swift key.
+
+
+ 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.
+
+ For more information about the network types, see Network Setup.
+
+ The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the steps that apply to you:
+
+
+
+
+
+
+
+
+
.
+ 
