ESXiのログの種類と見るべきログファイル - 3 （仮想マシンのログvmware.logを見よう）

今回は取得したサポートバンドル（vm-support）の中を見ていく第3弾。

地道に3回目を迎えた vm-support の記事。

ESXi上で稼働する仮想マシンたちは、当然ながら個々の仮想マシン内でログを吐きます。
Windows Server であれば、システムログ、アプリケーションログ などが一般的ですし、Linuxであればmessagesなどがありますね。

それらに加え、ESXiは個別にそれぞれの仮想マシンのログ（vmware.log）というログを保持しています。

場所はデフォルトではここです。
vm-supportを取得して解凍したファイルのディレクトリ構造も同じです。

> /vmfs/volumes/<データストア名>/<仮想マシン名>/

ログは仮想マシンが再起動 or 起動するたびにローテーションされ、数字で連番がついていきます。

vmware.log
vmware-1.log
vmware-2.log
vmware-3.log
vmware-4.log

ここで注意したいのは、このvmware.log は、仮想マシンの再起動のタイミングでローテーションするので、
長期間稼働し続けている仮想マシンが存在する場合、特大サイズになっていることがあります。

いざ、VMware社へ vm-support を提供しようした際、
ログバンドル（vm-support）が特大サイズで生成され、解凍した際のログのサイズが
100GBを超えたことがある環境もあるらしいです。（恐ろしい）

話はもどりますが、仮想マシンに問題が発生した場合、
主に見るべきログは、ゲストOS自体のログとESXiに保持されているvmware.log です。

もしvMotion や Cold Migration 時に挙動がおかしくなった場合はhostd.logを見る場合もありますが、まずは上記のログを見ます。

vmware.logですが、多くの情報を残してくれます。
例として、ゲストOSとして動作しているWindows Server 2008 R2 にNMIを発行し、
BSOD(Blue Screen of Death)を発生させ、vmware.log に何が記録されるか見てみましょう。

1.　Windows Server 2008 R2 のゲストにNMIを発行します。
　esxcli vm process listコマンドを実行し、パワーオン中の仮想マシンの情報を表示させます。
クラッシュダンプ作成対象の仮想マシンのWorld IDをメモします。
ここでは「World ID : 3891077 」と表示されています。

2．ゲストOSである Windows Server 2008 R2 側以下のレジストリ設定をしておく。

　HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl

[新規] から [DWORD 値] をクリックし、追加された DWORD 値の名前に ”NMICrashDump” と入力し、ENTER キーを押したあと、
[値のデータ] の空欄に ”1” を入力し [OK] ボタンをクリックします。
この部分はここを見てほしい。

メモリ ダンプ ファイルを生成する方法について | Ask CORE

3．ではESXiから vmdumper コマンドでNMIを発行します。
 　先ほどWorld ID を調べたので、World ID を指定したコマンドを実行します。
　> vmdumper 3891077 nmi　

実行後↓

4.　コマンド実行直後に仮想マシンはBSODになります。

