深夜3時の恐怖：ディスク容量の赤色アラート
インフラエンジニアやDevOps担当者なら、熟睡中にZabbixから「Disk Space Low（ディスク容量不足）」という Production環境のアラートを受け取った経験があるはずです。あの瞬間の感覚は、本当に…キツいものです。VMware ESXiにおいて、ストレージ管理は単に物理的なハードディスクを増設すれば済むという話ではありません。物理レイヤーから仮想化レイヤー（Datastore/VMDK）、そしてOSのパーティションに至るまでの一連の操作が必要になります。
新人の頃、2TBのデータベースサーバーのディスクをリサイズする際に手が震えたことを覚えています。誤ってデータを消してしまったり、顧客の仮想マシンをフリーズさせてしまったりするのが一番怖かったからです。その後、ProxmoxやHyper-Vなど多くのプラットフォームを渡り歩きましたが、やはりVMwareのストレージ管理は非常に厳格だと感じます。しかし、その本質さえ掴めば、すべてをコントロール下に置くことができます。
コア概念：Datastore（データストア）とVirtual Disk（仮想ディスク/VMDK）
コマンドを叩く前に、vSphere Clientでの操作で混乱しないよう、いくつかの概念を整理しておきましょう。
1. Datastoreとは何か？
Datastoreは、巨大な倉庫のようなものだと考えてください。ローカルディスク、RAIDアレイ、SAN/NASなど、基盤となるハードウェア의複雑さを隠蔽してくれます。VMwareは **VMFS (Virtual Machine File System)** という独自のファイルシステム形式を採用しています。これは、複数のホストが競合することなく、同時に同じディスクに対して読み書きを行えるようにするための特殊なフォーマットです。
2. Virtual Disk (VMDK) — 仮想マシンの「切り札」
これはゲストOSが認識する仮想ハードディスクファイルです。覚えておくべき3つの主要な形式があります。
- Thin Provisioning（シンプロビジョニング）: 「使った分だけ」確保する形式です。初期のVMDKファイルは非常に軽量です。ただし、500GBを割り当てても実際のDatastoreに100GBしか空きがない場合、その閾値を超えた瞬間に仮想マシンはダウンしてしまいます。
- Thick Provision Lazy Zeroed（シックプロビジョニング：レイジーゼロ）: 指定した全容量を即座に確保します。物理ディスク上の古いデータは、仮想マシンが初めて書き込みを行う際にのみ消去されます。作成は早いですが、初回の書き込みパフォーマンスはわずかに低下します。
- Thick Provision Eager Zeroed（シックプロビジョニング：イージーゼロ）: 最も高性能ですが、作成に最も時間がかかります。作成時に古いデータを完全に消去し、領域を占有します。SQL Serverなどの高いI/O（5000 IOPS以上）を必要とするアプリケーションでは、この選択が必須となります。
実践：ストレージ容量を根本から拡張する
サーバーに1TBのSSDを増設し、Ubuntuで動作しているWebサーバーの容量を増やしたいと仮定しましょう。プロセスは大きく分けて3つのステップです。
ステップ1：Datastoreの拡張（物理レイヤー）
ディスクを接続後、**Storage > Datastores > Increase capacity** に進みます。2つの選択肢が表示されます。
- Add extent: 新しいディスク（新しいLUN）を既存のDatastoreに統合します。この方法は少しリスクがあり、どちらか一方のディスクが故障するとDatastore全体が破損します。
- Expand existing extent: 物理RAIDアレイをリサイズした場合は、こちらを選択して新しく増えた空き容量をすべて取り込みます。
CLIで確認する場合は、ESXiにSSH接続して以下のコマンドを使用します：
# ストレージデバイスのリストを表示
esxcli storage core device list
# Datastoreの実際の容量を確認
vmkfstools -P /vmfs/volumes/DATASTORE_NAMEステップ2：Virtual Disk (VMDK) の拡張
倉庫が広くなったら、次はVMに「肉」を分け与えます。**Edit Settings** から **Hard Disk** 項目を探し、新しい数値を入力します。例：100GBから250GBへ。
警告： 仮想マシンに Snapshot が存在する場合、容量変更ボタンはグレーアウトされます。リサイズする前に、すべてのSnapshotを削除する必要があります。無理に操作しようとしないでください。VMDKファイルが破損すると修復不可能です。
コマンドでスマートに行いたい場合：
# VMDKファイルを一気に250GBまで増量
vmkfstools -X 250G /vmfs/volumes/DATA_01/WebSrv/WebSrv.vmdkステップ3：OSに新しい容量を認識させる
仮想マシンはハードディスクが大きくなったことを認識していますが、内部のパーティションはまだ変わっていません。Windowsの場合は、diskmgmt.msc を開いて **Extend Volume** を選択するだけです。Linux (LVM) の場合は、以下の「魔法の」コマンドセットを実行してください：
# 1. 新しい容量を認識させるためにディスクをスキャン
echo 1 > /sys/class/block/sda/device/rescan
# 2. Physical Volumeをリサイズ（パーティションがsda3の場合）
pvresize /dev/sda3
# 3. Logical Volume (LV) を空き容量100%分拡張
lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
# 4. 最後にファイルシステムのリサイズを確定
# EXT4の場合: resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
# XFSの場合: xfs_growfs /実戦から得た教訓
何度も「痛い目」に遭った結果、私はいくつかの鉄則を導き出しました：
1. 80/20の法則： Datastoreの容量を80%以上使わないようにしてください。100%に達すると、ESXiはすべての仮想マシンを「フリーズ（suspend）」させます。その状態になると、ファイルを削除するためにマシンを起動することすらできなくなります。
2. UNMAPの秘策： SSDとThin Provisioningを使用している場合、VM内でファイルを削除しても、Datastore上の容量はすぐには減りません。ESXi 6.7以降では、以下のコマンドを使って空き容量を回収しましょう：
esxcli storage vmfs unmap -l MyDatastore3. 厚遇しすぎない： 多くの人が Thick Eager Zeroed を神格化しがちです。しかし実際には、一般的なWebサーバーであれば、Thin Provisioning を使うことでディスク購入コストを大幅に節約でき、パフォーマンスもそれほど落ちません。
結論
ストレージ管理は、コストとパフォーマンスのバランスをどう取るかという問題です。教条主義的にならず、アプリケーションの実際の負荷に基づいて適切なディスク形式を選択してください。最も重要なのは、深夜にアラートを受け取らなくて済むよう、優れた監視システムを構築しておくことです。
この共有が、VMwareでの「コマンド捌き」に自信を持つ助けになれば幸いです。もしディスクに関して難しいケースに直面したら、下のコメント欄に残してくださいね！
