Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Marie Saito

作成者別アーカイブ: Marie Saito

vSphere 問題解決までのヒント!- 第2回 サポートリクエスト(SR)と情報採取

テクニカルサポートエンジニアのMarieです。

前回はトラブル発生時に役に立つリソースを紹介しました。
今回はサポートリクエスト(SR)と、調査に必要な情報採取についてお話していきます。

第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト(SR)と情報採取 ←This Post
第3回 実践編

VMware vSphereは、単なるサーバー仮想化ソフトではありません。
仮想化環境の包括的な管理・運用に対応した仮想化基盤であり、いわば仮想的なデータセンターです。
ストレージ、ネットワーク、ハードウェア、OS… 全てと関わりがありますのでトラブルシューティングが難しく感じるかもしれません。
しかし、状況をすばやく切り分け・整理して、必要な情報を揃えることができれば、調査はスムーズに進みます。
今回はそのために押さえていただきたいポイントをお話します。

1. 事象の伝え方

まず「どのような事象を問題だと考えているのか」をサポートエンジニアに伝える必要があります。
これが基本にしてとても難しい…のですが、いくつかのポイントを意識するだけでぐっとわかりやすい説明になります。

例えば以下の説明、とてもぼんやりしていますね。
私がこのSRを担当するとしたら、調査にとりかかる前にかなりのヒアリングが必要だと感じます。

サーバにハングが発生したようです。不具合の事例などありますでしょうか。

これをもう少しわかりやすく、状況が伝わりやすい説明に変えてみたいと思います。
サポートリクエスト発行ガイドという資料の中でテンプレートの使用をおすすめしておりますので、これも活用します。

VMware サポートリクエスト発行ガイド
http://campaign.vmware.com/imgs/apac/jp_dwn/PDF/support-SR_guide.pdf

– [1. ご担当者名]

ヴイエムウェア株式会社 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(VMware-vCenter-support-2015-06-09@19-23-44.zip)
イベントログ(ExportEventsLog_user.csv,ExportEventsLog_system.csv)

※ポイント1
「サーバ」だと ESXi なのか vCenter Server なのか仮想マシンなのかはっきりしませんね。
仮想マシン名も特定できているので具体的に明記しました。

※ポイント2
どのような事象を「ハング」だと言っているのか、どのように確認したのかを説明しました。
今回の場合は「 RDP している時に画面が動かなくなった」ということと「監視ツールからの ping に応答が無かった」ということを「ハング」だと言っています。

※ポイント3
事象が発生している対象と、発生していない対象の違いについてわかることを説明しました。
この情報だけで「GuestOS 依存の問題ではなさそう」「ESXi-データストア間の接続に問題がありそう」ということが推測できます。

※ポイント4
詳細はわからないながらも、トリガーと考えられる情報を共有しました。
データストアが NFS や iSCSI 接続のストレージで構成されていればこのメンテナンスの影響があるかもしれませんね。

※ポイント5
現在の状況を説明しました。
何をしたら直ったのかという情報が、問題箇所を絞り込むヒントになることがあります。
今回は何もしなくても復旧したので「設定や構成の問題というよりは一時的な問題ではないか」ということが推測できますね。

いかがでしょうか。
元々の説明よりも、調査のヒントになる情報が増えたと思います。
文章だと書きづらいという場合は箇条書きでもかまいませんので、なるべくポイントを押さえて整理してみて下さい。

・事象の概要
・事象をどのように確認したか
・事象が発生/復旧したタイミング、事象発生のトリガー
・事象が発生している対象と発生していない対象の違い
・ESXi名、仮想マシン名など
・時系列や作業手順

時系列や作業手順については、説明に加えて時間の見えるスクリーンショットも送付いただけると、とてもわかりやすくて助かります。

2. ログの採取方法

事象を整理することができたら、調査に必要なログを採取します。
情報採取を依頼されてからログを取得したらすでにローテートされていた…ということもありますので、なるべく早めに取得しておくことをおすすめします。
vSphereのトラブルでは基本的に以下のログを取得していただいています。

・ESXiのログバンドル(vmsupport)
・vCenter Server のログバンドル(vcsupport)
・vCenter Serverのイベントログ

色々な採取方法があるのですが、今回は以下の方法について説明します。
ログをエクスポートし、操作している端末のデスクトップに持ってくることがゴールです。

・ESXi、vCenter Serverのログバンドルの採取方法(Web Client経由)
・vCenter Serverのイベントログの採取方法(Web Client経由)
・ESXiのログバンドルの採取方法(SSHクライアント経由)

ESXi、vCenter Serverのログバンドルの採取方法(Web Client経由)

