[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13839387#comment-13839387
 ] 

ASF subversion and git services commented on CLOUDSTACK-5352:
-------------------------------------------------------------

Commit e85334ff515b6e640d61666998a08774ddcfb9f3 in branch refs/heads/4.3 from 
[~nitinme]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e85334f ]

CLOUDSTACK-5352:
CPU cap calculated incorrectly for VMs on XenServer hosts. It should not be 
limited by the overprovisioning and should set the cap as service offering


> 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
>            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)

Reply via email to