Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Thu, 7 Nov 2013 23:27:18 +0000 (UTC)
From: "Nitin Mehta (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12678106.1383866675001.38962.1383866838150@arcas>
In-Reply-To: <JIRA.12678106.1383866675001@arcas>
References: <JIRA.12678106.1383866675001@arcas>
Subject: [jira] [Comment Edited] (CLOUDSTACK-5091) Upgrade to 4.2 - used cpu
 is getting bumped up when the over provisioning factor > 1 - script fix
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-5091?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D13816782#comment-13816782 ]=20

Nitin Mehta edited comment on CLOUDSTACK-5091 at 11/7/13 11:26 PM:
-------------------------------------------------------------------

Issue =E2=80=93 Due to changes in over provisioning factor in 4.2, a bug go=
t introduced for customers using cpu.overprovisioning.factor (i.e. factor >=
 1)

Effects of the issue =E2=80=93 You will see the used capacity bumped up by =
cpu.overprovisioning.factor for all the vms deployed pre 4.2 version.

Who all need the fix =E2=80=93=20
If you have upgraded to 4.2 or planning to upgrade to 4.2. AND
If cpu.overprovisioning.factor in the global settings is not set 1, then yo=
u need to apply this fix.

Note =E2=80=93 If you are planning to upgrade to 4.2.1 then this fix is not=
 required.
When to fix
  If you are on 4.2 already then asap.
  If planning to upgrade to 4.2 then do it right after successful upgrade.

How to fix -=20
Choose one of the fixes from below. Manual Fix or Script Fix

Manual Fix
Get over provisioning factor from query below. If factor =3D 1, move to Ste=
p #4 else Step #2.
select value from `cloud`.`configuration` where name=3D'cpu.overprovisionin=
g.factor';
Get a list of vm ids which need this fix. Move to Step #2
select id from `cloud`.`vm_instance` where removed is null and id not in (s=
elect vm_id from `cloud`.`user_vm_details` where name=3D'cpuOvercommitRatio=
')
For each vm in the list insert the over provisioning factors.
INSERT IGNORE INTO cloud.user_vm_details (vm_id, name, value) VALUES (?, 'c=
puOvercommitRatio', over_provisioning_factor_from_Step_#1)
INSERT IGNORE INTO cloud.user_vm_details (vm_id, name, value) VALUES (?, 'm=
emoryOvercommitRatio', 1)
Verify from the dashboard that the used capacity has decreased by the over =
provisioning factor.
Done.


Script Fix
./fix_overprovisioning.sh -h
Usage: [-d] [-u] [-p]
-d - cloud DB server ip address, defaulted to localhost if not specified=20
-u - user name to access cloud DB, defaulted to cloud if not specified=20
-p - cloud DB user password, defaulted to cloud if not specified
Example: fix_overprovisioning.sh -dlocalhost -ucloud -pcloud
Verification =E2=80=93 Notice the used capacity decreased by the over provi=
sioning factor in the dashboard view of the UI.


was (Author: nitinme):
Issue =E2=80=93 Due to changes in over provisioning factor in 4.2, a bug go=
t introduced for customers using cpu.overprovisioning.factor (i.e. factor >=
 1)
Effects of the issue =E2=80=93 You will see the used capacity bumped up by =
cpu.overprovisioning.factor for all the vms deployed pre 4.2 version.
Who all need the fix =E2=80=93=20
If you have upgraded to 4.2 or planning to upgrade to 4.2. AND
If cpu.overprovisioning.factor in the global settings is not set 1, then yo=
u need to apply this fix.
Note =E2=80=93 If you are planning to upgrade to 4.2.1 then this fix is not=
 required.
When to fix
If you are on 4.2 already then asap.
If planning to upgrade to 4.2 then do it right after successful upgrade.
How to fix -=20
Choose one of the fixes from below. Manual Fix or Script Fix
Manual Fix
Get over provisioning factor from query below. If factor =3D 1, move to Ste=
p #4 else Step #2.
select value from `cloud`.`configuration` where name=3D'cpu.overprovisionin=
g.factor';
Get a list of vm ids which need this fix. Move to Step #2
select id from `cloud`.`vm_instance` where removed is null and id not in (s=
elect vm_id from `cloud`.`user_vm_details` where name=3D'cpuOvercommitRatio=
')
For each vm in the list insert the over provisioning factors.
INSERT IGNORE INTO cloud.user_vm_details (vm_id, name, value) VALUES (?, 'c=
puOvercommitRatio', over_provisioning_factor_from_Step_#1)
INSERT IGNORE INTO cloud.user_vm_details (vm_id, name, value) VALUES (?, 'm=
emoryOvercommitRatio', 1)
Verify from the dashboard that the used capacity has decreased by the over =
provisioning factor.
Done.
Script Fix
./fix_overprovisioning.sh -h
Usage: [-d] [-u] [-p]
-d - cloud DB server ip address, defaulted to localhost if not specified=20
-u - user name to access cloud DB, defaulted to cloud if not specified=20
-p - cloud DB user password, defaulted to cloud if not specified
Example: fix_overprovisioning.sh -dlocalhost -ucloud -pcloud
Verification =E2=80=93 Notice the used capacity decreased by the over provi=
sioning factor in the dashboard view of the UI.

> Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning=
 factor > 1 - script fix
> -------------------------------------------------------------------------=
------------------------
>
>                 Key: CLOUDSTACK-5091
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-509=
1
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the defa=
ult.)=20
>    Affects Versions: 4.2.0
>            Reporter: Nitin Mehta
>            Assignee: Nitin Mehta
>             Fix For: 4.2.0
>
>
> Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning=
 factor > 1
> Provide a script fix for this - Will solve the issue where used cpu is ge=
tting bumped up when the over provisioning factor > 1. This would need to b=
e documented and run manually as an additional step by the admin.
> Also write KB article


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