Hi, I'm new to this forum and hope that I have chosen the right group for my question 
We're running ESXi 5.5 on two hosts in a HA setup. A CentOS 6.5 Linux box serves as common NFS storage on its own storage network. We have a second CentOS 6.5 NFS server for backup on the general network.
I installed ghettoVCBg2 on a vMA, which actually uses vmkfstools to clone vmdks from our common NFS storage to the NFS backup server.
Everything seems to work ok, but there is one thing that puzzles me. I've spent some time browsing the Internet for an answer, but so far without luck. I'm not sure this is wrong behaviour or just the expected way it works.
Cloning vmdks between NFS servers works fine, regarding thin provision sizes. The target NFS server gets the thin provisioned size, which I checked with the "ls -l" and "du" commands.
It's the time it takes that is the problem, but only if it's read from a thin provisioned NFS storage. It spends the same time, as it would if it was thick provisioned. Even then, the received clone file gets thin provisioned.
I used vmkfstools directly to clone vmdks files manually for testing. "vmkfstools -d thin -i <nfs source> <local vmfs target>" spend the same as it were thick. While this is going on, I monitor constant high network traffic on the storage network the whole time, while the traffic on the general network stops at the expected time for the thin provisioned vmdk. Both NFS servers show the same behaviour.
Cloning the other way works perfectly. "vmkfstools -d thin -i <local vmfs source> <nfs target>". Both size and time as expected. Of course, "vmkfstools -d thin -i <local vmfs storage> <local vmfs storage on other ESXi>" works fine in both directions.
Is this the expected behaviour of vmkfstools, when working with NFS? We've many new thin provisioned VM's at the moment, so backup takes much longer time then it probably should.