[
https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta updated CLOUDSTACK-5352:
------------------------------------
Affects Version/s: 4.3.0
> CPU cap calculated incorrectly for VMs on XenServer hosts
> ---------------------------------------------------------
>
> Key: CLOUDSTACK-5352
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Affects Versions: 4.2.0, 4.3.0
> Reporter: Nitin Mehta
> Assignee: Nitin Mehta
> Priority: Critical
> Fix For: 4.3.0
>
>
> 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
--
This message was sent by Atlassian JIRA
(v6.1#6144)
