VMware / Microsoft 製品はこう使う。

好きなことを好きに描く.

その3:VxRail のログを解凍してみる-2 。iDRACのサポートバンドルめちゃ見やすい!

今回はVxRail のログバンドルに含まれる iDRAC のログを解凍していく回です。

 

iDRAC の構成情報&ログはめちゃくちゃ見やすく作られているので、サポートエンジニア観点だと正直感動するレベルです。

 

では順に記載していきます。

 

このVxRail のログバンドルは3ノード分収集しているので、3つのファイルが存在しています。

f:id:japan-vmware:20200212005546p:plain

 

-rw-r--r--. 1 root root 15100453 1月 7 21:28 iDRAC_support_collection_tky-vx5-node01.tkydemo.local_2020-01-08_02_28_14.zip
-rw-r--r--. 1 root root 14974368 1月 7 21:28 iDRAC_support_collection_tky-vx5-node02.tkydemo.local_2020-01-08_02_28_13.zip
-rw-r--r--. 1 root root 14939377 1月 7 21:28 iDRAC_support_collection_tky-vx5-node03.tkydemo.local_2020-01-08_02_27_43.zip

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

 

では、まずZipファイルを解凍して、Node 1 のファイルを覗いてみていきます。

↓を解凍します。

iDRAC_support_collection_tky-vx5-node01.tkydemo.local_2020-01-08_02_28_14.zip

f:id:japan-vmware:20200212010409p:plain

すると、以下のファイルが2つ生まれます。TSRから始まるファイルが本体です。

・TSR20200108112646_18ZNLN2.pl.zip
・signature

f:id:japan-vmware:20200212010518p:plain

 

では、次に、TSR20200108112646_18ZNLN2.pl.zip を解凍します。

「tsr」ディレクトリ内にいっぱいファイルが出てきました!

f:id:japan-vmware:20200212010840p:plain

生成された「tsr」ディレクトリの配下です。

f:id:japan-vmware:20200212011034p:plain

[root@Katayama-CentOS tsr]# ls
hardware metadata.json mut osapp viewer.html
---------------------------------------------------------------------

■Windows のブラウザで「Viewer.html」を開くべし!

私は、Linuxでファイルを解凍していたので、「tsr」ディレクトリまるごとWindowsマシンにコピーして、Viewer.html をChromeで開きます!

 

すると!!!ブラウザで iDRAC が持つ全部の情報が見れます。

ここからはどんどんスクリーンショットを貼り付けます。

f:id:japan-vmware:20200212014446p:plain

■System Board

f:id:japan-vmware:20200213000058p:plain

 ■CPU

f:id:japan-vmware:20200213000224p:plain

■Memory

f:id:japan-vmware:20200213000430p:plain

■Power Supplies

f:id:japan-vmware:20200213000739p:plain

■PCI Devices

f:id:japan-vmware:20200213000941p:plain

■Video

f:id:japan-vmware:20200213001029p:plain

■Ethernet

f:id:japan-vmware:20200213001711p:plain

■Storage - Controllers

f:id:japan-vmware:20200213001928p:plain

■Storage - Enclosures

f:id:japan-vmware:20200213002246p:plain

■Storage - Physical Disks

f:id:japan-vmware:20200213002445p:plain

■Storage - Virtual Disks

f:id:japan-vmware:20200213002557p:plain

■Sensors

f:id:japan-vmware:20200213002650p:plain

■Config
なんとBIOS設定からCPU、その他山程の設定を一覧化してくれています。
しかも検索窓まで用意してくれているという親切さ。

f:id:japan-vmware:20200213002812p:plain

■RAW

f:id:japan-vmware:20200213003001p:plain

■System Event Log
HPEのProLiantでいうところのIML(Integrated Management Log)にあたるものかなと。

f:id:japan-vmware:20200213003750p:plain

■Lifestyle Log

f:id:japan-vmware:20200213004954p:plain

 

■補足

Viewer.htmlがあるので、あまり見る必要はありませんが、同じディレクトリ内にある xml ファイルやjsonファイルからから列挙しています。

例えばわかりやすいところだと、「metadata.json」を開くと構成情報が表示されています。iDRAC バージョン、VxRail のモデル、

iDRAC Firmware Version 、ホスト名から第14世代のHardwareであることまで書いていますね。

f:id:japan-vmware:20200212011837p:plain
{
"iDracVersion":"9",
"FirmwareVersion":"3.34.34.34",
"BuildVersion":"17",
"Model":"VxRail V570F",
"ServiceTag":"内緒",
"Entitlement":"",
"SARegistrationID":"",
"ClientType":"iDRAC",
"CollectionDateTime":"2020-01-08 02:26:49.000+000",
"Make":".",
"OSName":"VMware ESXi",
"DeviceSystemId":"0x0737",
"HostName":"node-61020",
"System Generation":"14G Monolithic"
}

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

 

