MSA 2050 Change Pool Settings - Overcommit Flag cannot be disabled

[RobI_1]

Hi,

is I try to Change Pool Settings and remove the Flag on Enable overcommitment of pool? it is grayed out and I cannot remove it.

Running VL100P001 with 2 Pools  A and B, one disk group assigned to each pool and one LUN in each pool/group.

Is there any bug or any limitation why overcommit cannot be disabled?

We currently are on usage well below the allocated storage.

Thank you

[SUBHAJIT KHANBARMAN_1]

Can you please provide the GUI screenshot of the Pool usage?

You need to provide size information at the Pool level, Disk Group leve to get the idea.

# show pools

# show disk-groups

# show snapshot-space

As per SMU guide "If you try to disable overcommitment and the total space allocated to thin-provisioned volumes exceeds the physical capacity of their pool, an error will state that there is insufficient free disk space to complete the operation and
overcommitment will remain enabled. If your system has a replication set, the pool might be unexpectedly overcommitted
because of the size of the internal snapshots of the replication set."

There is one known issue,

Issue: When downloading CSV data from the "Pools" table, the fifth column is incorrectly labeled as "Allocated Size", when it should be "Available Size".
Workaround: After downloading CSV data from the Pools table, change the label of the fifth column from "Allocated Size" to "Available Size".

You can try restarting both management controllers.

You can try by updating Controller firmware to latest version VL270R001-01

Hope this helps!
Regards
Subhajit

I am an HPE employee

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************

[RobI_1]

Hi,

here it is.

# show pools
Name Serial Number Blocksize Total Size Avail Snap Size OverCommit Disk Groups Volumes Low Thresh Mid Thresh High Thresh Sec Fmt Health Reason Action
---------------------------------------------------------------------------------------------------------------------------
A 00c0ff3c1efc0000efb4345b01000000 512 3594.9GB 1543.3GB 0B Enabled 1 1 50.00 % 75.00 % 94.02 % 512n OK
B 00c0ff3c1fee00007db5345b01000000 512 3594.9GB 922.0GB 0B Enabled 1 1 50.00 % 75.00 % 94.02 % 512n OK
---------------------------------------------------------------------------------------------------------------------------
Success: Command completed successfully. (2019-03-20 08:42:35)

# show disk-groups
Name Blocksize Size Free Pool Tier % of Pool Own Pref RAID Disks Spr Chk Status Jobs Job% Serial Number Spin Down
SD Delay Sec Fmt Health Reason Action
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Group1 512 3594.9GB 1543.3GB A Standard 100 A A RAID5 7 0 64k FTOL 00c0ff3c1efc0000eeb4345b00000000 Disabled
0 512n OK
Group2 512 3594.9GB 922.0GB B Standard 100 B B RAID5 7 0 64k FTOL 00c0ff3c1fee00007bb5345b00000000 Disabled
0 512n OK
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Success: Command completed successfully. (2019-03-20 08:44:01)

# show snapshot-space
Snapshot Space
--------------
Pool: A
Limit (%Pool): 10%
Limit Size: 359.4GB
Allocated (%Pool): 0.0%
Allocated (%Snapshot Space): 0.0%
Allocated Size: 0B
Low Threshold (%Snapshot Space): 75%
Middle Threshold (%Snapshot Space): 90%
High Threshold (%Snapshot Space): 99%
Limit Policy: Notify Only

Snapshot Space
--------------
Pool: B
Limit (%Pool): 10%
Limit Size: 359.4GB
Allocated (%Pool): 0.0%
Allocated (%Snapshot Space): 0.0%
Allocated Size: 0B
Low Threshold (%Snapshot Space): 75%
Middle Threshold (%Snapshot Space): 9High Threshold (%Snapshot Space): 99%
Limit Policy: Notify Only

Success: Command completed successfully. (2019-03-20 08:44:35)

[SUBHAJIT KHANBARMAN_1]

forgot to ask below command output,

# show volumes

Also please provide the error screenshot that you are getting. What step you are following kindly mention as well.

Hope this helps!
Regards
Subhajit

I am an HPE employee

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************

[RobI_1]

Hi, here it is

