Solved!
Go to SolutionVASA Storage Alarm/VMax Meta Device
Trying to determine how to resolve the issue I have with VMware (5.1 env) thinking a particular device is oversubscribed?
The volumes itself from a VMware perspective is fine in terms of free space:
From a VMAX perspective my meta device:
We typically fully allocate volumes on creation, don't ask me why, still trying to change things a bit. Is that the reason why I have the alarm? I have other volumes that we provision the same way but dont have the alarm. In reading the EMC white paper on the topic its normal behavior, i'm just trying to understand how to make sense of it a bit more.
Seems like running a space reclamation on the device is the answer? Just hoping to get some feedback/advice.
1807
0
Posted April 23rd, 2014 06:00
Doing the vmkfstools command sends the UNMAP to the array and reclaims the % of space you specify from the array. So it's not an either/or. Example, if you have a 100GB datastore that is showing 20 GB free, and you issue this command to reclaim 50% of the space:
vmkfstools -y 50
It will attempt to reclaim 10GB of that free space (50% of 20GB) on the array.
1806
0
Posted April 23rd, 2014 06:00
if you ran vmkfstool -y, you won't need to do any further action as UNMAP will set the tracks to NWBH and if a full extent is marked as NWBH, the whole extent will deallocated and returned to the pool.
Hope that helps
Mohammed Salem @yankoora
1806
1
Posted April 23rd, 2014 06:00
Yes, It is non disruptive from SYMM side and also non disruptive from ESX side if you used a reasonable value of reclamation percentage for creating the temp balloon file.
Hope that helps
Mohammed Salem @yankoora
1807
2
Posted April 23rd, 2014 06:00
Just remember that if the preallocation of the TDEV was persistent, you will NOT be able to reclaim the space. As we have warned in the WP when using VASA, if the desire is to avoid the minor overhead of allocation of new extents our recommendation is to use eagerzeroedthick vmdks and not preallocation.
1806
0
Posted April 23rd, 2014 06:00
Thanks much pete2c thats a non-disruptive operation correct? running a reclaim on a device?
1807
0
Posted April 23rd, 2014 06:00
Yes, typically the reclaim (aka UNMAP) is non-disruptive. You can run it using the vmkfstools command. See this VMware KB for details - http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2014849
However, BEFORE DOING THAT you'll want to check which Enginuity you have on your array. There is a known issue as described in the following KB article. - https://support.emc.com/kb/184320
Make sure before doing any UNMAP command to a VMAX device that you have this fix.
1806
1
Posted April 23rd, 2014 06:00
Hello Duhhas,
As per the whitepaper, if the used capacity exceeded 80% you will receive an alert triggered from vCenter server as you mentioned above. These alerts are being sent by SMI-S to the vCenter server. Like you mentioned, you will need to reclaim space on the thin device from symmetrix side or run dead space reclamation using vmkfstools -y (for ESXi 5.1) Further info about this command can be found here:
http://kb.vmware.com/kb/2014849
http://blogs.vmware.com/vsphere/2012/04/vaai-thin-provisioning-block-reclaimunmap-in-action.html
Hope that helps
Mohammed Salem @yankoora
96
0
Posted April 23rd, 2014 07:00
Adding to what Drew mentioned, If the TDEV was originally created with Persistent allocation, Starting with SE7.4 and ucode 5876 you can clear the persistent allocations of tracks so that T10 UNMAP can reclaim these extents.
The command is: symdev -sid xxx unset -persistent
Hope it helps.
Mohammed Salem @yankoora
pete2c
1 Rookie
•
76 Posts
1805
1
Posted April 23rd, 2014 06:00
VASA is looking at the % written/allocated on the TDEV, which is why the alarm is red. As the whitepaper says, this is because it's over 80%.
The volume could be 93% full due to pre-allocating or, perhaps more likely, tracks have been written/deleted and have filled up that space. You should be able to issue a reclaim on the free space to resolve this.