Whenever you create a volume via cinder the actual size of the volume is smaller then the one requested. At first I thought it was gigabyte vs gibibyte issue (e.g. 1000 vs 1024 base).
Built to meet the extreme requirements of massively consolidated cloud service providers, HPE 3PAR StoreServ provides more than 3M IOPS and consistent sub-ms latency. Transform your midrange and enterprise deployments with solutions that scale from a few TBs to more than 20 PB.
But then I ran a comparison and it turned out that the ratio is always different. I created several volumes with cinder CLI and compared the size taken directly from 3PAR vs the size taken from cinder. Please see cinder sizecomparison.txt for results. In order to confirm that this is not an issue in hp3parclient I ran the same test again and this time created the volumes via hp3parclient package. See 3parsize comparison.
Txt for results. I'm running on CentOS 7, OpenStack Icehouse installed from RDO packages. I'm facing the same issue. To verify that the 3PAR itself works correctly I've tried allocating volumes in 3PAR Management Console client using both thin and full provisioning.
In both cases I've set size to 10 GiB. In both cases, 'Virtual Size' was reported as '10 GiB' whereas 'Used User Size' was different: for thinly provisioned volume it was 0.5 GiB and for fully provisioned one it was 10 GiB. So, 3PAR SAN itself works as expected. Then I tried to allocate volumes using OpenStack command-line utility, and the results repeat the issue described above.
I requested a 10 GiB volume, it was allocated successfully and OpenStack reports it as 10 GiB one, however, in 3PAR Management Console client 'Virtual Size' is reported as 9.5 GiB. Where have my 500 MiB gone? I also tried the `set volume backend name=3parfc hp3par: provisioning= full` trick as suggested in #8 and the problem is still there - 'Virtual Size' of requested 10 GiB volume is still 9.5 GiB as reported by 3PAR Management Console client. I also tried running the tests from #6 and I got similar results to what OP is reporting. Michael, I'm aware about thin provisioning.
And it's obvious that it has nothing to do with this particular problem. Please, focus on the bug instead of posting advertising leaflets. It looks to me that you didn't care to run any of the scripts I have provided to you. Please, consider this debug session instead.
Hello Ihor, So I believe this bug to be invalid, and here is why. Cinder's client is documented as follows: Positional arguments: Size of volume, in GBs. (Required unless snapshot-id /source- volid is specified). So, when you are requesting a cinder volume of size 4, you are actually requesting 4 Gigabytes. 4 gigabytes is equal to 3815 mebibytes (rounded up). This is not equivalent to creating a 4Gib volume on the 3PAR command line or the 3PAR management console.
All data on the 3PAR is listed as Mib, or Gib units, not MB or GB. The conversion we are doing in our driver from 4GB (coming from the cinder API), to GiB is correct. You end up with a volume of size 3840 showing up in the 3PAR command line management console, which is correct.
Hello, Walter. To me it looks like you haven't read neither my original issue description nor any of the attachmants.
At first I thought it was gigabyte vs gibibyte issue (e.g. 1000 vs 1024 base).
But then I ran a comparison and it turned out that the ratio is always different. If this would be a case with giga vs gibi then the ratio would be the same regardless of what volume size is requested. But this is not the case! Please, take a look at the evidences provided. They prove that you are wrond and this is not gigabytes to gibibytes conversion. Also, regardless of whether it is giga/gibi conversion issue or not the end-user expects the values shown in Horizon web ui and in their guest operating systems to match which would not be the case for 3PAR driver. The rest of drivers I've tried behave as expected and the sizes match.
So this is definitely a bug in 3PAR driver. Your assertions are false. Cinder and Horizon work and expect values in Gigabytes. 3PAR work in Gigibytes. A conversion has to happen, that conversion is working as expected as I described above.
When you run cinder create -name foo 4, you are asking Cinder to create a 4 Gigabyte volume. This gets converted to Gigibytes, which is what the 3PAR expects.
You will see in the 3PAR command console a 4 Gigabyte volume represented as Gigibytes. When you create a volume on the 3PAR itself using the 3PAR command line and or UI, you are creating volumes in Gigibytes.
So, when you enter 4, you are saying 4Gigibytes.