VHDXとは何か：実ディスク容量を食う仮想ディスク

容量喰いを追って、インストールした覚えのない何かが作った、.vhdx拡張子の30 GBファイルにたどり着いた。これは仮想ハードディスクだ。なぜこれほど巨大なのかという話は、その容量を安全に取り戻す話と表裏一体である。

VHDXとは何か、なぜ手元にあるのか

VHDXはWindowsの仮想ディスク形式――VHDの後継で、上限64 TB、電源断への耐性を備え――その中身は完全なファイルシステムで、Windowsは実ドライブのようにマウントする。意図的に作った覚えはないはずだ。WSL2はLinuxディストリビューションごとにext4.vhdxを持ち、Docker Desktopはその上にイメージを積み、Dev Driveは設計上マウントされたVHDXそのもので、Hyper-V仮想マシンや一部のバックアップツールも各自の分を追加する。ディスクを*.vhdxで検索すれば、1つでは済まないだろう。

WSL2ディストリビューション：%LOCALAPPDATA%\Packages\...\LocalState内のext4.vhdx ―― Linux内部のdfからは見えない
Docker Desktop：WSLデータディスクはイメージとコンテナレイヤーを引くたびに膨らむ
Dev Drive：本来あるべき場所にマウントされたVHDX ―― 判断する前に実際の使用量を確認
Hyper-V仮想マシン：既定のHyper-Vフォルダーか、VMを作った場所
イメージングツールのバックアップや「救援」イメージ ―― C:\直下にいる40 GBのサプライズ

肥大化の問題：拡大はしても縮小はしない

動的VHDXファイルはデータの書き込みで伸びるが、削除では縮まない。ゲストのファイルシステムでは空きとマークされる一方、ホスト側のファイルは最高水準のまま留まる。コンテナを引き、カーネルをビルドし、すべて削除したWSL2ディストリビューションが、実データ12 GBのまま60 GBのext4.vhdxを保持し続けることもある。Linuxは空だと言い、Windowsは巨大だと言い、どちらも正しい。これはリークではなく設計であり、ファイルそのものをコンパクト化しない限り、どんな「WSL内の掃除」もC:には1バイトも返さないという意味でもある。

容量を安全に取り戻すには

WSL2なら、まずwsl --shutdown。その後、最近のビルドではwsl --manage <distro> --set-sparse true、さもなければエクスポート／インポートの手順――.tarへエクスポートし、登録解除し、インポートし直せば、新しいvhdxは実データ寸法に揃う。Docker Desktopでは、データディスクを縮める前にDocker内部でイメージとボリュームを刈り込む。さもないと来週また同じファイルをコンパクトにすることになる。Hyper-V仮想マシンはVMを停止してからHyper-V マネージャー（またはOptimize-VHD -Path <file> -Mode Full）でコンパクト化し、Dev Driveには現実確認だけが必要だ。マウントして実際の使用量を見て、計画があるときだけリサイズする。そして唯一重要な規則：正体の分からない.vhdxは絶対に削除しない――まだ使っているVMやディストリビューションがそれを指しているなら、今そのディスク全体を消したことになる。