【Part.3-2】Advanced Troubleshooting of VMware ESXi Server 6.x for vSphere Gurus

Share on:

Table of contents

はじめに

VMworld 2017 SER2965BU のセッションでの 27:00 ~ 48:20 頃までの内容、七つ道具2セット目である7つのコマンドについて見ていきます。

  1. esxcli
  2. vsish
  3. vim-cmd
  4. vmkfstools
  5. memstats
  6. pktcap-uw
  7. 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 のバッチモードだと事前に列のフィルタのために構成ファイルを作る必要などもあるため、コマンドでメモリの情報をさらっと見たい場合には使えそうかなと思っています。冒頭の通りコマンドに関する公開情報は殆どありませんが、どうやら中の人は普通に使ってるようです。

また、書籍 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 ファイアウォールの構成

まず 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 のパフォーマンスチューニングをより深く知りたい場合にはこれらのビデオも参照してみてもらえれば幸いです。

To be continued…

前回と今回の記事で ESXi のコマンドを見ていきました。次は最後に ESXi の構成ファイルを見ていきます。


  1. 探した限り KB2043413KB76311 しか見つかりませんでした。 ↩︎

  2. NSX-T の分散ファイアウォールの実装は VMware NSX-T Design Guide: Designing Environments with NSX-T の資料の「5.3 NSX-T Data Plane Implementation - ESXi vs. KVM Hosts」が詳しいので、こちらを参照してもらえればと思います。 ↩︎

  3. pktcap-uw の実行結果とは関係ないですが、分散ファイアウォールのルールは単純に仮想マシンの IP アドレスを指定してドロップするようにしています。 ↩︎