Over provisioning storage in my personal opinion isn't a good idea.  It's only useful when growing a volume isn't supported and you know you're getting additional storage 'soon'.   Which isn't the case with ESX v4 and above.   My thought would be create a new smaller volume and move VMs there and start removing the large over provisioned volumes.   Then you can be sure that you won't run out of space and have volumes go offline.  Eventually, you will run out of space.   You are correct, there's no way to make the ESX admins realize they don't have the space they think they have.   In the future EQL will support SCSI UNMAP to freed pages will go back to the free space pool as files are deleted.  Which will make thin provisioning a more useful feature.   (I.e. more free space for snapshot reserve or replication)   Regards, 
I am new to EqualLogic, but have a very good background in storage (multi-protocol SAN/NAS, particularly NetApp & EMC). That said, I see the settings for "Maximun In-Use Space" on a volume that is thin provisioned.  I am looking at a system that was already configured, and this is what they did: Now what happens is this (and if you ask me this is insane, if not stupid): VMWare administrator uses vSphere Client to review datastores and sees that "Datastore X" has 495GB of free space.  It is a 1TB datastore, and so naturally when they are asked to deploy new virtual machines they place the VMs in this datastore.  The reality is, there is only 5GB free (due to Max In-Use set at 50%).  The VMWare administrator creates VMs and the datastore is kicked offline by Dell.  Everyone panics, calls the storage administrator, who then raises the Max In-Use Space setting for the volume because the pool has plenty of free space (other volumes are using less than 50%). To me, the obvious thing to do here is to set "Max In-Use" to 100% of the volume.  The problem is when a previous storage administrator decided to over-commit the pool.  So now I get warnings about Max In-Use exceeds pool capacity (no duh). My understanding of designing thin provisioning does not include overcommitting the volumes.  In fact, all it should be is the sharing of all the volume white spaces.  By sharing this way, the 495GB in the volume I spoke of earlier actually belongs to ALL the volumes should they need it.  Having a "Max In-Use" setting that kicks a LUN volume offline seems backwards, in my opinion, and counter-acts any thin provisioning. So I am ready to hear the opinion on this....here is how I think it should have been done. Set the volume sizes to what you think you actually need.  Thin provision the volume, set Max-In Use to 100% (heck that setting should be able to go to OVER 100% to be true thin provisioning right?).  The goal of SAN is to never crowd a LUN....let the volumes auto-grow if they have to.  
Design Question: Max In-Use Best Practices