深夜に仮想マシンが突然「ストライキ」を起こしたとき
よくあるシナリオ：深夜2時、締め切りに追われているか、VMware 上で Web サーバーの設定をしている最中。突然、停電が発生するか、Windows が勝手に再起動してアップデートを始めます。PC が再起動した後、作業を続けようと VMware を開くと、冷や水を浴びせられたような気分になります：「The virtual machine is in use」 または 「Taking ownership of this virtual machine failed」。
これはかなり痛い状況です！誰もこの仮想マシンを使っていないことは分かっているのに、VMware はロックされていると言い張ります。10台以上の ESXi ホストクラスターを運用し、数百台の仮想マシンを管理してきた経験から、私はこのような状況に日常的に遭遇しています。このエラーは実際には VMware の自己保護メカニズムに過ぎず、動作原理さえ分かっていれば、決して怖いものではありません。
ファイルロックの仕組み：なぜ仮想マシンは「自分自身をロック」するのか？
修復に取り掛かる前に、問題の根源を理解しましょう。VMware はデータの整合性を保つためにファイルロック（File Locking）メカニズムを使用しています。仮想マシン（VM）の電源を入れる（Power On）と、システムはその仮想マシンが格納されているディレクトリ内に .lck（Lock）拡張子のディレクトリまたはファイルを作成します。
これは VMware が「所有権」を主張する方法です。2つの異なる VMware プロセスが同じ仮想ディスクファイル（.vmdk）に同時にデータを書き込むのを防ぎます。この仕組みがなければ、データがめちゃくちゃに書き込まれ、一瞬で OS が破損（data corruption）してしまいます。
通常、仮想マシンを正しい手順でシャットダウン（Shutdown）すると、VMware はこれらの .lck ファイルを自動的にクリーンアップします。しかし、PC が突然電源落ちしたり、vmware-vmx.exe プロセスが予期せず終了したりすると、これらの「残骸」がそのまま残ってしまいます。再度開いたときに VMware は古いロックファイルを見つけ、仮想マシンがどこかで実行中であると勘違いしてアクセスを拒否するのです。
.lck ファイルを安全に処理する4つのステップ
仮想マシンを再インストールしたり、Windows を初期化したりするのはまだ早いです。以下の実践的な手順に沿って落ち着いて対処しましょう。
ステップ1：ハングアップしたプロセスのクリーンアップ
仮想マシンが実際には終了しておらず、エラープロセスとしてバックグラウンドで実行され続けている場合があります。Windows では、Ctrl + Shift + Esc を押してタスクマネージャー（Task Manager）を開きます。
- 「詳細」（Details）タブに切り替えます。
- 次のプロセスを探して終了させます：
vmware.exe、vmware-vmx.exe、vmware-authd.exe。 - 右クリックして「タスクの終了」（End Task）を選択し、ファイルを保持しているプロセスがないことを確認します。
Linux を使用している場合や ESXi ホストに SSH 接続している場合は、次の「強力な」コマンドを使用します：
# ハングアップしている仮想マシンの PID を探す
ps aux | grep vmx
# プロセスを強制終了する（PID を実際の数値に置き換えてください。例：kill -9 1234）
kill -9 <PID>ステップ2：「現場」を正確に特定する
仮想マシンがどこに保存されているか忘れた場合は、エラーメッセージに表示されているパスを確認してください。通常、これらのファイルは C:\Users\[ユーザー名]\Documents\Virtual Machines\... にあります。エクスプローラー（File Explorer）でそのディレクトリにアクセスします。
ステップ3：.lck ディレクトリの削除
仮想マシンのディレクトリに入ると、名前が .lck で終わるディレクトリがいくつか見つかります。例えば、Ubuntu-Dev という仮想マシンの場合、Ubuntu-Dev.vmdk.lck や Ubuntu-Dev.vmx.lck があります。
実行： 拡張子が .lck のディレクトリをすべて選択し、Shift + Delete を押して削除します。
重要な警告： 削除するのは拡張子が .lck のディレクトリ/ファイルのみです。.vmdk（仮想ディスク）、.vmx（構成ファイル）、.vmsd（スナップショット）ファイルには絶対に関わらないでください。誤って vmdk ファイルを削除すると、データが完全に失われ、復旧する方法はありません！
ステップ4：結果の確認
クリーンアップが終わったら、VMware Workstation を再度開きます。仮想マシンを起動してください。99% のケースで、何事もなかったかのようにスムーズに起動するはずです。
ESXi クラスター環境での秘策
本番（Production）環境では、vSphere Client からロックファイルを削除できないことがあります。これはホストのカーネル自体がロックを保持しているためです。このような場合、私は vmfsfilelockinfo コマンドを使って「犯人」（ロックを保持しているホストの MAC アドレス）を追跡します：
vmfsfilelockinfo -p /vmfs/volumes/DATASTORE_NAME/VM_NAME/VM_NAME.vmdkどのホストがファイルを保持しているか分かったら、そのホストの管理サービス（Management Service）を再起動するだけで解決します。実行中の他の仮想マシンには全く影響しません：
/etc/init.d/hostd restart
/etc/init.d/vpxa restartエラーを回避するための貴重な経験談
ウィンドウの「X」ボタンを押して「パワーオフ」（Power Off）を選択する（突然コンセントを抜くのと同じ）のではなく、ゲスト OS（Guest OS）の中からシャットダウンする習慣をつけましょう。これにより、VMware がファイル記述子（file descriptor）を閉じ、ロックファイルをきれいに削除するための十分な時間が確保されます。
あまり注目されませんが、もう一つの原因はディスク容量不足（Disk Full）です。物理ディスクがいっぱいになると、VMware は一時ファイルを書き込めず、プロセスのハングアップやロックの固着を招きます。システムが「息を継げる」ように、常に 10〜20GB 程度の空き容量を確保しておくようにしてください。
まとめ
「The virtual machine is in use」エラーは深刻そうに聞こえますが、実際には単なるメタデータの残骸に過ぎません。.lck ファイルの削除手順さえマスターすれば、仮想マシンを完全にコントロールできます。この「深夜作業」の経験が、皆さんのトラブルシューティングに役立つことを願っています。
