Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added source/_static/images/disk_offering_dailog.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
183 changes: 117 additions & 66 deletions source/adminguide/service_offerings.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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.


Expand All @@ -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.
Expand All @@ -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
Expand Down
62 changes: 50 additions & 12 deletions source/adminguide/storage.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Expand Down Expand Up @@ -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
Expand Down
33 changes: 33 additions & 0 deletions source/adminguide/virtual_machines.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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
----------------------
Expand Down
Loading