みなさん、こんにちは。
今回は、最新のVMware Workstation Pro 25H2を、軽量LinuxとしておなじみのBodhi Linux 7.0.0で試していた時に遭遇した、かなり根深いトラブルの話を共有したいと思います。
結論から言うと、「設定ファイル（.vmx）の魔改造で物理的な制約を回避しようとして泥沼にハマり、結局は基本に立ち返って解決した」という、エンジニアあるあるな失敗談です。
もし同じように、Linuxホスト上で「メモリは足りているはずなのにVMが起動しない！」と頭を抱えている方がいたら、この記事が「諦め」への近道（あるいは解決への近道）になれば幸いです。
環境と起きた問題の再確認
まずは今回の実験環境です。
- ホストOS: Bodhi Linux 7.0.0
- 仮想化ソフト: VMware Workstation Pro 25H2
- ホストマシンの物理スペック:
- RAM: 16GB
- SSD空き容量: 約7.5GB（ここが最大のボトルネック）
やりたかったことは単純です。この環境で、メモリ8GBを割り当てた仮想マシン（VM）を起動したい、ただそれだけでした。
ホストのメモリは16GBあるので、8GBをVMに渡しても残り8GB。OSもBodhi Linuxなので余裕で動作します。計算上は何の問題もありません。 しかし、VMの電源ボタンを押した瞬間、無慈悲なエラーメッセージが表示されました。
「ディスクの空き容量が不足しているため、仮想マシンを起動できません」（エラー表示は英語ですので意訳です）
はい、知っています。SSDの空きが8GBを切っているのは知っていました。でも、「メモリ（RAM）で動かすんだから、ディスク容量なんて関係ないだろう？」 と、私は高をくくっていたのです。ここから長い戦いが始まりました。
第1回戦 – 伝家の宝刀「VMXファイル破損」の巻
VMware使いの方ならご存知かと思いますが、VMwareはデフォルトで、ゲストOSのメモリ内容をディスク上のファイル（.vmem）として書き出そうとします。これがディスク容量を食う原因です。
これを防ぎ、全てのメモリを物理RAM上に展開させるための有名な設定を、私は自信満々で、対象VMの .vmx ファイルに以下を追記しました。
mainMem.useNamedFile = "FALSE"
prefvmx.minVmMemPct = "100"
prefvmx.useRecommendedLockedMemSize = "TRUE"
「これでディスクへの書き込みはなくなり、メモリだけで動くはず。どうだ！」
……結果は、vmxファイルが壊れているとエラーをはき、VMを認識してくれなくなりました。
特に prefvmx. で始まる設定は、本来VMware Workstation全体のグローバル設定に書くべきものです。VMware 25H2では、これらの設定をローカルの .vmx に記述したことで、構成ファイル自体が不正な記述としてエラーを吐き、VMがインベントリから消えるという最悪の事態になりました。ネットで調べた情報ではこれで解決したという報告もあったのですが、最新バージョンではルールが厳格化されたようです。
第2回戦 – VMXファイルが壊れたからこそ思い出した /dev/shm の壁
究極のメモリロック設定を試みた結果、VMXファイルは完全に破損。絶望しかけたとき、私はふと、「ディスクを使わないなら、Linuxはどこにメモリをバックアップしようとするのか？」という基本に立ち返りました。
そう、Linux版のVMwareが目を付けるのは、共有メモリ領域である /dev/shm です。
しかし、この /dev/shm には「Linux特有の事情」があります。
ここで問題になるのが、Linuxのデフォルト仕様です。通常、/dev/shm のサイズ上限は 物理メモリの50% に設定されています。 私の環境はRAM 16GBなので、/dev/shm の上限は約8GB（実効値で約7.8GB程度）です。
- VMの要求: 8GB + 管理用オーバーヘッド（数百MB）
- 用意された場所: 約7.8GB
……足りていません。 「なるほど、まずはこれを拡張しないと！」と原因を特定した気になった私は、以下のコマンドで一時的に共有メモリ領域を拡張しました。
# /dev/shm を 10GB に無理やり拡張
sudo mount -o remount,size=10G /dev/shmさらに、VMwareが作業用の一時ファイルを作成する場所もここに向けるよう、.vmx に追記を行いました。
tmpDirectory = "/dev/shm"
workingDir = "/dev/shm"「これで容量チェックも RAMディスク（/dev/shm）を見に行くはず。今度こそ完璧だ！」
意気揚々と起動ボタンをクリック。しかし……。
「ディスクの空き容量を確保してください」
……嘘でしょう？ 一時ファイルもメモリに逃がし、そのメモリ領域も拡張しました。それでもVMwareは、頑なに「物理ディスク（SSD）の空き」を要求してくるのです。
第3回戦 – 禁断のパラメータ
「こうなったら意地でもディスクは空けないぞ」と謎の闘志に火がついた私は、ネットの海を彷徨い、より強力と思われるパラメータを見つけてきました。
mainMem.backing = "unnamed"これは「名前付きファイルを使わず、純粋な無名メモリ空間を使う」というような設定らしいのですが、これを .vmx に追記して起動したところ、無情にも……。
「ディスクの空き容量を確保してください」
ここでようやく、私の心は折れました。
結論 – VMware 25H2 は「物理ディスクの空き」を絶対視する
今回の検証でわかったことは、VMware Workstation 25H2（少なくともこのバージョン）においては、「設定でどうあがいても、物理ディスクの空き容量チェックは回避できない可能性が高い」ということです。
推測ですが、起動時のプレフライトチェック（事前確認）の段階で、以下の安全策が働いていると思われます。
- サスペンド領域の強制確保
- 設定でサスペンドを無効化しても、万が一のために「メモリと同サイズのディスク領域」が物理的に空いているかを確認している。
- クラッシュ時の安全性
- ホストのディスクが溢れてファイルシステムが破損するのを防ぐため、実際の書き込み先をRAMに変えていようが関係なく、「最低限のバッファ（VMメモリ量相当）」を要求する仕様になっている。
小手先の設定で誤魔化そうとしても、このハードルは越えられませんでした。
最終的な解決策
結局どうしたかというと……。
不要なISOファイルや古いログを削除して、SSDの空き容量を10GB確保しました。
するとどうでしょう。 あんなに苦労した .vmx の設定を全て消してデフォルトに戻しても、あっさりと、何事もなく起動しました。
教訓
「メモリがあるから大丈夫」は、現代のVMware（特に25H2以降）では通用しない場合があります。
- 設定ファイル (
.vmx) をいじり回して数時間を溶かすくらいなら、素直にディスクの掃除をして空き容量を作るのが、最も速くて確実な解決策です。 - 際どい設定は、最新バージョンでは構文エラーを引き起こし、最悪の場合VMの設定自体が読み込めなくなるリスクがあります。
Bodhi Linuxのような軽量環境でVMを動かす際は、メモリだけでなく、ディスク容量にも十分な余裕（VMのメモリサイズ + 数GB）を持っておくことを強くおすすめします。 私のような「設定の沼」にハマる人が、一人でも減ることを祈っています。
本日も最後までお読みいただきありがとうございました。
それでは、よい仮想化ライフを！
