Return-Path: 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 D19BD10F8B for ; Wed, 16 Oct 2013 11:59:57 +0000 (UTC) Received: (qmail 91728 invoked by uid 500); 16 Oct 2013 11:59:49 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 91695 invoked by uid 500); 16 Oct 2013 11:59:47 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 91590 invoked by uid 99); 16 Oct 2013 11:59:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Oct 2013 11:59:43 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.212.170] (HELO mail-wi0-f170.google.com) (209.85.212.170) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Oct 2013 11:59:39 +0000 Received: by mail-wi0-f170.google.com with SMTP id l12so6865778wiv.3 for ; Wed, 16 Oct 2013 04:59:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=xgKM9/rdoe2AIzExyObrvXkJ71k0Ktznwu7VY0j/k+o=; b=fx6Tef2423PtZ79h2suFrVGwSXWrTF8UYmaOddpuxCX5CcmnNfk5pfseJjpE1GLbEk 33dhkzfC5+5dml9x4g3zxVZ2ersSs9SSRSKjMZOSPYwkrKY8q/LPMM+DNJZ+8Ec2aMuu K3JOKRCLcA6enfTRjSdY/10DUONcJQ62lFjmeeoSC/ZWE+UQRUnYVQSKTXdtehsuJIEI iehCse+t5ZOVATVbp5wrB6pn3C+eTMfvmgV1VUrhLJUo31mnSNjeBwhP06rMF1j4n97c dIBTU7jsV5FXog3Aj8vbPFiAPTJbrngSC407y40gBPADITBB7oWZSaND4f8SvECDTRRB 1GJQ== X-Gm-Message-State: ALoCoQm5yO0FIDD/cloqx+hEX6HVr0F1ORRuusmhS8z54+uDxRlmsF7CVeT1NdmuecKj3z079bVU X-Received: by 10.180.20.46 with SMTP id k14mr1963728wie.39.1381924757585; Wed, 16 Oct 2013 04:59:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.176.167 with HTTP; Wed, 16 Oct 2013 04:58:57 -0700 (PDT) X-Originating-IP: [115.113.153.226] In-Reply-To: <5F0F3D45-B8D0-42B3-A040-809CAA72B9F4@citrix.com> References: <5F0F3D45-B8D0-42B3-A040-809CAA72B9F4@citrix.com> From: Gaurav Aradhye Date: Wed, 16 Oct 2013 17:28:57 +0530 Message-ID: Subject: Re: Scaling up cpu and memory of user vm above host capacity To: "dev@cloudstack.apache.org" Content-Type: multipart/alternative; boundary=bcaec53f34eb4854c504e8da6ed9 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec53f34eb4854c504e8da6ed9 Content-Type: text/plain; charset=ISO-8859-1 I have logged issue https://issues.apache.org/jira/browse/CLOUDSTACK-4880 for this. I will check bevavior for changeServiceForVirtualMachine API too and log issue if confirmed. Regards, Gaurav On Wed, Oct 16, 2013 at 4:46 PM, Harikrishna Patnala < harikrishna.patnala@citrix.com> wrote: > Yes Gaurav, please file a bug ticket for this issue. We should also > consider host cpu cores while scaling up the VM. > If you want to check for changeServiceForVirtualMachine API, try it on > stopped vm since the API is meant for only stopped vms. > > Thankyou > Harikrishna > > > On 16-Oct-2013, at 4:16 PM, Gaurav Aradhye > wrote: > > > Hi Nitin, > > > > I am able to scale a virtual machine (using scaleVirtualMachine API) to > use > > 5 CPU cores where as the host has only 4 physical CPU cores. According to > > David, this should not be the case. I can also reboot this instance. But > I > > can't create a new instance with this scaled up service offering which > has > > 5 CPU cores (Which seems to be a valid behavior). > > > > Should I file an issue for this? > > > > This issue seems to be present only for CPU and not for memory. I can't > > scale memory above the available memory in host. > > > > I will check the behavior again for the old API > > (changeServiceForVirtualMachine). > > I think the old API had issue with both CPU and memory. > > > > Regards, > > Gaurav > > > > > > On Fri, Oct 4, 2013 at 10:36 PM, Nitin Mehta > wrote: > > > >> changeServiceForVirtualMachine API was the old API to change the service > >> offering for a stopped vm only. > >> I think it shouldn't have succeeded for a running vm. Please file a bug > if > >> this is the case > >> > >> scaleVirtualMachine is the new API introduced in 4.2 for scaling a > >> running/stopped vm. Do read the link I pointed below when you get a > chance. > >> > >> Thanks, > >> -Nitin > >> > >> On 03/10/13 11:50 PM, "Gaurav Aradhye" > wrote: > >> > >>> Hi Nitin, > >>> > >>> I was trying on running vm only, but I was > >>> using changeServiceForVirtualMachine API instead of scaleVirtualMachine > >>> API. > >>> But I wonder why changeServiceForVirtualMachine API succeeded in > >>> allocating > >>> more than host capacity. > >>> > >>> What is the basic difference between these two operations? > >>> > >>> Regards, > >>> Gaurav > >>> > >>> > >>> On Tue, Oct 1, 2013 at 10:45 PM, Nitin Mehta > >>> wrote: > >>> > >>>> Gaurav - Were you trying this on a stopped vm ? If you try and start > it > >>>> with an offering > >>>> above the host capacity (including over provisioning ) then it > shouldn't > >>>> start. Let me know how it goes. > >>>> > >>>> More details on scale vm feature @ > >>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of > >>>> +C > >>>> PU+and+RAM > >>>> > >>>> On 01/10/13 12:02 AM, "Gaurav Aradhye" > >>>> wrote: > >>>> > >>>>> Thanks David. That disabuses my confusion about the CPU > provisioning. I > >>>>> was > >>>>> using the wrong API to scale up the virtual machine, so above > >>>> observations > >>>>> stand invalid till I get the same results with the right API. > >>>>> > >>>>> About over-provisioning, I have the over provisioning factor set as 1 > >>>> both > >>>>> in case of CPU and memory. > >>>>> > >>>>> Regards, > >>>>> Gaurav > >>>>> > >>>>> > >>>>> On Mon, Sep 30, 2013 at 10:55 PM, David Ortiz > >>>> wrote: > >>>>> > >>>>>> A machine won't be able to support more cores on a VM than the > >>>> physical > >>>>>> processor. That should result in problems trying to deploy it. I'm > >>>>>> guessing the service offering is still valid since you could add a > >>>> host > >>>>>> later which has a hex core or two cpus in it. As far as RAM goes, > do > >>>>>> you > >>>>>> have overprovisioning enabled? > >>>>>> > >>>>>>> From: gaurav.aradhye@clogeny.com > >>>>>>> Date: Mon, 30 Sep 2013 14:00:04 +0530 > >>>>>>> Subject: Scaling up cpu and memory of user vm above host capacity > >>>>>>> To: dev@cloudstack.apache.org > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> I am trying to automate a scenario here. I have only one host in > >>>>>> cluster > >>>>>>> with 4 CPU cores and 15 GB total memory. When I try to scale up cpu > >>>>>> and > >>>>>> RAM > >>>>>>> of a running user vm above the host capacity, it doesn't throw any > >>>>>> error > >>>>>>> and I can see the updated values in VM statistics too. > >>>>>>> > >>>>>>> For CPU, I am able to change the service offering of user vm as 5 > >>>>>> cores > >>>>>> * > >>>>>>> 100 MHz (even though host has 4 cores). I am not sure how this > >>>>>> calculation > >>>>>>> is done. Definitely many no. of virtual cores can be formed on host > >>>>>> (more > >>>>>>> than 4), but is it possible to allocate 5 cores to single VM ? > >>>> When I > >>>>>> try > >>>>>>> to deploy new VM with 5 core CPU service offering, then in this > >>>> case > >>>>>> it > >>>>>>> fails saying not enough server capacity. > >>>>>>> > >>>>>>> Also, For memory, I am able to create 17 GB memory service offering > >>>>>> and > >>>>>>> allocate it to any running user vm (although the total memory on > >>>> host > >>>>>> is > >>>>>> 15 > >>>>>>> GB). > >>>>>>> > >>>>>>> Any directions? Is this an issue or am I missing something here? > >>>>>>> > >>>>>>> Regards, > >>>>>>> Gaurav > >>>>>> > >>>>>> > >>>> > >>>> > >> > >> > > --bcaec53f34eb4854c504e8da6ed9--