You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by sh...@apache.org on 2023/11/07 12:43:53 UTC
(cloudstack-documentation) branch main updated: Polish (#339)
This is an automated email from the ASF dual-hosted git repository.
shwstppr pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/cloudstack-documentation.git
The following commit(s) were added to refs/heads/main by this push:
new 00d91df Polish (#339)
00d91df is described below
commit 00d91dfb1f3c1d8888d616f3f0d08088b78befa9
Author: vladimirpetrov <vl...@gmail.com>
AuthorDate: Tue Nov 7 14:43:47 2023 +0200
Polish (#339)
Capitalisation of known object/resource types: Templates, Network, Snapshot, User, Account, fixing many typos and grammar mistakes.
---
source/adminguide/accounts.rst | 324 ++++----
source/adminguide/administration.rst | 24 +-
source/adminguide/api.rst | 32 +-
.../adminguide/autoscale_with_virtual_router.rst | 220 +++--
source/adminguide/autoscale_without_netscaler.rst | 67 +-
source/adminguide/backup_and_recovery.rst | 74 +-
source/adminguide/events.rst | 18 +-
source/adminguide/guest_os.rst | 4 +-
source/adminguide/hosts.rst | 90 +-
source/adminguide/index.rst | 8 +-
.../locale/pot/networking/persistent_networks.pot | 2 +-
source/adminguide/management.rst | 60 +-
source/adminguide/networker_plugin.rst | 18 +-
source/adminguide/networking.rst | 40 +-
.../adminguide/networking/advanced_zone_config.rst | 120 +--
source/adminguide/networking/basic_zone_config.rst | 2 +-
source/adminguide/networking/elastic_ips.rst | 30 +-
.../external_firewalls_and_load_balancers.rst | 148 ++--
.../networking/global_server_load_balancing.rst | 8 +-
source/adminguide/networking/guest_traffic.rst | 12 +-
.../adminguide/networking/inter_vlan_routing.rst | 22 +-
.../networking/ip_forwarding_and_firewalling.rst | 20 +-
.../ip_reservation_in_guest_networks.rst | 50 +-
.../networking/manage_guest_networks.rst | 20 +-
.../networking/multiple_guest_networks.rst | 32 +-
.../networking/multiple_ips_on_single_nic.rst | 22 +-
.../multiple_subnets_in_shared_network.rst | 16 +-
.../adminguide/networking/network_permissions.rst | 42 +-
.../adminguide/networking/persistent_networks.rst | 20 +-
source/adminguide/networking/portable_ips.rst | 6 +-
source/adminguide/networking/remote_access_vpn.rst | 10 +-
.../networking/reserving_an_ip_address.rst | 2 +-
source/adminguide/networking/security_groups.rst | 36 +-
source/adminguide/networking/site_to_site_vpn.rst | 28 +-
source/adminguide/networking/static_nat.rst | 6 +-
.../adminguide/networking/using_remote_access.rst | 2 +-
.../networking/virtual_private_cloud_config.rst | 334 ++++----
source/adminguide/networking_and_traffic.rst | 2 +-
source/adminguide/projects.rst | 115 ++-
source/adminguide/reliability.rst | 86 +-
source/adminguide/service_offerings.rst | 100 +--
source/adminguide/storage.rst | 354 ++++----
source/adminguide/systemvm.rst | 80 +-
source/adminguide/templates.rst | 278 +++----
.../templates/_bypass-secondary-storage-kvm.rst | 24 +-
source/adminguide/templates/_cloud_init.rst | 18 +-
source/adminguide/templates/_convert_hyperv.rst | 38 +-
source/adminguide/templates/_create_linux.rst | 48 +-
source/adminguide/templates/_create_windows.rst | 26 +-
source/adminguide/templates/_import_ami.rst | 2 +-
source/adminguide/templates/_password.rst | 14 +-
source/adminguide/troubleshooting.rst | 34 +-
source/adminguide/tuning.rst | 26 +-
source/adminguide/ui.rst | 54 +-
source/adminguide/usage.rst | 410 ++++-----
source/adminguide/veeam_plugin.rst | 34 +-
source/adminguide/virtual_machines.rst | 925 ++++++++++-----------
.../virtual_machines/importing_unmanaging_vms.rst | 240 +++---
source/adminguide/virtual_machines/user-data.rst | 48 +-
.../virtual_machines/virtual_appliances.rst | 18 +-
.../choosing_deployment_architecture.rst | 120 +--
source/conceptsandterminology/concepts.rst | 146 ++--
source/conceptsandterminology/index.rst | 2 +-
source/conceptsandterminology/network_setup.rst | 54 +-
source/conceptsandterminology/storage_setup.rst | 30 +-
source/developersguide/alloc.rst | 58 +-
source/developersguide/ansible.rst | 14 +-
source/developersguide/dev.rst | 40 +-
source/developersguide/developer_guide.rst | 10 +-
source/developersguide/plugins.rst | 14 +-
source/installguide/building_from_source.rst | 4 +-
source/installguide/configuration.rst | 122 +--
source/installguide/encryption.rst | 20 +-
source/installguide/hypervisor/hyperv.rst | 4 +-
source/installguide/hypervisor/kvm.rst | 46 +-
source/installguide/hypervisor/lxc.rst | 16 +-
source/installguide/hypervisor/vsphere.rst | 28 +-
source/installguide/hypervisor/xenserver.rst | 42 +-
.../locale/pot/hypervisor_installation.pot | 2 +-
.../installguide/management-server/_database.rst | 14 +-
source/installguide/management-server/_nfs.rst | 2 +-
.../installguide/management-server/_systemvm.rst | 13 +-
source/installguide/management-server/index.rst | 2 +-
source/installguide/optional_installation.rst | 26 +-
source/installguide/overview/_overview.rst | 2 +-
source/installguide/overview/_requirements.rst | 2 +-
source/plugins/cloudian-connector.rst | 28 +-
source/plugins/cloudstack-kubernetes-provider.rst | 4 +-
source/plugins/cloudstack-kubernetes-service.rst | 46 +-
source/plugins/ipv6.rst | 64 +-
source/plugins/midonet.rst | 18 +-
source/plugins/nicira-plugin.rst | 36 +-
source/plugins/ovs-plugin.rst | 92 +-
source/plugins/quota.rst | 34 +-
source/plugins/vxlan.rst | 36 +-
source/quickinstallationguide/qig.rst | 40 +-
source/releasenotes/api-changes.rst | 34 +-
source/releasenotes/compat.rst | 6 +-
source/upgrading/index.rst | 10 +-
source/upgrading/upgrade/_no-sysvm_templates.rst | 2 +-
source/upgrading/upgrade/_sysvm_manual_hotfix.rst | 18 +-
source/upgrading/upgrade/_sysvm_restart.rst | 30 +-
source/upgrading/upgrade/_sysvm_templates.rst | 16 +-
.../upgrading/upgrade/_sysvm_templates_pre45.rst | 22 +-
source/upgrading/upgrade/_xenserver_upg.rst | 4 +-
source/upgrading/upgrade/mysql.rst | 2 +-
source/upgrading/upgrade/upgrade-4.10.rst | 6 +-
source/upgrading/upgrade/upgrade-4.11.rst | 8 +-
source/upgrading/upgrade/upgrade-4.12.rst | 8 +-
source/upgrading/upgrade/upgrade-4.13.rst | 8 +-
source/upgrading/upgrade/upgrade-4.14.rst | 8 +-
source/upgrading/upgrade/upgrade-4.15.rst | 8 +-
source/upgrading/upgrade/upgrade-4.16.rst | 8 +-
source/upgrading/upgrade/upgrade-4.17.rst | 4 +-
source/upgrading/upgrade/upgrade-4.2.rst | 2 +-
source/upgrading/upgrade/upgrade-4.3.rst | 2 +-
source/upgrading/upgrade/upgrade-4.4.rst | 2 +-
source/upgrading/upgrade/upgrade-4.5.rst | 6 +-
source/upgrading/upgrade/upgrade-4.9.rst | 8 +-
source/upgrading/upgrade/upgrade_notes.rst | 8 +-
120 files changed, 3202 insertions(+), 3202 deletions(-)
diff --git a/source/adminguide/accounts.rst b/source/adminguide/accounts.rst
index a06656f..cbd705d 100644
--- a/source/adminguide/accounts.rst
+++ b/source/adminguide/accounts.rst
@@ -20,10 +20,10 @@ Roles, Accounts, Users, and Domains
Roles
~~~~~
-A role represents a set of allowed functions. All CloudStack accounts have a
+A role represents a set of allowed functions. All CloudStack Accounts have a
role attached to them that enforce access rules on them to be allowed or
disallowed to make an API request. Typically there are four default roles:
-root admin, resource admin, domain admin and user.
+root admin, resource admin, domain admin and User.
Newer roles have been added which include Read-Only Admin, Read-Only User,
Support Admin and Support User which are in turn based on the aforementioned roles.
@@ -31,48 +31,48 @@ Support Admin and Support User which are in turn based on the aforementioned rol
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.
+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
+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.
-Beside the Root Administrator type of account (available in the root domain only), two different types
-of accounts can be created for each domain: Domain Administrator and User.
+Beside the Root Administrator type of Account (available in the root domain only), two different types
+of Accounts can be created for each domain: 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.
+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 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
+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
+or delete other administrators, and change the password for any User in
the system.
Domain Administrators
~~~~~~~~~~~~~~~~~~~~~
-Domain administrators can perform administrative operations for users
+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.
@@ -81,49 +81,49 @@ Root Administrator
~~~~~~~~~~~~~~~~~~
Root administrators have complete access to the system, including
-managing templates, service offerings, customer care administrators, and
+managing Templates, service offerings, customer care administrators, and
domains
Read Only Administrator
~~~~~~~~~~~~~~~~~~~~~~~
-A restricted admin role in which an account is only allowed to perform any list, get
+A restricted admin role in which an Account is only allowed to perform any list, get
or find operations but not perform any other operation which can change the
-infrastructure, configuration or user resources.
+infrastructure, configuration or User resources.
Read Only User
~~~~~~~~~~~~~~
-A restricted user role in which an account is only allowed to perform list, get or find
-operations. It can be used by users who may only be interested in monitoring and usage
+A restricted User role in which an Account is only allowed to perform list, get or find
+operations. It can be used by Users who may only be interested in monitoring and usage
of resources.
Support Admin
~~~~~~~~~~~~~
-A restricted admin role in which an admin account is limited to perform axilary support
-and maintenance tasks which do not directly affect the infrastucture, such as creating offerings,
+A restricted admin role in which an admin Account is limited to perform auxiliary support
+and maintenance tasks which do not directly affect the infrastructure, such as creating offerings,
and put resources in maintenance, but cannot change the infrastructure such as physical networks.
Support User
~~~~~~~~~~~~
-A restricted user role in which an account cannot create or destroy resources, but can view resources
-and perform auxilary and support operations such as start or stop VMs, attach or detach volumes, ISOs etc.
+A restricted User role in which an Account cannot create or destroy resources, but can view resources
+and perform auxiliary and support operations such as start or stop Instances, attach or detach volumes, ISOs etc.
Resource Ownership
~~~~~~~~~~~~~~~~~~
-Resources belong to the account, not individual users in that account.
+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
+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.
+the ownership of any Instance from one Account to any other
+Account by using the assignVirtualMachine API. A domain or sub-domain
+administrator can do the same for Instances within the domain from one Account
+to any other Account in the domain or any of its sub-domains.
.. _using-dynamics-roles:
@@ -135,24 +135,24 @@ allows CloudStack root admins to create new roles with customized permissions.
The allow/deny rules can be configured dynamically during runtime without
restarting the management server(s).
-.. Note:: in versions before 4.16.1, any user given the custom roles
- that include permission to create and/or update accounts
+.. Note:: in versions before 4.16.1, any User given the custom roles
+ that include permission to create and/or update Accounts
will have the ability to assign new custom roles to
- themsevles or other users, irrespective of the privileges
- given in those roles. This could allow such a user to
+ themselves or other Users, irrespective of the privileges
+ given in those roles. This could allow such a User to
escalate their own privileges to include any API they might
not have had before. Therefore, the dynamic roles should be
carefully designed and the `createAccount` and
- `updateAccount` privileges should only be given to users who
+ `updateAccount` privileges should only be given to Users who
you are content to have this level of privilege.
- Since 4.16.1 a user will be prevented to create an account
+ Since 4.16.1 a User will be prevented to create an Account
with a role that has any permissions that they do not have
themselves. This check will also be performed, since that
- version, on updating an account-role.
+ version, on updating an Account-role.
-For backward compatiblity, all roles resolve to one of the four role types:
-admin, resource admin, domain admin and user. A new role can be created using
+For backward compatibility, all roles resolve to one of the four role types:
+admin, resource admin, domain admin and User. A new role can be created using
the roles tab in the UI and specifying a name, either a role type or ID of existing
role, and optionally a description. When a new role is created using ID of existing
role, all the rules of the existing role are copied to the new role and these rules
@@ -175,16 +175,16 @@ CSV file format:
…
so on
-When a user makes an API request, the backend checks the requested API against
+When a User makes an API request, the backend checks the requested API against
configured rules (in the order the rules were configured) for the caller
-user-account's role. It will iterate through the rules and would allow the
+User-Account's role. It will iterate through the rules and would allow the
API request if the API matches an allow rule, else if it matches a deny rule
it would deny the request. Next, if the request API fails to match any of
the configured rules it would allow if the requested API's default authorized
-annotaions allow that user role type and finally deny the user API request
+annotations allow that User role type and finally deny the User API request
if it fails to be explicitly allowed/denied by the role permission rules or the
default API authorize annotations. Note: to avoid root admin being locked
-out of the system, all root admin accounts are allowed all APIs.
+out of the system, all root admin Accounts are allowed all APIs.
The dynamic-roles feature is enabled by default only for all new CloudStack
installations since version `4.9.x <https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+Role+Based+API+Access+Checker+for+CloudStack>`_.
@@ -244,27 +244,27 @@ 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
+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
+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
+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
+ 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
+ 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
+ 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
+- Preferred implicit dedication. The Instance will be deployed in dedicated
+ infrastructure if possible. Otherwise, the Instance can be deployed in
shared infrastructure.
@@ -273,7 +273,7 @@ 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.
+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
@@ -284,7 +284,7 @@ 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
+resources are not available. Whenever a User creates an Instance based on this
service offering, it is allocated on one of the dedicated hosts.
@@ -293,39 +293,39 @@ How to Use Dedicated Hosts
To use an explicitly dedicated host, use the explicit-dedicated type of
affinity group (see `“Affinity Groups” <virtual_machines.html#affinity-groups>`_).
-For example, when creating a new VM, an
-end user can choose to place it on dedicated infrastructure. This
+For example, when creating a new Instance, 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.
+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
+The administrator can live migrate Instances away from dedicated hosts if
desired, whether the destination is a host reserved for a different
-account/domain or a host that is shared (not dedicated to any particular
-account or domain). CloudStack will generate an alert, but the operation
+Account/domain or a host that is shared (not dedicated to any particular
+Account or domain). CloudStack will generate an alert, but the operation
is allowed.
Dedicated hosts can be used in conjunction with host tags. If both a
-host tag and dedication are requested, the VM will be placed only on a
+host tag and dedication are requested, the Instance 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.
+available to that User that also has the host tag requested by the User,
+then the Instance will not deploy.
-If you delete an account or domain, any hosts, clusters, pods, and zones
+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.
+shared by any Account or domain, or the administrator may choose to
+re-dedicate them to a different Account or domain.
System VMs and virtual routers affect the behavior of host dedication.
System VMs and virtual routers are owned by the CloudStack system
-account, and they can be deployed on any host. They do not adhere to
-explicit dedication. The presence of system vms and virtual routers on a
+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
+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.
@@ -336,74 +336,74 @@ 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. CloudStack will search
the external LDAP directory tree starting at a specified base directory
-and gets user info such as first name, last name, email and username.
+and gets User info such as first name, last name, email and username.
Starting with CloudStack 4.11, an LDAP connection per domain can be
-defined. In this domain autosync per account can be configured,
-keeping the users in the domain up to date with their group membership
+defined. In this domain autosync per Account can be configured,
+keeping the Users in the domain up to date with their group membership
in LDAP.
.. Note:: A caveat with this is that ApacheDS does not yet support the
- virtual 'memberOf' attribute needed to check if a user moved
- to another account. Microsoft AD and OpenLDAP as well as
+ virtual 'memberOf' attribute needed to check if a User moved
+ to another Account. Microsoft AD and OpenLDAP as well as
OpenDJ do support this. It is a planned feature for ApacheDS
that can be tracked in
https://issues.apache.org/jira/browse/DIRSERVER-1844.
-There are now three ways to link LDAP users to CloudStack users. These
+There are now three ways to link LDAP Users to CloudStack Users. These
three ways where developed as extensions on top of each other.
To authenticate, in all three cases username and password entered by
-the user are used.
+the User are used.
-#. **manual import**. A user is explicitely mapped to a domain/account
- and created as a user in that account.
+#. **manual import**. A User is explicitly mapped to a domain/Account
+ and created as a User in that Account.
- #. CloudStack does a search for a user with the given username.
+ #. CloudStack does a search for a User with the given username.
- #. If it exists, it checks if the user is enabled.
+ #. If it exists, it checks if the User is enabled.
- #. If the user is enabled, CloudStack searches for it in LDAP
+ #. If the User is enabled, CloudStack searches for it in LDAP
by the configured ``ldap.username.attribute``.
- #. If the LDAP user is found, CloudStack does a bind request
- with the returned principal for that LDAP user and the
+ #. If the LDAP User is found, CloudStack does a bind request
+ with the returned principal for that LDAP User and the
entered password.
#. The authentication result from LAP is honoured.
-#. **autoimport**. A domain is configured to import any user if it
- does not yet exist in that domain. For these users, an account in the
- same name as the user is automatically created and the user is created
- in that account.
+#. **autoimport**. A domain is configured to import any User if it
+ does not yet exist in that domain. For these Users, an Account in the
+ same name as the User is automatically created and the User is created
+ in that Account.
#. If the domain is configured to be used with LDAP,
#. CloudStack searches for it in LDAP by the configured
``ldap.username.attribute``.
- #. If an LDAP user is found, CloudStack does a bind
- request with the returned principal for that LDAP user and
+ #. If an LDAP User is found, CloudStack does a bind
+ request with the returned principal for that LDAP User and
the entered password.
#. If LDAP authentication checks out, CloudStack checks if the
- authenticated user exists in the domain it is trying to log
+ authenticated User exists in the domain it is trying to log
on to.
- #. If the user exists in CloudStack, it is ensured to be enabled.
+ #. If the User exists in CloudStack, it is ensured to be enabled.
- #. If it doesn't exist it is created in a new account with
- the username as names for both account and user.
+ #. If it doesn't exist it is created in a new Account with
+ the username as names for both Account and User.
- #. In case authentication fails the user will be disabled in
+ #. In case authentication fails the User will be disabled in
cloudstack after the configured
``incorrect.login.attempts.allowed`` number of attempts.
#. **autosync**. A domain is configured to use a LDAP server and in this
- domain a number of accounts are 'mapped' against LDAP groups. Any
- user that is in one of these configured accounts will be checked against the
+ domain a number of Accounts are 'mapped' against LDAP groups. Any
+ User that is in one of these configured Accounts will be checked against the
current state of LDAP and if they exist they will be asserted to be
- in the right account according to their LDAP group. If they do not
+ in the right Account according to their LDAP group. If they do not
exist in LDAP they will be disabled in CloudStack.
#. If the domain is configured to be used by LDAP,
@@ -411,21 +411,21 @@ the user are used.
#. CloudStack searches for it in LDAP by the configured
``ldap.username.attribute``.
- #. If an LDAP user is found, it is checked for
- memberships of mapped account, i.e. accounts for which LDAP
+ #. If an LDAP User is found, it is checked for
+ memberships of mapped Account, i.e. Accounts for which LDAP
groups are configured.
- #. If the LDAP user has 0, 2 or more memberships the account
+ #. If the LDAP User has 0, 2 or more memberships the Account
is disabled and authentication fails.
#. CloudStack then does a bind request with the returned
- principal for that LDAP user and the entered password.
+ principal for that LDAP User and the entered password.
- #. If no CloudStack user exists it is created in the
- appropriate account.
+ #. If no CloudStack User exists it is created in the
+ appropriate Account.
- #. If a CloudStack user exists but is not in the appropriate
- account its credentials will be moved.
+ #. If a CloudStack User exists but is not in the appropriate
+ Account its credentials will be moved.
To set up LDAP authentication in CloudStack, call the CloudStack API
command ``addLdapConfiguration`` and provide Hostname or IP address
@@ -440,8 +440,8 @@ replicas. If one fails, the next one is used.
port=389\
domainid=12345678-90ab-cdef-fedc-ba0987654321
-This is all that is required to enable the manual importing of LDAP users, the
-LisLdapUsers API can be used to query for users to import.
+This is all that is required to enable the manual importing of LDAP Users, the
+LisLdapUsers API can be used to query for Users to import.
For the auto import method, a CloudStack Domain needs to be linked to
LDAP. For instance
@@ -454,7 +454,7 @@ LDAP. For instance
type=OU
When you want to use auto sync, no domain is linked to ldap but one or
-more accounts. Within a CloudStack domain one needs to link accounts
+more Accounts. Within a CloudStack domain one needs to link Accounts
to LDAP groups. The linkage of the domain is implicit and nit needed
to be applied through the API call described above.
@@ -464,7 +464,7 @@ to be applied through the API call described above.
[ -z "$LDAP1PASSWORD" -o -z "$LDAP2PASSWORD" ] && exit 1
ROOTDOMAIN=`cloudmonkey -d json list domains name=ROOT filter=id | jq .domain[0].id`
- # mapping domain and account(s) from ldap server 1
+ # mapping domain and Account(s) from ldap server 1
MAPPEDDOMAIN1=`cloudmonkey -d json create domain name=mappedDomain1 parentdomainid=$ROOTDOMAIN | jq .domain.id`
cloudmonkey -d json add ldapconfiguration hostname=10.1.2.5 port=389 domainid=$MAPPEDDOMAIN1
cloudmonkey -d json update configuration domainid=$MAPPEDDOMAIN1 name="ldap.basedn" value="dc=cloudstack,dc=apache,dc=org"
@@ -486,30 +486,30 @@ openldap)
- ``ldap.basedn``: Sets the basedn for LDAP. Ex: **OU=APAC,DC=company,DC=com**
-- ``ldap.bind.principal``, ``ldap.bind.password``: DN and password for a user
- who can list all the users in the above basedn. Ex:
+- ``ldap.bind.principal``, ``ldap.bind.password``: DN and password for a User
+ who can list all the Users in the above basedn. Ex:
**CN=Administrator, OU=APAC, DC=company, DC=com**
-- ``ldap.user.object``: object type of users within LDAP. Defaults value is
+- ``ldap.user.object``: object type of Users within LDAP. Defaults value is
**user** for AD and **interorgperson** for openldap.
-- ``ldap.email.attribute``: email attribute within ldap for a user. Default
+- ``ldap.email.attribute``: email attribute within ldap for a User. Default
value for AD and openldap is **mail**.
-- ``ldap.firstname.attribute``: firstname attribute within ldap for a user.
+- ``ldap.firstname.attribute``: firstname attribute within ldap for a User.
Default value for AD and openldap is **givenname**.
-- ``ldap.lastname.attribute``: lastname attribute within ldap for a user.
+- ``ldap.lastname.attribute``: lastname attribute within ldap for a User.
Default value for AD and openldap is **sn**.
-- ``ldap.username.attribute``: username attribute for a user within LDAP.
+- ``ldap.username.attribute``: username attribute for a User within LDAP.
Default value is **SAMAccountName** for AD and **uid** for openldap.
-Restricting LDAP users to a group:
+Restricting LDAP Users to a group:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ``ldap.search.group.principle``: this is optional and if set only users from
+- ``ldap.search.group.principle``: this is optional and if set only Users from
this group are listed.
@@ -534,18 +534,18 @@ LDAP groups:
Default value is **member** for AD and **uniquemember** for openldap.
Once configured, on Add Account page, you will see an "Add LDAP Account" button
-which opens a dialog and the selected users can be imported.
+which opens a dialog and the selected Users can be imported.
.. figure:: /_static/images/CloudStack-ldap-screen1.png
:align: center
You could also use api commands:
-``listLdapUsers``, to list users in LDAP that could or would be imported in CloudStack
-``ldapCreateAccount``, to manually create a user in a specific account
-``importLdapUsers``, to batch import users from LDAP
+``listLdapUsers``, to list Users in LDAP that could or would be imported in CloudStack
+``ldapCreateAccount``, to manually create a User in a specific Account
+``importLdapUsers``, to batch import Users from LDAP
-Once LDAP is enabled, the users will not be allowed to changed password
+Once LDAP is enabled, the Users will not be allowed to changed password
directly in CloudStack.
.. |button to dedicate a zone, pod,cluster, or host| image:: /_static/images/dedicate-resource-button.png
@@ -553,18 +553,18 @@ directly in CloudStack.
Using a SAML 2.0 Identity Provider for User Authentication
----------------------------------------------------------
-You can use a SAML 2.0 Identity Provider with CloudStack for user
+You can use a SAML 2.0 Identity Provider with CloudStack for User
authentication. This will require enabling the SAML 2.0 service provider plugin
in CloudStack. To do that first, enable the SAML plugin by setting
``saml2.enabled`` to ``true`` and restart management server.
-Starting 4.5.2, the SAML plugin uses an authorization workflow where users should
-be authorized by an admin using ``authorizeSamlSso`` API before those users can
+Starting 4.5.2, the SAML plugin uses an authorization workflow where Users should
+be authorized by an admin using ``authorizeSamlSso`` API before those Users can
use Single Sign On against a specific IDP. This can be done by ticking the enable
-SAML Single Sign On checkbox and selecting a IDP when adding or importing users.
-For existing users, admin can go to the user's page and click on configure
-SAML SSO option to enable/disable SSO for a user and select a Identity Provider.
-A user can be authorized to authenticate against only one IDP.
+SAML Single Sign On checkbox and selecting a IDP when adding or importing Users.
+For existing Users, admin can go to the User's page and click on configure
+SAML SSO option to enable/disable SSO for a User and select a Identity Provider.
+A User can be authorized to authenticate against only one IDP.
The CloudStack service provider metadata is accessible using the
``getSPMetadata`` API command, or from the URL
@@ -572,25 +572,25 @@ http://acs-server:8080/client/api?command=getSPMetadata where acs-server is the
domain name or IP address of the management server. The IDP administrator can
get the SP metadata from CloudStack and add it to their IDP server.
-To start a SAML 2.0 Single Sign-On authentication, on the login page users need to
+To start a SAML 2.0 Single Sign-On authentication, on the login page Users need to
select the Identity Provider or Institution/Department they can authenticate with
and click on Login button. This action call the ``samlsso`` API command which
-will redirect the user to the Identity Provider's login page. Upon successful
-authentication, the IdP will redirect the user to CloudStack. In case a user has
-multiple user accounts with the same username (across domains) for the same
-authorized IDP, that user would need to specify domainpath after selecting their
-IDP server from the dropdown list. By default, users don't need to specify any
-domain path. After a user is successfully authenticated by an IDP server, the SAML
-authentication plugin finds user accounts whose username match the username
+will redirect the User to the Identity Provider's login page. Upon successful
+authentication, the IdP will redirect the User to CloudStack. In case a User has
+multiple User Accounts with the same username (across domains) for the same
+authorized IDP, that User would need to specify domainpath after selecting their
+IDP server from the dropdown list. By default, Users don't need to specify any
+domain path. After a User is successfully authenticated by an IDP server, the SAML
+authentication plugin finds User Accounts whose username match the username
attribute value returned by the SAML authentication response; it fails
-only when it finds that there are multiple user accounts with the same user name
+only when it finds that there are multiple User Accounts with the same User name
for the specific IDP otherwise the unique useraccount is allowed to proceed and
-the user is logged into their account.
+the User is logged into their Account.
Limitations:
-- The plugin uses a user attribute returned by the IDP server in the SAML response
- to find and map the authorized user in CloudStack. The default attribute is `uid`.
+- The plugin uses a User attribute returned by the IDP server in the SAML response
+ to find and map the authorized User in CloudStack. The default attribute is `uid`.
- The SAML authentication plugin supports HTTP-Redirect and HTTP-Post bindings.
@@ -715,7 +715,7 @@ has to be provided in the login form and then click on OAuth login.
Using Two Factor Authentication For Users
------------------------------------------
-CloudStack supports two factor authentication wherein users need to provide a 2FA code after the
+CloudStack supports two factor authentication wherein Users need to provide a 2FA code after the
regular login using username and password. CloudStack currently supports Google Authenticator or
other TOTP authenticators and static PIN as the 2FA providers. Other 2FA providers can be easily
integrated with CloudStack using its plugin model.
@@ -731,27 +731,27 @@ For admins, the following are the settings available at global and domain level
Global setting Default values Description
================================================ ================ ===================================================================
enable.user.2fa false Determines whether 2FA is enabled or not
-mandate.user.2fa false Determines whether to make the 2FA mandatory or not for the users
-user.2fa.default.provider totp The default user 2FA provider plugin. Eg. totp, staticpin
+mandate.user.2fa false Determines whether to make the 2FA mandatory or not for the Users
+user.2fa.default.provider totp The default User 2FA provider plugin. Eg. totp, staticpin
================================================ ================ ===================================================================
-If 2FA is configured for the user, the 2FA verification page looks like below after the login.
+If 2FA is configured for the User, the 2FA verification page looks like below after the login.
-The verification page when the user configures 2FA using Google or other TOTP Authenticators.
+The verification page when the User configures 2FA using Google or other TOTP Authenticators.
.. image:: /_static/images/verify-2fa-totp.png
:width: 400px
:align: center
:alt: Verify 2FA page using TOTP
-The verification page when the user configures 2FA using Static PIN.
+The verification page when the User configures 2FA using Static PIN.
.. image:: /_static/images/verify-2fa-staticpin.png
:width: 400px
:align: center
:alt: Verify 2FA page using static PIN
-Users can configure 2FA in CloudStack using the action button in user form.
+Users can configure 2FA in CloudStack using the action button in User form.
.. image:: /_static/images/configure-2fa-action-button.png
:width: 400px
@@ -759,12 +759,12 @@ Users can configure 2FA in CloudStack using the action button in user form.
:alt: Configure 2FA action button
-In the 2FA setup form, the user needs to select one of the providers. CloudStack currently supports
+In the 2FA setup form, the User needs to select one of the providers. CloudStack currently supports
Google Authenticator or other TOTP Authenticators and static PIN as the 2FA providers.
-When the Google Authenticator or other TOTP 2FA provider is selected, the user must setup the account in
+When the Google Authenticator or other TOTP 2FA provider is selected, the User must setup the Account in
the respective application in their device by either scanning the QR code or using the setup key provided
-by CloudStack. Once this is set up in the authenticator application, the user must always use the provided
+by CloudStack. Once this is set up in the authenticator application, the User must always use the provided
2FA codes to log in.
.. image:: /_static/images/configure-google-2fa-form.png
@@ -773,18 +773,18 @@ by CloudStack. Once this is set up in the authenticator application, the user mu
:alt: Configure Google 2FA form
-When the static PIN 2FA provider is selected, the user must use the static PIN as the code to verify 2FA
-with CloudStack. The user must input this static PIN as a 2FA code every time they need to login.
+When the static PIN 2FA provider is selected, the User must use the static PIN as the code to verify 2FA
+with CloudStack. The User must input this static PIN as a 2FA code every time they need to login.
.. image:: /_static/images/configure-staticpin-2fa-form.png
:width: 400px
:align: center
:alt: Configure static PIN 2FA form
-The admin has the capability to mandate 2FA for users via the setting ``mandate.user.2fa``.
-In this case the user must configure 2FA during their first login into CloudStack.
+The admin has the capability to mandate 2FA for Users via the setting ``mandate.user.2fa``.
+In this case the User must configure 2FA during their first login into CloudStack.
-The user's first login page to configure 2FA looks like the below.
+The User's first login page to configure 2FA looks like the below.
.. image:: /_static/images/configure-2fa-at-login-page.png
:width: 400px
@@ -792,9 +792,9 @@ The user's first login page to configure 2FA looks like the below.
:alt: Configure 2FA at login page
-For the existing users, the admin can mandate 2FA using the 'updateUser' API with the parameter 'mandate2FA'.
+For the existing Users, the admin can mandate 2FA using the 'updateUser' API with the parameter 'mandate2FA'.
-The admin can also disable 2FA for a user using the action button as shown below.
+The admin can also disable 2FA for a User using the action button as shown below.
.. image:: /_static/images/disable-2fa.png
:width: 400px
@@ -802,7 +802,7 @@ The admin can also disable 2FA for a user using the action button as shown below
:alt: Disable 2FA action button
.. Note:: [2FA Recovery process] :
- If the user loses the authenticator application or forgets the static PIN, then the user must
+ If the User loses the authenticator application or forgets the static PIN, then the User must
contact admin to disable 2FA.
If the admin themself loses the authenticator application or forgets the static PIN, then the admin
will have to either use apikey to disable 2FA using the API setupUserTwoFactorAuthentication with
diff --git a/source/adminguide/administration.rst b/source/adminguide/administration.rst
index 4baa17f..908d07c 100644
--- a/source/adminguide/administration.rst
+++ b/source/adminguide/administration.rst
@@ -18,14 +18,14 @@ User Services
=============
In addition to the physical and logical infrastructure of your cloud and
-the CloudStack software and servers, you also need a layer of user
+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
+not just a User UI, but a set of options and resources that Users can
+choose from, such as Templates for creating Instances, 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
+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
+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.
@@ -33,9 +33,9 @@ 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
+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:
+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,
@@ -46,16 +46,16 @@ present users with choices when creating a new instance:
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
+ 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.
+ 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
+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
diff --git a/source/adminguide/api.rst b/source/adminguide/api.rst
index e4e4e44..2f65f4f 100644
--- a/source/adminguide/api.rst
+++ b/source/adminguide/api.rst
@@ -54,7 +54,7 @@ User Data and Meta Data Via Virtual Router
CloudStack provides API access to attach up to 32KB of user data to a
-deployed VM. Deployed VMs also have access to instance metadata via the
+deployed Instance. Deployed Instances also have access to metadata via the
virtual router.
User data can be accessed once the IP address of the virtual router is
@@ -75,41 +75,41 @@ 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
+- service-offering. A description of the Instance service offering
- availability-zone. The Zone name
-- local-ipv4. The guest IP of the VM
+- local-ipv4. The guest IP of the Instance
-- local-hostname. The hostname of the VM
+- local-hostname. The hostname of the Instance
- 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
+- instance-id. The Instance name
User Data and Meta Data via Config Drive
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Config drive is an ISO file that is mounted as a cd-rom on a user VM and
-contains the user VM related userdata, metadata (incl. ssh-keys) and
+Config drive is an ISO file that is mounted as a cd-rom on a user Instance and
+contains related userdata, metadata (incl. ssh-keys) and
password files.
Enable config drive
~~~~~~~~~~~~~~~~~~~
-To use the config drive the network offering must have the “ConfigDrive”
+To use the config drive the Network offering must have the “ConfigDrive”
provider selected for the userdata service.
-If the networkoffering uses ConfigDrive for userdata and the template is
-password enabled, the password string for the VM is placed in the
+If the networkoffering uses ConfigDrive for userdata and the Template is
+password enabled, the password string for the Instance is placed in the
vm_password.txt file and it is included in the ISO.
ConfigDrive availability
~~~~~~~~~~~~~~~~~~~~~~~~
-At VM start the config drive ISO is attached on the 2nd cd/dvd drive of the
-user instance, such that any other ISO image (e.g. boot image or vmware tools)
+At Instance start the config drive ISO is attached on the 2nd cd/dvd drive of the
+user Instance, such that any other ISO image (e.g. boot image or vmware tools)
is mounted on 1st cd/dvd drive. This means existing functionality of
supporting 1 cd rom drive is still available.
@@ -118,10 +118,10 @@ will be rebuilt. The existing ISO is mounted on a temporary directory,
password, userdata or ssh-keys are updated and a new ISO is built from the
updated directory structure.
-In case of a password reset, the new password will be picked-up at VM start.
+In case of a password reset, the new password will be picked-up at Instance start.
To access the updated userdata, the user needs to remount the config drive ISO.
-When a VM is stopped, the ConfigDrive network element will trigger the
+When an Instance is stopped, the ConfigDrive network element will trigger the
Secondary Storage VM to remove the ISO from the secondary storage.
If the config drive is stored on primary storage, the network element will
trigger the host to remove the ISO.
@@ -133,7 +133,7 @@ supported with use of the KVM Hypervisor.
Supporting ConfigDrive
~~~~~~~~~~~~~~~~~~~~~~
-Extra data is added to the VM profile to enable the creation of the config drive:
+Extra data is added to the Instance profile to enable the creation of the config drive:
VMdata - a list of String arrays representing [“directory”, “filename”, “content”] on the ConfigDrive device.
@@ -159,7 +159,7 @@ VMdata - a list of String arrays representing [“directory”, “filename”,
- vm_password.txt
- - vm_password_md5checksum (for windows VM’s)
+ - vm_password_md5checksum (for windows Instances)
- <mountdir>/openstack/version/:
diff --git a/source/adminguide/autoscale_with_virtual_router.rst b/source/adminguide/autoscale_with_virtual_router.rst
index 7426536..b196866 100644
--- a/source/adminguide/autoscale_with_virtual_router.rst
+++ b/source/adminguide/autoscale_with_virtual_router.rst
@@ -21,12 +21,12 @@ Configuring AutoScale with using CloudStack Virtual Router
What is AutoScaling?
--------------------
-AutoScaling allows you to scale your back-end services or application VMs up
+AutoScaling allows you to scale your back-end services or application Instances up
or down seamlessly and automatically according to the conditions you define.
-With AutoScaling enabled, you can ensure that the number of VMs you are using
+With AutoScaling enabled, you can ensure that the number of Instances you are using
seamlessly scale up when demand increases, and automatically decreases when
demand subsides. Thus it helps you save compute costs by terminating underused
-VMs automatically and launching new VMs when you need them, without the need
+Instances automatically and launching new ones when you need them, without the need
for manual intervention.
@@ -41,27 +41,27 @@ Prerequisites
Before you configure an AutoScale rule, consider the following:
-- Ensure that the necessary template is prepared before configuring AutoScale.
+- Ensure that the necessary Template is prepared before configuring AutoScale.
Firstly you must install the PV-driver or virtio driver, which helps CloudStack
- collects performance parameters (CPU and memory) into VMs. Beside, When a VM is
- deployed by using a template and when it comes up, the application should be
+ collects performance parameters (CPU and memory) into Instances. Besides, when an Instance is
+ deployed by using a Template and when it comes up, the application should be
up and running.
-- Create an Isolated network using a network offering which supports VM AutoScaling,
- acquire a new IP address (it will be used as Source NAT of the network) and create
- a load balancer rule without any VM.
+- Create an Isolated Network using a Network offering which supports Instance AutoScaling,
+ acquire a new IP address (it will be used as Source NAT of the Network) and create
+ a load balancer rule without any Instance.
For more information, see `“Configure Guest Traffic in an Advanced Zone”
<networking_and_traffic.html#configure-guest-traffic-in-an-advanced-zone>`_ ,
`“Acquiring a New IP Address” <networking_and_traffic.html#acquiring-a-new-ip-address>`_
and `“Adding a Load Balancer Rule” <networking_and_traffic.html#adding-a-load-balancer-rule>`_.
.. note::
- There is a known issue when CloudStack collects memory statistics from VMs on
+ There is a known issue when CloudStack collects memory statistics from Instances on
KVM hosts, see https://github.com/apache/cloudstack/pull/6358 .
To get memory statistics on KVM hosts, please add the following line to
/etc/cloudstack/agent/agent.properties and restart cloudstack-agent (5/10/60 are tested ok):
- vm.memballoon.stats.period = <Interval in seconds to get VM stats on KVM host>
+ vm.memballoon.stats.period = <Interval in seconds to get Instance stats on KVM host>
.. note::
There is a known issue when CloudStack collects average load balancer connections
@@ -72,106 +72,105 @@ Before you configure an AutoScale rule, consider the following:
<networking_and_traffic.html#load-balancer-configurations>`_.
.. note::
- VmAutoScaling capability is enabled by default for network offerings which support
- load balanacer. To disable it, please create a network offering without VmAutoScaling support.
+ VmAutoScaling capability is enabled by default for Network offerings which support
+ load balancer. To disable it, please create a Network offering without VmAutoScaling support.
For more information, see `“Creating a New Network Offering”
<networking.html#creating-a-new-network-offering>`_.
-Adding an AutoScale VM Group
+Adding an AutoScale Instance Group
-------------
#. Log in to the CloudStack UI as an administrator or end user.
-#. In the left navigation, choose Compute -> AutoScale VM Groups.
+#. In the left navigation, choose Compute -> AutoScale Instance Groups.
-#. Click the New AutoScale VM Group button.
+#. Click the New AutoScale Instance Group button.
Specify the following:
-- Zone: A zone where the VMs will be deployed to.
+- Zone: A zone where the Instances will be deployed to.
-- Template: A template consists of a base OS image and application. A
- template is used to provision the new instance of an application on a
- scaleup action. When a VM is deployed from a template, the VM can start
+- Template: A Template consists of a base OS image and application. A
+ Template is used to provision the new Instance of an application on a
+ scaleup action. When an Instance is deployed from a Template, it can start
taking the traffic from the load balancer without any admin intervention.
- For example, if the VM is deployed for a Web service, it should have the
+ For example, if the Instance is deployed for a Web service, it should have the
Web server running, the database connected, and so on.
- Compute offering: A predefined set of virtual hardware attributes,
including CPU speed, number of CPUs, and RAM size, that the user can select
- when creating a new virtual machine instance. Choose one of the compute
- offerings to be used while provisioning a VM instance as part of scaleup
- action.
+ when creating a new Instance. Choose one of the compute offerings to be used
+ while provisioning an Instance as part of the scaleup action.
-- Data disk: An extra disk attached to each VM instance in the VM group.
+- Data disk: An extra disk attached to each Instance in the Instance group.
-- Networks: The networks of the VM instances. If there are multiple networks
- checked, the network of the load balancer rule will be the default network
- of VM instances.
+- Networks: The Networks of the Instances. If there are multiple networks
+ checked, the network of the load balancer rule will be the default Network
+ of the Instances.
-- Load balancing rule: When a VM instance is created, it will be automatically
- assigned to the load balancing rule. When a VM instance is expunged, it
+- Load balancing rule: When an Instance is created, it will be automatically
+ assigned to the load balancing rule. When an Instance is expunged, it
will be removed from the load balancing rule.
- ScaleUp policies: The policies for ScaleUp action. When all of the conditions
- in one of the ScaleUp policies are met, CloudStack will create a VM instance
- if the number of VMs do not exceed Max Instance.
+ in one of the ScaleUp policies are met, CloudStack will create an Instance
+ if the number of Instances do not exceed Max Instance.
For more information, see `“AutoScale policies”
<autoscale_with_virtual_router.html#autoscale-policies>`_.
- ScaleDown policies: The policies for ScaleDown action. When all of the
conditions in one of the ScaleDown policies are met, CloudStack will expunge
- a VM instance in the group if the number of VMs is larger than Min Instance.
+ an Instance in the group if the number of Instances is larger than Min Instance.
For more information, see `“AutoScale policies”
<autoscale_with_virtual_router.html#autoscale-policies>`_.
-- Name: The name of the VM group. The name of new VM instances will use the
- name of the VM group as prefix.
+- Name: The name of the Instance group. The name of the new Instances will use the
+ name of the Instance group as prefix.
-- Min Instance: The minimum number of active VM instances that is assigned to
- a load balancing rule. The active VM instances are the application
- instances that are up and serving the traffic, and are being load balanced.
+- Min Instance: The minimum number of active Instances that is assigned to
+ a load balancing rule. The active Instances are the application
+ Instances that are up and serving the traffic, and are being load balanced.
This parameter ensures that a load balancing rule has at least the
- configured number of active VM instances are available to serve the traffic.
+ configured number of active Instances are available to serve the traffic.
-- Max Instance: Maximum number of active VM instances that should be assigned
+- Max Instance: Maximum number of active Instances that should be assigned
to a load balancing rule. This parameter defines the upper limit of active
- VM instances that can be assigned to a load balancing rule.
+ Instances that can be assigned to a load balancing rule.
- Specifying a large value for the maximum instance parameter might result in
- provisioning large number of VM instances, which in turn leads to a single
- load balancing rule exhausting the VM instances limit specified at the
+ Specifying a large value for the Maximum Instance parameter might result in
+ provisioning large number of Instances, which in turn leads to a single
+ load balancing rule exhausting the Instances limit specified at the
account or domain level.
- Polling interval: Frequency in which the conditions, combination of counter,
operator and threshold, are to be evaluated before taking a scale up or
down action. The default polling interval is 30 seconds.
-- Expunge VM Grace Period: The duration in seconds, after a scaledown action
- is initiated, to wait before the VM is expunged as part of scaledown
+- Expunge Instance Grace Period: The duration in seconds, after a scaledown action
+ is initiated, to wait before the Instance is expunged as part of scaledown
action. This is to ensure graceful close of any pending sessions or
- transactions being served by the VM marked for expunge. The default is 120
+ transactions being served by the Instance marked for expunge. The default is 120
seconds.
-- Create: Click Create to create the AutoScale VM group.
+- Create: Click Create to create the AutoScale Instance group.
Additionally, if you want to configure the advanced settings, click Show
advanced settings, and specify the following:
-- SSH key pairs: The SSH Keys of the VM instances.
+- SSH key pairs: The SSH Keys of the Instances.
For more information, see `“Using SSH Keys for Authentication”
<virtual_machines.html#using-ssh-keys-for-authentication>`_.
-- Affinity groups: The affinity groups of the VM instances.
+- Affinity groups: The affinity groups of the Instances.
For more information, see `“Affinity Groups”
<virtual_machines.html#affinity-groups>`_.
-- Userdata: The userdata of the VM instances.
+- Userdata: The userdata of the Instances.
For more information, see `“User-Data and Meta-Data”
<virtual_machines.html#user-data-and-meta-data>`_.
@@ -180,7 +179,7 @@ Specify the following:
AutoScale Policies
-------------------------------------------------
-An AutoScale Vm Group must have one or more scale-up policies, and one or more
+An AutoScale Instance Group must have one or more scale-up policies, and one or more
scale-down policies.
Each AutoScale Policy has the following parameters:
@@ -191,8 +190,8 @@ Each AutoScale Policy has the following parameters:
invoked.
- Quiet Time: This is the cool down period after an AutoScale action is
- initiated. The time includes the time taken to complete provisioning a VM
- instance from its template and the time taken by an application to be ready
+ initiated. The time includes the time taken to complete provisioning an
+ Instance from its Template and the time taken by an application to be ready
to serve traffic. This quiet time allows the fleet to come up to a stable
state before any action can take place. The default is 300 seconds.
@@ -203,13 +202,13 @@ Each AutoScale Policy has the following parameters:
Each condition in AutoScale policies has the following parameters:
- Counter: The performance counters expose the state of the monitored
- instances. We added five new counters to work with that feature:
+ Instances. We added five new counters to work with that feature:
- - VM CPU - average percentage
- - VM Memory - average percentage
- - Public Network - mbps received per vm
- - Public Network - mbps transmit per vm
- - Load Balancer - average connections per vm
+ - Instance CPU - average percentage
+ - Instance Memory - average percentage
+ - Public Network - mbps received per Instance
+ - Public Network - mbps transmit per Instance
+ - Load Balancer - average connections per Instance
Remember to choose one of them. If you choose anything else, the
autoscaling will not work.
@@ -223,77 +222,76 @@ Each condition in AutoScale policies has the following parameters:
a scaleup or scaledown action.
.. note::
- The counter "VM Memory - average percentage" calculates the average memory usage
- of available VMs (in Starting, Stopping, Running, Migrating states) in the
- AutoScale VM Group. On KVM/XenServer, the VM memory usage is calculated by
+ The counter "Instance Memory - average percentage" calculates the average memory usage
+ of available Instances (in Starting, Stopping, Running, Migrating states) in the
+ AutoScale Instance Group. On KVM/XenServer, the Instance memory usage is calculated by
- VM memory usage percentage = (total memory - free memory) * 100 / total memory
+ Instance memory usage percentage = (total memory - free memory) * 100 / total memory
.. note::
- The counters "Public Network - mbps received per vm" and
- "Public Network - mbps transmit per vm" consider all public
+ The counters "Public Network - mbps received per Instance" and
+ "Public Network - mbps transmit per Instance" consider all public
traffic through the VR public interface, including the traffic from/to other
- VMs which are not in the AutoScale VM group.
+ Instances which are not in the AutoScale Instance group.
.. note::
Each network has a network rate which are configured by global configuration
network.throttling.rate and "Network rate (Mb/s)" in network offering.
-Disabling and Enabling an AutoScale VM Group
+Disabling and Enabling an AutoScale Instance Group
-------------------------------------------------
-You can view the detail of the AutoScale VM Group.
+You can view the detail of the AutoScale Instance Group.
#. Log in to the CloudStack UI as an administrator or end user.
-#. In the left navigation, choose Compute -> AutoScale VM Groups.
+#. In the left navigation, choose Compute -> AutoScale Instance Groups.
-#. Select the AutoScale VM Group you want to work with.
+#. Select the AutoScale Instance Group you want to work with.
|autoscale-vmgroup-details.png|
-If you want to perform any maintenance operation on the AutoScale VM instances,
-disable the AutoScale VM Group. When the AutoScale VM Group is
+If you want to perform any maintenance operation on the AutoScale Instances,
+disable the AutoScale Instance Group. When the AutoScale Instance Group is
disabled, no scaleup or scaledown action is performed. You can use this
-downtime for the maintenance activities. To disable the AutoScale VM Group,
-click the Disable AutoScale VM Group button.
+downtime for the maintenance activities. To disable the AutoScale Instance Group,
+click the Disable AutoScale Instance Group button.
The button toggles between enable and disable, depending on whether AutoScale
is currently enabled or not. After the maintenance operations are done, you
-can enable the AutoScale VM Group back. To enable the AutoScale VM Group, click
-the Enable AutoScale VM Group button.
+can enable the AutoScale Instance Group back. To enable the AutoScale Instance Group, click
+the Enable AutoScale Instance Group button.
-Updating an AutoScale VM Group
+Updating an AutoScale Instance Group
-----------------------------------
-You can update the various parameters of VM profile, and add or delete the
-conditions in a scaleup or scaledown policy. Before you update an AutoScale VM
-Group, ensure that you disable the AutoScale VM Group by clicking the
-Disable AutoScale button.
+You can update the various parameters of Instance profile, and add or delete the
+conditions in a scaleup or scaledown policy. Before you update an AutoScale Instance
+Group, ensure that you disable it first by clicking the Disable AutoScale button.
-To update the AutoScale VM Group, click the Update AutoScale VM Group button.
+To update the AutoScale Instance Group, click the Update AutoScale Instance Group button.
|autoscale-vmgroup-update.png|
-Updating AutoScale VM Profile
+Updating AutoScale Instance Profile
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To update the VM Profile of the AutoScale VM Group, click the AutoScale VM Profile
-tab, You will see the details of AutoScale VM Profile.
+To update the Instance Profile of the AutoScale Instance Group, click the AutoScale Instance Profile
+tab, You will see the details of AutoScale Instance Profile.
|autoscale-vmgroup-profile.png|
-then click Edit AutoScale VM Profile button.
+then click Edit AutoScale Instance Profile button.
|autoscale-vmgroup-profile-update.png|
-You are able to reset userdata of the VM instances, by clicking Reset Userdata on AutoScale VM Group button.
+You are able to reset userdata of the Instance, by clicking Reset Userdata on AutoScale Instance Group button.
|autoscale-vmgroup-profile-reset-userdata.png|
-You are also able to update the deploy parameters of the VM instances.
+You are also able to update the deploy parameters of the Instances.
|autoscale-vmgroup-deploy-parameters.png|
@@ -310,12 +308,12 @@ The following parameters are supported.
- keypairs: The name of the SSH Key pairs, separated by a single comma
character (,).
-- networkids: The UUID of the VM networks, separated by a single comma
+- networkids: The UUID of the Instance networks, separated by a single comma
character (,).
- overridediskofferingid: The UUID of override disk offering for ROOT disk.
-- rootdisksize: The size of the ROOT disk. This overrides the size of VM template.
+- rootdisksize: The size of the ROOT disk. This overrides the size of the Instance Template.
- securitygroupids: The UUID of security groups, separated by a single comma
character (,). This is valid only if the network provider is Netscaler.
@@ -324,7 +322,7 @@ The following parameters are supported.
Adding an AutoScale policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To add a new Scale policy to the AutoScale VM Group, click the ScaleUp policy
+To add a new Scale policy to the AutoScale Instance Group, click the ScaleUp policy
or ScaleDown policy tab, then click "Add policy".
|autoscale-vmgroup-policy-new.png|
@@ -335,7 +333,7 @@ or ScaleDown policy tab, then click "Add policy".
Updating AutoScale policies
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To update the AutoScale policies of the AutoScale VM Group, click the ScaleUp policy
+To update the AutoScale policies of the AutoScale Instance Group, click the ScaleUp policy
or ScaleDown policy tab.
|autoscale-vmgroup-policy.png|
@@ -357,49 +355,49 @@ Removing an AutoScale policy
To remove an existing AutoScale policies, select a policy, click "Remove policy" button.
.. note::
- To apply the new AutoScale VM Profile and AutoScale policies, open the AutoScale VM
- Group details, then click the Enable AutoScale VM Group button.
+ To apply the new AutoScale Instance Profile and AutoScale policies, open the AutoScale Instance
+ Group details, then click the Enable AutoScale Instance Group button.
-Deleting an AutoScale VM Group
-----------------------
+Deleting an AutoScale Instance Group
+------------------------------------
-To remove an AutoScale VM Group, click "Delete AutoScale VM Group" button.
+To remove an AutoScale Instance Group, click "Delete AutoScale Instance Group" button.
|autoscale-vmgroup-delete.png|
-AutoScale VM Group can be removed only if there is no VM in the group.
+AutoScale Instance Group can be removed only if there are no Instances in the group.
-To force-delete the AutoScale VM Group, check the cleanup checkbox, then click OK button.
-All the VMs in the group will be expunged.
+To force-delete the AutoScale Instance Group, check the cleanup checkbox, then click OK button.
+All the Instances in the group will be expunged.
Runtime Considerations
----------------------
-An administrator should not assign a VM to a load balancing rule which is
+An administrator should not assign an Instance to a load balancing rule which is
configured for AutoScale.
Making API calls outside the context of AutoScale, such as destroyVM, on an
-autoscaled VM leaves the load balancing configuration in an inconsistent state.
-Though VM is destroyed from the load balancer rule, it continues be showed as
+autoscaled Instance leaves the load balancing configuration in an inconsistent state.
+Even though the Instance is destroyed from the load balancer rule, it continues to be shown as
a service assigned to a rule inside the context of AutoScale.
.. |autoscale-vmgroup-delete.png| image:: /_static/images/autoscale-vmgroup-delete.png
- :alt: Delete AutoScale VM Group.
+ :alt: Delete AutoScale Instance Group.
.. |autoscale-vmgroup-deploy-parameters.png| image:: /_static/images/autoscale-vmgroup-deploy-parameters.png
- :alt: AutoScale VM deploy parameters.
+ :alt: AutoScale Instance deploy parameters.
.. |autoscale-vmgroup-details.png| image:: /_static/images/autoscale-vmgroup-details.png
- :alt: AutoScale VM Group details.
+ :alt: AutoScale Instance Group details.
.. |autoscale-vmgroup-policy-new.png| image:: /_static/images/autoscale-vmgroup-policy-new.png
:alt: Add new AutoScale Policy.
.. |autoscale-vmgroup-policy.png| image:: /_static/images/autoscale-vmgroup-policy.png
:alt: AutoScale Policies.
.. |autoscale-vmgroup-profile.png| image:: /_static/images/autoscale-vmgroup-profile.png
- :alt: AutoScale VM Profile.
+ :alt: AutoScale Instance Profile.
.. |autoscale-vmgroup-update.png| image:: /_static/images/autoscale-vmgroup-update.png
- :alt: Update AutoScale VM Group.
+ :alt: Update AutoScale Instance Group.
.. |autoscale-vmgroup-profile-update.png| image:: /_static/images/autoscale-vmgroup-profile-update.png
- :alt: Update AutoScale VM Profile.
+ :alt: Update AutoScale Instance Profile.
.. |autoscale-vmgroup-profile-reset-userdata.png| image:: /_static/images/autoscale-vmgroup-profile-reset-userdata.png
- :alt: Reset Userdata in AutoScale VM Profile.
+ :alt: Reset Userdata in AutoScale Instance Profile.
diff --git a/source/adminguide/autoscale_without_netscaler.rst b/source/adminguide/autoscale_without_netscaler.rst
index c8f8f7f..efeb1db 100644
--- a/source/adminguide/autoscale_without_netscaler.rst
+++ b/source/adminguide/autoscale_without_netscaler.rst
@@ -26,12 +26,12 @@ Configuring AutoScale without using NetScaler
What is AutoScaling?
--------------------
-AutoScaling allows you to scale your back-end services or application VMs up
+AutoScaling allows you to scale your back-end services or application Instances up
or down seamlessly and automatically according to the conditions you define.
-With AutoScaling enabled, you can ensure that the number of VMs you are using
+With AutoScaling enabled, you can ensure that the number of Instances you are using
seamlessly scale up when demand increases, and automatically decreases when
demand subsides. Thus it helps you save compute costs by terminating underused
-VMs automatically and launching new VMs when you need them, without the need
+Instances automatically and launching new Instances when you need them, without the need
for manual intervention.
@@ -47,10 +47,10 @@ Prerequisites
Before you configure an AutoScale rule, consider the following:
-- Ensure that the necessary template is prepared before configuring AutoScale.
+- Ensure that the necessary Template is prepared before configuring AutoScale.
Firstly you must install the PV-driver, which helps Xenserver collect
- performance parameters (CPU and memory) into VMs. Beside, When a VM is
- deployed by using a template and when it comes up, the application should be
+ performance parameters (CPU and memory) into Instances. Besides, When an Instance is
+ deployed by using a Template and when it comes up, the application should be
up and running.
@@ -61,33 +61,32 @@ Specify the following:
.. image:: /_static/images/autoscale-config.png
-- Template: A template consists of a base OS image and application. A
- template is used to provision the new instance of an application on a
- scaleup action. When a VM is deployed from a template, the VM can start
+- Template: A Template consists of a base OS image and application. A
+ Template is used to provision the new Instance of an application on a
+ scaleup action. When an Instance is deployed from a Template, it can start
taking the traffic from the load balancer without any admin intervention.
- For example, if the VM is deployed for a Web service, it should have the
+ For example, if the Instance is deployed for a Web service, it should have the
Web server running, the database connected, and so on.
- Compute offering: A predefined set of virtual hardware attributes,
including CPU speed, number of CPUs, and RAM size, that the user can select
- when creating a new virtual machine instance. Choose one of the compute
- offerings to be used while provisioning a VM instance as part of scaleup
- action.
+ when creating a new Instance. Choose one of the compute offerings to be used
+ while provisioning an Instance as part of scaleup action.
-- Min Instance: The minimum number of active VM instances that is assigned to
- a load balancing rule. The active VM instances are the application
- instances that are up and serving the traffic, and are being load balanced.
+- Min Instance: The minimum number of active Instances that is assigned to
+ a load balancing rule. The active Instances are the application
+ Instances that are up and serving the traffic, and are being load balanced.
This parameter ensures that a load balancing rule has at least the
- configured number of active VM instances are available to serve the traffic.
+ configured number of active Instances are available to serve the traffic.
-- Max Instance: Maximum number of active VM instances that should be assigned
+- Max Instance: Maximum number of active Instances that should be assigned
to a load balancing rule. This parameter defines the upper limit of active
- VM instances that can be assigned to a load balancing rule.
+ Instances that can be assigned to a load balancing rule.
- Specifying a large value for the maximum instance parameter might result in
- provisioning large number of VM instances, which in turn leads to a single
- load balancing rule exhausting the VM instances limit specified at the
- account or domain level.
+ Specifying a large value for the maximum Instance parameter might result in
+ provisioning large number of Instances, which in turn leads to a single
+ load balancing rule exhausting the Instances limit specified at the
+ Account or domain level.
Specify the following scale-up and scale-down policies:
@@ -97,7 +96,7 @@ Specify the following scale-up and scale-down policies:
invoked.
- Counter: The performance counters expose the state of the monitored
- instances. We added two new counter to work with that feature:
+ Instances. We added two new counter to work with that feature:
- Linux User CPU [native] - percentage
- Linux User RAM [native] - percentage
@@ -123,15 +122,15 @@ Specify the following scale-up and scale-down policies:
down action. The default polling interval is 30 seconds.
- Quiet Time: This is the cool down period after an AutoScale action is
- initiated. The time includes the time taken to complete provisioning a VM
- instance from its template and the time taken by an application to be ready
+ initiated. The time includes the time taken to complete provisioning an
+ Instance from its Template and the time taken by an application to be ready
to serve traffic. This quiet time allows the fleet to come up to a stable
state before any action can take place. The default is 300 seconds.
-- Destroy VM Grace Period: The duration in seconds, after a scaledown action
- is initiated, to wait before the VM is destroyed as part of scaledown
+- Destroy Instance Grace Period: The duration in seconds, after a scaledown action
+ is initiated, to wait before the Instance is destroyed as part of scaledown
action. This is to ensure graceful close of any pending sessions or
- transactions being served by the VM marked for destroy. The default is 120
+ transactions being served by the Instance marked for destroy. The default is 120
seconds.
- Apply: Click Apply to create the AutoScale configuration.
@@ -140,7 +139,7 @@ Specify the following scale-up and scale-down policies:
Disabling and Enabling an AutoScale Configuration
-------------------------------------------------
-If you want to perform any maintenance operation on the AutoScale VM instances,
+If you want to perform any maintenance operation on the AutoScale Instances,
disable the AutoScale configuration. When the AutoScale configuration is
disabled, no scaleup or scaledown action is performed. You can use this
downtime for the maintenance activities. To disable the AutoScale
@@ -168,11 +167,11 @@ click the Enable AutoScale button.
Runtime Considerations
----------------------
-An administrator should not assign a VM to a load balancing rule which is
+An administrator should not assign an Instance to a load balancing rule which is
configured for AutoScale.
Making API calls outside the context of AutoScale, such as destroyVM, on an
-autoscaled VM leaves the load balancing configuration in an inconsistent state.
-Though VM is destroyed from the load balancer rule, it continues be showed as
-a service assigned to a rule inside the context of AutoScale.
+autoscaled Instance leaves the load balancing configuration in an inconsistent state.
+Even though the Instance is destroyed from the load balancer rule, it continues to be shown
+as a service assigned to a rule inside the context of AutoScale.
diff --git a/source/adminguide/backup_and_recovery.rst b/source/adminguide/backup_and_recovery.rst
index 99a4fd4..90d0fd3 100644
--- a/source/adminguide/backup_and_recovery.rst
+++ b/source/adminguide/backup_and_recovery.rst
@@ -17,10 +17,10 @@ About Backup And Recovery
--------------------------
CloudStack version 4.14 introduces a new Backup and Recovery (B&R) framework that
-provides CloudStack with users the ability to back up their guest VMs for recovery
+provides CloudStack with users the ability to back up their Guest Instances for recovery
purposes via 3rd party backup solutions. The framework abstracts the API commands
required for common backup and recovery
-operations, from the vendor specific commmands needed to perform those actions and provides
+operations, from the vendor specific commands needed to perform those actions and provides
a plugin model to enable any solution which provides backup and recovery 'like'
features to be integrated.
@@ -50,14 +50,14 @@ A user signs up for a 'Gold' offering, which might give them a RPO of 12 hours a
allowed to perform additional backups nor set the exact time that these backups took place. The user might be charged
a fix rate for these backups regardless of the size of the backups.
-To use an SLA based backup policy the user adds their VMs to the offering/policy. The job then runs at its predetermined times and 'includes' the
-VM when it runs. A user can remove the VM from the offering/policy and it will no longer be included in the job when it runs.
+To use an SLA based backup policy the user adds their Instances to the offering/policy. The job then runs at its predetermined times and 'includes' the
+Instance when it runs. A user can remove the Instance from the offering/policy and it will no longer be included in the job when it runs.
-Adhoc and user scheduled backups follow the same idea as volume snapshots, however they leverage the backup solution
+Adhoc and user scheduled backups follow the same idea as Volume Snapshots, however they leverage the backup solution
rather than secondary storage. These could likely be billed on backup storage consumed or protected capacity (the full virtual
-size of the VM(s) being backed up.
+size of the Instance(s) being backed up.
-Adhoc and user scheduled backups are created and managed in the same fashion as volume snapshots are.
+Adhoc and user scheduled backups are created and managed in the same fashion as Volume Snapshots are.
Configuring Backup and Recovery
@@ -112,18 +112,18 @@ To import a backup provider offering;
#. (As root) navigate to Service Offerings, click on the 'select offering' dropdown box and select 'Backup Offerings'
#. Click on Import Backup Offering
#. Enter your user-friendly name and description and select the applicable zone. The External ID will then be populated with the
- template jobs which CloudStack retrieves from the connected provider.
+ Template jobs which CloudStack retrieves from the connected provider.
|B&R-backup_offering_policy.png| |B&R-backup_offering.png|
-Creating VM Backups
----------------------
+Creating Instance Backups
+-------------------------
SLA/Policy Based backups
~~~~~~~~~~~~~~~~~~~~~~~~~
With the backup and recovery feature enabled for a zone, users simply add and
-remove a VM from a backup offering.
+remove an Instance from a backup offering.
|B&R-assignOffering.png|
@@ -131,16 +131,16 @@ Adhoc and Scheduled Backups
~~~~~~~~~~~~~~~~~~~~~~~~~~~
For backup offerings that allow ad-hoc user backups and user-defined backup
-schedules, user will be allowed to define a backup schedule for a VM that is
-assigned to a backup offering using UI and API. A VM with backup will not be
-allowed to add/remove volumes similar to VM snapshots.
+schedules, user will be allowed to define a backup schedule for an Instance that is
+assigned to a backup offering using UI and API. An Instance with backup will not be
+allowed to add/remove volumes similar to Instance Snapshots.
-To trigger an adhoc backup of a VM, navigate to the instance and click on the 'Create Backup'
+To trigger an adhoc backup of an Instance, navigate to the Instance and click on the 'Create Backup'
icon.
|B&R-createBackup.png|
-To setup a recurring backup schedule, navigate to the instance and click on the 'Backup Schedule'
+To setup a recurring backup schedule, navigate to the Instance and click on the 'Backup Schedule'
icon.
|B&R-BackupSchedule.png|
@@ -149,46 +149,46 @@ Then set the time and frequency of the backups, click 'Configure' and then 'Clos
|B&R-BackupScheduleEntry.png|
-Restoring VM Backups
----------------------
+Restoring Instance Backups
+--------------------------
-Users will need to stop a VM to restore to any existing VM backup, restoration
-of an expunged VM will not restore nics and recovery any network which may/may
-not exist. User may however restore a specific volume from a VM backup and attach
-that volume to a specified VM.
+Users will need to stop an Instance to restore to any existing Instance backup, restoration
+of an expunged Instance will not restore nics and recovery any network which may/may
+not exist. User may however restore a specific volume from an Instance backup and attach
+that volume to a specified Instance.
Supported APIs:
~~~~~~~~~~~~~~~~
-- **assignVirtualMachineToBackupOffering**: adds a VM to a backup offering.
-- **removeVirtualMachineFromBackupOffering**: removes a VM from a backup offering, if forced `true` parameter is passed this may also
- remove any and all the backups of a VM associated with a backup offering.
-- **createBackupSchedule**: creates a backup schedule for a VM.
+- **assignVirtualMachineToBackupOffering**: adds an Instance to a backup offering.
+- **removeVirtualMachineFromBackupOffering**: removes an Instance from a backup offering, if forced `true` parameter is passed this may also
+ remove any and all the backups of an Instance associated with a backup offering.
+- **createBackupSchedule**: creates a backup schedule for an Instance.
- **updateBackupSchedule**: updates backup schedule.
-- **listBackupSchedule**: returns backup schedule of a VM if defined.
-- **deleteBackupSchedule**: deletes backup schedule of a VM.
-- **createBackup**: creates an adhoc backup for a VM.
-- **deleteVMBackup**: deletes a VM backup (not support for per restore point for Veeam).
+- **listBackupSchedule**: returns backup schedule of an Instance if defined.
+- **deleteBackupSchedule**: deletes backup schedule of an Instance.
+- **createBackup**: creates an adhoc backup for an Instance.
+- **deleteVMBackup**: deletes an Instance backup (not support for per restore point for Veeam).
- **listBackups**: lists backups.
-- **restoreBackup**: restore a previous VM backup in-place of a stopped or destroyed VM.
-- **restoreVolumeFromBackup**: restore and attach a backed-up volume (of a VM backup) to a specified VM.
+- **restoreBackup**: restore a previous Instance backup in-place of a stopped or destroyed Instance.
+- **restoreVolumeFromBackup**: restore and attach a backed-up volume (of an Instance backup) to a specified Instance.
.. |B&R-assignOffering.png| image:: /_static/images/B&R-assignOffering.png
- :alt: Assigning an SLA/Policy to a VM.
+ :alt: Assigning an SLA/Policy to an Instance.
:width: 400 px
.. |B&R-backup_offering_policy.png| image:: /_static/images/B&R-backup_offering_policy.png
:alt: Importing an SLA/Policy offering.
:width: 300 px
.. |B&R-backup_offering.png| image:: /_static/images/B&R-backup_offering.png
- :alt: Importing a template backup offering.
+ :alt: Importing a Template backup offering.
:width: 300 px
.. |B&R-createBackup.png| image:: /_static/images/B&R-createBackup.png
- :alt: Triggering an adhoc backup for a VM.
+ :alt: Triggering an adhoc backup for an Instance.
:width: 400 px
.. |B&R-BackupSchedule.png| image:: /_static/images/B&R-BackupSchedule.png
- :alt: Creating a backup schedule for a VM.
+ :alt: Creating a backup schedule for an Instance.
:width: 400 px
.. |B&R-BackupScheduleEntry.png| image:: /_static/images/B&R-BackupScheduleEntry.png
- :alt: Creating a backup schedule for a VM.
+ :alt: Creating a backup schedule for an Instance.
:width: 400px
diff --git a/source/adminguide/events.rst b/source/adminguide/events.rst
index 629fcc4..7766973 100644
--- a/source/adminguide/events.rst
+++ b/source/adminguide/events.rst
@@ -50,8 +50,8 @@ notification is achieved by implementing the concept of event bus
abstraction in the Management Server.
A new event for state change, resource state change, is introduced as
-part of Event notification framework. Every resource, such as user VM,
-volume, NIC, network, public IP, snapshot, and template, is associated
+part of Event notification framework. Every resource, such as user Instance,
+volume, NIC, network, public IP, Snapshot, and Template, is associated
with a state machine and generates events as part of the state change.
That implies that a change in the state of a resource results in a state
change event, and the event is published in the corresponding state
@@ -113,11 +113,11 @@ changes can control the behaviour.
- port : The port on which RabbitMQ server is running.
- - username : The username associated with the account to access the
+ - username : The username associated with the Account to access the
RabbitMQ server.
- password : The password associated with the username of the
- account to access the RabbitMQ server.
+ Account to access the RabbitMQ server.
- exchange : The exchange name on the RabbitMQ server where
CloudStack events are published.
@@ -251,10 +251,10 @@ The events log records three types of standard events.
- WARN. This event is generated in the following circumstances.
- - When a network is disconnected while monitoring a template
+ - When a network is disconnected while monitoring a Template
download.
- - When a template download is abandoned.
+ - When a Template download is abandoned.
- When an issue on the storage server causes the volumes to fail
over to the mirror storage server.
@@ -273,10 +273,10 @@ The events log records three types of standard events.
- WARN. This event is generated in the following circumstances.
- - When a network is disconnected while monitoring a template
+ - When a network is disconnected while monitoring a Template
download.
- - When a template download is abandoned.
+ - When a Template download is abandoned.
- When an issue on the storage server causes the volumes to fail
over to the mirror storage server.
@@ -291,7 +291,7 @@ 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
+- Instance creation, deletion, and on-going management
operations
- Virtual router creation, deletion, and on-going management operations
diff --git a/source/adminguide/guest_os.rst b/source/adminguide/guest_os.rst
index cb90cbe..cb64f57 100644
--- a/source/adminguide/guest_os.rst
+++ b/source/adminguide/guest_os.rst
@@ -29,9 +29,9 @@
:alt: Add guest OS mapping button
CloudStack provides administrators a good control to manage the guest operating systems for the
-virtual machines. CloudStack maintains the list of guest operating systems that are supported
+Instances. CloudStack maintains the list of guest operating systems that are supported
by the hypervisors and also provides a way for operators or admins to add new guest OSs based on the need.
-For an operating system to be supported to CloudStack for the virtual machines, it has to be added in CloudStack
+For an operating system to be supported to CloudStack for the Instances, it has to be added in CloudStack
and also need to have a mapping with the actual operating system name supported by hypervisor.
Under "Configuration" section there are sub-sections for guest operating system.
diff --git a/source/adminguide/hosts.rst b/source/adminguide/hosts.rst
index 178283e..6feeabd 100644
--- a/source/adminguide/hosts.rst
+++ b/source/adminguide/hosts.rst
@@ -18,15 +18,15 @@ Adding Hosts
------------
Additional hosts can be added at any time to provide more capacity for
-guest VMs. For requirements and instructions, see :ref:`adding-a-host`.
+guest Instances. For requirements and instructions, see :ref:`adding-a-host`.
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
+activated, the host becomes unavailable to receive new guest Instances, and
+the guest Instances 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.
@@ -39,13 +39,13 @@ must be used in concert. CloudStack and vCenter have separate
maintenance modes that work closely together.
#. Place the host into CloudStack's "scheduled maintenance" mode. This
- does not invoke the vCenter maintenance mode, but only causes VMs to
+ does not invoke the vCenter maintenance mode, but only causes Instances to
be migrated off the host
When the CloudStack maintenance mode is requested, the host first
moves into the Prepare for Maintenance state. In this state it cannot
- be the target of new guest VM starts. Then all VMs will be migrated
- off the server. Live migration will be used to move VMs off the host.
+ be the target of new guest Instance starts. Then all Instances will be migrated
+ off the server. Live migration will be used to move Instances 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.
@@ -53,7 +53,7 @@ maintenance modes that work closely together.
#. 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
+ the host. During this time, the host cannot be the target of new Instance
allocations.
#. When the maintenance tasks are complete, take the host out of
@@ -66,8 +66,8 @@ maintenance modes that work closely together.
#. Then use CloudStack's administrator UI to cancel the CloudStack
maintenance mode
- When the host comes back online, the VMs that were migrated off of
- it may be migrated back to it manually and new VMs can be added.
+ When the host comes back online, the Instances that were migrated off of
+ it may be migrated back to it manually and new Instances can be added.
XenServer and Maintenance Mode
@@ -75,10 +75,10 @@ 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
+Maintenance Mode, all running Instances 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.
+Mode, you cannot create or start any Instances on it.
**To place a server in Maintenance Mode:**
@@ -92,7 +92,7 @@ Mode, you cannot create or start any VMs on it.
#. Click Enter Maintenance Mode.
-The server's status in the Resources pane shows when all running VMs
+The server's status in the Resources pane shows when all running Instances
have been successfully migrated off the server.
**To take a server out of Maintenance Mode:**
@@ -152,7 +152,7 @@ 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
+maintenance mode. This will ensure that all of the Instances on it have been
migrated to other Hosts. To remove a Host from the cloud:
#. Place the node in maintenance mode.
@@ -200,7 +200,7 @@ 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 lack of up-do-date hotfixes can lead to data corruption and lost Instances.
(XenServer) For more information, see
`Highly Recommended Hotfixes for XenServer in the CloudStack Knowledge Base
@@ -209,7 +209,7 @@ any system that is not up to date with patches.
Hypervisor Capabilities
-----------------------
-For different hypervisors and their versions, various capabilities such as maximum number of guest VMs per host, maximum number of volumes per VM, security group support, etc are considered by CloudStack. These capabilities are stored in the **cloud.hypervisor_capabilities** table in the database. If a specific hypervisor version is not available in the database, values against the *default* version for the hypervisor will be used.
+For different hypervisors and their versions, various capabilities such as maximum number of guest Instances per host, maximum number of volumes per Instance, security group support, etc are considered by CloudStack. These capabilities are stored in the **cloud.hypervisor_capabilities** table in the database. If a specific hypervisor version is not available in the database, values against the *default* version for the hypervisor will be used.
These capabilities can be listed using API - ``listHypervisorCapabilities``. Some of the hypervisor capabilities can also be updated for a hypervisor type and version combination using API - ``updateHypervisorCapabilities``.
Following hypervisor-specific documentations can be referred for different maximums for a particular hypervisor host:
@@ -220,7 +220,7 @@ Following hypervisor-specific documentations can be referred for different maxim
.. note::
- Guest VM limit check is not done while deploying a VM on a KVM hypervisor host.
+ Guest Instance limit check is not done while deploying an Instance on a KVM hypervisor host.
@@ -281,7 +281,7 @@ Over-Provisioning and Service Offering Limits
(Supported for XenServer, KVM, and VMware)
CPU and memory (RAM) over-provisioning factors can be set for each
-cluster to change the number of VMs that can run on each host in the
+cluster to change the number of Instances that can run on each host in the
cluster. This helps optimize the use of resources. By increasing the
over-provisioning factor, more resource capacity will be used. If the
factor is set to 1, no over-provisioning is done.
@@ -298,7 +298,7 @@ Capacity = 2 GB
Over-provisioning factor = 2
Capacity after over-provisioning = 4 GB
-With this configuration, suppose you deploy 3 VMs of 1 GB each:
+With this configuration, suppose you deploy 3 Instances of 1 GB each:
Used = 3 GB
Free = 1 GB
@@ -307,14 +307,14 @@ The administrator can specify a memory over-provisioning factor, and can
specify both CPU and memory over-provisioning factors on a per-cluster
basis.
-In any given cloud, the optimum number of VMs for each host is affected
+In any given cloud, the optimum number of Instances for each host is affected
by such things as the hypervisor, storage, and hardware configuration.
These may be different for each cluster in the same cloud. A single
global over-provisioning setting can not provide the best utilization
for all the different clusters in the cloud. It has to be set for the
lowest common denominator. The per-cluster setting provides a finer
granularity for better utilization of resources, no matter where the
-CloudStack placement algorithm decides to place a VM.
+CloudStack placement algorithm decides to place an Instance.
The overprovisioning settings can be used along with dedicated resources
(assigning a specific cluster to an account) to effectively offer
@@ -336,9 +336,9 @@ Limitations on Over-Provisioning in XenServer and KVM
- In XenServer, due to a constraint of this hypervisor, you can not use
an over-provisioning factor greater than 4.
-- The KVM hypervisor can not manage memory allocation to VMs
+- The KVM hypervisor can not manage memory allocation to Instances
dynamically. CloudStack sets the minimum and maximum amount of memory
- that a VM can use. The hypervisor adjusts the memory within the set
+ that an Instance can use. The hypervisor adjusts the memory within the set
limits based on the memory contention.
@@ -354,30 +354,30 @@ responsibility to ensure that these requirements are met.
Balloon Driver
^^^^^^^^^^^^^^
-All VMs should have a balloon driver installed in them. The hypervisor
+All Instances should have a balloon driver installed in them. The hypervisor
communicates with the balloon driver to free up and make the memory
-available to a VM.
+available to an Instance.
XenServer
'''''''''
The balloon driver can be found as a part of xen pv or PVHVM drivers.
-The xen pvhvm drivers are included in upstream linux kernels 2.6.36+.
+The xen PVHVM drivers are included in upstream linux kernels 2.6.36+.
VMware
''''''
The balloon driver can be found as a part of the VMware tools. All the
-VMs that are deployed in a over-provisioned cluster should have the
+Instances that are deployed in a over-provisioned cluster should have the
VMware tools installed.
KVM
'''
-All KVM VMs are required to support the virtio drivers. These drivers are
+All KVM Instances are required to support the virtio drivers. These drivers are
installed in all Linux kernel versions 2.6.25 and greater. The
administrator must set CONFIG\_VIRTIO\_BALLOON=y in the virtio
configuration. Drivers for Windows can be downloaded from
@@ -423,11 +423,11 @@ enabled by default, and can be checked otherwise by checking/setting
Note: the memory ballooning feature isn't automatic on KVM and shouldn't be
confused with the dynamic scaling feature that allows manual scaling of running
-VMs by changing the service offering (feature can be enabled via the setting
-enable.dynamic.scale.vm) of VMs that aren't using a fixed compute offering.
+Instances by changing the service offering (feature can be enabled via the setting
+enable.dynamic.scale.vm) of Instances that aren't using a fixed compute offering.
By default, when memory is over provisioned (setting mem.overprovisioning.factor
-is greater than 1.0 at global or cluster level) the actual memory for the VM is
+is greater than 1.0 at global or cluster level) the actual memory for the Instance is
the memory per the service offering divided by the global or cluster-specific
memory overprovisioning factor. This means guests start with a lower memory than
their service offering intended memory, which will not be changed or scaled
@@ -445,19 +445,19 @@ cpu.overprovisioning.factor and mem.overprovisioning.factor will be
applied when a new cluster is created. Later, the factors can be modified
for an existing cluster.
-Only VMs deployed after the change are affected by the new setting. If
-you want VMs deployed before the change to adopt the new
-over-provisioning factor, you must stop and restart the VMs. When this is
+Only Instances deployed after the change are affected by the new setting. If
+you want Instances deployed before the change to adopt the new
+over-provisioning factor, you must stop and restart the Instances. When this is
done, CloudStack recalculates or scales the used and reserved capacities
based on the new over-provisioning factors, to ensure that CloudStack is
correctly tracking the amount of free capacity.
.. note::
- It is safer not to deploy additional new VMs while the capacity
+ It is safer not to deploy additional new Instances while the capacity
recalculation is underway, in case the new values for available
- capacity are not high enough to accommodate the new VMs. Just wait
+ capacity are not high enough to accommodate the new Instances. Just wait
for the new used/available values to become available, to be sure
- there is room for all the new VMs you want.
+ there is room for all the new Instances you want.
To change the over-provisioning factors for an existing cluster:
@@ -807,7 +807,7 @@ and space are replaced with ``~``:
Starting 4.11.1, a KVM host is considered secured when it has its keystore and
certificates setup for both the agent and libvirtd process. A secured host will
-only allow and initiate TLS enabled live VM migration. This requires libvirtd
+only allow and initiate TLS enabled live Instance migration. This requires libvirtd
to listen on default port 16514, and the port to be allowed in the firewall
rules. Certificate renewal (using the ``provisionCertificate`` API) will restart
both the libvirtd process and agent after deploying new certificates.
@@ -822,7 +822,7 @@ Feature Overview
- This feature applies to KVM hosts.
- KVM utilised under CloudStack uses the standard Libvirt hook script behaviour as outlined in the Libvirt documentation page `hooks`_.
- During the install of the KVM CloudStack agent, the Libvirt hook script "/etc/libvirt/hooks/qemu", referred to as the qemu script hereafter is installed.
-- This is a python script that carries out network management tasks every time a VM is started, stopped or migrated, as per the Libvirt hooks specification.
+- This is a python script that carries out network management tasks every time an Instance is started, stopped or migrated, as per the Libvirt hooks specification.
- Custom network configuration tasks can be done at the same time as the qemu script is called.
- Since the tasks in question are user-specific, they cannot be included in the CloudStack-provided qemu script.
@@ -848,7 +848,7 @@ Usage
#. Sub-operation indication, or '-' if there is none.
#. An extra argument string, or '-' if there is none.
-- The operation argument is based on what actions KVM and Libvirt are carrying out on each VM: 'prepare', 'start', 'started', 'stopped', 'release', 'migrate', 'restore', 'reconnect', 'attach'.
+- The operation argument is based on what actions KVM and Libvirt are carrying out on each Instance: 'prepare', 'start', 'started', 'stopped', 'release', 'migrate', 'restore', 'reconnect', 'attach'.
- If an invalid operation argument is received, the qemu script will log the fact, not execute any custom scripts and exit.
@@ -875,18 +875,18 @@ Timeout Configuration
#. Find the "timeoutSeconds" timeout setting.
#. Change the 10 * 60 value to a preferred timeout value. For example 20 * 60, for a 20-minute timeout.
-Custom Script Naming for a Specific VM Action
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- For a custom script that needs to be executed at the end of a specific VM action, do the following:
+Custom Script Naming for a Specific Instance Action
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+- For a custom script that needs to be executed at the end of a specific Instance action, do the following:
#. Navigate to the custom script that needs to be executed for a specific action.
#. Rename the file by prefixing to the filename the specific action name followed by an underscore. For example, if a custom script is named abc.sh, then prefix 'migrate' and an underscore to the name to become migrate_abc.sh.
-Custom Script Naming for All VM Actions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Custom Script Naming for All Instance Actions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- For a custom script that needs to be executed at the end of all VM actions, do the following:
+- For a custom script that needs to be executed at the end of all Instance actions, do the following:
#. Navigate to the custom script that needs to be executed for all actions.
#. Rename the file by prefixing 'all' to the filename, followed by an underscore. For example, if a custom script is named def.py, then prefix 'all' and an underscore to the name to become all_def.py.
diff --git a/source/adminguide/index.rst b/source/adminguide/index.rst
index aeb3cbf..44633e9 100644
--- a/source/adminguide/index.rst
+++ b/source/adminguide/index.rst
@@ -72,8 +72,8 @@ Setting up Networking for Users
autoscale_with_virtual_router
-Working with Virtual Machines
------------------------------
+Working with Instances
+----------------------
.. toctree::
:maxdepth: 4
@@ -115,8 +115,8 @@ Working with Storage
storage
-Working with System Virtual Machines
-------------------------------------
+Working with System VMs
+-----------------------
.. toctree::
:maxdepth: 4
diff --git a/source/adminguide/locale/pot/networking/persistent_networks.pot b/source/adminguide/locale/pot/networking/persistent_networks.pot
index 5db6bc1..ae8f3c4 100644
--- a/source/adminguide/locale/pot/networking/persistent_networks.pot
+++ b/source/adminguide/locale/pot/networking/persistent_networks.pot
@@ -33,7 +33,7 @@ msgstr ""
#: ../../networking/persistent_networks.rst:33
# 87f88f46858c41ba96f785b7c3122342
-msgid "One of the advantages of having a persistent network is that you can create a VPC with a tier consisting of only physical devices. For example, you might create a VPC for a three-tier application, deploy VMs for Web and Application tier, and use physical machines for the Database tier. Another use case is that if you are providing services by using physical hardware, you can define the network as persistent and therefore even if all its VMs are destroyed the services will not be d [...]
+msgid "One of the advantages of having a persistent network is that you can create a VPC with a temtier consisting of only physical devices. For example, you might create a VPC for a three-tier application, deploy VMs for Web and Application tier, and use physical machines for the Database tier. Another use case is that if you are providing services by using physical hardware, you can define the network as persistent and therefore even if all its VMs are destroyed the services will not b [...]
msgstr ""
#: ../../networking/persistent_networks.rst:44
diff --git a/source/adminguide/management.rst b/source/adminguide/management.rst
index 0861ff1..b13086f 100644
--- a/source/adminguide/management.rst
+++ b/source/adminguide/management.rst
@@ -19,14 +19,14 @@ 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.
+tag a User Instance 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.
+have a given tag; for example, Instances 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
+You can tag a User Instance, 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
@@ -84,7 +84,7 @@ The following API commands have the "tags" input parameter:
Using Comments on the Resources in the Cloud
--------------------------------------------
-CloudStack allows users and administrators to create comments against cloud objects with a UUID. The listing page of any cloud object includes a blue icon next to the object name indicating that the object contains comments.
+CloudStack allows Users and administrators to create comments against cloud objects with a UUID. The listing page of any cloud object includes a blue icon next to the object name indicating that the object contains comments.
To create a new comment on an object:
@@ -97,13 +97,13 @@ To create a new comment on an object:
.. note::
Administrators only: Select the 'Only visible to Administrators' checkbox to create private comments across administrators
-To display al the comments created by the logged in user (or administrator):
+To display al the comments created by the logged in User (or administrator):
1. In the left navigation bar, click Tools
2. Click Comments (the default filter is 'Created by me')
-To display all the comments on the objects that the logged in user (or administrator) has access:
+To display all the comments on the objects that the logged in User (or administrator) has access:
1. In the left navigation bar, click Tools
@@ -215,8 +215,8 @@ 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
+Events track all of the User and administrator actions in the cloud. For
+example, every Guest Instance start creates an associated event. Events are
stored in the Management Server’s database.
Emails will be sent to administrators under the following circumstances:
@@ -262,7 +262,7 @@ be found by calling listAlerts.
::
- PUBLIC_IP = 4 // Number of unallocated virtual network public IPs is below configured threshold
+ PUBLIC_IP = 4 // Number of unallocated virtual Network public IPs is below configured threshold
::
@@ -278,7 +278,7 @@ be found by calling listAlerts.
::
- USERVM = 8 // User VM stopped unexpectedly
+ USERVM = 8 // User Instance stopped unexpectedly
::
@@ -302,7 +302,7 @@ be found by calling listAlerts.
::
- MANAGMENT_NODE = 14 // Management network CIDR is not configured originally
+ MANAGMENT_NODE = 14 // Management Network CIDR is not configured originally
::
@@ -314,7 +314,7 @@ be found by calling listAlerts.
::
- USERVM_MIGRATE = 17 // User VM Migration was unsuccessful
+ USERVM_MIGRATE = 17 // User Instance Migration was unsuccessful
::
@@ -342,7 +342,7 @@ be found by calling listAlerts.
::
- DIRECT_ATTACHED_PUBLIC_IP = 24 // Number of unallocated shared network IPs is low in availability zone
+ DIRECT_ATTACHED_PUBLIC_IP = 24 // Number of unallocated shared Network IPs is low in availability zone
::
@@ -350,7 +350,7 @@ be found by calling listAlerts.
::
- RESOURCE_LIMIT_EXCEEDED = 26 //Generated when the resource limit exceeds the limit. Currently used for recurring snapshots only
+ RESOURCE_LIMIT_EXCEEDED = 26 //Generated when the resource limit exceeds the limit. Currently used for recurring Snapshots only
You can also display the most up to date list by calling the API command ``listAlerts``.
@@ -445,7 +445,7 @@ alerts from CloudStack:
</appender>
#. If your cloud has multiple Management Server nodes, repeat these
- steps to edit log4j-cloud.xml on every instance.
+ steps to edit log4j-cloud.xml on every Instance.
#. If you have made these changes while the Management Server is
running, wait a few minutes for the change to take effect.
@@ -469,20 +469,20 @@ 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
+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
+ - At the Network level, the DNS suffix can be assigned through the
+ UI when creating a new Network, as described in
`“Adding an Additional Guest Network”
<networking2#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
+ - 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.
@@ -492,25 +492,25 @@ these steps.
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
+#. 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.
+ when the DNS suffix was specified while creating a new Network.
-The source of the network domain that is used depends on the following
+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 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
+- 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
+- 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
+- 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/source/adminguide/networker_plugin.rst b/source/adminguide/networker_plugin.rst
index c8f192f..c3b2ba7 100644
--- a/source/adminguide/networker_plugin.rst
+++ b/source/adminguide/networker_plugin.rst
@@ -40,15 +40,15 @@ KVM Hypervisor(s)
#. Hypervisor must be associated with the DELL EMC Networker server as CLIENT
#. DELL EMC Networker can connect and verify certificates to the Hyper-v Client
#. A Hypervisor must be in UP and ENABLED state and resource state respectively in order to be able to get backups
- for the VMS running.
+ for the Instances running.
#. A proper timezone set. Identical to the EMC Networker Server and Management server
#. Proper DNS resolution of the EMC Networker server
-Virtual Machines
+Instances
#. It is HIGHLY recommended to run qemu-guest-agent on the Machines you are planning to backup.
-#. There has been no testing regarding KVM Primary Storage snapshots and possible problems with EMC DELL Networker plugin
-#. In case you are using KVM Primary Storage snapshots, you have EMC Networker and you want to proceed with the
+#. There has been no testing regarding KVM Primary Storage Snapshots and possible problems with EMC DELL Networker plugin
+#. In case you are using KVM Primary Storage Snapshots, you have EMC Networker and you want to proceed with the
installation of this plugin proceed with extreme caution.
General Concepts
@@ -58,18 +58,18 @@ General Concepts
will expire. Restricted data zones can also be defined in POLICIES to create fine grain permissions.
#. As per EMC Networker Glossary and design those POLICIES are not actually used. They act as a placeholder
for the backup offerings and the retention policies.
-#. DELL EMC Networker has no ability to initiate backup tasks for KVM Virtual Machines at the moment.
+#. DELL EMC Networker has no ability to initiate backup tasks for KVM Instances at the moment.
The implementation is based on manual save sets initiated by the Cloudstack Networker plugin.
#. The tag -CSBKP- in the comment of the POLICY indicates that this policy is available to Cloudstack
Other POLICIES used in your infrastructure will not be visible inside Cloudstack. It is recommended to create
brand new POLICIES dedicated to Cloudstack and settings the Protection Periods to match the backup plan retention
you wish to enable for each of the offerings.
#. For each KVM Cluster you have, a relevant dummy client must be created in the DELL EMC Networker. This is used as a
- placeholder for being able to backup and restore your Virtual Machines from all hosts within the cluster.
+ placeholder for being able to backup and restore your Instances from all hosts within the cluster.
#. Cross cluster restores are indirectly supported by restoring to the original cluster and then migrating the Virtual
Machine to the destination cluster.
#. Any manual KVM backup you initiate (from the hyper-v command line) will be registered in Cloudstack automatically.
- You need to use the client scripts and pass the proper parameteres to do so.
+ You need to use the client scripts and pass the proper parameters to do so.
#. Any backup you expire/remove from the DELL EMC Networker side will be unregistered in Cloudstack automatically.
Installing DELL EMC Networker Backup and Recovery Plugin
@@ -83,8 +83,8 @@ performed in advance. Kindly make sure that DNS resolution, Timezones and system
Cloudstack Management Servers and DELL EMC Networker Server. Do not forget to perform your staging actions (if any)
before the savesets expire.
-Depending on your topology, network bandwidth, backend storage speeds, number of customer VMs you should carefully plan,
-design and implement the Storage volumes, media pools. If you have multiple VMs that your customers want to be processed
+Depending on your topology, network bandwidth, backend storage speeds, number of customer Instances you should carefully plan,
+design and implement the Storage volumes, media pools. If you have multiple Instances that your customers want to be processed
at the same time (e.g Friday night, end of business day in your timezone) this can easily overwhelm your resources since
the backups are initiated outside DELL EMC Networker.
diff --git a/source/adminguide/networking.rst b/source/adminguide/networking.rst
index 2b2dec0..69abb7f 100644
--- a/source/adminguide/networking.rst
+++ b/source/adminguide/networking.rst
@@ -48,7 +48,7 @@ or isolated.
Isolated Networks
~~~~~~~~~~~~~~~~~
-An isolated network can be accessed only by virtual machines of a single
+An isolated network can be accessed only by Instances of a single
account. Isolated networks have the following properties.
- Resources such as VLAN are allocated and garbage collected
@@ -66,12 +66,12 @@ For more information, see `“Configure Guest Traffic in an Advanced Zone”
Shared Networks
~~~~~~~~~~~~~~~
-A shared network can be accessed by virtual machines that belong to many
+A shared network can be accessed by Instances that belong to many
different accounts. Network Isolation on shared networks is accomplished
by using techniques such as security groups, which is supported only in
Basic zones or Advanced Zones with Security Groups.
-- Shared Networks are created by the the end users or the administrator. Network offerings
+- Shared Networks are created by the end users or the administrator. Network offerings
which allow the network creator to specify a VLAN can only be created
by the root admins.
@@ -104,9 +104,9 @@ IP addresses.
which allow the network creator to specify a VLAN can only be created
by the root admins.
-- CloudStack does not assign IP addresses to VMs.
+- CloudStack does not assign IP addresses to instances.
-- Userdata and metadata can be passed to the VM using a config drive
+- Userdata and metadata can be passed to the instance using a config drive
(which must be enabled in the network service offering)
Example GUI dialog box (for a regular user account) is shown below:
@@ -119,8 +119,8 @@ 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
+activated only when the first Instance starts in the network.
+When all Instances have left the virtual network, the network
resources are garbage collected so they can be allocated again. This
helps to conserve network resources.
@@ -210,8 +210,8 @@ A network offering is a named set of network services, such as:
- (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.
+When creating a new instance, the user chooses one of the available network
+offerings, and that determines which network services the instance can use.
The CloudStack administrator can create any number of custom network
offerings, in addition to the default network offerings provided by
@@ -271,14 +271,14 @@ To create a network offering:
- **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
+ deploy an instance on it is termed persistent network. For more
information, see `“Persistent
Networks” <networking_and_traffic.html#persistent-networks>`_.
- **Specify VLAN**. 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
+ creating a VPC Network 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
@@ -290,7 +290,7 @@ To create a network offering:
- **Promiscuous Mode**. Applicable for guest networks on VMware hypervisor only. It accepts the following values for desired behaviour of the network elements:
- *Reject* - The switch drops any outbound frame from a virtual machine adapter with a source MAC address that is different from the one in the .vmx configuration file.
+ *Reject* - The switch drops any outbound frame from an Instance adapter with a source MAC address that is different from the one in the .vmx configuration file.
*Accept* - The switch does not perform filtering, and permits all outbound frames.
@@ -298,7 +298,7 @@ To create a network offering:
- **Forged Transmits**. Applicable for guest networks on VMware hypervisor only. It accepts the following values for desired behaviour of the network elements:
- *Reject* - The switch drops any outbound frame from a virtual machine adapter with a source MAC address that is different from the one in the .vmx configuration file.
+ *Reject* - The switch drops any outbound frame from an Instance adapter with a source MAC address that is different from the one in the .vmx configuration file.
*Accept* - The switch does not perform filtering, and permits all outbound frames.
@@ -306,11 +306,11 @@ To create a network offering:
- **MAC Address Changes**. Applicable for guest networks on VMware hypervisor only. It accepts the following values for desired behaviour of the network elements:
- *Reject* - If the guest OS changes the effective MAC address of the virtual machine to a value that is different from the MAC address of the VM network adapter (set in the .vmx configuration file), the switch drops all inbound frames to the adapter.
+ *Reject* - If the guest OS changes the effective MAC address of the Instance to a value that is different from the MAC address of the instance network adapter (set in the .vmx configuration file), the switch drops all inbound frames to the adapter.
- If the guest OS changes the effective MAC address of the virtual machine back to the MAC address of the VM network adapter, the virtual machine receives frames again.
+ If the guest OS changes the effective MAC address of the Instance back to the MAC address of the instance network adapter, the Instance receives frames again.
- *Accept* - If the guest OS changes the effective MAC address of the virtual machine to a value that is different from the MAC address of the VM network adapter, the switch allows frames to the new address to pass.
+ *Accept* - If the guest OS changes the effective MAC address of the Instance to a value that is different from the MAC address of the instance network adapter, the switch allows frames to the new address to pass.
*None* - Default to value from global setting - ``network.mac.address.changes``.
@@ -414,7 +414,7 @@ To create a network offering:
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
+ a public IP address to the instances deployed in the guest network. This
option is available only if
- Guest network is shared.
@@ -430,16 +430,16 @@ To create a network offering:
if you want to use two virtual routers in the network for
uninterrupted connection: one operating as the primary virtual
router and the other as the backup. The primary virtual router
- receives requests from and sends responses to the user’s VM. The
+ receives requests from and sends responses to the user’s instance. The
backup virtual router is activated only when the primary is down.
After the failover, the backup becomes the primary virtual router.
CloudStack deploys the routers on different hosts to ensure
reliability if one host is down.
- - **Supports VM auto scaling**: Indicate whether VM autoscaling feature
+ - **Supports instance auto scaling**: Indicate whether instance autoscaling feature
is supported. It is available only when Virtual Router or Netscaler
is selected as the Load Balancer provider. For more information on
- VM autoscaling using Virtual Router, see `“Configuring AutoScale
+ instance autoscaling using Virtual Router, see `“Configuring AutoScale
with using CloudStack Virtual Router” <autoscale_with_virtual_router.html>`_.
- **Conserve mode**: Indicate whether to use conserve mode. In this
diff --git a/source/adminguide/networking/advanced_zone_config.rst b/source/adminguide/networking/advanced_zone_config.rst
index 40e3cda..3d8299c 100644
--- a/source/adminguide/networking/advanced_zone_config.rst
+++ b/source/adminguide/networking/advanced_zone_config.rst
@@ -19,7 +19,7 @@ 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
+Management Server how the physical Network is set up to carry different
kinds of traffic in isolation.
@@ -27,58 +27,58 @@ 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:
+configure the base guest Network:
#. In the left navigation, choose Network.
-#. Click Add network.
+#. Click Add Network.
- The Add guest network window is displayed:
+ The Add guest Network window is displayed:
|addguestnetwork.png|
-#. Provide the following information for creating an isolated network:
+#. Provide the following information for creating an isolated Network:
- - **Name**: The name of the network. This will be user-visible
+ - **Name**: The name of the Network. This will be User-visible
- - **Description**: The description of the network. This will be
- user-visible
+ - **Description**: The description of the Network. This will be
+ User-visible
- - **Zone**: The zone in which you are configuring the guest network.
+ - **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
+ Network offerings, select the one you want to use for this Network
- **Public MTU**: The MTU that will be configured on the public interfaces
- of the network's VR.
- **NOTE:** This will not be considered for VPC network tiers, as the
- public MTU defined at the VPC network creation level will be considered
+ of the Network's VR.
+ **NOTE:** This will not be considered for VPC Network Tiers, as the
+ public MTU defined at the VPC Network creation level will be considered
- **Private MTU**: The MTU that will configured on the private interface(s)
- of the network's VR
+ of the Network's VR
- - **External Id**: ID of the network in an external system.
+ - **External Id**: ID of the Network in an external system.
- - **Gateway**: The gateway that the guests instances will use.
+ - **Gateway**: The gateway that the guests Instances will use.
- - **Netmask**: The netmask in use on the subnet the guest instances
+ - **Netmask**: The netmask in use on the subnet the Guest Instances
will use.
- - **DNS**: A set of custom DNS that will be used by the guest network. If not provided then DNS specified for the zone will be used. Available only when the selected network offering supports DNS service.
+ - **DNS**: A set of custom DNS that will be used by the guest Network. If not provided then DNS specified for the zone will be used. Available only when the selected Network offering supports DNS service.
- - **IPv6 DNS**: A set of custom IPv6 DNS that will be used by the guest network. If not provided then IPv6 DNS specified for the zone will be used. Available only when the selected network offering is IPv6 enabled and supports DNS service.
+ - **IPv6 DNS**: A set of custom IPv6 DNS that will be used by the guest Network. If not provided then IPv6 DNS specified for the zone will be used. Available only when the selected Network offering is IPv6 enabled and supports DNS service.
- - **IPv4 address for the VR in this Network**: The source NAT address or primary public network address to use by the guest network. If not provided then a random address from the available pool of addresses wil be used.
+ - **IPv4 address for the VR in this Network**: The source NAT address or primary public Network address to use by the guest Network. If not provided then a random address from the available pool of addresses wil be used.
- - **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
+ - **Network Domain**: A custom DNS suffix at the level of a Network. If you
+ want to assign a special domain name to the Guest Instance Network, specify a
DNS suffix.
#. Click OK.
.. note::
- * In security groups-enabled Advanced zones and Basic zones, creation of VPC and isolated networks are not supported.
+ * In security groups-enabled Advanced zones and Basic zones, creation of VPC and isolated Networks are not supported.
* MTU options will be shown in the UI and considered only when zone configuration - `allow.end.users.to.specify.vr.mtu` is set to true. Maximum allowed values for public and private MTU can be controlled by zone-level configurations, `vr.public.interface.max.mtu` and `vr.private.interface.max.mtu` respectively.
Configure Public Traffic in an Advanced Zone
@@ -91,105 +91,105 @@ one range of IP addresses for Internet traffic.
Configuring a Shared Guest Network
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-#. Log in to the CloudStack UI as administrator or an end user.
+#. Log in to the CloudStack UI as administrator or an end User.
#. In the left navigation, choose Network.
-#. Click the Guest networks tab
+#. Click the Guest Networks tab
-#. Click the Add network icon.
+#. Click the Add Network icon.
#. Click the Shared tab.
- The Add guest network window is displayed.
+ The Add guest Network window is displayed.
|addsharednetwork.png|
#. Specify the following:
- - **Name**: The name of the network. This will be visible to the user.
+ - **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.
+ - **Description**: The short description of the Network that can be
+ displayed to Users.
- - **Zone**: The zone for the network.
+ - **Zone**: The zone for the Network.
- - **Physical Network**: The physical network ID the network belongs to.
+ - **Physical Network**: The physical Network ID the Network belongs to.
- **VLAN ID**: (Administrators only) The unique ID of the VLAN.
- **Secondary VLAN Type**: (Administrators only) The isolation private
- VLAN type for this network
+ VLAN type for this Network
- **Secondary VLAN ID**: (Administrators only) The unique ID of the
Secondary Isolated VLAN.
- **Bypass VLAN id/range overlap**: (Administrators only) When true
- bypasses VLAN id/range overlap check during network creation for
- shared and L2 networks
+ bypasses VLAN id/range overlap check during Network creation for
+ shared and L2 Networks
- **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
+ 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 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
+ - **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
+ - **Project**: The project for which the guest Network is being
created for. You must specify the domain the project belongs
to.
- - **All**: (Administrators only) The guest network is available
- for all the domains, account, projects within the selected zone.
+ - **All**: (Administrators only) 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.
+ Network offerings, select the one you want to use for this
+ Network.
- **Public MTU**: The MTU that will be configured on the public interfaces
- of the network's VR. This MTU will considered for redundant VRs
+ of the Network's VR. This MTU will considered for redundant VRs
- **Private MTU**: The MTU that will configured on the private interface(s)
- of the network's VR
+ of the Network's VR
- - **Associated Network**: The L2 or Isolated network this network is
- associated to. This network will use same VLAN as associated network.
- This will be visible if network offering has specifyvlan is false.
+ - **Associated Network**: The L2 or Isolated Network this Network is
+ associated to. This Network will use same VLAN as associated Network.
+ This will be visible if Network offering has specifyvlan is false.
- **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.
+ Internet and are assigned to the Guest Instances.
- - **DNS**: A set of custom DNS that will be used by the network. If not provided then DNS specified for the zone will be used. Available only when the selected network offering supports DNS service.
+ - **DNS**: A set of custom DNS that will be used by the Network. If not provided then DNS specified for the zone will be used. Available only when the selected Network offering supports DNS service.
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
+ - **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
+ in the guest Networks in this zone. To allot IP addresses from
within a particular address block, enter a CIDR.
- - **IPv6 DNS**: A set of custom IPv6 DNS that will be used by the network. If not provided then IPv6 DNS specified for the zone will be used. Available only when the selected network offering supports DNS service.
+ - **IPv6 DNS**: A set of custom IPv6 DNS that will be used by the Network. If not provided then IPv6 DNS specified for the zone will be used. Available only when the selected Network offering supports DNS service.
- - **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.
+ - **Network Domain**: A custom DNS suffix at the level of a Network.
+ If you want to assign a special domain name to the Guest Instance
+ Network, specify a DNS suffix.
#. Click OK to confirm.
.. note::
- * End users (not administrator) can only use the network
- offerings with specifyvlan is false. Please create a network offering
+ * End users (not administrator) can only use the Network
+ offerings with specifyvlan is false. Please create a Network offering
with specifyvlan is false to enable this for end users. See
`“Creating a New Network Offering”
<networking.html#creating-a-new-network-offering>`_.
@@ -200,4 +200,4 @@ Configuring a Shared Guest Network
:alt: Add Guest network setup in a single zone.
.. |addsharednetwork.png| image:: /_static/images/add-shared-network.png
- :alt: Add Shared Guest network.
+ :alt: Add Shared Guest Network.
diff --git a/source/adminguide/networking/basic_zone_config.rst b/source/adminguide/networking/basic_zone_config.rst
index a1ba26c..692d011 100644
--- a/source/adminguide/networking/basic_zone_config.rst
+++ b/source/adminguide/networking/basic_zone_config.rst
@@ -20,5 +20,5 @@ 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
+traffic that is generated by Guest Instances. When you first add a zone to
CloudStack, you set up the guest network through the Add Zone screens.
\ No newline at end of file
diff --git a/source/adminguide/networking/elastic_ips.rst b/source/adminguide/networking/elastic_ips.rst
index fe83a3b..2eb02a0 100644
--- a/source/adminguide/networking/elastic_ips.rst
+++ b/source/adminguide/networking/elastic_ips.rst
@@ -20,11 +20,11 @@ About Elastic IPs
Elastic IP (EIP) addresses are the IP addresses that are associated with
an account, and act as static IP addresses. The account owner has the
complete control over the Elastic IP addresses that belong to the
-account. As an account owner, you can allocate an Elastic IP to a VM of
+account. As an account owner, you can allocate an Elastic IP to an instance of
your choice from the EIP pool of your account. Later if required you can
-reassign the IP address to a different VM. This feature is extremely
-helpful during VM failure. Instead of replacing the VM which is down,
-the IP address can be reassigned to a new VM in your account.
+reassign the IP address to a different instance. This feature is extremely
+helpful during instance failure. Instead of replacing the instance which is down,
+the IP address can be reassigned to a new instance in your account.
Similar to the public IP address, Elastic IP addresses are mapped to
their associated private IP addresses by using StaticNAT. The EIP
@@ -47,11 +47,11 @@ through the firewall.
The EIP work flow is as follows:
-- When a user VM is deployed, a public IP is automatically acquired
+- When a user instance is deployed, a public IP is automatically acquired
from the pool of public IPs configured in the zone. This IP is owned
- by the VM's account.
+ by the instance's account.
-- Each VM will have its own private IP. When the user VM starts, Static
+- Each instance will have its own private IP. When the user instance starts, Static
NAT is provisioned on the NetScaler device by using the Inbound
Network Address Translation (INAT) and Reverse NAT (RNAT) rules
between the public IP and the private IP.
@@ -59,21 +59,21 @@ The EIP work flow is as follows:
.. note::
Inbound NAT (INAT) is a type of NAT supported by NetScaler, in which
the destination IP address is replaced in the packets from the public
- network, such as the Internet, with the private IP address of a VM in
+ network, such as the Internet, with the private IP address of an instance in
the private network. Reverse NAT (RNAT) is a type of NAT supported by
NetScaler, in which the source IP address is replaced in the packets
- generated by a VM in the private network with the public IP address.
+ generated by an instance in the private network with the public IP address.
- This default public IP will be released in two cases:
- - When the VM is stopped. When the VM starts, it again receives a
+ - When the instance is stopped. When the instance starts, it again receives a
new public IP, not necessarily the same one allocated initially,
from the pool of Public IPs.
- The user acquires a public IP (Elastic IP). This public IP is
associated with the account, but will not be mapped to any private
IP. However, the user can enable Static NAT to associate this IP
- to the private IP of a VM in the account. The Static NAT rule for
+ to the private IP of an instance in the account. The Static NAT rule for
the public IP can be disabled at any time. When Static NAT is
disabled, a new public IP is allocated from the pool, which is not
necessarily be the same one allocated initially.
@@ -83,21 +83,21 @@ flexibility to choose not to allocate a public IP by default. You can
use the Associate Public IP option to turn on or off the automatic
public IP assignment in the EIP-enabled Basic zones. If you turn off the
automatic public IP assignment while creating a network offering, only a
-private IP is assigned to a VM when the VM is deployed with that network
-offering. Later, the user can acquire an IP for the VM and enable static
+private IP is assigned to an instance when the instance is deployed with that network
+offering. Later, the user can acquire an IP for the instance and enable static
NAT.
For more information on the Associate Public IP option, see
`"Creating a New Network Offering" <networking.html#creating-a-new-network-offering>`_.
.. note::
- The Associate Public IP feature is designed only for use with user VMs.
+ The Associate Public IP feature is designed only for use with user instances.
The System VMs continue to get both public IP and private by default,
irrespective of the network offering configuration.
New deployments which use the default shared network offering with EIP
and ELB services to create a shared network in the Basic zone will
-continue allocating public IPs to each user VM.
+continue allocating public IPs to each user instance.
.. |eip-ns-basiczone.png| image:: /_static/images/eip-ns-basiczone.png
diff --git a/source/adminguide/networking/external_firewalls_and_load_balancers.rst b/source/adminguide/networking/external_firewalls_and_load_balancers.rst
index 31c16d0..be58c02 100644
--- a/source/adminguide/networking/external_firewalls_and_load_balancers.rst
+++ b/source/adminguide/networking/external_firewalls_and_load_balancers.rst
@@ -19,14 +19,14 @@ 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
+balancer for gateway and load balancing services. In this case, the instances
use the SRX as their gateway.
About Using a NetScaler Load Balancer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Citrix NetScaler is supported as an external network element for load
+Citrix NetScaler is supported as an external Network element for load
balancing in zones that use isolated networking in advanced zones. Set
up an external load balancer when you want to provide load balancing
through means other than CloudStack's provided virtual router.
@@ -36,21 +36,21 @@ through means other than CloudStack's provided virtual router.
Elastic IP or Elastic LB services are enabled.
When NetScaler load balancer is used to provide EIP or ELB services in a
-Basic zone, ensure that all guest VM traffic must enter and exit through
+Basic zone, ensure that all Guest Instance traffic must enter and exit through
the NetScaler device. When inbound traffic goes through the NetScaler
device, traffic is routed by using the NAT protocol depending on the
EIP/ELB configured on the public IP to the private IP. The traffic that
-is originated from the guest VMs usually goes through the layer 3
+is originated from the Guest Instances usually goes through the layer 3
router. To ensure that outbound traffic goes through NetScaler device
providing EIP/ELB, layer 3 router must have a policy-based routing. A
policy-based route must be set up so that all traffic originated from
-the guest VM's are directed to NetScaler device. This is required to
-ensure that the outbound traffic from the guest VM's is routed to a
+the Guest Instance's are directed to NetScaler device. This is required to
+ensure that the outbound traffic from the Guest Instance's is routed to a
public IP by using NAT.For more information on Elastic IP, see
`"About Elastic IP" <#about-elastic-ip>`_.
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
+must be added before any load balancing rules are deployed on Guest Instances
in the zone.
The functional behavior of the NetScaler with CloudStack is the same as
@@ -76,7 +76,7 @@ summarizes how these variants are treated in CloudStack.
**VPX**
-- Virtual appliance. Can run as VM on XenServer, ESXi, and Hyper-V
+- Virtual appliance. Can run as instance on XenServer, ESXi, and Hyper-V
hypervisors. Same functionality as MPX
- Supported on ESXi and XenServer. Same functional support as for MPX.
@@ -98,12 +98,12 @@ Configuring SNMP Community String on a RHEL Server
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The SNMP Community string is similar to a user id or password that
-provides access to a network device, such as router. This string is sent
+provides access to a Network device, such as router. This string is sent
along with all SNMP requests. If the community string is correct, the
device responds with the requested information. If the community string
is incorrect, the device discards the request and does not respond.
-The NetScaler device uses SNMP to communicate with the VMs. You must
+The NetScaler device uses SNMP to communicate with the instances. You must
install SNMP and configure SNMP Community string for a secure
communication between the NetScaler device and the RHEL machine.
@@ -180,8 +180,8 @@ communication between the NetScaler device and the RHEL machine.
Initial Setup of External Firewalls and Load Balancers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-When the first VM is created for a new account, CloudStack programs the
-external firewall and load balancer to work with the VM. The following
+When the first instance is created for a new account, CloudStack programs the
+external firewall and load balancer to work with the instance. The following
objects are created on the firewall:
- A new logical interface to connect to the account's private VLAN. The
@@ -209,14 +209,14 @@ 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
+to specific instances. This is accomplished by enabling static NAT for a
+public IP address, assigning the IP to an instance, and specifying a set of
protocols and port ranges to open. When a static NAT rule is created,
CloudStack 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.
+ address of an instance.
- A security policy that allows traffic within the set of protocols and
port ranges that are specified.
@@ -234,14 +234,14 @@ 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
+balance traffic received at a public IP to one or more instances. A user
creates a rule, specifies an algorithm, and assigns the rule to a set of
-VMs.
+instances.
.. note::
- If you create load balancing rules while using a network service
+ 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
+ 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.
@@ -256,7 +256,7 @@ Adding a Load Balancer Rule
#. In the left navigation, choose Network.
-#. Click the name of the network where you want to load balance the
+#. Click the name of the Network where you want to load balance the
traffic.
#. Click Public IP Addresses.
@@ -270,7 +270,7 @@ Adding a Load Balancer Rule
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
+ To do that, select the name of the Network, then click Add Load
Balancer tab. Continue with #7.
#. Fill in the following:
@@ -280,7 +280,7 @@ Adding a 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
+ - **Private Port**: The port that the instances will use to receive the
traffic.
- **Algorithm**: Choose the load balancing algorithm you want
@@ -318,7 +318,7 @@ Adding a Load Balancer Rule
health check failures that are required before declaring an
instance unhealthy. Default: 10.
-#. Click Add VMs, then select two or more VMs that will divide the load
+#. Click Add instances, then select two or more instances that will divide the load
of incoming traffic, and click Apply.
The new load balancer rule appears in the list. You can repeat these
@@ -456,7 +456,7 @@ the resource later becomes available again, the periodic health check
will discover it, and the resource will once again be added to the pool
of resources that can receive requests from the load balancer. At any
given time, the most recent result of the health check is displayed in
-the UI. For any VM that is attached to a load balancer rule with a
+the UI. For any instance that is attached to a load balancer rule with a
health check configured, the state will be shown as UP or DOWN in the UI
depending on the result of the most recent health check.
@@ -477,20 +477,20 @@ Configuring AutoScale
~~~~~~~~~~~~~~~~~~~~~
AutoScaling allows you to scale your back-end services or application
-VMs up or down seamlessly and automatically according to the conditions
+instances up or down seamlessly and automatically according to the conditions
you define. With AutoScaling enabled, you can ensure that the number of
-VMs you are using seamlessly scale up when demand increases, and
+instances you are using seamlessly scale up when demand increases, and
automatically decreases when demand subsides. Thus it helps you save
-compute costs by terminating underused VMs automatically and launching
-new VMs when you need them, without the need for manual intervention.
+compute costs by terminating underused instances automatically and launching
+new instances when you need them, without the need for manual intervention.
-NetScaler AutoScaling is designed to seamlessly launch or terminate VMs
+NetScaler AutoScaling is designed to seamlessly launch or terminate instances
based on user-defined conditions. Conditions for triggering a scaleup or
scaledown action can vary from a simple use case like monitoring the CPU
usage of a server to a complex use case of monitoring a combination of
server's responsiveness and its CPU usage. For example, you can
-configure AutoScaling to launch an additional VM whenever CPU usage
-exceeds 80 percent for 15 minutes, or to remove a VM whenever CPU usage
+configure AutoScaling to launch an additional instance whenever CPU usage
+exceeds 80 percent for 15 minutes, or to remove an instance whenever CPU usage
is less than 20 percent for 30 minutes.
CloudStack uses the NetScaler load balancer to monitor all aspects of a
@@ -507,12 +507,12 @@ Prerequisites
Before you configure an AutoScale rule, consider the following:
- Ensure that the necessary template is prepared before configuring
- AutoScale. When a VM is deployed by using a template and when it
+ AutoScale. When an instance is deployed by using a template and when it
comes up, the application should be up and running.
.. note::
If the application is not running, the NetScaler device considers the
- VM as ineffective and continues provisioning the VMs unconditionally
+ instance as ineffective and continues provisioning the instances unconditionally
until the resource limit is exhausted.
- Deploy the templates you prepared. Ensure that the applications come
@@ -523,7 +523,7 @@ Before you configure an AutoScale rule, consider the following:
- The AutoScale feature supports the SNMP counters that can be used to
define conditions for taking scale up or scale down actions. To
monitor the SNMP-based counter, ensure that the SNMP agent is
- installed in the template used for creating the AutoScale VMs, and
+ installed in the template used for creating the AutoScale instances, and
the SNMP operations work with the configured SNMP community and port
by using standard SNMP managers. For example, see
`"Configuring SNMP Community String on a RHELServer"
@@ -547,9 +547,9 @@ Before you configure an AutoScale rule, consider the following:
the user participates in are disabled and then enabled to reflect the
configuration changes in the NetScaler.
-- In an advanced Zone, ensure that at least one VM should be present
- before configuring a load balancer rule with AutoScale. Having one VM
- in the network ensures that the network is in implemented state for
+- In an advanced Zone, ensure that at least one instance should be present
+ before configuring a load balancer rule with AutoScale. Having one instance
+ in the Network ensures that the Network is in implemented state for
configuring AutoScale.
@@ -562,52 +562,52 @@ Specify the following:
- **Template**: A template consists of a base OS image and application.
A template is used to provision the new instance of an application on
- a scaleup action. When a VM is deployed from a template, the VM can
+ a scaleup action. When an instance is deployed from a template, the instance can
start taking the traffic from the load balancer without any admin
- intervention. For example, if the VM is deployed for a Web service,
+ intervention. For example, if the instance is deployed for a Web service,
it should have the Web server running, the database connected, and so
on.
- **Compute offering**: A predefined set of virtual hardware
attributes, including CPU speed, number of CPUs, and RAM size, that
- the user can select when creating a new virtual machine instance.
- Choose one of the compute offerings to be used while provisioning a
- VM instance as part of scaleup action.
+ the user can select when creating a new Instance.
+ Choose one of the compute offerings to be used while provisioning an
+ Instance as part of scaleup action.
-- **Min Instance**: The minimum number of active VM instances that is
- assigned to a load balancing rule. The active VM instances are the
+- **Min Instance**: The minimum number of active instances that is
+ assigned to a load balancing rule. The active instances are the
application instances that are up and serving the traffic, and are
being load balanced. This parameter ensures that a load balancing
- rule has at least the configured number of active VM instances are
+ rule has at least the configured number of active instances are
available to serve the traffic.
.. note::
- If an application, such as SAP, running on a VM instance is down for
- some reason, the VM is then not counted as part of Min Instance
+ If an application, such as SAP, running on an instance is down for
+ some reason, the instance is then not counted as part of Min Instance
parameter, and the AutoScale feature initiates a scaleup action if
- the number of active VM instances is below the configured value.
+ the number of active instances is below the configured value.
Similarly, when an application instance comes up from its earlier
down state, this application instance is counted as part of the
active instance count and the AutoScale process initiates a scaledown
action when the active instance count breaches the Max instance
value.
-- **Max Instance**: Maximum number of active VM instances that **should
+- **Max Instance**: Maximum number of active instances that **should
be assigned to**\ a load balancing rule. This parameter defines the
- upper limit of active VM instances that can be assigned to a load
+ upper limit of active instances that can be assigned to a load
balancing rule.
Specifying a large value for the maximum instance parameter might
- result in provisioning large number of VM instances, which in turn
- leads to a single load balancing rule exhausting the VM instances
+ result in provisioning large number of instances, which in turn
+ leads to a single load balancing rule exhausting the instances
limit specified at the account or domain level.
.. note::
- If an application, such as SAP, running on a VM instance is down for
- some reason, the VM is not counted as part of Max Instance parameter.
- So there may be scenarios where the number of VMs provisioned for a
+ If an application, such as SAP, running on an instance is down for
+ some reason, the instance is not counted as part of Max Instance parameter.
+ So there may be scenarios where the number of instances provisioned for a
scaleup action might be more than the configured Max Instance value.
- Once the application instances in the VMs are up from an earlier down
+ Once the application instances in the instances are up from an earlier down
state, the AutoScale feature starts aligning to the configured Max
Instance value.
@@ -645,33 +645,33 @@ advanced settings, and specify the following:
- **Quiet Time**: This is the cool down period after an AutoScale
action is initiated. The time includes the time taken to complete
- provisioning a VM instance from its template and the time taken by an
+ provisioning an instance from its template and the time taken by an
application to be ready to serve traffic. This quiet time allows the
fleet to come up to a stable state before any action can take place.
The default is 300 seconds.
-- **Destroy VM Grace Period**: The duration in seconds, after a
- scaledown action is initiated, to wait before the VM is destroyed as
+- **Destroy Instance Grace Period**: The duration in seconds, after a
+ scaledown action is initiated, to wait before the instance is destroyed as
part of scaledown action. This is to ensure graceful close of any
- pending sessions or transactions being served by the VM marked for
+ pending sessions or transactions being served by the instance marked for
destroy. The default is 120 seconds.
- **Security Groups**: Security groups provide a way to isolate traffic
- to the VM instances. A security group is a group of VMs that filter
+ to the instances. A security group is a group of instances that filter
their incoming and outgoing traffic according to a set of rules,
- called ingress and egress rules. These rules filter network traffic
+ called ingress and egress rules. These rules filter Network traffic
according to the IP address that is attempting to communicate with
- the VM.
+ the instance.
- **Disk Offerings**: A predefined set of disk size for primary data
storage.
- **SNMP Community**: The SNMP community string to be used by the
NetScaler device to query the configured counter value from the
- provisioned VM instances. Default is public.
+ provisioned instances. Default is public.
- **SNMP Port**: The port number on which the SNMP agent that run on
- the provisioned VMs is listening. Default port is 161.
+ the provisioned instances is listening. Default port is 161.
- **User**: This is the user that the NetScaler device use to invoke
scaleup and scaledown API calls to the cloud. If no option is
@@ -684,7 +684,7 @@ advanced settings, and specify the following:
Disabling and Enabling an AutoScale Configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-If you want to perform any maintenance operation on the AutoScale VM
+If you want to perform any maintenance operation on the AutoScale
instances, disable the AutoScale configuration. When the AutoScale
configuration is disabled, no scaleup or scaledown action is performed.
You can use this downtime for the maintenance activities. To disable the
@@ -715,20 +715,20 @@ again, then click the Enable AutoScale button.
Runtime Considerations
^^^^^^^^^^^^^^^^^^^^^^
-- An administrator should not assign a VM to a load balancing rule
+- An administrator should not assign an instance to a load balancing rule
which is configured for AutoScale.
-- Before a VM provisioning is completed if NetScaler is shutdown or
- restarted, the provisioned VM cannot be a part of the load balancing
+- Before an instance provisioning is completed if NetScaler is shutdown or
+ restarted, the provisioned instance cannot be a part of the load balancing
rule though the intent was to assign it to a load balancing rule. To
- workaround, rename the AutoScale provisioned VMs based on the rule
- name or ID so at any point of time the VMs can be reconciled to its
+ workaround, rename the AutoScale provisioned instances based on the rule
+ name or ID so at any point of time the instances can be reconciled to its
load balancing rule.
- Making API calls outside the context of AutoScale, such as destroyVM,
- on an autoscaled VM leaves the load balancing configuration in an
- inconsistent state. Though VM is destroyed from the load balancer
- rule, NetScaler continues to show the VM as a service assigned to a
+ on an autoscaled instance leaves the load balancing configuration in an
+ inconsistent state. Though instance is destroyed from the load balancer
+ rule, NetScaler continues to show the instance as a service assigned to a
rule.
diff --git a/source/adminguide/networking/global_server_load_balancing.rst b/source/adminguide/networking/global_server_load_balancing.rst
index fef3eb7..a357564 100644
--- a/source/adminguide/networking/global_server_load_balancing.rst
+++ b/source/adminguide/networking/global_server_load_balancing.rst
@@ -75,7 +75,7 @@ A typical GSLB environment is comprised of the following components:
services.
- **GSLB Virtual Servers**: A GSLB virtual server refers to one or more
- GSLB services and balances traffic between traffic across the VMs in
+ GSLB services and balances traffic between traffic across the instances in
multiple zones by using the CloudStack functionality. It evaluates
the configured GSLB methods or algorithms to select a GSLB service to
which to send the client requests. One or more virtual servers from
@@ -273,11 +273,11 @@ Prerequisites and Guidelines
A zone shall be considered as GSLB capable only if a GSLB service
provider is provisioned in the zone.
-- When users have VMs deployed in multiple availability zones which are
+- When users have instances deployed in multiple availability zones which are
GSLB enabled, they can use the GSLB functionality to load balance
- traffic across the VMs in multiple zones.
+ traffic across the instances in multiple zones.
-- The users can use GSLB to load balance across the VMs across zones in
+- The users can use GSLB to load balance across the instances across zones in
a region only if the admin has enabled GSLB in that region.
- The users can load balance traffic across the availability zones in
diff --git a/source/adminguide/networking/guest_traffic.rst b/source/adminguide/networking/guest_traffic.rst
index 51374d1..1d5443b 100644
--- a/source/adminguide/networking/guest_traffic.rst
+++ b/source/adminguide/networking/guest_traffic.rst
@@ -17,8 +17,8 @@
Guest Traffic
-------------
-A network can carry guest traffic only between VMs within one zone.
-Virtual machines in different zones cannot communicate with each other
+A network can carry guest traffic only between Instances within one zone.
+Instances 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.
@@ -27,7 +27,7 @@ See a typical guest traffic setup given below:
|guest-traffic-setup.png|
Typically, the Management Server automatically creates a virtual router
-for each network. A virtual router is a special virtual machine that
+for each network. A virtual router is a special Instance that
runs on the hosts. Each virtual router in an isolated network has three
network interfaces. If multiple public VLAN is used, the router will
have multiple public interfaces. Its eth0 interface serves as the
@@ -38,12 +38,12 @@ If multiple public VLAN is used, the router will have multiple public
interfaces.
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
+address for each Guest Instance within the IP range assigned for the network.
+The user can manually reconfigure Guest Instances to assume different IP
addresses.
Source NAT is automatically configured in the virtual router to forward
-outbound traffic for all guest VMs
+outbound traffic for all Guest Instances
.. |guest-traffic-setup.png| image:: /_static/images/guest-traffic-setup.png
diff --git a/source/adminguide/networking/inter_vlan_routing.rst b/source/adminguide/networking/inter_vlan_routing.rst
index fd651a8..93f24e5 100644
--- a/source/adminguide/networking/inter_vlan_routing.rst
+++ b/source/adminguide/networking/inter_vlan_routing.rst
@@ -22,12 +22,12 @@ 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
+your create, and instances 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
+the instances. In effect, you can segment instances 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
+separate application instances for higher security and lower broadcasts, while
remaining physically connected to the same device.
This feature is supported on XenServer, KVM, and VMware hypervisors.
@@ -35,23 +35,23 @@ This feature is supported on XenServer, KVM, 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
+ instances on these VLANs. A guest VLAN is randomly allotted to an account
+ from a pre-specified set of guest VLANs. All the instances 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
+ application. In this scenario, the instances 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
+ network NIC is plugged to the VPC virtual router when the first instance is
deployed in a tier.
- The administrator can create the following gateways to send to or
- receive traffic from the VMs:
+ receive traffic from the instances:
- **VPN Gateway**: For more information, see `"Creating a VPN gateway for the
VPC" <#creating-a-vpn-gateway-for-the-vpc>`_.
@@ -70,12 +70,12 @@ The major advantages are:
For example:
- **VLANs and Public Gateway**: For example, an application is
- deployed in the cloud, and the Web application VMs communicate
+ deployed in the cloud, and the Web application instances 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
+ application is deployed in the cloud; the Web application instances
+ communicate with the Internet; and the database instances communicate
with the on-premise devices.
- The administrator can define Network Access Control List (ACL) on the
diff --git a/source/adminguide/networking/ip_forwarding_and_firewalling.rst b/source/adminguide/networking/ip_forwarding_and_firewalling.rst
index e13fe63..f37faba 100644
--- a/source/adminguide/networking/ip_forwarding_and_firewalling.rst
+++ b/source/adminguide/networking/ip_forwarding_and_firewalling.rst
@@ -26,9 +26,9 @@ 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
+that range to specific ports on user instances. 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.
+to port 100 on one user instance's private IP.
Firewall Rules
@@ -138,7 +138,7 @@ Configuring an Egress Firewall Rule
#. 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 guest network:
+ sent out of instances in this guest network:
|egress-firewall-rule.png|
@@ -148,7 +148,7 @@ Configuring an Egress Firewall Rule
the destination. For example, 192.168.0.0/22. To allow all CIDRs,
set to 0.0.0.0/0.
- - **Protocol**: The networking protocol that VMs uses to send
+ - **Protocol**: The networking protocol that instances uses to send
outgoing traffic. 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.
@@ -224,15 +224,15 @@ 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
+policy. A port forward service is then applied to one or more Guest Instances.
+The Guest Instance 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
+A Guest Instance can be in any number of port forward services. Port forward
+services can be defined but have no members. If a Guest Instance is part of
more than one network, port forwarding rules will function only if they
are defined on the default network
@@ -248,11 +248,11 @@ To set up port forwarding:
zone in CloudStack. See Adding a Zone and Pod in the Installation
Guide.
-#. Add one or more VM instances to CloudStack.
+#. Add one or more instances to CloudStack.
#. In the left navigation bar, click Network.
-#. Click the name of the guest network where the VMs are running.
+#. Click the name of the guest network where the instances are running.
#. Choose an existing IP address or acquire a new IP address. See
`"Acquiring a New IP Address" <#acquiring-a-new-ip-address>`_.
diff --git a/source/adminguide/networking/ip_reservation_in_guest_networks.rst b/source/adminguide/networking/ip_reservation_in_guest_networks.rst
index 028f504..32d4aff 100644
--- a/source/adminguide/networking/ip_reservation_in_guest_networks.rst
+++ b/source/adminguide/networking/ip_reservation_in_guest_networks.rst
@@ -18,24 +18,24 @@ IP Reservation in Isolated Guest Networks
-----------------------------------------
In isolated guest networks, a part of the guest IP address space can be
-reserved for non-CloudStack VMs or physical servers. To do so, you
+reserved for non-CloudStack instances or physical servers. To do so, you
configure a range of Reserved IP addresses by specifying the CIDR when a
guest network is in Implemented state. If your customers wish to have
-non-CloudStack controlled VMs or physical servers on the same network,
+non-CloudStack controlled instances or physical servers on the same network,
they can share a part of the IP address space that is primarily provided
to the guest network.
In an Advanced zone, an IP address range or a CIDR is assigned to a
network when the network is defined. The CloudStack virtual router acts
as the DHCP server and uses CIDR for assigning IP addresses to the guest
-VMs. If you decide to reserve CIDR for non-CloudStack purposes, you can
+instances. If you decide to reserve CIDR for non-CloudStack purposes, you can
specify a part of the IP address range or the CIDR that should only be
-allocated by the DHCP service of the virtual router to the guest VMs
+allocated by the DHCP service of the virtual router to the Guest Instances
created in CloudStack. The remaining IPs in that network are called
Reserved IP Range. When IP reservation is configured, the administrator
-can add additional VMs or physical servers that are not part of
+can add additional instances or physical servers that are not part of
CloudStack to the same network and assign them the Reserved IP
-addresses. CloudStack guest VMs cannot acquire IPs from the Reserved IP
+addresses. CloudStack Guest Instances cannot acquire IPs from the Reserved IP
Range.
@@ -52,13 +52,13 @@ machines:
- No IP Reservation is done by default.
-- Guest VM CIDR you specify must be a subset of the network CIDR.
+- Guest instance CIDR you specify must be a subset of the network CIDR.
-- Specify a valid Guest VM CIDR. IP Reservation is applied only if no
- active IPs exist outside the Guest VM CIDR.
+- Specify a valid Guest instance CIDR. IP Reservation is applied only if no
+ active IPs exist outside the Guest instance CIDR.
- You cannot apply IP Reservation if any VM is alloted with an IP
- address that is outside the Guest VM CIDR.
+ You cannot apply IP Reservation if any instance is alloted with an IP
+ address that is outside the Guest instance CIDR.
- To reset an existing IP Reservation, apply IP reservation by
specifying the value of network CIDR in the CIDR field.
@@ -68,24 +68,24 @@ machines:
.. cssclass:: table-striped table-bordered table-hover
- ===== ============= ============== ======================================== ========================================================
- Case CIDR Network CIDR Reserved IP Range for Non-CloudStack VMs Description
- ===== ============= ============== ======================================== ========================================================
- 1 10.1.1.0/24 None None No IP Reservation.
- 2 10.1.1.0/26 10.1.1.0/24 10.1.1.64 to 10.1.1.254 IP Reservation configured by the UpdateNetwork API with
- guestvmcidr=10.1.1.0/26 or enter 10.1.1.0/26 in the CIDR
- field in the UI.
- 3 10.1.1.0/24 None None Removing IP Reservation by the UpdateNetwork API with
- guestvmcidr=10.1.1.0/24 or enter 10.1.1.0/24 in the CIDR
- field in the UI.
- ===== ============= ============== ======================================== ========================================================
+ ===== ============= ============== ============================================== ========================================================
+ Case CIDR Network CIDR Reserved IP Range for Non-CloudStack instances Description
+ ===== ============= ============== ============================================== ========================================================
+ 1 10.1.1.0/24 None None No IP Reservation.
+ 2 10.1.1.0/26 10.1.1.0/24 10.1.1.64 to 10.1.1.254 IP Reservation configured by the UpdateNetwork API with
+ guestvmcidr=10.1.1.0/26 or enter 10.1.1.0/26 in the CIDR
+ field in the UI.
+ 3 10.1.1.0/24 None None Removing IP Reservation by the UpdateNetwork API with
+ guestvmcidr=10.1.1.0/24 or enter 10.1.1.0/24 in the CIDR
+ field in the UI.
+ ===== ============= ============== ============================================== ========================================================
Limitations
~~~~~~~~~~~
- The IP Reservation is not supported if active IPs that are found
- outside the Guest VM CIDR.
+ outside the Guest instance CIDR.
- Upgrading network offering which causes a change in CIDR (such as
upgrading an offering with no external devices to one with external
@@ -98,7 +98,7 @@ Best Practices
Apply IP Reservation to the guest network as soon as the network state
changes to Implemented. If you apply reservation soon after the first
-guest VM is deployed, lesser conflicts occurs while applying
+Guest Instance is deployed, lesser conflicts occurs while applying
reservation.
@@ -113,7 +113,7 @@ Reserving an IP Range
#. Click Edit. |ip-edit-icon.png|
-#. In CIDR, specify the Guest VM CIDR.
+#. In CIDR, specify the Guest instance CIDR.
#. Click Apply.
diff --git a/source/adminguide/networking/manage_guest_networks.rst b/source/adminguide/networking/manage_guest_networks.rst
index b754622..e0eefb9 100644
--- a/source/adminguide/networking/manage_guest_networks.rst
+++ b/source/adminguide/networking/manage_guest_networks.rst
@@ -17,28 +17,28 @@
Editing, Restarting, and Removing a Guest Network
--------------------------------------------------
-.. note:: Ensure that all the VMs are removed before you remove a guest network.
+.. note:: Ensure that all the Instances are removed before you remove a guest Network.
#. Log in to the CloudStack UI as an administrator or end user.
#. In the left navigation, choose Network.
-#. In the Select view, select Guest networks.
+#. In the Select view, select Guest Networks.
- All the guest networks that you have created for the account are listed in the
+ All the guest Networks that you have created for the account are listed in the
page.
-#. Select the guest network you want to work with.
+#. Select the guest Network you want to work with.
#. In the Details tab, click the "Delete Network" button
- You can also remove the guest network by using the remove button in the Quick
+ You can also remove the guest Network by using the remove button in the Quick
View.
- You can edit the name, description, network offering, CIDR, network domain of a
- guest network. To do that, click the "Edit" button.
+ You can edit the name, description, Network offering, CIDR, Network domain of a
+ guest Network. To do that, click the "Edit" button.
- To restart a guest network, click the "Restart network" button. Please note
- all services provided by this network will be interrupted. When you enable "Clean up",
- the virtual routers of guest network will be destroyed and new virtual routers will
+ To restart a guest Network, click the "Restart Network" button. Please note
+ all services provided by this Network will be interrupted. When you enable "Clean up",
+ the virtual routers of guest Network will be destroyed and new virtual routers will
be provisioned.
diff --git a/source/adminguide/networking/multiple_guest_networks.rst b/source/adminguide/networking/multiple_guest_networks.rst
index f7900cd..6b8b3b8 100644
--- a/source/adminguide/networking/multiple_guest_networks.rst
+++ b/source/adminguide/networking/multiple_guest_networks.rst
@@ -22,12 +22,12 @@ 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
+A instance's networks are defined at instance creation time. An instance 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
+Each instance 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
@@ -35,7 +35,7 @@ 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
+accounts are zone-wide. Any user with access to the zone can create an instance
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.
@@ -72,11 +72,11 @@ Adding an Additional Guest Network
#. Click Create.
-Reconfiguring Networks in VMs
+Reconfiguring Networks in instances
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-CloudStack provides you the ability to move VMs between networks and
-reconfigure a VM's network. You can remove a VM from a network and add
+CloudStack provides you the ability to move instances between networks and
+reconfigure an instance's network. You can remove an instance from a network and add
to a new network. You can also change the default network of a virtual
machine. With this functionality, hybrid or traditional server loads can
be accommodated with ease.
@@ -87,7 +87,7 @@ This feature is supported on XenServer, VMware, and KVM hypervisors.
Prerequisites
^^^^^^^^^^^^^
-Ensure that vm-tools are running on guest VMs for adding or removing
+Ensure that vm-tools are running on Guest Instances for adding or removing
networks to work on VMware hypervisor.
@@ -98,16 +98,16 @@ Adding a Network
#. In the left navigation, click Instances.
-#. Choose the VM that you want to work with.
+#. Choose the instance that you want to work with.
#. Click the NICs tab.
-#. Click Add network to VM.
+#. Click Add network to instance.
- The Add network to VM dialog is displayed.
+ The Add network to instance dialog is displayed.
#. In the drop-down list, select the network that you would like to add
- this VM to.
+ this instance to.
A new NIC is added for this network. You can view the following
details in the NICs page:
@@ -136,7 +136,7 @@ Removing a Network
#. In the left navigation, click Instances.
-#. Choose the VM that you want to work with.
+#. Choose the instance that you want to work with.
#. Click the NICs tab.
@@ -154,7 +154,7 @@ Selecting the Default Network
#. In the left navigation, click Instances.
-#. Choose the VM that you want to work with.
+#. Choose the instance that you want to work with.
#. Click the NICs tab.
@@ -174,7 +174,7 @@ associated with an existing guest network.
#. 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.
+ providers, you must first stop all the instances on the network.
#. In the left navigation, choose Network.
@@ -193,10 +193,10 @@ associated with an existing guest network.
network device as provider, acknowledge the change of CIDR to
continue, so choose Yes.
-#. Wait for the update to complete. Don't try to restart VMs until the
+#. Wait for the update to complete. Don't try to restart instances until the
network change is complete.
-#. If you stopped any VMs, restart them.
+#. If you stopped any instances, restart them.
.. |remove-nic.png| image:: /_static/images/remove-nic.png
diff --git a/source/adminguide/networking/multiple_ips_on_single_nic.rst b/source/adminguide/networking/multiple_ips_on_single_nic.rst
index 8cd7fb7..3082c9b 100644
--- a/source/adminguide/networking/multiple_ips_on_single_nic.rst
+++ b/source/adminguide/networking/multiple_ips_on_single_nic.rst
@@ -18,15 +18,15 @@ Configuring Multiple IP Addresses on a Single NIC
-------------------------------------------------
CloudStack provides you the ability to associate multiple private IP
-addresses per guest VM NIC. In addition to the primary IP, you can
-assign additional IPs to the guest VM NIC. This feature is supported on
+addresses per Guest Instance NIC. In addition to the primary IP, you can
+assign additional IPs to the Guest Instance NIC. This feature is supported on
all the network configurations: Basic, Advanced, and VPC. Security
Groups, Static NAT and Port forwarding services are supported on these
additional IPs.
As always, you can specify an IP from the guest subnet; if not
-specified, an IP is automatically picked up from the guest VM subnet.
-You can view the IPs associated with for each guest VM NICs on the UI.
+specified, an IP is automatically picked up from the Guest Instance subnet.
+You can view the IPs associated with for each Guest Instance NICs on the UI.
You can apply NAT on these additional guest IPs by using network
configuration option in the CloudStack UI. You must specify the NIC to
which the IP should be associated.
@@ -57,10 +57,10 @@ Guidelines
~~~~~~~~~~
To prevent IP conflict, configure different subnets when multiple
-networks are connected to the same VM.
+networks are connected to the same instance.
-Assigning Additional IPs to a VM
+Assigning Additional IPs to an instance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Log in to the CloudStack UI.
@@ -76,9 +76,9 @@ Assigning Additional IPs to a VM
#. Click Acquire New Secondary IP, and click Yes in the confirmation
dialog.
- You need to configure the IP on the guest VM NIC manually. CloudStack
- will not automatically configure the acquired IP address on the VM.
- Ensure that the IP address configuration persist on VM reboot.
+ You need to configure the IP on the Guest Instance NIC manually. CloudStack
+ will not automatically configure the acquired IP address on the instance.
+ Ensure that the IP address configuration persist on instance reboot.
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
@@ -94,5 +94,5 @@ default is the primary IP. To enable this functionality, an extra
optional parameter 'vmguestip' is added to the Port forwarding and
StaticNAT APIs (enableStaticNat, createIpForwardingRule) to indicate on
what IP address NAT need to be configured. If vmguestip is passed, NAT
-is configured on the specified private IP of the VM. if not passed, NAT
-is configured on the primary IP of the VM.
+is configured on the specified private IP of the instance. if not passed, NAT
+is configured on the primary IP of the instance.
diff --git a/source/adminguide/networking/multiple_subnets_in_shared_network.rst b/source/adminguide/networking/multiple_subnets_in_shared_network.rst
index d172757..bd7087f 100644
--- a/source/adminguide/networking/multiple_subnets_in_shared_network.rst
+++ b/source/adminguide/networking/multiple_subnets_in_shared_network.rst
@@ -75,21 +75,21 @@ Adding Multiple Subnets to a Shared Network
All the fields are mandatory.
- - **Gateway**: The gateway for the tier you create. Ensure that the
+ - **Gateway**: The gateway for the Network 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.
+ existing Network Tier within the VPC.
- - **Netmask**: The netmask for the tier you create.
+ - **Netmask**: The netmask for the Network 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.
+ 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 Network Tier is 10.0.1.1, and the
+ netmask of the Network Tier is 255.255.255.0.
- **Start IP/ End IP**: A range of IP addresses that are accessible
- from the Internet and will be allocated to guest VMs. Enter the
+ from the Internet and will be allocated to Guest Instances. Enter the
first and last IP addresses that define a range that CloudStack
- can assign to guest VMs.
+ can assign to Guest Instances.
- **VLAN/VNI**: the ID or VID of the VLAN. If not specified, will be
defaulted to the vlan of the network or if vlan of the network is
diff --git a/source/adminguide/networking/network_permissions.rst b/source/adminguide/networking/network_permissions.rst
index 7076f5c..1a230fc 100644
--- a/source/adminguide/networking/network_permissions.rst
+++ b/source/adminguide/networking/network_permissions.rst
@@ -17,60 +17,60 @@
Guest Network Permissions
-----------------------------
-From Apache CloudStack 4.17.0.0, guest networks can be shared to other
-accounts in the same domain by managing network permissions.
+From Apache CloudStack 4.17.0.0, guest Networks can be shared to other
+accounts in the same domain by managing Network permissions.
-The following networks can be shared:
+The following Networks can be shared:
-#. L2 networks not in Project
+#. L2 Networks not in Project
-#. Isolated networks not in Project
+#. Isolated Networks not in Project
-#. Shared networks with scope is Account
+#. Shared Networks with scope is Account
-Adding a network permission
+Adding a Network permission
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Log in to the CloudStack UI as an administrator or end user.
#. In the left navigation, choose Network.
-#. In the Select view, select Guest networks.
+#. In the Select view, select Guest Networks.
-#. Select the guest network you want to work with.
+#. Select the guest Network you want to work with.
#. Click the Network Permissions tab.
- All the network permissions that you have created for the network are
+ All the Network permissions that you have created for the Network are
listed in the page. |network-permissions.png|
#. Click Add Network Permission icon. Provide the following information:
- - **Account**: The name of the accounts this network will be shared to.
+ - **Account**: The name of the accounts this Network will be shared to.
- - **Project**. The name of the projects this network will be shared to.
+ - **Project**. The name of the projects this Network will be shared to.
#. Click OK.
.. note::
- The accounts/projects are permitted to create VMs on the network.
- However, they are not permitted to restart and update network, and
- modify network rules (e.g. firewall, static nat, load balancer, port
+ The accounts/projects are permitted to create Instances on the Network.
+ However, they are not permitted to restart and update Network, and
+ modify Network rules (e.g. firewall, static nat, load balancer, port
forwarding).
-Removing a network permission
+Removing a Network permission
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To remove a network permission, click the Delete Network Permission icon of
-the network permission. |delete-button.png|
+To remove a Network permission, click the Delete Network Permission icon of
+the Network permission. |delete-button.png|
-Resetting network permissions
+Resetting Network permissions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-CloudStack provides the ability to reset the network permissions of a network.
-All network permissions will be removed. To reset the network permission, click
+CloudStack provides the ability to reset the Network permissions of a Network.
+All Network permissions will be removed. To reset the Network permission, click
the Reset Network Permissions button on the page.
diff --git a/source/adminguide/networking/persistent_networks.rst b/source/adminguide/networking/persistent_networks.rst
index 99eab71..f981f1d 100644
--- a/source/adminguide/networking/persistent_networks.rst
+++ b/source/adminguide/networking/persistent_networks.rst
@@ -17,26 +17,26 @@
Persistent Networks
-------------------
-The network that you can provision without having to deploy any VMs on
+The network that you can provision without having to deploy any instances on
it is called a persistent network. A persistent network can be part of a
VPC or a non-VPC environment.
When you create other types of network, a network is only a database
-entry until the first VM is created on that network. When the first VM
+entry until the first instance is created on that network. When the first instance
is created, a VLAN ID is assigned and the network is provisioned. Also,
-when the last VM is destroyed, the VLAN ID is released and the network
+when the last instance is destroyed, the VLAN ID is released and the network
is no longer available. With the addition of persistent network, you
will have the ability to create a network in CloudStack in which
-physical devices can be deployed without having to run any VMs.
+physical devices can be deployed without having to run any instances.
Additionally, you can deploy physical devices on that network.
One of the advantages of having a persistent network is that you can
-create a VPC with a tier consisting of only physical devices. For
-example, you might create a VPC for a three-tier application, deploy VMs
+create a VPC with a Network Tier consisting of only physical devices. For
+example, you might create a VPC for a three-tier application, deploy instances
for Web and Application tier, and use physical machines for the Database
tier. Another use case is that if you are providing services by using
physical hardware, you can define the network as persistent and
-therefore even if all its VMs are destroyed the services will not be
+therefore even if all its instances are destroyed the services will not be
discontinued.
@@ -63,15 +63,15 @@ Persistent Network Considerations
- An existing network can be made persistent by changing its network
offering to an offering that has the Persistent option enabled. While
- setting this property, even if the network has no running VMs, the
+ setting this property, even if the network has no running instances, the
network is provisioned.
- An existing network can be made non-persistent by changing its
network offering to an offering that has the Persistent option
- disabled. If the network has no running VMs, during the next network
+ disabled. If the network has no running instances, during the next network
garbage collection run the network is shut down.
-- When the last VM on a network is destroyed, the network garbage
+- When the last instance on a network is destroyed, the network garbage
collector checks if the network offering associated with the network
is persistent, and shuts down the network only if it is
non-persistent.
diff --git a/source/adminguide/networking/portable_ips.rst b/source/adminguide/networking/portable_ips.rst
index a65ca05..0bf0435 100644
--- a/source/adminguide/networking/portable_ips.rst
+++ b/source/adminguide/networking/portable_ips.rst
@@ -76,9 +76,9 @@ Configuring Portable IPs
#. Specify the following:
- **Start IP/ End IP**: A range of IP addresses that are accessible
- from the Internet and will be allocated to guest VMs. Enter the
+ from the Internet and will be allocated to Guest Instances. Enter the
first and last IP addresses that define a range that CloudStack
- can assign to guest VMs.
+ can assign to Guest Instances.
- **Gateway**: The gateway in use for the Portable IP addresses you
are configuring.
@@ -129,7 +129,7 @@ API:
http://localhost:8096/client/api?command=enableStaticNat&response=json&ipaddressid=a4bc37b2-4b4e-461d-9a62-b66414618e36&virtualmachineid=a242c476-ef37-441e-9c7b-b303e2a9cb4f&networkid=6e7cd8d1-d1ba-4c35-bdaf-333354cbd49810
Replace the UUID with appropriate UUID. For example, if you want to
-transfer a portable IP to network X and VM Y in a network, execute the
+transfer a portable IP to network X and instance Y in a network, execute the
following:
.. code:: bash
diff --git a/source/adminguide/networking/remote_access_vpn.rst b/source/adminguide/networking/remote_access_vpn.rst
index 5b4f15e..ffa4582 100644
--- a/source/adminguide/networking/remote_access_vpn.rst
+++ b/source/adminguide/networking/remote_access_vpn.rst
@@ -19,8 +19,8 @@
Remote Access VPN
-----------------
-CloudStack account owners can create virtual private networks (VPN) to
-access their virtual machines. If the guest network is instantiated from
+CloudStack Account owners can create virtual private networks (VPN) to
+access their Instances. 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
@@ -96,7 +96,7 @@ Configuring Remote Access VPN in VPC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On enabling Remote Access VPN on a VPC, any VPN client present outside
-the VPC can access VMs present in the VPC by using the Remote VPN
+the VPC can access instances present in the VPC by using the Remote VPN
connection. The VPN client can be present anywhere except inside the VPC
on which the user enabled the Remote Access VPN service.
@@ -113,7 +113,7 @@ To enable VPN for a VPC:
#. Click the Configure button of the VPC.
- For each tier, the following options are displayed:
+ For each Network Tier, the following options are displayed:
- Internal LB
@@ -121,7 +121,7 @@ To enable VPN for a VPC:
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
diff --git a/source/adminguide/networking/reserving_an_ip_address.rst b/source/adminguide/networking/reserving_an_ip_address.rst
index f6f82c6..26542f8 100644
--- a/source/adminguide/networking/reserving_an_ip_address.rst
+++ b/source/adminguide/networking/reserving_an_ip_address.rst
@@ -40,7 +40,7 @@ The public IP address can be reserved to the caller or other accounts.
#. Click Submit button.
- Reserved Public IP Addresses can be acquired and used in isolated networks
+ Reserved Public IP Addresses can be acquired and used in isolated Networks
or VPCs of the accounts which the Public IP Addresses are reserved to.
Reserved Public IP Addresses will be considered as an used Public IP of
diff --git a/source/adminguide/networking/security_groups.rst b/source/adminguide/networking/security_groups.rst
index a82ced9..5211c24 100644
--- a/source/adminguide/networking/security_groups.rst
+++ b/source/adminguide/networking/security_groups.rst
@@ -20,33 +20,33 @@ Security Groups
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
+Security groups provide a way to isolate traffic to instances. A security
+group is a group of instances 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
+attempting to communicate with the instance. 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
+guest network for all Guest Instances. In advanced zones, security groups are
supported only on the KVM hypervisor.
.. note::
In a zone that uses advanced networking, you can instead define
- multiple guest networks to isolate traffic to VMs.
+ multiple guest networks to isolate traffic to instances.
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
+security group can be modified so that all new instances 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
+When a new instance is launched, it is assigned to the default security group
+unless another user-defined security group is specified. An instance can be a
+member of any number of security groups. Once an instance 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.
+can not move a running instance 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
+ingress and egress rules. When you do, the new rules apply to all instances in
the group, whether running or stopped.
If no ingress rules are specified, then no traffic will be allowed in,
@@ -131,7 +131,7 @@ Adding Ingress and Egress Rules to a 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
+ following fields to specify what network traffic is allowed into instance
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.
@@ -139,7 +139,7 @@ Adding Ingress and Egress Rules to a Security Group
- **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
+ if you want to allow incoming traffic from all instances in another
security group
- **Protocol**. The networking protocol that sources will use to
@@ -164,7 +164,7 @@ Adding Ingress and Egress Rules to a Security Group
- **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
+ account. To allow traffic between instances 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:
@@ -173,7 +173,7 @@ Adding Ingress and Egress Rules to a Security Group
#. 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
+ sent out of 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;
@@ -183,10 +183,10 @@ Adding Ingress and Egress Rules to a Security Group
- **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
+ if you want to allow outgoing traffic to all instances in another
security group.
- - **Protocol**. The networking protocol that VMs will use to send
+ - **Protocol**. The networking protocol that instances 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.
@@ -207,7 +207,7 @@ Adding Ingress and Egress Rules to a Security Group
- **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
+ in that account. To allow traffic between instances within the security
group you are editing now, enter its name.
#. Click Add.
diff --git a/source/adminguide/networking/site_to_site_vpn.rst b/source/adminguide/networking/site_to_site_vpn.rst
index 15224f1..33d3ccb 100644
--- a/source/adminguide/networking/site_to_site_vpn.rst
+++ b/source/adminguide/networking/site_to_site_vpn.rst
@@ -20,12 +20,12 @@ 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
+users to access the Guest Instances by establishing a VPN connection to the
virtual router of the account from a device in the datacenter of the
enterprise. You can also establish a secure connection between two VPC
setups or high availability zones in your environment. Having this
facility eliminates the need to establish VPN connections to individual
-VMs.
+instances.
The difference from Remote VPN is that Site-to-site VPNs connects entire
networks to each other, for example, connecting a branch office network
@@ -211,12 +211,12 @@ Creating a VPN gateway for the VPC
page.
#. Click the Configure button of the VPC to which you want to deploy the
- VMs.
+ instances.
- The VPC page is displayed where all the tiers you created are listed
+ The VPC page is displayed where all the Network Tiers you created are listed
in a diagram.
- For each tier, the following options are displayed:
+ For each Network Tier, the following options are displayed:
- Internal LB
@@ -224,7 +224,7 @@ Creating a VPN gateway for the VPC
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
@@ -272,14 +272,14 @@ Creating a VPN Connection
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.
+ instances.
- The VPC page is displayed where all the tiers you created are listed
+ The VPC page is displayed where all the Network Tiers you created are listed
in a diagram.
#. Click the Settings icon.
- For each tier, the following options are displayed:
+ For each Network Tier, the following options are displayed:
- Internal LB
@@ -287,7 +287,7 @@ Creating a VPN Connection
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
@@ -404,14 +404,14 @@ Restarting and Removing a VPN Connection
page.
#. Click the Configure button of the VPC to which you want to deploy the
- VMs.
+ instances.
- The VPC page is displayed where all the tiers you created are listed
+ The VPC page is displayed where all the Network Tiers you created are listed
in a diagram.
#. Click the Settings icon.
- For each tier, the following options are displayed:
+ For each Network Tier, the following options are displayed:
- Internal LB
@@ -419,7 +419,7 @@ Restarting and Removing a VPN Connection
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
diff --git a/source/adminguide/networking/static_nat.rst b/source/adminguide/networking/static_nat.rst
index 6e57b36..83dc293 100644
--- a/source/adminguide/networking/static_nat.rst
+++ b/source/adminguide/networking/static_nat.rst
@@ -18,7 +18,7 @@ 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
+an instance in order to allow Internet traffic into the instance. 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.
@@ -30,7 +30,7 @@ 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
+If a Guest Instance 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.
@@ -49,7 +49,7 @@ function only if they are defined on the default network.
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.
+ the destination instance and click Apply.
.. |enabledisablenat.png| image:: /_static/images/enable-disable.png
diff --git a/source/adminguide/networking/using_remote_access.rst b/source/adminguide/networking/using_remote_access.rst
index 394d29d..3af1db7 100644
--- a/source/adminguide/networking/using_remote_access.rst
+++ b/source/adminguide/networking/using_remote_access.rst
@@ -26,7 +26,7 @@ Using Remote Access VPN
Remote Access VPN connection to VPC or Guest Network to access Instances and applications. This section considers you have enabled Remote acccess VPN, refer to: :ref:`remote-access-vpn`.
-When connected to a VPC via VPN, the client have access to all Tiers.
+When connected to a VPC via VPN, the client have access to all Network Tiers.
Following information is required to confiture VPN client:
diff --git a/source/adminguide/networking/virtual_private_cloud_config.rst b/source/adminguide/networking/virtual_private_cloud_config.rst
index b68b1e4..79599d0 100644
--- a/source/adminguide/networking/virtual_private_cloud_config.rst
+++ b/source/adminguide/networking/virtual_private_cloud_config.rst
@@ -25,35 +25,35 @@ 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.
+CloudStack. A VPC can have its own virtual Network topology that
+resembles a traditional physical Network. You can launch Instances 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,
+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:
+A VPC is comprised of the following Network components:
-- **VPC**: A VPC acts as a container for multiple isolated networks
+- **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
+- **Network Tiers**: Each Network 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.
+ Instances. The Network Tiers are segmented by means of VLANs. The NIC of each
+ Network 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
+ started when you create a VPC. The virtual router connect the Network 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 NAT Instances. For each Network Tier, a corresponding NIC and IP exist in
the virtual router. The virtual router provides DNS and DHCP services
through its IP.
@@ -62,35 +62,35 @@ A VPC is comprised of the following network components:
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
+- **Private Gateway**: All the traffic to and from a private Network
routed to the VPC through the private gateway. For more information,
see ":ref:`adding-priv-gw-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
+ between your VPC and your datacenter, home Network, or co-location
facility. For more information, see ":ref:`setting-s2s-vpn-conn`".
- **Customer Gateway**: The customer side of a VPN Connection. For more
information, see `"Creating and Updating a VPN
Customer Gateway" <#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
+- **NAT Instance**: An Instance that provides Port Address Translation
+ for Instances to access the Internet via the public gateway. For more
information, see ":ref:`enabling-disabling-static-nat-on-vpc`".
- **Network ACL**: Network ACL is a group of Network ACL items. Network
ACL items are nothing but numbered rules that are evaluated in order,
starting with the lowest numbered rule. These rules determine whether
- traffic is allowed in or out of any tier associated with the network
+ traffic is allowed in or out of any Network Tier associated with the Network
ACL. For more information, see ":ref:`conf-net-acl`".
Network Architecture in a VPC
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In a VPC, the following four basic options of network architectures are
+In a VPC, the following four basic options of Network architectures are
present:
- VPC with a public gateway only
@@ -126,20 +126,20 @@ Consider the following before you create a VPC:
- 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
+- 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.
+ 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.
+- The default number of Network 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.
+- Each Network Tier should have an unique CIDR in the VPC. Ensure that the
+ Network Tier's CIDR should be within the VPC CIDR range.
-- A tier belongs to only one VPC.
+- A Network Tier belongs to only one VPC.
-- All network tiers inside the VPC should belong to the same account.
+- 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.
@@ -147,38 +147,38 @@ Consider the following before you create a VPC:
- 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 can only have a private IP address that you provision.
- To communicate with the Internet, enable NAT to an instance that you
+- The Instances can 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
+- 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.
+- The load balancing service can be supported by only one Network Tier
+ inside the VPC.
-- If an IP address is assigned to a tier:
+- If an IP address is assigned to a Network 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
+ - That IP can't be used by more than one Network Tier at a time in the VPC.
+ For example, if you have Network 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.
+ forwarding rules for another guest Network inside the VPC.
-- Remote access VPN is not supported in VPC networks.
+- Remote access VPN is not supported in VPC Networks.
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 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.
+#. Log in to the CloudStack UI as an administrator or end User.
#. In the left navigation, choose Network.
@@ -197,15 +197,15 @@ addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
- **Zone**: Choose the zone where you want the VPC to be available.
- **CIDR**: 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.
+ the Network Tiers (guest Networks) within a VPC. When you create a
+ Network Tier, ensure that its CIDR is within the Super CIDR value
+ you enter. The CIDR must be RFC1918 compliant.
- **Network Domain**: 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.
+ all the Network Tiers within the VPC. That implies, all the Network
+ 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.
- **VPC Offering**: If the administrator has configured multiple
VPC offerings, select the one you want to use for this VPC.
@@ -214,88 +214,88 @@ addresses in the form of a Classless Inter-Domain Routing (CIDR) block.
- **IPv6 DNS**: A set of custom IPv6 DNS that will be used by this VPC. If not provided then IPv6 DNS specified for the zone will be used. Available only when the selected VPC offering is IPv6 enabled and supports DNS service.
- - **IPv4 address for the VR in this VPC**: The source NAT address or primary public network address to use by the guest networks. If not provided then a random address from the available pool of addresses wil be used.
+ - **IPv4 address for the VR in this VPC**: The source NAT address or primary public Network address to use by the guest Networks. If not provided then a random address from the available pool of addresses wil be used.
- **Public MTU**: The MTU to be configured on the public interfaces of the
- VPC network's VR
+ VPC Network's VR
#. Click OK.
.. note::
* In security groups-enabled Advanced zones and Basic zones, creation of
- VPC and isolated networks are not supported.
+ VPC and isolated Networks are not supported.
* Public MTU option will be shown in the UI and considered only when zone configuration - `allow.end.users.to.specify.vr.mtu` is set to true. Maximum allowed value for public MTU can be controlled by zone-level configuration - `vr.public.interface.max.mtu`.
-Adding Tiers
-~~~~~~~~~~~~
+Adding Network 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.
+Network Tiers are distinct locations within a VPC that act as isolated Networks,
+which do not have access to other Network Tiers by default. Network Tiers are
+set up on different VLANs that can communicate with each other by using a virtual
+router. Network Tiers provide inexpensive, low latency Network connectivity to
+other Network Tiers within the VPC.
-#. Log in to the CloudStack UI as an administrator or end user.
+#. 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
+ 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
+ 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.
+ Network Tiers.
-#. Click Create network.
+#. Click Create Network.
- The Add new tier dialog is displayed, as follows:
+ The Add new Network Tier dialog is displayed, as follows:
|add-tier.png|
- If you have already created tiers, the VPC diagram is displayed.
- Click Create Tier to add a new tier.
+ If you have already created Network Tiers, the VPC diagram is displayed.
+ Click Create Network Tier to add a new Network Tier.
#. Specify the following:
All the fields are mandatory.
- - **Name**: A unique name for the tier you create.
+ - **Name**: A unique name for the Network Tier you create.
- - **Network Offering**: The following default network offerings are
+ - **Network Offering**: The following default Network offerings are
listed: Internal LB,
DefaultIsolatedNetworkOfferingForVpcNetworksNoLB,
DefaultIsolatedNetworkOfferingForVpcNetworks
- In a VPC, only one tier can be created by using LB-enabled network
+ In a VPC, only one Network Tier can be created by using LB-enabled Network
offering.
- - **Gateway**: The gateway for the tier you create. Ensure that the
+ - **Gateway**: The gateway for the Network 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.
+ existing Network Tier within the VPC.
- - **VLAN**: The VLAN ID for the tier that the root admin creates.
+ - **VLAN**: The VLAN ID for the Network Tier that the root admin creates.
- This option is only visible if the network offering you selected
+ This option is only visible if the Network offering you selected
is VLAN-enabled.
For more information, see `"Assigning VLANs to
Isolated Networks" <hosts.html#assigning-vlans-to-isolated-networks>`_.
- - **Netmask**: The netmask for the tier you create.
+ - **Netmask**: The netmask for the Network 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.
+ 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 Network Tier is 10.0.1.1,
+ and the netmask of the Network Tier is 255.255.255.0.
#. Click OK.
-#. Continue with configuring access control list for the tier.
+#. Continue with configuring access control list for the Network Tier.
.. _conf-net-acl:
@@ -308,8 +308,8 @@ Network Access Control Lists can only be created if the service
"NetworkACL" is supported by the created VPC.
Define a Network Access Control List (ACL) to control incoming
-(ingress) and outgoing (egress) traffic between the associated tier
-and external networks (other tiers of the VPC as well as public networks).
+(ingress) and outgoing (egress) traffic between the associated Network Tier
+and external Networks (other Network Tiers of the VPC as well as public Networks).
About Network ACL Lists
^^^^^^^^^^^^^^^^^^^^^^^
@@ -317,7 +317,7 @@ About Network ACL Lists
In CloudStack terminology, a Network ACL is a group of Network ACL rules.
Network ACL rules are processed by their order, starting with the lowest
numbered rule. Each rule defines at least an affected protocol, traffic type,
-action and afected destination / source network. The following table shows a
+action and affected destination / source Network. The following table shows a
exemplary content of a "default_deny" ACL.
.. cssclass:: table-striped table-bordered table-hover
@@ -330,12 +330,12 @@ Rule Protocol Traffic type Action CIDR
===== ======== ============ ====== =========
Each Network ACL is associated with a VPC and can be assigned
-to multiple VPC tiers. Every tier needs to be associated with a
-Network ACL. Only one ACL can be associated with a tier at a time. If no
-custome network ACL is availeable at the time of tier creation, a default
-Network ACL has to be used instead. Curretly two default ACL are
+to multiple VPC Network Tiers. Every Network Tier needs to be associated with a
+Network ACL. Only one ACL can be associated with a Network Tier at a time. If no
+custom Network ACL is available at the time of Network Tier creation, a default
+Network ACL has to be used instead. Currently two default ACL are
available. The "default_allow" ACL allows in- and egress traffic while
-the "default_deny" blocks all in- and egress traffic. Default network
+the "default_deny" blocks all in- and egress traffic. Default Network
ACL cannot be removed or modified. Newly created ACLs, while showing
empty, deny all incoming traffic to the associated tier and allow all
outgoing traffic. To change the defaults add a "deny all egress
@@ -344,8 +344,8 @@ Afterwards traffic can be white- or blacklisted.
.. note::
- ACL Rules in Cloudstack are stateful
-- Source / Destination CIDRs are always external networks
-- ACL rules can also beeen seen on the virtual router of the VPC. Ingress
+- Source / Destination CIDRs are always external Networks
+- ACL rules can also been seen on the virtual router of the VPC. Ingress
rules are listed in the table iptables table "filter" while egress rules
are placed in the "mangle" table
- ACL rules for ingress and egress are not correlating. For example a
@@ -356,13 +356,13 @@ Afterwards traffic can be white- or blacklisted.
Creating ACL Lists
^^^^^^^^^^^^^^^^^^
-#. Log in to the CloudStack UI as an administrator or end user.
+#. 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
+ All the VPCs that you have created for the Account is listed in the
page.
#. Click the Configure button of the VPC.
@@ -375,7 +375,7 @@ Creating ACL Lists
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
@@ -411,7 +411,7 @@ Creating an ACL Rule
#. In the Select view, select VPC.
- All the VPCs that you have created for the account is listed in the
+ All the VPCs that you have created for the Account is listed in the
page.
#. Click the Configure button of the VPC.
@@ -512,18 +512,18 @@ Assigning a Custom ACL List to a Tier
Adding a Private Gateway to a VPC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A private gateway can be added by the root admin and users. The VPC private
+A private gateway can be added by the root admin and Users. The VPC private
network has 1:1 relationship with the NIC of the physical network. You
can configure multiple private gateways to a single VPC. 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.
+#. 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
+ 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
@@ -542,7 +542,7 @@ with duplicated VLAN and IP are allowed in the same data center.
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
@@ -606,11 +606,11 @@ Source NAT on Private Gateway
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You might want to deploy multiple VPCs with the same super CIDR and
-guest tier CIDR. Therefore, multiple guest VMs from different VPCs can
+guest tier CIDR. Therefore, multiple Guest Instances from different VPCs can
have the same IPs to reach a enterprise data center through the private
gateway. In such cases, a NAT service need to be configured on the
private gateway to avoid IP conflicts. If Source NAT is enabled, the
-guest VMs in VPC reaches the enterprise network via private gateway IP
+Guest Instances in VPC reaches the enterprise network via private gateway IP
address by using the NAT service.
The Source NAT service on a private gateway can be enabled while adding
@@ -692,39 +692,39 @@ continue functioning. You cannot add a static route if the route is
denied for the zone.
-Deploying VMs to the Tier
-~~~~~~~~~~~~~~~~~~~~~~~~~
+Deploying Instances to the Tier
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-#. Log in to the CloudStack UI as an administrator or end user.
+#. 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
+ 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.
+ Instances.
The VPC page is displayed where all the tiers you have created are
listed.
-#. Click Virtual Machines tab of the tier to which you want to add a VM.
+#. Click Instances tab of the tier to which you want to add an Instance.
|add-vm-vpc.png|
The Add Instance page is displayed.
- Follow the on-screen instruction to add an instance. For information
- on adding an instance, see the Installation Guide.
+ Follow the on-screen instruction to add an Instance. For information
+ on adding an Instance, see the Installation Guide.
-Deploying VMs to VPC Tier and Shared Networks
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Deploying Instances to VPC Tier and Shared Networks
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-CloudStack allows you deploy VMs on a VPC tier and one or more shared
-networks. With this feature, VMs deployed in a multi-tier application
+CloudStack allows you deploy Instances on a VPC tier and one or more shared
+networks. With this feature, Instances deployed in a multi-tier application
can receive monitoring services via a shared network provided by a
service provider.
@@ -736,21 +736,21 @@ service provider.
#. Select a zone.
-#. Select a template or ISO, then follow the steps in the wizard.
+#. Select a Template or ISO, then follow the steps in the wizard.
#. Ensure that the hardware you have allows starting the selected
service offering.
-#. Under Networks, select the desired networks for the VM you are
+#. Under Networks, select the desired networks for the Instance you are
launching.
- You can deploy a VM to a VPC tier and multiple shared networks.
+ You can deploy an Instance to a VPC tier and multiple shared networks.
|addvm-tier-sharednw.png|
#. Click Next, review the configuration and click Launch.
- Your VM will be deployed to the selected VPC tier and shared network.
+ Your Instance will be deployed to the selected VPC tier and shared network.
Acquiring a New IP Address for a VPC
@@ -762,17 +762,17 @@ 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.
+#. 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
+ 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.
+ Instances.
The VPC page is displayed where all the tiers you created are listed
in a diagram.
@@ -785,7 +785,7 @@ associated to more than one network at a time.
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
@@ -811,8 +811,8 @@ associated to more than one network at a time.
address in port forwarding, load balancing, and static NAT rules.
-Releasing an IP Address Alloted to a VPC
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Releasing an IP Address Allotted 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
@@ -821,13 +821,13 @@ 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.
+#. 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
+ 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.
@@ -843,7 +843,7 @@ still belongs to the same VPC.
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
@@ -872,26 +872,26 @@ 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
+an Instance 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
+If a Guest Instance 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.
+#. 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
+ 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.
+ Instances.
The VPC page is displayed where all the tiers you created are listed
in a diagram.
@@ -904,7 +904,7 @@ function only if they are defined on the default network.
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
@@ -933,7 +933,7 @@ function only if they are defined on the default network.
|select-vmstatic-nat.png|
-#. Select the tier and the destination VM, then click Apply.
+#. Select the tier and the destination Instance, then click Apply.
Adding Load Balancing Rules on a VPC
@@ -945,20 +945,20 @@ the traffic received at a public IP of the VPC virtual router. The
traffic is load balanced within a tier based on your configuration.
Citrix NetScaler and VPC virtual router are supported for external LB.
When you use internal LB service, traffic received at a tier is load
-balanced across different VMs within that tier. For example, traffic
-reached at Web tier is redirected to another VM in that tier. External
+balanced across different Instances within that tier. For example, traffic
+reached at Web tier is redirected to another Instance in that tier. External
load balancing devices are not supported for internal LB. The service is
-provided by a internal LB VM configured on the target tier.
+provided by a internal LB Instance configured on the target tier.
Load Balancing Within a Tier (External LB)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
+balance traffic received at a public IP to one or more Instances 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 tier.
+Instances within a tier.
Enabling NetScaler as the LB Provider on a VPC Tier
@@ -992,7 +992,7 @@ follows:
#. Log in to the CloudStack UI as a user or admin.
-#. Naviagte to Service Offerings and choose Network Offering.
+#. Navigate to Service Offerings and choose Network Offering.
#. Click Add Network Offering.
@@ -1013,7 +1013,7 @@ follows:
- **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.
+ deploy an Instance on it is termed persistent network.
- **VPC**: This option indicate whether the guest network is Virtual
Private Cloud-enabled. A Virtual Private Cloud (VPC) is a private,
@@ -1053,7 +1053,7 @@ Creating an External LB Rule
#. In the Select view, select VPC.
- All the VPCs that you have created for the account is listed in the
+ All the VPCs that you have created for the Account is listed in the
page.
#. Click the Configure button of the VPC, for which you want to
@@ -1070,7 +1070,7 @@ Creating an External LB Rule
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
@@ -1102,7 +1102,7 @@ Creating an External LB 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
+ - **Private Port**: The port that the Instances will use to receive the
traffic.
- **Algorithm**. Choose the load balancing algorithm you want
@@ -1119,7 +1119,7 @@ Creating an External LB Rule
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
+ - **Add Instances**: Click Add Instances, then select two or more Instances that will
divide the load of incoming traffic, and click Apply.
The new load balancing rule appears in the list. You can repeat these
@@ -1145,14 +1145,14 @@ How Does Internal LB Work in VPC?
In this figure, a public LB rule is created for the public IP
72.52.125.10 with public port 80 and private port 81. The LB rule,
created on the VPC virtual router, is applied on the traffic coming from
-the Internet to the VMs on the Web tier. On the Application tier two
+the Internet to the Instances on the Web tier. On the Application tier two
internal load balancing rules are created. An internal LB rule for the
-guest IP 10.10.10.4 with load balancer port 23 and instance port 25 is
-configured on the VM, InternalLBVM1. Another internal LB rule for the
-guest IP 10.10.10.4 with load balancer port 45 and instance port 46 is
-configured on the VM, InternalLBVM1. Another internal LB rule for the
-guest IP 10.10.10.6, with load balancer port 23 and instance port 25 is
-configured on the VM, InternalLBVM2.
+guest IP 10.10.10.4 with load balancer port 23 and Instance port 25 is
+configured on the Instance, InternalLBVM1. Another internal LB rule for the
+guest IP 10.10.10.4 with load balancer port 45 and Instance port 46 is
+configured on the Instance, InternalLBVM1. Another internal LB rule for the
+guest IP 10.10.10.6, with load balancer port 23 and Instance port 25 is
+configured on the Instance, InternalLBVM2.
|vpc-lb.png|
@@ -1166,7 +1166,7 @@ Guidelines
- Internal LB is supported just on VPC networks in CloudStack 4.2
release.
-- Only Internal LB VM can act as the Internal LB provider in CloudStack
+- Only Internal LB Instance can act as the Internal LB provider in CloudStack
4.2 release.
- Network upgrade is not supported from the network offering with
@@ -1198,7 +1198,7 @@ network offering as follows:
#. Log in to the CloudStack UI as a user or admin.
-#. Naviagte to Service Offerings and choose Network OfferingPublic IP Addresses.
+#. Navigate to Service Offerings and choose Network OfferingPublic IP Addresses.
#. Click Add Network Offering.
@@ -1219,7 +1219,7 @@ network offering as follows:
- **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.
+ deploy an Instance on it is termed persistent network.
- **VPC**: This option indicate whether the guest network is Virtual
Private Cloud-enabled. A Virtual Private Cloud (VPC) is a private,
@@ -1251,13 +1251,13 @@ network offering as follows:
Creating an Internal LB Rule
''''''''''''''''''''''''''''
-When you create the Internal LB rule and applies to a VM, an Internal LB
-VM, which is responsible for load balancing, is created.
+When you create the Internal LB rule and applies to an Instance, an Internal LB
+Instance, which is responsible for load balancing, is created.
-You can view the created Internal LB VM in the Instances page if you
+You can view the created Internal LB Instance in the Instances page if you
navigate to **Infrastructure** > **Zones** > <zone\_ name> >
<physical\_network\_name> > **Network Service Providers** > **Internal
-LB VM**. You can manage the Internal LB VMs as and when required from
+LB Instance**. You can manage the Internal LB Instances as and when required from
the location.
#. Log in to the CloudStack UI as an administrator or end user.
@@ -1266,7 +1266,7 @@ the location.
#. In the Select view, select VPC.
- All the VPCs that you have created for the account is listed in the
+ All the VPCs that you have created for the Account is listed in the
page.
#. Locate the VPC for which you want to configure internal LB, then
@@ -1293,13 +1293,13 @@ the location.
specified, the IP address is automatically allocated from the
network CIDR.
- For every Source IP, a new Internal LB VM is created for load
+ For every Source IP, a new Internal LB Instance is created for load
balancing.
- **Source Port**: The port associated with the source IP. Traffic
on this port is load balanced.
- - **Instance Port**: The port of the internal LB VM.
+ - **Instance Port**: The port of the internal LB Instance.
- **Algorithm**. Choose the load balancing algorithm you want
CloudStack to use. CloudStack supports the following well-known
@@ -1321,11 +1321,11 @@ Adding a Port Forwarding Rule on a VPC
#. In the Select view, select VPC.
- All the VPCs that you have created for the account is listed in the
+ 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.
+ Instances.
The VPC page is displayed where all the tiers you created are listed
in a diagram.
@@ -1338,7 +1338,7 @@ Adding a Port Forwarding Rule on a VPC
- Static NAT
- - Virtual Machines
+ - Instances
- CIDR
@@ -1368,7 +1368,7 @@ Adding a Port Forwarding Rule on a VPC
- **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
+ - **Private Port**: The port on which the Instance is listening for
forwarded public traffic.
- **Protocol**: The communication protocol in use between the two
@@ -1378,10 +1378,10 @@ Adding a Port Forwarding Rule on a VPC
- UDP
- - **Add VM**: Click Add VM. Select the name of the instance to which
+ - **Add Instance**: Click Add Instance. 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.
+ You can test the rule by opening an SSH session to the Instance.
Removing Tiers
@@ -1399,7 +1399,7 @@ belonging to the same VPC.
#. In the Select view, select VPC.
- All the VPC that you have created for the account is listed in the
+ 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
@@ -1427,7 +1427,7 @@ Editing, Restarting, and Removing a Virtual Private Cloud
#. In the Select view, select VPC.
- All the VPCs that you have created for the account is listed in the
+ All the VPCs that you have created for the Account is listed in the
page.
#. Select the VPC you want to work with.
@@ -1453,9 +1453,9 @@ Editing, Restarting, and Removing a Virtual Private Cloud
.. |add-new-gateway-vpc2.png| image:: /_static/images/add-new-gateway-vpc2.png
:alt: adding a private gateway for the VPC.
.. |add-vm-vpc.png| image:: /_static/images/add-vm-vpc.png
- :alt: adding a VM to a vpc.
+ :alt: adding an Instance to a VPC.
.. |addvm-tier-sharednw.png| image:: /_static/images/addvm-tier-sharednw.png
- :alt: adding a VM to a VPC tier and shared network.
+ :alt: adding an Instance to a VPC tier and shared network.
.. |release-ip-icon.png| image:: /_static/images/release-ip-icon.png
:alt: button to release an IP.
.. |enable-disable.png| image:: /_static/images/enable-disable.png
diff --git a/source/adminguide/networking_and_traffic.rst b/source/adminguide/networking_and_traffic.rst
index 6adbd53..e2d7949 100644
--- a/source/adminguide/networking_and_traffic.rst
+++ b/source/adminguide/networking_and_traffic.rst
@@ -14,7 +14,7 @@
under the License.
-In a CloudStack, guest VMs can communicate with each other using shared
+In a CloudStack, Guest Instances 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.
diff --git a/source/adminguide/projects.rst b/source/adminguide/projects.rst
index 68ceec0..791ad89 100644
--- a/source/adminguide/projects.rst
+++ b/source/adminguide/projects.rst
@@ -17,71 +17,71 @@
Overview of Projects
--------------------
-Projects are used to organize people and resources. CloudStack users
+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
+can collaborate and share virtual resources such as Instances, 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
+other Users of the same cloud
-You can configure CloudStack to allow any user to create a new project,
+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 to either add people directly to a project, or 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
+(for example, share Instances). 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.
+such as project Instances, fellow project members, project-related alerts, and so on.
From CloudStack 4.15 onwards, it is possible for a project to have
-multiple project administrators and to add/invite specific users of
-an account to a project in addition to adding accounts. By means of
-Project Roles associated with a user or an account of the project,
-it is possible to restrict access of users in a project, i.e., in
-addition to account-level roles, one can further restrict access to
+multiple project administrators and to add/invite specific Users of
+an Account to a project in addition to adding Accounts. By means of
+Project Roles associated with a User or an Account of the project,
+it is possible to restrict access of Users in a project, i.e., in
+addition to Account-level roles, one can further restrict access to
operations (or APIs) by associating a project-level role to the
-user or account. However, if an account has already been added, one will not
-be able to associate a role to a specific user of that account.
+User or Account. However, if an Account has already been added, one will not
+be able to associate a role to a specific User of that Account.
-**NOTE:** Project Roles work over Account level Roles. If a user/account is
+**NOTE:** Project Roles work over Account level Roles. If a User/Account is
added to a project without a project role, it would imply that the
-user / account added will have access to all APIs that are made available
+User / Account added will have access to all APIs that are made available
by the Account level role. If there are no specific deny rules in the
-project role, it would again fallback onto the account-level role to decide
-whether the user has permissions to perform a specific action. It is also to be
+project role, it would again fallback onto the Account-level role to decide
+whether the User has permissions to perform a specific action. It is also to be
noted that Project roles are restrictive in nature, i.e., to say that, one may
-not allow a user to perform an operation that is NOT allowed at the Account level.
+not allow a User to perform an operation that is NOT allowed at the Account level.
Even if a rule is added at the project level, allowing such an action, it will not
have any effect as the action will be prohibited by the Account Role.
-The project administrator can promote or demote a user in the project.
+The project administrator can promote or demote a User in the project.
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
+project, resources created by that User, such as 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
+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
+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
+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
+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.
@@ -90,7 +90,7 @@ at the project level.
Configuring Projects
--------------------
-Before CloudStack users start using projects, the CloudStack
+Before CloudStack Users start using projects, the CloudStack
administrator must set up various systems to support them, including
membership invitations, limits on project resources, and controls on who
can create projects.
@@ -102,7 +102,7 @@ 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
+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.
@@ -152,12 +152,11 @@ 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
+Snapshots, IP addresses, and Instances. Domain administrators can override
+these resource limits for individual projects with their domains,
+as long as the new limits are below the global defaults set by the CloudStack
+root administrator. The root administrator can also set lower resource limits
+for any project in the cloud.
Setting Per-Project Resource Limits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -209,11 +208,11 @@ Setting the Global Project Resource Limits
+--------------------------+------------------------------------------------------------------------------------------------------------------------------+
| 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.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.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.uservms | Maximum number of guest Instances that can be owned by any project in the cloud. See Working With Instances. |
+--------------------------+------------------------------------------------------------------------------------------------------------------------------+
| max.project.volumes | Maximum number of data volumes that can be owned by any project in the cloud. See Working with Volumes. |
+--------------------------+------------------------------------------------------------------------------------------------------------------------------+
@@ -228,7 +227,7 @@ Setting the Global Project Resource Limits
Setting Project Creator Permissions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-You can configure CloudStack to allow any user to create a new project,
+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.
@@ -241,7 +240,7 @@ or you can restrict that ability to just CloudStack administrators.
``allow.user.create.projects``
- Set to true to allow end users to create projects. Set to false if
+ 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.
@@ -257,7 +256,7 @@ 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.
+to true, end Users can also create projects.
#. Log in as administrator to the CloudStack UI.
@@ -265,7 +264,7 @@ to true, end users can also create projects.
#. Click New Project.
-#. Give the project a name and description for display to users, then
+#. 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
@@ -303,13 +302,13 @@ not turned on, use the procedure in Adding Project Members From the UI.
#. Click the name of the project you want to work with.
-#. Click on the `Add Account to Project` button. This will have 2 tabs, one to add account to the project and the other to add a user to the project. Here, we can specify the:
+#. Click on the `Add Account to Project` button. This will have 2 tabs, one to add Account to the project and the other to add a User to the project. Here, we can specify the:
- - account or user and/or email id of the user to be invited,
- - (Optional) the Role i.e, Admin or Regular that the user is to be added as, defualts to Regular role,
- - (Optional) the Project role specifying the list of APIs the user is allowed/ denied access to
+ - Account or User and/or email id of the User to be invited,
+ - (Optional) the Role i.e, Admin or Regular that the User is to be added as, defaults to Regular role,
+ - (Optional) the Project role specifying the list of APIs the User is allowed/ denied access to
- 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.
+ 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
@@ -332,13 +331,13 @@ Invitations” <#sending-project-membership-invitations>`_.
#. Click the name of the project you want to work with.
-#. Click on the `Add Account to Project` button. This will have 2 tabs, one to add account to the project and the other to add a user to the project. Here, we can specify the:
+#. Click on the `Add Account to Project` button. This will have 2 tabs, one to add Account to the project and the other to add a User to the project. Here, we can specify the:
- - account or user and/or email id of the user to be invited,
- - (Optional) the Role i.e, Admin or Regular that the user is to be added as, defualts to Regular role,
- - (Optional) the Project role specifying the list of APIs the user is allowed/ denied access to
+ - Account or User and/or email id of the User to be invited,
+ - (Optional) the Role i.e, Admin or Regular that the User is to be added as, defaults to Regular role,
+ - (Optional) the Project role specifying the list of APIs the User is allowed/ denied access to
-#. You can add only people who have an account in this cloud and within the same domain as the project.
+#. You can add only people who have an Account in this cloud and within the same domain as the project.
Accepting a Membership Invitation
@@ -356,7 +355,7 @@ want to accept the invitation, follow these steps:
#. If you see the invitation listed onscreen, click the Accept button.
Invitations listed on screen were sent to you using your CloudStack
- account name.
+ 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.
@@ -370,7 +369,7 @@ 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
+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
@@ -403,13 +402,13 @@ and resources.
#. Click Project View.
-#. The project dashboard appears, showing the project’s VMs, volumes,
- users, events, network settings, and more. From the dashboard, you
+#. The project dashboard appears, showing the project’s Instances, 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 or vice versa.
+ members, or change the role of a member from User to admin or vice versa.
- (If invitations are enabled) Click the Invitations button to view and
manage invitations that have been sent to new project members but
diff --git a/source/adminguide/reliability.rst b/source/adminguide/reliability.rst
index 05e066c..62bdcf5 100644
--- a/source/adminguide/reliability.rst
+++ b/source/adminguide/reliability.rst
@@ -23,10 +23,10 @@ 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.
+Serves. All Guest Instances 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
+When the Management Server is down, no new Instances can be created, and the
+end User and admin UI, API, dynamic load distribution, and HA will cease
to work.
.. _management-server-load-balancing:
@@ -66,7 +66,7 @@ Multiple Management Servers Support on agents
In a Cloudstack environment with multiple management servers, an agent can be
configured, based on an algorithm, to which management server to connect to.
-This can be useful as an internal loadbalancer or for high availability.
+This can be useful as an internal load balancer or for high availability.
An administrator is responsible for setting the list of management servers and
choosing a sorting algorithm using global settings.
The management server is responsible for propagating the settings to the
@@ -75,7 +75,7 @@ Virtual Machine, Console Proxy Virtual Machine or the KVM hosts).
The three global settings that need to be configured are the following:
-- hosts: a comma seperated list of management server IP addresses
+- hosts: a comma separated list of management server IP addresses
- indirect.agent.lb.algorithm: The algorithm for the indirect agent LB
- indirect.agent.lb.check.interval: The preferred host check interval
for the agent's background task that checks and switches to an agent's
@@ -135,58 +135,58 @@ Setting 'host' = 'A,B,C', agents will receive lists depending on
receives: 'B,C,A', third agent receives: 'C,B,A'
'shuffle': Each agent will receive a list in random order.
-HA-Enabled Virtual Machines
----------------------------
+HA-Enabled Instances
+--------------------
-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
+The User can specify an Instance as HA-enabled. By default, all
+virtual router Instances and Elastic Load Balancing Instances are automatically
+configured as HA-enabled. When an HA-enabled Instance crashes, CloudStack
+detects the crash and restarts the Instance 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
+Zones. CloudStack has a conservative policy towards restarting Instances and
+ensures that there will never be two equal Instances running at
+the same time. The Management Server attempts to start the Instance on another
Host in the same cluster.
HA features work with iSCSI or NFS primary storage. HA with local
storage is not supported.
.. note::
- HA-Enabled VMs will be restarted when it is detected that the VM is
+ HA-Enabled Instances will be restarted when it is detected that the Instance is
crashed beyond a shadow of a doubt. When the host it is running on is
- unreachable, either because of network issue or because it is crashed,
- CloudStack can not be sure the disk image of the VM is not still being
- accessed and will not restart the VM.
+ unreachable, either because of Network issue or because it is crashed,
+ CloudStack can not be sure the disk image of the Instance is not still being
+ accessed and will not restart the Instance.
Dedicated HA Hosts
------------------
-One or more hosts can be designated for use only by HA-enabled VMs that
+One or more hosts can be designated for use only by HA-enabled Instances 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
+dedicated HA hosts as the recovery destination for all HA-enabled Instances is
useful to:
-- Make it easier to determine which VMs have been restarted as part of
- the CloudStack high-availability function. If a VM is running on a
- dedicated HA host, then it must be an HA-enabled VM whose original
+- Make it easier to determine which Instances have been restarted as part of
+ the CloudStack high-availability function. If an Instance is running on a
+ dedicated HA host, then it must be an HA-enabled Instance whose original
host failed. (With one exception: It is possible for an administrator
- to manually migrate any VM to a dedicated HA host.).
+ to manually migrate any Instance to a dedicated HA host.).
-- Keep HA-enabled VMs from restarting on hosts which may be reserved
+- Keep HA-enabled Instances 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
+HA-enabled Instances, 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.
+that you want to dedicate to HA-enabled Instances.
.. note::
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
+ any host in the cloud, the HA-enabled Instances will fail to restart after
a crash.
@@ -198,21 +198,21 @@ HA-Enabled Hosts
on for instance VMware or Xen. For those hypervisor types, the Host HA
is left to the VMware-cluster or Xen-pool respectively.
-The user can specify a host as HA-enabled, In the event of a host
-failure, attemps will be made to recover the failed host by first
+The User can specify a host as HA-enabled, In the event of a host
+failure, attempts will be made to recover the failed host by first
issuing some OOBM commands. If the host recovery fails the host will be
fenced and placed into maintenance mode. To restore the host to normal
operation, manual intervention would then be required.
Out of band management is a requirement of HA-Enabled hosts and has to be
-confiured on all intended participating hosts.
+configured on all intended participating hosts.
(see `“Out of band management” <hosts.html#out-of-band-management>`_).
Host-HA has granular configuration on a host/cluster/zone level. In a large
environment, some hosts from a cluster can be HA-enabled and some not,
Host-HA uses a state machine design to manage the operations of recovering
-and fencing hosts. The current status of a host is reported when quering a
+and fencing hosts. The current status of a host is reported when querying a
specific host.
Timely health investigations are done on HA-Enabled hosts to monitor for
@@ -222,7 +222,7 @@ only when it’s exceeded, will the host transition to a different state.
Host-HA uses both health checks and activity checks to make decisions on
recovering and fencing actions. Once determined that the host is in faulty
state (health checks failed) it runs activity checks to figure out if there is
-any disk activity on the VMs running on the specific host.
+any disk activity on the Instances running on the specific host.
The HA Resource Management Service manages the check/recovery cycle including
periodic execution, concurrency management, persistence, back pressure and
@@ -248,7 +248,7 @@ states:
- SUSPECT - There are health checks failing with the host.
- CHECKING - Activity checks are being performed.
- DEGRADED - The host is passing the activity check ratio and still providing
- service to the end user, but it cannot be managed from the CloudStack
+ service to the end User, but it cannot be managed from the CloudStack
management server.
- RECOVERING - The Host-HA framework is trying to recover the host by issuing
OOBM jobs.
@@ -300,14 +300,14 @@ 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
+all Instances 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
+back on line. With NFS, the hypervisor may allow the Instances 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
+NFS hang will cause the Guest Instances 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.
+Templates.
Secondary Storage Outage and Data Loss
@@ -315,13 +315,13 @@ 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
+impact running Guest Instances. It may become impossible to create an Instance
+with the selected Template for a User. A User may also not be able to save
+Templates or examine/restore saved Templates. 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
+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/source/adminguide/service_offerings.rst b/source/adminguide/service_offerings.rst
index 1b15c18..9a3e690 100644
--- a/source/adminguide/service_offerings.rst
+++ b/source/adminguide/service_offerings.rst
@@ -23,7 +23,7 @@ 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.
+such as Templates for creating Instances, 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
@@ -35,9 +35,9 @@ 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
+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:
+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,
@@ -54,8 +54,8 @@ present users with choices when creating a new instance:
- 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.
+ 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
@@ -91,7 +91,7 @@ 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. Based on the user’s
+available offerings when they create a new Instance. Based on the user’s
selected offering, CloudStack emits usage records that can be integrated
with billing systems.
@@ -100,7 +100,7 @@ Compute offerings may be "fixed", "custom constrained" or "custom unconstrained"
In fixed offering the Number of CPUs, Memory and CPU frequency in each service
offerings are predefined by the CloudStack administrator, in custom unconstrained
offerings they are left undefined so that the end-user can enter their own desired
-values when creating a guest instance. Since 4.13 custom constrained offerings have
+values when creating a Guest Instance. Since 4.13 custom constrained offerings have
been introduced to allow the end-user to enter the number of CPUs and memory
required within constraints set by the administrator. The constraints can be
different for different custom constrained offerings. This is useful to reduce
@@ -108,7 +108,7 @@ the number of offerings the CloudStack administrator has to define; Instead of
defining a compute offering for every imaginable combination of values that a user
might want, the administrator can define offerings that provide some
flexibility to the users and can serve as the basis for several
-different VM configurations.
+different Instance configurations.
A service offering includes the following elements:
@@ -121,7 +121,7 @@ A service offering includes the following elements:
- 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
+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.
CloudStack separates service offerings into compute offerings and disk
@@ -149,22 +149,22 @@ The disk offering specifies:
To support the custom offerings, usage events register events for dynamically
-assigned resources. Usage events are registered when a VM is created
+assigned resources. Usage events are registered when an Instance is created
from a custom compute offering, and upon changing
-the compute offering of a stopped or running VM. The values of the
+the compute offering of a stopped or running Instance. The values of the
parameters, such as CPU, speed, RAM are recorded.
Creating a New Compute Offering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Along with the compute details of the VM, root volume definition is also
+Along with the compute details of the Instance, root volume definition is also
included in the compute offering. The root volume specifications can be included
in the computer offering in two ways. One is disk specifications like disk size,
storage type, tags can be included directly in the compute offering. The other way
is linking a disk offering in the compute offering. The linked disk offering will
-be used for the root disk while creating the VM. Users can also choose a different
-disk offering for the root volume while creating the VM.
+be used for the root disk while creating the Instance. Users can also choose a different
+disk offering for the root volume while creating the Instance.
Following are the two ways of creating the compute offering.
@@ -203,7 +203,7 @@ To create a new compute offering:
displayed to users
- **Compute Offering Type**: The amount of freedom that the end user
- has to customise the compute power that their instance has when using this
+ has to customise the compute power that their Instance has when using this
compute offering. The options are; Fixed offering - user has no
ability to customise, Custom constrained - user has some latitude
to customise the compute within parameters set by the offering,
@@ -214,23 +214,23 @@ To create a new compute offering:
- **# of CPU cores**: The number of cores which should be allocated
to a system VM with this offering. If 'Custom constrained' is checked, the admin will
be asked to enter the minimum and maximum number of CPUs that a user
- can request. If 'Custom unconstrained' is checked, this
- field does not appear as the user will be prompted to enter a value when creating their guest instance.
+ can request. If 'Custom unconstrained' is checked, this field does not appear
+ as the user will be prompted to enter a value when creating their guest Instance.
- - **CPU (in MHz)**: The CPU speed of the cores that the guest instance is
+ - **CPU (in MHz)**: The CPU speed of the cores that the guest Instance is
allocated. For example, “2000” would provide a 2GHz CPU clock speed.
**This setting only used if CPU cap is selected.**
- This value is also passed to the hypervisor as a share value to give VMs
+ This value is also passed to the hypervisor as a share value to give Instances
relative priority when a hypervisor host is over-provisioned.
If 'Custom unconstrained' is checked this field does not appear as the user
- will be prompted to enter a value when creating their guest instance.
+ will be prompted to enter a value when creating their guest Instance.
- **Memory (in MB)**: The amount of memory in megabytes that the
system VM should be allocated. For example, “2048” would provide
a 2 GB RAM allocation. If 'Custom constrained' is selected, the admin will
be asked to enter the minimum and maximum amount of RAM that a user
can request. If 'Custom unconstrained' is selected, this field does
- not appear as the user will be prompted to enter a value when creating their guest instance.
+ not appear as the user will be prompted to enter a value when creating their guest Instance.
- **Host Tags**: (Optional) Any tags that you use to organize your
hosts
@@ -240,30 +240,30 @@ To create a new compute offering:
- **Offer HA**: If yes, the administrator can choose to have the
system VM be monitored and as highly available as possible.
- - **Dynamic Scaling Enabled**: If yes, virtual machine can be dynamically scalable of cpu or memory
+ - **Dynamic Scaling Enabled**: If yes, Instance can be dynamically scalable of cpu or memory
- **CPU cap**: Whether to limit the level of CPU usage even if spare
capacity is available.
- - **Volatile**: If checked, VMs created from this service offering
+ - **Volatile**: If checked, Instances created from this service offering
will have their root disks reset upon reboot. This is useful for
secure environments that need a fresh start on every boot and for
desktops that should not retain state.
- **Deployment Planner**: Choose the technique that you would like
- CloudStack to use when deploying VMs based on this service
+ CloudStack to use when deploying Instances based on this service
offering.
- - **First Fit**: places new VMs on the first host that is found having
- sufficient capacity to support the VM's requirements.
+ - **First Fit**: places new Instances on the first host that is found having
+ sufficient capacity to support the Instance's requirements.
- - **User Dispersing**: makes the best effort to evenly distribute VMs
+ - **User Dispersing**: makes the best effort to evenly distribute Instances
belonging to the same account on different clusters or pods.
- - **User Concentrated**: prefers to deploy VMs belonging to the same
+ - **User Concentrated**: prefers to deploy Instances belonging to the same
account within a single pod.
- - **Implicit Dedication**: will deploy VMs on private infrastructure that
+ - **Implicit Dedication**: will deploy instances on private infrastructure that
is dedicated to a specific domain or account. If you choose this
planner, then you must also pick a value for Planner Mode. See
`Dedicating Resources to Accounts and Domains <accounts.html#dedicating-resources-to-accounts-and-domains>`_.
@@ -272,7 +272,7 @@ To create a new compute offering:
Installation in the Installation Guide.
- **Planner Mode**: Used when ImplicitDedicationPlanner is selected
- in the previous field. The planner mode determines how VMs will be
+ in the previous field. The planner mode determines how instances will be
deployed on private infrastructure that is dedicated to a single
domain or account.
@@ -282,25 +282,25 @@ To create a new compute offering:
be shared between different accounts without violating the desktop
software's terms of license.
- - Preferred: The VM will be deployed in dedicated infrastructure if
- possible. Otherwise, the VM can be deployed in shared infrastructure.
+ - Preferred: The instance will be deployed in dedicated infrastructure if
+ possible. Otherwise, the instance can be deployed in shared infrastructure.
- **GPU**: Assign a physical GPU(GPU-passthrough) or a portion of a physical
- GPU card (vGPU) to the guest VM. It allows graphical applications to run on the VM.
+ GPU card (vGPU) to the guest instance. It allows graphical applications to run on the instance.
Select the card from the supported list of cards.
The options given are NVIDIA GRID K1 and NVIDIA GRID K2. These are vGPU
capable cards that allow multiple vGPUs on a single physical GPU. If you
want to use a card other than these, follow the instructions in the
- **"GPU and vGPU support for CloudStack Guest VMs"** page in the
+ **"GPU and vGPU support for CloudStack Guest instances"** page in the
Cloudstack Version 4.4 Design Docs found in the Cloudstack Wiki.
- **vGPU Type**: Represents the type of virtual GPU to be assigned to a
- guest VM. In this case, only a portion of a physical GPU card (vGPU) is
- assigned to the guest VM.
+ guest instance. In this case, only a portion of a physical GPU card (vGPU) is
+ assigned to the guest instance.
Additionally, the **passthrough vGPU** type is defined to represent a physical GPU
- device. A **passthrough vGPU** can directly be assigned to a single guest VM.
+ device. A **passthrough vGPU** can directly be assigned to a single guest instance.
In this case, a physical GPU device is exclusively allotted to a single
- guest VM.
+ guest instance.
- **Public**: Indicate whether the compute offering should be
available to all domains or only some domains. Choose Yes to make it
@@ -379,7 +379,7 @@ To create a new compute offering:
if the root disk is 20 GB and Hypervisor Snapshot Reserve is 200%, the
storage volume that backs the storage repository (XenServer) or
datastore (VMware) in question is sized at 60 GB (20 GB + (20 GB * 2)).
- This enables space for hypervisor snapshots in addition to the virtual
+ This enables space for hypervisor Snapshots in addition to the virtual
disk that represents the root disk. This does not apply for KVM.
- **Storage Tags**: The tags that should be associated with the
@@ -393,14 +393,14 @@ To create a new compute offering:
- **Disk Offerings**: Select one disk offering from the list with which compute offering will be associated
- **Disk Offering Strictness**: This flag defines the strictness of the disk offering association
- with the compute offering. When set to true, overriding of disk offering is not allowed on deploy VM
+ with the compute offering. When set to true, overriding of disk offering is not allowed on deploy instance
and change disk offering is not allowed for the ROOT disk
#. Click Add.
-.. [1] These options are dependant on the capabilities of the hypervisor or the shared storage system which the VMs are on.
+.. [1] These options are dependant on the capabilities of the hypervisor or the shared storage system which the instances are on.
If the hypervisor or underlying storage don't support a particular capability in the offering, the setting will have no effect.
@@ -477,7 +477,7 @@ To create a new disk offering:
if the data disk is 20 GB and Hypervisor Snapshot Reserve is 200%, the
storage volume that backs the storage repository (XenServer) or
datastore (VMware) in question is sized at 60 GB (20 GB + (20 GB * 2)).
- This enables space for hypervisor snapshots in addition to the virtual
+ This enables space for hypervisor Snapshots in addition to the virtual
disk that represents the data disk. This does not apply for KVM.
- **(Optional)Storage Tags**: The tags that should be associated with
@@ -508,7 +508,7 @@ To create a new disk offering:
#. Click Add.
-.. [2] These options are dependant on the capabilities of the hypervisor or the shared storage system which the VMs are on.
+.. [2] These options are dependant on the capabilities of the hypervisor or the shared storage system which the instances are on.
If the hypervisor or underlying storage don't support a particular capability in the offering, the setting will have no effect.
@@ -524,7 +524,7 @@ click on the update offering access button |update-service-offering-button.png|.
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
+use, it will remain in the database until all the Instances
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.
@@ -535,7 +535,7 @@ 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
+being used for Instance 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
@@ -658,13 +658,13 @@ Storage network of Console Proxy VM System Network Offering
Management network of Console Proxy VM System Network Offering
Storage network of Virtual Router System Network Offering
Management network of Virtual Router System Network Offering
-Public network of Secondary Storage VM System Network Offering
-Public network of Console Proxy VM System Network Offering
-Default network of a guest VM Compute Offering
-Additional networks of a guest VM Corresponding Network Offerings
+Public network of Secondary Storage instance System Network Offering
+Public network of Console Proxy instance System Network Offering
+Default network of a guest instance Compute Offering
+Additional networks of a guest instance Corresponding Network Offerings
=========================================== ===============================
-A guest VM must have a default network, and can also have many
+A guest instance must have a default network, and can also have many
additional networks. Depending on various parameters, such as the host
and virtual switch used, you can observe a difference in the network
rate in your cloud. For example, on a VMware host the actual network
diff --git a/source/adminguide/storage.rst b/source/adminguide/storage.rst
index 1695b89..84bbe62 100644
--- a/source/adminguide/storage.rst
+++ b/source/adminguide/storage.rst
@@ -63,10 +63,10 @@ Best Practices for Primary Storage
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.
+Root volumes are created automatically when an Instance is
+created. Root volumes are deleted when the Instance is destroyed. Data volumes
+can be created and dynamically attached to Instances. Data volumes are not
+deleted when Instances are destroyed.
Administrators should monitor the capacity of primary storage devices
and add additional primary storage as needed. See :ref:`add-primary-storage`.
@@ -75,11 +75,11 @@ Administrators add primary storage to the system by creating a
CloudStack storage pool. Each storage pool is associated with a cluster
or a zone.
-With regards to data disks, when a user executes a Disk Offering to
+With regards to data disks, when a User executes a Disk Offering to
create a data disk, the information is initially written to the
CloudStack database only. Upon the first request that the data disk be
-attached to a VM, CloudStack determines what storage to place the volume
-on and space is taken from that storage (either from preallocated
+attached to an Instance, CloudStack determines what storage to place the volume
+on and space is taken from that storage (either from pre-allocated
storage or from a storage system (ex. a SAN), depending on how the
primary storage was added to CloudStack).
@@ -107,7 +107,7 @@ Storage media \\ hypervisor VMware vSphere Citrix XenServer
**PowerFlex/ScaleIO** No No Yes No
============================================== ================ ==================== =========================== ============================
-XenServer uses a clustered LVM system to store VM images on iSCSI and
+XenServer uses a clustered LVM system to store Instance 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
@@ -275,7 +275,7 @@ under "Browser" tab for a secondary storage.
Read only
~~~~~~~~~
Secondary storages can also be set to read-only in order to cordon it off
-from being used for storing any further templates, volumes and snapshots.
+from being used for storing any further Templates, Volumes and Snapshots.
.. code:: bash
@@ -285,9 +285,9 @@ from being used for storing any further templates, volumes and snapshots.
Working With Volumes
--------------------
-A volume provides storage to a guest VM. The volume can provide for a
+A volume provides storage to a Guest Instance. The volume can provide for a
root disk or an additional data disk. CloudStack supports additional
-volumes for guest VMs.
+volumes for Guest Instances.
Volumes are created for a specific hypervisor type. A volume that has
been attached to guest using one hypervisor type (e.g, XenServer) may
@@ -295,15 +295,15 @@ not be attached to a guest that is using another hypervisor type, for
example: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 "/"
+CloudStack defines a volume as a unit of storage available to a Guest
+Instance. 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, for example: "/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
+for additional storage, for example: "/opt" or "D:". Every Guest Instance has
+a root disk, and Instances can also optionally have a data disk. End Users can
+mount multiple data disks to Guest Instances. 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
+Template creation. Volumes are hypervisor-specific: a volume from one
hypervisor type may not be used on a guest of another hypervisor type.
.. note::
@@ -320,31 +320,31 @@ hypervisor type may not be used on a guest of another hypervisor type.
Creating a New Volume
~~~~~~~~~~~~~~~~~~~~~
-You can add more data disk volumes to a guest VM at any time, up to the
+You can add more data disk volumes to a Guest Instance at any time, up to the
limits of your storage capacity. Both CloudStack administrators and
-users can add volumes to VM instances. When you create a new volume, it
+Users can add volumes to Instances. When you create a new volume, it
is stored as an entity in CloudStack, but the actual storage resources
are not allocated on the physical storage device until you attach the
volume. This optimization allows the CloudStack to provision the volume
nearest to the guest that will use it when the first attachment is made.
-When creating a new volume from an existing ROOT volume snapshot,
+When creating a new volume from an existing ROOT Volume Snapshot,
it is required to explicitly define a Disk offering (UI will offer only Disk
-offerings whose disk size is equal or bigger than the size of the snapshot).
+offerings whose disk size is equal or bigger than the size of the Snapshot).
|volume-from-snap.png|
-When creating a new volume from an existing DATA volume snapshot, the disk offering
-associated with the snapshots (inherited from the original volume) is assigned
+When creating a new volume from an existing DATA Volume Snapshot, the disk offering
+associated with the Snapshots (inherited from the original volume) is assigned
to the new volume.
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
+KVM, and VMware). The data volume is placed on the same host as the Instance,
+that is attached to the data volume. These local data volumes
+can be attached to Instances, 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
@@ -354,20 +354,20 @@ 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
+You can create a data disk offering for local storage. When a User
+creates a new Instance, 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
+You can not migrate an Instance 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.
+Instances with local data volumes on that host.
To Create a New Volume
^^^^^^^^^^^^^^^^^^^^^^
-#. Log in to the CloudStack UI as a user or admin.
+#. Log in to the CloudStack UI as a User or admin.
#. In the left navigation bar, click Storage.
@@ -379,7 +379,7 @@ To Create a New Volume
- 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.
+ should be close to the Instance that will use the volume.
- Disk Offering. Choose the characteristics of the storage.
@@ -390,14 +390,14 @@ To Create a New Volume
#. To start using the volume, continue to Attaching a Volume
-Uploading an Existing Volume to a Virtual Machine
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Uploading an Existing Volume to an Instance
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-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.
+Existing data can be made accessible to an Instance. This is
+called uploading a volume to the Instance. For example, this is useful to
+upload data from a local file system and attach it to an Instance. Root
+administrators, domain administrators, and end Users can all upload
+existing volumes to Instances.
The upload is performed using HTTP. The uploaded volume is placed in the
zone's secondary storage
@@ -414,7 +414,7 @@ To upload a volume:
you are going to upload. After uploading the data disk, CloudStack
will use this value to verify that no data corruption has occurred.
-#. Log in to the CloudStack UI as an administrator or user
+#. Log in to the CloudStack UI as an administrator or User
#. In the left navigation bar, click Storage.
@@ -426,7 +426,7 @@ To upload a volume:
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.
+ volume. Instances 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.
@@ -458,9 +458,9 @@ To upload a volume:
Attaching a Volume
~~~~~~~~~~~~~~~~~~
-You can attach a volume to a guest VM to provide extra disk storage.
+You can attach a volume to a Guest Instance 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
+an existing volume from one Instance to another, or after you have migrated a
volume from one storage pool to another.
#. Log in to the CloudStack UI as a user or admin.
@@ -472,13 +472,13 @@ volume from one storage pool to another.
#. Click the volume name in the Volumes list, then click the Attach Disk
button |AttachDiskButton.png|
-#. 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
+#. In the Instance popup, choose the Instance 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.
+ clicking Instances, the Instance name, and View Volumes.
Detaching and Moving Volumes
@@ -486,62 +486,62 @@ Detaching and Moving Volumes
.. note::
This procedure is different from moving volumes from one storage pool
- to another as described in `“VM Storage Migration”
+ to another as described in `“Instance Storage Migration”
<#vm-storage-migration>`_.
-A volume can be detached from a guest VM and attached to another guest.
-Both CloudStack administrators and users can detach volumes from VMs and
-move them to other VMs.
+A volume can be detached from a Guest Instance and attached to another guest.
+Both CloudStack administrators and users can detach volumes from Instances and
+move them to other Instances.
-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.
+If the two Instances are in different clusters, and the volume is large, it
+may take several minutes for the volume to be moved to the new Instance.
#. Log in to the CloudStack 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
+ Select View. Alternatively, if you know which Instance the volume is
+ attached to, you can click Instances, click the Instance name, and click
View Volumes.
#. Click the name of the volume you want to detach, then click the
Detach Disk button. |DetachDiskButton.png|
-#. To move the volume to another VM, follow the steps in
+#. To move the volume to another Instance, follow the steps in
`“Attaching a Volume” <#attaching-a-volume>`_.
-VM Storage Migration
+Instance Storage Migration
~~~~~~~~~~~~~~~~~~~~
Supported in XenServer, KVM, and VMware.
.. note::
- This procedure is different from moving disk volumes from one VM to
+ This procedure is different from moving disk volumes from one Instance to
another as described in `“Detaching and Moving Volumes”
<#detaching-and-moving-volumes>`_.
-You can migrate a virtual machine’s root disk volume or any additional
+You can migrate an Instance’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
+pools and increasing the reliability of Instances by moving them
away from any storage pool that is experiencing issues.
-On XenServer and VMware, live migration of VM storage is enabled through
+On XenServer and VMware, live migration of Instance storage is enabled through
CloudStack support for XenMotion and vMotion. Live storage migration
-allows VMs to be moved from one host to another, where the VMs are not
+allows Instances to be moved from one host to another, where the Instances are not
located on storage shared between the two hosts. It provides the option
-to live migrate a VM’s disks along with the VM itself. It is possible to
-migrate a VM from one XenServer resource pool / VMware cluster to
-another, or to migrate a VM whose disks are on local storage, or even to
-migrate a VM’s disks from one storage repository to another, all while
-the VM is running.
+to live migrate an Instance’s disks along with the Instance itself. It is possible to
+migrate an Instance from one XenServer resource pool / VMware cluster to
+another, or to migrate an Instance whose disks are on local storage, or even to
+migrate an Instance’s disks from one storage repository to another, all while
+the Instance is running.
.. note::
- Because of a limitation in VMware, live migration of storage for a
- VM is allowed only if the source and target storage pool are
- accessible to the source host; that is, the host where the VM is
+ Because of a limitation in VMware, live migration of storage for an
+ Instance is allowed only if the source and target storage pool are
+ accessible to the source host; that is, the host where the Instance is
running when the live migration operation is requested.
@@ -551,25 +551,25 @@ Migrating a Data Volume to a New Storage Pool
There are two situations when you might want to migrate a disk:
- Move the disk to new storage, but leave it attached to the same
- running VM.
+ running Instance.
-- Detach the disk from its current VM, move it to new storage, and
- attach it to a new VM.
+- Detach the disk from its current Instance, move it to new storage, and
+ attach it to a new Instance.
-Migrating Storage For a Running VM
-''''''''''''''''''''''''''''''''''
+Migrating Storage For a Running Instance
+''''''''''''''''''''''''''''''''''''''''
(Supported on XenServer and VMware)
#. Log in to the CloudStack UI as a user or admin.
-#. In the left navigation bar, click Instances, click the VM name, and
+#. In the left navigation bar, click Instances, click the Instance name, and
click View Volumes.
#. Click the volume you want to migrate.
-#. Detach the disk from the VM. See `“Detaching and
+#. Detach the disk from the Instance. See `“Detaching and
Moving Volumes” <#detaching-and-moving-volumes>`_ but skip the “reattach”
step at the end. You will do that after migrating to new storage.
@@ -580,12 +580,12 @@ Migrating Storage For a Running VM
Ready.
-Migrating Storage and Attaching to a Different VM
-'''''''''''''''''''''''''''''''''''''''''''''''''
+Migrating Storage and Attaching to a Different Instance
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''
#. Log in to the CloudStack UI as a user or admin.
-#. Detach the disk from the VM. See `“Detaching and
+#. Detach the disk from the Instance. See `“Detaching and
Moving Volumes” <#detaching-and-moving-volumes>`_ but skip the “reattach”
step at the end. You will do that after migrating to new storage.
@@ -597,44 +597,44 @@ Migrating Storage and Attaching to a Different VM
navigation bar. Make sure that Volumes is displayed at the top of the
window, in the Select View dropdown.
-#. Attach the volume to any desired VM running in the same cluster as
+#. Attach the volume to any desired Instance running in the same cluster as
the new storage server. See `“Attaching a
Volume” <#attaching-a-volume>`_
-Migrating a Instance Root Volume to a New Storage Pool
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Migrating an Instance Root Volume to a New Storage Pool
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-(XenServer, VMware) You can live migrate a instance's root disk from one
-storage pool to another, without stopping the instance first.
+(XenServer, VMware) You can live migrate an Instance's root disk from one
+storage pool to another, without stopping the Instance first.
-(KVM) When migrating the root disk volume, the instance must first be stopped,
-and users can not access the instance. After migration is complete, the instance
-can be restarted.
+(KVM) When migrating the root disk volume, the Instance must first be stopped,
+and users can not access the Instance. After migration is complete, the Instance can
+be restarted.
#. Log in to the CloudStack UI as a user or admin.
-#. In the left navigation bar, click Instances, and click the instance name.
+#. In the left navigation bar, click Instances, and click the Instance name.
-#. (KVM only) Stop the instance.
+#. (KVM only) Stop the Instance.
#. Click the Migrate button |Migrateinstance.png| and choose the
destination from the dropdown list.
.. note::
- If the instance's storage has to be migrated along with the instance,
- this will be noted in the host list. CloudStack will take care of the storage
+ If the Instance's storage has to be migrated along with the Instance, this will
+ be noted in the host list. CloudStack will take care of the storage
migration for you.
#. Watch for the volume status to change to Migrating, then back to
Running (or Stopped, in the case of KVM). This can take some time.
-#. (KVM only) Restart the instance.
+#. (KVM only) Restart the Instance.
.. note::
In case of KVM and PowerFlex/ScaleIO storage, live migration of
- instance's root disk is allowed from one PowerFlex/ScaleIO storage pool
- to another, without stopping the instance.
+ Instance's root disk is allowed from one PowerFlex/ScaleIO storage pool
+ to another, without stopping the Instance.
Resizing Volumes
@@ -662,7 +662,7 @@ shrinking volumes is not supported on VMware hosts.
Before you try to resize a volume, consider the following:
-- The VMs associated with the volume are stopped.
+- The Instances associated with the volume are stopped.
- The data disks associated with the volume are removed.
@@ -701,17 +701,17 @@ To resize a volume:
Root Volume size defined via Service Offering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If a Service Offering is created with a root disk size, then resizing the Root volume is possible only by resizing the VMs service offering.
+If a Service Offering is created with a root disk size, then resizing the Root volume is possible only by resizing the Instances service offering.
Service offering Root resizing constrains:
-#. Users cannot deploy VMs with custom root disk size when using such offerings
+#. Users cannot deploy Instances with custom root disk size when using such offerings
-#. Users cannot resize the VM root disk size when using such offerings
+#. Users cannot resize the Instance root disk size when using such offerings
-#. The Root Volume of such VMs can only be resized when changing to another Service Offering with a Root disk size equals or larger than the current one.
+#. The Root Volume of such Instances can only be resized when changing to another Service Offering with a Root disk size equals or larger than the current one.
-#. Users can change the VM offering to a service offering with a Root size of 0GB (default) and then customize the volume size.
+#. Users can change the Instance offering to a service offering with a Root size of 0GB (default) and then customize the volume size.
The following table shows possible combinations of Service offering supported resizing based on the offering Root disk size:
@@ -764,19 +764,19 @@ To change the disk offering of a volume:
#. Click OK.
-Reset VM to New Root Disk on Reboot
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Reset Instance to New Root Disk on Reboot
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can specify that you want to discard the root disk and create a new
-one whenever a given VM is rebooted. This is useful for secure
+one whenever a given Instance is rebooted. This is useful for secure
environments that need a fresh start on every boot and for desktops that
-should not retain state. The IP address of the VM will not change due to
+should not retain state. The IP address of the Instance will not change due to
this operation.
-**To enable root disk reset on VM reboot:**
+**To enable root disk reset on Instance reboot:**
When creating a new service offering, set the parameter isVolatile to
-True. VMs created from this service offering will have their disks reset
+True. Instances created from this service offering will have their disks reset
upon reboot. See `“Creating a New Compute
Offering” <service_offerings.html#creating-a-new-compute-offering>`_.
@@ -784,18 +784,18 @@ Offering” <service_offerings.html#creating-a-new-compute-offering>`_.
Volume Deletion and Garbage Collection
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The deletion of a volume does not delete the snapshots that have been
+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
+When an Instance is destroyed, data disk volumes that are attached to the Instance
are not deleted unless specified.
-In managed storage systems such as Solidfire and others, the volume snapshots
+In managed storage systems such as Solidfire and others, the volume Snapshots
are linked entities in the volumes wherein deletion of the volume would delete
-those snapshots. In such managed storage systems, the volume snapshots exist on
+those Snapshots. In such managed storage systems, the volume Snapshots exist on
the primary storage and may not be backed up to the secondary storages. For a
volume deleted in CloudStack, it will not be deleted on the managed storage
-(such as Solidfire and others) until all the volume snapshots are deleted in
+(such as Solidfire and others) until all the volume Snapshots are deleted in
CloudStack.
Volumes are permanently destroyed using a garbage collection process.
@@ -848,29 +848,29 @@ Working with Volume 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
+CloudStack supports Snapshots of disk volumes. Snapshots are a
+point-in-time capture of Instance disks. Memory and CPU states
are not captured. If you are using the Oracle VM hypervisor, you can not
-take snapshots, since OVM does not support them.
+take Snapshots, since OVM does not support them.
Snapshots may be taken for volumes, including both root and data disks
(except when the Oracle VM hypervisor is used, which does not support
-snapshots). 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
+Snapshots). 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 an Instance 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
+not currently support booting a Instance 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.
+to an Instance.
-A completed snapshot is copied from primary storage to secondary
-storage, where it is stored until deleted or purged by newer snapshot.
+A completed Snapshot is copied from primary storage to secondary
+storage, where it is stored until deleted or purged by newer Snapshot.
Users can also select the desired zones at the time of taking manual snapshots
or while creating a snapshot policy. When additional zone(s) are selected and
@@ -886,24 +886,24 @@ How to Snapshot a Volume
#. In Select View, be sure Volumes is selected.
-#. Click the name of the volume you want to snapshot.
+#. Click the name of the volume you want to Snapshot.
#. Click the Snapshot button. |SnapshotButton.png|
KVM volume Snapshot specifics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-In recent CloudStack versions, by default, creating a volume snapshot for a running VM is disabled
-due to a possible volume corruption in certain cases. To enable creating a volume snapshots while the VM
+In recent CloudStack versions, by default, creating a Volume Snapshot for a running Instance is disabled
+due to a possible volume corruption in certain cases. To enable creating a Volume Snapshots while the Instance
is running, the global setting 'kvm.snapshot.enabled' must be set to 'True'.
-The volume snapshot creation has changed in recent versions:
+The Volume Snapshot creation has changed in recent versions:
-Under the hood, first, a full VM snapshot is taken - this means that during the taking of
-the VM snapshot the VM will be in the "Paused" state (while RAM memory is being written to the
-QCOW2 file), which means that VM will be unavailable from the network point of view.
-When the VM snapshot is created, VM is unpaused/resumed, the single volume snapshot is exported
-to the Secondary Storage, and then the VM snapshots is removed from the VM.
+Under the hood, first, a full Instance Snapshot is taken - this means that during the taking of
+the Instance Snapshot the Instance will be in the "Paused" state (while RAM memory is being written to the
+QCOW2 file), which means that Instance will be unavailable from the Network point of view.
+When the Instance Snapshot is created, Instance is unpaused/resumed, the single Volume Snapshot is exported
+to the Secondary Storage, and then the Instance Snapshots is removed from the Instance.
Automatic Snapshot Creation and Retention
@@ -912,20 +912,20 @@ 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
+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.
+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
+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 CloudStack
administrator. See `“Globally Configured
Limits” <usage.html#globally-configured-limits>`_. 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
+to those Snapshots that are taken as part of an automatic recurring
+Snapshot policy. Additional manual Snapshots can be created and
retained.
@@ -933,7 +933,7 @@ 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
+Snapshot is created, it is immediately backed up to secondary storage
and removed from primary storage for optimal utilization of space on
primary storage.
@@ -952,24 +952,24 @@ incremental backups are supported, every N backup is a full backup.
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. CloudStack
-ensures that at least one snapshot is taken since the volume last became
+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 an Instance that is not running. CloudStack
+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
+When a Snapshot is taken manually, a Snapshot is always created
regardless of whether a volume has been active or not.
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
+There are two paths to restoring Snapshots. Users can create a volume
+from the Snapshot. The volume can then be mounted to an Instance and files
+recovered as needed. Alternatively, a Template may be created from the
+Snapshot of a root disk. The user can then boot an Instance from this Template
to effect recovery of the root disk.
Some hypervisor and storage combinations also allow for Instances and volumes
@@ -990,31 +990,31 @@ to be restored is present.
Snapshot Job Throttling
~~~~~~~~~~~~~~~~~~~~~~~
-When a snapshot of a virtual machine is requested, the snapshot job runs
-on the same host where the VM is running or, in the case of a stopped
-VM, the host where it ran last. If many snapshots are requested for VMs
-on a single host, this can lead to problems with too many snapshot jobs
+When a Snapshot of an Instance is requested, the Snapshot job runs
+on the same host where the Instance is running or, in the case of a stopped
+Instance, the host where it ran last. If many Snapshots are requested for Instances
+on a single host, this can lead to problems with too many Snapshot jobs
overwhelming the resources of the host.
To address this situation, the cloud's root administrator can throttle
-how many snapshot jobs are executed simultaneously on the hosts in the
+how many Snapshot jobs are executed simultaneously on the hosts in the
cloud by using the global configuration setting
concurrent.snapshots.threshold.perhost. By using this setting, the
-administrator can better ensure that snapshot jobs do not time out and
+administrator can better ensure that Snapshot jobs do not time out and
hypervisor hosts do not experience performance issues due to hosts being
-overloaded with too many snapshot requests.
+overloaded with too many Snapshot requests.
Set concurrent.snapshots.threshold.perhost to a value that represents a
-best guess about how many snapshot jobs the hypervisor hosts can execute
+best guess about how many Snapshot jobs the hypervisor hosts can execute
at one time, given the current resources of the hosts and the number of
-VMs running on the hosts. If a given host has more snapshot requests,
-the additional requests are placed in a waiting queue. No new snapshot
-jobs will start until the number of currently executing snapshot jobs
+Instances running on the hosts. If a given host has more Snapshot requests,
+the additional requests are placed in a waiting queue. No new Snapshot
+jobs will start until the number of currently executing Snapshot jobs
falls below the configured limit.
The admin can also set job.expire.minutes to place a maximum on how long
-a snapshot request will wait in the queue. If this limit is reached, the
-snapshot request fails and returns an error message.
+a Snapshot request will wait in the queue. If this limit is reached, the
+Snapshot request fails and returns an error message.
Snapshot Copy
@@ -1031,20 +1031,20 @@ deleted without affecting other replicas.
VMware Volume Snapshot Performance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-When you take a snapshot of a data or root volume on VMware, CloudStack
+When you take a Snapshot of a data or root volume on VMware, CloudStack
uses an efficient storage technique to improve performance.
-A snapshot is not immediately exported from vCenter to a mounted NFS
+A Snapshot is not immediately exported from vCenter to a mounted NFS
share and packaged into an OVA file format. This operation would consume
time and resources. Instead, the original file formats (e.g., VMDK)
provided by vCenter are retained. An OVA file will only be created as
needed, on demand. To generate the OVA, CloudStack uses information in a
properties file (\*.ova.meta) which it stored along with the original
-snapshot data.
+Snapshot data.
.. note::
For upgrading customers: This process applies only to newly created
- snapshots after upgrade to CloudStack 4.2. Snapshots that have already
+ Snapshots after upgrade to CloudStack 4.2. Snapshots that have already
been taken and stored in OVA format will continue to exist in that
format, and will continue to work as expected.
@@ -1055,13 +1055,13 @@ Linstor Primary Storage
LINSTOR is a configuration management system for storage on Linux systems.
It manages LVM logical volumes and/or ZFS ZVOLs on a cluster of nodes.
It leverages DRBD for replication between different nodes and to provide block storage devices
-to users and applications. It manages snapshots, encryption and caching of HDD backed data in SSDs via bcache.
+to users and applications. It manages Snapshots, encryption and caching of HDD backed data in SSDs via bcache.
LINSTOR can be used as volume storage provider for Cloudstack, it currently only supports KVM hypervisors.
To get started first setup your LINSTOR cluster according to the `LINSTOR User Guide <https://linbit.com/drbd-user-guide/linstor-guide-1_0-en/>`_
.. note::
- Make sure a LINSTOR-Satellite is running on all nodes where you want to have a storage provided for you VM's
+ Make sure a LINSTOR-Satellite is running on all nodes where you want to have a storage provided for you Instances
and that the nodes have the exact same node names as the nodes in Cloudstack.
Also add a resource group to LINSTOR which you intend to use in Cloudstack.
@@ -1088,4 +1088,4 @@ and use the resource group name you added in the LINSTOR cluster.
.. |volume-metrics.png| image:: /_static/images/volume-metrics.png
:alt: Volume metrics
.. |volume-from-snap.png| image:: /_static/images/volume-from-snap.png
- :alt: Offering is needed when creating a volume from the ROOT volume snapshot.
+ :alt: Offering is needed when creating a volume from the ROOT Volume Snapshot.
diff --git a/source/adminguide/systemvm.rst b/source/adminguide/systemvm.rst
index 15c39bf..cdda0ca 100644
--- a/source/adminguide/systemvm.rst
+++ b/source/adminguide/systemvm.rst
@@ -14,7 +14,7 @@
under the License.
-CloudStack uses several types of system virtual machines to perform
+CloudStack uses several types of system Instances 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
@@ -24,7 +24,7 @@ roles to assist in debugging issues.
The System VM Template
----------------------
-The System VMs come from a single template. The System VM has the
+The System VMs come from a single Template. The System VM has the
following characteristics:
- Debian 10.8(buster), 4.19.0 kernel with the latest security
@@ -53,7 +53,7 @@ Changing the Default System VM Template
The 64-bit template should be used with a System Offering of at least 512MB
of memory.
-#. Based on the hypervisor you use, download the 64-bit template - e.g. from
+#. Based on the hypervisor you use, download the 64-bit Template - e.g. from
the following location:
.. cssclass:: table-striped table-bordered table-hover
@@ -69,25 +69,25 @@ of memory.
#. As an administrator, log in to the CloudStack UI
-#. Register the 64-bit template.
+#. Register the 64 bit Template.
For example: KVM64bitTemplate
-#. While registering the template, select Routing.
+#. While registering the Template, select Routing.
#. Navigate to Configuration, Global Settings:
-#. Set the name of the 64-bit template, KVM64bitTemplate, in the
+#. Set the name of the 64-bit Template, KVM64bitTemplate, in the
*``router.template.kvm``* global parameter.
- If you are using a XenServer 64-bit template, set the name in the
+ If you are using a XenServer 64-bit Template, set the name in the
*``router.template.xenserver``* global parameter.
- If you are using a VMware 64-bit template, set the name in the
+ If you are using a VMware 64-bit Template, set the name in the
*``router.template.vmware``* global parameter.
Any new virtual router created in this Zone automatically picks up
- this template.
+ this Template.
#. Restart the Management Server.
@@ -140,11 +140,11 @@ System VMs running on ESXi, the key is stored on the management server at
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.
+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
+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
@@ -164,12 +164,12 @@ Clicking a console icon brings up a new window. The console viewer
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 viewer 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 connection to the VNC port for the requested instance on the Host hosting
the guest.
Since 4.15, noVNC has been integrated into the console proxy and is the
default viewer. It inherently supports multiple keyboard layouts configured
-in the guest virtual machine. Additionally, it can scale the display as
+in the Guest Instance. Additionally, it can scale the display as
well as paste into the console.
noVNC is set as the default console viewer which be changed via the
@@ -187,26 +187,26 @@ 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
+Assignment of Guest Instance to console proxy is determined by first
+determining if the Guest Instance 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
+instance 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.
-Creating a VM Console Endpoint
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Creating an Instance Console Endpoint
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The access to a VM Console is created by the API 'createConsoleEndpoint',
-for the VM specified in the parameter 'virtualmachineid'. By default,
+The access to an instance console is created by the API 'createConsoleEndpoint',
+for the instance specified in the parameter 'virtualmachineid'. By default,
the CloudStack UI connects to the URL that this API generates.
The response of the 'createConsoleEndpoint' API also contain the information
to create a websocket session to the VNC server on the console proxy, this
-infomation includes: the host, port, path and token parameters required to
+information includes: the host, port, path and token parameters required to
establish a websocket session, bypassing the VNC client on the console proxy.
It is possible to add extra validation for the console proxy authentication,
@@ -361,7 +361,7 @@ http://123.123.123.123:8080/client/api?command=uploadCustomCertificate&...&name=
Here names are "root1" and "intermed1".
If you used other names previously, please check the cloud.keystore table to obtain used names.
-If you still have problems and folowing errors in management.log while destroying CPVM:
+If you still have problems and following errors in management.log while destroying CPVM:
- Unable to build keystore for CPVMCertificate due to CertificateException
- Cold not find and construct a valid SSL certificate
@@ -399,7 +399,7 @@ To implement SSL-Offloading you need 2 public IP addresses (one for Console Prox
each of them resolve to a different FQDN and terminate at the load balancer. Also 3 global settings need to be edited.
- The setting ‘consoleproxy.url.domain’ to the FQDN used by the certificate (For example: cpvm.company.com)
-- The setting ‘secstorage.ssl.cert.domain’ to the FQDN used by the cerrificate (For example: ssvm.company.com)
+- The setting ‘secstorage.ssl.cert.domain’ to the FQDN used by the certificate (For example: ssvm.company.com)
- The setting ‘secstorage.encrypt.copy’ to true
.. warning::
@@ -430,7 +430,7 @@ 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 from a Guest Instance. Some of the characteristics of the
virtual router are determined by its associated system service offering.
@@ -589,7 +589,7 @@ to the virtual router
This happens in the following steps:
1. Management server periodically pushes data to each running virtual router
-including schedule intervals, tests to skip, some configuration for LB, VMs,
+including schedule intervals, tests to skip, some configuration for LB, instances,
Gateways, etc.
2. Basic and advanced tests as scheduled as per the intervals in the data sent
@@ -610,7 +610,7 @@ fresh checks is expensive and will cause management server doing the following:
c. Fetch the result of the health check from router to be sent back in response.
-4. The patch also supports custom health checks with custom systemVM templates.
+4. The patch also supports custom health checks with custom systemVM Templates.
This is achieved as follows:
a. Each executable script placed in '/root/health_scripts/' is considered an
@@ -642,7 +642,7 @@ This is achieved as follows:
wanted commands and print some output to STDOUT; otherwise if it receives 'advanced'
as the first parameter, it should not execute any commands/logic nor print anything to STDOUT
-5. There are 9 health check scripts written in default systemvm template in '/root/health_checks/'
+5. There are 9 health check scripts written in default systemvm Template in '/root/health_checks/'
folder. These indicate the health checks described in executive summary.
6. The management server will connect periodically to each virtual router to confirm that the
@@ -693,7 +693,7 @@ Following global configs have been added for configuring health checks:
- ``router.health.checks.to.exclude`` - Health checks that should be excluded when
executing scheduled checks on the router. This can be a comma separated list of
script names placed in the '/root/health_checks/' folder. Currently the following
- scripts are placed in default systemvm template - cpu_usage_check.py,
+ scripts are placed in default systemvm Template - cpu_usage_check.py,
disk_space_check.py, gateways_check.py, iptables_check.py, router_version_check.py,
dhcp_check.py, dns_check.py, haproxy_check.py, memory_usage_check.py.
@@ -727,7 +727,7 @@ Details of individual checks:
d. Memory usage check against a threshold – we use 'free' utility to get the
used memory and compare that with the configured max memory usage threshold.
- e. Router template and scripts version check – is done by comparing the contents
+ e. Router Template and scripts version check – is done by comparing the contents
of the '/etc/cloudstack-release' and '/var/cache/cloud/cloud-scripts-signature'
with the data given by management server.
@@ -737,10 +737,10 @@ Details of individual checks:
2. Advanced checks:
a. DNS config match against MS – this is checked by comparing entries of '/etc/hosts'
- on the VR and VM records passed by management server.
+ on the VR and instance records passed by management server.
b. DHCP config match against MS – this is checked by comparing entries of
- '/etc/dhcphosts.txt' on the VR with the VM entries passed by management server.
+ '/etc/dhcphosts.txt' on the VR with the instance entries passed by management server.
c. HA Proxy config match against MS (internal LB and public LB) - this is checked
by verifying the max connections, and entries for each load balancing rule in the
@@ -823,7 +823,7 @@ Supported Virtual Routers
Upgrading Virtual Routers
^^^^^^^^^^^^^^^^^^^^^^^^^
-#. Download the latest System VM template.
+#. Download the latest System VM Template.
#. Download the latest System VM to all the primary storage pools.
@@ -837,7 +837,7 @@ Upgrading Virtual Routers
# cloudstack-sysvmadm -d <IP address> -u cloud -p -s
Even when the VRs are still on older versions, existing services will
- continue to be available to the VMs. The Management Server cannot
+ continue to be available to the instances. The Management Server cannot
perform any operations on the VRs until they are upgraded.
#. Selectively upgrade the VRs:
@@ -880,12 +880,12 @@ 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
+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.
+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.
@@ -893,7 +893,7 @@ The administrator can log in to the secondary storage VM if needed.
.. |update-ssl.png| image:: /_static/images/update-ssl.png
:alt: Updating Console Proxy SSL Certificate
.. |vr-upgrade.png| image:: /_static/images/vr-upgrade.png
- :alt: Button to upgrade VR to use the new template.
+ :alt: Button to upgrade VR to use the new Template.
Migrating System VMs
--------------------
@@ -929,7 +929,7 @@ The Extra Args parameter is for specifying command line optional parameters
as one would when executing any of the tools from the terminal or command line.
The supported versions are Debian 10 based since system VMs are built using the
-same Debian 10 based templates.
+same Debian 10 based Templates.
| See:
| Traceroute(1): https://manpages.debian.org/stretch/traceroute/traceroute.1.en.html
diff --git a/source/adminguide/templates.rst b/source/adminguide/templates.rst
index ced7cf9..7429c6e 100644
--- a/source/adminguide/templates.rst
+++ b/source/adminguide/templates.rst
@@ -16,79 +16,79 @@
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.
+A Template is a reusable configuration for Instances. When Users
+launch Instances, they can choose from a list of Templates in CloudStack.
-Specifically, a template is a virtual disk image that includes one of a
+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
+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.
+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: 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
+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.
+#. Launch an Instance that has the operating system you want. Make any
+ other desired configuration changes to the Instance.
-#. Stop the VM.
+#. Stop the Instance.
-#. Convert the volume into a template.
+#. 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.
+There are other ways to add Templates to CloudStack. For example, you
+can take a Snapshot of the Instance'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
+The various techniques for creating Templates are described in the next
few sections.
Requirements for Templates
--------------------------
-- For XenServer, install PV drivers / Xen tools on each template that
+- 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.
+- For vSphere, install VMware Tools on each Template that you create.
This will enable console view to work properly.
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.
+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 Template
--------------------
-CloudStack includes a CentOS template. This template is downloaded by
+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.
+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".
+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
+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.
+The default Template includes the standard iptables rules, which will
+block most access to the Template excluding ssh.
.. code:: bash
@@ -121,35 +121,35 @@ block most access to the template excluding ssh.
Private and Public Templates
----------------------------
-When a user creates a template, it can be designated private or public.
+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.
+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
+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.
+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 Machine
-----------------------------------------------------
+Creating a Template from an Existing Instance
+---------------------------------------------
-Once you have at least one VM set up in the way you want, you can use it
-as the prototype for other VMs.
+Once you have at least one Instance set up in the way you want, you can use it
+as the prototype for other Instances.
-#. Create and start a virtual machine using any of the techniques given
- in `“Creating VMs” <virtual_machines.html#creating-vms>`_.
+#. Create and start an Instance using any of the techniques given
+ in `“Creating Instances” <virtual_machines.html#creating-instances>`_.
-#. Make any desired configuration changes on the running VM, then click
+#. Make any desired configuration changes on the running Instance, then click
Stop.
-#. Wait for the VM to stop. When the status shows Stopped, go to the
+#. Wait for the Instance to stop. When the status shows Stopped, go to the
next step.
#. Go into "View Volumes" and select the Volume having the type "ROOT".
@@ -163,13 +163,13 @@ as the prototype for other VMs.
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 operating system of the stopped Instance is listed, choose it.
- - If the OS type of the stopped VM is not listed, choose Other.
+ - If the OS type of the stopped Instance is not listed, choose Other.
- - If you want to boot from this template in PV mode, 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:
+ for XenServer:
.. note::
Generally you should not choose an older version of the OS
@@ -178,35 +178,35 @@ as the prototype for other VMs.
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
+ - **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 `“Private and
Public Templates” <#private-and-public-templates>`_.
- - **Password Enabled**. Choose Yes if your template has the
+ - **Password Enabled**. Choose Yes if your Template has the
CloudStack password change script installed. See
:ref:`adding-password-management-to-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.
+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 Instance.
.. note::
- Since version 4.15, CloudStack obtains information from the VMware templates
- automatically at registration time. If a template contains different deployment
+ Since version 4.15, CloudStack obtains information from the VMware Templates
+ automatically at registration time. If a Template contains different deployment
options (or configurations) as in the case of virtual appliances, then CloudStack
- display the information required by the template, allowing users or administrators
- to configure their instances.
+ display the information required by the Template, allowing Users or administrators
+ to configure their Instances.
Creating a Template from a Snapshot
-----------------------------------
-If you do not want to stop the VM in order to use the Create Template
+If you do not want to stop the Instance in order to use the Create Template
menu item (as described in `“Creating a Template from an Existing
-Virtual Machine” <#creating-a-template-from-an-existing-virtual-machine>`_),
-you can create a template directly from any snapshot through the
+Instance” <#creating-a-template-from-an-existing-virtual-machine>`_),
+you can create a Template directly from any Snapshot through the
CloudStack UI.
@@ -218,15 +218,15 @@ Uploading Templates from a remote HTTP server
vSphere Templates and ISOs
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. warning::
- If you are uploading a template that was created using vSphere Client,
+ 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
+ of Instances 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:
+To upload a Template:
#. In the left navigation bar, click Templates.
@@ -240,11 +240,11 @@ To upload a template:
- **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
+ - **Zone**. Choose the zone where you want the Template to be
available, or All Zones to make it available throughout
CloudStack.
- - **Read VM settings from OVA**. (VMware only) If selected, the registered template will allow users to deploy VMs as clones of the template, including all their properties, configurations, end-user license agreements, disks, os type, etc. This option allows users to register virtual appliances. See `Support for Virtual Appliances <virtual_machines.html#about-virtual-appliances>`_.
+ - **Read Instance settings from OVA**. (VMware only) If selected, the registered Template will allow Users to deploy Instances as clones of the Template, including all their properties, configurations, end-user license agreements, disks, os type, etc. This option allows Users to register virtual appliances. See `Support for Virtual Appliances <virtual_machines.html#about-virtual-appliances>`_.
.. note::
When this option is selected the following fields are hidden: Root disk controller, Keyboard type and OS Type.
@@ -253,9 +253,9 @@ To upload a template:
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 operating system of the stopped Instance is listed, choose it.
- - If the OS type of the stopped VM is not listed, choose Other.
+ - If the OS type of the stopped Instance is not listed, choose Other.
.. note::
You should not choose an older version of the OS than the
@@ -264,9 +264,9 @@ To upload a template:
those cases you should choose Other.
.. note::
- Since version 4.15.1, VMware templates do not allow users or administrators
- selecting an OS Type when registering a template if the option 'Read VM settings from OVA' is selected. In this case, the OS Type is
- obtained from the template after it is registered.
+ Since version 4.15.1, VMware Templates do not allow Users or administrators
+ selecting an OS Type when registering a Template if the option 'Read Instance settings from OVA' is selected. In this case, the OS Type is
+ obtained from the Template after it is registered.
- **Userdata**: The registered Userdata are listed. Select the
desired one.
@@ -278,28 +278,28 @@ To upload a template:
- **Hypervisor**: The supported hypervisors are listed. Select the
desired one.
- - **Format**. The format of the template upload file, such as VHD or
+ - **Format**. The format of the Template upload file, such as VHD or
OVA.
- - **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.
+ - **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
+ - **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 `“Private and
Public Templates” <#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
+ - **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.
+ Template Featured.
-Note that uploading multi-disk templates is also supported.
+Note that uploading multi-disk Templates is also supported.
.. note::
- VMware only: If the template is registered with the option 'Read VM settings
- from OVA' then the VM deployment wizard will display all the available OVF
+ VMware only: If the Template is registered with the option 'Read Instance settings
+ from OVA' then the Instance deployment wizard will display all the available OVF
properties, different deployment options or configurations, multiple NICs or
end-user license agreements.
@@ -314,8 +314,8 @@ Note that uploading multi-disk templates is also supported.
Uploading Templates and ISOs from a local computer
-------------------------------------------
-It's also possible to upload an already prepared template or an ISO from your local computer.
-The steps are similar as when Uploading a template/ISO from a remote HTTP server, except that you need to choose a local template/ISO file from your PC.
+It's also possible to upload an already prepared Template or an ISO from your local computer.
+The steps are similar as when Uploading a Template/ISO from a remote HTTP server, except that you need to choose a local Template/ISO file from your PC.
For this feature to work, your SSVMs must be supporting HTTPS (for more info please visit `“Using a SSL Certificate for the Console Proxy”
<systemvm.html#using-a-ssl-certificate-for-the-console-proxy>`_).
@@ -325,68 +325,68 @@ Example GUI dialog of uploading Template/ISO from local (browser) is given below
|upload-iso-from-local.png|
-Note that uploading multi-disk templates is also supported.
+Note that uploading multi-disk Templates is also supported.
-Sharing templates and ISOs with other accounts/projects
-----------------------------------------------
+Sharing Templates and ISOs with other Accounts/projects
+-------------------------------------------------------
-When adding a template/ISO, the owner can choose to make template/ISO public or to keep it private. Once the template/ISO is created, the owner can choose to share this template/ISO so that other accounts/projects can also use the template/ISO.
+When adding a Template/ISO, the owner can choose to make Template/ISO public or to keep it private. Once the Template/ISO is created, the owner can choose to share this Template/ISO so that other Accounts/Projects can also use the Template/ISO.
-Currently, the owners can share their template/ISO with:
- - other accounts inside their own domain (i.e. can't share the template/ISO with other accounts in the subdomain of their domain or any other domains)
+Currently, the owners can share their Template/ISO with:
+ - other Accounts inside their own domain (i.e. can't share the Template/ISO with other Accounts in the subdomain of their domain or any other domains)
- projects where they belongs to (i.e. projects where they are the owners/creators or other projects where they have been joined)
-Template/ISO permissions can be changed via updateTemplatePermissions/updateIsoPermissions API call or via GUI. It is supported to add, remove or reset (remove all) template/ISO permissions.
+Template/ISO permissions can be changed via updateTemplatePermissions/updateIsoPermissions API call or via GUI. It is supported to add, remove or reset (remove all) Template/ISO permissions.
-When adding or removing permissions to/from a template/ISO, it is required to specify account/project name which is being added/removed from the template/ISO permissions.
+When adding or removing permissions to/from a Template/ISO, it is required to specify Account/Project name which is being added/removed from the Template/ISO permissions.
-Global setting "allow.user.view.all.domain.accounts" has a default value of "false". This makes sure that when the regular users (of a "User" role) wants to share a template/ISO via GUI, they will not be shown the list of all accounts in their domain and they will need to know the name of the destination account with which they are sharing the template/ISO. This makes sense in public clouds where each account of a single domain is a different tenant/customer and privacy is imperative. I [...]
+Global setting "allow.user.view.all.domain.accounts" has a default value of "false". This makes sure that when the regular Users (of a "User" role) wants to share a Template/ISO via GUI, they will not be shown the list of all Accounts in their domain and they will need to know the name of the destination Account with which they are sharing the Template/ISO. This makes sense in public clouds where each Account of a single domain is a different tenant/customer and privacy is imperative. In [...]
.. warning::
- The images displayed below refer to template permissions, but the same applies for ISO permissions.
+ The images displayed below refer to Template permissions, but the same applies for ISO permissions.
|template-permissions-update-manually-1.png|
-Sharing the template with account "user2"
+Sharing the Template with Account "user2"
|template-permissions-update-manually-2.png|
-Revoking permissions from account "user2"
+Revoking permissions from Account "user2"
-But in environments where privacy within a domain is not an issue, setting "allow.user.view.all.domain.accounts" setting to "true" will make sure that the user, who is sharing the template, will be presented a more user-friendly multi-select list, listing all the accounts in their domain. This is shown in the images below;
+But in environments where privacy within a domain is not an issue, setting "allow.user.view.all.domain.accounts" setting to "true" will make sure that the User, who is sharing the Template, will be presented a more User-friendly multi-select list, listing all the Accounts in their domain. This is shown in the images below;
|template-permissions-update-1.png|
-Sharing the template with just account "user8"
+Sharing the Template with just Account "user8"
|template-permissions-update-2.png|
-Sharing template with 2 specific projects
+Sharing Template with 2 specific projects
|template-permissions-update-3.png|
-Revoking permissions from account "user8"
+Revoking permissions from Account "user8"
|template-permissions-update-4.png|
Revoking permissions from both projects previously added
-Finally, template permissions can be reset:
+Finally, Template permissions can be reset:
|template-permissions-update-5.png|
Resetting (removing all) permissions
.. warning::
- Project-owned templates are not supported to be shared outside of
+ Project-owned Templates are not supported to be shared outside of
the Project, and if attempted to do so, a proper error message is shown.
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
+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.
.. include:: templates/_create_linux.rst
@@ -403,16 +403,16 @@ the Actions menu.
Deleting Templates
------------------
-Templates may be deleted. However when the templates are used the default
-behaviour is to refuse deletion. In general, when a template spans multiple
+Templates may be deleted. However when the Templates are used the default
+behaviour is to refuse deletion. 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
+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.
+When Templates are deleted, the Instances instantiated from them will continue
+to run. However, new Instances cannot be created based on the deleted
+Template.
As said, Cloudstack refuses to delete a template when VMs based on the
template exist. If this is the case, the parameter "forced" can be set
@@ -422,23 +422,23 @@ reinstalled from that template, but will be unaffected otherwise.
Working with ISOs
===================
-CloudStack supports ISOs and their attachment to guest VMs. An ISO is a
+CloudStack supports ISOs and their attachment to Guest Instances. 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.
+upload their own ISOs and mount them on their Guest Instances.
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
+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
+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
+CloudStack allows a User to boot a Guest Instance off of an ISO image. Users
+can also attach ISO images to Guest Instances. For example, this enables
installing PV drivers into Windows. ISO images are not
hypervisor-specific.
@@ -447,12 +447,12 @@ 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
+with Guest Instances, 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.
+part of a Template.
-#. Log in to the CloudStack UI as an administrator or end user.
+#. Log in to the CloudStack UI as an administrator or end User.
#. In the left navigation bar, click Templates.
@@ -492,9 +492,9 @@ part of a template.
- (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
+ - (KVM only) If you choose an OS that is PV-enabled, the Instances
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 OS is not PV-enabled, the Instances will have an IDE root disk.
The PV-enabled types are:
- Fedora 13
@@ -536,10 +536,10 @@ part of a template.
extraction.
- **Public**: Choose Yes if this ISO should be available to other
- users.
+ 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
+ prominent for Users to select. The ISO will appear in the Featured
ISOs list. Only an administrator can make an ISO Featured.
#. Click OK.
@@ -555,12 +555,12 @@ part of a template.
with it.
-Attaching an ISO to a VM
--------------------------
+Attaching an ISO to a Instance
+------------------------------
#. In the left navigation, click Instances.
-#. Choose the virtual machine you want to work with.
+#. Choose the Instance you want to work with.
#. Click the Attach ISO button. |iso.png|
@@ -582,15 +582,15 @@ Attaching an ISO to a VM
.. |template-upload-from-local.png| image:: /_static/images/template-upload-from-local.png
:alt: Upload Template from local
.. |template-permissions-update-manually-1.png| image:: /_static/images/template-permissions-update-manually-1.png
- :alt: USharing template with account "user2"
+ :alt: USharing template with Account "user2"
.. |template-permissions-update-manually-2.png| image:: /_static/images/template-permissions-update-manually-2.png
- :alt: Revoking permissions from account "user2"
+ :alt: Revoking permissions from Account "user2"
.. |template-permissions-update-1.png| image:: /_static/images/template-permissions-update-1.png
- :alt: Sharing template with just account "user8"
+ :alt: Sharing template with just Account "user8"
.. |template-permissions-update-2.png| image:: /_static/images/template-permissions-update-2.png
:alt: Sharing template with 2 specific projects
.. |template-permissions-update-3.png| image:: /_static/images/template-permissions-update-3.png
- :alt: Revoking permissins from account "user8"
+ :alt: Revoking permissins from Account "user8"
.. |template-permissions-update-4.png| image:: /_static/images/template-permissions-update-4.png
:alt: Revoking permsissons from both projects previously added
.. |template-permissions-update-5.png| image:: /_static/images/template-permissions-update-5.png
diff --git a/source/adminguide/templates/_bypass-secondary-storage-kvm.rst b/source/adminguide/templates/_bypass-secondary-storage-kvm.rst
index d45f048..0aa5376 100644
--- a/source/adminguide/templates/_bypass-secondary-storage-kvm.rst
+++ b/source/adminguide/templates/_bypass-secondary-storage-kvm.rst
@@ -16,16 +16,16 @@
.. _bypass-secondary-storage-kvm:
-Bypassing Secondary Storage For KVM templates
+Bypassing Secondary Storage For KVM Templates
---------------------------------------------
-CloudStack provides an additional way to register and use templates on KVM.
+CloudStack provides an additional way to register and use Templates on KVM.
-Instead of registering a template and storing it on secondary storage, the user can opt to skip downloading the template to secondary storage for KVM at template registration. At deployment time, the template is downloaded directly to primary storage from the registered source, instead of being copied from secondary storage.
+Instead of registering a Template and storing it on secondary storage, the user can opt to skip downloading the Template to secondary storage for KVM at Template registration. At deployment time, the Template is downloaded directly to primary storage from the registered source, instead of being copied from secondary storage.
-Supported protocols: HTTP/HTTPS, NFS and metalinks. The protocol is obtained from the template URL.
+Supported protocols: HTTP/HTTPS, NFS and metalinks. The protocol is obtained from the Template URL.
-To enable this option for a template:
+To enable this option for a Template:
#. In the left navigation bar, click Templates.
@@ -37,11 +37,11 @@ To enable this option for a template:
- **Direct Download**. This option will be shown in the UI when KVM is selected as the hypervisor. Choose Yes to enable the bypassing secondary storage option.
- - **Checksum**. Optional field. If this field is populated, the checksum is compared to the downloaded template checksum when the template is downloaded to primary storage at deployment time.
+ - **Checksum**. Optional field. If this field is populated, the checksum is compared to the downloaded Template checksum when the Template is downloaded to primary storage at deployment time.
-After the template is registered, it is automatically available for VM deployments.
+After the Template is registered, it is automatically available for instance deployments.
-From CloudStack 4.14.0, system VM templates also support direct download. An administrator can register a new system VM template as ROUTING or USER type with the direct download flag, and it can be changed to SYSTEM type during the upgrade or by out-of-band database changes. Type of newly registered template can be changed to SYSTEM in the database using a SQL query similar to:
+From CloudStack 4.14.0, system VM Templates also support direct download. An administrator can register a new system VM Template as ROUTING or USER type with the direct download flag, and it can be changed to SYSTEM type during the upgrade or by out-of-band database changes. Type of newly registered Template can be changed to SYSTEM in the database using a SQL query similar to:
.. code:: bash
@@ -50,7 +50,7 @@ From CloudStack 4.14.0, system VM templates also support direct download. An adm
Uploading Certificates for Direct Downloads
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-For direct downloads over HTTPS, the KVM hosts must have valid certificates. These certificates can be either self-signed or signed and will allow the KVM hosts to access the templates/ISOs and download them.
+For direct downloads over HTTPS, the KVM hosts must have valid certificates. These certificates can be either self-signed or signed and will allow the KVM hosts to access the Templates/ISOs and download them.
CloudStack provides some APIs to handle certificates for direct downloads:
@@ -84,8 +84,8 @@ CloudStack provides some APIs to handle certificates for direct downloads:
upload templatedirectdownloadcertificate hypervisor=KVM name=CERTIFICATE_ALIAS zoneid=ZONE_ID certificate=CERTIFICATE_FORMATTED hostid=HOST_ID
-Syncronising Certificates for Direct Downloads
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Synchronising Certificates for Direct Downloads
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As new hosts may be added to a zone which do not include a certificate which was previously uploaded to pre-existing hosts.
@@ -99,7 +99,7 @@ CloudStack provides a way to synchronize certificates across all the connected h
Direct Download Timeouts
~~~~~~~~~~~~~~~~~~~~~~~~
-With 4.14.0, ability to configure different timeout values for the direct downloading of templates has been added. Three new global settings have been added for this:
+With 4.14.0, ability to configure different timeout values for the direct downloading of Templates has been added. Three new global settings have been added for this:
- **direct.download.connect.timeout** - Connection establishment timeout in milliseconds for direct download. Default value: 5000 milliseconds.
diff --git a/source/adminguide/templates/_cloud_init.rst b/source/adminguide/templates/_cloud_init.rst
index c3dfa29..c6caa45 100644
--- a/source/adminguide/templates/_cloud_init.rst
+++ b/source/adminguide/templates/_cloud_init.rst
@@ -17,7 +17,7 @@
Cloud-init integration
-------------------------
-Cloudstack and cloud-init integration provide instances with advanced management features such as:
+Cloudstack and cloud-init integration provide Instances with advanced management features such as:
* Password management
* SSH keys management
@@ -34,7 +34,7 @@ Examples for relevant features are listed for different distributions.
Linux with Cloud-init
----------------------
-These features can be implemented in `“Linux template creation process” <_create_linux.html#creating-a-linux-template>`_. where they are executed just before the **Template cleanup** step.
+These features can be implemented in `“Linux Template creation process” <_create_linux.html#creating-a-linux-template>`_. where they are executed just before the **Template cleanup** step.
#. **Install and configure cloud-init**
@@ -65,11 +65,11 @@ These features can be implemented in `“Linux template creation process” <_cr
#. **Password management**
- Cloudstack integration with cloud-init `set_passwords module <https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=ssh_pwauth#set-passwords>`_ will enable the platform to set a password for each instance created from the Main Template. Additionally it will allow to reset the user password through the GUI.
+ Cloudstack integration with cloud-init `set-passwords module <https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=ssh_pwauth#set-passwords>`_ will enable the platform to set a password for each Instance created from the Main Template. Additionally it will allow to reset the user password through the GUI.
- **Enable set_passwords module on every boot**
- By default the set_passwords module runs only on first boot of the instance, change that to run on every boot.
+ By default the set-passwords module runs only on first boot of the Instance, change that to run on every boot.
.. code:: bash
@@ -92,7 +92,7 @@ These features can be implemented in `“Linux template creation process” <_cr
#. **SSH keys management**
Cloud-init `ssh module <https://cloudinit.readthedocs.io/en/latest/topics/modules.html#ssh>`_ can automatically install new SSH keys when set or reset from Cloudstack GUI.
- By default the module runs once during instance creation and will fetch Cloudstack keys without any additional configuration.
+ By default the module runs once during Instance creation and will fetch Cloudstack keys without any additional configuration.
To enable Cloudstack reset SSH keys feature configure cloud-init ssh module to run on every boot.
.. code:: bash
@@ -105,7 +105,7 @@ These features can be implemented in `“Linux template creation process” <_cr
If the cloud-init ssh module is set to run every boot, it will regenerate the certificate fingerprint of the host. This will cause a warning to anyone that logs in the system and also bring trouble to anyone trying to automate ssh access.
- Disable cloud-init regenerating host certificates on boot. If template certificates are deleted they will be regenerated by the OS on instance first boot.
+ Disable cloud-init regenerating host certificates on boot. If Template certificates are deleted they will be regenerated by the OS on instnace first boot.
.. code:: bash
@@ -206,7 +206,7 @@ These features can be implemented in `“Linux template creation process” <_cr
#. **User-data**
- Cloud-init can parse and execute user-data form Cloud-stack during instance creation. This feature works as is without additional configuration.
+ Cloud-init can parse and execute user-data form Cloud-stack during Instance creation. This feature works as is without additional configuration.
#. **Cleanup**
@@ -228,6 +228,6 @@ These features can be implemented in `“Linux template creation process” <_cr
rm -rf /etc/sudoers.d/*
-#. **Finalize template**
+#. **Finalize Template**
- Proceed with `“Linux template creation process” <_create_linux.html>`_ continuing with **Template cleanup** step.
+ Proceed with `“Linux Template creation process” <_create_linux.html>`_ continuing with **Template cleanup** step.
diff --git a/source/adminguide/templates/_convert_hyperv.rst b/source/adminguide/templates/_convert_hyperv.rst
index 9e15490..620d1ea 100644
--- a/source/adminguide/templates/_convert_hyperv.rst
+++ b/source/adminguide/templates/_convert_hyperv.rst
@@ -1,15 +1,15 @@
-Converting a Hyper-V VM to a Template
--------------------------------------
+Converting a Hyper-V Instance to a Template
+-------------------------------------------
-To convert a Hyper-V VM to a XenServer-compatible CloudStack template,
+To convert a Hyper-V Instance 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
+For Linux Instances, you may need to do some preparation in Hyper-V before
+trying to get the Instance to work in XenServer. Clone the Instance and work on the
+clone if you still want to use the Instance in Hyper-V. Uninstall Hyper-V
Integration Components and check for any references to device names in
/etc/fstab:
@@ -26,7 +26,7 @@ Integration Components and check for any references to device names in
those entries (if any) to mount by LABEL or UUID. You can get that
information with the blkid command.
-The next step is make sure the VM is not running in Hyper-V, then get
+The next step is make sure the Instance is not running in Hyper-V, then get
the VHD into XenServer. There are two options for doing this.
Option one:
@@ -36,10 +36,10 @@ Option one:
#. Choose the VHD, then click Next.
-#. Name the VM, choose the NFS VHD SR under Storage, enable "Run
+#. Name the Instance, 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.
+#. Click Next, then Finish. An Instance should be created.
Option two:
@@ -50,30 +50,30 @@ Option two:
#. Input the XenServer host info, then click Next.
-#. Name the VM, then click Next, then Convert. A VM should be created.
+#. Name the Instance, then click Next, then Convert. An Instance should be created.
-Once you have a VM created from the Hyper-V VHD, prepare it using the
+Once you have an Instance created from the Hyper-V VHD, prepare it using the
following steps:
-#. Boot the VM, uninstall Hyper-V Integration Services, and reboot.
+#. Boot the Instance, uninstall Hyper-V Integration Services, and reboot.
#. Install XenServer Tools, then reboot.
-#. Prepare the VM as desired. For example, run sysprep on Windows VMs.
+#. Prepare the Instance as desired. For example, run sysprep on Windows Instances.
See `“Creating a Windows
Template” <#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
+Either option above will create an Instance in HVM mode. This is fine for
+Windows Instances, but Linux Instances may not perform optimally. Converting a Linux
+instance 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
+#. Shut down the instance 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:
+#. In CloudStack, create a new Template using the following values:
- URL. Give the URL for the VHD
@@ -85,4 +85,4 @@ distribution.
- Format. VHD
-The template will be created, and you can create instances from it.
+The Template will be created, and you can create instances from it.
diff --git a/source/adminguide/templates/_create_linux.rst b/source/adminguide/templates/_create_linux.rst
index f8cee78..727b944 100644
--- a/source/adminguide/templates/_create_linux.rst
+++ b/source/adminguide/templates/_create_linux.rst
@@ -17,11 +17,11 @@
Creating a Linux Template
-------------------------
-Linux templates should be prepared using this documentation in order to
-prepare your linux VMs for template deployment. For ease of
-documentation, the VM which you are configuring the template on will be
+Linux Templates should be prepared using this documentation in order to
+prepare your linux Instances for Template deployment. For ease of
+documentation, the Instance which you are configuring the Template on will be
referred to as "Main Template". The final product, as created and usable
-for deplyoment in Cloudstack, will be referred as "Final Template".
+for deployment in Cloudstack, will be referred as "Final Template".
This guide will cover cloud-init setup and scripted setups where available. It is assumed that openssh-server
is installed during installation.
@@ -32,17 +32,17 @@ An overview of the procedure is as follow:
For more information, see `“Adding an
ISO” <virtual_machines.html#adding-an-iso>`_.
-#. Create a VM Instance with this ISO.
+#. Create an Instance with this ISO.
For more information, see `“Creating
VMs” <virtual_machines.html#creating-vms>`_.
-#. Prepare the Linux VM
+#. Prepare the Linux Instance
-#. Create a template from the VM.
+#. Create a Template from the Instance.
For more information, see `“Creating a Template from an Existing
- Virtual Machine” <#creating-a-template-from-an-existing-virtual-machine>`_.
+ Instance” <#creating-a-template-from-an-existing-virtual-machine>`_.
System preparation for Linux
@@ -74,7 +74,7 @@ templating of Centos and Ubuntu.
#. **Networking**
- Set template network interface configuration to DHCP so Cloudstack infrastructure can assign one on boot.
+ Set Template Network interface configuration to DHCP so Cloudstack infrastructure can assign one on boot.
.. warning::
@@ -92,7 +92,7 @@ templating of Centos and Ubuntu.
#. **Hostname Management**
- Set a generic name to the template VM during installation, this will ensure components such as LVM do not appear unique to a machine. It is recommended that the name of "localhost" is used for installation.
+ Set a generic name to the Template Instance during installation, this will ensure components such as LVM do not appear unique to a machine. It is recommended that the name of "localhost" is used for installation.
.. code:: bash
@@ -103,10 +103,10 @@ templating of Centos and Ubuntu.
.. note::
- It is a good practice to remove any non root users that come with the OS (such as ones created during the Ubuntu
- installation). First ensure the root user account is enabled by giving it a password and then login as root to continue.
+ It is a good practice to remove any non root Users that come with the OS (such as ones created during the Ubuntu
+ installation). First ensure the root user Account is enabled by giving it a password and then login as root to continue.
- Once logged in as root, any custom user can be removed.
+ Once logged in as root, any custom User can be removed.
.. code:: bash
@@ -119,7 +119,7 @@ templating of Centos and Ubuntu.
#. **SSH keys management**
- Cloudstack can create key pair and push certificates to instances. This feature is available with:
+ Cloudstack can create key pair and push certificates to Instances. This feature is available with:
* `Cloud-init integration <_cloud_init.html#linux-with-cloud-init>`_
* `Implementing a SSH-Key bash script <http://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines.html#creating-an-instance-template-that-supports-ssh-keys>`_
@@ -131,7 +131,7 @@ templating of Centos and Ubuntu.
#. **User-data**
- Cloudstack can push user-data during instance creation.
+ Cloudstack can push user-data during Instance creation.
This feature is possible with `Cloud-init integration <_cloud_init.html#linux-with-cloud-init>`_.
#. **Template cleanup**
@@ -140,13 +140,13 @@ templating of Centos and Ubuntu.
Cleanup steps should be run when all Main Template configuration
is done and just before the shutdown step. After shut down Final
- template should be created. If the Main Template is started or
- rebooted before Final template creation all cleanup steps have to be rerun.
+ Template should be created. If the Main Template is started or
+ rebooted before Final Template creation all cleanup steps have to be rerun.
- **Remove the udev persistent device rules**
This step removes information unique to the Main Template such as
- network MAC addresses, lease files and CD block devices, the files
+ Network MAC addresses, lease files and CD block devices, the files
are automatically generated on next boot.
~ CentOS
@@ -165,7 +165,7 @@ templating of Centos and Ubuntu.
- **Remove SSH Keys**
- This step is to ensure all Templated VMs do not have the same
+ This step is to ensure all Templated Instances do not have the same
SSH keys, which would decrease the security of the machines
dramatically.
@@ -184,10 +184,10 @@ templating of Centos and Ubuntu.
logrotate -f /etc/logrotate.conf 2>/dev/null
rm -f /var/log/*-* /var/log/*.gz 2>/dev/null
- - **Set user password to expire**
+ - **Set User password to expire**
- This step forces the user to change the password of the VM after the
- template has been deployed.
+ This step forces the User to change the password of the Instance after the
+ Template has been deployed.
.. code:: bash
@@ -202,7 +202,7 @@ templating of Centos and Ubuntu.
history -c
unset HISTFILE
-#. **Shutdown the VM**
+#. **Shutdown the Instance**
Shutdown the Main Template.
@@ -210,7 +210,7 @@ templating of Centos and Ubuntu.
halt -p
-#. **Create the template!**
+#. **Create the Template!**
You are now ready to create the Final Template, for more information see
`“Creating a Template from an Existing Virtual
diff --git a/source/adminguide/templates/_create_windows.rst b/source/adminguide/templates/_create_windows.rst
index cb1d554..53adfe0 100644
--- a/source/adminguide/templates/_create_windows.rst
+++ b/source/adminguide/templates/_create_windows.rst
@@ -17,13 +17,13 @@
Creating a Windows Template
---------------------------
-Windows templates must be prepared with Sysprep before they can be
+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.
+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
+ (XenServer) Windows instances running on XenServer require PV drivers, which
+ may be provided in the Template or added after the instance is created. The
PV drivers are necessary for essential management functions such as
mounting additional volumes and ISO images, live migration, and
graceful shutdown.
@@ -35,17 +35,17 @@ An overview of the procedure is as follows:
For more information, see `“Adding an
ISO” <virtual_machines.html#adding-an-iso>`_.
-#. Create a VM Instance with this ISO.
+#. Create an instance with this ISO.
For more information, see `“Creating
- VMs” <virtual_machines.html#creating-vms>`_.
+ instances” <virtual_machines.html#creating-vms>`_.
#. 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.
+ Template as described in Creating the Windows Template.
System Preparation for Windows Server 2008 R2
@@ -68,8 +68,8 @@ Use the following steps to run sysprep for Windows 2008 R2:
#. 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
+ Windows AIK should not be installed on the Windows 2008 R2 instance 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
@@ -116,7 +116,7 @@ Use the following steps to run sysprep for Windows 2008 R2:
|software-license.png|
#. 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
+ can just enter the MAK key on the Windows 2008 R2 instance. 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
@@ -140,7 +140,7 @@ Use the following steps to run sysprep for Windows 2008 R2:
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
+ directory of the Windows 2008 R2 Instance
#. Once you place the unattend.xml file in
c:\\windows\\system32\\sysprep directory, you run the sysprep tool as
@@ -151,7 +151,7 @@ Use the following steps to run sysprep for Windows 2008 R2:
cd c:\Windows\System32\sysprep
sysprep.exe /oobe /generalize /shutdown
- The Windows 2008 R2 VM will automatically shut down after sysprep is
+ The Windows 2008 R2 instance will automatically shut down after sysprep is
complete.
@@ -163,7 +163,7 @@ 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.
+ 2003 R2 instance.
#. Run c:\\sysprep\\setupmgr.exe to create the sysprep.inf file.
diff --git a/source/adminguide/templates/_import_ami.rst b/source/adminguide/templates/_import_ami.rst
index b81829f..5f307d8 100644
--- a/source/adminguide/templates/_import_ami.rst
+++ b/source/adminguide/templates/_import_ami.rst
@@ -147,7 +147,7 @@ To import an AMI:
PermitRootLogin yes
PasswordAuthentication yes
-#. If you need the template to be enabled to reset passwords from the
+#. 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 :ref:`adding-password-management-to-templates`.
diff --git a/source/adminguide/templates/_password.rst b/source/adminguide/templates/_password.rst
index 1b39ae9..3378acb 100644
--- a/source/adminguide/templates/_password.rst
+++ b/source/adminguide/templates/_password.rst
@@ -24,20 +24,20 @@ 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.
+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
+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
+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
+If the script is unable to contact the virtual router during Instance
boot it will not set the password but boot will continue normally.
@@ -82,4 +82,4 @@ Windows OS Installation
Download the installer, CloudInstanceManager.msi, from the `Download
page <http://sourceforge.net/projects/cloudstack/files/Password%20Management%20Scripts/CloudInstanceManager.msi/download>`_
-and run the installer in the newly created Windows VM.
+and run the installer in the newly created Windows Instance.
diff --git a/source/adminguide/troubleshooting.rst b/source/adminguide/troubleshooting.rst
index f4c0efc..7bb889f 100644
--- a/source/adminguide/troubleshooting.rst
+++ b/source/adminguide/troubleshooting.rst
@@ -155,52 +155,52 @@ Solution
Use vCenter to place the host in maintenance mode.
-Unable to deploy VMs from uploaded vSphere template
----------------------------------------------------
+Unable to deploy Instances from uploaded vSphere Template
+---------------------------------------------------------
Symptom
~~~~~~~~
-When attempting to create a VM, the VM will not deploy.
+When attempting to create an Instance, it does not deploy.
Cause
~~~~~
-If the template was created by uploading an OVA file that was created
+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.
+it does, the deployment of Instances from the Template will fail.
Solution
~~~~~~~~
-Remove the ISO and re-upload the template.
+Remove the ISO and re-upload the Template.
-Unable to power on virtual machine on VMware
---------------------------------------------
+Unable to power on Instance on VMware
+-------------------------------------
Symptom
~~~~~~~
-Virtual machine does not power on. You might see errors like:
+Instance 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
+- Unable to access Instance 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.
+Instance files and file systems to prevent concurrent changes.
+Sometimes the files are not unlocked when the Instance is powered
+off. When an Instance attempts to power on, it can not access
+these critical files, and the Instance is unable to power on.
Solution
@@ -343,7 +343,7 @@ Trouble Shooting Steps
interfaces bridge. This virtual interface to physical interface mapping
is done automatically by CloudStack using the traffic label settings for
the Zone. If you have provided correct settings and still dont have a
- working working Internet, check the switching layer before you debug any
+ working Internet, check the switching layer before you debug any
further. You can verify traffic using tcpdump on the virtual, physical
and bridge interfaces.
@@ -383,7 +383,7 @@ Trouble Shooting Steps
#. The Internet would be accessible from both the SSVM and CPVM
- instances by default. Their public IPs will also be directly pingable
+ Instances by default. Their public IPs will also be directly pingable
from the Internet. Please note that these test would work only if your
switches and traffic labels are configured correctly for your
environment. If your SSVM/CPVM cant reach the Internet, its very
@@ -436,7 +436,7 @@ Trouble Shooting Steps
.. image:: /_static/images/networking-ingress-rule.png
-#. The VM Instances by default wont be able to access the Internet. Add
+#. The Instances by default won't be able to access the Internet. Add
Egress rules to permit traffic.
.. image:: /_static/images/networking-egress-rule.png
diff --git a/source/adminguide/tuning.rst b/source/adminguide/tuning.rst
index c5b0115..c1fb354 100644
--- a/source/adminguide/tuning.rst
+++ b/source/adminguide/tuning.rst
@@ -111,32 +111,32 @@ The value of 'database.server.stats.retention' can be changed to tweak
the number of values that are maintained.
-Set and Monitor Total VM Limits per Host
-----------------------------------------
+Set and Monitor Total Instance 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
+The CloudStack administrator should monitor the total number of
+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,
+hosts failing, which would increase the Instance load on the other hosts as
+the Instances are automatically redeployed. Consult the documentation for your
+chosen hypervisor to find the maximum permitted number of Instances 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
+default limit. Monitor the Instance activity in each cluster at all times.
+Keep the total number of Instances 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
+any given time, the total number of 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.
+this number of Instances, use the CloudStack UI to disable allocation of more
+Instances to the cluster.
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.
+This can enable XenServer to handle larger numbers of Instances.
We recommend 2940 MB of RAM for XenServer dom0. For instructions on how
to do this, see `Citrix Knowledgebase
Article <http://support.citrix.com/article/CTX126531>`_.The article
diff --git a/source/adminguide/ui.rst b/source/adminguide/ui.rst
index 0c6cfbc..2591af7 100644
--- a/source/adminguide/ui.rst
+++ b/source/adminguide/ui.rst
@@ -19,11 +19,11 @@ 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
+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 all modern popular browsers including Chrome, Firefox, Edge and
Safari. The UI uses API auto-discovery to discover APIs allowed for a logged-in
-user and creates navigation and views based on that, and requires the following:
+User and creates navigation and views based on that, and requires the following:
- API discovery (listApis) enabled for all roles that must use the UI
- Modern browsers that are `ES5-compliant <https://github.com/vuejs/vue#browser-compatibility>`_
@@ -38,19 +38,19 @@ 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.
+Username -> The User ID of your Account. The default username is admin.
-Password -> The password associated with the user ID. The password for
+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.
+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,
+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
+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
@@ -60,10 +60,10 @@ UI, see Logging In as the Root Administrator.
End User's UI Overview
~~~~~~~~~~~~~~~~~~~~~~
-The CloudStack UI helps users of cloud infrastructure to view and use
-their cloud resources, including virtual machines, templates and ISOs,
-data volumes and snapshots, guest networks, and IP addresses. If the
-user is a member or administrator of one or more CloudStack projects,
+The CloudStack UI helps Users of cloud infrastructure to view and use
+their cloud resources, including Instances, 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.
@@ -76,7 +76,7 @@ Root Administrator's UI Overview
:align: left
The CloudStack UI helps the CloudStack administrator provision, view,
-and manage the cloud infrastructure, domains, user accounts, projects,
+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
@@ -90,7 +90,7 @@ 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
+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
@@ -111,8 +111,8 @@ provision, view, and manage your cloud infrastructure.
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.
+ provide storage; a single machine running Instances 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
@@ -123,8 +123,8 @@ provision, view, and manage your cloud infrastructure.
deployment, or you are ready to start scaling up a trial cloud
that you set up earlier with the basic setup screens. In the
Administrator UI, you can start using the more powerful features
- of CloudStack, such as advanced VLAN networking, high
- availability, additional network elements such as load balancers
+ 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.
@@ -135,10 +135,10 @@ provision, view, and manage your cloud infrastructure.
chose experienced user, use the steps in :ref:`changing-root-password`.
.. warning::
- You are logging in as the root administrator. This account manages the
+ 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
+ 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.
@@ -149,9 +149,9 @@ 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
+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
+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.
@@ -163,12 +163,12 @@ new, unique value.
http://<management-server-ip-address>:8080/client
-#. Log in to the UI using the current root user ID and password. The
+#. 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 the admin Account name.
#. Click View Users.
@@ -288,7 +288,7 @@ Some assorted primary theme colours:
- Purple: #722ED1
The config.json also allows to configure a special-purpose card that shows on
-the account and project dashboards. This card is created using the `userCard`
+the Account and project dashboards. This card is created using the `userCard`
section that has a configurable title, icon and a list of configurable links
that have a title, text (description), link and icon.
@@ -580,11 +580,11 @@ The following features are no longer supported or available in the UI but are st
- Support for S3 based secondary storage.
- NFS secondary staging storage list/resource view and add/update actions.
-- SSL certificate for Guest network LB rule.
+- SSL certificate for Guest Network LB rule.
- Regions.
.. |change-password.png| image:: /_static/images/change-password.png
- :alt: button to change a user's password
+ :alt: button to change a User's password
.. |ui-custom-plugin.png| image:: /_static/images/ui-custom-plugin.png
:alt: Custom plugin shown in UI with navigation
diff --git a/source/adminguide/usage.rst b/source/adminguide/usage.rst
index 654faea..6467b7e 100644
--- a/source/adminguide/usage.rst
+++ b/source/adminguide/usage.rst
@@ -28,8 +28,8 @@ will use CloudStack resource UUIDs instead of internal database IDs. To get
description in the old format, an API parameter "oldformat" is introduced
which is false by default.
-The usage records show the amount of resources, such as VM run time or
-template storage space, consumed by guest instances.
+The usage records show the amount of resources, such as Instance 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.
@@ -99,8 +99,8 @@ 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,
+customer invoices. For example, this checks for Instance usage records created
+after the Instance 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.
@@ -167,7 +167,7 @@ Setting Usage Limits
--------------------
CloudStack provides several administrator control points for capping
-resource usage by users. Some of these limits are global configuration
+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.
@@ -175,9 +175,9 @@ on a per-account basis.
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
+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.
@@ -188,29 +188,29 @@ 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.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.snapshots | Number of Templates that can exist for an Account |
+---------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| max.account.templates | Number of templates 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.user.vms | Number of Instances that can exist for an Account |
+---------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| max.account.volumes | Number of disk volumes 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.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) |
+| 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.hourly | Maximum recurring hourly Templates to be retained for a volume. If the limit is reached, early Templates from the start of the hour are deleted so that newer ones can be saved. This limit does not apply to manual Templates. If set to 0, recurring hourly Templates 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.daily | Maximum recurring daily Templates to be retained for a volume. If the limit is reached, Templates from the start of the day are deleted so that newer ones can be saved. This limit does not apply to manual Templates. If set to 0, recurring daily Templates 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.weekly | Maximum recurring weekly Templates to be retained for a volume. If the limit is reached, Templates from the beginning of the week are deleted so that newer ones can be saved. This limit does not apply to manual Templates. If set to 0, recurring weekly Templates 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. |
+| snapshot.max.monthly | Maximum recurring monthly Templates to be retained for a volume. If the limit is reached, Templates from the beginning of the month are deleted so that newer ones can be saved. This limit does not apply to manual Templates. If set to 0, recurring monthly Templates can not be scheduled. |
+---------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
To modify global configuration parameters, use the global configuration
@@ -224,7 +224,7 @@ CloudStack allows you to control resource usage based on the types of
resources, such as CPU, RAM, Primary storage, and Secondary storage. A
new set of resource types has been added to the existing pool of
resources to support the new customization model—need-basis usage, such
-as large VM or small VM. The new resource types are now broadly
+as large Instance or small Instance. The new resource types are now broadly
classified as CPU, RAM, Primary storage, and Secondary storage. The root
administrator is able to impose resource usage limit by the following
resource types for Domain, Project, and Accounts.
@@ -245,21 +245,21 @@ parameters have been added:
=================================== =================================================================
Parameter Name Description
=================================== =================================================================
-max.account.cpus Maximum number of CPU cores that can be used for an account.
+max.account.cpus Maximum number of CPU cores that can be used for an Account.
Default is 40.
-max.account.ram (MB) Maximum RAM that can be used for an account.
+max.account.ram (MB) Maximum RAM that can be used for an Account.
Default is 40960.
-max.account.primary.storage (GB) Maximum primary storage space that can be used for an account.
+max.account.primary.storage (GB) Maximum primary storage space that can be used for an Account.
Default is 200.
-max.account.secondary.storage (GB) Maximum secondary storage space that can be used for an account.
+max.account.secondary.storage (GB) Maximum secondary storage space that can be used for an Account.
Default is 400.
-max.project.cpus Maximum number of CPU cores that can be used for an account.
+max.project.cpus Maximum number of CPU cores that can be used for an Account.
Default is 40.
-max.project.ram (MB) Maximum RAM that can be used for an account.
+max.project.ram (MB) Maximum RAM that can be used for an Account.
Default is 40960.
-max.project.primary.storage (GB) Maximum primary storage space that can be used for an account.
+max.project.primary.storage (GB) Maximum primary storage space that can be used for an Account.
Default is 200.
-max.project.secondary.storage (GB) Maximum secondary storage space that can be used for an account.
+max.project.secondary.storage (GB) Maximum secondary storage space that can be used for an Account.
Default is 400.
=================================== =================================================================
@@ -267,7 +267,7 @@ max.project.secondary.storage (GB) Maximum secondary storage space that can be
User Permission
~~~~~~~~~~~~~~~
-The root administrator, domain administrators and users are able to list
+The root administrator, domain administrators and Users are able to list
resources. Ensure that proper logs are maintained in the ``vmops.log``
and ``api.log`` files.
@@ -275,10 +275,10 @@ and ``api.log`` files.
limits.
- The domain administrators are allowed to list and change these
- resource limits only for the sub-domains and accounts under their own
+ resource limits only for the sub-domains and Accounts under their own
domain or the sub-domains.
-- The end users will the privilege to list resource limits. Use the
+- The end Users will the privilege to list resource limits. Use the
listResourceLimits API.
@@ -289,47 +289,47 @@ Limit Usage Considerations
volume and not the physical size— the actual consumed size on disk in
case of thin provisioning.
-- If the admin reduces the resource limit for an account and set it to
+- If the admin reduces the resource limit for an Account and set it to
less than the resources that are currently being consumed, the
- existing VMs/templates/volumes are not destroyed. Limits are imposed
- only if the user under that account tries to execute a new operation
+ existing Instances/Templates/Volumes are not destroyed. Limits are imposed
+ only if the User under that Account tries to execute a new operation
using any of these resources. For example, the existing behavior in
- the case of a VM are:
+ the case of an Instance are:
- - migrateVirtualMachine: The users under that account will be able
- to migrate the running VM into any other host without facing any
+ - migrateVirtualMachine: The Users under that Account will be able
+ to migrate the running Instance into any other host without facing any
limit issue.
- - recoverVirtualMachine: Destroyed VMs cannot be recovered.
+ - recoverVirtualMachine: Destroyed Instances cannot be recovered.
- For any resource type, if a domain has limit X, sub-domains or
accounts under that domain can have there own limits. However, the
- sum of resource allocated to a sub-domain or accounts under the
+ sum of resource allocated to a sub-domain or Accounts under the
domain at any point of time should not exceed the value X.
For example, if a domain has the CPU limit of 40 and the sub-domain
- D1 and account A1 can have limits of 30 each, but at any point of
+ D1 and Account A1 can have limits of 30 each, but at any point of
time the resource allocated to D1 and A1 should not exceed the limit
of 40.
- If any operation needs to pass through two of more resource limit
check, then the lower of 2 limits will be enforced, For example: if
- an account has the VM limit of 10 and CPU limit of 20, and a user
- under that account requests 5 VMs of 4 CPUs each. The user can deploy
- 5 more VMs because VM limit is 10. However, the user cannot deploy
- any more instances because the CPU limit has been exhausted.
+ an Account has the Instance limit of 10 and CPU limit of 20, and a User
+ under that Account requests 5 Instances of 4 CPUs each. The User can deploy
+ 5 more Instances because Instance limit is 10. However, the User cannot deploy
+ any more Instances because the CPU limit has been exhausted.
Limiting Resource Usage in a Domain
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CloudStack allows the configuration of limits on a domain basis. With a
-domain limit in place, all users still have their account limits. They
+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 the accounts in all the sub-domains of that
+set on their domain. Domain limits aggregate the usage of all Accounts
+in the domain as well as all the Accounts in all the sub-domains of that
domain. Limits set at the root domain level apply to the sum of resource
-usage by the accounts in all the domains and sub-domains below that root
+usage by the Accounts in all the domains and sub-domains below that root
domain.
To set a domain limit:
@@ -353,7 +353,7 @@ To set a domain limit:
- Instance Limits
- The number of instances that can be used in a domain.
+ The number of Instances that can be used in a domain.
- Public IP Limits
@@ -365,11 +365,11 @@ To set a domain limit:
- Snapshot Limits
- The number of snapshots that can be created in a domain.
+ The number of Templates that can be created in a domain.
- Template Limits
- The number of templates that can be registered in a domain.
+ The number of Templates that can be registered in a domain.
- VPC limits
@@ -397,19 +397,19 @@ To set a domain limit:
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
+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
+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
+#. Select the Account you want to modify. The current limits are
displayed.
A value of -1 shows that there is no limit in place.
@@ -424,61 +424,61 @@ resource limit.
- Instance Limits
- The number of instances that can be used in an account.
+ The number of Instances that can be used in an Account.
The default is 20.
- Public IP Limits
- The number of public IP addresses that can be used in an account.
+ The number of public IP addresses that can be used in an Account.
The default is 20.
- Volume Limits
- The number of disk volumes that can be created in an account.
+ The number of disk volumes that can be created in an Account.
The default is 20.
- Snapshot Limits
- The number of snapshots that can be created in an account.
+ The number of Templates that can be created in an Account.
The default is 20.
- Template Limits
- The number of templates that can be registered in an account.
+ The number of Templates that can be registered in an Account.
The default is 20.
- VPC limits
- The number of VPCs that can be created in an account.
+ The number of VPCs that can be created in an Account.
The default is 20.
- CPU limits
- The number of CPU cores that can be used for an account.
+ The number of CPU cores that can be used for an Account.
The default is 40.
- Memory limits (MB)
- The number of RAM that can be used for an account.
+ The number of RAM that can be used for an Account.
The default is 40960.
- Primary Storage limits (GB)
- The primary storage space that can be used for an account.
+ The primary storage space that can be used for an Account.
The default is 200.
- Secondary Storage limits (GB)
- The secondary storage space that can be used for an account.
+ The secondary storage space that can be used for an Account.
The default is 400.
@@ -488,40 +488,40 @@ resource limit.
Usage Record Format
-------------------
-Virtual Machine Usage Record Format
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Instance Usage Record Format
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-For running and allocated virtual machine usage, the following fields
+For running and allocated Instance usage, the following fields
exist in a usage record:
-- account – name of the account
+- account – name of the Account
-- accountid – ID of the account
+- accountid – ID of the Account
-- domainid – ID of the domain in which this account resides
+- 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)
+ usage (e.g. 'Hrs' for Instance 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
+- virtualMachineId – The ID of the Instance
-- name – The name of the virtual machine
+- name – The name of the Instance
- 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
+- 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
+- usageid – Instance
- type – Hypervisor
@@ -532,14 +532,14 @@ exist in a usage record:
Network Usage Record Format
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-For network usage (bytes sent/received), the following fields exist in a
+For Network usage (bytes sent/received), the following fields exist in a
usage record.
-- account – name of the account
+- account – name of the Account
-- accountid – ID of the account
+- accountid – ID of the Account
-- domainid – ID of the domain in which this account resides
+- domainid – ID of the domain in which this Account resides
- zoneid – Zone where the usage occurred
@@ -562,9 +562,9 @@ IP Address Usage Record Format
For IP address usage the following fields exist in a usage record.
-- account - name of the account
+- account - name of the Account
-- accountid - ID of the account
+- accountid - ID of the Account
- domainid - ID of the domain in which this account resides
@@ -617,7 +617,7 @@ For disk volumes, the following fields exist in a usage record.
- type – Hypervisor
-- templateid – ROOT template ID
+- templateid – ROOT Template ID
- size – The amount of storage allocated
@@ -645,14 +645,14 @@ Template, ISO, and Snapshot Usage Record Format
- rawusage – A number representing the actual usage in hours
-- usageid – The ID of the the template, ISO, or snapshot
+- usageid – The ID of the Template, ISO, or Template
- offeringid – The ID of the disk offering
-- templateid – – Included only for templates (usage type 7). Source
- template ID.
+- templateid – – Included only for Templates (usage type 7). Source
+ Template ID.
-- size – Size of the template, ISO, or snapshot
+- size – Size of the Template, ISO, or Template
- startdate, enddate – The range of time for which the usage is
aggregated; see Dates in the Usage Record
@@ -706,15 +706,15 @@ Network Offering Usage Record Format
- rawusage – A number representing the actual usage in hours
-- usageid – ID of the network offering
+- 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 Instance
-- virtualMachineId – The ID of the virtual machine
+- virtualMachineId – The ID of the Instance
- startdate, enddate – The range of time for which the usage is
aggregated; see Dates in the Usage Record
@@ -740,7 +740,7 @@ VPN User Usage Record Format
- rawusage – A number representing the actual usage in hours
-- usageid – VPN user ID
+- usageid – VPN User ID
- usagetype – A number representing the usage type (see Usage Types)
@@ -755,108 +755,108 @@ The following table shows all usage types.
.. cssclass:: table-striped table-bordered table-hover
-+------------------+-----------------------------------+-----------------------+
-| 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. |
-+------------------+-----------------------------------+-----------------------+
++------------------+-----------------------------------+-----------------------------+
+| Type ID | Type Name | Description |
++==================+===================================+=============================+
+| 1 | RUNNING\_VM | Tracks the total |
+| | | running time of an Instance |
+| | | per usage record |
+| | | period. If the Instance is |
+| | | upgraded during the |
+| | | usage period, you |
+| | | will get a separate |
+| | | Usage Record for the |
+| | | new upgraded Instance. |
++------------------+-----------------------------------+-----------------------------+
+| 2 | ALLOCATED\_VM | Tracks the total time |
+| | | the Instance 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 Instances for an |
+| | | account. Cloud.com |
+| | | does not currently |
+| | | track Network traffic |
+| | | per Instance. |
++------------------+-----------------------------------+-----------------------------+
+| 5 | NETWORK\_BYTES\_RECEIVED | Tracks the total |
+| | | number of bytes |
+| | | received by all the |
+| | | Instances for an account. |
+| | | Cloud.com does not |
+| | | currently track |
+| | | Network traffic per |
+| | | Instance. |
++------------------+-----------------------------------+-----------------------------+
+| 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 |
+| | | Template 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 Template |
+| | | 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 an Instance |
+| | | 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 an Instance |
+| | | until it is removed. |
++------------------+-----------------------------------+-----------------------------+
+| 14 | VPN\_USERS | The time from when a |
+| | | VPN User is created |
+| | | until it is removed. |
++------------------+-----------------------------------+-----------------------------+
Example response from listUsageRecords
@@ -900,32 +900,32 @@ 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
+exception; see below). An Instance 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).
+running Instance usage (usage type 1) and 12 hours of allocated Instance usage
+(usage type 2). If the same Instance runs for the entire next
+day, there will 24 hours of both running Instance usage (type 1) and allocated
+Instance 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
+Note: The start date is not the time an Instance was started, and
+the end date is not the time when an Instance 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
+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
+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
+IP addresses and Instances, the old unprocessed data is not included in daily
aggregation.
diff --git a/source/adminguide/veeam_plugin.rst b/source/adminguide/veeam_plugin.rst
index 14424fb..f0d2091 100644
--- a/source/adminguide/veeam_plugin.rst
+++ b/source/adminguide/veeam_plugin.rst
@@ -23,20 +23,20 @@ About the Veeam Backup and Recovery Plugin
There are a couple of important concepts to understand before working with the Veeam plugin.
-#. Backup Provider Offerings for the Veeam B&R plugin are template backup jobs.
+#. Backup Provider Offerings for the Veeam B&R plugin are Template backup jobs.
#. Veeams API does not allow for the creation of backup jobs. Therefore, a backup job must be created which will act
- as a template for all 'backups' which are based on it. You will need to create backup job templates for each of the
- Backup Offerings which you will be presenting to your users, be they a default template for ad-hoc/scheduled backups or
- 'SLA' specific templates (ie Gold offering). Refer to the general B&R for information regrading the B&R
+ as a Template for all 'backups' which are based on it. You will need to create backup job Templates for each of the
+ Backup Offerings which you will be presenting to your users, be they a default Template for ad-hoc/scheduled backups or
+ 'SLA' specific Templates (ie Gold offering). Refer to the general B&R for information regrading the B&R
job types.
-#. The backup job templates will be zone specific as they will contain the backup destination, and this will be different
- in each zone (unless you have extreamly fat links between zones).
+#. The backup job Templates will be zone specific as they will contain the backup destination, and this will be different
+ in each zone (unless you have extremely fat links between zones).
#. Veeam backup jobs are not allowed to be empty (i.e. they must backup something); therefore a dummy tag which
- is not assigned to any VM must be created via vCenter. The initial backup target of the backup job templates is
- then 'any VM with the dummy tag assigned' i.e. no VMs
+ is not assigned to any Instance must be created via vCenter. The initial backup target of the backup job Templates is
+ then 'any VM with the dummy tag assigned' i.e. no Instances
#. Veeam's API is not complete and therefore a mix of API commands and powershell commands (via SSH) are employed.
@@ -53,7 +53,7 @@ Windows Server 2019 (with desktop), although much of the development work was do
desktop).
The following steps give a minimal installation, they do not cover Veeam integrations with backup, storage or
-virtualisation hardware. A number of the steps below may already have been carried out if you are already using Veeam Backup
+virtualisation hardware. A number of the steps below may already have been carried out if you are already using Veeam Backup
and Replication, however please read the steps below carefully to ensure that your installation meet all requirements for
compatibility with the B&R Veeam plug-in.
@@ -77,7 +77,7 @@ but at a high level you need to have done the following;
Creating Template jobs
----------------------
-#. As noted above, a dummy VM tag is required in order to create template jobs which don't contain any VMs. This is done via vCenter
+#. As noted above, a dummy VM tag is required in order to create Template jobs which don't contain any Instances. This is done via vCenter
by navigating to the 'Tags and Custom Attributes' section, and first creating a category (if you dont already have a suitable one).
|BnR-DummyTagCategory.jpg|
@@ -86,25 +86,25 @@ Creating Template jobs
|BnR-CreateDummyTag.jpg|
-#. Now create the template job in Veeam Backup and Replication Manager. using the New Backup Job (Virtual Machine) wizard.
+#. Now create the Template job in Veeam Backup and Replication Manager. Using the New Backup Job (Instance) wizard.
#. Give the job a name that describes what the job does ie *template_job_zone1_default* or *template_daily_job-14_kept*
(the end user will not see this name).
- #. In the Virtual Machines section of the wizard, click 'Add' and select the 'VMs and Tags' filter (top right of the
+ #. In the Instances section of the wizard, click 'Add' and select the 'VMs and Tags' filter (top right of the
'Add Objects' dialog box). And then select your dummy tag and click on Add.
|BnR-VMsandTags.jpg|
#. In the Storage section is the correct Backup repository for the zone and number of restore points. (note there are a number
- of other advanaced options which can be set, these are transparent to CloudStack. CloudStack will clone this job 'as-is' including
- all advanced settings. However changing these settings will only effect NEW jobs created from the template, existing jobs will be
+ of other advanced options which can be set, these are transparent to CloudStack. CloudStack will clone this job 'as-is' including
+ all advanced settings. However changing these settings will only effect NEW jobs created from the Template, existing jobs will be
unchanged.
#. The same is true for the Guest Processing section.
- #. In the Schedule section you, if you are creating an 'SLA' based backup template, you would set the job to run automatically and
+ #. In the Schedule section you, if you are creating an 'SLA' based backup Template, you would set the job to run automatically and
select 'Periodically every' 24hrs and then in the 'Schedule' dialog set the hours in which the job is allowed to run. This allows
- Veeam to choose the best time to run the backup within a given window. If you are creating a template for adhoc/scheduled backups,
+ Veeam to choose the best time to run the backup within a given window. If you are creating a Template for adhoc/scheduled backups,
do not tick 'Run the job automatically' as CloudStack will trigger jobs as and when required.
|BnR-backupschedule.jpg|
@@ -115,7 +115,7 @@ Creating Template jobs
Connecting CloudStack to Veeam
-------------------------------
-Once Veeam is configured with SSH enabled and at least one template job, we can connect CloudStack to your Veeam server.
+Once Veeam is configured with SSH enabled and at least one Template job, we can connect CloudStack to your Veeam server.
To do this, you simply update the global settings listed below:
diff --git a/source/adminguide/virtual_machines.rst b/source/adminguide/virtual_machines.rst
index db57234..1c0c6ad 100644
--- a/source/adminguide/virtual_machines.rst
+++ b/source/adminguide/virtual_machines.rst
@@ -13,87 +13,87 @@
specific language governing permissions and limitations
under the License.
-About Working with Virtual Machines
-===================================
+About Working with Instances
+============================
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.
+lifecycle of all guest Instances executing in the cloud. CloudStack provides
+several guest management operations for end Users and administrators.
+Instances 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:
+Guest Instances have a name and group. Instance names and groups are opaque to
+CloudStack and are available for end Users to organize their Instances. Each
+Instance 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
+ 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.
+ 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
+- Name – host name that the DHCP server assigns to the Instance. Can be set
+ by the User. Defaults to Instance name
.. note::
- You can append the display name of a guest VM to its internal name.
- For more information, see `“Appending a Name to the Guest VM’s
+ You can append the display name of a guest Instance to its internal name.
+ For more information, see `“Appending a Name to the Guest Instance’s
Internal Name” <#appending-a-name-to-the-guest-vms-internal-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
+Guest Instances can be configured to be Highly Available (HA). An HA-enabled
+Instance is monitored by the system. If the system detects that the Instance is
+down, it will attempt to restart the Instance, possibly on a different host.
+For more information, see HA-Enabled Instances on
-Each new VM is allocated one public IP address. When the VM is started,
+Each new Instance is allocated one public IP address. When the Instance is started,
CloudStack automatically creates a static NAT between this public IP
-address and the private IP address of the VM.
+address and the private IP address of the Instance.
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
+address initially allocated to the new Instance 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
+IP and the guest Instance’s private IP. The Instance’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
+you can also decide not to allocate a public IP to an Instance in an
EIP-enabled Basic zone. For more information on Elastic IP, see
`“About Elastic IP” <networking/elastic_ips.html>`_.
-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
+CloudStack cannot distinguish a guest Instance that was shut down by the User
+(such as with the “shutdown” command in Linux) from an Instance that shut down
+unexpectedly. If an HA-enabled Instance is shut down from inside the Instance,
+CloudStack will restart it. To shut down an HA-enabled Instance, you must go
through the CloudStack UI or API.
.. note::
- **Monitor VMs for Max Capacity**
+ **Monitor Instances for Max Capacity**
- 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
+ The CloudStack administrator should monitor the total number of 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,
+ hosts failing, which would increase the Instance load on the other hosts as
+ the Instances are automatically redeployed. Consult the documentation for your
+ chosen hypervisor to find the maximum permitted number of Instances 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
+ default limit. Monitor the Instance activity in each cluster at all times.
+ Keep the total number of Instances 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
+ any given time, the total number of 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.
+ this number of Instances, use the CloudStack UI to disable allocation of more
+ Instances to the cluster.
-VM Lifecycle
-============
+Instance Lifecycle
+==================
-Virtual machines can be in the following states:
+Instances can be in the following states:
- Created
- Running
@@ -109,31 +109,31 @@ With the intermediate states of
- Expunging
-Creating VMs
-------------
+Creating Instances
+------------------
-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
+Instance are usually created from a Template. Users can also
+create blank Instances. A blank Instance is a virtual
+machine without an OS Template. Users can attach an ISO file and install
the OS from the CD/DVD-ROM.
.. note::
- 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,
+ You can create an Instance without starting it. You can determine whether the
+ Instance needs to be started as part of the Instance 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:
+To create an Instance from a Template:
-#. Log in to the CloudStack UI as an administrator or user.
+#. Log in to the CloudStack UI as an administrator or User.
#. In the left navigation bar, click Compute -> Instances.
#. Click the Add Instance button.
-#. Select a zone. Admin users will have the option to select a pod, cluster or host.
+#. Select a zone. Admin Users will have the option to select a pod, cluster or host.
-#. Select a template or ISO. For more information about how the templates came
+#. Select a Template or ISO. For more information about how the Templates came
to be in this list, see `*Working with Templates* <templates.html>`_.
#. Be sure that the hardware you have allows starting the selected
@@ -141,126 +141,126 @@ To create a VM from a template:
#. Select a disk offering.
-#. Select/Add a network.
+#. Select/Add a Network.
.. note::
- VMware only: If the selected template contains OVF properties, different deployment options or configurations,
+ VMware only: If the selected Template contains OVF properties, different deployment options or configurations,
multiple NICs or end-user license agreements, then the wizard will display these properties.
See `“Support for Virtual Appliances” <virtual_machines.html#support-for-virtual-appliances>`_.
-#. Click Launch Virtual Machine and your VM will be created and started.
+#. Click Launch Instance and your Instance will be created and started.
.. note::
- For security reason, the internal name of the VM is visible
+ For security reason, the internal name of the Instance is visible
only to the root admin.
.. note::
**XenServer**
- Windows VMs running on XenServer require PV drivers,
- which may be provided in the template or added after the VM is
+ Windows Instances running on XenServer require PV drivers,
+ which may be provided in the Template or added after the Instance is
created. The PV drivers are necessary for essential management
functions such as mounting additional volumes and ISO images,
live migration, and graceful shutdown.
**VMware**
- If the rootDiskController and dataDiskController are not specified for an instance using instance details and
- these are set to use osdefault in the template or the global configuration, then CloudStack tries to find the
+ If the rootDiskController and dataDiskController are not specified for an Instance using Instance details and
+ these are set to use osdefault in the Template or the global configuration, then CloudStack tries to find the
recommended disk controllers for it using guest OS from the hypervisor. In some specific cases, it may create
- issues with the instance deployment or start operation. To overcome this, a specific disk controller can be
- specified at the instance or template level. For an existing instance its settings can be updated while it is in
+ issues with the Instance deployment or start operation. To overcome this, a specific disk controller can be
+ specified at the Instance or Template level. For an existing Instance its settings can be updated while it is in
stopped state by admin.
Install Required Tools and Drivers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Be sure the following are installed on each VM:
+Be sure the following are installed on each Instance:
-- For XenServer, install PV drivers and Xen tools on each VM. This will
+- For XenServer, install PV drivers and Xen tools on each Instance. This will
enable live migration and clean guest shutdown. Xen tools are
required in order for dynamic CPU and RAM scaling to work.
-- For vSphere, install VMware Tools on each VM. This will enable
+- For vSphere, install VMware Tools on each Instance. This will enable
console view to work properly. VMware Tools are required in order for
dynamic CPU and RAM scaling to work.
To be sure that Xen tools or VMware Tools is installed, use one of the
following techniques:
-- Create each VM from a template that already has the tools installed;
+- Create each Instance from a Template that already has the tools installed;
or,
-- When registering a new template, the administrator or user can
- indicate whether tools are installed on the template. This can be
+- When registering a new Template, the Administrator or User can
+ indicate whether tools are installed on the Template. This can be
done through the UI or using the updateTemplate API; or,
-- If a user deploys a virtual machine with a template that does not
+- If a User deploys an Instance with a Template that does not
have Xen tools or VMware Tools, and later installs the tools on the
- VM, then the user can inform CloudStack using the
+ Instance, then the User can inform CloudStack using the
updateVirtualMachine API. After installing the tools and updating the
- virtual machine, stop and start the VM.
+ Instance, stop and start the Instance.
-Accessing VMs
--------------
+Accessing Instances
+-------------------
-Any user can access their own virtual machines. The administrator can
-access all VMs running in the cloud.
+Any User can access their own Instances. The administrator can
+access all Instances running in the cloud.
-To access a VM through the CloudStack UI:
+To access an Instance through the CloudStack UI:
-#. Log in to the CloudStack UI as a user or admin.
+#. Log in to the CloudStack UI as a User or admin.
-#. Click Compute -> Instances, then click the name of a running VM.
+#. Click Compute -> Instances, then click the name of a running Instance.
#. Click the View Console button |console-icon.png|.
-To access a VM directly over the network:
+To access an Instance 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
+#. The Instance must have some port open to incoming traffic. For example, in
+ a basic zone, a new Instance 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
+ picked when creating the Instance. In other cases, you can open a port by
setting up a port forwarding policy. See `“IP
Forwarding and Firewalling” <advanced_zone_config.html#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 a port is open but you can not access the Instance using ssh, it’s
+ possible that ssh is not already enabled on the Instance. This will depend
+ on whether ssh is enabled in the Template you picked when creating
+ the Instance. Access the Instance through the CloudStack UI and enable ssh on the
+ machine using the commands for the Instance’s operating system.
-#. If the network has an external firewall device, you will need to
+#. If the Network has an external firewall device, you will need to
create a firewall rule to allow access. See `“IP
Forwarding and Firewalling” <advanced_zone_config.html#ip-forwarding-and-firewalling>`_.
-Securing VM Console Access (KVM only)
--------------------------------------
+Securing Instance Console Access (KVM only)
+-------------------------------------------
CloudStack provides a way to secure VNC console access on KVM using the CA Framework certificates to enable TLS on VNC on each KVM host.
To enable TLS on a KVM host, navigate to the host and click on: Provision Host Security Keys (or invoke the provisionCertificate API for the host):
- When a new host is added and it is provisioned with a certificate, TLS will also be enabled for VNC
-- The running VMs on a secured host will continue to be VNC unencrypted unless they are stopped and started.
-- New VMs created on a secured host will be VNC encrypted.
+- The running Instances on a secured host will continue to be VNC unencrypted unless they are stopped and started.
+- New Instances created on a secured host will be VNC encrypted.
-Once the administrator concludes the certificates provisioning on Cloudstack, the VM console access for new VMs on the hosts will be encrypted. CloudStack displays the console of the virtual machines through the noVNC viewer embedded in the console proxy System VMs.
-The CloudStack users will notice the encrypted VNC sessions display a green bar stating the session is encrypted as in the image below. Also, the tab title includes ‘(TLS backend)’ when the session is encrypted.
+Once the administrator concludes the certificates provisioning on Cloudstack, the console access for new Instances on the hosts will be encrypted. CloudStack displays the console of the Instances through the noVNC viewer embedded in the console proxy System VMs.
+The CloudStack Users will notice the encrypted VNC sessions display a green bar stating the session is encrypted as in the image below. Also, the tab title includes ‘(TLS backend)’ when the session is encrypted.
.. note::
CloudStack will give access to the certificates to the group defined on the /etc/libvirt/qemu.conf file (or the last one defined on the file in case of multiple lines setting a group).
-Stopping and Starting VMs
--------------------------
+Stopping and Starting Instance
+-------------------------------
-Once a VM instance is created, you can stop, restart, or delete it as
-needed. In the CloudStack UI, click Instances, select the VM, and use
+Once an Instance is created, you can stop, restart, or delete it as
+needed. In the CloudStack UI, click Instances, select the Instance, and use
the Stop, Start, Reboot, and Destroy buttons.
A stop will attempt to gracefully shut down the operating system, via
@@ -270,48 +270,47 @@ be forcefully terminated. This has the same effect as pulling out the power
cord from a physical machine.
A reboot should not be considered as a stop followed by a start. In CloudStack,
-a start command reconfigures the virtual machine to the stored parameters in
+a start command reconfigures the Instance to the stored parameters in
CloudStack's database. The reboot process does not do this.
-When starting a VM, admin users have the option to specify a pod, cluster, or host.
+When starting an Instance, admin Users have the option to specify a pod, cluster, or host.
-Deleting VMs
--------------------------
+Deleting Instance
+------------------
-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.
+Users can delete their own Instance. A running Instance will be abruptly stopped
+before it is deleted. Administrators can delete any Instance.
-To delete a virtual machine:
+To delete an Instance:
-#. Log in to the CloudStack UI as a user or admin.
+#. Log in to the CloudStack UI as a User or admin.
#. In the left navigation, click Compute -> Instances.
-#. Choose the VM that you want to delete.
+#. Choose the Instance that you want to delete.
#. Click the Destroy Instance button. |Destroyinstance.png|
#. Optionally both expunging and the deletion of any attached volumes can be enabled.
-When a virtual machine is **destroyed**, it can no longer be seen by the end user,
+When an Instance is **destroyed**, it can no longer be seen by the end User,
however, it can be seen (and recovered) by a root admin. In this state it still
-consumes logical resources. Global settings control the maximum time from a VM
-being destroyed, to the physical disks being removed. When the VM and its root disk
-have been deleted, the VM is said to have been expunged.
+consumes logical resources. Global settings control the maximum time from an Instance
+being destroyed, to the physical disks being removed. When the Instance and its rooot disk
+have been deleted, the Instance is said to have been expunged.
-Once a virtual machine is **expunged**, 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.
+Once an Instance is **expunged**, it cannot be recovered. All the
+resources used by the Instance will be reclaimed by the system,
+This includes the Instance’s IP address.
-Managing Virtual Machines
-=========================
+Managing Instances
+==================
-Scheduling operations on a VM
+Scheduling operations on an Instance
-------------------------------------
-After a VM is created, you can schedule VM lifecycle operations using cron expressions. The operations that can be scheduled are:
+After an Instance is created, you can schedule Instance lifecycle operations using cron expressions. The operations that can be scheduled are:
- Start
- Stop
@@ -319,15 +318,15 @@ After a VM is created, you can schedule VM lifecycle operations using cron expre
- Force Stop
- Force Reboot
-To schedule an operation on a VM through the UI:
+To schedule an operation on an Instance through the UI:
-#. Log in to the CloudStack UI as a user or admin.
+#. Log in to the CloudStack UI as a User or admin.
#. In the left navigation, click Instances.
-#. Click the VM that you want to schedule the operation on.
+#. Click the Instance that you want to schedule the operation on.
-#. On the VM details page, click the **Schedule** button. |vm-schedule-tab.png|
+#. On the Instance details page, click the **Schedule** button. |vm-schedule-tab.png|
#. Click on **Add schedule** button to add a new schedule or click on Edit button |EditButton.png| to edit
an existing schedule. |vm-schedule-form.png|
@@ -357,48 +356,48 @@ To schedule an operation on a VM through the UI:
#. Click OK to save the schedule.
.. note::
- If multiple schedules are configured for a VM and the scheduled time coincides, then only the schedule which was created first
+ If multiple schedules are configured for an Instance and the scheduled time coincides, then only the schedule which was created first
will be executed and the rest will be skipped.
-Changing the VM Name, OS, or Group
--------------------------------------
+Changing the Instance Name, OS, or Group
+----------------------------------------
-After a VM is created, you can modify the display name, operating
+After an Instance is created, you can modify the display name, operating
system, and the group it belongs to.
-To access a VM through the CloudStack UI:
+To access an Instance through the CloudStack UI:
-#. Log in to the CloudStack UI as a user or admin.
+#. 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.
+#. Select the Instance that you want to modify.
-#. Click the Stop button to stop the VM. |StopButton.png|
+#. Click the Stop button to stop the Instance. |StopButton.png|
#. Click Edit. |EditButton.png|
#. Make the desired changes to the following:
#. **Display name**: Enter a new display name if you want to change the
- name of the VM.
+ name of the Instance.
#. **OS Type**: Select the desired operating system.
-#. **Group**: Enter the group name for the VM.
+#. **Group**: Enter the group name for the Instance.
#. Click Apply.
-Appending a Name to the Guest VM’s Internal Name
---------------------------------------------------
+Appending a Name to the Guest Instance’s Internal Name
+------------------------------------------------------
-Every guest VM has an internal name. The host uses the internal name to identify the guest VMs. CloudStack gives you an option to provide a guest VM with a name. You can set this name as the internal name so that the vCenter can use it to identify the guest VM. A new global parameter, vm.instancename.flag, has now been added to achieve this functionality.
+Every guest Instance has an internal name. The host uses the internal name to identify the guest Instances. CloudStack gives you an option to provide a guest Instance with a name. You can set this name as the internal name so that the vCenter can use it to identify the guest Instance. A new global parameter, vm.instancename.flag, has now been added to achieve this functionality.
-The default format of the internal name is i-<account\_id>-<vm\_id>-<i.n>, where i.n is the value of the global configuration - instance.name. However, If vm.instancename.flag is set to true, and if a name is provided during the creation of a guest VM, the name is appended to the internal name of the guest VM on the host. This makes the internal name format as i-<account\_id>-<vm\_id>-<name>. The default value of vm.instancename.flag is set to false. This feature is intended to make the [...]
+The default format of the internal name is i-<account\_id>-<vm\_id>-<i.n>, where i.n is the value of the global configuration - instance.name. However, If vm.instancename.flag is set to true, and if a name is provided during the creation of a guest Instance, the name is appended to the internal name of the guest Instance on the host. This makes the internal name format as i-<account\_id>-<vm\_id>-<name>. The default value of vm.instancename.flag is set to false. This feature is intended [...]
-The following table explains how a VM name is displayed in different scenarios.
+The following table explains how an Instance name is displayed in different scenarios.
.. cssclass:: table-striped table-bordered table-hover
@@ -416,48 +415,48 @@ The following table explains how a VM name is displayed in different scenarios.
<i.n> represents the value of the global configuration - instance.name
-Changing the Service Offering for a VM
-----------------------------------------
+Changing the Service Offering for an Instance
+---------------------------------------------
-To upgrade or downgrade the level of compute resources available to a
-virtual machine, you can change the VM's compute offering.
+To upgrade or downgrade the level of compute resources available to an
+Instance, you can change the Instance's compute offering.
-#. Log in to the CloudStack UI as a user or admin.
+#. 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.
+#. Choose the Instance that you want to work with.
-#. (Skip this step if you have enabled dynamic VM scaling; see
+#. (Skip this step if you have enabled dynamic Instance scaling; see
:ref:`cpu-and-memory-scaling`.)
- Click the Stop button to stop the VM. |StopButton.png|
+ Click the Stop button to stop the Instance. |StopButton.png|
#. Click the Change Service button. |ChangeServiceButton.png|
The Change service dialog box is displayed.
-#. Select the offering you want to apply to the selected VM.
+#. Select the offering you want to apply to the selected Instance.
#. Click OK.
.. _cpu-and-memory-scaling:
-CPU and Memory Scaling for Running VMs
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+CPU and Memory Scaling for Running Instances
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Supported on VMware and XenServer)
It is not always possible to accurately predict the CPU and RAM
-requirements when you first deploy a VM. You might need to increase
-these resources at any time during the life of a VM. You can dynamically
-modify CPU and RAM levels to scale up these resources for a running VM
+requirements when you first deploy an Instance. You might need to increase
+these resources at any time during the life of an Instance. You can dynamically
+modify CPU and RAM levels to scale up these resources for a running Instance
without incurring any downtime.
Dynamic CPU and RAM scaling can be used in the following cases:
-- User VMs on hosts running VMware and XenServer.
+- User Instances on hosts running VMware and XenServer.
- System VMs on VMware.
@@ -465,21 +464,21 @@ Dynamic CPU and RAM scaling can be used in the following cases:
machine.
- The new requested CPU and RAM values must be within the constraints
- allowed by the hypervisor and the VM operating system.
+ allowed by the hypervisor and the Instance operating system.
-- New VMs that are created after the installation of CloudStack 4.2 can
+- New Instances that are created after the installation of CloudStack 4.2 can
use the dynamic scaling feature. If you are upgrading from a previous
- version of CloudStack, your existing VMs created with previous
+ version of CloudStack, your existing Instances created with previous
versions will not have the dynamic scaling capability unless you
update them using the following procedure.
-Updating Existing VMs
-~~~~~~~~~~~~~~~~~~~~~
+Updating Existing Instances
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are upgrading from a previous version of CloudStack, and you want
-your existing VMs created with previous versions to have the dynamic
-scaling capability, update the VMs using the following steps:
+your existing Instances created with previous versions to have the dynamic
+scaling capability, update the Instances using the following steps:
#. Make sure the zone-level setting enable.dynamic.scale.vm is set to
true. In the left navigation bar of the CloudStack UI, click
@@ -487,9 +486,9 @@ scaling capability, update the VMs using the following steps:
the Settings tab.
#. Install Xen tools (for XenServer hosts) or VMware Tools (for VMware
- hosts) on each VM if they are not already installed.
+ hosts) on each Instance if they are not already installed.
-#. Stop the VM.
+#. Stop the Instance.
#. Click the Edit button.
@@ -497,7 +496,7 @@ scaling capability, update the VMs using the following steps:
#. Click Apply.
-#. Restart the VM.
+#. Restart the Instance.
Configuring Dynamic CPU and RAM Scaling
@@ -513,48 +512,48 @@ variables:
= 2.
Along with these global configurations, the following options need to be enabled
-to make a VM dynamically scalable
+to make an Instance dynamically scalable
-- Template from which VM is created needs to have Xen tools (for XenServer hosts)
+- Template from which Instance is created needs to have Xen tools (for XenServer hosts)
or VMware Tools (for VMware hosts) and it should have 'Dynamically Scalable'
flag set to true.
-- Service Offering of the VM should have 'Dynamic Scaling Enabled' flag set to true.
+- Service Offering of the Instance should have 'Dynamic Scaling Enabled' flag set to true.
By default, this flag is true when a Service Offering is created.
-- While deploying a VM, User or Admin needs to mark 'Dynamic Scaling Enabled' to true.
+- While deploying an Instance, User or Admin needs to mark 'Dynamic Scaling Enabled' to true.
By default this flag is set to true.
-If any of the above settings are false then VM cannot be configured as dynamically scalable.
+If any of the above settings are false then the Instance cannot be configured as dynamically scalable.
How to Dynamically Scale CPU and RAM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To modify the CPU and/or RAM capacity of a virtual machine, you need to
-change the compute offering of the VM to a new compute offering that has
+To modify the CPU and/or RAM capacity of an Instance, you need to
+change the compute offering of the Instance to a new compute offering that has
the desired CPU value and RAM value and 'Dynamic Scaling Enabled' flag as true.
-You can use the same steps described above in `“Changing the Service Offering for a
-VM” <#changing-the-service-offering-for-a-vm>`_, but skip the step where you
-stop the virtual machine. Of course, you might have to create a new
+You can use the same steps described above in `“Changing the Service Offering for an
+Instance” <#changing-the-service-offering-for-a-vm>`_, but skip the step where you
+stop the Instance. Of course, you might have to create a new
compute offering first.
When you submit a dynamic scaling request, the resources will be scaled
up on the current host if possible. If the host does not have enough
-resources, the VM will be live migrated to another host in the same
+resources, the Instance will be live migrated to another host in the same
cluster. If there is no host in the cluster that can fulfill the
-requested level of CPU and RAM, the scaling operation will fail. The VM
+requested level of CPU and RAM, the scaling operation will fail. The Instance
will continue to run as it was before.
Limitations
~~~~~~~~~~~
-- You can not do dynamic scaling for system VMs on XenServer.
+- You can not do dynamic scaling for system Instances on XenServer.
- CloudStack will not check to be sure that the new CPU and RAM levels
- are compatible with the OS running on the VM.
+ are compatible with the OS running on the Instance.
-- When scaling memory or CPU for a Linux VM on VMware, you might need
+- When scaling memory or CPU for a Linux Instance on VMware, you might need
to run scripts in addition to the other steps mentioned above. For
more information, see `Hot adding memory in Linux
(1012764) <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012764>`_
@@ -566,88 +565,88 @@ Limitations
information, see
`https://issues.apache.org/jira/browse/CLOUDSTACK-1809 <https://issues.apache.org/jira/browse/CLOUDSTACK-1809>`_.
-- On VMs running Linux 64-bit and Windows 7 32-bit operating systems,
- if the VM is initially assigned a RAM of less than 3 GB, it can be
+- On Instances running Linux 64-bit and Windows 7 32-bit operating systems,
+ if the Instance is initially assigned a RAM of less than 3 GB, it can be
dynamically scaled up to 3 GB, but not more. This is due to a known
issue with these operating systems, which will freeze if an attempt
is made to dynamically scale from less than 3 GB to more than 3 GB.
-- On KVM, not all versions of Qemu/KVM may support dynamic scaling. Some combinations may result CPU or memory related failures during instance deployment.
+- On KVM, not all versions of Qemu/KVM may support dynamic scaling. Some combinations may result CPU or memory related failures during Instance deployment.
-Resetting the Virtual Machine Root Volume on Reboot
----------------------------------------------------
+Resetting the Instance Root Volume on Reboot
+--------------------------------------------
-For secure environments, and to ensure that VM state is not persisted
+For secure environments, and to ensure that Instance state is not persisted
across reboots, you can reset the root disk. For more information, see
-`“Reset VM to New Root Disk on
+`“Reset Instance to New Root Disk on
Reboot” <storage.html#reset-vm-to-new-root-disk-on-reboot>`_.
-Moving VMs Between Hosts (Manual Live Migration)
-------------------------------------------------
+Moving Instances Between Hosts (Manual Live Migration)
+------------------------------------------------------
-The CloudStack administrator can move a running VM from one host to
-another without interrupting service to users or going into maintenance
+The CloudStack administrator can move a running Instance 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 root administrator is logged in. Domain admins and Users can not
+ perform manual live migration of Instances.
-- The VM is running. Stopped VMs can not be live migrated.
+- The Instance is running. Stopped Instances can not be live migrated.
- The destination host must have enough available capacity. If not, the
- VM will remain in the "migrating" state until memory becomes
+ Instance will remain in the "migrating" state until memory becomes
available.
-- (KVM) The VM must not be using local disk storage. (On XenServer and
- VMware, VM live migration with local disk is enabled by CloudStack
+- (KVM) The Instance must not be using local disk storage. (On XenServer and
+ VMware, Instance live migration with local disk is enabled by CloudStack
support for XenMotion and vMotion.)
- (KVM) The destination host must be in the same cluster as the
- original host. (On XenServer and VMware, VM live migration from one
+ original host. (On XenServer and VMware, Instance live migration from one
cluster to another is enabled by CloudStack support for XenMotion and
vMotion.)
-To manually live migrate a virtual machine
+To manually live migrate an Instance
#. Log in to the CloudStack UI as root administrator.
#. In the left navigation, click Instances.
-#. Choose the VM that you want to migrate.
+#. Choose the Instance that you want to migrate.
#. Click the Migrate Instance button. |Migrateinstance.png|
#. From the list of suitable hosts, choose the one to which you want to
- move the VM.
+ move the Instance.
.. note::
- If the VM's storage has to be migrated along with the VM, this will
+ If the Instance's storage has to be migrated along with the Instance, this will
be noted in the host list. CloudStack will take care of the storage
migration for you.
#. Click OK.
.. note::
- (KVM) If the VM's storage has to be migrated along with the VM, from a mounted NFS storage pool to a cluster-wide mounted NFS storage pool, then the 'migrateVirtualMachineWithVolume' API has to be used. There is no UI integration for this feature.
+ (KVM) If the Instance's storage has to be migrated along with the Instance, from a mounted NFS storage pool to a cluster-wide mounted NFS storage pool, then the 'migrateVirtualMachineWithVolume' API has to be used. There is no UI integration for this feature.
(CloudMonkey) > migrate virtualmachinewithvolume virtualmachineid=<virtual machine uuid> hostid=<destination host uuid> migrateto[i].volume=<virtual machine volume number i uuid> migrateto[i].pool=<destination storage pool uuid for volume number i>
- where i in [0,..,N] and N = number of volumes of the virtual machine
+ where i in [0,..,N] and N = number of volumes of the Instance
Moving Instance's Volumes Between Storage Pools (offline volume Migration)
---------------------------------------------------------------------
+--------------------------------------------------------------------------
-The CloudStack administrator can move a stopped instance's volumes from one
+The CloudStack administrator can move a stopped Instance's volumes from one
storage pool to another within the cluster. This is called offline volume
migration, and can be done under the following conditions:
-- The root administrator is logged in. Domain admins and users can not
- perform offline volume migration of instances.
+- The root administrator is logged in. Domain admins and Users can not
+ perform offline volume migration of Instances.
-- The instance is stopped.
+- The Instance is stopped.
- The destination storage pool must have enough available capacity.
@@ -657,38 +656,38 @@ migration, and can be done under the following conditions:
'migrateto' map parameter.
-To perform stopped instance's volumes migration
+To perform stopped Instance's volumes migration
... 6106 lines suppressed ...