Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Tue, 3 Dec 2013 18:04:36 +0000 (UTC)
From: "Nitin Mehta (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12682447.1386093801161.63476.1386093876727@arcas>
In-Reply-To: <JIRA.12682447.1386093801161@arcas>
References: <JIRA.12682447.1386093801161@arcas>
Subject: [jira] [Created] (CLOUDSTACK-5352) CPU cap calculated incorrectly
 for VMs on XenServer hosts
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Nitin Mehta created CLOUDSTACK-5352:
---------------------------------------

             Summary: CPU cap calculated incorrectly for VMs on XenServer h=
osts
                 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 defa=
ult.)
    Affects Versions: 4.2.0
            Reporter: 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 resul=
t in performance problems. This seems related to CPU overprovisioning. The =
assigned CPU cap is approximately the expected cap / CPU overprovisioning v=
alue. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the cus=
tomer 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 ex=
pected CPU cap.
I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220=
L CPU =E2=80=93 2x physical cores / 4x logical cores (with hyperthreading) =
at 2.20GHz =E2=80=93 8800 MHz total (confirmed in op_host_capacity), a Comp=
ute Offering with 2200 MHz and 4 cores gives a VM with:
[root@csdemo-xen2 ~]# xe vm-list params=3Dname-label,uuid,VCPUs-params name=
-label=3Di-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=3Dname-label,uuid,VCPUs-params name=
-label=3Di-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 environme=
nt, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settin=
gs. In example 1 the cap should be:
2200 * 0.99 * 4 / 2200 * 100
=3D 396
But it is:
2200 * 0.99 * 4 / (3*2200) * 100
=3D 132
For example 2 it should be:
2200 * 0.99 * 1 / 2200 * 100
=3D 99
But it is:
2200 * 0.99 * 1 / (3*2200) * 100


--
This message was sent by Atlassian JIRA
(v6.1#6144)