Hi Dave447,

To clear up any confusion, here is a quick explanation of what you would expect to see on vCenter in comparison to what you would see on the XtremIO GUI.

vCenter – The space utilization that you see on vCenters end should accurately reflect the amount of data that has been written (logically or physically) to the datastore before deduplication and compression.

XtremIO – The space utilization that you see on the XtremIO GUI should accurately reflect the amount of physical data consumed after deduplication and compression. Because of this, the vCenter display will almost always be a larger number.

Looking at the example above, we see that Vcenter has used 14599.18 GBs of data, while the XtremIO is only using 3.146 TBs of data. However if we take the physical data and multiply it by the data reduction ratio of 3.9, we will see a number much closer to the vCenter output.

At this time it is not possible for vCenter to correctly report available storage for thin provisioned volumes. This may have other implications if it was allowed as well.

As a quick example, there would need to be additional calculations and parameters specified to determine if it’s possible to vMotion a VM from one datastore to another. It may only consume 15 GBs on the XtremIO array due to the high levels of deduplication, however if we vMotion the 15 GB VM to another datastore that is not being de-duplicated (or even simply another array with different data), that VM could easily consume a significantly larger portion of storage.

With that said, there is one method which may work depending on how the XtremIO array is being used. By using VAAI-TP alerts, vCenter can report based on user defined thresholds of overall Storage array capacity. If we are using one big datastore (such as shown in the example above), we could instead create a much larger datastore, one that we ideally will never reach capacity on and monitor for the VAAI-TP alerts to notify us when the array is running out of physical capacity.

Here’s a link to the latest XtremIO user guide. Instructions on how to set the VAAI-TP limit on the array can be found on page 454. - https://support.emc.com/docu71055_XtremIO_XIOS_4.0.2_and_4.0.4_and_4.0.10_and_4.0.15_with_XMS_4.2.0_and_4.2.1_Storage_Array_User_Guide.pdf?language=en_US

Each volume will also need to have VAAI TP alerts enabled as well. More information on how to accomplish this can be found on page 488 of the User guide above.

Here is also a VMware blog that may provide some more detail. - http://blogs.vmware.com/kb/2012/12/out-of-space-conditions-for-thin-provisioned-array-luns.html

Let me know if any further clarification is needed.

Thanks,

Max Houde

Have any space reclamation techniques been employed to see if some of that space can be reduced to provision more VM's?

Cheers Max -

we are using one big datastore - we could instead create a much larger datastore ?

• there is no space available for this.
• How big do you go...

VAAI-TP is enable and set to don't limit..

Space reclamation - are you referring to the unmap feature - ?

i was looking at Cormac Hogans VAAI Thin Provisioning Block Reclaim/UNMAP In Action - VMware vSphere Blog

or something a little more automated http://www.virtuallyghetto.com/2014/09/want-to-issue-a-vaai-unmap-operation-using-the-vsphere-web-client.html

we are looking at migrating some vapps off to an nfs, but i would still like to get a proper representation of the available storage in the VC..

Hi Dave447,

Regarding the below questions:

- There is no space available for this

     A. Looking at the above screenshot showing the XtremIO use, we can see that the physical capacity consumed on the cluster is only 21% currently (79% free) / 3.146 TBs. For a true answer to how much storage space is available, the XtremIO GUI will need to be consulted.

         To add on, the volume capacity shown above is specifically what has been provisioned to hosts, and is entirely independent from storage used.

- How big do you go?

     A. This is a question that will be specific to your environment and what you are looking to accomplish. Typically we would want to limit them so that we lower the risk of running out of capacity unexpectedly on the array. As long as the physical space is monitored to ensure capacity doesn't run out, then the datastore size can be anything.

- Space Reclamation - are you referring to the unmap feature?

     A. Space reclamation I think is the non-OS specific term, but we are indeed referring to the unmap feature.

Let me know if any you have any questions or further clarification is needed.

Thanks,

Max Houde

Hi,

You will want to install a free plugin called VSI (https://support.emc.com/products/34010_VSI-for-VMware-vSphere-Web-Client).

This plugin gives you exactly what you are looking for: Ability to run or schedule space reclaim from vCenter, along with viewing of actual capacity used on the LUN (including data reduction) making up the Datastore.

Hi Mabela..

I have setup the VSI registered both vc & xio, but i don't see the option reclaim the storage ?

is there a guide?

Hi Dave447,

You can find the VSI Product Guide at: https://support.emc.com/docu82029_VSI-for-VMware-vSphere-Web-Client-7.1-Product-Guide.pdf?language=en_US

You can find info on space reclaim on page 61. You should also look into having VSI set the recommended best practice settings for you.

Cheers Mabela...

I didn't spot the the right click vsi menu.. cheers, I just need to implement the host recommendations, so have to do some shuffling to allow the reboot.Then i will schedule the space reclamation during the weekend.

Thanks

Dave.

Hi,

scheduled the space reclamation for the weekend,

enabled host recommended settings

looking through the logs  - esxcli storage vmfs unmap -l hpod_XIO_15TB -n 30000

storage is still showing the same availability

I ran the command from a host within the cluster..

esxcli storage vmfs unmap -u 5730a91f-6350e668-d98c-0025b56a0027 -n 30000

looking at the host  ==> hostd.log <==

Unmap: Async Unmapped 200 blocks from volume 5730a91f-6350e668-d98c-0025b56a0027

Unmap: Async Unmapped 200 blocks from volume 5730a91f-6350e668-d98c-0025b56a0027

Unmap: Async Unmapped 200 blocks from volume 5730a91f-6350e668-d98c-0025b56a0027

• -n|--reclaim-unit=number
  
  The number of VMFS blocks to UNMAP per iteration. This is an optional argument. If it is not specified, the command uses a default value of 200.

This is looks to be the default value..of 200.. not the -n setting?

Available storage is still the same...anything else i should be looking for

although the logical vlaue showing below is correct..

mabela  is this what you have?