[
https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14951845#comment-14951845
]
ASF GitHub Bot commented on CLOUDSTACK-8896:
--------------------------------------------
Github user bhaisaab commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/873#discussion_r41697351
--- 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 --
I guess there is no consensus or guideline around logging ids in debug logs
(uuids vs ids) though I've seen most logs messages using IDs instead of UUIDs
(perhaps because most code relied on IDs than UUIDs, as UUIDs were introduced
only in that last 2 years or so).
Though the logged message is not verbose enough wrt what it was doing, may
be you can add some context to say what it is doing etc?
> 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)
