[jira] [Commented] (CLOUDSTACK-5061) Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores

["Noel King (JIRA)" <ji...@apache.org>]

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

Noel King commented on CLOUDSTACK-5061:
---------------------------------------

Hi 

I see this fix, but I am wondering if there is a path missing for this fix? From what I can read in the code from the StatsController it triggers based on the storage.stats.interval time interval.  This is calling the StorageController? which has the following code which can set the pool.setCapacityBytes without containing the over provisioning factor? 

I had identified the issue raised here in version 4.1.1 which I am using on VMWare and as a consequence looked to see if I could update the database manually to handle this op_host_capacity and storage_pool tables, however I believe the StorageController is the class that keeps resetting my updated database values.  My investigation is a little hard as I am just reading through the code to understand the paths potentially impacting the issue raised here.

I know this issues is closed and I can raise a new one if the correct procedure in such a situation.

============= StatsController > StorageController > run()
Answer answer = _storageManager.sendToPool(pool, command);
    					if (answer != null && answer.getResult()) {
    						storagePoolStats.put(pool.getId(), (StorageStats)answer);
    
    						// Seems like we have dynamically updated the pool size since the prev. size and the current do not match
    						if (_storagePoolStats.get(poolId)!= null &&
    								_storagePoolStats.get(poolId).getCapacityBytes() != ((StorageStats)answer).getCapacityBytes()){
    		                    pool.setCapacityBytes(((StorageStats)answer).getCapacityBytes());
    		                    _storagePoolDao.update(pool.getId(), pool);
    	                    }
    					}
=========================

Thanks

Noel

> Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-5061
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5061
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Storage Controller
>    Affects Versions: 4.2.0
>            Reporter: Sateesh Chodapuneedi
>            Assignee: Sateesh Chodapuneedi
>            Priority: Critical
>             Fix For: 4.2.1
>
>
> Cloudstack does not let us to create new VMs as it cannot calculate a free space correctly when using Thin Provisioning with VMware. It calculates space from the size of the volumes rather then what is truly utilized on the SAN. 
> DETAILS
>  ===================
>  1. DB
>  mysql> select p.name, p.pool_type, p.used_bytes, p.capacity_bytes, sum(v.size) as volumes_allocated from volumes v join storage_pool p on v.pool_id=p.id where v.removed is null group by v.pool_id;
> -------------------------------------------------------------------------------------
> name  pool_type  used_bytes  capacity_bytes  volumes_allocated  
> -------------------------------------------------------------------------------------
> PrimaryStorage1  VMFS  804432904192  1023812829184  940446842880  
> PrimaryStorage2  VMFS  901673648128  1023812829184  347791687680  
> -------------------------------------------------------------------------------------
>  2 rows in set (0.01 sec)
> 2. vCenter reports as the datastore size, storage allocated, and storage used
>  Capacity : 953.50GB
>  Provisioned Space : 944.76GB
>  Free Space : 751.60GB



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)