Most Storage solutions now come with the capability to over provision the available storage. This allows over-committing the storage and using the space more efficiently.
CloudStack currently is able to leverage this functionality by specifying global parameter storage.overprovisioning.factor which is the admin defined over provision factor for all the primary storages.
This functional specification describes the requirements for support of per-primary storage overprovision setting.
https://issues.apache.org/jira/browse/CLOUDSTACK-6092
The feature allows CloudStack admins to define over-provisioning for individual primary data storages. This will eliminate the tight dependency over the global parameter to leverage underlying overprovisioning.
A typical Cloud deployment will have different combinations of primary storages. They could either be from different vendors or from the same vendor but different products.
Depending on the storage capability, CloudStack admins will have the flexibility to determine what the over-provisioning factor should be for each primary storage.
available storage exposed for the primary data store will be (actualStorageSize) * (storage.overprovisioning.factor for the primary)
The total summation of capacity of all the primary storages will be displayed on the dashboard with appropriate alerts.
All operations like attach Volume, copy Template, resize Volume, Migration etc. will be handled to adhere to the overprovisioning of the primary data store involved.
admin can update an existing primary store by setting overprovisioning in the per primary setting.
This value will override the value at the global level. This leverages the granularity of global parameters introduced in 4.2
To fall back to the global value, null value can be passed.
To disable overprovision a value of 1 will be passed.
Storage stats will now include actual used size (requires writing/modifying resource calls). This value will be used by the admin to decrease/increase the overprovision factor depending upon the actual capacity used.
For examaple, a higher value of used size will be indicative of lowering overprovisioning for further vm deployments.
Fix for CLOUDSTACK-5806 as suggested by community requires implementing isOverProvisionSupported() which will be used to calculate allocated storage as per-primary type basis, thus not restricting this functionality to NFS and VMFS only.
Incorporating the fix will allow admin to overprovision primary based on the overprovisioning capability.
Adding new column used_size to storage_pool table
listStoragePool will have overprovision factor also listed.
.All operations like attach Volume, copy Template, resize Volume etc that involve Primary Storages would be logged at different log levels (INFO, ERROR, DEBUG) in management server log file.
Appropriate Upgrades will be handled.
Listing Primary Store will have the overprovisionfactor also.