I'm guessing you mean VMFS-3 here Rob. We never had a VMFS-4 :-) Yes, my understanding is that it is ok to run the vmkfstools reclaim command against a VMFS-3 datastore. The VMFS drivers which ship with 5.0 and later have the necessary VAAI TP extension code. You can verify that the UNMAPS are occurring with esxtop by looking at the DELETE field in the VAAI stats view: esxtop -> u (device view) -> f (select fields) -> O (VAAI Stats)

Hi Karl, Yes - my understanding is that this article is being reworked to include some of the guidelines in this blog post. Thanks for highlighting. Cormac

Hi Conor, In this case, presenting those LUNs directly to a VM would necessitate the use of RDMs, which do not require VMFS heap. Therefore you do not need to take VMFS heap into consideration in that case.

It could be one of the heartbeat datastores. in your vSphere HA cluster, edit the settings and see which datastores are being used for heartbeating. If this datastore is being used, change the settings to use another one.

These test were done on 5.0 Ray. When migrating a vRDM, if you choose to change the format, you can convert it to a VMDK.

Thank you Dario. I will investigate this with the KB team.

Sparrow, unfortunately much of the output will not make much sense without a deep understanding of VMFS metadata and layout, and that is not something I can share. The interesting part is the lock, and thank you for replying to Tia in the previous post - you are correct. If no-one has a lock on the file, then the host which runs the command will lock it which is why you see that list of zeros.

Thanks for the update Leslie.

Hi Greg, Nope - no impact. This feature/primitive is all about the ESXi host telling the array that these blocks, which I was using previously but I am no longer using, can be placed back on your free list (reclaimed). CBT is all about tracking which blocks have changed within a VMDK during a particular epoch. A scenario where they might co-exist is a Storage vMotion in 5.0. CBT is used to recursively keep track of blocks changing in a VM during the migration. Eventually the number of blocks which have changed during one of the recursive copies should be small enough in number to allow us to switch over to the VM on the destination. UNMAP can then be used to tell the array that the block which the VM occupied on the source datastore may now be reclaimed. Cormac

Hi Martin, Thanks for the feedback. Could I ask you to describe your use case for larger than 2TB VMDK? I'd appreciate it if you could add the comments to this post as we are actively tracking these requirements going forward. http://blogs.vmware.com/vsphere/2012/01/how-much-storage-can-i-present-to-a-virtual-machine.html Thank you Cormac

Derek, No - to the best of my knowledge, there are no requirements on the VM HW version.

Hi Johnny, That is true, if we were still using the bus walking method. If you have all your disks in a contiguous range starting from 0, then once we meet the first empty position, we stop scanning. However REPORT_LUNs avoids this as it requests a target SCSI layer to return a logical unit inventory (LUN list) to the initiator SCSI layer rather than querying each LUN individually. My understanding is that Disk.SupportSparseLUN doesn't play a role when REPORT_LUNs is used (and that is the default since ESX 2.x I think)

We are looking to handle this condition on single-target, single LUN arrays going forward. I can't say anymore about this right now except to keep following the blog.

Hi Adam, I don't see why not. If there were some constraints, these should be called out in the HCL footnotes.

Hey Gareth, We are working on it. Hopefully I'll have some details in and around the VMworld timeframe.

Sorry for the delayed repsonse vmitguy. I only just came across your question. The datastore browser does not use the internal VMkernel Data Mover or VAAI for that matter - it has its own API. Therefore what you observe is correct - datastore browser copy/paste operations will not use VAAI.