Copilot commented on code in PR #543:
URL: 
https://github.com/apache/cloudstack-documentation/pull/543#discussion_r2286930308


##########
source/installguide/hypervisor/kvm.rst:
##########
@@ -331,81 +331,94 @@ sudoers file:
    Defaults:cloudstack !requiretty
 
 
-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
 
-#. **host-model:** libvirt will identify the CPU model in
-   /usr/share/libvirt/cpu\_map.xml which most closely matches the host,
+   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.

Review Comment:
   The word 'path' should be 'paths' to match the plural context of 'KVM hosts'.
   ```suggestion
      paths of the KVM hosts.
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to