&PRODUCT; Developer's Guide

In-Reply-To: <70dce7e46df64989b9cdbc3fddef9604@git.apache.org> References: <70dce7e46df64989b9cdbc3fddef9604@git.apache.org> X-Mailer: ASF-Git Admin Mailer Subject: [47/51] [partial] cloudstack-docs git commit: Remove all old docbook files http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/Developers_Guide.xml ---------------------------------------------------------------------- diff --git a/en-US/Developers_Guide.xml b/en-US/Developers_Guide.xml deleted file mode 100644 index 7106faf..0000000 --- a/en-US/Developers_Guide.xml +++ /dev/null @@ -1,61 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - - - - &PRODUCT; Developer's Guide - Apache CloudStack - 4.3.0 - - - - - This guide shows how to develop &PRODUCT;, use the API for operation and integration, access the usage data and use &PRODUCT; specific tools to ease development, testing and integration. - - - - - - - - - - - - - - - - - - - - - - - - - - - http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/Installation_Guide.ent ---------------------------------------------------------------------- diff --git a/en-US/Installation_Guide.ent b/en-US/Installation_Guide.ent deleted file mode 100644 index abb1885..0000000 --- a/en-US/Installation_Guide.ent +++ /dev/null @@ -1,22 +0,0 @@ - - - - - - http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/Installation_Guide.xml ---------------------------------------------------------------------- diff --git a/en-US/Installation_Guide.xml b/en-US/Installation_Guide.xml deleted file mode 100644 index 8b4c871..0000000 --- a/en-US/Installation_Guide.xml +++ /dev/null @@ -1,62 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - - - &PRODUCT; Installation Guide - Apache CloudStack - 4.3.0 - 1 - - - Installation Guide for &PRODUCT;. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/LDAPserver-for-user-authentication.xml ---------------------------------------------------------------------- diff --git a/en-US/LDAPserver-for-user-authentication.xml b/en-US/LDAPserver-for-user-authentication.xml deleted file mode 100644 index 449d500..0000000 --- a/en-US/LDAPserver-for-user-authentication.xml +++ /dev/null @@ -1,53 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -

- Using an LDAP Server for User Authentication - &PRODUCT; supports authentication through a Lightweight Directory Access Protocol (LDAP) - server, such as Microsoft Active Directory or ApacheDS. You can add LDAP associations to - &PRODUCT; so users can log in by using credentials based on your existing authentication scheme. - Additionally, the simplified LDAP authentication mechanism in &PRODUCT; 4.3 allows you to import - users directly from the configured LDAP Group. LDAP users are authenticated without creating - individual users in &PRODUCT;. - To use LDAP for authentication of &PRODUCT; users, you must do the following steps: - - - Add a working LDAP server. - See . - - - Configure the LDAP attributes. - See . - - - Import users from the LDAP group. - See . - - - To confirm authentication, log in to &PRODUCT; UI as one of the LDAP user you have - imported. - - - - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/Preface.xml ---------------------------------------------------------------------- diff --git a/en-US/Preface.xml b/en-US/Preface.xml deleted file mode 100644 index 28ad48e..0000000 --- a/en-US/Preface.xml +++ /dev/null @@ -1,31 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - - - Preface - - - - - http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/Revision_History.xml ---------------------------------------------------------------------- diff --git a/en-US/Revision_History.xml b/en-US/Revision_History.xml deleted file mode 100644 index 55d741a..0000000 --- a/en-US/Revision_History.xml +++ /dev/null @@ -1,45 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - - - Revision History - - - - 0-0 - Tue May 29 2012 - - Jessica - Tomechak - - - - - Initial creation of book by publican - - - - - - http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/Revision_History_Install_Guide.xml ---------------------------------------------------------------------- diff --git a/en-US/Revision_History_Install_Guide.xml b/en-US/Revision_History_Install_Guide.xml deleted file mode 100644 index ee8dd31..0000000 --- a/en-US/Revision_History_Install_Guide.xml +++ /dev/null @@ -1,55 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - - - Revision History - - - - 1-0 - October 5 2012 - - Jessica - Tomechak - - - - Radhika - PC - - - - Wido - den Hollander - - - - - Initial publication - - - - - - http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/SSL-keystore-path-and-password.xml ---------------------------------------------------------------------- diff --git a/en-US/SSL-keystore-path-and-password.xml b/en-US/SSL-keystore-path-and-password.xml deleted file mode 100644 index f7b7426..0000000 --- a/en-US/SSL-keystore-path-and-password.xml +++ /dev/null @@ -1,28 +0,0 @@ - - -%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. -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/VPN-user-usage-record-format.xml ---------------------------------------------------------------------- diff --git a/en-US/VPN-user-usage-record-format.xml b/en-US/VPN-user-usage-record-format.xml deleted file mode 100644 index dd66fb4..0000000 --- a/en-US/VPN-user-usage-record-format.xml +++ /dev/null @@ -1,40 +0,0 @@ - - -%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 - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-clusters.xml ---------------------------------------------------------------------- diff --git a/en-US/about-clusters.xml b/en-US/about-clusters.xml deleted file mode 100644 index ff9c57e..0000000 --- a/en-US/about-clusters.xml +++ /dev/null @@ -1,63 +0,0 @@ - - -%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 fourth-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. - An Administrator must register the vCenter server with &PRODUCT;. There may - be multiple vCenter servers per zone. Each vCenter server may manage - multiple VMware clusters. - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-hosts.xml ---------------------------------------------------------------------- diff --git a/en-US/about-hosts.xml b/en-US/about-hosts.xml deleted file mode 100644 index 4264cc8..0000000 --- a/en-US/about-hosts.xml +++ /dev/null @@ -1,49 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - -

