vSphere 6, VVOL and Unmap

Hello,

Unmap for VVols is a feature we’ve not implemented in the current release, however we very much understand the importance of this functionality and it is planned for a future firmware release.

 Unmap with non VVOLs volume types is supported.

Regards,

Don

I'm seeing the same behavior as reported by phouten.

We are not using VVOLs, but standard VMFS volumes.  We are Thin (vmdks) on Thin (EQL volumes).

Post upgrade to VM Hardware 11, the OS does see the drives as thin provisioned, but optimizing them does not shrink them.

Hello Evan,

That's a much different issue.  With VMFS Datastores the Virtual Disks are files.  So only space deleted by the ESXi node, which controls the filesystem can do the UNMAP.  VMware does not support automatic space reclaim.   You have to periodically run the UNMAP command at the ESXi node itself.

Please see this VMware KB for more info on how to run ESXCLI to do the UNMAP/Reclaim process.

kb.vmware.com/.../search.do;cmd=displayKC&externalId=2057513

Regards,

Don

Hi Donald,

With the new vSphere 6 release the unmap feature should be working automatically in VMFS and VVOL volumes if you enable the VMFS3.Blockdelete according to Cormac Hogans post. The manual option from the cli was already available in earlier releases.

Is there already a new release scheduled for the Equallogic firmware which support unmap in VVOL?

Kind regards,

Patrick

Hello,

I am not sure that it's a tested feature.  It doesn't appear in any of the certification requirements I've seen.

Reclaim using the esxcli should work, at least as a test.  The array only responds to the UNMAP command sent by the initiator.  For non VVOLs if we receive it on a non replicated volume (SYNC or ASYNC) then it will unmap those blocks.   If it works at the CLI, but not once the feature has been enabled, they should open a support case with their VMware support provider.

Support for UNMAP with VVOLs is scheduled for a future release is all that I can say at this time.

Regards,

Don

Donald,

Yes, I know about the CLI unmap command, we've had it scripted and been using it since it was supported (and ran into one of the initial issues with it on EQL - it didn't work on upgraded VMFS datastores, we had to re-create them with VMFS 5).  

As phouten says, we are discussing the automatic passthrough of unmap commands enabled by turning on VMF3.BlockDelete, which is supposed to work in vSphere  6.

It would be nice to get some EQL eyes on this, as this is a VMWare feature that should be supported.  

It sounds like you are telling us to contact support - great - whose support?  VMWare or EQL?  Is this something that isn't supported on the EQL side, or is it a VMWare issue?  It seems that we'd be better off if you could at least find that out for us, so who know who to bother.

Hello,

I do understand what you are trying to accomplish. EQL supports UNMAP on non replicated, standard volumes.  If  the array receives the UNMAP command for LBA X  we will unallocated that block. If the result of the UNMAP command(s) completely unallocates a 15MB page on the array, that 15MB will be returned to free space if the volume is thin provisioned, or on thick provisioned volume show a reduced amount of in-use space.    It's up to the OS controlling the filesystem to send these commands.  The array is completely passive in this process.

So if you run it at the CLI and it works, but can't do it the VM side after making the appropriate changes to ESXi and VM, then the issue likely is on the VMware side.  It may require opening a case with both VMware and Dell.  

Regards,

Don

Something interesting that I noticed from the blog post.  He references the following VM KB.

http://kb.vmware.com/kb/2112333

Which has this info:

In non-VVols environments, a LUN on the ESXi host can be used as an RDM, VMFS, VMFS-L, VFFS, and so on. With VMFS, for example, the UNMAP command from a guest OS cannot be passed directly to the array and would need a manual command to trigger UNMAP for the array. How UNMAP is handled in non-VVols cases is not covered in this article.

Solution

On VVols-backed VMs, if a guest OS issues the UNMAP command, the command can be sent directly to the VVols array for handling. This, however, depends on the type of the guest OS and on the hardware version of a particular VM.

For example, Windows 2012 Server VMs that run on vSphere 6.0 integrated with VVols storage can generate UNMAP commands. Some guest OSes that support unmapping of blocks, such as Linux-based systems, do not generate UNMAP commands on virtual disks in vSphere 6.0. This occurs because the level of SCSI support for ESXi 6.0 virtual disks is SCSI-2, while Linux expects 5 or higher for SPC-4 standard. This limitation prevents generation of UNMAP commands until the virtual disks are able to claim support for at least SPC-4 SCSI commands.

To support UNMAP automatically, the VMs that run in VVols environment must be of hardware version 11 or above.

I'm still researching this on the EQL side. 

 Don

Donald,

Another post about unmap on a VMFS volume:

itzikr.wordpress.com/.../vsphere-6-guest-unmap-support-or-the-case-for-sparse-se-part-2

There are now numerous post's and blog's about this new feature of vSphere 6. Unfortunately it's never on Dell hardware...

Greetz, Patrick

Hi Patrick,

Thanks. If the storage receives the UNMAP command EQL will respond to it on a supported volume.

Did you also see the limitations to it in that article?

=========================================================================

it’s not perfect, there are many cases where this will not work:

◾unmap of deleted blocks with in VMFS (i.e vmdk deletion, swap file deletion etc), for this you can use the EMC VSI plugin.

◾Smaller unmap granularity. With existing VMFS version, the minimum unmap granularity is 1MB.

◾Automatic UNMAP for support for windows version less than Windows 8 / server 2012 (no linux support)

◾the device at the VM level (the drive) must be configured as “thin”, not “eager zeroed thick” or “lazy zeroed thick”

==============================================================================

So if you delete a VM or VMDK, or storage vMotion it to another Datastore, this new feature won't reclaim that space.  So the need for the CLI UNMAP process remains.

There also remains a larger issue IMO about using thin provisioned VMDKs.  A very real impact in write performance compared to eager zero'd VMDKs.   There are extra commands required for growing TP VMDKs and then zeroing out the blocks before the data can be written to it.   The is seen especially when doing a storage vMotion or deploy from template.    This is another of the advantages of VVOLs by the way.

Don

Hi Donald,

Is there already any news on implementing the unmap option from the guest os (Windows 2012R2)?

Kind regards,

Patrick

Hello Patrick,

Not as of yet.  There is a joint effort between Dell and VMware to resolve how UNMAP is being handled with VVOLs for all OS's that support it, not just Windows 2012R2.

Here's some info on how UNMAP is being handled by VMware.

blogs.vmware.com/.../vsphere-virtual-volumes-interoperability-vaai-apis-vs-vvols

KB article: How Virtual Volumes and UNMAP primitive interact?

kb.vmware.com/.../search.do;cmd=displayKC&externalId=2112333

To support UNMAP automatically, the VMs that run in VVols environment must be of hardware version 11 or above.

Regards,

Don

Hi Donald,

We are using windows 2012R2 and HW version 11... I would really like if this option become available soon :-)

Is there a document from Dell which explaines all VVOL features that are available or not for the Equallogic users? (Such document was available for the VAAI option)

Kind regards,

Patrick van Houten

Hi Donald,

Any update on the currently available options in VVOL?

Kind regards,

Patrick

Hello Patrick,

Sorry, but I have not found anything like that.  UNMAP is the only feature I am aware of that's not enabled. A future version of EQL firmware is expected to re-enable this feature.

Regards,

Don