vCenter Server にログインします。

supportblog2_1a

ホーム画面から [vCenter Server] を選択します。
[vCenter Serverホーム] 画面に遷移します。

supportblog2_1b

[インベントリリスト] から [vCenter Server] を選択します。

supportblog2_1c

[該当のvCenter Server] を選択します。
今回は vc55.mylab.local というvCenter Server からログを取得します。

supportblog2_1d

[該当のvCenter Server] 画面に遷移したら、[監視]タブ – [システムログ] を選択し、[システムログのエクスポート] を押下して下さい。
ここからログバンドルをエクスポートすることができます。

supportblog2_1e

[ログのエクスポート] 画面がポップアップされます。
[フィルタ] タブにはこのvCenter Server が管理しているESXiが表示されますのでログが必要なESXiにチェックを入れて下さい。
今回は、vCenter Server、このvCenter Serverが管理しているの192.168.1.3というESXi、Web Clientのログを取得する設定になっています。
チェックができたら [次へ] で先に進みます。

supportblog2_1f

[ログバンドルの生成] を選択します。

supportblog2_1g

生成中…少し待ちます。

supportblog2_1h

ログが生成されました。
[ログバンドルのダウンロード] を選択して端末にダウンロードします。

supportblog2_1i

あとはブラウザで、お好きな場所に保存すれば完了です。
今回はデスクトップに置くことにします。

supportblog2_1j

できました!

supportblog2_1k

vCenter Serverのイベントログの採取方法(Web Client経由)

続けてイベントログを取得してみます。
ログバンドルを取得した [該当のvCenter Server]画面 – [監視]タブで、今度は [イベント] を選択します。
[ホーム]画面 – [イベントコンソール] からでも同じことができます。
画面右下のマークを押下して下さい。

supportblog2_2a

[イベントのエクスポート]画面がポップアップします。
[タイプ:] は [システム] に設定していますが、同じ手順で [ユーザー] でも取得して下さいね。
[開始時間] [終了時間] は事象が発生した時間帯を含まれるように設定します。
[CSVレポートの生成] を押下します。

supportblog2_2b

生成できました。
[保存] で先に進みます。

supportblog2_2c

あとはブラウザで、お好きな場所に保存しましょう。

supportblog2_2d

できました!

supportblog2_2e

ESXiのログバンドルの採取方法(SSHクライアント経由)

ESXiに直接ログインしてESXiのログバンドルを取得する方法を説明します。
ESXiのログだけ取得したい時や、vCenter Serverから管理できない状態になっている時などはこの方法がよいと思います。

今回はESXiにSSHでログインしてログを取得します。

ESXiにSSHで接続しログインし、vm-supportコマンドを実行します。

supportblog2_3a

ログバンドルの生成が完了しました。

supportblog2_3b

var/tmp 以下にファイルが作成されています。

supportblog2_3c

今回はSSHクライアントのSCP機能を使用して端末のデスクトップに送りました。
完了です!

supportblog2_3d

「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

「なるべく早く、正確に、問題を解決したい」という気持ちは、お客様もサポートエンジニアも同じです。
うまくコミュニケーションを取って問題を解決しましょう!

第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト(SR)と情報採取
第3回 実践編

第1回ではトラブル発生時に確認しておきたい情報と、確認の方法についてお話しました。
お客様自身で解決できる問題もあったかと思いますし、解決まではたどりつけなくても問題がどこにあるのかの切り分けや状況の整理ができたかと思います。
第2回、今回はお問い合わせいただくときに意識していただきたいポイントや情報採取についてお話しました。
ここまでで、トラブル発生~お客様自身でのトラブルシューティング~お問い合わせ の基本的な流れをイメージしていただけましたでしょうか。
次回は具体例を上げながら、実際問題が発生した時にはまりやすいポイントについてお話します。

vSphere 問題解決までのヒント!- 第1回 トラブル発生時に役立つ 4 つのリソース

テクニカルサポートエンジニアのMarieです。

みなさん、VMwareのサポートにどのような印象をお持ちでしょうか。
職人のようなサポートエンジニアがログを見てさくさくっと回答していると思われるかもしれませんが、
技術的な調査に取りかかる以前に 「何が出来なくてどうお困りなのか」 をお伺いするのに苦労していたりもします。

私が日々お仕事をしていて感じるのは「事象や構成が整理されているお問い合わせは、解決までのスピードが早い!」ということです。
長引いているケースが技術的に難しくて複雑であるとは限らなくて、事象や構成がはっきりしないために技術的な調査が進められないということもあるのです。

