Thats normal you are saving VMDK Files on this NFS Datastore these files are unique for every VM.

Dedup only works hash based over complete files.

So nothing within VMDK files can be deduped?

Dont take this the wrong way but right now it seems that those functions I payd extra to get Thin and Dedupe doesent work as i run VMWare.
As a network storage the VMXe3100 is eating up alot of expensive network ports

Then why pay more for a EMC product rather than say a HP P2000?
The blue LEDs?

Is there any way to actually dedupe the files contained within VMWare files like using paravirtulized disks?

I'm stuck with the same issue.  During the sales process we let the technical rep know that we would be using NFS for vSphere storage and the dedupe was one of the buying points.  We run a ton of virutal machines where 50-70% of the data is identical and static.  

I set up a test environment to check the functionality of the array and ran into the same problem as you.  I'm more than a little disappointed because this array will have nothing but vmdk files so what we payed for dedupe is wasted along with losing at least 25% of the capacity I planned.

Yes VNXe can not dedup files inside a VMDK.

The only feature that is working in your setup is compression.

You can save space with dedup when you think about to migrate your file servers to the VNXe file server.

Then you can use Dedup for your file shares.

The ability to consolidate your file servers and storage on the VNXe is the main reason for the price difference.

Also its easy to built a HA environment for file and block with 2 VNXe systems.

Why is this the case?  It is a technical issue or a feature the only spending five figures doesn't buy you?

to confirm what others are saying...dedup on vnxe is file based and geared toward fileshares.

data must be static for at least 30 days on a fileshare for dedup to do its thing...

it would of been nice if the vnxe had of implemented block based dedup, and then the contents of VMDK's would of been covered.

On a 13TB archive fileshare filled to 95% with files we acheived a dedup/compression saving of 15%. Would be inetresting in hearing what others are getting.

Its a technical problem from file based dedup. You can manipulate the content of an VMKD file it would get corrupt.

If there would be a Block Compression it would be possible but for that much more CPU Power is needed.

There is also a White Paper available that answers many questions.

https://support1.emc.com/docu35603_White-Paper:-EMC-VNXe-File-Deduplication-and-Compression.pdf

Its sad that your sales representative doesn't know this dependencies but its not a misstake from the VNXe System.

Is it possible to licence upgrade to block dedupe on a VNXe3100 platform?

Block dedupe is not supported on the VNXe platforms at this time.

I seem to recall there was a param on Celerra to get around ignoring files that had changed <30 days.   Does this exist on the VNXe?  With that, it would be possible to at least get some compression savings on active (but low I/O) VM's.