- About Hosts - A host is a single computer. Hosts provide the computing resources that run guest virtual - machines. Each host has hypervisor software installed on it to manage the guest VMs. For - example, a host can be a Citrix XenServer server, a Linux KVM-enabled server, an ESXi server, or - a Windows Hyper-V server. - The host is the smallest organizational unit within a &PRODUCT; deployment. Hosts are contained within clusters, clusters are contained within pods, pods are contained within zones, and - zones can be contained within regions. - Hosts in a &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. - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-password-encryption.xml ---------------------------------------------------------------------- diff --git a/en-US/about-password-encryption.xml b/en-US/about-password-encryption.xml deleted file mode 100644 index a13ff60..0000000 --- a/en-US/about-password-encryption.xml +++ /dev/null @@ -1,65 +0,0 @@ - - -%BOOK_ENTITIES; -]> - -

- About Password and Key Encryption - &PRODUCT; stores several sensitive passwords and secret keys that are used to provide - security. These values are always automatically encrypted: - - - Database secret key - - - Database password - - - SSH keys - - - Compute node root password - - - VPN password - - - User API secret key - - - VNC password - - - &PRODUCT; uses the Java Simplified Encryption (JASYPT) library. The data values are - encrypted and decrypted using a database secret key, which is stored in one of &PRODUCT;’s - internal properties files along with the database password. The other encrypted values listed - above, such as SSH keys, are in the &PRODUCT; internal database. - Of course, the database secret key itself can not be stored in the open – it must be - encrypted. How then does &PRODUCT; read it? A second secret key must be provided from an - external source during Management Server startup. This key can be provided in one of two ways: - loaded from a file or provided by the &PRODUCT; administrator. The &PRODUCT; database has a - configuration setting that lets it know which of these methods will be used. If the encryption - type is set to "file," the key must be in a file in a known location. If the encryption type is - set to "web," the administrator runs the utility - com.cloud.utils.crypt.EncryptionSecretKeySender, which relays the key to the Management Server - over a known port. - The encryption type, database secret key, and Management Server secret key are set during - &PRODUCT; installation. They are all parameters to the &PRODUCT; database setup script - (cloudstack-setup-databases). The default values are file, password, and password. It is, of course, - highly recommended that you change these to more secure keys. -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-physical-networks.xml ---------------------------------------------------------------------- diff --git a/en-US/about-physical-networks.xml b/en-US/about-physical-networks.xml deleted file mode 100644 index b22e48b..0000000 --- a/en-US/about-physical-networks.xml +++ /dev/null @@ -1,42 +0,0 @@ - - -%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 - - - - - - - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-pods.xml ---------------------------------------------------------------------- diff --git a/en-US/about-pods.xml b/en-US/about-pods.xml deleted file mode 100644 index 72db19c..0000000 --- a/en-US/about-pods.xml +++ /dev/null @@ -1,38 +0,0 @@ - - -%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 third-largest organizational unit within a &PRODUCT; deployment. Pods are contained within zones. Each zone can contain one or more pods. - A pod consists of one or more clusters of hosts and one or more primary storage servers. - Pods are not visible to the end user. - - - - - - pod-overview.png: Nested structure of a simple pod - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-primary-storage.xml ---------------------------------------------------------------------- diff --git a/en-US/about-primary-storage.xml b/en-US/about-primary-storage.xml deleted file mode 100644 index ca319c6..0000000 --- a/en-US/about-primary-storage.xml +++ /dev/null @@ -1,47 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - -

- About Primary Storage - Primary storage is associated with a cluster or (in KVM and VMware) a zone, and it stores - the disk volumes for all the VMs running on hosts. - You can add multiple primary storage servers to a cluster or zone. At least one is - required. It is typically located close to the hosts for increased performance. - &PRODUCT; manages the allocation of guest virtual disks to particular primary storage devices. - It is useful to set up zone-wide primary storage when you want to avoid extra data copy - operations. With cluster-based primary storage, data in the primary storage is directly - available only to VMs within that cluster. If a VM in a different cluster needs some of the - data, it must be copied from one cluster to another, using the zone's secondary storage as an - intermediate step. This operation can be unnecessarily time-consuming. - For Hyper-V, SMB/CIFS storage is supported. Note that Zone-wide Primary Storage is not - supported in Hyper-V. - &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 adding separate - primary storage. -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-regions.xml ---------------------------------------------------------------------- diff --git a/en-US/about-regions.xml b/en-US/about-regions.xml deleted file mode 100644 index a12c183..0000000 --- a/en-US/about-regions.xml +++ /dev/null @@ -1,50 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -

- About Regions - To increase reliability of the cloud, you can optionally group resources into multiple geographic regions. - A region is the largest available organizational unit within a &PRODUCT; deployment. - A region is made up of several availability zones, where each zone is roughly equivalent to a datacenter. - Each region is controlled by its own cluster of Management Servers, running in one of the zones. - The zones in a region are typically located in close geographical proximity. - Regions are a useful technique for providing fault tolerance and disaster recovery. - By grouping zones into regions, the cloud can achieve higher availability and scalability. - User accounts can span regions, so that users can deploy VMs in multiple, widely-dispersed regions. - Even if one of the regions becomes unavailable, the services are still available to the end-user through VMs deployed in another region. - And by grouping communities of zones under their own nearby Management Servers, the latency of communications within the cloud is reduced - compared to managing widely-dispersed zones from a single central Management Server. - - - Usage records can also be consolidated and tracked at the region level, creating reports or invoices for each geographic region. - - - - - - region-overview.png: Nested structure of a region. - - Regions are visible to the end user. When a user starts a guest VM on a particular &PRODUCT; Management Server, - the user is implicitly selecting that region for their guest. - Users might also be required to copy their private templates to additional regions to enable creation of guest VMs using their templates in those regions. -

\ No newline at end of file http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-secondary-storage.xml ---------------------------------------------------------------------- diff --git a/en-US/about-secondary-storage.xml b/en-US/about-secondary-storage.xml deleted file mode 100644 index f6c2277..0000000 --- a/en-US/about-secondary-storage.xml +++ /dev/null @@ -1,61 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -

- About Secondary Storage - Secondary storage stores the following: - - - Templates — OS images that can be used to boot VMs and can include additional - configuration information, such as installed applications - - - ISO images — disc images containing data or bootable media for operating - systems - - - Disk volume snapshots — saved copies of VM data which can be used for data - recovery or to create new templates - - - The items in secondary storage are available to all hosts in the scope of the secondary - storage, which may be defined as per zone or per region. - To make items in secondary storage available to all hosts throughout the cloud, you can add - object storage in addition to the zone-based NFS Secondary Staging Store. It is not necessary to - copy templates and snapshots from one zone to another, as would be required when using zone NFS - alone. Everything is available everywhere. - For Hyper-V hosts, SMB/CIFS storage is supported. - &PRODUCT; provides plugins that enable both OpenStack Object Storage (Swift, swift.openstack.org) and Amazon Simple Storage - Service (S3) object storage. When using one of these storage plugins, you configure Swift or S3 - storage for the entire &PRODUCT;, then set up the NFS Secondary Staging Store for each zone. The - NFS storage in each zone acts as a staging area through which all templates and other secondary - storage data pass before being forwarded to Swift or S3. The backing object storage acts as a - cloud-wide resource, making templates and other data available to any zone in the cloud. - - - Heterogeneous Secondary Storage is not supported in Regions. For example, you cannot set - up multiple zones, one using NFS secondary and the other using S3 or Swift secondary. - - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-security-groups.xml ---------------------------------------------------------------------- diff --git a/en-US/about-security-groups.xml b/en-US/about-security-groups.xml deleted file mode 100644 index 6a31b25..0000000 --- a/en-US/about-security-groups.xml +++ /dev/null @@ -1,40 +0,0 @@ - - -%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 advanced zones, security groups are supported only on the KVM hypervisor. - 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. -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-virtual-networks.xml ---------------------------------------------------------------------- diff --git a/en-US/about-virtual-networks.xml b/en-US/about-virtual-networks.xml deleted file mode 100644 index 4dbd201..0000000 --- a/en-US/about-virtual-networks.xml +++ /dev/null @@ -1,30 +0,0 @@ - - -%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. - - - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-working-with-vms.xml ---------------------------------------------------------------------- diff --git a/en-US/about-working-with-vms.xml b/en-US/about-working-with-vms.xml deleted file mode 100644 index 90e5abf..0000000 --- a/en-US/about-working-with-vms.xml +++ /dev/null @@ -1,64 +0,0 @@ - - -%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 - - - - You can append the display name of a guest VM to its internal name. For more information, - see . - - 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. Optionally, you can also decide not to allocate a - public IP to a VM in an EIP-enabled Basic zone. For more information on Elastic IP, see . - &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. -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/about-zones.xml ---------------------------------------------------------------------- diff --git a/en-US/about-zones.xml b/en-US/about-zones.xml deleted file mode 100644 index 2a4eeb4..0000000 --- a/en-US/about-zones.xml +++ /dev/null @@ -1,74 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -

- About Zones - A zone is the second 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. - A zone may contain one or more primary storage servers, which are shared by all the pods in the zone. - Secondary storage, which is shared by all the pods in the zone. - - - - - - zone-overview.png: Nested structure of a simple zone. - - Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for their guest. Users might also be required to copy their private templates to additional zones to enable creation of guest VMs using their templates in those zones. - Zones can be public or private. Public zones are visible to all users. This means that any user may create a guest in that zone. Private zones are reserved for a specific domain. Only users in that domain or its subdomains may create guests in that zone. - Hosts in the same zone are directly accessible to each other without having to go through a firewall. Hosts in different zones can access each other through statically configured VPN tunnels. - For each zone, the administrator must decide the following. - - How many pods to place in each zone. - How many clusters to place in each pod. - How many hosts to place in each cluster. - (Optional) How many primary storage servers to place in each zone and total capacity for these storage servers. - How many primary storage servers to place in each cluster and total capacity for these storage servers. - How much secondary storage to deploy in a zone. - - When you add a new zone using the &PRODUCT; UI, you will be prompted to configure the zone’s physical network - and add the first pod, cluster, host, primary storage, and secondary storage. - In order to support zone-wide functions for VMware, &PRODUCT; is aware of VMware Datacenters and can map each Datacenter to a - &PRODUCT; zone. To enable features like storage live migration and zone-wide - primary storage for VMware hosts, &PRODUCT; has to make sure that a zone - contains only a single VMware Datacenter. Therefore, when you are creating a new - &PRODUCT; zone, you can select a VMware Datacenter for the zone. If you - are provisioning multiple VMware Datacenters, each one will be set up as a single zone - in &PRODUCT;. - - If you are upgrading from a previous &PRODUCT; version, and your existing - deployment contains a zone with clusters from multiple VMware Datacenters, that zone - will not be forcibly migrated to the new model. It will continue to function as - before. However, any new zone-wide operations, such as zone-wide primary storage - and live storage migration, will - not be available in that zone. - - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/accept-membership-invite.xml ---------------------------------------------------------------------- diff --git a/en-US/accept-membership-invite.xml b/en-US/accept-membership-invite.xml deleted file mode 100644 index dc59d00..0000000 --- a/en-US/accept-membership-invite.xml +++ /dev/null @@ -1,36 +0,0 @@ - - -%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. - -

