Wer in seiner VMware Infrastruktur auf SAN setzt wird vermutlich bereits auf das Thema SCSI Unmap bzw. VAAI UNMAP gestoßen sein. Hier noch mal ein kurzer Abriss.
SCSI Unmap – Worum geht es?
Wenn auf einem VMware ESXi SAN-Datastore Files gelöscht werden, wird der Speicherplatz aus ESXi Sicht wieder freigegeben. Dies bedeutet aber nicht, dass es auf dem unterliegenden Storage Array auch so aussieht.
Für das Storage Array ist dieser Speicherplatz weiter belegt und wird nicht wieder per Thin-Provisioning wieder freigegeben.
Nicht sehr effizient. Aber vor allem riskant bei einer hohen Überbuchung des Storage Arrays.
Wie kann der Speicher freigegeben werden?
Kurz gesagt, muss dem Storage Array mitgeteilt werden, dass der Speicher nicht mehr belegt wird und damit freigegeben werden kann.
Hierzu wird die VAAI Schnittstelle verwendet.
Ob das verwendete Storage und die eingesetzte Firmware diese Schnittstelle unterstützt, kann in der VMware HCL geprüft werden:

VMware HCL – SAN
Oder direkt auf der ESXCLI:

ESXCLI – Device Details
Mehr Details dazu in einem VMware Blog Beitrag von Cormac Hogan (@CormacJHogan).
Das genaue Vorgehen hat sich allerdings über einige ESXi Versionen hin verändert:
ESXi 5.0: Einführung mit automatischem VAAI UNMAP
ESXi 5.o Patch 2: Deaktivierung VAAI UNMAP, wegen massiven Problemen
ESXi 5.o Update 1: VAAI UNMAP manuell per vmkfstools wieder möglich
ESXi 5.5: VAAI UNMAP manuell per esxcli möglich
ESXi 6.0: VAAI UNMAP vom Gast aus möglich (Details)
SCSI Unmap – Das Script
Ich verwende hier die Möglichkeit per VMware PowerCLI esxcli Befehle aufzurufen.
Nötige Anpassungen
Diese beiden Parameter müssen an Ihre Umgebung angepasst werden:
$VIServer = „myvCenter.lab.lan„
$UNMAPs = @( („esx01.*„, „*Silber*„), („esx02.*„, „*Bronze*„))
$UNMAPs setzt sich wie folgt zusammen:
(„esx01.*“, „*Silber*“)
(ESXi Host auf dem der UNMAP Befehl durchgeführt werden soll, Datastore Wildcard)
Somit wird auf einem Host nach dem anderen für alle Datastores passend zur Wildcard der SCSI UNMAP durchgeführt.
PowerShell Code
GitHub Gist:
UNMAP im ESXi Log prüfen
Im hostd log befinden sich während des UNMAP folgende Einträge:
Unmap: Async Unmapped 200 blocks from volume xxxxxxxx-xxxxxxxx-xxxx-xxxxxxxx
Etwas aufbereitet, kann man schnell die bearbeitet LUNs (bzw. deren UUDs) aus dem Log exportieren.
~ # grep „Unmap:“ var/log/hostd.log | awk ‚{print $8}‘ | sort | uniq
531ecb5b-3717dccc-69ec-00215a9b0064
53831310-0c5ea9a5-f108-00215a9b00e2
UNMAP in ESXTOP prüfen
ESXTOP Auswahl
esxtop > „u“ > „f“
Auswahl für die Anzeige wie oben anpassen.
ESXTOP Statistik
Refresh Rate kann mit „s“ > „2“ reduziert werden,
Bekanntes Problem
Leider hat sich ein kleines Problem mit den esxcli Befehlen via PowerCLI aufgezeigt.
Wenn der esxcli Befehl länger als 30 Minuten läuft, bricht PowerCLI mit einem Timeout ab, der Befehl läuft jedoch im Hintergrund auf dem ESXi weiter.

esxcli Timeout
Zu dem Thema habe ich mich auch in der Community einer Diskussion angeschlossenen, sowie einen VMware Case geöffnet.
Leider geht der Case sehr schleppend vorwärts.
Wenn ähnliche Probleme vorhanden sind, würde ich mich über eine Rückmeldung freuen, eventuell können wir die Bearbeitung dann etwas beschleunigen.
Update zum Thema „WebOperationTimeout“:
Nach langem hin und her mit dem VMware Support hat sich nun ergeben, dass das maximale Timeout von 30 Minuten leider HardCoded ist.