Presenting virtual harddisks as thin provisioned to the Guest OS

[andreaspa]

Hi,

I know that Hyper-V tells the guest OS that the disk is thin provisioned, so that the guest can send TRIM-commands to the hypervisor and have the underlying storage system reclaim this space.

Do you know if/when VMware will implement a similar feature? The only way to free up unused space at the storage array level now seems to be running SDelete.exe so the array catches all the zeroes and can free up that space.

Any suggestions on how to do this better? Scheduling SDelete.exe in all VMs doesn't seem like a good idea in the long run..

[JarryG]

Although I could not find exact answer concerning esxi & trim, I suppose trim is not supported on vmfs5. Reason is simple: it is not worth the effort to implement it, because even if it was supported, it would not work in the most real-world scenarios, when there is another abstraction layer between filesystem and storage (i.e. raid-array, network-storage, etc), which (as of now) do not support trim. But that is not big issue, because ssds today do not rely solely on os-triggered trim, they use much more "inteligent" garbage collection routines.

Concerning SDelete.exe, I do not recommend to use it on ssd, because it actually does not work as expected. You can never be sure this "secure" overwriting works, because there is some over-provisioning space on every ssd used for wear-leveling, and ssd-controller itself decides which cells it overwrites. SDelete might think it is overwriting particular empty sector if the filesystem, but in reality it might be just writing to completely different sector. Even if you just formated your filesystem and wrote it completely full with zeros till the last sector, there still might remain previous data. It is fair to say that "sectors" do not have any practical meaning with ssd.

The only thing I can recommend with ssd to keep it healthy is to guarantee its total over-provisioning is sufficiently high, about 20%. Then ssd-controller has enough space to do wear-leveling, and performance does not drop.

[andreaspa]

JarryG wrote:

Although I could not find exact answer concerning esxi & trim, I suppose trim is not supported on vmfs5. Reason is simple: it is not worth the effort to implement it, because even if it was supported, it would not work in the most real-world scenarios, when there is another abstraction layer between filesystem and storage (i.e. raid-array, network-storage, etc), which (as of now) do not support trim. But that is not big issue, because ssds today do not rely solely on os-triggered trim, they use much more "inteligent" garbage collection routines.

Concerning SDelete.exe, I do not recommend to use it on ssd, because it actually does not work as expected. You can never be sure this "secure" overwriting works, because there is some over-provisioning space on every ssd used for wear-leveling, and ssd-controller itself decides which cells it overwrites. SDelete might think it is overwriting particular empty sector if the filesystem, but in reality it might be just writing to completely different sector. Even if you just formated your filesystem and wrote it completely full with zeros till the last sector, there still might remain previous data. It is fair to say that "sectors" do not have any practical meaning with ssd.

The only thing I can recommend with ssd to keep it healthy is to guarantee its total over-provisioning is sufficiently high, about 20%. Then ssd-controller has enough space to do wear-leveling, and performance does not drop.

TRIM is supported on VMFS5 via esxcli, it's simply called UNMAP and must be ran manually for each VMFS-volume you have (afaik).

I notice now that I could have been much clearer in my original post, apologies for that. I am primarily looking at this from a 3PAR and Dell Compellent perspective. HP recommends running SDelete.exe in the VM if you have freed up space inside of it, that way the storage array gets notified that there is blocks that are filled with zeroes and the array can reclaim those blocks. I am unsure how Compellent handles this at the moment. The idea was to maximize the free space

I hope that VMware in the future will have really dynamic VMDK-files, just like in Hyper-V.