これらを知ってどうなるねん、と思うかもしれませんが、
システムの増設などが発生した際に、既存環境の情報がどうしても必要になることとかありますよね。現地まで行ったり、お客さんに許可もらったりすることなく、
お客さんにログバンドル取ってもらえば、 ちゃちゃっと作業者側で確認できますよね。

HPE のProLiant にも似たログが存在していて、AHS log (Active Health System Log)というのですが、ベンダーサポートのエンジニアさんしか開けない形式になっているので、その点PowerEdge は良心的だなと思いました。

 

今回はVxRail というより、Dell Technologies のPowerEdge の話になってしまいましたが、以上になります。

 

次はVxRail  Manager のログか、PTAgentのログですね。

どちらにするか考えます。

 

では。

 

その2:VxRail のログを解凍してみる-1 。

みなさん こんにちは。

 

先日、VxRailを触ったので、もともとサポートエンジニアだったということもあり、興味本位で、VxRail Support Bandleを順に解凍し、勝手な見解を書いていく記事です。

 

前回の記事はこちらです。
【その1:VxRail のログを取得してみる】
http://bambi.paddle-point.com/entry/VxRail-log-generate

 

どんどん解凍していく

とにかく VxRail Support Bandle (つまりログ)は、いろんなログや構成情報が1つにまとまって .zip 化されているので、今までログを見たことがない人にとっては、とにかくどのファイルに何が含まれているのか、サッパリわからないと思います。

 

VxRail Support Bandleにはzip形式のものや、tgz 形式のもであったり、gz 形式のものがあったりと、Windows だと解凍がめんどくさいものも多くあるので、私はLinux (今回はCent OS 8)でログをいつも見ていました。

本稿の目的はディレクトリ構造や今自分が見ているファイルが何か、を理解することが目的ですので、Windowsマシンを使用していただいても問題ありません。

 

 前回の記事で取得したログをLinuxマシンに配置

f:id:japan-vmware:20200124155310p:plain

 

 まずは、Unzip します。

f:id:japan-vmware:20200124155525p:plain

 解凍後。

f:id:japan-vmware:20200124155716p:plain

 解凍後のディレクトリの配下にはこれらのファイルが存在する。

f:id:japan-vmware:20200124155803p:plain

 【ログに何が入っているか?】

ESXI_support_collection_2020-01-08_02_27_03.zip
  →ESXiのログ、すなわち vm-support が格納されている。

VC_support_collection_2020-01-08_02_27_03.zip

  →vCenter Server のログが格納されている

 ※これらの中身は一般的なESXi、vCneter のログと同じ

ptagent_support_collection__2020-01-08_02_22_53.zip

  →PTAgent のログが格納されている。

vxrail_data_collection__2020-01-08_02_22_15.zip

  →VxRail Managerのログが格納されている。

iDRAC_support_collection__2020-01-08_02_28_14.zip

   →iDRAC のログが格納されている。(HPEでいうiLOみたいなやつ)

 

すべてのファイルを解凍したあとがコチラ。

f:id:japan-vmware:20200124160403p:plain

 

ESXI_support_collection_2020-01-08_02_27_03.zip

VC_support_collection_2020-01-08_02_27_03.zip

 →これら2つに関しては、私の過去の記事をみてほしい。
  なんと3年くらい前の記事ではあるが、ファイル数の増減はあるが、見方や構造の変化がほぼなかった。。楽しみが少し減った。。

◆ESXiのログの種類と見るべきログファイル(その1~その3)

   http://bambi.paddle-point.com/entry/2016/04/17/012616

   http://bambi.paddle-point.com/entry/2016/04/22/012827

   http://bambi.paddle-point.com/entry/2016/05/09/231929

 

ということで、次回は私がまったく知識がない  ↓  のログを見ようと思う

iDRAC_support_collection__2020-01-08_02_28_14.zip

ptagent_support_collection__2020-01-08_02_22_53.zip

vxrail_data_collection__2020-01-08_02_22_15.zip

 

次の投稿では以下を解凍していこう思う。

iDRAC_support_collection__2020-01-08_02_28_14.zip

 

※次の投稿から頑張る・・・・

 

オワリ

その1:VxRail のログを取得して見てみた。

DELL EMC が満を持して猛烈に力を入れているHCI アプライアンスを先日触ることができたので、プリセールスという立場でありながら、VxRail のログを見てみよう、という記事です。

 

実際の中の人(サポートエンジニア)の人がサポート系の記事を書くと、しがらみや責任問題が発生するので、個人的に私が書く というスタンスです。

 

VxRail とは?

DELL EMC がオススメしているHCI アプライアンスです。

