[
https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta updated CLOUDSTACK-5352:
------------------------------------
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
was:
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
> 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)
