Creating a New Network Offering

X-Mailer: ASF-Git Admin Mailer Subject: [38/51] [partial] Adding documents from 4.2 http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/creating-network-offerings.xml ---------------------------------------------------------------------- diff --git a/en-US/creating-network-offerings.xml b/en-US/creating-network-offerings.xml new file mode 100644 index 0000000..4f75781 --- /dev/null +++ b/en-US/creating-network-offerings.xml @@ -0,0 +1,285 @@ + + +%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. + + + Guest Type. Choose whether the guest network is + isolated or shared. + For a description of this term, see . + For a description of this term, see the Administration Guide. + + + + Persistent. Indicate whether the guest network is + persistent or not. The network that you can provision without having to deploy a VM on + it is termed persistent network. For more information, see . + + + Specify VLAN. (Isolated guest networks only) + Indicate whether a VLAN could be specified when this offering is used. If you select + this option and later use this network offering while creating a VPC tier or an isolated + network, you will be able to specify a VLAN ID for the network you create. + + + VPC. This option indicate whether the guest network + is Virtual Private Cloud-enabled. A Virtual Private Cloud (VPC) is a private, isolated + part of &PRODUCT;. A VPC can have its own virtual network topology that resembles a + traditional physical network. For more information on VPCs, see . + + + 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 + For more information, see . + Supported + Supported + + + DNS + For more information, see . + 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 + + + Firewall + For more information, see . + For more information, see the Administration + Guide. + 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 + For more information, see . + Supported + Not Supported + + + User Data + For more information, see . + For more information, see the Administration + Guide. + Not Supported + Supported + + + Network ACL + For more information, see . + Supported + Not Supported + + + Security Groups + For more information, 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 . + For more information, see the Administration Guide. + + + LB Isolation: Specify what type of load balancer + isolation you want for the network: Shared or Dedicated. + Dedicated: If you select dedicated LB isolation, a + dedicated load balancer device is assigned for the network from the pool of dedicated + load balancer devices provisioned in the zone. If no sufficient dedicated load balancer + devices are available in the zone, network creation fails. Dedicated device is a good + choice for the high-traffic networks that make full use of the device's + resources. + Shared: If you select shared LB isolation, a shared + load balancer device is assigned for the network from the pool of shared load balancer + devices provisioned in the zone. While provisioning &PRODUCT; picks the shared load + balancer device that is used by the least number of accounts. Once the device reaches + its maximum capacity, the device will not be allocated to a new account. + + + Mode: You can select either Inline mode or Side by + Side mode: + Inline mode: Supported only for Juniper SRX + firewall and BigF5 load balancer devices. In inline mode, a firewall device is placed in + front of a load balancing device. The firewall acts as the gateway for all the incoming + traffic, then redirect the load balancing traffic to the load balancer behind it. The + load balancer in this case will not have the direct access to the public network. + Side by Side: In side by side mode, a firewall + device is deployed in parallel with the load balancer device. So the traffic to the load + balancer public IP is not routed through the firewall, and therefore, is exposed to the + public network. + + + Associate Public IP: Select this option if you want + to assign a public IP address to the VMs deployed in the guest network. This option is + available only if + + + Guest network is shared. + + + StaticNAT is enabled. + + + Elastic IP is enabled. + + + For information on Elastic IP, see . + + + Redundant router capability: 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. When conservative mode is off, the public IP can only be used for + a single service. For example, a public IP used for a port forwarding rule cannot be + used for defining other services, such as StaticNAT or load balancing. When the conserve + mode is on, you can define more than one service on the same public IP. + + If StaticNAT is enabled, irrespective of the status of the conserve mode, no port + forwarding or load balancing rule can be created for the IP. However, you can add the + firewall rules by using the createFirewallRule command. + + + + Tags: Network tag to specify which physical network + to use. + + + Default egress policy: Configure the default policy + for firewall egress rules. Options are Allow and Deny. Default is Allow if no egress + policy is specified, which indicates that all the egress traffic is accepted when a + guest network is created from this offering. + To block the egress traffic for a guest network, select Deny. In this case, when you + configure an egress rules for an isolated guest network, rules are added to allow the + specified traffic. + + + + + Click Add. + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/creating-new-volumes.xml ---------------------------------------------------------------------- diff --git a/en-US/creating-new-volumes.xml b/en-US/creating-new-volumes.xml new file mode 100644 index 0000000..5440dc5 --- /dev/null +++ b/en-US/creating-new-volumes.xml @@ -0,0 +1,84 @@ + + +%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. +

