This is an automated email from the ASF dual-hosted git repository.
rohit 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 a8a7bf4 Update documentation for strict host tags (#398)
a8a7bf4 is described below
commit a8a7bf4abe21aba48fa45586fe7d526fe3a214fd
Author: Vishesh <[email protected]>
AuthorDate: Tue Jun 25 14:42:58 2024 +0530
Update documentation for strict host tags (#398)
* Update documentation for strict host tags
* Address comments
---
source/adminguide/host_and_storage_tags.rst | 35 +++++++++++++++++++++++++++++
source/adminguide/virtual_machines.rst | 19 ++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/source/adminguide/host_and_storage_tags.rst
b/source/adminguide/host_and_storage_tags.rst
index 9969495..9bbb18b 100644
--- a/source/adminguide/host_and_storage_tags.rst
+++ b/source/adminguide/host_and_storage_tags.rst
@@ -54,6 +54,41 @@ To explain the behavior of host tags, some examples will be
demonstrated with tw
* Offering: h3
None of the hosts have compatible tags and it will not be possible to
deploy a VM with the offering. However, CloudStack ignores this behavior when a
host is manually selected.
+.. _strict-host-tags:
+Strict Host Tags
+-----------------
+During certain operations, such as changing the compute offering or starting or
+live migrating an instance to a specific host, CloudStack may ignore the host
+tags. This behavior is intentional and is designed to provide flexibility in
+resource allocation. However, in some cases, this can lead to instances being
+deployed on undesired hosts.
+
+To address this, CloudStack introduces an add-on feature that allows
administrators
+to enforce tag checks during these operations. By specifying the required tags
+in the global configuration `vm.strict.host.tags`, CloudStack will ensure that
+the specified tags must match during the operations. If any of the specified
+tags do not match, the operation will fail.
+
+If `resource.limit.host.tags` are defined and
+`vm.strict.resource.limit.host.tag.check` is set to true, the tags defined in
+`resource.limit.host.tags` are included with the `vm.strict.host.tags`.
+
+.. list-table:: Strict host tags related global settings
+ :header-rows: 1
+
+ * - Parameter
+ - Default
+ - Description
+ * - ``vm.strict.host.tags``
+ - empty
+ - A comma-separated list of tags which must match during operations like
+ modifying the compute offering for an instance, and starting or live
+ migrating an instance to a specific host.
+ * - ``vm.strict.resource.limit.host.tag.check``
+ - `true`
+ - If set to true, tags specified in `resource.limit.host.tags` are also
+ included in `vm.strict.host.tags`.
+
Storage tags
------------
Storage tags are responsible for directing volumes to compatible primary
storage. They are validated with the storage tags entered in the disk offerings
or system offerings.
diff --git a/source/adminguide/virtual_machines.rst
b/source/adminguide/virtual_machines.rst
index 90d041a..f292d11 100644
--- a/source/adminguide/virtual_machines.rst
+++ b/source/adminguide/virtual_machines.rst
@@ -276,6 +276,14 @@ CloudStack's database. The reboot process does not do
this.
When starting an Instance, admin Users have the option to specify a pod,
cluster, or host.
+.. note::
+ When starting an instance, it's possible to specify a host for deployment,
+ even if the host's tags don't match the instance's tags. This can lead to a
+ mismatch between the VM's tags and the host's tags, which may not be
+ desirable.
+
+ To avoid this, refer to the :ref:`strict-host-tags` section
+
Deleting Instance
------------------
@@ -441,6 +449,11 @@ Instance, you can change the Instance's compute offering.
#. Click OK.
+.. note::
+ When changing the service offering for an instance, it's possible to have a
+ mismatch of host tags which can be problematic.
+
+ For more information on how to prevent this, see :ref:`strict-host-tags`.
.. _cpu-and-memory-scaling:
@@ -637,6 +650,12 @@ To manually live migrate an Instance
where i in [0,..,N] and N = number of volumes of the Instance
+.. note::
+ During live migration, there can be a mismatch between the instance's tags
+ with the destination host's tags which might be undesirable.
+
+ For more details on how to prevent this, see :ref:`strict-host-tags`.
+
Moving Instance's Volumes Between Storage Pools (offline volume Migration)
--------------------------------------------------------------------------
