You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by su...@apache.org on 2026/05/26 08:25:43 UTC
(cloudstack-documentation) 01/01: Merge branch '4.20' into 4.22
This is an automated email from the ASF dual-hosted git repository.
sureshanaparti pushed a commit to branch 4.22
in repository https://gitbox.apache.org/repos/asf/cloudstack-documentation.git
commit 8331917b954ad80ffda94bde3fe872d8a7433eb9
Merge: 736f8a3d febd11e9
Author: Suresh Kumar Anaparti <su...@shapeblue.com>
AuthorDate: Tue May 26 13:55:23 2026 +0530
Merge branch '4.20' into 4.22
source/_static/images/resize-volume.png | Bin 10420 -> 40174 bytes
source/adminguide/index.rst | 2 +-
source/adminguide/networking/security_groups.rst | 5 +
.../networking/virtual_private_cloud_config.rst | 18 ++--
source/adminguide/service_offerings.rst | 8 ++
source/adminguide/storage.rst | 15 ++-
.../adminguide/tuning/disable_omit_stack_trace.rst | 55 ++++++++++
source/adminguide/{ => tuning}/tuning.rst | 3 +
source/adminguide/virtual_machines.rst | 12 +++
source/conf.py | 2 +-
source/installguide/configuration.rst | 58 +++++++++--
source/installguide/hypervisor/kvm.rst | 116 ++++++++++++++++++++-
.../management-server/_pkg_install.rst | 16 +++
source/installguide/overview/_overview.rst | 2 +-
source/releasenotes/changes.rst | 2 +-
source/releasenotes/compat.rst | 15 +--
source/upgrading/index.rst | 11 ++
source/upgrading/upgrade/_sysvm_restart.rst | 30 +++++-
source/upgrading/upgrade/mysql.rst | 103 +++++++++++++++++-
source/upgrading/upgrade/upgrade_notes.rst | 111 ++++++++++++++++++++
20 files changed, 547 insertions(+), 37 deletions(-)
diff --cc source/installguide/hypervisor/kvm.rst
index d5dc3baa,5097b2f9..f7050040
--- a/source/installguide/hypervisor/kvm.rst
+++ b/source/installguide/hypervisor/kvm.rst
@@@ -24,7 -24,7 +24,7 @@@ KVM is included with a variety of Linux
Although you are not required to run these distributions, the following
are recommended:
- - CentOS / RHEL / Binary-compatible variants: 8.X, 9.X, 10.X
-- CentOS / RHEL / Binary-compatible variants: 8.X or 9.X
++- CentOS / RHEL: 7.X
- Ubuntu: 22.04 +
@@@ -328,82 -310,99 +328,129 @@@ sudoers file
cloudstack ALL=NOPASSWD: /usr/bin/cloudstack-setup-agent
Defaults:cloudstack !requiretty
+Please note that when adding the KVM host to your Cloudstack Management server,
+the setup commands will be run with sudo, even with root account.
+You should make sure that you are allowed to run binaries and sudo binaries.
+
+On security hardened machines, make sure that the following line is
+commented-out in your sudoers file if it exists:
+
+.. parsed-literal::
+
+ #Defaults noexec
+
+You may also want to make sure that sudo works by executing the following as
+the user you want to register the KVM host with:
+
+.. parsed-literal::
+
+ sudo /usr/in/cloudstack-setup-agent --help
+
+ Limit Resources For the Agent Service
+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+ #. Edit the cloudstack-agent.service file at:
+
+ .. code:: bash
+
+ /usr/lib/systemd/system/cloudstack-agent.service
+
+ #. You can set the following resource controls in the cloudstack-agent service:
+
+ - Limit the number of file descriptors
+
+ The default configuration is usually higher, set to a lower number explicitly when required. It is observed
+ that the average FDs for a host with 40 VMs was 380, we can reserve +20% based on the requirement. Example
+ shown below.
+
+ .. code:: bash
+
+ LimitNOFILE=1500
+
+ - Limit the memory usage
+
+ You can limit the memory usage. For example, set to 2500MB (2500 * 1024 * 1024 bytes) as shown below.
+
+ .. code:: bash
+
+ MemoryMax=2500M
+
+ - Limit the CPU quota
+
+ You can control the CPU allocation. For example, set to allow 2 full cores worth of CPU time as shown below.
+
+ .. code:: bash
+
+ CPUQuota=200%
+
+ #. Reload and restart the cloudstack-agent service after changing any of the resource controls:
+
+ .. code:: bash
+
+ sudo systemctl daemon-reload
+ sudo systemctl restart cloudstack-agent
+
+
+ .. include:: ../../adminguide/tuning/disable_omit_stack_trace.rst
+
-
-Configure CPU model for KVM guest (Optional)
+Configure CPU model for KVM guests (Optional)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-In additional,the CloudStack Agent allows host administrator to control
-the guest CPU model which is exposed to KVM Instances. By default, the
-CPU model of KVM Instance is likely QEMU Virtual CPU version x.x.x with
-least CPU features exposed. There are a couple of reasons to specify the
-CPU model:
+The CloudStack Agent allows host administrators to control
+the CPU model which is exposed to KVM instances. By default, the
+default QEMU CPU models (``qemu32`` or ``qemu64``) will be used, which
+are designed to be compatible with all hosts and, as a consequence, will
+expose the least amount of CPU features possible. Therefore, there are
+a couple of reasons to specify the CPU model:
-- To maximise performance of Instances by exposing new host CPU
- features to the KVM Instances;
+- Maximize performance of instances by exposing new host CPU
+ features to them; and,
-- To ensure a consistent default CPU across all machines,removing
- reliance of variable QEMU defaults;
+- Ensure a consistent default CPU across all machines, removing
+ reliance of variable QEMU defaults.
-For the most part it will be sufficient for the host administrator to
-specify the guest CPU config in the per-host configuration file
-(/etc/cloudstack/agent/agent.properties). This will be achieved by
-introducing following configuration parameters:
+The guest CPU configuration can be configured per host in the
+``/etc/cloudstack/agent/agent.properties`` configuration file
+through the following properties: ``guest.cpu.mode``, ``guest.cpu.model`` and ``guest.cpu.features``.
-.. parsed-literal::
+The ``guest.cpu.mode`` property accepts three possible values:
- guest.cpu.mode=custom|host-model|host-passthrough
- guest.cpu.model=from /usr/share/libvirt/cpu_map.xml(only valid when guest.cpu.mode=custom)
- guest.cpu.features=vmx ept aes smx mmx ht (space separated list of cpu flags to apply)
+#. **custom:** Allows the customization of the CPU model, which
+ should be defined in the ``guest.cpu.model`` setting. For instance:
-There are three choices to fulfill the cpu model changes:
+ .. parsed-literal::
-#. **custom:** you can explicitly specify one of the supported named
- model in /usr/share/libvirt/cpu\_map.xml
+ guest.cpu.mode=custom
+ guest.cpu.model=SandyBridge
+
+ The available CPU models for a given architecture can be retrieved by
+ executing ``virsh cpu-models <architecture>``. The XML definition of each
+ available model can be accessed at the ``/usr/share/libvirt/cpu_map/``
+ path of the KVM hosts.
-#. **host-model:** libvirt will identify the CPU model in
- /usr/share/libvirt/cpu\_map.xml which most closely matches the host,
+#. **host-model:** Libvirt will identify the CPU model in
+ ``/usr/share/libvirt/cpu_map`` which most closely matches the host's CPU,
and then request additional CPU flags to complete the match. This
- should give close to maximum functionality/performance, which
- maintaining good reliability/compatibility if the guest is migrated
- to another host with slightly different host CPUs.
-
-#. **host-passthrough:** libvirt will tell KVM to passthrough the host
- CPU with no modifications. The difference to host-model, instead of
- just matching feature flags, every last detail of the host CPU is
- matched. This gives absolutely best performance, and can be important
- to some apps which check low level CPU details, but it comes at a
+ should give close to maximum functionality/performance and
+ maintains good reliability/compatibility if the guest is migrated
+ to another host with slightly different CPUs.
+
+#. **host-passthrough:** Libvirt will tell KVM to passthrough the host
+ CPU with no modifications. The difference to ``host-model`` is that, instead of
+ just matching CPU flags, every last detail of the host's CPU is
+ matched. This gives absolutely best performance and can be important
+ to some apps that check low level CPU details. However, it comes at a
cost with respect to migration: the guest can only be migrated to an
- exactly matching host CPU.
+ exactly matching host's CPU.
+
+Furthermore, there is the ``guest.cpu.features`` setting that can be used
+to add or remove individual CPU features. It is important to highlight
+that Libvirt complains about specifying a list of flags without a CPU model.
+Therefore, to apply CPU flags in KVM, one of the following requirements must be met:
+
+- Define ``guest.cpu.mode=host-model`` and specify the flags;
+- Define ``guest.cpu.mode=host-passthrough`` and specify the flags; or,
+- Define ``guest.cpu.mode=custom``, ``guest.cpu.model=<cpu-model>`` and specify the flags.
Here are some examples:
diff --cc source/releasenotes/compat.rst
index f72cff06,b4e5af83..46e9bb5e
--- a/source/releasenotes/compat.rst
+++ b/source/releasenotes/compat.rst
@@@ -22,12 -22,13 +22,13 @@@ Supported OS Versions for Management Se
This section lists the operating systems that are supported for running
CloudStack Management Server.
- - Ubuntu 22.04 LTS, 24.04 LTS
- - Oracle Linux 8, 9, 10
- - Rocky Linux 8, 9, 10
- - Alma Linux 8, 9, 10
- - RHEL versions 8, 9, 10 (not tested, but expected to work same as other EL distros)
- - openSUSE Leap 15 (not widely tested and used by the community, tested to work openSUSE Leap 15.6)
+ - Ubuntu 20.04 LTS, 22.04 LTS, 24.04 LTS
+ - Oracle Linux 8, 9
+ - Rocky Linux 8, 9
+ - Alma Linux 8, 9
+ - RHEL versions 8, 9
+ - Experimental support for RHEL 10
-- openSUSE Leap 15 (not widely tested and used by the community, tested to work openSUSE Leap 15.6)
++- openSUSE Leap 15 (not widely tested and used by the community, tested to work in past CloudStack versions)
- SUSE Linux Enterprise Server 15 (not tested, but expected to work same as with openSUSE 15 but likely require workarounds)
- Debian 12, 13 (not tested, but expected to work same as Ubuntu)