SW v8 build 8730 VAAI on ESXi 6.0 U1B

[lohelle]

I have done some testing using latest Starwind and ESXi releases.
Tests:

Created LSFS datastore (dedupe) of 100GB and added to ESXi host.
I cloned 3 VMs from a template. Used space did not grow much/at all for the 2 latest clones.

Copied 10GB of files to the first VM. Allocated physical space increased 5-6 GB. I deleted the files + sdelete, and space was reclaimed.
I copied a 10GB file, then deleted it. And then I copied a different 10GB file. The used physical space usage did not increase much. This should mean that when the OS overwrites deleted blocks, SW deletes the deleted data from the dedupe storage. Great! Did not work so well before. After some sdelete, all space was reclaimed again.

I copied the same files to two VMs, and almost no physical space increase for the second one.
I deleted the files on both VM, and ran sdelete to reclaim the space (successful)
The space on the VMFS datastore was still used.

Then I tried the direct guest OS unmap feature from this article:
http://blog.purestorage.com/direct-gues ... ere-6-0-2/
I upgraded the VMs to HW version 11, and changed EnableBlockDelete to 1 under advanced settings, VMFS3.
I copied a 10GB file to one of the VMs and then deleted it. I used the builtin "optimize drives" feature of Windows Server 2012 R2 (rightclick drive, properties + tools).
This reduced the size of the VMDK. COOL!!
But it did not unmap to Starwind. I also tried "esxcli storage vmfs unmap -l datastorename", but still no go.

I checked other VAAI-features, and copy/zero features also seems to not work (checked esxtop after slow sdelete and slow creation of an eager zeroed file). Also reclaim/unmap after svmotion.

Actually, when using the optimize feature from the guest without zeroing the drive first left data in Starwind, even after migrating all VMs away from the datastore + esxcli unmap command. I was able to reclaim this by creating a large eager zeroed VMDK almost filling the datastore. It was very slow btw, as the mentioned zero-accelleration of VAAI did not work.

After all, the deduplication seems to work now! Great! Will test long term before implementing in production, but looks OK now. When VAAI is fixed (do not know if it is an ESXi or Starwind error), I think all would be great now! Hopefully VAAI unmap will work together with the direct guest unmap feature. This would remove the need to storage vmotion to shrink VMDK's, and also remove the need to sdelete to reclaim physical used data on the SAN.

edit: clean installed ESXi host, so no custom setup on the host.

[fbifido]

Thanks.

So LSFS dedup works ok. , it seems like ages.
but esxi VAAI does not.

Can you try esxi VAAI on a non-dedup lsfs volume?

Thanks again.

[lohelle]

VAAI zero works on non-dedupe thick. I have not tested other combinations yet.

[Tarass (Staff)]

Hi guys, thank you for your contribution to our community.

Some more useful information on the case could be found here: https://www.starwindsoftware.com/starwi ... s-properly

[lohelle]

Can you please confirm that this is a known issue? (VAAI + LSFS with deduplication). The zeroing is the most important feature for us, but accellerated copy yould also be great.
As mentioned, this works on thick devices.

[fbifido]

http://www.starwindsoftware.com/release-notes-build

Tarass, can you put this web link on your webpage menu, under support or products.
because I can't seem to find it unless I search the forum.

Thanks.

lohelle, the most important feature of VAAI, is all of it.

Thanks

[Tarass (Staff)]

fbifido, release notes are intended to be used by current customers. You can easily find them on customer latest build download page: https://www.starwindsoftware.com/customer-page

[lohelle]

lohelle, the most important feature of VAAI, is all of it.

Thanks

Actually, I don't agree here, as the other features mostly help on performance, but missing VAAI UNMAP/DELETE prevents the thin-provisioned volume from shrinking as it should/could.

[fbifido]

lohelle, the most important feature of VAAI, is all of it.

Thanks

Actually, I don't agree here, as the other features mostly help on performance, but missing VAAI UNMAP/DELETE prevents the thin-provisioned volume from shrinking as it should/could.

PERFORMACE, that's what LSFS was created for.
Does blender effect correction, rings a bell?
Step-by-Step it's getting their.

[anton (staff)]

You right. That's going to be implemented. I'll check within R&D what's the status there. AFAIK it was on a roadmap long time ago...

lohelle, the most important feature of VAAI, is all of it.

Thanks

Actually, I don't agree here, as the other features mostly help on performance, but missing VAAI UNMAP/DELETE prevents the thin-provisioned volume from shrinking as it should/could.

[Alex (staff)]

Yes, UNMAP functionality for LSFS is being tested now. We are planning to release it in March.