# show volumes
Pool Name Total Size Alloc Size Type Health Reason Action
-----------------------------------------------------------
A LUN1 3593.9GB 2051.5GB base OK
B LUN2 3593.9GB 2672.8GB base OK
-----------------------------------------------------------
Success: Command completed successfully. (2019-03-20 09:45:32)

Can it be the fact that there is a failed disk in the array and is not allowing changes?

[SUBHAJIT KHANBARMAN_1]

It seems better to get SMU V3 Home screen screenshot to understand how much is Reserved space (RAID Parity and metadata) because this space will be taken from disk-group space only.

Also good to get "show disks" command output but don't share drive serial numbers in public. Just remove or hide all serial numbers.

In your Case total Pool A size 3594.9GB because disk-group Group1 size 3594.9GB. Now volume LUN1 provisioned size 3593.9GB. In this condition if you try to disable overcommit option that means you are trying to allocate full space for the volume which means this volume will no longer be Thin provisioned volume and it will become Thick Volume or fully allocated volume. This means LUN1 will require 3593.9GB of space from the pool. But if there is already some space got eaten up by Reserved space then we will be shortage of some space which LUN1 require to convert from Thin to Thick.

Another reason could be failure of one disk.

I have no idea drive failed part of which pool?

Are you facing overcommit disable issue for both Pools ?

Hope this helps!
Regards
Subhajit

I am an HPE employee

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************

[Shawn_K]

Hello,

All of your Pools and disk-groups are seen as healthy and not in a degraded state. So the drive failure is not currently playing a part in your issue. That being said you should get a replacement drive in the system and assigned as a global spare.

You have 3594.9GB of space allocated and 3594.9GB provisioned. When you disable the over committed feature there is not enough space to move from thinly provisioned to fully provisioned. Which means there is likely some data that is not yet fully committed.

I suggest you add more capacity to your existing disk-groups, allow the over provisioned space to move, and then you will be able to move from thinly provisioned to fully provisioned.

Cheers,
Shawn

I work for Hewlett Packard Enterprise. The comments in this post are my own and do not represent an official reply from HPE. No warranty or guarantees of any kind are expressed in my reply.

[RobI_1]

# show disks
Location Serial Number Vendor Rev Description Usage Jobs Speed (kr/min) Size Sec Fmt Disk Group Pool Tier Health
------------------------------------------------------------------------------------------------------------------------------------------------------
1.1 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group1 A Standard OK
1.2 REMOVED HP HPD3 SAS FAILED 15 600.1GB 512n N/A Fault
1.3 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group1 A Standard OK
1.4 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group1 A Standard OK
1.5 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group1 A Standard OK
1.6 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group1 A Standard OK
1.7 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group1 A Standard OK
1.8 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group2 B Standard OK
1.9 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group2 B Standard OK
1.10 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group2 B Standard OK
1.11 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group2 B Standard OK
1.12 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group2 B Standard OK
1.13 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group2 B Standard OK
1.14 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group2 B Standard OK
1.15 REMOVED HP HPD3 SAS VIRTUAL POOL 15 600.1GB 512n Group1 A Standard OK
1.16 REMOVED HP HPD3 SAS GLOBAL SP 15 600.1GB 512n N/A OK
1.17 REMOVED HP HPD3 SAS AVAIL 15 600.1GB 512n N/A OK
1.18 REMOVED HP HPD3 SAS AVAIL 15 600.1GB 512n N/A OK
------------------------------------------------------------------------------------------------------------------------------------------------------
Info: * Rates may vary. This is normal behavior. (2019-03-21 12:34:45)

I have no idea drive failed part of which pool?

It was pool A and has now automatically failed to 15th disk

Are you facing overcommit disable issue for both Pools ?

Yes

[RobI_1]

Will try that as soon as we get the disk replaced.

[SUBHAJIT KHANBARMAN_1]

Yes as per details received, it looks like 1.2 failed which was part of disk-group Group1 and 1.15 was configured as Global spare. The moment 1.2 failed, 1.15 got used to reconstruct data of 1.2 so 1.15 now part of Group1 means part of Pool A

As informed you earlier,  It seems better to get SMU V3 Home screen screenshot to understand how much is Reserved space (RAID Parity and metadata) because this space will be taken from disk-group space only.

