【Part.3-1】Advanced Troubleshooting of VMware ESXi Server 6.x for vSphere Gurus
Table of contents
はじめに
VMworld 2017 SER2965BU のセッションでの 27:00 ～ 48:20 頃までの内容、七つ道具2セット目である７つのコマンドについて見ていきます。
- esxcli - ESXi の設定の確認や変更
- vsish - VMkernel Sysinfo Shell
- vim-cmd - ESXi と仮想マシンの構成の管理
- vmkfstools - データストアや仮想ディスクの管理
- memstats- 詳細なメモリ統計情報
- pktcap-uw - パケットのキャプチャ＆トレース
- esxtop - パフォーマンスモニタリング
今回の記事では esxcli ～ vmkfstools までのコマンドを見ていきます。これだけでも長いため memstats ～ esxtop は次回の記事で。
esxcli, vmkfstools, pktcap-uw, esxtop は公式ドキュメントもあり、非常に便利で強力なトラブルシューティングツールです。これらは平時でも使えるように HOL や Nested ESXi で練習しておいた方が良いかなと思います。
セッションでは公開情報がない裏技的なコマンドも紹介されていますが、ESXi の仕組みの理解に役立つので本記事でも概要を紹介しています。
ESXi Shell と SSH の有効化
ESXi のコマンドは ESXi Shell か SSH で実行しますので、コマンドの利用にはまずこれらの有効化が必要になります。ESXi Shell の有効化の手順などは以下の KB2004746 に記載されていますので、こちらをご参照ください。
ESXi 5.x および 6.x での ESXi Shell の使い方 (2004746)
なお、あくまでもトラブルシューティング用に使う機能のため、通常運用時はセキュリティの観点から無効にしておくことが推奨されます。
esxcli - ESXi の設定の確認や変更
一番有名でよく使うコマンドといえば esxcli です。ESXi のストレージ、ネットワーク、システム情報、ソフトウェアパッケージ、vSAN 構成、仮想マシンなど、色々な情報を取得したり操作に使うことができます。
非常に多彩なコマンドがありますが、基本的に使用できるコマンドは vSphere CLI や Standalone ESXCLI と同じです。すべてを記事にするのは困難かつセッションの範疇外なので、各種コマンドの詳細な内容は VMware {code} にあるコマンドリファレンスなどを参照してもらえればと思います。
esxcli のユースケースは色々ありますがセッションで挙げられているものに言及すると、esxcli network ip neighbor list コマンドで ESXi の ARP テーブルを確認することが出来ます。
1# esxcli network ip neighbor list
2Neighbor Mac Address Vmknic Expiry State Type
3------------------------ ----------------- ------ --------- ----- -------
4192.168.0.129 00:0c:29:16:e6:3f vmk0 1105 sec Unknown
5192.168.0.1 00:1b:8b:ae:d2:8a vmk0 862 sec Unknown
6192.168.0.130 00:50:56:ad:ce:76 vmk0 1139 sec Unknown
7192.168.0.3 00:d8:61:a5:e9:d3 vmk0 1199 sec Unknown
8fe80::21b:8bff:feae:d28a 00:1b:8b:ae:d2:8a vmk0 78801 sec Stale Unknown
カスタム TCP/IP スタックが使われている場合は -N オプションでデフォルト以外の TCP/IP スタックを指定して確認することも出来ます。以下は NSX-T の vxlan スタック (GENEVE で通信する TEP のカスタム TCP/IP スタック) に対しての実行結果です。
1# esxcli network ip neighbor list -N vxlan
2Neighbor Mac Address Vmknic Expiry State Type
3---------- ----------------- ------ -------- ----- ----
410.3.0.3 00:50:56:60:a0:40 vmk10 1192 sec Dynamic
510.3.0.2 00:50:56:6e:89:3e vmk10 1173 sec Dynamic
610.3.0.5 00:50:56:ad:c7:8d vmk10 1196 sec Dynamic
710.3.0.4 00:50:56:69:49:90 vmk10 1193 sec Dynamic
他には esxcli vm process list コマンドで実行中の仮想マシンの一覧を確認するなども可能です。仮想マシン自体がハングしてしまい、kill -9 コマンドで強制終了する必要があるケースなどにはよく使用されます。
1# esxcli vm process list
2VCSA01a
3 World ID: 2100060
4 Process ID: 0
5 VMX Cartel ID: 2100059
6 UUID: 42 2d c4 e7 72 b6 e6 47-aa e6 43 dd e7 81 b2 60
7 Display Name: VCSA01a
8 Config File: /vmfs/volumes/5ef41cb4-a94a9e8c-e0ab-b8ac6f12a79c/VCSA01a.vmx
9
10ADCS
11 World ID: 2100515
12 Process ID: 0
13 VMX Cartel ID: 2100514
14 UUID: 42 2d 80 9d ce ee c5 b8-d9 9d f3 b1 75 48 84 41
15 Display Name: ADCS
16 Config File: /vmfs/volumes/5ef41cb4-a94a9e8c-e0ab-b8ac6f12a79c/ADCS.vmx
個人的によく使うのは esxcli network nic list や esxcli storage core adapter list でしょうか。
1# esxcli network nic list
2Name PCI Device Driver Admin Status Link Status Speed Duplex MAC Address MTU Description
3------ ------------ ------ ------------ ----------- ----- ------ ----------------- ---- -------------------------------------------------------------
4vmnic0 0000:01:00.0 qflge Up Up 1000 Full b8:ac:6f:12:a7:9c 9000 Broadcom Corporation Broadcom NetXtreme II BCM5709 1000Base-T
5vmnic1 0000:01:00.1 qflge Up Down 0 Half b8:ac:6f:12:a7:9e 1500 Broadcom Corporation Broadcom NetXtreme II BCM5709 1000Base-T
6vmnic2 0000:02:00.0 qflge Up Down 0 Half b8:ac:6f:12:a7:a0 1500 Broadcom Corporation Broadcom NetXtreme II BCM5709 1000Base-T
7vmnic3 0000:02:00.1 qflge Up Down 0 Half b8:ac:6f:12:a7:a2 1500 Broadcom Corporation Broadcom NetXtreme II BCM5709 1000Base-T
1# esxcli storage core adapter list
2HBA Name Driver Link State UID Capabilities Description
3-------- ------------ ---------- -------------- ------------------- ------------------------------------------------------------------
4vmhba0 megaraid_sas link-n/a unknown.vmhba0 (0000:03:00.0) LSI / Symbios Logic Dell PERC 6/i Integrated
5vmhba1 vmkata link-n/a sata.vmhba1 (0000:00:1f.2) Intel Corporation 2 port SATA IDE Controller (ICH9)
6vmhba64 vmkata link-n/a sata.vmhba64 (0000:00:1f.2) Intel Corporation 2 port SATA IDE Controller (ICH9)
7vmhba65 iscsi_vmk online iscsi.vmhba65 Second Level Lun ID iSCSI Software Adapter
NIC や HBA で実際に使用されているドライバを確認したり、PCI スロット番号をハードウェアのマニュアルと照らし合わせてハードウェア上での位置を特定する等の用途に使えます。PCI スロットの表記は Linux の lspci 等と同様に「ドメイン:バス:スロット.機能番号」です。
なお、セッションの esxcli の説明で最初に挙げられていますが、esxcli の使用時に意識しておくべき内容があります。それは esxcli 自体の実行が異様に遅かったり失敗するケースです。
最初の ESXi のアーキテクチャを思い出してもらえると、以下のように esxcli は hostd に対してアクセスを行っています。つまり、hostd に問題が発生している場合、hostd へのアクセスに失敗して esxcli も使用できない可能性があります。
このような場合、代わりに localcli コマンドを使用することで、hostd を迂回して同じような操作を行うことが出来ます。問題の根本原因が hostd の動作にも影響していて esxcli が使えない1、というケースもありますので頭の片隅に留めておくと良いと思います。なお、hostd を迂回するため、整合性を保つ観点から通常運用時は localcli による設定変更は行わない方が良いでしょう。
esxcli コマンドは使いこなせると非常に強力なツールですので、是非 VMware HOL や Nested ESXi といったサンドボックス環境で実際にいじってマスターすることをおすすめしたいです。
vsish - VMkernel Sysinfo Shell
VMkernel 内部の情報を取得するための特殊なシェルです。このコマンドは VMware Knowledge Base を検索するとちょこちょこ出てくるのですが、vsish 上でのコマンドの書式やユースケースなどが体系的にまとめられたドキュメントは公開されていないようです。
前提として vsish で設定を「変更」すると予期せず大きなインパクトを与える可能性があります。このため、セッションでは vsish 上で実行するコマンドは get だけに留めるように言及されています。ナレッジベースなどの公開情報で必要と明示されていない限り、それ以外のコマンドを使用することは避けるべきです。
コマンドの書式としては “get /<opt.1>/<opt.2>/<opt.3>…” のように、get の後にディレクトリのような階層構造で取得するオプションを指定します。オプションについては Tab キーで一覧を表示できます。
例えば、CPU 情報を取得したい場合、vsish シェルを起動してから以下のように get コマンドを実行します。
1# vsish
2/> get /hardware/cpu/cpuInfo
3CPU global information {
4 Hyperthreading state:Hyperthreading state: 3 -> enabled
5 HV state:HV state: 3 -> HV Enabled
6 Number of packages:2
7 Number of cores:12
8 Number of CPUs (threads):24
9 Number of licensable cores:12
10 SLC64 capable:0
11 HV Replay capable:0
12 First of reasons why replay is disabled on Host:Reason replay is disabled on Host: 1 -> CPU does not support HV Replay
13 Several reasons why replay is disabled on Host:Reason replay is disabled on Host: 1 -> CPU does not support HV Replay
14 NVOA:0
15 Hyperthreading security vulnerability mitigated:0
16}
vsish の実行時に -e オプションと合わせてワンライナーとしても実行できます。
1※以下でも同じ結果を得られます。
2# vsish -e get /hardware/cpu/cpuInfo
vsish を使うサンプルケースとして、2vCPU 仮想マシン2台の CPU 使用率が常に 100% になっている仮定において、2vCPU という構成が妥当かどうかを一例として見ています。具体的には、vsish での仮想マシンの CPU 統計情報から demand-entitlement-ratio (仮想マシンのリソース要求と実際の割り当ての比率) という値を一つの目安としています。
1# ps | grep vmx
22100059 2100059 vmx
3
4# vsish
5/> get /sched/Vcpus/2100059/groupID
613871
7/> get /sched/groups/13871/stats/cpuStatsDir/cpuStats
8group CpuStats {
9 number of vsmps:26
10 size:40
11 used-time:7637451738 usec
12 latency-stats:latency-stats {
13 cpu-latency:cpu-latency {
14 stolen-time:1892717578 usec
15 ready-time:248449051 usec
16 costop-time:3489838 usec
17 limbo-time:0 usec
18 execution-skew-time:1640778689 usec
19 }
20 (中略)
21 demand:1052 MHz
22 demand-entitlement-ratio:45
23}
この値が 100% を超えている状況、例えば 150% などであれば、単純に仮想マシンからの CPU 要求が割り当てを超過しているため、vCPU の追加が必要との判断に移れます。逆に 100% を大きく下回っている、例えば 50% や 25% であればオーバープロビジョニングの可能性が考えられるので、esxtop で %READY の値を見て CPU がオーバーコミットしていないかをチェックするなどの対応が必要という判断に移れます。
なお、あくまでも上記は vsish の使い方のサンプルです。一般には、仮想マシンの性能情報は以下のようなガイドラインを見つつ esxtop で見る方が多いかなと思います。冒頭の通り vsish については体系的な公開情報も無いので、あくまで「こういう目安の出し方もあるよ」といった程度に考えておくと良いかなと思います。
- ESX/ESXi 仮想マシンのパフォーマンス問題のトラブルシューティング (2001003)
- 応答しなくなった仮想マシンのトラブルシューティング： VMM とゲスト CPU 使用量の比較 (1017926)
また、セッションでは hardware, net, storage の3点の最上位のオプションから以下が一例として抜粋されていますが詳細は解説されていないので、本記事でもオプションの一覧と概要だけに留めます。
- /hardware/bios - BIOS 情報 (ベンダーやバージョンなど)
- /hardware/hardwareInfo - ハードウェア情報 (NUMA ノード数しか出てこず使い道が不明)
- /net/pNics/vmnic<n>/stats - アップリンクの統計情報 (各種エラーフレームのカウントなど)
- /net/portsets/<vSwitch>/stats - 仮想スイッチの統計情報
- /storage/scsifw/devices/<device identifier>/stats - ストレージデバイスの統計情報
- /storage/scsifw/adapters/vmhba<n>/stats - ストレージアダプタの統計情報
vim-cmd - ESXi と仮想マシンの構成の管理
vim-cmd も体系的なドキュメントはありませんが、以下のような仮想マシンのパワーオンなどで使用したことがある人もいると思います。こちらのコマンドは仮想マシンのパワーオンなどのタスク以外にも、ホスト単体で行えるようなタスク、例えばスナップショットの作成などは vim-cmd コマンドで行えるようになっています。
vSphere Client を使用してホストを管理できない場合にコマンド ラインから仮想マシンをパワーオンする (1038043)
vim-cmd も vsish と同じようにオプションは階層構造で指定します。上述の通り体系的な情報はありませんが、ざっと見た感じ最上位のオプションは以下のような対応付けのようです。
- vmsvc - 仮想マシン関連の操作
- hostsvc - ホスト関連を操作
- solo - 仮想マシンの登録など独立した操作
- vimsvc - タスク管理などの操作
- proxysvc - rhttpproxy (ESXi のリバースプロキシ) 周りの操作
- internalsvc - ホストの内部処理
- hbrsvc - vSphere Replication のレプリケーション関連の操作
セッションでは以下の２つのコマンドについて説明されています。
- vim-cmd /vmsvc/getallvms (ホストのインベントリ上の仮想マシン一覧を表示)
- vim-cmd /vimsvc/task_list (ホストで実行されたタスクの一覧)
1つ目の /vmsvc/getallvms は前回のログに関する記事で hostd.log の解説時にも少し見ました。ホスト上の仮想マシンの一覧を表示することができますが、それ以外にもコマンドが正常に実行されるかどうかで hostd が正常に動作しているかの切り分けに利用することが出来ます。
1# vim-cmd help /vmsvc/getallvms
2Usage: getallvms [includeConfigNotAvailable]
3
4getallvms
5
6Get the list of virtual machines on the host.
7
8# vim-cmd /vmsvc/getallvms
9Vmid Name File Guest OS Version Annotation
104 Photon [vsanDatastore] be93505f-43a9-269e-7f16-005056adc982/Photon.vmx other3xLinux64Guest vmx-11 This OVA provides a minimal installed profile of PhotonOS.
2つ目の /vimsvc/task_list は、GUI で表示されないものも含めてホストで実行された最近のタスクを一覧で確認できます。スナップショットの統合が滞留しているなどの場合には、こちらでタスクを確認して /vimsvc/task_info で詳細を確認するなどの対応も可能です。
1# vim-cmd help /vimsvc/task_list
2Usage: task_list
3
4Get list of recent tasks.
5
6# vim-cmd /vimsvc/task_list
7(ManagedObjectReference) [
8 'vim.Task:haTask-4-vim.VirtualMachine.reconfigure-2471509727',
9 'vim.Task:haTask-ha-host-vim.host.NetworkSystem.refresh-2471509741',
10 'vim.Task:haTask--vim.vslm.host.CatalogSyncManager.queryCatalogChange-2471509796',
11 'vim.Task:haTask-ha-host-vim.host.NetworkSystem.refresh-2471509800',
12 'vim.Task:haTask--vim.vslm.host.CatalogSyncManager.queryCatalogChange-2471509859',
13 'vim.Task:haTask-ha-host-vim.host.PatchManager.Query-2471509865',
14 'vim.Task:haTask-4-vim.VirtualMachine.powerOn-2471509883'
15]
なお、/vimsvc/task_cancel でのタスクのキャンセルは、GUI からの実施と同様に種類によってはキャンセルできなかったり問題が発生する場合もあります。タスクのキャンセルは GUI / CLI に関わらず注意が必要です。
vmkfstools - データストアや仮想ディスクの管理
vmkfstools はデータストアや仮想ディスクの管理操作に使えるコマンドです。vmkfstools についてはスナップショットの統合や仮想ディスクのクローンで使用したことがある人も多いかなと思います。
vmkfstools は以下の「vSphere のストレージ」のドキュメントにコマンドの構文やオプションがまとめられており、esxcli と同様に慣れておきたいコマンドの一つとして挙げられます。
個人的には以下のオプションは比較的よく使います。この3つに関しては覚えてしまって損はないです。
1VMFS データストアの構成情報の確認
2# vmkfstools -P -h /vmfs/volumes/<datastore name>
3
4仮想ディスクをシンプロビジョニングに変換
5# vmkfstools -K thickdisk.vmdk
6
7仮想ディスクをシンプロビジョニングでクローン
8# vmkfstools -i srcdisk.vmdk -d thin tgtdisk.vmdk
セッションでは -e, -t10 -v10, -x という3つの少しマイナーな組み合わせについて解説されています。
まず１つ目の -e オプションですが、こちらはスナップショットチェーンの整合性が維持されているかをチェックします。
例えば、ログの記事で言及した KB1007969 のようにスナップショットチェーンの整合性が取れていなくなった状態を仮定します。今回は実験として以下のように親ディスクの CID を vi で編集しましたが、実験以外では絶対にやらないようにお願いします。
1■Example.vmdk (ベースディスク＝親ディスク)
2# Disk DescriptorFile
3version=1
4encoding="UTF-8"
5CID=f1171234 ※親の CID
6parentCID=ffffffff
7createType="vmfs"
8
9■Example-000001.vmdk (子ディスク)
10# Disk DescriptorFile
11version=1
12encoding="UTF-8"
13CID=0826a84f
14parentCID=f11708be ※親の CID と一致してない＝チェーン破損
15createType="seSparse"
16parentFileNameHint="Example.vmdk"
この状態で vmkfstools -e コマンドを実行すると、以下のように子ディスクから親ディスクへのスナップショットチェーンが破損していることが確認できます。
1# vmkfstools -e Example.vmdk
2Disk chain is consistent.
3
4# vmkfstools -e Example-000001.vmdk
5Disk link /vmfs/volumes/5ef41cb4-a94a9e8c-e0ab-b8ac6f12a79c/Example/Example-000001.vmdk successfully opened.
6Disk link /vmfs/volumes/5ef41cb4-a94a9e8c-e0ab-b8ac6f12a79c/Example/Example.vmdk successfully opened.
7Cannot establish parent(/vmfs/volumes/5ef41cb4-a94a9e8c-e0ab-b8ac6f12a79c/Example/Example.vmdk)-child(/vmfs/volumes/5ef41cb4-a94a9e8c-e0ab-b8ac6f12a79c/Example/Example-000001.vmdk) relationship : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18)
8Parent link description
9 Name: /vmfs/volumes/5ef41cb4-a94a9e8c-e0ab-b8ac6f12a79c/Example/Example.vmdk
10 Create Type: vmfs
11 Capacity: 274877906944
12 Content ID: 4044821044
13 Parent Content ID: 4294967295
14Child link description
15 Name: /vmfs/volumes/5ef41cb4-a94a9e8c-e0ab-b8ac6f12a79c/Example/Example-000001.vmdk
16 Create Type: seSparse
17 Capacity: 274877906944
18 Content ID: 136751183
19 Parent Content ID: 4044818622
20Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18)
もしこの状況に陥ってしまった場合には、KB1007969 を参考に頑張って VMDK ファイルを修正した上でゲストが正常に起動できることを祈るか、仮想マシンのバックアップからリストアしてください。ゲストが正常に動作する保証もないことから基本的にバックアップからのリストアを推奨します。
次に２つ目の -t オプションです。-t オプションはコマンドのヘルプにすら表示されませんが、仮想ディスクと VMFS データストアのブロックの対応付けや整合性が確認できるようです。ただし、ゲストOSのファイルシステムの破損はもちろん確認できないので、あくまでも仮想ディスクと VMFS の間での確認であることに留意が必要です。
シンプロビジョニングの仮想ディスクでの実行結果を示します。実行結果を見る限りでは以下の表記と思われます。
[VMDK 上のオフセット: 連続して確保したサイズ] --> [VMFS or 未割り当て(NOMP) -- 連続する領域]
1# vmkfstools -t10 Example.vmdk
2Mapping for file Example.vmdk (274877906944 bytes in size):
3[ 0: 1048576] --> [VMFS -- LVID:5ef41cb3-9908b450-562d-b8ac6f12a79c/5ef41cb3-8ebb96d4-b073-b8ac6f12a79c/1:( 143363407872 --> 143364456448)]
4[ 1048576: 2097152] --> [VMFS -- LVID:5ef41cb3-9908b450-562d-b8ac6f12a79c/5ef41cb3-8ebb96d4-b073-b8ac6f12a79c/1:( 143371796480 --> 143373893632)]
5[ 3145728: 103809024] --> [NOMP -- :( 0 --> 103809024)]
6[ 106954752: 1048576] --> [VMFS -- LVID:5ef41cb3-9908b450-562d-b8ac6f12a79c/5ef41cb3-8ebb96d4-b073-b8ac6f12a79c/1:( 143365505024 --> 143366553600)]
7[ 108003328: 2097152] --> [VMFS -- LVID:5ef41cb3-9908b450-562d-b8ac6f12a79c/5ef41cb3-8ebb96d4-b073-b8ac6f12a79c/1:( 143373893632 --> 143375990784)]
8[ 110100480: 167772160] --> [VMFS -- LVID:5ef41cb3-9908b450-562d-b8ac6f12a79c/5ef41cb3-8ebb96d4-b073-b8ac6f12a79c/1:( 143488188416 --> 143655960576)]
9[ 277872640: 1048576] --> [VMFS -- LVID:5ef41cb3-9908b450-562d-b8ac6f12a79c/5ef41cb3-8ebb96d4-b073-b8ac6f12a79c/1:( 143865675776 --> 143866724352)]
10[ 278921216: 536870912] --> [NOMP -- :( 0 --> 536870912)]
11[ 815792128: 536870912] --> [NOMP -- :( 0 --> 536870912)]
12 (中略)
13[ 274662948864: 213909504] --> [NOMP -- :( 0 --> 213909504)]
14[ 274876858368: 1048576] --> [VMFS -- LVID:5ef41cb3-9908b450-562d-b8ac6f12a79c/5ef41cb3-8ebb96d4-b073-b8ac6f12a79c/1:( 143364456448 --> 143365505024)]
最後に３つ目の -x オプションです。こちらはホストのクラッシュやストレージの障害でディスクの中身が破損した場合にチェックや修復を行います。
-x check は問題がなければ以下のように Disk is error free と出ます。
1# vmkfstools -x check Example.vmdk
2Disk is error free
ディスクに問題があると Disk needs repair. と表示されるので、その場合は -x repair として修復します。ただし、あらゆる状況に対応できるわけではないため、修復しても駄目だった場合は最終手段として仮想マシンのバックアップからリストアが必要になります。
To be continued…
次回も残りの ESXi のコマンドについて見ていきます。