VMFS ボリューム上でロックされている仮想ディスクのトラブルシューティング
1 - 詳細をログに書き込む
スナップショット操作とパワーオン操作は、/vmfs/volumes/<vm-datastore>/<vm-name>/vmware.log ファイル(仮想マシンがすでにパワーオンされている場合のみスナップショット)に書き込まれます。
統合の問題があって仮想マシンがパワーオンされている場合は、問題のトラブルシューティングを支援するため、統合タスクをトリガーして、新しい一連のログ エントリを書き込みます。
仮想マシンのパワーオンに失敗した場合は、この項目と III (a) をスキップします。
2 - ディスクのロックを特定するには、ディスク上で想定されるすべてのロックをクリアする必要があります。
パワーオン状態の仮想マシンは、所有する ESXi ホストを通して排他ロックによって保護されています。該当する場合は、仮想マシンの電源を切ります。
残りのロックはすべて、想定外のものとみなされ、調査が必要です。
A - ロックされているファイルを見つける
- SSH を使用して、該当する仮想マシンを実行している ESXi ホストに root としてログインします。/vmfs/volumes/vm-datastore/vm-name/ に移動します。
- /var/log/vmware.log ファイルを開き、最後の統合/パワーオン プロセスを確認します。
- ロックの問題でアクセスできない、少なくとも 1 つのファイルについてのエラーか警告があるはずです。
- 問題の種類に応じて、ログ メッセージは異なります。
問題のメッセージを見つけるのに問題がある場合は、この部分をスキップして III(b) に進みます。
B - ロックされているファイル (b) を見つける
- 仮想マシンのディレクトリに移動し、コマンド vmkfstools を対応する記述子ファイルに対して実行します。
- コマンド vmkfstools -qv10 を、現在マウントされているスナップショットに対して実行します(どれがマウントされているかは、vCenter Server の仮想マシン設定でディスクを確認します)。
- 仮想ディスクが複数ある場合は、次のコマンドを、現在マウントされている各ディスクのスナップショットに対して実行します。
例:
vmkfstools -qv10 vm-disk-000009.vmdk
これにより、選択したスナップショットからフラット ディスクへの実際のスナップショット チェーンが表示されます。
注:この出力でスナップショット チェーン エラーが返された場合、統合の問題は、スナップショットのチェーンが壊れているために発生しています。修正方法については、対応するナレッジ ベースの記事を参照してください。
これらのファイルを書き留めてください。さらに確認する必要があります。ログで見つかったファイル(手順 III (a))は、このリストの一部に含まれるはずです。
スナップショットがない場合は、フラット ディスクのロックのみを確認する必要があります。そのため、上記の部分はスキップできます。次に、コマンド vmkfstools -D を、ロックを確認するログで見つかったすべてのファイルに対して使用します。
手順 III をスキップした場合は、 vmkfstools -qv10 で返されたすべてのファイルに対して次のコマンドを実行します。
例:
vmkfstools -D vm-disk-flat.vmdk
vmkfstools -D vm-disk-000001-delta.vmdk
これにより、ロックしている ESXi ホストを特定する MAC アドレスが(UUID の一部として)返されます。詳細については、「
ファイルがロックされているために仮想マシンがパワーオンされない (1033280)」を参照してください。
例:
gen 2021, mode 1, owner 543d375e-1db58166-0bd6-002219a74751 mtime 691807
mode 1 は、排他的な読み取り/書き込みロックを示しています(例:仮想マシンのパワーオン)
この場合、次のコマンドを各 ESXi ホストに対して実行し、仮想ディスクがパワーオン状態の別の仮想マシンに接続されているか、この仮想マシンがパワーオフされているかを確認します。
grep -i <diskname> /vmfs/volumes/*/*/*.vmx
mode 2 または RO Owner は、おそらくディスクがバックアップ アプライアンスにまだ接続されていることが原因である読み取り専用ロックを示しています。これが読み取り/書き込みアクセスを必要とする最新のスナップショットでない限り、既存の読み取り専用ロックは別の読み取り専用ロックと併存できるため、これによりパワーオンが妨げられることはありません。ただし、統合のプロセス中は書き込みアクセスが必要なため、統合は妨げられます。
次のコマンドを実行し、現在の ESXi ホストの MAC アドレスを表示します。
esxcfg-nics -l
問題の MAC アドレスがこの ESXi ホストからのものでない場合は、別のホストを確認します(
[vCenter Server] >
[構成] >
[ネットワーク アダプタ])
注:MAC アドレスはロックを引き起こしているホストを特定するだけで、実際の NIC への参照と間違うことはありません。そのため、この NIC がネットワークに接続されていなくても、ロックをかけている vmnic0 を見つけることができます。
バックアップ ソリューションを使用しており、このアプライアンスが上記のプロセスで見つけた ESXi ホストで実行されている場合は、電源を切るか、その構成から仮想ディスクを削除するか、またはその両方を行います。
統合/パワーオンできるはずです。
C - ロックをかけているプロセス/サービスを見つける
上記のトラブルシューティングで問題が解決されない場合は、ホットアドまたは同じディスクにアクセスする別の実行中の仮想マシンによって引き起こされる、別の種類のロックが存在する可能性があります。
次の手順を実行します。
- 最後の手順で返された MAC アドレスで特定される ESXi ホストに接続します。
- 次のコマンドを実行して、ロックを扱っているプロセスを見つけます。
ps | grep -i vm-name
- このコマンドで空でない出力が返された場合は、ディスクをロックしているプロセスがあります。そうでない場合は、手順 b にスキップします。
- 上記の出力で、vmm0 を見つけ、ID を書き留めます(行の先頭)。次のコマンドを実行します。
esxcli vm process list | grep -i <ID> -B1
これにより、プロセス ID に対応する仮想マシンが返されます。この仮想マシンがロックをかけています。
- この仮想マシンからディスクを削除するか、仮想マシンの電源を切ります。統合/パワーオンできるはずです。
- 次のコマンドを実行して、ロックを扱っているタスク/サービスを見つけます。
lsof | grep -i <vm-name>
これにより出力が返された場合は、ディスクをロックしているサービスかタスクがあります。これは、仮想マシンが登録されているのと同じ ESXi ホストでのみ発生します。
- 次のコマンドを実行すると、タスクに関する詳細情報を得られます。
vim-cmd vmsvc/getallvms | grep -i vm-name
- 出力で得られた ID を書き留め(行の先頭の数字)、次のコマンドを実行します。
vim-cmd vmsvc/get.tasklist <ID>
出力は次のようになります。
vim-cmd vmsvc/get.tasklist 109
(ManagedObjectReference) [
'vim.Task:haTask-109-vim.vm.Snapshot.remove-92744898'
]
「:」の後のタスク ID を書き留めます。
- 次のコマンドを実行します。
vim-cmd vimsvc/task_info <Task ID>
例:
vim-cmd vimsvc/task_info haTask-109-vim.vm.Snapshot.remove-92744898
これにより、タスクを特定するのに役立つ情報(短縮形)が出力されます。
task = 'vim.Task:haTask-109-vim.vm.Snapshot.remove-92744898',
state = "running",
cancelled = false,
cancelable = true,
progress = 75,
startTime = "2014-12-06T03:47:26.30322Z",
- この ESXi ホストの管理エージェントを再起動し、サービス/タスクをクリアします。詳細については、「ESX および ESXi ホストでの管理エージェントの再起動 (1037058)」を参照してください。
注:不要なフェイルオーバーを回避するため、最初に HA Host Monitoring を無効にします。
数秒後に、コマンド get.tasklist (上記参照)をもう一度実行します。空の出力が返されるはずです。統合/パワーオンできるはずです。
場合により、このプロセスではさらにクリーンアップの作業が必要になります。
- 最初のコマンドをもう一度実行して仮想マシンが引き続き登録されていることを確認します(または vCenter で状態が invalid になっていることを確認します)。
vim-cmd vmsvc/getallvms | grep <ID>
Skipping invalid VM '109'
注:invalid VM 出力を得ていない場合は、このセクションの残りの部分をスキップします。
- この出力は競合があることを示しています。仮想マシンが引き続き実行していても ID が割り当てられていない可能性があります。次のコマンドを実行します。
esxcli vm process list | grep -i <vm-name> -B5
出力は、仮想マシンのリストを示しています。この仮想マシンのワールド ID を書き留めます。
esxcli vm process kill -t force -w <World ID>
注:これにより、仮想マシンのプロセスが kill されます(ハード シャットダウン)。各自のリスクでご利用ください。また、仮想マシンが応答している場合は、この仮想マシンに RDP 接続して、ゲスト OS レベルでシャットダウンします。上記の esxcli vm process list コマンドを(数秒後に)もう一度実行すると、出力が空になるはずです。vCenter インベントリから仮想マシンを削除し、そこに追加し直します。
統合/パワーオンできるはずです。
- それでも仮想マシンを統合/パワーオンできない場合は、VMware にサポート リクエストを提出してください。詳細については、「Customer Connect でサポート リクエストを提出する方法 (2079666)」を参照してください。
NFS ボリューム上でロックされている仮想ディスクのトラブルシューティング
NFS データストア上のロックの問題は、VMFS データストア上のロックの問題とは異なります。NFS は、ブロック レベルのアクセスを提供せず、SCSI ロックを回避するため、ロックのメカニズムが異なります。NFS ロックは、NFS サーバ上にロック ファイルを作成することで実装されます。NFS データストアを参照して隠しファイルを表示すると、.lck-#### ファイルが大量に表示されます。このロック メカニズムが原因で、同じコマンド ライン ツールを使用してロックをかけているものを特定することができません。
バックアップ アプライアンス、仮想ディスクにアクセスする可能性のあるその他の仮想マシンだけでなく、仮想マシンの電源を切ります。
1. ロックを見つける
- 仮想マシンが登録されている ESXi ホストに SSH を使用して root として接続し、データストアを参照します。
- 次のコマンドを実行して、.lck-#### 隠しファイルを表示します。
# ls -lha
仮想マシンの電源が切れており、他に仮想ディスクへのアクセスがない場合は、.lck-#### ファイルがありません。
2. ロックについての情報
.lck-#### ファイルがある場合は、次のコマンドを実行してコンテンツを見ることにより、その元についてさらに情報を得ることができます。
# strings .lck-#### (正しいファイル名に置き換える)
ESXi5.5以降では、次のコマンドを実行します:
# hexdump -C .lck-####(正しいファイル名に置き換える)
これにより、ロック所有者のホスト名が得られます。例:
sxhost2.domain.local3. ロックを解除する
次に、(仮想マシンがパワーオフの場合に限り) rm コマンドを使用してこのファイルを削除できます。
# rm .lck-#### (正しいファイル名に置き換える)
同じ ls -lha コマンドを数秒後に実行し、ロックが再書き込みされたかどうかを確認します。
その場合は、どの仮想マシンをこの ESXi ホストが所有しているかを調べて、この問題を引き起こしている仮想マシンを見つけます(通常はバックアップ アプライアンスまたは CD/DVD としてマウントされている NFS からの ISO です)。
そうでない場合は、
統合/パワーオンできるはずです。
D. 問題の原因は .lck-#### ファイルではなく、一般的な接続の問題である
この記事は、一般的な NFS 接続の問題が原因で発生する問題を考慮していません。一般的なトラブルシューティングについては、「
ESX および ESXi ホストの NFS データストアへの接続の問題に関するトラブルシューティング (2081125)」を参照してください。
ディスク モジュール早期エラーが発生する仮想マシン ディレクトリを(SSH またはデータストア ブラウザで)参照すると、次のようなファイル名が表示されます。
000002-s001.vmdk
000002-s002.vmdk
000002-s003.vmdk
[...]
注:詳細については、「
マウントされた twoGbMaxExtentSparse ディスクを使用して仮想マシンをパワーオンできない (2095798)」を参照してください。
1. 2gbsparse の情報
最大 2 GB の拡張サイズを持つスパース ディスク。このフォーマットのディスクは他の VMware 製品でも使用できますが、ESXi ホスト上でスパース ディスクをパワーオンするには、vmkfstools コマンドを使用して(Thick や Thin などの)互換フォーマットでディスクを再インポートする必要があります。
2. 原因
VMware Converter (P2V) を使用し、誤ったディスク タイプを選択した場合にのみ、このフォーマットになります。修正:もう一度変換し、正しいフォーマットを使用します(Thin、Thick、等)。
3. 回避策/修正
サポートされているフォーマットでディスクのクローンを作成する
- ESXi Shell にログインし、マルチエクステント モジュールをロードして、次のコマンドを実行します。
# vmkload_mod multiextent
一時的に統合/パワーオンできるはずです。
- 次のコマンドを実行して、ホストされたディスクのソース ource.vmdk を new.vmdk にクローン作成します。
# vmkfstools -i source.vmdk new.vmdk -d zeroedthick|eagerzereodthick|thin
- クローン作成に成功したら、次のコマンドを実行してホストされたディスク test1.vmdk を削除します。
# vmkfstools -U source.vmdk
- クローン作成された vmfs タイプのディスク new.vmdk の名前を source.vmdk に変更します。
# vmkfstools -E new.vmdk nsource.vmdk
統合/パワーオンできるはずです。
- マルチエクステント モジュールを次のコマンドでアンロードします。
# vmkload_mod -u multiextent