BryanMLima commented on a change in pull request #6031:
URL: https://github.com/apache/cloudstack/pull/6031#discussion_r813192363
##########
File path:
plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtScaleVmCommandWrapper.java
##########
@@ -68,6 +71,23 @@ public Answer execute(ScaleVmCommand command,
LibvirtComputingResource libvirtCo
}
}
+ /**
+ * Set the cpu_shares (priority) of the running VM. This is necessary
because the priority is only calculated when deploying the VM.
+ * When the number of cores and/or speed of the CPU is changed the
cpu_shares is only updated if the VM is restarted or manually, using the
command schedinfo.
+ * To correct this behaviour when live scaling, this command changes the
cpu_shares of a running VM.
+ * @param dm domain of the VM.
+ * @param newCpuShares new priority of the running VM.
+ * @throws org.libvirt.LibvirtException
+ **/
+ protected void updateCpuShares(Domain dm, int newCpuShares) throws
LibvirtException {
+ int oldCpuShares = LibvirtComputingResource.getCpuShares(dm);
+
+ if (oldCpuShares < newCpuShares) {
Review comment:
In ACS, the live scale process does not allow to reduce the resource of
a running VM. Therefore, it can only occur upwards and the cpu_shares is
calculated as follow:
`cpu_shares = number of vCPUs X vCPU frequency in Mhz`.
This `if` (the conditional) is to check if the vCPUs or CPU speed is higher
than the current compute offering, as it makes no sense to decrease the
priority of a VM that is having its resources increased. In other words, this
`if` is to check if it is a memory scale only, which should not have its
priority changed in the host.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