技術のベースはVMware製品で、vSphere(ESXi,vCenter), vSAN, VxRail Managerで構成されています。

 VMware社とDELL EMC が共同開発しているだけあって、かなり作り込まれている製品で、運用のラクさをとにかく意識した製品です。

 

環境情報

VxRail Manager 4.7.300
vCenter 6.7 14368073
VMware ESXi 6.7 Build 14320388
PTAgent 1.9.2-20

ログバンドルを取得

ログを取得して見てみた、という記事なのでログの取得から見てみます。

すべてGUI(vSphere Client) を使って取得します。楽チンです。

 

1.インベントリからクラスタをクリックします
2.[設定]-[トラブルシューティング] をクリックします
3.右端に表示されている [作成...]ボタンをクリックします

f:id:japan-vmware:20200112234539p:plain

vSphereClientLog1

 [収集するデータ] は全部選択します。
ここでの注目ポイントは、トラブルシューティングに必要な基本的なログや構成情報はすべてここで収集してくれます。

f:id:japan-vmware:20200113212638p:plain

次にどのホストのログバンドルを収集するのか、を選択します。

ホスト名とかではなく、まさかの [サービスタグ]、[アプライアンスID] での選択です 笑
[アプライアンスID]はVxRail のコンソール画面(ESXiのコンソール画面)に表示されていますし、その他の箇所でも確認可能です。[サービスタグ]については筐体を見て確認することもできます。

f:id:japan-vmware:20200113213214p:plain

 

iDRAC の横にある「i」マークをマウスオーバーすると説明が表示されます。
説明がイマイチ…!ですが、HPE のサーバーでいうと iLO と同じ役割のものです。リモートごしにサーバーハードそのものを管理することができ、遠隔地に設置しているサーバーのパワーオンができたり、常にサーバーの状態を監視しています。
つまり、DELL EMC特有のものでありながら、vSphere Client からログが取れるというDell Technologies であるがゆえの機能ですね。

f:id:japan-vmware:20200113213741p:plain

 

続いて、PTAgent の横にある「i」マークをマウスオーバーしてみます。
PTAgent はESXi上で動作するサービスの1つで、iDRAC などと通信して情報をとったり、VxRail Managerとの連携に必要なサービスです。そのログを収集します。

余談になりますが、PTAgentのサービスのRestartは、以下のコマンドで実施できます。

 # /etc/init.d/DellPTAgent restart

 f:id:japan-vmware:20200113215026p:plain

 

[生成]ボタンをクリックするとログの収集がはじまり、収集するログの量に応じた時間がかかります。お使いの環境に応じてログの量が違うので、だいたい目安の時間は、
5分~30分前後が多いです。ログ収集の際に影響しがちなのは、稼働日数が長い仮想マシン(1年とか)が居る場合、vmware.log が巨大になっていることがあるので、事前に確認するのはアリかもしれません。

f:id:japan-vmware:20200114143525p:plain

収集後はダウンロードボタンからダウンロードします。

f:id:japan-vmware:20200114144940p:plain

 

ダウンロードしたログはこちらです。

 ※別の日時で取得したものなのでファイル名は異なっています。

f:id:japan-vmware:20200114145128p:plain

 

 

今回はここまで!

 

次回はログの展開して、ログのディレクトリ構造などを見ながら雰囲気を見ていきたいとおもいます。

 

vCSA [6.0, 6.5, 6.7 etc] : WinSCP でvCSAに接続しようとするとエラー(ファイル転送ができない)

みなさまへ

こんにちは。

この記事にたどり着いた方は結構お困りなのではないかと推察します。

 

というのも、vCSA(vCenter Server Appliance)をデプロイしたあとに、vCSAにプラグインをインストールしようとしたりする際にSSH接続はできるけどSCPでファイル転送しようとするとエラーになったり、我々がよく使うWinSCPでvCSAに接続しようとすると、エラーになり、「vCSAにファイルを送れないじゃないか!!!」となっている方がたどり着く記事だからです。

 

そこであまり日本の記事や情報が見当たらなかったので、情報の共有です。

 

まず、結論から申し上げると、VMware KB があります。

 

+Error when uploading files to vCenter Server Appliance using WinSCP (2107727)
https://kb.vmware.com/kb/2107727

 

中身を見ると、理由などが書かれているんですが、我々がやりたことはとにかくファイルを転送させてくれ!というところだと思うんですね。

この問題に直面している人のだいたいが構築中の方だとおもいますので、先に解消することが先決かと思うので、方法だけを記載します。

 

1.vCSAにTeraterm などでSSH接続します。(root)

2.画面上に何をするかの選択肢が出てきます。Shellと入力してEnterです。

f:id:japan-vmware:20190517025114p:plain

 

