Return-Path: 
 <issues-return-61727-apmail-cloudstack-issues-archive=cloudstack.apache.org@cloudstack.apache.org>
X-Original-To: apmail-cloudstack-issues-archive@www.apache.org
Delivered-To: apmail-cloudstack-issues-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id A7EEB184B9
	for <apmail-cloudstack-issues-archive@www.apache.org>;
 Thu,  1 Oct 2015 06:13:04 +0000 (UTC)
Received: (qmail 67939 invoked by uid 500); 1 Oct 2015 06:13:04 -0000
Delivered-To: apmail-cloudstack-issues-archive@cloudstack.apache.org
Received: (qmail 67905 invoked by uid 500); 1 Oct 2015 06:13:04 -0000
Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@cloudstack.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@cloudstack.apache.org>
List-Post: <mailto:issues@cloudstack.apache.org>
List-Id: <issues.cloudstack.apache.org>
Reply-To: dev@cloudstack.apache.org
Delivered-To: mailing list issues@cloudstack.apache.org
Received: (qmail 67896 invoked by uid 500); 1 Oct 2015 06:13:04 -0000
Delivered-To: apmail-incubator-cloudstack-issues@incubator.apache.org
Received: (qmail 67892 invoked by uid 99); 1 Oct 2015 06:13:04 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Oct 2015 06:13:04 +0000
Date: Thu, 1 Oct 2015 06:13:04 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12895381.1442913989000.128590.1443679984414@Atlassian.JIRA>
In-Reply-To: <JIRA.12895381.1442913989000@Atlassian.JIRA>
References: <JIRA.12895381.1442913989000@Atlassian.JIRA>
 <JIRA.12895381.1442913989809@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of
 storage can go beyond 100%
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14939364#comment-14939364 ] 

ASF GitHub Bot commented on CLOUDSTACK-8896:
--------------------------------------------

Github user karuturi commented on a diff in the pull request:

    https://github.com/apache/cloudstack/pull/873#discussion_r40881830
  
    --- Diff: server/src/com/cloud/storage/StorageManagerImpl.java ---
    @@ -1736,7 +1737,10 @@ public boolean storagePoolHasEnoughSpace(List<Volume> volumes, StoragePool pool)
                         allocatedSizeWithtemplate = _capacityMgr.getAllocatedPoolCapacity(poolVO, tmpl);
                     }
                 }
    -            if (volumeVO.getState() != Volume.State.Ready) {
    +            // A ready state volume is already allocated in a pool. so the asking size is zero for it.
    +            // In case the volume is moving across pools or is not ready yet, the asking size has to be computed
    +            s_logger.debug("pool id for the volume with id: " + volumeVO.getId() + " is: " + volumeVO.getPoolId());
    --- End diff --
    
    @wido numeric ids in logs are easy to understand/debug than uuids. names might me more readable but ids are unique and hence no ambiguity. 
    The current pool-id is already logged and the pool-id of the the volume would help me see if the volume is moving across pools. That was the information I was looking for while debugging this issue and was hard to find given nothing was logged before.


> Allocated percentage of storage can go beyond 100%
> --------------------------------------------------
>
>                 Key: CLOUDSTACK-8896
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>    Affects Versions: 4.5.2, 4.6.0
>            Reporter: Rajani Karuturi
>            Assignee: Rajani Karuturi
>
> This issue occurs when a volume in Ready state is moved across storage pools.
> Let us say there is a data volume, volume0 in Ready state in a cluster scope primary storage primary0.
> Now, when an operation is attempted to attach this volume to a vm in another cluster, the volume is moved to the new cluster and the asking size is zero at this time.
> you can observe logs like below with asking size 0 in the management server logs.
> 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) (logid:a0a97129) Checking pool: 1 for volume allocation [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : 24096276480, askingSize : 0, allocated disable threshold: 0.85



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)