You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by pa...@apache.org on 2019/07/17 10:27:16 UTC
[cloudstack-documentation] branch master updated: Constrained
custom offerings update for 4.13 (#53)
This is an automated email from the ASF dual-hosted git repository.
paul_a pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/cloudstack-documentation.git
The following commit(s) were added to refs/heads/master by this push:
new f69d28b Constrained custom offerings update for 4.13 (#53)
f69d28b is described below
commit f69d28b1f00b8d6f144eae3517e73f1677fec70a
Author: Paul Angus <pa...@shapeblue.com>
AuthorDate: Wed Jul 17 11:27:12 2019 +0100
Constrained custom offerings update for 4.13 (#53)
* modify files for 4.13 upgrade docs
* update disk offerings and 'updating offerings' text
* update compute offering text
---
.../images/compute_offering_dialog-multidomain.png | Bin 0 -> 65598 bytes
source/_static/images/compute_offering_dialog.png | Bin 0 -> 113614 bytes
.../images/update-service-offering-button.jpg | Bin 0 -> 13590 bytes
source/_static/theme_overrides.css | 4 +
source/adminguide/service_offerings.rst | 259 ++++++++++++---------
source/conf.py | 1 +
source/upgrading/index.rst | 1 +
source/upgrading/upgrade/upgrade-4.10.rst | 1 +
.../upgrade/{upgrade-4.10.rst => upgrade-4.12.rst} | 125 +++-------
source/upgrading/upgrade/upgrade-4.7.rst | 6 +-
source/upgrading/upgrade/upgrade-4.8.rst | 1 -
11 files changed, 184 insertions(+), 214 deletions(-)
diff --git a/source/_static/images/compute_offering_dialog-multidomain.png b/source/_static/images/compute_offering_dialog-multidomain.png
new file mode 100644
index 0000000..883b543
Binary files /dev/null and b/source/_static/images/compute_offering_dialog-multidomain.png differ
diff --git a/source/_static/images/compute_offering_dialog.png b/source/_static/images/compute_offering_dialog.png
new file mode 100644
index 0000000..210cb8d
Binary files /dev/null and b/source/_static/images/compute_offering_dialog.png differ
diff --git a/source/_static/images/update-service-offering-button.jpg b/source/_static/images/update-service-offering-button.jpg
new file mode 100644
index 0000000..e282a04
Binary files /dev/null and b/source/_static/images/update-service-offering-button.jpg differ
diff --git a/source/_static/theme_overrides.css b/source/_static/theme_overrides.css
index f5c5a5e..6e50835 100644
--- a/source/_static/theme_overrides.css
+++ b/source/_static/theme_overrides.css
@@ -11,6 +11,10 @@
overflow: visible;
}
+.rst-content li {
+ padding-top: 4px;
+}
+
/*
div[class^="highlight"] pre {
font-size:10px
diff --git a/source/adminguide/service_offerings.rst b/source/adminguide/service_offerings.rst
index 01bb76e..29975c7 100644
--- a/source/adminguide/service_offerings.rst
+++ b/source/adminguide/service_offerings.rst
@@ -13,6 +13,11 @@
specific language governing permissions and limitations
under the License.
+.. |update-service-offering-button.jpg| image:: /_static/images/update-service-offering-button.jpg
+ :alt: Update offering access button
+
+.. |edit-icon.png| image:: /_static/images/edit-icon.png
+ :alt: edit offering button
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
@@ -69,14 +74,20 @@ available offerings when they create a new VM. Based on the user’s
selected offering, CloudStack emits usage records that can be integrated
with billing systems.
-Some characteristics of service offerings must be defined by the CloudStack
-administrator, and others can be left undefined so that the end-user can
-enter their own desired values. This is useful to reduce 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
+Compute offerings may be "fixed", "custom constrained" or "custom unconstrained".
+
+In fixed offering the Number of CPUs, Memory and CPU frequecy 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
+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
+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 VM configurations.
A service offering includes the following elements:
@@ -113,33 +124,9 @@ The disk offering specifies:
- Tags on the data disk
-Custom Compute Offering
-~~~~~~~~~~~~~~~~~~~~~~~
-
-CloudStack provides you the flexibility to specify the desired values for
-the number of CPU, CPU speed, and memory while deploying a VM. As an
-admin, you create a Compute Offering by marking it as custom, and the
-users will be able to customize this dynamic Compute Offering by
-specifying the memory, and CPU at the time of VM creation or upgrade.
-Custom Compute Offering is same as the normal Compute Offering except
-that the values of the dynamic parameters will be set to zeros in the
-given set of templates. Use this offering to deploy VM by specifying
-custom values for the dynamic parameters. Memory, CPU and number of CPUs
-are considered as dynamic parameters.
-
-Dynamic Compute Offerings can be used in following cases: deploying a
-VM, changing the compute offering of a stopped VM and running VMs, which
-is nothing but scaling up. To support this feature a new field, Custom,
-has been added to the Create Compute Offering page. If the Custom field
-is checked, the user will be able to create a custom Compute Offering by
-filling in the desired values for number of CPU, CPU speed, and memory.
-See ? for more information on this.
-
-*Recording Usage Events for Dynamically Assigned Resources*.
-
-To support this feature, usage events has been enhanced to register
-events for dynamically assigned resources. Usage events are registered
-when a VM is created from a custom compute offering, and upon changing
+To support the custom offerings, usage events register events for dynamically
+assigned resources. Usage events are registered when a VM is created
+from a custom compute offering, and upon changing
the compute offering of a stopped or running VM. The values of the
parameters, such as CPU, speed, RAM are recorded.
@@ -147,6 +134,13 @@ parameters, such as CPU, speed, RAM are recorded.
Creating a New Compute Offering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. image:: /_static/images/compute_offering_dialog.png
+ :width: 400px
+ :align: center
+ :alt: Compute offering dialog box
+
+
+
To create a new compute offering:
#. Log in with admin privileges to the CloudStack UI.
@@ -169,65 +163,76 @@ To create a new compute offering:
system VM is running. Shared allocates from storage accessible via
NFS.
- - **Custom**: Custom compute offerings can be used in following
- cases: deploying a VM, changing the compute offering of a stopped
- VM and running VMs, which is nothing but scaling up.
-
- If the Custom field is checked, the end-user must fill in the
- desired values for number of CPU, CPU speed, and RAM Memory when
- using a custom compute offering. When you check this box, those
- three input fields are hidden in the dialog box.
-
+ - **Provisioning type**: The type of disk that should be allocated.
+ Local
+
+ - **Compute Offering Type**: The amount of freedom that the end user
+ 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,
+ Custom unconstrained - user can set any values that they wish
+ 'Custom constrained' is recommended over 'Custom unconstrained' as
+ it enables the admin to set some boundaries.
+
- **# of CPU cores**: The number of cores which should be allocated
- to a system VM with this offering. If Custom is checked, this
- field does not appear.
-
- - **CPU (in MHz)**: The CPU speed of the cores that the system VM is
- allocated. For example, “2000” would provide for a 2 GHz clock. If
- Custom is checked, this field does not appear.
+ 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.
+
+ - **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
+ 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.
- **Memory (in MB)**: The amount of memory in megabytes that the
system VM should be allocated. For example, “2048” would provide
- for a 2 GB RAM allocation. If Custom is checked, this field does
- not appear.
+ 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.
- **Network Rate**: Allowed data transfer rate in MB per second.
- - **Disk Read Rate**: Allowed disk read rate in bits per second.
+ - **Disk Read Rate** [1]_: Allowed disk read rate in bits per second.
- - **Disk Write Rate**: Allowed disk write rate in bits per second.
+ - **Disk Write Rate** [1]_: Allowed disk write rate in bits per second.
- - **Disk Read Rate**: Allowed disk read rate in IOPS (input/output
+ - **Disk Read Rate** [1]_: Allowed disk read rate in IOPS (input/output
operations per second).
- - **Disk Write Rate**: Allowed disk write rate in IOPS (input/output
+ - **Disk Write Rate** [1]_: Allowed disk write rate in IOPS (input/output
operations per second).
- **Offer HA**: If yes, the administrator can choose to have the
system VM be monitored and as highly available as possible.
- - **QoS Type**: Three options: Empty (no Quality of Service), hypervisor
+ - **QoS Type** [1]_: Three options: Empty (no Quality of Service), hypervisor
(rate limiting enforced on the hypervisor side), and storage
(guaranteed minimum and maximum IOPS enforced on the storage
side). If leveraging QoS, make sure that the hypervisor or storage
system supports this feature.
- - **Custom IOPS**: If checked, the user can set their own IOPS. If not
+ - **Custom IOPS** [1]_: If checked, the user can set their own IOPS. If not
checked, the root administrator can define values. If the root
admin does not set values when using storage QoS, default values
are used (the defauls can be overridden if the proper parameters
are passed into CloudStack when creating the primary storage in
question).
- - **Min IOPS**: Appears only if storage QoS is to be used. Set a
+ - **Min IOPS** [1]_: Appears only if storage QoS is to be used. Set a
guaranteed minimum number of IOPS to be enforced on the storage
side.
- - **Max IOPS**: Appears only if storage QoS is to be used. Set a maximum
+ - **Max IOPS** [1]_: Appears only if storage QoS is to be used. Set a maximum
number of IOPS to be enforced on the storage side (the system may
go above this limit in certain circumstances for short intervals).
- - **Hypervisor Snapshot Reserve**: For managed storage only. This is
+ - **Hypervisor Snapshot Reserve** [1]_: For managed storage only. This is
a value that is a percentage of the size of the root disk. For example:
if the root disk is 20 GB and Hypervisor Snapshot Reserve is 200%, the
storage volume that backs the storage repository (XenServer) or
@@ -244,10 +249,10 @@ To create a new compute offering:
- **CPU cap**: Whether to limit the level of CPU usage even if spare
capacity is available.
- - **Public**: Indicate whether the service offering should be
- available all domains or only some domains. Choose Yes to make it
- available to all domains. Choose No to limit the scope to a
- subdomain; CloudStack will then prompt for the subdomain's name.
+ - **Public**: Indicate whether the compute offering should be
+ available to all domains or only some domains. Choose Yes to make it
+ available to all domains. Choose No to limit the scope to one or more
+ specific domains.
- **isVolatile**: If checked, VMs created from this service offering
will have their root disks reset upon reboot. This is useful for
@@ -258,43 +263,40 @@ To create a new compute offering:
CloudStack to use when deploying VMs 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 VMs on the first host that is found having
+ sufficient capacity to support the VM's requirements.
- User Dispersing makes the best effort to evenly distribute VMs
- belonging to the same account on different clusters or pods.
+ - **User Dispersing**: makes the best effort to evenly distribute VMs
+ belonging to the same account on different clusters or pods.
- User Concentrated prefers to deploy VMs belonging to the same
- account within a single pod.
+ - **User Concentrated**: prefers to deploy VMs belonging to the same
+ account within a single pod.
- Implicit Dedication will deploy VMs 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>`_.
+ - **Implicit Dedication**: will deploy VMs 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>`_.
- Bare Metal is used with bare metal hosts. See Bare Metal
- Installation in the Installation Guide.
+ - **Bare Metal**: is used with bare metal hosts. See Bare Metal
+ Installation in the Installation Guide.
- **Planner Mode**: Used when ImplicitDedicationPlanner is selected
in the previous field. The planner mode determines how VMs will be
deployed on private infrastructure that is dedicated to a single
domain or account.
- Strict: A host will not be shared across multiple accounts. For
- example, strict implicit dedication is useful for deployment of
- certain types of applications, such as desktops, where no host can
- be shared between different accounts without violating the desktop
- software's terms of license.
+ - Strict: A host will not be shared across multiple accounts. For
+ example, strict implicit dedication is useful for deployment of
+ certain types of applications, such as desktops, where no host can
+ be shared between different accounts without violating the desktop
+ software's terms of license.
- Preferred: The VM will be deployed in dedicated infrastructure if
- possible. Otherwise, the VM can be deployed in shared
- infrastructure.
-
- - **GPU**: Assign a physical GPU(GPU-passthrough) or a portion of a physicalGPU
- GPU card(vGPU) to the guest VM. It allows graphical applications to run on the VM.
- Select the card from the supported list of cards.
+ - Preferred: The VM will be deployed in dedicated infrastructure if
+ possible. Otherwise, the VM 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.
+ 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
@@ -304,16 +306,30 @@ To create a new compute offering:
- **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.
-
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.
In this case, a physical GPU device is exclusively allotted to a single
guest VM.
+ - **Domain**: This is only visible When 'Public' is unchecked. When visible, this
+ controls the domains which will be able to use this compute offering. A multi-selection
+ list box will be displayed. One or more domains can be selected from
+ this list box by holding down the control key and clicking on the desired domains.
+
+ - **Zone**: This controls which zones a compute offering is available in. 'All zones' or
+ only specific zones can be selected. One or more zones can be selected from
+ this list box by holding down the control key and clicking on the desired zones.
+
#. Click Add.
+
+.. [1] These options are dependant on the capabilities of the hypervisor or the shared storage system which the VMs are on.
+ If the hypervisor or underlying storage don't support a particular capability in the offering, the setting will have no effect.
+
+
+
Creating a New Disk Offering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -341,28 +357,28 @@ To create a new disk offering:
- **Disk Size**: Appears only if Custom Disk Size is not selected.
Define the volume size in GB (2^30 1GB = 1,073,741,824 Bytes).
- - **QoS Type**: Three options: Empty (no Quality of Service), hypervisor
+ - **QoS Type** [2]_: Three options: Empty (no Quality of Service), hypervisor
(rate limiting enforced on the hypervisor side), and storage
(guaranteed minimum and maximum IOPS enforced on the storage
side). If leveraging QoS, make sure that the hypervisor or storage
system supports this feature.
- - **Custom IOPS**: If checked, the user can set their own IOPS. If not
+ - **Custom IOPS** [2]_: If checked, the user can set their own IOPS. If not
checked, the root administrator can define values. If the root
admin does not set values when using storage QoS, default values
are used (the defauls can be overridden if the proper parameters
are passed into CloudStack when creating the primary storage in
question).
- - **Min IOPS**: Appears only if storage QoS is to be used. Set a
+ - **Min IOPS** [2]_: Appears only if storage QoS is to be used. Set a
guaranteed minimum number of IOPS to be enforced on the storage
side.
- - **Max IOPS**: Appears only if storage QoS is to be used. Set a maximum
+ - **Max IOPS** [2]_: Appears only if storage QoS is to be used. Set a maximum
number of IOPS to be enforced on the storage side (the system may
go above this limit in certain circumstances for short intervals).
- - **Hypervisor Snapshot Reserve**: For managed storage only. This is
+ - **Hypervisor Snapshot Reserve** [2]_: For managed storage only. This is
a value that is a percentage of the size of the data disk. For example:
if the data disk is 20 GB and Hypervisor Snapshot Reserve is 200%, the
storage volume that backs the storage repository (XenServer) or
@@ -379,19 +395,35 @@ To create a new disk offering:
Storage for the volume to be provisioned. If no such primary
storage exists, allocation from the disk offering will fail..
- - **Public**: Indicate whether the service offering should be available
- all domains or only some domains. Choose Yes to make it available
- to all domains. Choose No to limit the scope to a subdomain;
- CloudStack will then prompt for the subdomain's name.
+ - **Public**: Indicates whether the disk offering should be
+ available to all domains or only some domains. Choose Yes to make it
+ available to all domains. Choose No to limit the scope to one or more
+ specific domains.
+
+ - **Domain**: This is only visible When 'Public' is unchecked. When visible, this
+ controls the domains which will be able to use this compute offering. A multi-selection
+ list box will be displayed. One or more domains can be selected from
+ this list box by holding down the control key and selecting the desired domains.
+
+ - **Zone**: This controls which zones a disk offering is available in. 'All zones' or
+ only specific zones can be selected. One or more zones can be selected from
+ this list box by holding down the control key and selecting the desired zones.
#. Click Add.
+.. [2] These options are dependant on the capabilities of the hypervisor or the shared storage system which the VMs are on.
+ If the hypervisor or underlying storage don't support a particular capability in the offering, the setting will have no effect.
+
Modifying or Deleting a Service Offering
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Service offerings cannot be changed once created. This applies to both
-compute offerings and disk offerings.
+Service offerings cannot be materially changed once created. This applies to
+both compute offerings and disk offerings. However their name, description
+and scope can be modified. To edit the name or description navigate to the
+service offering's detail page and click on the edit icon |edit-icon.png|.
+To alter the scope (zones and domains) that an offering is available in
+click on the update offering access button |update-service-offering-button.jpg|.
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
@@ -436,43 +468,43 @@ To create a system service offering:
#. In the dialog, make the following choices:
- - Name. Any desired name for the system offering.
+ - **Name**: Any desired name for the system offering.
- - Description. A short description of the offering that can be
+ - **Description**: A short description of the offering that can be
displayed to users
- - System VM Type. Select the type of system virtual machine that
+ - **System VM Type**: Select the type of system virtual machine that
this offering is intended to support.
- - Storage type. The type of disk that should be allocated. Local
+ - **Storage type**: The type of disk that should be allocated. Local
allocates from storage attached directly to the host where the
system VM is running. Shared allocates from storage accessible via
NFS.
- - # of CPU cores. The number of cores which should be allocated to a
+ - **# of CPU cores**: The number of cores which should be allocated to a
system VM with this offering
- - CPU (in MHz). The CPU speed of the cores that the system VM is
+ - **CPU (in MHz)**: The CPU speed of the cores that the system VM is
allocated. For example, "2000" would provide for a 2 GHz clock.
- - Memory (in MB). The amount of memory in megabytes that the system
+ - **Memory (in MB)**: The amount of memory in megabytes that the system
VM should be allocated. For example, "2048" would provide for a 2
GB RAM allocation.
- - Network Rate. Allowed data transfer rate in MB per second.
+ - **Network Rate**: Allowed data transfer rate in MB per second.
- - Offer HA. If yes, the administrator can choose to have the system
+ - **Offer HA**: If yes, the administrator can choose to have the system
VM be monitored and as highly available as possible.
- - Storage Tags. The tags that should be associated with the primary
+ - **Storage Tags**: The tags that should be associated with the primary
storage used by the system VM.
- - Host Tags. (Optional) Any tags that you use to organize your hosts
+ - **Host Tags**: (Optional) Any tags that you use to organize your hosts
- - CPU cap. Whether to limit the level of CPU usage even if spare
+ - **CPU cap**: Whether to limit the level of CPU usage even if spare
capacity is available.
- - Public. Indicate whether the service offering should be available
+ - **Public**: Indicate whether the service offering should be available
all domains or only some domains. Choose Yes to make it available
to all domains. Choose No to limit the scope to a subdomain;
CloudStack will then prompt for the subdomain's name.
@@ -571,7 +603,6 @@ the instance if any, similar to shared networks.
For example:
Network rate of network offering = 10 Mbps
-
Network rate of compute offering = 200 Mbps
In shared networks, ingress traffic will not be limited for CloudStack,
diff --git a/source/conf.py b/source/conf.py
index 4607e9d..bfbcb04 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -93,6 +93,7 @@ html_theme = 'sphinx_rtd_theme'
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
+html_css_files = ['theme_overrides.css']
# Custom sidebar templates, must be a dictionary that maps document names
# to template names.
#
diff --git a/source/upgrading/index.rst b/source/upgrading/index.rst
index 041f3b8..3acf799 100644
--- a/source/upgrading/index.rst
+++ b/source/upgrading/index.rst
@@ -37,6 +37,7 @@ Contents:
.. toctree::
:maxdepth: 1
+ upgrade/upgrade-4.12
upgrade/upgrade-4.11
upgrade/upgrade-4.10
upgrade/upgrade-4.9
diff --git a/source/upgrading/upgrade/upgrade-4.10.rst b/source/upgrading/upgrade/upgrade-4.10.rst
index 4e9c729..9341b1d 100644
--- a/source/upgrading/upgrade/upgrade-4.10.rst
+++ b/source/upgrading/upgrade/upgrade-4.10.rst
@@ -217,6 +217,7 @@ This file should have content similar to the following:
enabled=1
gpgcheck=0
+
If you are using the community provided package repository, change the base url to:
.. parsed-literal::
diff --git a/source/upgrading/upgrade/upgrade-4.10.rst b/source/upgrading/upgrade/upgrade-4.12.rst
similarity index 74%
copy from source/upgrading/upgrade/upgrade-4.10.rst
copy to source/upgrading/upgrade/upgrade-4.12.rst
index 4e9c729..310219b 100644
--- a/source/upgrading/upgrade/upgrade-4.10.rst
+++ b/source/upgrading/upgrade/upgrade-4.12.rst
@@ -14,13 +14,13 @@
under the License.
-.. |version_to_upgrade| replace:: 4.10.x
+.. |version_to_upgrade| replace:: 4.12.x
Upgrade Instruction from |version_to_upgrade|
=============================================
-This section will guide you from CloudStack |version_to_upgrade| to CloudStack
-|release|.
+This section will guide you from CloudStack |version_to_upgrade| to latest
+CloudStack |release|.
Any steps that are hypervisor-specific will be called out with a note.
@@ -39,10 +39,6 @@ Upgrade Steps:
#. Upgrade CloudStack management server(s)
#. Update hypervisors specific dependencies
-Apache CloudStack 4.10.0.0 users who are upgrading to 4.11.0.0 should read the
-following discussion and workaround for a db-upgrade issue:
-http://markmail.org/message/f42kqr3mx4r4hgih
-
.. include:: _sysvm_templates.rst
Packages repository
@@ -57,12 +53,11 @@ Create RPM or Debian packages (as appropriate) and a repository from
the |release| source, or check the Apache CloudStack downloads page at
http://cloudstack.apache.org/downloads.html
for package repositories supplied by community members. You will need
-them for :ref:`ubuntu410` or :ref:`rhel410` and :ref:`kvm410` hosts upgrade.
+them for :ref:`ubuntu411` or :ref:`rhel411` and :ref:`kvm411` hosts upgrade.
Instructions for creating packages from the CloudStack source are in the
`CloudStack Installation Guide`_.
-
Database Preparation
--------------------
@@ -108,13 +103,13 @@ Backup current database
$ mysql -u cloud -p -e 'update cloud.storage_pool set path="/var/lib/libvirt/images" where path="/var/lib/libvirt/images/"';
-.. _ubuntu410:
+.. _ubuntu411:
Management Server on Ubuntu
---------------------------
If you are using Ubuntu, follow this procedure to upgrade your packages. If
-not, skip to step :ref:`rhel410`.
+not, skip to step :ref:`rhel411`.
.. note::
**Community Packages:** This section assumes you're using the community
@@ -126,10 +121,7 @@ each system with CloudStack packages. This means all management
servers, and any hosts that have the KVM agent. (No changes should
be necessary for hosts that are running VMware or Xen.)
-
-.. _apt-repo410:
-
-.. include:: _java_8_ubuntu.rst
+.. _apt-repo411:
CloudStack apt repository
^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -178,13 +170,13 @@ read as appropriate for your |version| repository.
$ sudo apt-get upgrade cloudstack-usage
-.. _rhel410:
+.. _rhel411:
Management Server on CentOS/RHEL
--------------------------------
If you are using CentOS or RHEL, follow this procedure to upgrade your
-packages. If not, skip to hypervisors section :ref:`upg_hyp_410`.
+packages. If not, skip to hypervisors section :ref:`upg_hyp_411`.
.. note::
**Community Packages:** This section assumes you're using the community
@@ -192,7 +184,7 @@ packages. If not, skip to hypervisors section :ref:`upg_hyp_410`.
yum repository, substitute your own URL for the ones used in these examples.
-.. _rpm-repo410:
+.. _rpm-repo411:
CloudStack RPM repository
^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -213,11 +205,12 @@ This file should have content similar to the following:
[apache-cloudstack]
name=Apache CloudStack
- baseurl=http://download.cloudstack.org/centos/6/4.10/
+ baseurl=http://download.cloudstack.org/centos/6/4.12/
enabled=1
gpgcheck=0
-If you are using the community provided package repository, change the base url to:
+If you are using the community provided package repository, change
+the base url to:
.. parsed-literal::
@@ -247,19 +240,16 @@ read as appropriate for your |version| repository.
$ sudo yum upgrade cloudstack-usage
-.. _upg_hyp_410:
+.. _upg_hyp_411:
-Hypervisor: XenServer
----------------------
+Upgrade Hypervisors
+-------------------
-**(XenServer only)** Copy vhd-utils file on CloudStack management servers.
-Copy the file `vhd-utils <http://download.cloudstack.org/tools/vhd-util>`_
-to ``/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver``.
-.. parsed-literal::
+Hypervisor: XenServer
+^^^^^^^^^^^^^^^^^^^^^
- wget -P /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver \
- http://download.cloudstack.org/tools/vhd-util
+No additional steps are required wrt for XenServer Hypervisor for this upgrade.
Hypervisor: VMware
@@ -267,87 +257,26 @@ Hypervisor: VMware
.. warning::
For VMware hypervisor CloudStack management server packages must be
- build using "noredist". Refer to :ref:`building-noredist`
-
-**(VMware only)** Additional steps are required for each VMware cluster.
-These steps will not affect running guests in the cloud. These steps
-are required only for clouds using VMware clusters:
-
-#. Stop the Management Server:
-
- .. parsed-literal::
-
- $ sudo service cloudstack-management stop
-
-#. Generate the encrypted equivalent of your vCenter password:
-
- .. parsed-literal::
-
- $ java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.2.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI encrypt.sh input="_your_vCenter_password_" password="`cat /etc/cloudstack/management/key`" verbose=false
-
-Store the output from this step, we need to add this in
-cluster\_details table and vmware\_data\_center tables in place of
-the plain text password
-
-#. Find the ID of the row of cluster\_details table that you have to
- update:
-
- .. parsed-literal::
+ build using "noredist". Refer to :ref:`building-noredist`.
- $ mysql -u <username> -p<password>
-
- .. parsed-literal::
-
- select * from cloud.cluster_details;
-
-#. Update the plain text password with the encrypted one
-
- .. parsed-literal::
-
- update cloud.cluster_details set value = '_ciphertext_from_step_1_'
- where id = _id_from_step_2_;
-
-#. Confirm that the table is updated:
-
- .. parsed-literal::
-
- select * from cloud.cluster_details;
-
-#. Find the ID of the correct row of vmware\_data\_center that you
- want to update
-
- .. parsed-literal::
-
- select * from cloud.vmware_data_center;
-
-#. update the plain text password with the encrypted one:
-
- .. parsed-literal::
-
- update cloud.vmware_data_center set password = '_ciphertext_from_step_1_'
- where id = _id_from_step_5_;
-
-#. Confirm that the table is updated:
-
- .. parsed-literal::
- select * from cloud.vmware_data_center;
+No additional steps are requried for the VMware Hypervisor for this upgrade.
-.. _kvm410:
+.. _kvm411:
Hypervisor: KVM
----------------
+^^^^^^^^^^^^^^^
KVM on Ubuntu
-^^^^^^^^^^^^^
+""""""""""""""
(KVM only) Additional steps are required for each KVM host. These
steps will not affect running guests in the cloud. These steps are
required only for clouds using KVM as hosts and only on the KVM
hosts.
-#. Configure the :ref:`APT repo <apt-repo410>` as detailed above.
+#. Configure the :ref:`APT repo <apt-repo411>` as detailed above.
#. Stop the running agent.
@@ -378,10 +307,10 @@ hosts.
KVM on CentOS/RHEL
-^^^^^^^^^^^^^^^^^^
+"""""""""""""""""""
For KVM hosts, upgrade the ``cloudstack-agent`` package
-#. Configure the :ref:`rpm-repo410` as detailed above.
+#. Configure the :ref:`rpm-repo411` as detailed above.
.. parsed-literal::
diff --git a/source/upgrading/upgrade/upgrade-4.7.rst b/source/upgrading/upgrade/upgrade-4.7.rst
index e94f35f..0833c6d 100644
--- a/source/upgrading/upgrade/upgrade-4.7.rst
+++ b/source/upgrading/upgrade/upgrade-4.7.rst
@@ -215,7 +215,11 @@ This file should have content similar to the following:
gpgcheck=0
If you are using the community provided package repository, change
-the base url to ``http://download.cloudstack.org/centos/$releasever/4.9/``.
+the base url to:
+
+.. parsed-literal::
+
+ http://download.cloudstack.org/centos/$releasever/|version|/
Setup the GPG public key if you wish to enable ``gpgcheck=1``:
diff --git a/source/upgrading/upgrade/upgrade-4.8.rst b/source/upgrading/upgrade/upgrade-4.8.rst
index 9e4458b..6cdc837 100644
--- a/source/upgrading/upgrade/upgrade-4.8.rst
+++ b/source/upgrading/upgrade/upgrade-4.8.rst
@@ -222,7 +222,6 @@ If you are using the community provided package repository, change the base url
http://download.cloudstack.org/centos/$releasever/|version|/
-
Setup the GPG public key if you wish to enable ``gpgcheck=1``:
.. parsed-literal::