5.　BSODになったので、vmware.log を見てみます。
きちんとBSODが発生したことや、STOPコードまで記録されています。
◆vmware.log（テキスト）
2016-05-09T14:10:38.751Z| svga| I120: WinBSOD: ( 1) `A problem has been detected and Windows has been shut down to prevent damage '

2016-05-09T14:10:38.751Z| svga| I120: WinBSOD: ( 2) `to your computer. '
2016-05-09T14:10:38.752Z| svga| I120: WinBSOD: ( 4) `Hardware malfunction. '
2016-05-09T14:10:38.763Z| svga| I120: WinBSOD: ( 6) `If this is the first time you've seen this Stop error screen, '
2016-05-09T14:10:38.764Z| svga| I120: WinBSOD: ( 7) `restart your computer. If this screen appears again, follow '
2016-05-09T14:10:38.764Z| svga| I120: WinBSOD: ( 8) `these steps: '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (10) `Check to make sure any new hardware or software is properly installed. '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (11) `If this is a new installation, ask your hardware or software manufacturer '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (12) `for any Windows updates you might need. '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (14) `If problems continue, disable or remove any newly installed hardware '
2016-05-09T14:10:38.780Z| svga| I120: WinBSOD: (15) `or software. Disable BIOS memory options such as caching or shadowing. '
2016-05-09T14:10:38.781Z| svga| I120: WinBSOD: (16) `If you need to use Safe Mode to remove or disable compone '
2016-05-09T14:10:38.797Z| svga| I120: WinBSOD: (16) `If you need to use Safe Mode to remove or disable components, restart '
2016-05-09T14:10:38.797Z| svga| I120: WinBSOD: (17) `your computer, press F8 to select Advanced Startup Options, and then '
2016-05-09T14:10:38.797Z| svga| I120: WinBSOD: (18) `select Safe Mode. '
2016-05-09T14:10:38.797Z| svga| I120: WinBSOD: (20) `Technical information: '
2016-05-09T14:10:38.798Z| svga| I120: WinBSOD: (22) `*** STOP: 0x00000080 (0x00000000004F4454,0x0000000000000000,0x0000000000000000,0'
2016-05-09T14:10:38.798Z| svga| I120: WinBSOD: (23) `x0000000000000000) '
2016-05-09T14:10:38.798Z| svga| I120: WinBSOD: (27) `Collecting data for crash dump ... '
2016-05-09T14:10:38.813Z| svga| I120: WinBSOD: (28) `Initializing disk for crash dump ... '
2016-05-09T14:10:42.972Z| svga| I120: WinBSOD: (29) `Beginning dump of physical memory. '
2016-05-09T14:10:42.972Z| svga| I120: WinBSOD: (30) `Dumping physical memory to disk: 0 '

+vmware.log（画面キャプチャ）

このように、仮想マシンで何か発生した際には、
vmware.logを見てみてください。

では、よい仮想化ライフを。

ESXiのログの種類と見るべきログファイル - 2 （ネットワーク障害時）

今回は取得したサポートバンドル（vm-support）の中を見ていく第二弾。

ネットワーク障害時のトラブルシュートしていくときに見ていくログを挙げていく。

【ESXi5.x】
　　◆ファイル名（主なログ）
　　　　/var/log/vmkernel.log　->　vmkernel のログ
　　　　/var/run/log/vmkernel.*.gz　->　vmkernel のログ (過去分)
　　　　/var/log/vobd.log　->　vmkernel observation events

主にこれらのログを見ていくことになる。
その他のログについては、VMware KBも公開されている。
+ESXi 5.1 および 5.5 ログ ファイルの場所 (2080773)

https://kb.vmware.com/kb/2080773

しかし、いきなりvmkernelログを見ていくのは無謀である。
事前に  ESXiのログの種類と見るべきログファイル - 2　で記載したとおり、
「commands」ディレクトリ配下にある「nicinfo.sh.txt」や「 esxcfg-vmknic_-l.txt」を
見てから、どのvmkernel port での事象なのか、またはどのvmnic（物理NIC）での
事象なのかをきちんと確認したうえで、vmkernelログを見るようにしよう。

「nicinfo.sh.txt」のサンプルを記載する。
（かなり長いので冒頭のみを記載）
============

# more nicinfo.sh.txt
Network Interface Cards Information.

Name PCI Device Driver Link Speed Duplex MAC Address MTU Description
----------------------------------------------------------------------------------------
vmnic0 0000:004:00.0 igb Up 1000 Full e4:11:5b:96:c1:ee 1500 Intel Corporation I350 Gigabit Backplane Connection
vmnic1 0000:004:00.1 igb Down 0 Half e4:11:5b:96:c1:ef 1500 Intel Corporation I350 Gigabit Backplane Connection

NIC: vmnic0

NICInfo:
Advertised Auto Negotiation: true
Advertised Link Modes: 1000baseT/Full
Auto Negotiation: true
Cable Type: FIBRE
Current Message Level: 7
Driver Info:
NICDriverInfo:
Bus Info: 0000:04:00.0
Driver: igb
Firmware Version: 1.53, 0x80000bc6, 1.464.0
Version: 5.0.5.1
Link Detected: true
Link Status: Up
Name: vmnic0
PHY Address: 0
Pause Autonegotiate: true
Pause RX: true
Pause TX: true
====================================

この一部だけでこのサーバーのネットワーク構成の概要がわかる。
結果からわかることを抜粋します。

