diff --git a/source/_static/images/change-offering-for-volume.png b/source/_static/images/change-offering-for-volume.png new file mode 100644 index 0000000000..850a2c1179 Binary files /dev/null and b/source/_static/images/change-offering-for-volume.png differ diff --git a/source/_static/images/compute_offering_dailog_with_compute_only_disk_offering.png b/source/_static/images/compute_offering_dailog_with_compute_only_disk_offering.png new file mode 100644 index 0000000000..af6f52a1fa Binary files /dev/null and b/source/_static/images/compute_offering_dailog_with_compute_only_disk_offering.png differ diff --git a/source/_static/images/compute_offering_dailog_with_diskoffering.png b/source/_static/images/compute_offering_dailog_with_diskoffering.png new file mode 100644 index 0000000000..fa0ac654c3 Binary files /dev/null and b/source/_static/images/compute_offering_dailog_with_diskoffering.png differ diff --git a/source/_static/images/disk_offering_dailog.png b/source/_static/images/disk_offering_dailog.png new file mode 100644 index 0000000000..53678dccb6 Binary files /dev/null and b/source/_static/images/disk_offering_dailog.png differ diff --git a/source/adminguide/service_offerings.rst b/source/adminguide/service_offerings.rst index 1a85afec4c..1b15c18a3c 100644 --- a/source/adminguide/service_offerings.rst +++ b/source/adminguide/service_offerings.rst @@ -97,7 +97,7 @@ with billing systems. Compute offerings may be "fixed", "custom constrained" or "custom unconstrained". -In fixed offering the Number of CPUs, Memory and CPU frequecy in each service +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 @@ -158,7 +158,27 @@ parameters, such as CPU, speed, RAM are recorded. Creating a New Compute Offering ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. image:: /_static/images/compute_offering_dialog.png +Along with the compute details of the VM, 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. + +Following are the two ways of creating the compute offering. + +1. Create compute only offering + +.. image:: /_static/images/compute_offering_dailog_with_compute_only_disk_offering.png + :width: 400px + :align: center + :alt: Compute offering dialog box + + +2. Create compute offering associated to a disk offering + +.. image:: /_static/images/compute_offering_dailog_with_diskoffering.png :width: 400px :align: center :alt: Compute offering dialog box @@ -182,21 +202,6 @@ To create a new compute offering: - **Description**: A short description of the offering that can be displayed to users - - **Storage type**: The type of disk that should be allocated. Local - allocates from storage attached directly to the host where the - system VM is running. Shared allocates from storage accessible via - NFS. - - - **Provisioning type**: The type of disk that should be allocated. - Valid values are thin, sparse, fat. When using the VMWare hypervisor, - these values are mapped to the following vSphere disk provisioning types: - - - **thin**: **Thin Provision** - - **sparse**: **Thick Provision Lazy Zeroed** - - **fat**: **Thick Provision Eager Zeroed** - - The disk provisioning type strictness on VMWare is controlled with the zone level setting - **disk.provisioning.type.strictness**. If set to true, the disk is created only when there is a suitable storage pool that supports the disk provisioning type specified by the service/disk offering. If set to false, the disk is created with a disk provisioning type supported by the pool. Default value is false and this is currently supported for VMware only. - - **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 @@ -227,64 +232,19 @@ To create a new compute offering: 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** [1]_: Allowed disk read rate in bits per second. - - - **Disk Write Rate** [1]_: Allowed disk write rate in bits per second. - - - **Disk Read Rate** [1]_: Allowed disk read rate in IOPS (input/output - operations per second). + - **Host Tags**: (Optional) Any tags that you use to organize your + hosts - - **Disk Write Rate** [1]_: Allowed disk write rate in IOPS (input/output - operations per second). + - **Network Rate**: Allowed data transfer rate in MB per second. - **Offer HA**: If yes, the administrator can choose to have the system VM be monitored and as highly available as possible. - - **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** [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** [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** [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** [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 - 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 - disk that represents the root disk. This does not apply for KVM. - - - **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 + - **Dynamic Scaling Enabled**: If yes, virtual machine can be dynamically scalable of cpu or memory - **CPU cap**: Whether to limit the level of CPU usage even if spare capacity is available. - - **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. - - **Volatile**: If checked, VMs 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 @@ -342,6 +302,11 @@ To create a new compute offering: In this case, a physical GPU device is exclusively allotted to a single guest VM. + - **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. + - **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 @@ -354,6 +319,83 @@ To create a new compute offering: - **Storage Policy**: Name of the storage policy defined at vCenter, this is applicable only for VMware. When a specific Zone is selected, one of the storage policies can be selected from the list box. + - **Compute only Disk Offering**: When this flag is enabled, a compute only disk offering + is created with the disk related information provided and then linked to the compute offering. + Compute only disk offering is specific to the newly created compute offering to record the + disk related information. when this flag is disabled, existing disk offering can be selected to + associate with the compute offering or a new disk offering can be created at the same time and + associate with the compute offering + + When the flag is enabled + + - **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. + + - **Provisioning type**: The type of disk that should be allocated. + Valid values are thin, sparse, fat. When using the VMWare hypervisor, + these values are mapped to the following vSphere disk provisioning types: + + - **thin**: **Thin Provision** + - **sparse**: **Thick Provision Lazy Zeroed** + - **fat**: **Thick Provision Eager Zeroed** + + The disk provisioning type strictness on VMWare is controlled with the zone level setting - **disk.provisioning.type.strictness**. If set to true, the disk is created only when there is a suitable storage pool that supports the disk provisioning type specified by the service/disk offering. If set to false, the disk is created with a disk provisioning type supported by the pool. Default value is false and this is currently supported for VMware only. + + - **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. + + - **Disk Read Rate** [1]_: Allowed disk read rate in bits per second. + + - **Disk Write Rate** [1]_: Allowed disk write rate in bits per second. + + - **Disk Read Rate** [1]_: Allowed disk read rate in IOPS (input/output + operations per second). + + - **Disk Write Rate** [1]_: Allowed disk write rate in IOPS (input/output + operations per second). + + - **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** [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** [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** [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 + 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 + disk that represents the root disk. This does not apply for KVM. + + - **Storage Tags**: The tags that should be associated with the + primary storage used by the system VM. + + When the flag is disabled + + - **Add Disk Offering**: Create a new disk offering while creating the compute offering itself. + Once disk offering is created, the new disk offering is auto selected from the below Disk Offerings list. + + - **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 + and change disk offering is not allowed for the ROOT disk + #. Click Add. @@ -376,6 +418,12 @@ To create a new disk offering: #. Click Add Disk Offering. + .. image:: /_static/images/disk_offering_dailog.png + :width: 400px + :align: center + :alt: Disk offering dialog box + + #. In the dialog, make the following choices: - **Name**: Any desired name for the disk offering. @@ -400,6 +448,9 @@ To create a new disk offering: The disk provisioning type strictness on VMWare is controlled with the zone level setting - **disk.provisioning.type.strictness**. If set to true, the disk is created only when there is a suitable storage pool that supports the disk provisioning type specified by the service/disk offering. If set to false, the disk is created with a disk provisioning type supported by the pool. Default value is false and this is currently supported for VMware only. + - **Disk Size Strictness**: The flag defines the size strictness of the volume created from this disk offering. + When flag is true, volume's size cannot be changed. + - **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 diff --git a/source/adminguide/storage.rst b/source/adminguide/storage.rst index 109927b5c9..40afc0a628 100644 --- a/source/adminguide/storage.rst +++ b/source/adminguide/storage.rst @@ -533,34 +533,39 @@ Migrating Storage and Attaching to a Different VM Volume” <#attaching-a-volume>`_ -Migrating a VM Root Volume to a New Storage Pool -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Migrating a Instance Root Volume to a New Storage Pool +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -(XenServer, VMware) You can live migrate a VM's root disk from one -storage pool to another, without stopping the VM first. +(XenServer, VMware) You can live migrate a instance's root disk from one +storage pool to another, without stopping the instance first. -(KVM) When migrating the root disk volume, the VM must first be stopped, -and users can not access the VM. After migration is complete, the VM can -be restarted. +(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 VM name. +#. In the left navigation bar, click Instances, and click the instance name. -#. (KVM only) Stop the VM. +#. (KVM only) Stop the instance. #. Click the Migrate button |Migrateinstance.png| and choose the destination from the dropdown list. .. note:: - If the VM's storage has to be migrated along with the VM, 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 VM. +#. (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. Resizing Volumes @@ -659,6 +664,37 @@ The following table shows possible combinations of Service offering supported re Shrinking the Root disk is not supported via the service offering resizing workflow. All the combinations above assume a transition to Root disks with size equals or bigger than the original. Service Offerings with Root size of 0GB do not change the disk size to Zero and indicates that the offering do not enforces a Root disk size. +Change disk offering for volume +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +There are volume operations like migrate volume and resize volume and both accepts new disk offering to replace the existing disk offering of volume. +Instead of using these APIs directly, the operation can be performed in the UI using change offering in the details view for the volume. +Upon changing the disk offering the volume will be resized and/or migrated to the suitable storage pool if required according to the new disk offering. + +The zone level setting "match.storage.pool.tags.with.disk.offering" gives flexibility or control to choose the new disk offering. +If this setting is true, then the new disk offering should have the same storage tags as the exiting disk offering of the volume. + +To change the disk offering of a volume: + +#. Log in to the CloudStack UI as a user or admin. + +#. In the left navigation bar, click Storage. + +#. In Select View, choose Volumes. + +#. Select the volume name in the Volumes list, then click the Change Offering for Volume button + +#. In the Change Offering For Volume pop-up, choose desired disk offering for the + volume. + + |change-offering-for-volume.png| + + #. If you select Custom Disk, specify a custom size. + + #. Enable or Disable "Auto migrate to another storage pool if required" as needed + +#. Click OK. + Reset VM to New Root Disk on Reboot ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -934,6 +970,8 @@ and use the resource group name you added in the LINSTOR cluster. :alt: button to display the resize volume option. .. |resize-volume.png| image:: /_static/images/resize-volume.png :alt: option to resize a volume. +.. |change-offering-for-volume.png| image:: /_static/images/change-offering-for-volume.png + :alt: option to change offering for a volume. .. |SnapshotButton.png| image:: /_static/images/SnapshotButton.png :alt: Snapshot Button. .. |DetachDiskButton.png| image:: /_static/images/detach-disk-icon.png diff --git a/source/adminguide/virtual_machines.rst b/source/adminguide/virtual_machines.rst index bef876a931..9c3284951a 100644 --- a/source/adminguide/virtual_machines.rst +++ b/source/adminguide/virtual_machines.rst @@ -558,7 +558,40 @@ To manually live migrate a virtual machine where i in [0,..,N] and N = number of volumes of the virtual machine +Moving Instance's Volumes Between Storage Pools (offline volume Migration) +-------------------------------------------------------------------- +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 instance is stopped. + +- The destination storage pool must have enough available capacity. + +- UI operation allows only migrating the root volume upon selecting the + storage pool. To migrate all volumes to the desired storage pools + the 'migrateVirtualMachineWithVolume' API has to be used by providing + 'migrateto' map parameter. + + +To perform stopped instance's volumes migration + +#. Log in to the CloudStack UI as root administrator. + +#. In the left navigation, click Instances. + +#. Choose the instance that you want to migrate. + +#. Click the Migrate Instance button. |Migrateinstance.png| + +#. From the list of suitable storage pools, choose the one to which you want to + move the instance root volume. + +#. Click OK. Assigning VMs to Hosts ---------------------- diff --git a/source/plugins/cloudstack-kubernetes-service.rst b/source/plugins/cloudstack-kubernetes-service.rst index 0373879877..445ed984ce 100644 --- a/source/plugins/cloudstack-kubernetes-service.rst +++ b/source/plugins/cloudstack-kubernetes-service.rst @@ -153,6 +153,23 @@ A new network offering named DefaultNetworkOfferingforKubernetesService has been - Multi-control nodes, HA cluster can be created for Kubernetes version 1.16 and above only. - While creating multi-control nodes, HA cluster over a shared network, an external load-balancer must be manually setup. This load-balancer should have port-forwarding rules for SSH, Kubernetes API server access. Service assumes SSH access to cluster nodes is available from port 2222 to (2222 + cluster node count -1). Similarly, for API access 6443 must be forwarded to control nodes. Over the CloudStack isolated network these rules are automatically provisioned. + +Examples of how to ssh into the Control and Worker nodes + +Control node + +.. parsed-literal:: + + ssh -i -p 2222 cloud@ + +Worker node + +.. parsed-literal:: + + ssh -i -p 2223 cloud@ + + + Managing Kubernetes clusters ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/quickinstallationguide/qig.rst b/source/quickinstallationguide/qig.rst index 3f1cb7f1a3..4183931ea1 100644 --- a/source/quickinstallationguide/qig.rst +++ b/source/quickinstallationguide/qig.rst @@ -86,10 +86,10 @@ CloudStack. We will go over the steps to prepare now. Operating System ~~~~~~~~~~~~~~~~ -Using the CentOS 7.9.2009 minmal x86_64 install ISO, you'll need to install +Using the CentOS 7.9.2009 minimal x86_64 install ISO, you'll need to install CentOS 7 on your hardware. The defaults will generally be acceptable for this installation - but make sure to configure IP address/parameters so that you can later install needed -packages from internet. Later, we will change the network configuration as needed. +packages from the internet. Later, we will change the network configuration as needed. Once this installation is complete, you'll want to gain access to your server - through SSH. @@ -447,7 +447,7 @@ Install Python MySQL connector from the MySQL community repository (which we've # yum -y install mysql-connector-python Please note that the previously required ``mysql-connector-java`` library is now bundled with CloudStack -Management server and is no more required to be installed separately. +Management server and is no longer required to be installed separately. Installation ~~~~~~~~~~~~ @@ -460,14 +460,14 @@ following command: # yum -y install cloudstack-management CloudStack |version| requires Java 11 JRE. Installing the management server -will automatically install Java 11, but it's good to explicitly confirm that the Java 11 +will automatically install Java 11, but it's good to explicitly confirm that Java 11 is the selected/active one (in case you had a previous Java version already installed): .. parsed-literal:: $ alternatives --config java -Make sure that Java 11 is the chosen one. +Make sure that Java 11 is selected. With the application itself installed we can now setup the database, we'll do that with the following command and options: