This post is more than 5 years old
2 Intern
•
227 Posts
0
2257
VASA 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.
pete2c
76 Posts
1
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.
pete2c
76 Posts
0
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.
M_Salem
213 Posts
0
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
M_Salem
213 Posts
1
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
duhaas1
2 Intern
2 Intern
•
227 Posts
0
April 23rd, 2014 06:00
great, thanks agaon @pete2c and M.Salem to be clear, is it recommended to do the unmap in VMware and the reclaim on the vmax, or is it an either or?
WorldPolice
123 Posts
2
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.
duhaas1
2 Intern
2 Intern
•
227 Posts
0
April 23rd, 2014 06:00
Thanks much pete2c thats a non-disruptive operation correct? running a reclaim on a device?
pete2c
76 Posts
0
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.
M_Salem
213 Posts
1
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
M_Salem
213 Posts
0
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
WorldPolice
123 Posts
0
April 23rd, 2014 07:00
Check out our other WP on VAAI for UNMAP help:
http://www.emc.com/collateral/hardware/white-papers/h8115-vmware-vstorage-vmax-wp.pdf