物理NICとしてvmnic0とvmnic1 が存在し、vmnic0 がLinkUpしていて、vmnic1はLinkDownしている。vmnic0は1000baseT/Full でLinkUpしており、Driverは igb Driverで動作していてNICのFirmwareは5.0.5.1である。スピードはオートネゴシエーションの設定となっている。

このあたりだろうか。

ネットワーク構成情報を踏まえたうえで、vmkernelログを見てください。

vmkernelログをみるときの注意点が１つあります。
ESXiのログは基本的にすべてUTC時刻で記録されます。
UTCとは全世界で時刻を記録する際に使われる公式な時刻のことです。
日本時間はUTC +9 時間ということになっています。

UTC: 2016-04-21 16:20:00　→　JST：2016-04-22 01:20:00

つまり、日本でトラブルが発生した時間が2016年4月22日01時20分である場合、

ESXiのログ上の事象発生時刻は2016年4月21日16時20分になります。
間違えてJSTのまま想定してログを見ていると意味不明な結論にたどり着いてしまう可能性もあるため、注意が必要です。

今回はこの辺で。

ESXiのログの種類と見るべきログファイル - 1 （収集したコマンド結果）

今回は取得したサポートバンドル（vm-support）の中を見ていく第一弾。

とはいっても、まずはどのファイルをトラブルシュート時に見ていくのかを
ある程度知っておくと便利であるため、そのあたりから書いていこうと思う。

◆環境
ESXi5.5 Update 2
---
vm-supportのファイル名は↓の命名規則で生成される。

<IP Address or hostname> -vmsupport-<取得日付>@<時間>.tgz 

tgz 形式であるため、Linux上で解凍するでもよし、Windowsに便利なツールをいれて解凍するもよし。

解凍すると、ディレクトリやファイルが数多く散見できる。

主にみることが多いところを列挙する。

commands　→　各コマンドの結果をテキストファイルにまとめてこのディレクトリに入れてくれる。（トラブルシュート時に超重要情報がたくさん入っている。）

var　→　配下に log ディレクトリおよびvar/run/log などが存在し、見ることが多い。
vmfs　→　配下にはESXiがマウントしているデータストアなどの情報が含まれる。当然ながら、データストアには仮想マシンが配置されているため、仮想マシンに関する情報はここを見ることが多い。

まずは「commands」ディレクトリの中を見ていこう。
その前に、上記の画面に 「reconstruct.sh」というシェルがあることがわかる。

これは予め実行しておこう。理由は後述させていただく。
実行はLinux上で実行する

ここからは何かとWindows で開くよりもLinuxでファイルを開いたほうがわかりやすいため、Linuxでログを表示した画面を紹介していく。

まずはサポートバンドルの上位ディレクトリはこのような構造になっている。
（上記Windowsの画面と同じ場所）

  # cd commands　でディレクトリを移動する。
ls コマンドの結果を見ると数多くの結果を見ることができる。
これはすべてコマンド結果のテキストファイルである。

これらのテキストファイルには構成を知ることができる情報が満載である。
例えば、「esxcfg-vswitch_-l.txt」を開くと以下のようなvSwitchの結果が記録されている。
また、どのような vmkernel Port が表示されている。

--------------------------------------------
# cat esxcfg-vswitch_-l.txt

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch0 1536 6 128 1500 vmnic0

PortGroup Name VLAN ID Used Ports Uplinks
VM Network 0 0 vmnic0
VMkernel_vMotion 0 1 vmnic0
VMkernel_iSCSIStorege 0 1 vmnic0
Management Network 0 1 vmnic0
--------------------------------------------
ログバンドルを収集した環境のvSwitchの構成は以下のとおりである。

さらにもっとvmkernel Port の情報が欲しい場合は、「 esxcfg-vmknic_-l.txt」を見ると良い。（画像小さくてすみません）

NIC関連の情報を一気に見たいときは「nicinfo.sh.txt」を見るのもアリだ。

その他にもどのようなデータストアがあるかを確認する場合は、
「localcli_storage-vmfs-extent-list.txt」を見ると良い。
Device Nameまでわかるため、その他の調査にも役立つ。

その他にもStorage と接続しているHBAやサーバー情報など、
トラブル時に必要な構成情報や環境面の情報はほとんど確認ができる。
Windows でも msinfo32 や各サーバーベンダーが収集ツールなどを提供していると思うが、ここまでOS標準のログ収集機能で収集できるとなると、大変便利である。

