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 <[email protected]> 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)
