テクニカルサポートエンジニアのMarieです。
前回はトラブル発生時に役に立つリソースを紹介しました。
今回はサポートリクエスト（SR）と、調査に必要な情報採取についてお話していきます。
第１回 トラブル発生時に役立つ 4 つのリソース
第２回 サポートリクエスト（SR）と情報採取 ←This Post
第３回 実践編
VMware vSphereは、単なるサーバー仮想化ソフトではありません。
仮想化環境の包括的な管理・運用に対応した仮想化基盤であり、いわば仮想的なデータセンターです。
ストレージ、ネットワーク、ハードウェア、OS… 全てと関わりがありますのでトラブルシューティングが難しく感じるかもしれません。
しかし、状況をすばやく切り分け・整理して、必要な情報を揃えることができれば、調査はスムーズに進みます。
今回はそのために押さえていただきたいポイントをお話します。
まず「どのような事象を問題だと考えているのか」をサポートエンジニアに伝える必要があります。
これが基本にしてとても難しい…のですが、いくつかのポイントを意識するだけでぐっとわかりやすい説明になります。
例えば以下の説明、とてもぼんやりしていますね。
私がこのSRを担当するとしたら、調査にとりかかる前にかなりのヒアリングが必要だと感じます。
これをもう少しわかりやすく、状況が伝わりやすい説明に変えてみたいと思います。
サポートリクエスト発行ガイドという資料の中でテンプレートの使用をおすすめしておりますので、これも活用します。
VMware サポートリクエスト発行ガイド
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/support-SR_guide.pdf
ヴイエムウェア株式会社 Saito
– [2. サイト・システム名]
検証環境
– [3. 問い合わせ概要]
特定の仮想マシンがハングしました。
– [4. 業務影響]
すでに復旧しているため影響ありません。
– [5. 利用環境]
vCenter Server 5.5U2 Build 2183111
ESXi 5.5U2 Build 1892794 ×1
仮想マシン：Windows Server 2008R2×2, RHEL 6.3×2
– [6. 発生契機／日時／頻度]
6月10日 14:30から14:35頃
– [7. 貴社での切り分け調査内容]
特定の仮想マシン（win1,rh1）がハングしました。※1
6月10日14:30頃、RDP で GuestOS に接続して作業を行っていたのですが画面が動かなくなりました。
監視ツールからの ping にも応答が無かったようで、アラートもあがっていました。※2
事象が発生した仮想マシンの GuestOS は Windows Server と RHEL 各1台ずつで同じデータストア上で稼動しています。
他のデータストアで稼動している仮想マシンについては RDP 接続しておりませんが、監視ツールからのアラートはありませんでした。※3
詳細は不明ですが正午から15時頃までネットワーク機器のメンテナンスが行われていました。※4
14:35頃には自然に復旧し、現在は問題なく動作しております。※5
– [8. サポート調査依頼内容]
メンテナンスの影響と考えておりますが、念のため確認をお願いします。
それ以外に不具合の事例などありましたらお知らせ下さい。
– [9. 送付資料]
vcsupport,vmsupport（[email protected]）
イベントログ（ExportEventsLog_user.csv,ExportEventsLog_system.csv）
※ポイント1
「サーバ」だと ESXi なのか vCenter Server なのか仮想マシンなのかはっきりしませんね。
仮想マシン名も特定できているので具体的に明記しました。
※ポイント2
どのような事象を「ハング」だと言っているのか、どのように確認したのかを説明しました。
今回の場合は「 RDP している時に画面が動かなくなった」ということと「監視ツールからの ping に応答が無かった」ということを「ハング」だと言っています。
※ポイント3
事象が発生している対象と、発生していない対象の違いについてわかることを説明しました。
この情報だけで「GuestOS 依存の問題ではなさそう」「ESXi-データストア間の接続に問題がありそう」ということが推測できます。
※ポイント4
詳細はわからないながらも、トリガーと考えられる情報を共有しました。
データストアが NFS や iSCSI 接続のストレージで構成されていればこのメンテナンスの影響があるかもしれませんね。
※ポイント5
現在の状況を説明しました。
何をしたら直ったのかという情報が、問題箇所を絞り込むヒントになることがあります。
今回は何もしなくても復旧したので「設定や構成の問題というよりは一時的な問題ではないか」ということが推測できますね。
—
いかがでしょうか。
元々の説明よりも、調査のヒントになる情報が増えたと思います。
文章だと書きづらいという場合は箇条書きでもかまいませんので、なるべくポイントを押さえて整理してみて下さい。
・事象の概要
・事象をどのように確認したか
・事象が発生/復旧したタイミング、事象発生のトリガー
・事象が発生している対象と発生していない対象の違い
・ESXi名、仮想マシン名など
・時系列や作業手順
時系列や作業手順については、説明に加えて時間の見えるスクリーンショットも送付いただけると、とてもわかりやすくて助かります。
事象を整理することができたら、調査に必要なログを採取します。
情報採取を依頼されてからログを取得したらすでにローテートされていた…ということもありますので、なるべく早めに取得しておくことをおすすめします。
vSphereのトラブルでは基本的に以下のログを取得していただいています。
・ESXiのログバンドル（vmsupport）
・vCenter Server のログバンドル（vcsupport）
・vCenter Serverのイベントログ
色々な採取方法があるのですが、今回は以下の方法について説明します。
ログをエクスポートし、操作している端末のデスクトップに持ってくることがゴールです。
・ESXi、vCenter Serverのログバンドルの採取方法（Web Client経由）
・vCenter Serverのイベントログの採取方法（Web Client経由）
・ESXiのログバンドルの採取方法（SSHクライアント経由）
vCenter Server にログインします。
ホーム画面から [vCenter Server] を選択します。
[vCenter Serverホーム] 画面に遷移します。
[インベントリリスト] から [vCenter Server] を選択します。
[該当のvCenter Server] を選択します。
今回は vc55.mylab.local というvCenter Server からログを取得します。
[該当のvCenter Server] 画面に遷移したら、[監視]タブ – [システムログ] を選択し、[システムログのエクスポート] を押下して下さい。
ここからログバンドルをエクスポートすることができます。
[ログのエクスポート] 画面がポップアップされます。
[フィルタ] タブにはこのvCenter Server が管理しているESXiが表示されますのでログが必要なESXiにチェックを入れて下さい。
今回は、vCenter Server、このvCenter Serverが管理しているの192.168.1.3というESXi、Web Clientのログを取得する設定になっています。
チェックができたら [次へ] で先に進みます。
[ログバンドルの生成] を選択します。
生成中…少し待ちます。
ログが生成されました。
[ログバンドルのダウンロード] を選択して端末にダウンロードします。
あとはブラウザで、お好きな場所に保存すれば完了です。
今回はデスクトップに置くことにします。
できました！
続けてイベントログを取得してみます。
ログバンドルを取得した [該当のvCenter Server]画面 – [監視]タブで、今度は [イベント] を選択します。
[ホーム]画面 – [イベントコンソール] からでも同じことができます。
画面右下のマークを押下して下さい。
[イベントのエクスポート]画面がポップアップします。
[タイプ：] は [システム] に設定していますが、同じ手順で [ユーザー] でも取得して下さいね。
[開始時間] [終了時間] は事象が発生した時間帯を含まれるように設定します。
[CSVレポートの生成] を押下します。
生成できました。
[保存] で先に進みます。
あとはブラウザで、お好きな場所に保存しましょう。
できました！
ESXiに直接ログインしてESXiのログバンドルを取得する方法を説明します。
ESXiのログだけ取得したい時や、vCenter Serverから管理できない状態になっている時などはこの方法がよいと思います。
今回はESXiにSSHでログインしてログを取得します。
ESXiにSSHで接続しログインし、vm-supportコマンドを実行します。
ログバンドルの生成が完了しました。
var/tmp 以下にファイルが作成されています。
今回はSSHクライアントのSCP機能を使用して端末のデスクトップに送りました。
完了です！
「1.事象の伝え方」の内容と重複しますがログと一緒に必ず送っていただきたいのが、「ログを調査するための情報」です。
「ログがあれば何でもわかるでしょ！」と思われるかもしれませんが、vSphereのログは膨大ですのでこれを全て精査するのは人間には難しい作業です。
時間帯やコンポーネントを絞って確認する必要がありますので、是非ご協力をお願いします。
・作業手順（文章による説明やスクリーンショットで）
・時刻、時系列（文章による説明やスクリーンショットで）
・事象が発生しているESXiや仮想マシンの名前
■参考になるKB
* VMware KB: Collecting diagnostic information for VMware vCenter Server 4.x, 5.x and 6.0 (1011641)
http://kb.vmware.com/kb/1011641
vCenter Serverのログの取得方法がまとめられています。
* VMware KB: Collecting diagnostic information for ESX/ESXi hosts and vCenter Server using the vSphere Web Client (2032892)
http://kb.vmware.com/kb/2032892
Web Clientを使用してログを取得する方法が説明されています。
* Collecting diagnostic information using the vm-support command in VMware ESX/ESXi (1010705)
http://kb.vmware.com/kb/1010705
ESXiからコマンドでログを取得する方法が説明されています。
—
長くなりましたが、ひとつひとつの作業はそれほど難しくないと感じていただけたのではないかと思います。
ここまできちんと揃えていただければ、スムーズに調査が進むはずですので、お問い合わせの際ご活用下さい。
弊社サポートセンターへはMyVMwareからお問い合わせいただけます。
MyVMware
https://my.vmware.com/web/vmware/login
SRの発行方法やデータのアップロード方法については、以下のガイドが公開されております。
VMware サポートリクエスト発行ガイド
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/support-SR_guide.pdf
「なるべく早く、正確に、問題を解決したい」という気持ちは、お客様もサポートエンジニアも同じです。
うまくコミュニケーションを取って問題を解決しましょう！
第１回 トラブル発生時に役立つ 4 つのリソース
第２回 サポートリクエスト（SR）と情報採取
第３回 実践編
第１回ではトラブル発生時に確認しておきたい情報と、確認の方法についてお話しました。
お客様自身で解決できる問題もあったかと思いますし、解決まではたどりつけなくても問題がどこにあるのかの切り分けや状況の整理ができたかと思います。
第２回、今回はお問い合わせいただくときに意識していただきたいポイントや情報採取についてお話しました。
ここまでで、トラブル発生～お客様自身でのトラブルシューティング～お問い合わせ の基本的な流れをイメージしていただけましたでしょうか。
次回は具体例を上げながら、実際問題が発生した時にはまりやすいポイントについてお話します。