+ Using Local Storage for Data Volumes + You can create data volumes on local storage (supported with XenServer, KVM, and VMware). + The data volume is placed on the same 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. + 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. +

+ To Create a New Volume + + + 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 + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/creating-shared-network.xml ---------------------------------------------------------------------- diff --git a/en-US/creating-shared-network.xml b/en-US/creating-shared-network.xml new file mode 100644 index 0000000..e6a018f --- /dev/null +++ b/en-US/creating-shared-network.xml @@ -0,0 +1,132 @@ + + +%BOOK_ENTITIES; +]> + + +

+ Configuring a Shared Guest Network + + + Log in to the &PRODUCT; UI as administrator. + + + In the left navigation, choose Infrastructure. + + + On Zones, click View More. + + + Click the zone to which you want to add a guest network. + + + Click the Physical Network tab. + + + Click the physical network you want to work with. + + + On the Guest node of the diagram, click Configure. + + + Click the Network tab. + + + Click Add guest network. + The Add guest network window is displayed. + + + Specify the following: + + + Name: The name of the network. This will be visible + to the user. + + + Description: The short description of the network + that can be displayed to users. + + + VLAN ID: The unique ID of the VLAN. + + + Isolated VLAN ID: The unique ID of the Secondary + Isolated VLAN. + + + Scope: The available scopes are Domain, Account, + Project, and All. + + + Domain: Selecting Domain limits the scope of + this guest network to the domain you specify. The network will not be available for + other domains. If you select Subdomain Access, the guest network is available to all + the sub domains within the selected domain. + + + Account: The account for which the guest + network is being created for. You must specify the domain the account belongs + to. + + + Project: The project for which the guest + network is being created for. You must specify the domain the project belongs + to. + + + All: The guest network is available for all the + domains, account, projects within the selected zone. + + + + + Network Offering: If the administrator has + configured multiple network offerings, select the one you want to use for this + network. + + + Gateway: The gateway that the guests should + use. + + + Netmask: The netmask in use on the subnet the + guests will use. + + + IP Range: A range of IP addresses that are + accessible from the Internet and are assigned to the guest VMs. + If one NIC is used, these IPs should be in the same CIDR in the case of IPv6. + + + IPv6 CIDR: The network prefix that defines the + guest network subnet. This is the CIDR that describes the IPv6 addresses in use in the + guest networks in this zone. To allot IP addresses from within a particular address + block, enter a CIDR. + + + Network Domain: A custom DNS suffix at the level of + a network. If you want to assign a special domain name to the guest VM network, specify + a DNS suffix. + + + + + Click OK to confirm. + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/creating-system-service-offerings.xml ---------------------------------------------------------------------- diff --git a/en-US/creating-system-service-offerings.xml b/en-US/creating-system-service-offerings.xml new file mode 100644 index 0000000..e33d9d0 --- /dev/null +++ b/en-US/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. + + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/creating-vms.xml ---------------------------------------------------------------------- diff --git a/en-US/creating-vms.xml b/en-US/creating-vms.xml new file mode 100644 index 0000000..86d05d3 --- /dev/null +++ b/en-US/creating-vms.xml @@ -0,0 +1,90 @@ + + +%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. + + 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 request parameter, startVM, in the deployVm API + provides this feature. For more information, see the Developer's Guide + + 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 zone. + + + Select a template, then follow the steps in the wizard. For more information about how + the templates came to be in this list, see . + + + 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. + + + + 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 a zone. + + + Select ISO Boot, and follow the steps in the wizard. + + + Click Submit and your VM will be created and started. + + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/customizing-dns.xml ---------------------------------------------------------------------- diff --git a/en-US/customizing-dns.xml b/en-US/customizing-dns.xml new file mode 100644 index 0000000..c24bad8 --- /dev/null +++ b/en-US/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. + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/database-replication.xml ---------------------------------------------------------------------- diff --git a/en-US/database-replication.xml b/en-US/database-replication.xml new file mode 100644 index 0000000..8ca8071 --- /dev/null +++ b/en-US/database-replication.xml @@ -0,0 +1,144 @@ + + +%BOOK_ENTITIES; +]> + + + +