You don't have sufficient space to convert Thin Volume to Fully provision volume or Thick Volume that's why you are not getting overcommit disable option.

You need to add more drives and make new disk-group like Group1 and then add it to Pool A. It's always recommended to add same number of drives and configure in same RAID like existing disk-group in same tier to get better performance for that Pool. Keep in mind that you can't extend disk-group  here like you did vdisk expand in linear MSA array.

Hope this helps!
Regards
Subhajit

I am an HPE employee

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************

[RobI_1]

[SUBHAJIT KHANBARMAN_1]

Thank you for sharing the Home Screen details.

According to that, you can see that total Virtual Disk Group size 8401 GB, out of that Allocated 4725 GB and unallocated 2462 GB. Which means reserved space left = [8401 - (4725 + 2462)] = 1214 GB

Now there are two Pools and Two disk-groups which means for each disk-group 607 GB got reserved. Your Thin provisioned Volume Size was 3594 GB .and Disk-group Size also 3594 GB. This the main reason when you try to disable overcommit option that time it's greyed out which means with current condition not possible.

Hope this helps!
Regards
Subhajit

I am an HPE employee

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************

[RobI_1]

Hi, apologies but is very hard to follow these calculations criteria.

I have 1 Disk Group in RAID 5 assigned to POOL A made of 8*600GB disks, totals up to ~4.2TB Netto.

From This POOL A we publish a Volume of 3593.9 GB as LUN 1 to VMware and we use ~70% of that.

Disk Group 1 shows 1542.5GB free.

Can you tell me why, it is not possible to thick provision this Volume?

It is hard to follow the new way HP has obliged us to use for the virtual arrays, the fact the linear capability was removed is very annoying and even more annoying is that we cannot add single disks to expand capacity.

[SUBHAJIT KHANBARMAN_1]

Yes there is difference between linear array and Virtual array.

In case of linear array all volumes Thick volume only but in Virtual array all volumes by default Thin Volume only.

In todays world most people interested in Thin Volume only because space should be allocated based on demand from backend rather than allocating entire space in 1st day itself which is the case of Thick volume. Lots of wastage of space.

Virtualization is a technology which helps to save price like pay as you use concept.

HPE came up with Virtualization technology with entry level Storage like MSA which is really great.

Applogise for the earlier Calculation which was not correct and I have corrected it.

Now coming to your setup, you are considering 7 x 600Gb drives which is approx 4.2TB physical space but when you create RAID 5 disk-group that time some space gets reserved as RAID parity and metadata for which affective space you get (4200-606) = 3594GB

Out of this VDG space already 2052 Gb got allocated and 1541 Gb unallocated space.

Virtual volumes make use of a method of storing user data in virtualized pages. These pages may be spread throughout
the underlying physical storage in a random fashion and allocated on demand. Virtualized storage therefore has a
dynamic mapping between logical and physical blocks.

Linear volumes make use of a method of storing user data in sequential fully allocated physical blocks. These blocks have
a fixed (static) mapping between the logical data presented to hosts and the physical location where it is stored.

This is the main reason when you try to disable overcommit option that time it look for sequential blocks or pages to allocate but it will not get that and that is the reason overcommit disable not possible in your case. 

So the solution is if you want to convert Thin Volume to Thick Volume then you need same size of space where sequeatial physical blocks available means 3594GB of sequential blocks required.

Hope this helps!
Regards
Subhajit

I am an HPE employee

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************

[RobI_1]

Does this mean we have to add 8*600GB disks to each pool in order to switch them to thick? Or less?

[SUBHAJIT KHANBARMAN_1]

You already have 3 drives at location 1.2, 1.17 and 1.18. Out of them you need to just replace 1.2 as that one failed.

Then  you need another 11 drives of 600 Gb each. so that  you can create Virtual Disk Group 7 x 600 GB =4200 Gb drives in each Pool.

Otherwise you can take data backup, then delete all data and existing disk-groups. Then re-create VDG and volumes. After that you can convert them as Thick Volume means overcommit option you can disable by modifying Pools settings.

Hope this helps!
Regards
Subhajit

I am an HPE employee

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************