もし興味があるようであれば、commandsディレクトリ内のファイルはすべて見ておくと何かと便利である。

[補足]
ESX4.xのときは別のディレクトリにコマンド結果が吐かれる。
たしか tmp 配下だったような。（忘れました）

今回はこの辺で。

ESXi やvCenter Server のログを収集しよう。

VMware製品では、ログの収集方法を知ることすら一苦労だなと感じている。

KB も多数公開されているが、本当に使えるものが取れるのか、

"この方法であってる？"  であったり、正直不安な部分が多い。

VMware KB だとこの辺だろう。

+ VMware ESX/ESXi における vm-support コマンドを使用した診断情報の収集 (1036179)
https://kb.vmware.com/kb/1036179

今回はきちんとログを収集する順番を記載していこうと思う。
といってもすごく簡単ですが。画面に表示されるIP Addressなどの名前はマスクさせてもらう。

まず、vSphere Client からvCenter Server に接続し、
ツリーの一番上（vCenter Server）をクリックした状態にする。

上部のメニューから [ファイル] - [エクスポート] - [システムログのエクスポート] を
クリックする。

ログを収集するESXiホストにチェックを入れる。
また、vCenter Server の情報も一括で収集したい場合は、
[vCenter Server およびvSphere Client からの情報を含む] にチェックをいれておく。

デフォルトで [次へ] をクリックだ。

任意の保存先を選ぶのみ。

[終了] をクリックするとログ収集が開始される。

あとは待つだけだ。

ここまでの操作で収集されるものは、VMWare KB などでいうところの、

vm-support , vc-support  というログバンドルになる。

・　vm-support　-> ESXi上のログをまとめて圧縮したもの

・　vc-support　->　vCenter のログバンドル

vm-supportというログバンドルは、一括収集しているだけでなく、
いろんなコマンド結果をテキストファイルに保存してログバンドルとして保存してくれている。すごくいい奴なんです。

VMware社に問い合わせるときにもこれらを収集するよう言われることが多いみたいです。

vm-supportの中身については、次回の記事に記載したいなと思う。

ESXi6.0 Update 2 からESXiホスト単体のWeb Client が提供されています。

VMwareがvSphere Web Client をリリースし、新機能については

vSphere Client では使えなくなり、vSphere Web Client で利用できることを

言い出してからかれこれ　xx年　くらい経つ。

私は、今だにVMware製品使っている人で、vSphere Web Client をがっつり

使っている人を見たことがない。vSphere Client でできないことは仕方なしに

vSphere Web Client を利用しているという印象だ。

その理由の１つとして、ESXi単体ではvSphere Web Client  が利用できないことが挙げられる。つまり、vCenter Server ありきのvSphere Web Client だったわけだ。

しかし、このたびリリースされたESXi6.0 Update 2からESXi単体でもWeb Clientが使えるようになったので、メモとして残そうと思う。

-------------------------------------------

ESXi6.0 Update 2 のリリースノートにはこのような記載がある。

VMware Host Client: VMware Host Client は HTML5 クライアントであり、単一の ESXi ホストに接続してそのホストを管理するために使用します。管理タスクを実行して、仮想マシン、ネットワークおよびストレージなどのホスト リソースを管理できます。VMware Host Client はまた、vCenter Server および vSphere Web Client が利用できないときに、個別の仮想マシンまたはホストをトラブルシューティングする場合に役立ちます。VMware Host Client の詳細については、『VMware Host Client 1.0 リリース ノート』を参照してください。
-------------------------------------------

VMware Host Client というらしい。

さっそく試してみた。適当なESXi6.0 Update 2 を用意（Nested）

このあたりの情報を参考にする。

https://labs.vmware.com/flings/esxi-embedded-host-client
For ESXi 5.5U2 and prior, and ESXi 6.0 hosts upgraded from any 5.5U2 or prior version, you will get a 503 error returned after visiting https://<esxhost>/ui/.

なるほど、http://のIP Address>/ui/　と入力するらしい。

さっそくGoogle Chromeを使って開いてみる。

なかなか良い見栄え。というよりも、vSphere Web Client や最近ではvRealize 　Operationsと同じ見栄えの画面になっている。統一感持たせてます。

