Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
4.2.0, 4.3.0
-
None
-
Security Level: Public (Anyone can view this level - this is the default.)
-
None
Description
The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap.
I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with:
[root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM
uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb
name-label ( RW): i-2-87-VM
VCPUs-params (MRW): weight: 84; cap: 131
And with a Compute Offering with 2200 MHz and 1 core gives a VM with:
[root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM
uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd
name-label ( RW): i-2-87-VM
VCPUs-params (MRW): weight: 84; cap: 32
The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be:
2200 * 0.99 * 4 / 2200 * 100
= 396
But it is:
2200 * 0.99 * 4 / (3*2200) * 100
= 132
For example 2 it should be:
2200 * 0.99 * 1 / 2200 * 100
= 99
But it is:
2200 * 0.99 * 1 / (3*2200) * 100
Attachments
Issue Links
- mentioned in
-
Page Loading...