Return-Path: 
 <dev-return-50922-apmail-cloudstack-dev-archive=cloudstack.apache.org@cloudstack.apache.org>
X-Original-To: apmail-cloudstack-dev-archive@www.apache.org
Delivered-To: apmail-cloudstack-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id D6D76106E7
	for <apmail-cloudstack-dev-archive@www.apache.org>;
 Tue, 28 Jan 2014 05:33:22 +0000 (UTC)
Received: (qmail 12994 invoked by uid 500); 28 Jan 2014 05:33:21 -0000
Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org
Received: (qmail 12969 invoked by uid 500); 28 Jan 2014 05:33:20 -0000
Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cloudstack.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cloudstack.apache.org>
List-Post: <mailto:dev@cloudstack.apache.org>
List-Id: <dev.cloudstack.apache.org>
Reply-To: dev@cloudstack.apache.org
Delivered-To: mailing list dev@cloudstack.apache.org
Received: (qmail 12961 invoked by uid 99); 28 Jan 2014 05:33:20 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Jan 2014 05:33:20 +0000
X-ASF-Spam-Status: No, hits=-2.3 required=5.0
	tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of harikrishna.patnala@citrix.com
 designates 103.14.252.240 as permitted sender)
Received: from [103.14.252.240] (HELO SMTP.CITRIX.COM.AU) (103.14.252.240)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Jan 2014 05:33:13 +0000
X-IronPort-AV: E=Sophos;i="4.95,733,1384300800";
   d="scan'208";a="2541905"
Received: from sinaccessns.citrite.net (HELO SINPEX01CL02.citrite.net)
 ([10.151.60.9])
  by sinpip01.citrite.net with ESMTP; 28 Jan 2014 05:32:51 +0000
Received: from SINPEX01CL03.citrite.net ([169.254.3.46]) by
 SINPEX01CL02.citrite.net ([169.254.2.69]) with mapi id 14.02.0342.004; Tue,
 28 Jan 2014 13:32:50 +0800
From: Harikrishna Patnala <harikrishna.patnala@citrix.com>
To: "<dev@cloudstack.apache.org>" <dev@cloudstack.apache.org>
Subject: Re: KVM memory overprovision breaking me
Thread-Topic: KVM memory overprovision breaking me
Thread-Index: AQHPG8L1HpuISCHxI0mLw65MPHxxdZqYzeOAgAASbICAADbTAA==
Date: Tue, 28 Jan 2014 05:32:50 +0000
Message-ID: <02D880FC-CEAA-48C1-BE6A-27539BB656C3@citrix.com>
References: 
 <CALFpzo7yx+N=RrbfUkwn7PHbf+Ra=6880YQtJYGJXd2yjt_r1A@mail.gmail.com>
 <da8ae7c3b90d3aa33137708e4c857826@li.nux.ro>
 <CALFpzo4FoZOsuACVQOH8QzABfK=xJ85+W2EoYsXFCZaGYHZP=w@mail.gmail.com>
In-Reply-To: 
 <CALFpzo4FoZOsuACVQOH8QzABfK=xJ85+W2EoYsXFCZaGYHZP=w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.151.46.1]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <2ABF3F21FDB7384F98E4268E41DCF5F3@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-DLP: SIN1
X-Virus-Checked: Checked by ClamAV on apache.org

Hi,
I think the way it was done is to guarantee minimum memory to that VM and u=
pon demand it can get upto the memory defined in service offering.
Say a vm with service offering 4Gb is deployed with overprovisioing factor =
2, we guarantee that vm should get minimum of 2GB (4GB/2) and if that VM is=
 overloaded then it can get memory unto max 4GB.
This is what it is showing vm definition
>>> <memory unit=3D'KiB=92>4GB</memory>
>>>  <currentMemory unit=3D'KiB=92>2GB</currentMemory>
"memory unit=94 is what it can get maximum.

-Harikrishna


On 28-Jan-2014, at 7:46 am, Marcus Sorensen <shadowsor@gmail.com> wrote:

> Its an easy fix on the KVM side, just waiting to hear any objections.
> On Jan 27, 2014 6:11 PM, "Nux!" <nux@li.nux.ro> wrote:
>=20
>> On 28.01.2014 00:49, Marcus Sorensen wrote:
>>=20
>>> So... I tried to use memory overcommit on KVM this week, and it blew
>>> up in my face. Apparently it's configured such that if I have a
>>> Service Offering of 4G, and I set memory overprovisioning to 2:1, the
>>> guest only actually gets configured with 2G. That's not how
>>> overprovisioning is supposed to work, IMO.
>>>=20
>>> Here's a vm definition with a 3:1 mem overprovision setting, which
>>> ensures that system vms don't work:
>>>=20
>>>  <memory unit=3D'KiB'>262144</memory>
>>>  <currentMemory unit=3D'KiB'>87040</currentMemory>
>>>=20
>>> Note currentMemory needs to be manually tuned if I ever want the vm to
>>> use/see more. This is more for live scaling (which is also broken
>>> because the guest could just rmmod virtio-balloon and see everything).
>>>=20
>>> I'd like to just rip out the code that is setting ballooning feature
>>> based on overprovisioning factor, but perhaps there was a reason this
>>> was done. From my point of view, if I give someone a service offering
>>> that says 4G, it should provide 4G, and if I can do memory
>>> deduplication on the backend to overprovision that's up to me to do.
>>> Overprovisioning should not be a divider on all service offerings.
>>>=20
>>=20
>> Wow! I also thought, heck, KSM & thin qcows for the win! If
>> overprovisioning really "works" as you described then it can't possibly =
be
>> used for any commercial offering ...
>> This needs to get fixed.. Too late to see this in 4.3?
>>=20
>> --
>> Sent from the Delta quadrant using Borg technology!
>>=20
>> Nux!
>> www.nux.ro
>>=20