【Part.3-2】Advanced Troubleshooting of VMware ESXi Server 6.x for vSphere Gurus
Table of contents
はじめに
VMworld 2017 SER2965BU のセッションでの 27:00 ~ 48:20 頃までの内容、七つ道具2セット目である7つのコマンドについて見ていきます。
- esxcli
- vsish
- vim-cmd
- vmkfstools
- memstats
- pktcap-uw
- esxtop
今回は残りのコマンドである memstats, pktcap-uw, esxtop を見ていきます(esxtop は概観だけ)。
memstats - 詳細なメモリ統計情報
通常、リアルタイムなメモリの性能情報を見る場合は esxtop を使うと思います。ファイルとして保存する場合はバッチモードを使うかもしれません。
memstats コマンドは公開情報がほとんど無い1コマンドですが、こちらを使うとコマンド実行時点の様々なメモリ統計情報を取得することが出来ます。
セッションではホストがメモリ不足になり仮想マシンでメモリのバルーンやスワップが発生した場合、memstats コマンドで状態を見てみる方法が解説されています。メモリオーバーコミットによるバルーンやスワップの動作は割愛しますが、これらの動作の詳細は以下のドキュメントを参照してください。
memstats -r vm-stats -s <columns> としてコマンドを実行することで、実行中の仮想マシンのメモリの状態を見ることが出来ます。以下は観測対象の仮想マシンの Cartel ID (ps の2列目) を確認し、メモリのバルーンとスワップの状態を見ています。ホスト上で複数の仮想マシンが実行されている場合は全て一覧で表示されます。
1# ps | grep vmx
2604326 604326 vmx
3604331 604326 vmx-vthread-604
4604332 604326 vmx-filtPoll:Photon
5604333 604326 vmx-mks:Photon
6604334 604326 vmx-svga:Photon
7604335 604326 vmx-vcpu-0:Photon
8
9# memstats -r vm-stats -s name:balloonTgt:ballooned:swapTgt:swapped:memSize:mapped
10
11 VIRTUAL MACHINE STATS: Sat Sep 12 15:45:22 2020
12 -----------------------------------------------
13 Start Group ID : 0
14 No. of levels : 12
15 Unit : KB
16 Selected columns : name:memSize:balloonTgt:ballooned:swapTgt:swapped:mapped
17
18---------------------------------------------------------------------------------
19 name memSize balloonTgt ballooned swapTgt swapped mapped
20---------------------------------------------------------------------------------
21 vm.604326 2097152 0 0 0 0 212992
22---------------------------------------------------------------------------------
23 Total 2097152 0 0 0 0 212992
24---------------------------------------------------------------------------------
実行結果の列は左から順に以下の通りです。上述の結果では特にバルーンやスワップは発生していません。
- name - 観測対象の名前 (vm.<Cartel ID>)
- memSize - メモリサイズ
- balloonTgt - バルーンで解放しよう試みているメモリ量
- ballooned - バルーンで解放済みのメモリ量
- swapTgt - スワップで解放しようと試みているメモリ量
- swapped - スワップで解放済みのメモリ量
- mapped - ホストから割り当て(マッピング)済みのメモリ
また、オプションを以下のように指定すると、仮想マシンのスワップの状態について確認できます。また、-u オプションで単位(Unit)を MB としています。
1# memstats -r swap-stats -s name:isSwapping:swapped:swapIn:swapout -u mb
2
3 VIRTUAL MACHINE SWAP STATS: Sat Sep 12 15:53:35 2020
4 ----------------------------------------------------
5 Start Group ID : 0
6 No. of levels : 12
7 Unit : MB
8 Selected columns : name:isSwapping:swapped:swapIn:swapOut
9
10----------------------------------------------------------------
11 name isSwapping swapped swapIn swapOut
12----------------------------------------------------------------
13 vm.604326 n 0 0 0
14----------------------------------------------------------------
15 Total 0 0 0
16----------------------------------------------------------------
オプションは左から順に以下です。
- name - 観測対象の名前 (vm.<Cartel ID>)
- isSwapping - スワップが進行中かどうか
- swapped - スワップで解放済みのメモリ量
- swapIn - スワップインの速度
- swapOut - スワップアウトの速度
esxtop のバッチモードだと事前に列のフィルタのために構成ファイルを作る必要などもあるため、コマンドでメモリの情報をさらっと見たい場合には使えそうかなと思っています。冒頭の通りコマンドに関する公開情報は殆どありませんが、どうやら中の人は普通に使ってるようです。
- IMPACT OF CPU HOT ADD ON NUMA SCHEDULING
- I have memory pages swapped, can vSphere unswap them?
- New vSphere 5 CLI Utilities/Tricks Marketing Did Not Tell You About Part 2
また、書籍 VMware vSphere 6.5 Host Resource Deep Dive のメモリ関連の章 (12. MEMORY RECLAMATION TECHNIQUES) でも memstats コマンドが頻繁に出てきていましたので、memstats コマンドの使い方が気になる方はこの本をチェックしてみると良いと思います。
カウンタ自体は esxtop のメモリパネルのものにも見えるので、esxtop のドキュメントは参考になるかもしれません。
pktcap-uw - パケットのキャプチャ&トレース
pktcap-uw は ESXi でパケットのキャプチャが行うためのコマンドラインツールです。一般的には本ツールで採取したパケットキャプチャを pcap や pcapng ファイルとして保存、Wireshark などの解析ツールで採取したパケットキャプチャを解析することが多いと思います。
pktcap-uw ユーティリティを使用したネットワーク パケットのキャプチャとトレース
基本的なキャプチャ時の構文は「pktcap-uw <対象仮想ポート> <キャプチャポイント> <フィルタ> <出力制御>」です。例えば、ある仮想マシンが vNIC で受信する TCP 443 ポート宛のパケットを1つキャプチャして example.pcap としてファイルに保存する場合、以下のようなオプションを指定することになります。
1# pktcap-uw --switchport 33554442 --capture VnicRx --dstport 443 -c 1 -o /vmfs/volumes/datastore1/example.pcap
対象仮想ポートは –vmk vmk<n> や –switchport <port id> のように指定します。–switchport で指定する仮想ポートIDの特定はドキュメントだと esxtop のネットワークパネルで確認する方法になっています。ただ、仮想マシンが多いと見つけづらい時も多々ありますので、個人的には net-stats -l コマンドで仮想ポートの一覧を出したものを grep すると楽かなと思っています。
1# net-stats -l
2PortNum Type SubType SwitchName MACAddress ClientName
333554434 4 0 vSwitch0 b8:ac:6f:12:a7:9c vmnic0
433554436 3 0 vSwitch0 b8:ac:6f:12:a7:9c vmk0
533554452 5 7 vSwitch0 00:50:56:ad:85:aa Test2NICVM
667108876 5 7 DvsPortset-0 00:50:56:ad:9f:3e Test2NICVM.eth1
esxcli コマンドで仮想マシンの World ID から仮想ポートの一覧を取ってくることも出来ます。こちらの場合は現時点で vNIC に紐付いているアップリンクなど詳細な内容も見られます。
1# esxcli network vm list
2World ID Name Num Ports Networks
3-------- ---------------------- --------- --------------------------------------------------------------------
4 2103782 Test2NICVM 2 VM Network, dvportgroup-119027
5
6# esxcli network vm port list -w 2102036
7 Port ID: 33554452
8 vSwitch: vSwitch0
9 Portgroup: VM Network
10 DVPort ID:
11 MAC Address: 00:50:56:ad:27:d2
12 IP Address: 0.0.0.0
13 Team Uplink: vmnic0
14 Uplink Port ID: 33554434
15 Active Filters:
16
17 Port ID: 67108876
18 vSwitch: DSwitch
19 Portgroup: dvportgroup-119027
20 DVPort ID: 13
21 MAC Address: 00:50:56:ad:c7:8d
22 IP Address: 0.0.0.0
23 Team Uplink: vmnic3
24 Uplink Port ID: 67108877
25 Active Filters:
キャプチャポイントは公式ブログの ESXi Network Troubleshooting Tools の記事で代表的なものが挙げられており、特に記事で公開されている以下の画像は非常に分かりやすく、コマンドのチートシートとしても使えます。私もこの画像はよく見ます。
キャプチャポイントの一覧は「pktcap-uw ユーティリティのポイントのキャプチャ」のドキュメントに記載されていますが、pktcap-uw -A コマンドを実行しても –capture で指定可能なキャプチャポイントの一覧を見られます。
1# pktcap-uw -A
2Supported capture points:
3 1: Dynamic -- The dynamic inserted runtime capture point.
4 2: UplinkRcv -- Function to Rx packets from uplink at driver side (obsoleted).
5 3: UplinkSnd -- Function to Tx packets on uplink at driver side (obsoleted).
6 4: VnicTx -- Function in vnic backend to Tx packets from guest
7 5: VnicRx -- Function in vnic backend to Rx packets to guest
8 6: PortInput -- Port_Input function of any given port
9 7: IOChain -- The virtual switch port iochain capture point.
10 8: EtherswitchDispath -- Function that receives packets for switch
11 9: EtherswitchOutput -- Function that sends out packets, from switch
12 (中略)
13 30: EnsPortWriterQueue -- Queue mbufs to an ENS port
14 31: EnsPortWriterFlush -- Flush mbufs on an ENS port
なお、キャプチャポイントが未指定の場合は PortInput (=仮想スイッチへの入力方向) でパケットが捕捉されます。仮想マシンで受信するパケットが取れないなどの混乱を避けるため、キャプチャポイントは明示的に指定した方が良いと思います。その他のキャプチャポイント、フィルタや出力制御のオプションなどは以下の公式ドキュメントをご参照ください。
ここまで pktcap-uw でのキャプチャの概略を簡単に説明しましたが、セッションでは pktcap-uw のディープな使い方として –trace オプションによるトレースが紹介されています。
pktcap-uw ユーティリティを使用したパケットのトレース
この –trace オプションは何に使うかというと、ESXi 上を流れるパケットが何の処理に時間がかかっているか、どこでドロップされているかといった、ESXi のネットワークスタック上のパケットの流れをトレースすることが出来ます。
以下は IP アドレスが 192.168.0.130 の仮想マシンが任意のパケット1個を受信する様子がトレースされた場合の例です。トレースの場合は仮想ポートやキャプチャポイントが指定できないので、フィルタの指定が実質的に必須になると思います。
1# pktcap-uw --trace --srcip 192.168.0.130 -c 1
2The trace session is enabled.
3The session filter source IP address is 192.168.0.130.
4To capture 1 packets.
5No server port specifed, select 7407 as the port.
6Output the packet info to console.
7Local CID 2.
8Listen on port 7407.
9Accept...
10Vsock connection from port 1064 cid 2.
11Receive thread exiting...
1212:48:35.691797[1] Captured at PktFree point, TSO not enabled, Checksum offloaded and not verified, length 765.
13 PATH:
14 +- [12:48:35.691710] | PortOutput | 33554444 |
15 +- [12:48:35.691721] | VnicRx | 33554444 |
16 +- [12:48:35.691796] | PktFree | |
17 Segment[0] ---- 54 bytes:
18 0x0000: 00d8 61a5 e9d3 0050 56ad ce76 0800 4500
19 0x0010: 02ef 7f11 4000 4006 3722 c0a8 0082 c0a8
20 0x0020: 0003 01bb 7416 563d 4e6d fc9a 2222 5018
21 0x0030: 00c9 84b7 0000
22 Segment[1] ---- 711 bytes:
23 0x0030: 1703 0302 c2a5 65c5 1cfc
24 (中略)
25 0x02f0: f4d8 cfe8 36fe 008e 3ca4 6bf5 88
26
27Dump thread exiting...
28Destroying session 40.
29
30Dumped 1 packet to console, dropped 0 packets.
31Done.
セッションでは「仮想マシンやアップリンク、ホストの通信のドロップなど色々見られるよ」程度の簡単な説明のみで手頃な事例が出ていなかったので、これだけだと少し使い道などイメージが掴みづらい印象がありました。
そこで、ESXi 自身のファイアウォールは既定で送受信可能なポートを制限していることから、この記事では VMkernel ポートの不正な TCP 通信をホストのファイアウォールがドロップする様子を実際に見てみたいと思います。
まず ESXi に SSH クライアントで接続し、pktcap-uw コマンドでソース IP アドレスに VMkernel ポートの IP アドレス、ターゲット TCP ポートに 1234 (許可されないポート)を指定します。
1# pktcap-uw --trace --srcip 192.168.0.128 --dstport 1234 -c 1
2The trace session is enabled.
3The session filter source IP address is 192.168.0.128.
4The session filter destination TCP port is 1234.
5To capture 1 packets.
6No server port specifed, select 7247 as the port.
7Output the packet info to console.
8Local CID 2.
9Listen on port 7247.
10Accept...
11Vsock connection from port 1057 cid 2.
この状態で別の SSH クライアントから ESXi に接続し、nc コマンドで適当な IP アドレス宛に TCP 1234 で通信を試みてみます。
1# nc 123.132.213.231 1234
すると pktcap-uw がパケットを捕捉するので見てみると、パスが TcpipTx → PortInput → … と進んでいった後に Drop となっています。また、キャプチャの冒頭のメッセージも「Drop Reason ‘Firewall Drop’」となっています。これらにより ESXi 自身のファイアウォールが VMkernel ポートからのパケットをドロップしたことが分かります。
1# pktcap-uw --trace --srcip 192.168.0.128 --dstport 1234 -c 1
2 (中略)
3Vsock connection from port 1057 cid 2.
4Receive thread exiting...
512:17:04.977883[1] Captured at PktFree point, Drop Reason 'Firewall Drop'. Drop Function 'DVFilterInputOutputIOChainCB'. TSO not enabled, Checksum offloaded and not verified, length 74.
6 PATH:
7 +- [12:17:04.977854] | TcpipTx | 33554436 |
8 +- [12:17:04.977864] | PortInput | 33554436 |
9 +- [12:17:04.977865] | IOChain | | DVFilterInputOutputIOChainCB@com.vmware.vmkapi#v2_5_0_0
10 +- [12:17:04.977865] | PreDVFilter | |
11 +- [12:17:04.977879] | Drop | |
12 +- [12:17:04.977881] | PktFree | |
13 Segment[0] ---- 74 bytes:
14 0x0000: 001b 8bae d28a b8ac 6f12 a79c 0800 4500
15 0x0010: 003c 23f4 4000 4006 0434 c0a8 0080 7b84
16 0x0020: d5e7 e3a4 04d2 35de 30ef 0000 0000 a002
17 0x0030: ffff 12c3 0000 0204 05b4 0103 0309 0402
18 0x0040: 080a 799f d84b 0000 0000
19Dump thread exiting...
20Destroying session 33.
21
22Dumped 1 packet to console, dropped 0 packets.
23Done.
また、Segment 部分は Ethernet フレームのヘッダ以降が16進数で表記されています。冒頭に宛先 MAC アドレスと送信元 MAC アドレスが6バイトずつ入るので、7~12バイト目を確認することで送信元 MAC アドレスが VMkernel ポートの MAC アドレスだということも特定することが出来ました。
1 Segment[0] ---- 74 bytes:
2 0x0000: 001b 8bae d28a b8ac 6f12 a79c 0800 4500
3 ^^^^^^^^^^^^^^
1# esxcli network ip interface list
2vmk0
3 Name: vmk0
4 MAC Address: b8:ac:6f:12:a7:9c
5 Enabled: true
6 Portset: vSwitch0
7 Portgroup: Management Network
8 Netstack Instance: defaultTcpipStack
なお vSphere 単体の内容からは少し離れてしまいますが、NSX-T には分散ファイアウォールという機能があります。この分散ファイアウォールは仮想 NIC ごとにホスト上でファイアウォールインスタンスが作られ2、NSX Manager で作成したルールに基づいてパケットをフィルタリングするという機能です。
pktcap-uw –trace を見ている中で、NSX-T の分散ファイアウォールが使われている場合の見え方が気になってしまいました。このため、NSX-T 3.0 + VDS 7.0 の構成で分散ファイアウォールによりドロップされる場合3も pktcap-uw でトレースしてみました。以下は実行結果からトレースパスを抜粋したものになりますが、なかなか興味深い結果が得られています。
1※NSX-T の分散ファイアウォールでドロップされないパケット
213:31:38.630856[1] Captured at PktFree point, TSO not enabled, Checksum not offloaded and not verified, SourcePort 100663325, VNI 67590 but not encapsulated, length 98.
3 PATH:
4 +- [13:31:38.630690] | VnicTx | 100663325 |
5 +- [13:31:38.630696] | PortInput | 100663325 |
6 +- [13:31:38.630697] | IOChain | | TF_LeafInput@com.vmware.traceflow#1.0.7.0.15945874
7 +- [13:31:38.630698] | IOChain | | SwSec_ProcessPacketsToSwitch@com.vmware.switchsecurity#1.0.7.0.15945874
8 +- [13:31:38.630703] | IOChain | | DVFilterInputOutputIOChainCB@com.vmware.vmkapi#v2_6_0_0
9 +- [13:31:38.630704] | PreDVFilter | |
10 +- [13:31:38.630738] | PostDVFilter | |
11 +- [13:31:38.630738] | IOChain | | FC_LookupInput@com.vmware.nsx.fc#1.1.7.0.15945874
12 +- [13:31:38.630743] | IOChain | | VDL2LeafInput@com.vmware.nsx.l2#1.1.7.0.15945874
13 +- [13:31:38.630746] | IOChain | | L2Sec_FilterSrcMACForgeries@com.vmware.vswitch#1.0.7.0.15945874
14 +- [13:31:38.630748] | IOChain | | VDL2InsertQoSTag@com.vmware.nsx.l2#1.1.7.0.15945874
15 +- [13:31:38.630750] | EtherswitchDispath | 100663325 |
16 +- [13:31:38.630753] | EtherswitchFwdCheckPolicy | 100663325 |
17 +- [13:31:38.630756] | EtherswitchFwdCheckPolicy | 100663318 |
18 +- [13:31:38.630761] | EtherswitchOutput | |
19 +- [13:31:38.630761] | PortOutput | |
20 +- [13:31:38.630762] | IOChain | |
21 +- [13:31:38.630763] | IOChain | |
22 +- [13:31:38.630765] | IOChain | |
23 +- [13:31:38.630765] | IOChain | |
24 +- [13:31:38.630768] | VdrRxTerminal | |
25 +- [13:31:38.630768] | VdrRxTerminal | |
26 +- [13:31:38.630854] | PktFree | |
27
28※NSX-T の分散ファイアウォールでドロップされたパケット
2913:32:05.157232[1] Captured at PktFree point, TSO not enabled, Checksum not offloaded and not verified, SourcePort 100663325, length 98.
30 PATH:
31 +- [13:32:05.157190] | VnicTx | 100663325 |
32 +- [13:32:05.157198] | PortInput | 100663325 |
33 +- [13:32:05.157199] | IOChain | | TF_LeafInput@com.vmware.traceflow#1.0.7.0.15945874
34 +- [13:32:05.157200] | IOChain | | SwSec_ProcessPacketsToSwitch@com.vmware.switchsecurity#1.0.7.0.15945874
35 +- [13:32:05.157204] | IOChain | | DVFilterInputOutputIOChainCB@com.vmware.vmkapi#v2_6_0_0
36 +- [13:32:05.157205] | PreDVFilter | |
37 +- [13:32:05.157229] | PktFree | |
一番興味深い点としては、分散ファイアウォールがドロップした場合はトレースパス上で PreDVFilter の後に PostDVFilter 以降が存在せず、dvFilter から抜け出す前にトレースが終わっているように見えます。また、先ほどの ESXi のホストファイアウォールがドロップした場合のように「Drop Reason ‘Firewall Drop’」のような特別なメッセージも出ていません。
NSX-T などのコンポーネントは dvFilter というネットワーク通信をフィルタする ESXi の API を使用しており、パケットが dvFilter を通過する際に独自の処理を行っています。このため、dvFilter から分散ファイアウォールインスタンスに処理が移っている中でパケットが破棄される、といった仕様を考えれば、ESXi (pktcap-uw) からこういう見え方になるのは自然かなと思いました。
Understanding the ESXi Network IOChain
When we closely examine the upper diagram, we see the additional DVfilter components. The DVfilter is an API framework that is available for VDS and required for NSX. When NSX installs, it introduces additional kernel modules in vSphere ESXi. The summarize-dvfilter command on an ESXi shell shows the loaded DVfilter agents and filters per port.
dvFilter の話を簡単にしたところで先ほどの ESXi 自身のファイアウォールでドロップされたケースに戻りますが、こちらも PreDVFilter の後に Drop となり PostDVFilter 以降は存在していませんでした。
112:17:04.977883[1] Captured at PktFree point, Drop Reason 'Firewall Drop'. Drop Function 'DVFilterInputOutputIOChainCB'. TSO not enabled, Checksum offloaded and not verified, length 74.
2 PATH:
3 +- [12:17:04.977854] | TcpipTx | 33554436 |
4 +- [12:17:04.977864] | PortInput | 33554436 |
5 +- [12:17:04.977865] | IOChain | | DVFilterInputOutputIOChainCB@com.vmware.vmkapi#v2_5_0_0
6 +- [12:17:04.977865] | PreDVFilter | |
7 +- [12:17:04.977879] | Drop | |
8 +- [12:17:04.977881] | PktFree | |
summarize-dvfilter でホスト上の dvFilter を見てみると、VMkernel ポートには ESXi-Firewall という dvFilter のエージェントが構成されているため、dvFilter を通過する際に ESXi-Firewall によってパケットがドロップされたと考えることが出来ます3。
1# summarize-dvfilter
2Fastpaths:
3agent: dvfilter-faulter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter
4agent: ESXi-Firewall, refCount: 3, rev: 0x1010000, apiRev: 0x1010000, module: esxfw
5agent: dvfilter-generic-vmware, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-generic-fastpath
6
7ServiceVMs:
8
9Filters:
10world 0 <no world>
11 port 33554436 vmk0
12 vNic slot 0
13 name: nic-0-eth4294967295-ESXi-Firewall.0
14 agentName: ESXi-Firewall
15 state: IOChain Attached
16 vmState: Detached
17 failurePolicy: failOpen
18 serviceVMID: none
19 filter source: Invalid
長々と書いてきましたが、pktcap-uw では ESXi 上を流れるパケットのキャプチャやトレースを行うことが出来ます。実際にどのキャプチャポイントを使用するべきか等はケースバイケースで変わるため判断が難しいところもありますが、ネットワークのトラブルシューティング時に適切に使うことができれば強力なツールになり得ると思います。
esxtop - ESXi のパフォーマンス計測
ESXi で性能を見るためのコマンドラインツールと言えば esxtop です。vSphere で性能分析と言ったら基本的にパフォーマンスチャートを見るか esxtop を見ることになります。
パフォーマンス監視ユーティリティ: resxtop および esxtop
esxtop で確認できる大項目は以下のものがあります。確認したい性能指標によって使い分ける必要があります。例えば、CPU リソースの競合なら CPU パネルで %READY フィールドの値が上がっていないか等があります。また、CPU 電力パネルは見逃されがちですが、物理 CPU コアが各 C-State / P-State になっている時間の割合を見られるため、CPU の省電力機能を BIOS 等で有効にしている場合はこの辺りも性能に影響していないか注意を払う必要があります。
- c - CPU パネル
- m - メモリパネル
- d - ストレージアダプタパネル
- u - ストレージデバイスパネル
- v - 仮想マシンストレージパネル
- n - ネットワークパネル
- p - CPU 電力パネル
- i - 割り込みパネル
- x - vSAN パネル
SER2965BU のセッションでは、ネットワークパネルでパケットドロップ (%DRPTX, %DRPRX)、ストレージアダプタパネルでディスクの平均遅延時間 (DAVG/cmd) が見られるということだけ1分程度で簡単に紹介されていました。
1※ネットワークパネル
2 5:03:20pm up 8:31, 925 worlds, 12 VMs, 59 vCPUs; CPU load average: 0.34, 0.39, 0.39
3
4 PORT-ID USED-BY TEAM-PNIC DNAME PKTTX/s MbTX/s PSZTX PKTRX/s MbRX/s PSZRX %DRPTX %DRPRX
5 33554433 Management n/a vSwitch0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
6 33554434 vmnic0 - vSwitch0 81.53 0.40 639.00 4.63 0.00 75.00 0.00 0.00
7 33554435 Shadow of vmnic0 n/a vSwitch0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
8 33554436 vmk0 vmnic0 vSwitch0 5.00 0.01 300.00 2.59 0.00 60.00 0.00 0.00
9 33554437 2099810:ADDS-DNS vmnic0 vSwitch0 1.48 0.00 154.00 1.48 0.00 90.00 0.00 0.00
10 33554438 2100027:ADCS vmnic0 vSwitch0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
11 33554439 2100202:ADFS vmnic0 vSwitch0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12 33554440 2100363:VCSA01a vmnic0 vSwitch0 10.93 0.02 194.00 10.38 0.03 382.00 0.00 0.00
1※ストレージアダプタパネル
2 5:04:21pm up 8:32, 925 worlds, 12 VMs, 59 vCPUs; CPU load average: 0.34, 0.39, 0.39
3
4 ADAPTR PATH NPTH CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd
5 vmhba0 - 6 727.06 588.16 138.90 2.79 0.95 8.18 0.00 8.19 0.00
6 vmhba1 - 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
7vmhba64 - 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
8vmhba65 - 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
esxtop はとても多機能で様々な性能分析に使うことができ、esxtop 単体でいくつも記事が書けるレベルのアーミーナイフ的なツールです。とてもじゃないですが一記事で書けるようなツールではないので本記事でも概要だけに留めたいと思います。
esxtop のユースケースや vSphere の性能分析の考え方などは別途、以下のような VMworld 2017 のセッションで詳しく解説されていますので、vSphere のパフォーマンスチューニングをより深く知りたい場合にはこれらのビデオも参照してみてもらえれば幸いです。
- VMworld 2017 SER1534BUR - VMware vSphere Performance Troubleshooting and Root Cause Analysis
- VMworld 2017 SER2724BU - Extreme Performance Series: Performance Best Practices
- VMworld 2017 ADV3368BUS - Find performance bottlenecks. Understanding VMware ESXi Storage Queueing
- VMworld 2017 - VIRT1430BE - Performance Tuning and Monitoring for Virtualized Database Servers
To be continued…
前回と今回の記事で ESXi のコマンドを見ていきました。次は最後に ESXi の構成ファイルを見ていきます。