外部ストレージを使っている環境だと気づきませんでしたが、シンプロビジョニングで構成したゲストOSの領域をVAAIという機能で、領域開放してくれていたようです。それが、ローカルディスクの場合、シンプロビジョニングで構成したゲストOSでは、領域開放されずに、vmdkのサイズが増えていくという事象が発生しています。
そして、VMFS6でゲストOSからのunmapコマンドの要求で領域開放される条件があるようです。以下は公式サイトの情報です。
ゲスト OS からの容量の再利用の要求（VMware）
まず、ESXi は、ストレージ容量を再利用するためにゲスト OS から直接発行される unmap コマンドをサポートしていて、サポートのレベルおよび要件は、仮想マシンが存在するデータストアのタイプによって異なるとあります。これはゲストOSから直接とあるので、WindowsなどのOSから直接という意味だと思われます。
続いて、仮想マシン内部でストレージ容量が解放されるのは、たとえばシン仮想ディスクでファイルを削除したときなどとあります。
ここが重要ですね。
ゲスト OS は unmap コマンドを送信して、解放された容量について VMFS に通知します。ゲスト OS から送信された unmap コマンドにより、VMFS データストア内の容量が解放されます。このコマンドはその後、アレイが解放された容量のブロックを再利用できるようにアレイに渡されます。
ゲストOSはunmapコマンドを送信して、VMFSに通知。VMFSであることが条件でしょうか。そこまでは書かれていませんが。
VMFS6 仮想マシンの容量の再利用
そして、VMFS6 は、一般にゲスト OS から生成される容量の自動再利用の要求をサポートしており、これらの要求をアレイに渡すことができるそうです。
多くのゲスト OS は unmap コマンドを送信でき、追加の設定は必要ありません。自動マッピング解除をサポートしないゲスト OS では、ユーザーの介入が必要な場合もあります。VMFS6 の容量の自動再利用をサポートするゲスト OS の詳細については、ベンダーにお問い合わせください。
通常、ゲスト OS はアドバタイズするマッピング解除の精度に基づいて unmap コマンドを送信します。詳細については、ゲスト OS に付属するドキュメントを参照してください。
VMFS6 は、再利用する容量が 1 MB または 1 MB の倍数の場合のみ、ゲスト OS からのマッピング解除の要求を処理します。容量が 1 MB 未満、または 1 MB の倍数になっていない場合、マッピング解除の要求は処理されません。
これだけ見ると、VMFS6であれば自動unmapがローカルディスクでも使えそうですが実際に試してみないとわかりません。
VMFS5は、VMFS5 上のゲスト OS から生成される unmap コマンドを直接アレイに渡すことはできません。アレイのマッピング解除をトリガするには esxcli storage vmfs unmap コマンドを実行する必要があるとありますので、VMFS6と違い、自動で領域開放されないように見えますね。
VMFS5 仮想マシンの容量の再利用
通常、VMFS5 上のゲスト OS から生成される unmap コマンドを直接アレイに渡すことはできません。アレイのマッピング解除をトリガするには esxcli storage vmfs unmap コマンドを実行する必要があります。ただし、ごく一部のゲスト OS については、VMFS5 が容量の自動再利用の要求をサポートしています。
ゲスト OS からマッピング解除要求をアレイに送信するには、仮想マシンが次の前提条件を満たしている必要があります。
仮想マシンはシンプロビジョニングである必要があります。
仮想マシンのハードウェアはバージョン 11 (ESXi 6.0) 以降である必要があります。
詳細設定の EnableBlockDelete を 1 に設定する必要があります。
ゲスト OS が仮想ディスクをシンとして識別できる必要があります。
このあたりは実際に動作確認してみないとわからないですね。
