REVISION, I didn’t quite understand this, luckily some people at the dell equallogic conference filled me in

This was a bit unintuitive to me so I thought I would put it out there. So, say you have a volume of 500 GB with thin provisioning enabled. Now, let’s say that you cloned a production 250 GB VM onto this volume. Now you have 250 GB in use and 250 GB free. Well now lets say you don’t need that VM anymore and you want a fresher copy of your production VM, so inside VSphere you right click on the VM and go delete from disk. Next, you clone your production VM onto your original 500 GB volume and BAM you just filled that volume! (And potentially put the volume into offline mode)

I thought it was permanently filling the space… but that would be ludicrous. Really it is very similar to what would happen if you didn’t quick format a thin provisioned volume. It would go ahead and use all of the space, thereby rendering the thin provisioning null and void. When you thin provision it draws a line in the sand, when you go past that line it draws another line farther out but even if you delete some files you can never go back to the previous line (this would be re thining the partition) eventually when the OS and the SAN support it, it should be possible to re thin a volume. The only way to reclaim this ‘used’ space is to move the data to another thin provisioned volume thereby starting the process over again.

What I think happened in my case is that the delete of the previous VM had not completed so when cloning the new one onto the partition it wasn’t writing to the beginning (now open) part of the volume and/or I hit a bug??

In reality this doesn’t turn out to be that big of an issue…. whew

What happened? This is the answer from EqualLogic support

The answer lies in the SCSI protocol.  As you know, our SAN is just a really big SCSI drive, for all that the server knows. It doesn’t know that the SAN is off on the network, and that the iSCSI initiator intercepts commands to/from the OS and redirects them over to us.
Unfortunately, the is no ‘delete’ command in the SCSI protocol. The server changes the File Table on one of the blocks of storage we’ve set aside for it the blocks it no longer needs, effectively deleting the data. But it never actually sends us a command ‘delete block 346135.’
Since we’re block storage, we are agnostic to the data stored on our blocks of disk space. The volume could be NTFS, or VMDK, we don’t know. So we dutifully mark any used blocks as dirty, and that’s how they stay, until the volume is deleted, or the server again writes over that block.
The server has the file table. So it knows where the blocks are, and which are used or not. When it reports that only 25GB of the 100GB volume are in use, you can believe it. When we say that 75GB of the 100GB are dirty, then you can believe us that at some point in time, data was written to all 75GB of space.
If you need to recover some of that space, then you will need to move the data off, delete the volume, and create a new, smaller volume. It’s the only way to recover dirty, yet un-used, space.

More discussions here http://communities.vmware.com/thread/255173