- http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/accessing-system-vms.xml ---------------------------------------------------------------------- diff --git a/en-US/accessing-system-vms.xml b/en-US/accessing-system-vms.xml deleted file mode 100755 index e1b6090..0000000 --- a/en-US/accessing-system-vms.xml +++ /dev/null @@ -1,66 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - -

- Accessing System VMs - It may sometimes be necessary to access System VMs for diagnostics of certain issues, for example if you are experiencing SSVM (Secondary Storage VM) connection issues. Use the steps below in order to connect to the SSH console of a running System VM. - - Accessing System VMs over the network requires the use of private keys and connecting to System VMs SSH Daemon on port 3922. - XenServer/KVM Hypervisors store this key at /root/.ssh/id_rsa.cloud on each &PRODUCT; agent. - To access System VMs running on ESXi, the key is stored on the management server at /var/lib/cloudstack/management/.ssh/id_rsa. - - - - Find the details of the System VM - - Log in with admin privileges to the &PRODUCT; UI. - Click Infrastructure, then System VMs, and then click the name of a running VM. - Take a note of the 'Host', 'Private IP Address' and 'Link Local IP Address' of the System VM you wish to access. - - - - - XenServer/KVM Hypervisors - - Connect to the Host of which the System VM is running. - SSH the 'Link Local IP Address' of the System VM from the Host on which the VM is running. - Format: ssh -i <path-to-private-key> <link-local-ip> -p 3922 - Example: root@faith:~# ssh -i /root/.ssh/id_rsa.cloud 169.254.3.93 -p 3922 - - - - ESXi Hypervisors - - Connect to your &PRODUCT; Management Server. - ESXi users should SSH to the private IP address of the System VM. - Format: ssh -i <path-to-private-key> <vm-private-ip> -p 3922 - Example: root@management:~# ssh -i /var/lib/cloudstack/management/.ssh/id_rsa 172.16.0.250 -p 3922 - - - - - - - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/accessing-vms.xml ---------------------------------------------------------------------- diff --git a/en-US/accessing-vms.xml b/en-US/accessing-vms.xml deleted file mode 100644 index 67d9d77..0000000 --- a/en-US/accessing-vms.xml +++ /dev/null @@ -1,40 +0,0 @@ - - -%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 . - 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 . - -

- http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/accounts-users-domains.xml ---------------------------------------------------------------------- diff --git a/en-US/accounts-users-domains.xml b/en-US/accounts-users-domains.xml deleted file mode 100644 index 3accbbe..0000000 --- a/en-US/accounts-users-domains.xml +++ /dev/null @@ -1,133 +0,0 @@ - - -%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 - - - Resource Ownership - Resources belong to the account, not individual users in that account. For example, - billing, resource limits, and so on are maintained by the account, not the users. A user - can operate on any resource in the account provided the user has privileges for that - operation. The privileges are determined by the role. A root administrator can change - the ownership of any virtual machine from one account to any other account by using the - assignVirtualMachine API. A domain or sub-domain administrator can do the same for VMs - within the domain from one account to any other account in the domain or any of its - sub-domains. - -