この連載では、スムーズな問題解決のためのヒントになるようなお話しをしていきたいと思います。
技術的な話が少なくて拍子抜けかもしれませんが、「サポートエンジニアも結構地道な作業をしているのね!」と感じていただけるかと思います。
徐々にステップアップしていきましょう!

第1回 トラブル発生時に役立つ 4 つのリソース ←This Post
第2回 サポートリクエスト(SR)と情報採取
第3回 実践編

今回はトラブル発生時に役立つリソースとその使い方をご紹介いたします。

  1. ナレッジベース(http://kb.vmware.com/
    障害の発生事例や対処法、トラブルシューティング方法、ベストプラクティス等を検索することができます。
  2. 各種ドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/
    製品マニュアルやリリースノートなど、各種ドキュメントが公開されています。
  3. コンパチビリティガイド(http://www.vmware.com/resources/compatibility/search.php
    VMware製品とハードウェアやOSの互換性をチェックすることができます。
  4. VMware製品間の相互運用性マトリックス(http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php
    VMware製品間の互換性をチェックすることができます。

これから紹介するページは、弊社のサイト(http://www.vmware.com)トップ画面の [サポート] からアクセスできます。
設計・構築時にご利用いただいているものもあるかと思いますが、今回はトラブル発生時にどのようなポイントを確認したらいいかという観点でご説明したいと思います。
はじめての方も、まずは手を動かしながら色々調べてみましょう!

supportblog_index

1. ナレッジベースKnowledge Base(http://kb.vmware.com/supportblog_kb1
まずはここ、1つ目はナレッジベース(Knowledge Base)です。
障害の事例や対処法、トラブルシューティング方法、ベストプラクティス等を検索することができます。
エラーメッセージやコンポーネント名、ハードウェア名などで検索してみて下さい。
最近は日本語に翻訳された記事も増えてきているのですが、英語で書かれた記事をベストエフォートで翻訳していますので、最新情報ではない可能性もあります。
例えば、日本語版では回避策なしと案内されている場合も、オリジナルの英語版では回避策や修正についての情報がアップデートされているかもしれません。
日本語版の記事にはオリジナルの英語版へのリンクがありますので、必ずこちらも合わせて確認するようにして下さいね。


2. 各種ドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/

そして2つ目、製品ドキュメントやリリースノートをはじめ各種ドキュメントが公開されています。
supportblog_doc1
まずは html 版の vSphere 5.5 の製品マニュアルである「VMware vSphere 5.5 ドキュメント センター(http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/Welcome/welcome.html)」を見てみます。
上記のページ「VMware vSphereのドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs/)」各ガイド欄にリンクされています。
supportblog_doc2
確認してもらいたいポイントに沿ってご紹介します。

・構成(システム要件、インストール方法など)
要件を満たしていないシステムでは予期せぬトラブルが発生することがあります。
ご利用いただいている環境がシステム要件を満たしているか、インストールや設定方法に問題が無かったか確認してみましょう。
お客様のシステムはお客様が一番よく知っているはずなので、ここは頑張っていただきたいポイントです!

システム要件を見てみます。
vSphere のインストールとセットアップから展開できます。
supportblog_doc3
例えば、vCenter Server, Web Client, Inventory Service, Single Sign-On すべて同じマシンの構成だと 12GB 以上のメモリが必要ですが、この条件を満たしていないマシンをたまに見かけますね。
基本的なことではありますが、念のためひとつひとつ確認してみて下さい。
supportblog_doc4・トラブルシューティングガイド
トラブルシューティングガイドでは、よくあるトラブルについて、問題・原因・解決方法が説明されています。
このガイドに記載の無い問題であったとしても、類似の問題から何かヒントを得られるかもしれませんので目を通してみて下さい。
supportblog_doc5

次に確認していただきたいのがリリースノートです。
リリースノートには新機能の紹介だけでなく、既知の問題とその回避策も公開されています。
supportblog_rn1
「VMware vSphereのドキュメント(http://www.vmware.com/jp/support/support-resources/pubs/vsphere-esxi-vcenter-server-pubs/)」ページに戻り、vCenter Server 5.5.x の一番新しいバージョン(5.5 Update 2d)のリリースノートを見てみます。
既知の問題の欄をご参照下さい。
ここで紹介されている問題にあてはまりそうな場合、回避策を試してみて下さい。
supportblog_rn2

トラブル時の確認という観点でいうと製品ドキュメントとリリースノートあたりですが、他にも色々なドキュメントが公開されています。
製品への理解を深めるのにお役立てください。


3. コンパチビリティガイドVMware Compatibility Guide http://www.vmware.com/resources/compatibility/search.php

3つ目、少しレベルアップして構成にあわせた確認をしていきましょう。
ストレージやネットワークなど問題が絞りこめている場合は、改めてハードウェアのコンパチビリティを確認してみて下さい。
項目によっては互換性の有無だけではなく、推奨設定なども確認できます。

supportblog_hcl1

試しに私が使っているマシンのHBAのコンパチビリティを確認してみましょう。
vmhba0として認識されているIntel Corporation Avoton AHCI Contorollerにポイントします。

supportblog_hcl3

esxcfg-infoコマンドで詳細を確認してみます。

supportblog_hcl4
supportblog_hcl5

ESXi のバージョンも確認しましょう。
Buildは1892794 なので、ESXi 5.5U1 とのコンパチビリティを確認することになります。

supportblog_hcl6

Web Clientからもハードウェアの情報を確認できます。
インベントリツリーで [ホストおよびクラスタ] – [該当のホスト] – [管理タブ] でネットワークやストレージアダプタを確認できます。

supportblog_wc1

詳細な情報を確認したい場合は、[管理タブ] の右隣 [監視タブ] の [ハードウェアステータス] から該当のアダプタを選択して下さい。

supportblog_wc2

ESXiのバージョン、Buildは [サマリタブ] の [構成] から確認できます。

supportblog_wc3

では、確認した情報を元に検索してみます。

調べる対象はSATA controller なので [What are you looking for] は [IO Device] 、[I/O Device Type] は [SATA] に設定しました。
[Brand Name] や [VID] や [DID] も esxcfg-info や ハードウェアステータスタブ の内容を参考に選択し、 [Update and View Results] で検索を実行します。

supportblog_hcl7

出ましたっ!

supportblog_hcl8

ESXi 5.5U1とIntel Corporation Avoton AHCI Contorollerには互換性があることが確認できました。

supportblog_hcl8

ドライバのバージョンも問題ありませんね。
最新のドライバがあればアップデートしておくとベストです。

supportblog_hcl10

手順やよくある質問についてはこちらをご覧下さい。

* VMware KB: Identifying correct driver for ESXi/ESX host PCI devices (HBA) using VMware Hardware Compatibility Guide (HCL) (1031534)
http://kb.vmware.com/kb/1031534
* VMware KB: Identifying and downloading the appropriate driver for your adapter: Process and FAQ (2050194)
http://kb.vmware.com/kb/2050194


4. VMware製品間の相互運用性マトリックスVMware Product Interoperability Matrixeshttp://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php

見落としがちな4つ目、VMware製品間の相互運用性マトリックス(VMware Product Interoperability Matrixes)では製品同士の互換性を確認することができます。
バージョンアップや旧環境からの移行の後に問題が発生したなんていう時は、念のため確認してみて下さい。supportblog_iom1

では私の使っているマシンにインストールされている ESXi とそれを管理している vCenter Server の互換性を確認してみます。
ESXi はBuild 1892794 なのでESXi 5.5U1、vCenter Server はBuild 2183111 なので 5.5U2 に該当します。
[Select a Solution] で [ESX/ESXi] を選択し、[Version] を指定するとESXi5.5.U1の列が追加されました。

supportblog_iom2

今回確認したいのは vCenter Server との互換性です。
[Add Plat form/Solution] には [vCenter Server] を選択し [Add] すると [vCenter Server] の行が追加されました。

supportblog_iom3

チェックが付いているのが互換性ありのしるしです。
ESXi 5.5U1 と vCenter Server 5.5U2 は互換性に問題が無い組み合わせであることが確認できました。
手順は以下のKBが参考になります。

* VMware KB: Using the VMware HCL and Product Interoperability Matrixes (2006028)
http://kb.vmware.com/kb/2006028

ここまで調べてみて、いかがでしたでしょうか。
問題は解決しましたか?

どれにもあてはまらない…
案内されている方法を試してみたけど直らない…

という場合はサポートリクエスト(SR)を発行してみましょう。
「それなら最初から問い合わせすればよかった!」と思っているかもしれないみなさまに、
ここまで手を動かした努力は決して無駄ではない!」ということをお伝えしたいです。

最初にお話したように、スムーズな問題の解決のためには、問題に対するお客様のご理解がとても大切です。
コンパチビリティを確認してみて、普段ご利用いただいている環境のことがより理解できたのではないでしょうか。
また、ナレッジベースやドキュメントを検索しているうちに、発生している事象が整理されてきたのではないかと思います。

次回はサポートリクエスト(SR)の発行と情報採取についてお話したいと思います。

連載 vSphere 問題解決までのヒント!
第1回 トラブル発生時に役立つ 4 つのリソース
第2回 サポートリクエスト(SR)と情報採取
第3回 実践編