+ Database Replication (Optional) + &PRODUCT; supports database replication from one MySQL node to another. This is achieved using standard MySQL replication. You may want to do this as insurance against MySQL server or storage loss. MySQL replication is implemented using a master/slave model. The master is the node that the Management Servers are configured to use. The slave is a standby node that receives all write operations from the master and applies them to a local, redundant copy of the database. The following steps are a guide to implementing MySQL replication. + Creating a replica is not a backup solution. You should develop a backup procedure for the MySQL data that is distinct from replication. + + Ensure that this is a fresh install with no data in the master. + + Edit my.cnf on the master and add the following in the [mysqld] section below datadir. + +log_bin=mysql-bin +server_id=1 + + The server_id must be unique with respect to other servers. The recommended way to achieve this is to give the master an ID of 1 and each slave a sequential number greater than 1, so that the servers are numbered 1, 2, 3, etc. + + + Restart the MySQL service. On RHEL/CentOS systems, use: + +# service mysqld restart + + On Debian/Ubuntu systems, use: + +# service mysql restart + + + + Create a replication account on the master and give it privileges. We will use the "cloud-repl" user with the password "password". This assumes that master and slave run on the 172.16.1.0/24 network. + +# mysql -u root +mysql> create user 'cloud-repl'@'172.16.1.%' identified by 'password'; +mysql> grant replication slave on *.* TO 'cloud-repl'@'172.16.1.%'; +mysql> flush privileges; +mysql> flush tables with read lock; + + + Leave the current MySQL session running. + In a new shell start a second MySQL session. + + Retrieve the current position of the database. + +# mysql -u root +mysql> show master status; ++------------------+----------+--------------+------------------+ +| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | ++------------------+----------+--------------+------------------+ +| mysql-bin.000001 | 412 | | | ++------------------+----------+--------------+------------------+ + + + Note the file and the position that are returned by your instance. + Exit from this session. + + Complete the master setup. Returning to your first session on the master, release the locks and exit MySQL. + +mysql> unlock tables; + + + + Install and configure the slave. On the slave server, run the following commands. + +# yum install mysql-server +# chkconfig mysqld on + + + + Edit my.cnf and add the following lines in the [mysqld] section below datadir. + +server_id=2 +innodb_rollback_on_timeout=1 +innodb_lock_wait_timeout=600 + + + + Restart MySQL. Use "mysqld" on RHEL/CentOS systems: + +# service mysqld restart + + On Ubuntu/Debian systems use "mysql." + +# service mysql restart + + + + Instruct the slave to connect to and replicate from the master. Replace the IP address, password, log file, and position with the values you have used in the previous steps. + +mysql> change master to + -> master_host='172.16.1.217', + -> master_user='cloud-repl', + -> master_password='password', + -> master_log_file='mysql-bin.000001', + -> master_log_pos=412; + + + + Then start replication on the slave. + +mysql> start slave; + + + + Optionally, open port 3306 on the slave as was done on the master earlier. + This is not required for replication to work. But if you choose not to do this, you will need to do it when failover to the replica occurs. + + +