ESXi単体なので、ESXiのroot ユーザーでログインします。

仮想マシンを作ってみましょう。

すでに「Windows Server 2016」が選べるようになっていますね…

データストアを選択

さくさく作成できます。
VMwareのコンセプト通り、今後はこれがスタンダードになっていくような気がします。使い慣れておいたほうがいいですね。

◆どこで実行されているのか

この機能、実際に何で実装されているのかというと、vib  で提供されています。
（vibは、Linux でいうパッケージrpmみたいなもの、ような位置づけ）

ここに書かれていますが、esxui-signed-3623722.vib をESXiにインストールすることで利用できるようになります。つまりESXi5.xなどに入れて使うこともできます。（サポートはされてないですが）

ESXi Embedded Host Client – VMware Labs

試したのが結構前なのでウル覚えですが、SSHでESXiにログインして、

>esxcli software vib install -v <esxui-signed-3623722.vibの場所>

で、インストールできます。

インストール後、ESXiを再起動しないときちんと表示されませんでした。

◆感想
vSphere Web Client と比べて、操作がきびきび動いてストレスが少ないです。
コンソールの表示なども早く、利用していきたいと感じた。

vMotion が失敗するVMware KB 2143943 が公開されていた。

おととい、インターネットで調べものをしていると、あるVMware KB に行きついた。
まずひとこと言わせてもらうと、タイトルが長い。

+ After upgrading from ESXi 5.0/5.1 to 5.5 Update 3 or 6.0 Update 1b,
　vMotion fails with: failed to add memory page 0x201 to VM: Bad parameter (2143943)
http://kb.vmware.com/kb/2143943

内容はここに書いている。

After upgrading from ESXi 5.0.x or 5.1.x to ESXi 5.5 Update 3 or 6.0 Update 1b, you experience these symptoms:
vMotioning a virtual machine from an ESXi 5.0 or 5.1 host to a ESXi 5.5 Update 3b or 6.0 Update 1b host fails.

移行元がESXi 5.0 か5.1 で 移行先が ESXi5.5 Update3b か 6.0 Update 1b だと失敗すると書いてある。

驚いた。

普段からよく構築した会社とかサポートから  "できるだけ最新にしてほしい"  と言われるのに、vMotion が失敗することがあるという記載である…。
たまったもんじゃない。コワイコワイ。

そして、現段階では　恒久対策方法はナシ！
問題が発生したら仮想マシンをパワーオフして再度パワーオンするよう書いている。
KB には書いていないけど、どうせ一度パワーオフするなら、Cold Migration　を実施するほうが確実だと思った。

おそらくvMotion 時に移行先ESXiホストへメモリの内容を転送した際に、解釈できないパラメータを受け、vMotionが失敗してしまうという雰囲気。（妄想）

Resolution

This is a known issue affecting ESXi 5.5 Update 3b and 6.0 Update 1b

 

Currently, there is not resolution.

 

To work around this issue, power off the virtual machine and power it back on.

 
しかし、堂々と　↑　こう書ける度胸が素晴らしいような気もする。

事象に合致しているか否かはKBに記載されているとおり、ログをみることになるのだろうなぁと思う。

仮想マシンの挙動をログに記録するvmware.log　や　ESXiをつかさどるカーネルのログ（vmkernel.log）もしくは、仮想マシンの管理を行うメインプロセスのログ（hostd.log）を見ろと書いている。

私みたいな一般ユーザーが見ることはまずないですね…

このVMware KB 2143943 が早めに更新されることを祈ります。

-------------------------------------------

更新情報
-------------------------------------------

修正されていました。素直にESXi 6.0 を使っている場合は、
Update 2にしたほうがいいですね。

Resolution

This issue is resolved in:

• ESXi 6.0 Update 2, available at VMware Downloads. For more information, see the VMware ESXi 6.0 Update 2 Release Notes.
• ESXi 5.5 patch ESXi550-201602001. For more information, see VMware ESXi 5.5, Patch Release ESXi550-201602001 (2144353).

 

To work around this issue if you are unable to upgrade, power off the virtual machine and power it on.

痛恨である不具合にはさっさと対処するのも外資系ならでは、なのかもしれませんね。

いやはや、治ってよかった。

私の環境もこの際、ESXi6.0 Update 2 にしてしまおうと思います。