- Dedicating Resources to Accounts and Domains - The root administrator can dedicate resources to a specific domain or account - that needs private infrastructure for additional security or performance guarantees. - A zone, pod, cluster, or host can be reserved by the root administrator for a specific domain or account. - Only users in that domain or its subdomain may use the infrastructure. - For example, only users in a given domain can create guests in a zone dedicated to that domain. - There are several types of dedication available: - - - Explicit dedication. A zone, pod, cluster, or host is dedicated to an account or - domain by the root administrator during initial deployment and - configuration. - Strict implicit dedication. A host will not be shared across multiple accounts. For example, - strict implicit dedication is useful for deployment of certain types of - applications, such as desktops, where no host can be shared - between different accounts without violating the desktop software's terms of license. - Preferred implicit dedication. The VM will be deployed in dedicated infrastructure if - possible. Otherwise, the VM can be deployed in shared - infrastructure. - -

- How to Dedicate a Zone, Cluster, Pod, or Host to an Account or Domain - For explicit dedication: When deploying a new zone, pod, cluster, or host, the - root administrator can click the Dedicated checkbox, then choose a domain or account - to own the resource. - To explicitly dedicate an existing zone, pod, cluster, or host: log in as the root admin, - find the resource in the UI, and click the Dedicate button. - - - - - dedicate-resource-button.png: button to dedicate a zone, pod, cluster, or host - - - For implicit dedication: The administrator creates a compute service offering and - in the Deployment Planner field, chooses ImplicitDedicationPlanner. Then in Planner - Mode, the administrator specifies either Strict or Preferred, depending on whether - it is permissible to allow some use of shared resources when dedicated resources are - not available. Whenever a user creates a VM based on this service offering, it is - allocated on one of the dedicated hosts. -

- How to Use Dedicated Hosts - To use an explicitly dedicated host, use the explicit-dedicated type of affinity - group (see ). For example, when creating a new VM, - an end user can choose to place it on dedicated infrastructure. This operation will - succeed only if some infrastructure has already been assigned as dedicated to the - user's account or domain. -

- Behavior of Dedicated Hosts, Clusters, Pods, and Zones - The administrator can live migrate VMs away from dedicated hosts if desired, whether the destination - is a host reserved for a different account/domain or a host that is shared (not dedicated to any particular account or domain). - &PRODUCT; will generate an alert, but the operation is allowed. - Dedicated hosts can be used in conjunction with host tags. If both a host tag and dedication are requested, - the VM will be placed only on a host that meets both requirements. If there is no dedicated resource available - to that user that also has the host tag requested by the user, then the VM will not deploy. - If you delete an account or domain, any hosts, clusters, pods, and zones that were - dedicated to it are freed up. They will now be available to be shared by any account - or domain, or the administrator may choose to re-dedicate them to a different - account or domain. - System VMs and virtual routers affect the behavior of host dedication. - System VMs and virtual routers are owned by the &PRODUCT; system account, - and they can be deployed on any host. They do not adhere to explicit dedication. - The presence of system vms and virtual routers on a host makes it unsuitable for strict implicit dedication. - The host can not be used for strict implicit dedication, - because the host already has VMs of a specific account (the default system account). - However, a host with system VMs or virtual routers can be used - for preferred implicit dedication. - -

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/accounts.xml ---------------------------------------------------------------------- diff --git a/en-US/accounts.xml b/en-US/accounts.xml deleted file mode 100644 index aa62f68..0000000 --- a/en-US/accounts.xml +++ /dev/null @@ -1,29 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - - - Accounts - - - http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/f42520a5/en-US/acquire-new-ip-address.xml ---------------------------------------------------------------------- diff --git a/en-US/acquire-new-ip-address.xml b/en-US/acquire-new-ip-address.xml deleted file mode 100644 index 3dbd79e..0000000 --- a/en-US/acquire-new-ip-address.xml +++ /dev/null @@ -1,52 +0,0 @@ - - -%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. - The Acquire New IP window is displayed. - - - Specify whether you want cross-zone IP or not. - If you want Portable IP click Yes in the confirmation dialog. If you want a normal - Public IP click No. - For more information on Portable IP, see . - 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. - - -