+ Failover + This will provide for a replicated database that can be used to implement manual failover for the Management Servers. &PRODUCT; failover from one MySQL instance to another is performed by the administrator. In the event of a database failure you should: + + Stop the Management Servers (via service cloudstack-management stop). + Change the replica's configuration to be a master and restart it. + Ensure that the replica's port 3306 is open to the Management Servers. + Make a change so that the Management Server uses the new database. The simplest process here is to put the IP address of the new database server into each Management Server's /etc/cloudstack/management/db.properties. + + Restart the Management Servers: + +# service cloudstack-management start + + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/dates-in-usage-record.xml ---------------------------------------------------------------------- diff --git a/en-US/dates-in-usage-record.xml b/en-US/dates-in-usage-record.xml new file mode 100644 index 0000000..dc2f072 --- /dev/null +++ b/en-US/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. +

+ http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/dedicated-ha-hosts.xml ---------------------------------------------------------------------- diff --git a/en-US/dedicated-ha-hosts.xml b/en-US/dedicated-ha-hosts.xml new file mode 100644 index 0000000..89c721f --- /dev/null +++ b/en-US/dedicated-ha-hosts.xml @@ -0,0 +1,34 @@ + + +%BOOK_ENTITIES; +]> + + + +

+ Dedicated HA Hosts + 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. +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/default-account-resource-limit.xml ---------------------------------------------------------------------- diff --git a/en-US/default-account-resource-limit.xml b/en-US/default-account-resource-limit.xml new file mode 100644 index 0000000..5134e50 --- /dev/null +++ b/en-US/default-account-resource-limit.xml @@ -0,0 +1,45 @@ + + +%BOOK_ENTITIES; +]> + + +

+ Default Account Resource Limits + You can limit resource use by accounts. The default limits are set by using global + configuration parameters, and they affect all accounts within a cloud. The relevant + parameters are those beginning with max.account, for example: max.account.snapshots. + 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 + + + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/default-template.xml ---------------------------------------------------------------------- diff --git a/en-US/default-template.xml b/en-US/default-template.xml new file mode 100644 index 0000000..16442c3 --- /dev/null +++ b/en-US/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- + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/delete-event-alerts.xml ---------------------------------------------------------------------- diff --git a/en-US/delete-event-alerts.xml b/en-US/delete-event-alerts.xml new file mode 100644 index 0000000..c0d5671 --- /dev/null +++ b/en-US/delete-event-alerts.xml @@ -0,0 +1,87 @@ + + +%BOOK_ENTITIES; +]> + + +

+ Deleting and Archiving Events and Alerts + &PRODUCT; provides you the ability to delete or archive the existing alerts and events that + you no longer want to implement. You can regularly delete or archive any alerts or events that + you cannot, or do not want to resolve from the database. + You can delete or archive individual alerts or events either directly by using the Quickview + or by using the Details page. If you want to delete multiple alerts or events at the same time, + you can use the respective context menu. You can delete alerts or events by category for a time + period. For example, you can select categories such as USER.LOGOUT, VM.DESTROY, VM.AG.UPDATE, CONFIGURATION.VALUE.EDI, and so on. + You can also view the number of events or alerts archived or deleted. + In order to support the delete or archive alerts, the following global parameters have been + added: + + + alert.purge.delay: The alerts older than specified + number of days are purged. Set the value to 0 to never purge alerts automatically. + + + alert.purge.interval: The interval in seconds to wait + before running the alert purge thread. The default is 86400 seconds (one day). + + + + Archived alerts or events cannot be viewed in the UI or by using the API. They are + maintained in the database for auditing or compliance purposes. + +

+ Permissions + Consider the following: + + + The root admin can delete or archive one or multiple alerts or events. + + + The domain admin or end user can delete or archive one or multiple events. + + +