すると一般的なLinuxと同じ画面になります。

 

3. /etc/passwd  を vi エディタで開きます。

f:id:japan-vmware:20190517025334p:plain

 

4.一番上の行に /bin/appliancesh  になっているのがわかります。

f:id:japan-vmware:20190517025449p:plain

 

5. viエディタの挿入キーである 「i」を押し、一番上の行を/bin/bash に変更します。その後、:wq!  と入力して保存します。

f:id:japan-vmware:20190517025559p:plain

 

6.WinSCP で接続できるようになります!

7.必要なファイルをvCSAに転送しちゃいましょう。

 

8.その後 /bin/bash に変更したものを /bin/appliancesh  に戻しておきましょう。

 

以上になります。

 

私も最初ファイル転送できなくて、デプロイ操作でなにか誤りがあったかな?と思っていましたが、そうではなかったという結論です。

 

なぜこのような現象になるか興味ある方は VMware KB 2107727 を見てください。

 

今回はこのへんで。

 

VCF(VMware Cloud Foundation) とはなにかご存知ですか。

みなさま、こんにちは。

 

最近投稿が滞ってしまっていました。

 

2018年12月から製品部に所属するプリセールスにJob Changeし、立場が変わり、いろいろバタバタしております。前職種ではテクニカルサポートエンジニアとして仕事をしていました。

現在はVMware 製品、Microsoft 製品、SimpliVityの製品プリセールスをしています。

特にSimpliVityに関してはサポート側でLeadをしていたので、発信できればと思っています。

職種が守る側から攻める側に変わったので、生活スタイルが激変しました。

※イメージ

f:id:japan-vmware:20190505000430p:plain

 

以前までは、技術サポート情報中心の投稿でしたが、これからはプリセールス観点でもいろいろ発信できればと考えていますので、よろしくお願いいたします。

 

さて、今回のネタは VMwareさんが推し推しのVCF(VMware Cloud Foundation)の内容です。

みなさまVCFご存知ですか? 「よくわからない」、「ナニソレ?」という人向けにVMwareさんご協力のもと、VMware公式Blogに説明記事を掲載しました!

よければ見てください。

「VMware Cloud Foundation (VCF) 」 をご存知ですか?
https://blogs.vmware.com/jp-cim/2019/03/vcf1.html

 

 なぜこのタイミングで VCFのお話をするのかというと…

ゴールデンウィーク真っ只中の10連休の前半 2019年4月29日(米国時間)Microsoftから「Azure VMware Solutions」が発表されましたね。

わかりやすい日本語の記事だと@ITさんの記事かなと思います。

 

Microsoft Azure上のVMware vSphereクラウドサービス、「Azure VMware Solutions」が発表

https://www.atmarkit.co.jp/ait/articles/1904/30/news017.html

 

記事の中身を見ると… 書いてますね!VCF!!

VMware Cloud Foundationを自動展開することで、ホステッドプライベートクラウドを提供する。」

 

そうなんです、Azure VMware SolutionsはVCFベースで稼動するのです。

あまり知られていませんが、「VMware Cloud on AWS」もVCFをベースに構築されています。つまり、VCFは知っておく必要があるものというのは容易に判断できるとおもいます。

 

実はわたくし VMware Cloud Foundation の検証なども社内で実施する立場にいまして、現行のVCFバージョンは3.7ですが、3.5のときなどの情報も含みながら、スクリーンショット付きで次回以降ご紹介できればとおもっています。

 

では今回はこのへんで。

vCenter 6.7 Update 1 でログを採取する方法(HTML5 - vSphere Client)

vCenter 6.7 Update 1 でログを採取する方法(HTML5 - vSphere Client)

 

https://vCenter のIP  or FQDN /ui/   でログインします。

 

インベントリツリーの一番上を右クリックし、[システム ログのエクスポート] をクリックします。

 

f:id:japan-vmware:20181025184711p:plain

 

ログを取得したいESXiにチェックを入れます。(vm-support)

[vCenter Server およびvSphere UI Client ログを含めます] にチェックを入れます。(vc-support)

f:id:japan-vmware:20181025184939p:plain

 

収集するログを選択します。基本はデフォルトのままでよいです。

[ログのエクスポート]をクリックします。

f:id:japan-vmware:20181025192734p:plain

 

f:id:japan-vmware:20181025202349p:plain

 

ダウンロードしたファイルがこちら。

従来のvSphere Web Client のときとはファイルの命名規則が異なっています。

f:id:japan-vmware:20181025210352p:plain

 

しかし、解凍をして中をみると従来どおりでした。

f:id:japan-vmware:20181025210509p:plain

 

ファイル名に vcsupport と入っているものが vc-support です。

のこりの2つがvm-support です。

 

おわり