+ Procedure + + + Log in as administrator to the &PRODUCT; UI. + + + In the left navigation, click Events. + + + Perform either of the following: + + + To archive events, click Archive Events, and specify event type and date. + + + To archive events, click Delete Events, and specify event type and date. + + + + + Click OK. + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/delete-reset-vpn.xml ---------------------------------------------------------------------- diff --git a/en-US/delete-reset-vpn.xml b/en-US/delete-reset-vpn.xml new file mode 100644 index 0000000..2fe85d2 --- /dev/null +++ b/en-US/delete-reset-vpn.xml @@ -0,0 +1,107 @@ + + +%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. + For each tier, the following options are displayed: + + + Internal LB + + + Public LB IP + + + Static NAT + + + Virtual Machines + + + CIDR + + + The following router information is displayed: + + + Private Gateways + + + Public IP Addresses + + + Site-to-Site VPNs + + + Network ACL Lists + + + + + 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 + + + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/delete-templates.xml ---------------------------------------------------------------------- diff --git a/en-US/delete-templates.xml b/en-US/delete-templates.xml new file mode 100644 index 0000000..f9351da --- /dev/null +++ b/en-US/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. +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/deleting-vms.xml ---------------------------------------------------------------------- diff --git a/en-US/deleting-vms.xml b/en-US/deleting-vms.xml new file mode 100644 index 0000000..97245c8 --- /dev/null +++ b/en-US/deleting-vms.xml @@ -0,0 +1,43 @@ + + +%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 + + + + +

+ http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/dell62xx-hardware.xml ---------------------------------------------------------------------- diff --git a/en-US/dell62xx-hardware.xml b/en-US/dell62xx-hardware.xml new file mode 100644 index 0000000..8bc7770 --- /dev/null +++ b/en-US/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. + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/dell62xx-layer2.xml ---------------------------------------------------------------------- diff --git a/en-US/dell62xx-layer2.xml b/en-US/dell62xx-layer2.xml new file mode 100644 index 0000000..1c0eea0 --- /dev/null +++ b/en-US/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. + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/deployment-architecture-overview.xml ---------------------------------------------------------------------- diff --git a/en-US/deployment-architecture-overview.xml b/en-US/deployment-architecture-overview.xml new file mode 100644 index 0000000..835898c --- /dev/null +++ b/en-US/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 the "Choosing a Deployment Architecture" + section of the &PRODUCT; Installation Guide. + + + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/detach-move-volumes.xml ---------------------------------------------------------------------- diff --git a/en-US/detach-move-volumes.xml b/en-US/detach-move-volumes.xml new file mode 100644 index 0000000..8922db1 --- /dev/null +++ b/en-US/detach-move-volumes.xml @@ -0,0 +1,59 @@ + + +%BOOK_ENTITIES; +]> + + +

+ Detaching and Moving Volumes + + This procedure is different from moving volumes from one storage pool to another as described in . + + 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 . + + +

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/b23872a5/en-US/devcloud-usage-mode.xml ---------------------------------------------------------------------- diff --git a/en-US/devcloud-usage-mode.xml b/en-US/devcloud-usage-mode.xml new file mode 100644 index 0000000..bc211ce --- /dev/null +++ b/en-US/devcloud-usage-mode.xml @@ -0,0 +1,60 @@ + + +%BOOK_ENTITIES; +]> + + + +

+ DevCloud Usage Mode + DevCloud can be used in several different ways: + + + Full sandbox. Where &PRODUCT; is run within the DevCloud instance started in Virtual Box. + In this mode, the &PRODUCT; management server runs within the instance and nested virtualization allows instantiation of tiny VMs within DevCloud itself. &PRODUCT; code modifications are done within DevCloud. + The following diagram shows the architecture of the SandBox mode. + + + + + + DevCloud.png: Schematic of the DevCloud SandBox architecture + + + + + A deployment environment. Where &PRODUCT; code is developed in the localhost of the developer and the resulting build is deployed within DevCloud + This mode was used in the testing procedure of &PRODUCT; 4.0.0 incubating release. See the following screencast to see how: http://vimeo.com/54621457 + + + A host-only mode. Where DevCloud is used only as a host. &PRODUCT; management server is run in the localhost of the developer + This mode makes use of a host-only interface defined in the Virtual Box preferences. Check the following screencast to see how: http://vimeo.com/54610161 + The following schematic shows the architecture of the Host-Only mode. + + + + + + DevCloud-hostonly.png: Schematic of the DevCloud host-only architecture + + + + +