###手順

1. vSphere Clientで対象ESXiへログイン

2. vSphere ClientよりFile > Export > Export System logsを選択（下図参照）

3. 表れるWindowにてデフォルトのままNextを選択

4. ダウンロード先を選択してNextを選択

5. Finishを選択してログの作成&転送開始

6. ステータスが両方ともCompleteになりましたら、転送完了です

本記事では、VDP(VMware Data Protection) ログの採取方法についてご紹介します。

なお、VDP ver6.1.5で動作検証を行っています。

UIの表示等 version毎に違いがある可能性がありますので予めご了承下さい。

VDP管理GUIから

1.ブラウザに https://<VDP IP Address>:8543/vdp-configure/  と打ち込み、VDP管理GUIを開きrootでログインします。

2.[Log Collector]タブをクリック

3. ①すべてのVDPアプライアンスログ/②クライアントログ/③構成 情報の3つ全てで"ダウンロード"を実施し、

    保存したファイルを弊社サポートへお寄せ下さい。

SSH接続を有効化し、CLIから

障害状況によっては、VDP管理GUIが開かない などといった場合があります。

以下コマンドにてtomcatサービスの再起動実行してもGUIが開けない場合、本手順を参考に、CLIからログを取得します。

emwebapp.sh --start

なお、VDP5.8からはセキュリティ強化としてSSHがdefault無効化されているため、まず有効化します。

1.web clientからVDPの仮想マシンアプライアンスを選択し、[アクション]タブ > [コンソールを開く]よりコンソールを開きます。

2.コンソールが開いたらEnterキーを押下します。

3.ログインプロンプトが表示されるため、rootでログインします。

4.sshのconfigを編集します。

vi /etc/sshd_config

5.sshd_configへviで表示されたら、 i を押下してコマンドモードから編集モードへ切り替えます。

6.編集モードへ切り替えると下部に [-- INSERT --]と表示されます。

   以下の通り、[PermitRootLogin]行のコメントアウト # を消します。

7.ESCキーを押下して編集モードからコマンドモードへ切り戻し、:wq! と打ち込み、編集内容を保存します。

8.その後、SSHサービスを再起動します。本作業にて、SSH接続が許可されるようになります。

/etc/rc.d/sshd restart

9.teratermなどのターミナルソフトウェアよりSSHでrootログインします
   (teratermの場合はチャレンジレスポンス認証を利用)。

   その後、以下コマンドにてログを採取します。

   構成によっては、いくつかのログ取得にFailした旨のメッセージが表示されます。

cd /usr/local/avamarclient/bin

./FileCollector –o /space/<Name_Of_Log_File>.zip

chmod 755 /space/<Name_Of_Log_File>.zip

10.採取したログはteratermの転送機能やWinSCPなどのFTPクライアントソフトウェアを利用しローカルに保存し、

     弊社サポートへお寄せ下さい。

     ログ保存後は、以下コマンドでログファイルを削除してください。

rm /space/<Name_Of_Log_File>.zip

11.お客様のセキュリティ要件に応じて、有効化したSSH接続を改めて無効化してください。

参考資料:

- Collecting diagnostic information for VMware Data Protection (2033910)

    https://kb.vmware.com/s/article/2033910

- Collecting vSphere Data Protection logs when the VDP configuration GUI is unresponsive (2053235)

    https://kb.vmware.com/s/article/2053235

- VMware vSphere Data Protection (VDP) 5.8 に SSH で root ユーザーとして接続しようとしても、

「アクセスが拒否されました」というエラーで失敗する (2089874)

  https://kb.vmware.com/s/article/2089874?lang=ja

本記事では、USVM(Guest Introspection)のログ採取手順をご案内します。

※本記事の手順は以下のVMware KBより抜粋、および改変したものです。

最新の情報については以下のKBをご参照ください

How to collect logs in NSX for vSphere 6.x Guest Introspection (2144624)

### ログ取得手順 ###

1. ホスト MOID を特定します。

a. Web ブラウザを開き、https://<vcenter_IP>/mob/ を参照します。

b. vCenter Server の管理者認証情報(vCenter SSO)を使用してログインします。

c. [content]をクリックして、[group-d1] をクリックします。

d. childEntity で、ESXi ホストがあるデータセンターの [datacenter-##] をクリックします。

e. hostFolder で [group-h##] をクリックします。

f. childEntity で、ESXi ホストがあるクラスタの [domain-c##] をクリックします。

   ホスト セクションに、すべてのホスト MOID のリストが表示されます。

   以下のように表示されますので、host-##の部分を記録してください。

※ 手順中 ##の部分には環境に応じた数字が入ります。

VxRail 4.0 & 組み込み型vcsaの場合は通常は以下の数字の組み合わせになります

[group-d1]  > [datacenter-2] > [group-h4] > [domain-c7]

VxRail 4.5 & 組み込み型vcsaの場合は通常は以下の数字の組み合わせになります

[group-d1]  > [datacenter-2] > [group-h4] > [domain-c8]

2. ログを生成するには、次のコマンドを実行します。コマンド中、host-##の部分には手順1で取得したMOIDを代入してください。

    また、コマンド中<>の部分には、それぞれNSX ManagerのAdminユーザのパスワード、NSX ManagerのIPアドレスを代入してください。

vcsa:~# curl -D - -k -u 'admin:<NSXMGRのpassword>' -L -X GET https://<NSXMGRのIP>/api/1.0/hosts/host-##/techsupportlogs -o host-##-usvm.log.gz

※ -D - -k の部分は入力ミスではありませんのでそのままご入力下さい

※生成されたログをそのままDell EMCにご提供ください

※USVM（Guest Introspection VM）が稼働するすべてのホストに対してご取得ください

※本コマンドはcurlコマンドを実行できるLinuxホストから実施できます。

   VCSA上でコマンドを実行し、作成したログをSCPでダウンロードする際に正常にアクセスができない場合は下記をご参照ください。

   WinSCP を使用してファイルを vCenter Server Appliance にアップロードするとエラーが発生する (2107727)

■GIのログ採取APIの成功例（curlのHTTPステータスコードとファイルサイズで判断）

$ curl -D - -k -u 'admin:Passw0rd!' -L -X GET https://192.168.0.1/api/1.0/hosts/host-10/techsupportlogs -o host-10-usvm.log.gz

HTTP/1.1 303 See Other

...

 

HTTP/1.1 200 OK

...

 

$ ls -l host-10-usvm.log.gz

-rw-rw-r-- 1 administrator administrator 8967  9月 27 04:10 host-10-usvm.log.gz

■GIのログ採取APIの失敗例

$ curl -D - -k -u 'admin:Passw0rd!' -L -X GET https://192.168.0.1/api/1.0/hosts/host-10/techsupportlogs -o host-10-usvm.log.gz

HTTP/1.1 400 Bad Request

...

 

$ ls -l host-10-usvm.log.gz

-rw-rw-r-- 1 administrator administrator 160  9月 27 04:23 host-10-usvm.log.gz

 

$ cat host-10-usvm.log.gz

<?xml version="1.0" encoding="UTF-8"?>

<error><details>RPC request timed out.</details><errorCode>2502</errorCode><moduleName>core-services</moduleName></error>

■ 失敗例：SSL Unknown Protocol

$ curl -D - -k -u 'admin:Passw0rd!' -L -X GET https://192.168.0.1/api/1.0/hosts/host-10/techsupportlogs -o host-10-usvm.log.gz

* About to connect() to 192.168.0.1 port 443 (#0)

*   Trying 192.168.0.1... connected

* Connected to 192.168.0.1 (192.168.0.1) port 443 (#0)

* successfully set certificate verify locations:

*   CAfile: none

CApath: /etc/ssl/certs/

* TLSv1.0, TLS handshake, Client hello (1):

* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

* Closing connection #0

curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

※上記はcurl コマンドが使用するopensslのVersionが古いことに由来しています。

openssl 1.0以降を利用している端末から実施してください。

TSRログはPowerEdgeサーバのハードウェアの状態やiDRACの情報を得るために必要です。

ハードウェア障害が疑われる場合や、iDRACの動作不良などが疑われる場合などに採取を依頼しています。

※この文書は以下のリンクを参考にしています。

・Legacy EMC KB

https://support.emc.com/kb/501922

・Legacy Dell

http://www.dell.com/support/article/in/en/indhs1/sln295784/how-to-export-a-supportassist-collection-and-the-raid-controller-log-via-idrac-7-and-8-?lang=en

### ログ取得手順 ###

１．iDRACにブラウザでログインしてください

     ※以下の図を参考にroot ユーザでiDRACの管理コンソールにログインしてください

     ※ip addressとパスワードは構築資料をご参照、もしくは構築ベンダーにお問い合わせください

２．ログイン後、下図を参考に Troubleshooting > SupportAssist > Edit Collection Data 順に選択してください

３．Collection DataのEdit画面にて下図のようにRAID Controller Logをチェックし、Applyを押してください

４．Export Support Assist Collectionを選択してください

５．Term and Conditions の内容を確認したのち、チェックを入れてContinueで進んでください

６．進捗バーが現れるので完了するまで待ちます

７．完了したらOKボタンを押してください

８．OKボタンを押すと保存を促されますので保存してください。

          ※保存のポップアップが出るまで数十秒程度かかる場合があります

９．保存フォルダに以下の名前形式でzipファイルが作成されますのでDell EMCへご提出ください

     名前形式：TSR<日付>_<英数字(ServiceTag)>.zip

          ※稀に保存に失敗する場合があります。ファイル名とファイルサイズが正常であることを事前にご確認ください

vc-supportログとセットでvm-suuportログも生成するも、vm-supportが同梱されていないときなど、

指定のESXiホストのvm-suuportログだけを取得する際に利用できます。

vSphere Clientを利用されている方はコチラ。

VxRail: vm-support取得方法（vSphere Client利用）

vSphere Web Clientを利用して、単体ESXiホストからのvm-supportログ生成手順

1. vSphere Web Clientにログイン

2.Home > Host and Clusters > 対象ESXiを右クリック > Export System Logs..をクリック

3. Export LogsウィザードのReady to Complete画面の[Generate Log Bundle]ボタンをクリック

4. Log bundle generated..のメッセージが表示されてたら、[Download Log Bundle]ボタンをクリック

5.保存先を選択 > [Save]

5. 指定先へのログ保存を待つ

6. Download Completedメッセージ表示 > Finishボタン

　※指定先にログファイルが生成されるものの、[Finish]ボタンがグレイアウトしたままになることがありますが

　　ログファイルが生成されていれば問題ないので、その際は[Cancel]で終了します。

指定した保存先にファイル名[VMware-vCenter-support-20YY-MM-DD@HH-MM-SS.zip]というログが保存されます。

zipを展開すると、ESXiホスト名が入ったログ[<ESXi_host_name>-vm20yy-mm-d@hh-mm-ss.tgz]が生成されています。

## はじめに ##

本ドキュメントでは、iDRAC9を利用してハードウェアlog、

並びに 一部 ESXi log収集を行うための手順をご紹介致します。

## 世代 について ##

Dell PowerEdge サーバー ベースで提供されるVxRail Modelでは、

特定のModel範囲を意味する「世代」という単語によってマシンを判別する事があります。

VxRail では以下世代区分となります。

## TSR(SupportAssist)ログ取得方法 ##

1.ブラウザに[https://iDRACのIPアドレス]を入力し、iDRACにアクセスします。

   ※ip addressとパスワードは構築資料をご参照、もしくは構築ベンダーにお問い合わせください

2.上部タブ[メンテナンス] > [SupportAssist]をクリックします。

  [SupportAssist登録]のウィンドウが表示されましたら[キャンセル]にて画面を閉じます。

3.[収集の開始]をクリックし、[デバックログ]にチェックを入れて[収集]を押下します。

4.ログの収集が完了するまで待ちます。[ジョブキュー]をクリックすると、ジョブID情報が参照出来ます。

5.ログの収集が完了したら、[OK]をクリックするとログがローカルに保存されます。

   保存フォルダに以下の名前形式でzipファイルが作成されますのでDell EMCへご提出ください。

     名前形式：TSR<日付>_<英数字(ServiceTag)>.zip

この記事ではVxRailログバンドル（VxRail Support Bundle）の作成方法を紹介します。

VxRail ver 4.5.x/4.0.x/3.x

VxRail Support Bundleとは、VxRailの管理コンポーネントであるVxRail Managerが保持している情報を一括して取得するログです。

主にVxRail Manager GUI上のエラー、VxRail Upgradeやノード/ディスク追加時のトラブルシューティングで利用されます。

手順

1. administratorアカウントにてVxRail Manager GUI(htttps://<IP or FQDN of VxRail Manager>) にログイン

2. 左メニューの構成(Config) >

画面上部の一般(General)タブ (バージョンによっては"全般"と表示されています) >

ログコレクション配下の"新しいログバンドルの生成(Generate New Log Bundle)"ボタンをクリック

3. ログが作成されるとポップアップウィンドウが表示されるので、ログをローカルPCへダウンロード

VxRail ver 4.7.x/4.5.3xx

VxRail GUIから採取できるログが強化されています。

取得頂くログに関して、サポートより個別に指示させて頂く場合があります。

vm-supportやiDRAC,PTAgentの採取はnode単位で指定取得が可能です。

取得したいログコンポーネントにチェックしたら、[生成]をクリックします。

ログ収集が完了すると以下通りGUIに反映があるため、[ダウンロード]を押下してログファイルを入手してください。

VxRail ver 4.7.1xx

VxRail ver 4.7.100から、VxRail ManagerがvCenter Pluginの一部として実装されています。

手順:

    1.html5 Clientへアクセスし、左ペインの[クラスタアイコン] > [設定]タブ > [VxRail > トラブルシューティング]欄を

       クリックし、"ログ コレクション"を開き、右上[作成]を選択します。

    ※旧来のVxRail Manager GUIアクセス方法( https://<VxRailManager_IP> ) で開こうとすると自動でリダイレクトされ、html5 Clientが開くようになっています

　 2.ログファイルに含めるデータを選択します。VxRail ver 4.5.x/4.0.3xxと同じデータを個別に選択可能です。

    　取得するログを選んだ後は[生成]をクリックします。

過去に複数ログを採取してVxRail Managerのログディスク容量がひっ迫している場合、

クリーンナップタスクのポップアップが表示されます。[許可する] を選択するとこれまで取得した過去のログが自動的に消去され、

収集が開始されます。必要な過去ログをローカルに保存していない場合、事前にダウンロードしたのちに新しいログを収集するようにしてください。

　3.正常にログが生成された後は対象のラジオボタンにチェックし、[ダウンロード]をクリックすれば、

　  ログのダウンロードが開始されます。

※VxRail Manager DB dumpの取得(サポートエンジニアからの指示がなければ不要)

VxRail Managerは、アプライアンス内部でクラスターの稼働状態、各種ジョブのステータス等をDB管理しています。

調査の際にはこれらのDBのダンプ情報を確認する場合がありますが、

特定の世代より古いバージョンではDBダンプがVxRailログバンドルに同梱されません。

サポートエンジニアからの指示があった場合は下記の方法でDBのコピーを取得ください。

※※Step5. 以後の手順ではESXiホストに対しscpファイル転送を行うため、ESXiにSSHが有効化されている必要があります。

SSH有効化手順については下記をご参照ください。

ESXi、vCenter、PSCのSSH有効化

・手順

1. vSphere Web ClientからVxRail Managerの仮想マシンコンソールを開き、rootとしてログイン

2. SUSEのGUIデスクトップが表示される

3. [XTerm]を選択し、ターミナルが開く

4. 以下コマンドを実行する

#DBのコピーをVxRail Managerの/tmp配下に作成

# pg_dump -U postgres mysticmanager > /tmp/db_mysticmanager_bk

# pg_dump -U postgres marvin > /tmp/db_marvin_bk

# pg_dump -U postgres spring_batch > /tmp/db_spring_batch_bk

作成したファイルの権限を設定

# chmod 755 /tmp/db_mysticmanager_bk

# chmod 755 /tmp/db_marvin_bk

# chmod 755 /tmp/db_spring_batch_bk

5. scpコマンドを利用して、任意のESXiホストの/tmp配下へログファイルを転送

# scp /tmp/db_mysticmanager_bk root@<任意のESXiホストのIPアドレス>:/tmp

# scp /tmp/db_marvin_bk root@<任意のESXiホストのIPアドレス>:/tmp

# scp /tmp/db_spring_batch_bk root@<任意のESXiホストのIPアドレス>:/tmp

6. SCPで転送先に指定した任意のESXiホストに、WinSCP等のファイル転送ソフトやコマンドラインのファイル転送を用いて、各種DBのコピーをローカルへ保存

7) ローカルへ保存後、VxRail Manager/ESXiホストのそれぞれに保存されている3つのログファイルを、rmコマンドで削除

以上

vm-supportの取得手順としては、下記のように他のコミュニティでも紹介されている通り、様々な手段があります。

ここでは、vCenterにアクセスできないなどの発生時にvCenterを使用しないvm-supportの取得が可能な手段をご紹介いたします。

vSphere Client(C#)での取得は、vCenterアクセスができない場合も使えますが、ESXi 6.5以降の場合は使用できないため、

Host ClientもしくはCLIでの取得が必要となります。

■Host Clientからのvm-support取得

　1. Web Browser経由で、ESXiホストのIPアドレスあてにアクセスします。

https://<host-ip-address>/

※ログインユーザは、Single Sign-Onの*****@vsphere.localではなく、rootなどのホストのアカウントを使用します。

　2. [ホスト]->[アクション]->[サポートバンドルの生成]とたどります。

　3. しばらくして、バンドルの収集が完了すると、下記のような画面が表示されますので、[ダウンロード]ボタンを押して、任意の場所にログを保存して下さい。

■CLIでのvm-support取得

　1. ESXiホストにsshでログインします。

sshが無効化になっている場合はESXi、vCenter、PSCのSSH有効化を参考にして有効化します。

　2. 下記のコマンドを実行します。

[esxi-example:~] vm-support

　3. 数分程待ち、下記のようにプロンプトが返ってきたらvm-supportの生成が終了となります。

01:32:39: Gathering output from /sbin/localcli --formatter=json storage nfs list

01:32:40: Gathering output from /bin/cat /var/log/vvold.log             

01:32:42: Gathering output from /usr/lib/vmware/vm-support/bin/encryption-epilog

01:32:42: Done.                                                         

Please attach this file when submitting an incident report.

To file a support incident, go to http://www.vmware.com/support/sr/sr_login.jsp

To see the files collected, check '/vmfs/volumes/DExxxxxxxxxxxx-01-01-service-datastore1/hostname.example-2018-09-02--01.28-15762050.tgz'

[esxi-example:~]

　4. WinSCPなどのファイル転送ソフトを使用し、表示されたパスに保存されたログをローカルに取得します。

※ログの取得が完了しましたら、ESXi上のログファイルは削除してください。

1. https://<host ip>/mobfdm にブラウザでアクセスし、rootユーザでログインする

2. ページ内中腹のDumpDebugInfoを選択する

3. 新しいWindowが開くので任意のファイル名を入力してInvoke Methodをクリックする

4. 対象ホストの/var/log/vmware/fdm配下に生成されるdebug dumpファイルを取得する

5. 上記1~4のステップを指示のあったホストにて実施いただき、Dell EMCへご提供をお願いします

test

test

※vCenter で発生するアラームを含んだイベントログファイルは、vc-support ログや vm-support ログに含まれません。

そのため、vCenterシステムイベントログを個別に取得してサポートに提供すると、vCenterで発生アラームの調査の際に役立ちます。

vSphere Web Client からのvCenter システムイベントログの取得手順

1. vSphere Web Client にログイン

2. Hosts and Clusters > 左ペインで vCenter を選択 > Monitor > Events > イベントリスト右下のエクスポートボタンをクリック

3. [Export Events] 画面にて、ログに含める情報を選択

　　・Events > Type > System を選択

　　　               Severity > Error, Information, Warning すべて選択(デフォルト選択のまま)

　　・Time > Last.....過去 X 時間 or X 日 or X ヶ月の期間選択

　　　            From:  mm/dd/yy   To: mm/dd/yy  でログに含める期間を選択

　　　※ 期間が長すぎるとイベントエクスポートがタイムアウトすることがあります。

　　・Limits > All matching events を選択 (デフォルト)

　　・Columns > 基本すべて選択 (デフォルト)

4.  Generate CSV Report ボタンをクリック > Collecting events data........

5. XX events match the provided criteria. のメッセージと「Save」ボタンが表示されるので、Saveをクリックし

　保存先を指定して、CSV 形式のログ・ファイルを保存

　標準ファイル名「ExportEventsLog.csv」

これで、vCenterシステムイベントログの生成は完了です。

この記事では、ESXiにてPSOD(Purple Screen of Death)が発生した場合に、出力されているメッセージの画面を取得する方法を紹介します。

1. BrowserよりBMCへアクセス(default user/passwordは admin/admin)

※Browerにてpop-up windowの制御している場合は、許可の実施をします

FireFox：Option > Allow pop-ups for <BMC IP address>  を選択

Google Chrome:右上のアイコンをクリック> ポップアップを常に許可する　を選択

2. Login後、上部のMenuから Remote Control > Console Redirection を選択

3. "Java Console"　ボタンを押す

4. JavaのViewer がDownloadされるのでを開く

※Chromeの場合は、一度Downloadを実施する必要がある場合がございます

※Javaのセキュリティのメッセージは"続行"、"実行"を選択してください

5. Virtual Console が開きます

6. PSOD画面のキャプチャーを実施

画面キャプチャソフトウェアやスクリーンショットにて画面のキャプチャーを取得してください

キャプチャーを実施する際には、メッセージがすべて表示されている状態にてお願いいたします。

複数枚になっても問題ございません

(最上部にはESXiのVersionが表示されます)

この記事では、VMware vRealize Log InsightのLog(diagnostic information)の取得手順を紹介します。

GUIからのLog取得方法

※VersionによってGUIの画面に違いがある可能性がございます

1. https://<Log Insight IP or Log Insight hostname> にWebブラウザでアクセスし、admin userにてLoginを実施

2.  右上にあるマーク("三")をクリックし、"Administration"を選択

3. Management 欄にある "Cluster" > "Download Support Bundle"  > "Static support bundle"の順に選択し

　Continue ボタンをクリック

※下記のようなメッセージが出ましたら保存を押してLogのDownloadを開始してください

4. Log生成中はDownload Support Bundle部分に"Generating Bundle"と表示され、生成が完了すると再度ボタンが押せるようになります

CLIからのLog取得方法

1.teratermなどのターミナルソフトウェアから、LogInsightにrootでSSH接続を実施

※rootユーザを使用する際にはpasswordの設定が必要な場合がございます

認証が上手くいかない場合は下記の手順を参考に設定をお願いいたします

vRealize Log Insight 仮想アプライアンス用の root の SSH パスワードの構成

2. /tmpフォルダに移動し以下コマンドを実行し、ログの収集を開始

loginsight-support

生成が完了するとloginsight-support-<日付>.tar.gzといったファイルが作成されます

WinSCPなどを使用してローカルにファイルを保存してください

3. ローカルにファイルを保存を実施したら、下記のようなrm コマンドにてLogを削除

rm loginsight-support-<日付>.tar.gz

Licenseの確認方法

契約上の観点により、お客様が使用しているLicense情報の確認を実施させていただく場合がございます。

下記の手順を参考にLicense情報のご取得をお願いいたします。

1. https://<Log Insight IP or Log Insight hostname> にWebブラウザでアクセスし、admin userにてLoginを実施

2.  右上にあるマーク("三")をクリックし、"Administration"を選択

3. Management 欄にある "License"を選択し、Keyの文字列が確認できるように画面キャプチャをお願いいたします

この文書では、VxRailでESXi等からLog InsightへSyslog転送したログをExportする方法について紹介します。

※VersionによってGUIの画面に違いがある可能性がございます

Log Insightにsyslogを転送するための設定手順は、以下のVMware Documentをご参照下さい。

vRealize Log Insightにログ イベントを転送するための ESXi ホストの構成

1.https://<Log Insight IP or Log Insight hostname> にWebブラウザでアクセスし、admin userにてLoginを実施します。

2. adminユーザーでのログイン後、画面左上の[Interactive Analytics]をクリックします。

3.Log Insightでは、最大20,000イベントまでしかExportできません。

　以下で、必要なログをすべてExportするための日時指定の例、Filterの例を紹介します。

　■ 日時指定の例

　下の図のように、三角(▼)のボタンをクリックし、ログを確認したい期間を選択します。

　Custom time rangeを選択した場合、下の図のように、取得時間をマニュアルで入力できるようになります。

　カレンダーマークをクリックすると、カレンダーから日付を選択することもできます。

  ■ Filterの例

  Log Insight画面の左側の[+Add Filter]よりFilterを設定します。

  ログをExportしたい対象のホスト名を指定するには、"hostname"、

  Exportしたいログの種類(vmkernel, hostd, vpxa等)を指定するには、"appname"を指定します。

4.日時指定、Filterの設定を実施した後、日時指定する欄の横の虫眼鏡マークをクリックします。

5.画面にイベント一覧が出ます。

　Event一覧の表示される画面右側に日時、Filterした条件にマッチしたイベントの総数が出ますので、

　20,000件以内であるかご確認ください。

　20,000件を超えるようでしたら、全てのイベントがエクスポートできませんので3の手順で日時指定等を変更してください。

6.このままログをExportすると、新しいイベントが先頭に表示されるため、Event一覧の 表示される画面の右側の[Sort:]欄より、

　[Oldest First]を選択して、古いログから表示されるように変更します。

7.画面右端の[Export or Share Current query]のボタンをクリックしてして、[Export Event Results]をクリックします。

8. Export するフォーマットを指定します。

　[Raw events]　TXT形式で保存されます。　

　[JSON]　JSON形式で保存されます。

　[CSV]　CSV形式で保存されます。

　Exportをクリックします。

9.ログのExportが完了し、ブラウザよりファイルを保存する旨のダイアログが表示されましたらファイルを保存してください。

• Introduction
• A Typical Single NIC DMZ Deployment
• Separating Unauthenticated User Traffic from Backend and Management Traffic
• Routing

Introduction

VMware UAG is a virtual appliance used by several End-User Computing products to support remote access from the Internet into applications and virtual desktops running in corporate data centres or in the cloud. It is a layer 7 security appliance that is normally installed in a De-militarized Zone (DMZ) and is used to ensure that the only traffic entering the corporate data center is traffic on behalf of a strongly authenticated remote user. You can read more details of this here Technical Introduction to UAG for Secure Remote Access - VMware End-User Computing Blog - VMware Blogs

UAG is usually installed by using a PowerShell command. This avoids the need to use a GUI and simplifies installation allowing all configuration settings to be precisely applied so that the appliance is secure and production ready on first boot. See Using PowerShell to Deploy VMware UAG.

One of the configuration settings for UAG is the number of virtual Network Internet Cards (NICs) to use. UAG has a deploymentOption settings which is specified as onenic, twonic or threenic. Each NIC must be on a separate segment so onenic, twonic or threenic corresponds to environments with one, two or three segments respectively.

The use of multiple physical networks or vLANS within a DMZ is not new. Reducing the number of open ports on each vLAN/segment and separating out the different types of network traffic can significantly improve security. This post describes the purpose of multiple NICs with UAG and outlines some of the security and performance benefits. The benefits are mainly in terms of separating and isolating the different types of network traffic as part of a defense-in-depth DMZ security design strategy. This can be achieved either by implementing separate physical switches within the DMZ, with multiple vLANs within the DMZ or as part of a full NSX managed DMZ.

A Typical Single NIC DMZ Deployment

The simplest deployment of UAG is with a single NIC where all network traffic is combined onto a single network. This works well for a simple DMZ. Traffic from the Internet facing firewall is directed to one of the available UAG appliances. Authorized traffic is then forwarded by UAG via the Inner firewall to resources on the internal network. Unauthorized traffic is discarded by UAG.

Figure 1 - UAG ONENIC Option

Separating Unauthenticated User Traffic from Backend and Management Traffic

An improvement over the single NIC deployment is to specify 2 NICs. The first is still used for Internet facing unauthenticated access, but the backend authenticated traffic and management traffic are separated onto a different network as shown in figure 2 below.

Figure 2 - UAG TWONIC Option

In this two NIC deployment, traffic going to the internal network via the inner firewall must have been authorized by UAG as any unauthorized traffic will not be on this backend network. Management traffic such as the REST API for UAG will only be on this second network.

If a device on the unauthenticated front-end network was compromised, such as the load balancer, then reconfiguring that device to bypass UAG would still not be possible in this two NIC deployment. It combines layer 4 firewall rules with layer 7 UAG security. Similarly, if the Internet facing firewall was misconfigured to allow TCP port 9443 through, this would still not expose the UAG Management REST API to Internet users. A defense-in-depth principle uses multiple levels of protection, such as knowing that a single configuration mistake or system attack will not necessarily create an overall vulnerability.

In a two NIC deployment, it is common to put additional infrastructure systems such as DNS servers, RSA SecurID Authentication Manager servers etc. on the backend network within the DMZ so that they can not be visible on the Internet facing network. This guards against layer 2 attacks from the internet facing LAN from a compromised front-end system and effectively reduces the overall attack surface.

Most UAG network traffic is the display protocols for Blast and PCoIP. With a single NIC, display protocol traffic to/from the Internet is combined with traffic to/from the backend systems. When two or more NICs are used, the traffic is spread across front-end and back-end NICs and networks. This can result in performance benefits by reducing the potential bottleneck of a single NIC.

VMware's own deployments of UAG such as for Horizon Air, uses the two NIC deployment approach.

UAG supports a further separation by also allowing separation of the management traffic onto a specific management LAN. HTTPS management traffic to port 9443 is then only possible from the management LAN. This final option is shown in figure 3 below.

Figure 3 - UAG THREENIC Option

Routing

During UAG deployment it is common to specify a default gateway. In complex environments involving multiple NICs and routing through more than one gateway, UAG also supports the ability to specify explicit IP routes. These are routes that don't use the default gateway.

For example, with a TWONIC UAG deployment, the network routing may involve a default gateway for all IP traffic destined for Internet located devices. Additionally network routing to the Internal Network may involving routing through a separate back-end gateway.

Front-end DMZ Network: 192.168.9.0/24

UAG Front-end IP address (ip0): 192.168.9.51

Internet Access gateway: 192.168.9.1

Backend and Management DMZ Network: 192.168.0.0/24

UAG Back-end IP address (ip1): 192.168.0.51

Internal network Access gateway: 192.168.0.1

Internal Network: 10.0.0.0/16

The configuration for UAG would be:

ip0=192.168.9.51

ip1=192.168.0.51

defaultGatteway=192.168.9.1

routes1=10.0.0.0/16 192.168.0.1

When UAG needs to connect to a host on the Internal network with an IP address of say 10.0.0.120, the routing entry on UAG would force this connection to go via the back-end gateway 192.168.0.1 on the second NIC (eth1). The NIC used by UAG for any outgoing IP traffic is selected based on the destination IP address and for destinations not on any local segment, the contents of the routing table. For any destination not on any of the local segments, UAG will look for an explicit route for that network. If no routes are found, it will direct traffic via the default gateway which is normally the gateway to the Internet.

From the UAG console, where you login as root, you can run "ifconfig" to look at the addresses for each NIC (eth0 and eth1 in a TWONIC setup) and run the "route -n" command to show the active routing table.

Figure 4 - UAG Console showing ifconfig and route commands

To check the routing table for any IP destination address you can run the "tracepath -n destination-ip-address-or-hostname" to see details of the route.

Figure 5 - UAG Console showing route and tracepath commands

vCenter サーバのライセンスにバンドルされるvRealize Log insightのUpgrade方法です。

!!!!! 注意 !!!!!

vRealize Log InsightのUpgradeはVxRailのサポートに含まれません。

VxRailのUpgradeの際にvRealize Log InsightはUpgradeされませんので、お客様にて事前にUpgradeを実施いただく必要があります。

本資料は参考資料としていただき、正式な手順についてはVMware社のドキュメントをご参照ください。

↓↓ VMware社のドキュメント

vRealize Log Insight のアップグレード

### vRealize Log Insight Upgrade 手順 ###

現在のVersionの確認

vRealize Log Insightにブラウザでアクセスして、admin ユーザでログインしてください。

以下の図を参考に現在のVersionをご確認ください

互換性を確認

以下のVMwareのサイトよりUpgradeターゲットのVxRailに含まれるESXiとVCSAとの互換性を確認して

ターゲットコードを決めてください。

VMware Product Interoperability Matrices

Upgrade Pathを確認

以下のVMwareのサイトより、現行のVersionとターゲットVersionとのUpgrade Pathを確認してください。

※Versionによっては2段階、3段階のUpgradeとなる場合があります。

Upgradeファイルをダウンロード

VMwareのサイトよりターゲットコードのUpgrade ファイル（.pakファイル）をダウンロードください

検索エンジンで検索すると簡単に見つけられます。

Snapshotを取得

Upgrade前にWebClientからSnapshotをご取得ください。もしくはバックアップSolutionよりバックアップをご取得ください。

vRealize Log InsightにログインしてUpgradeを実行

以下の手順を参考にUpgradeを実施ください

１．vRealize Log Insightへログイン（admin ユーザ）

２．管理画面へ移動

３．クラスタタブに移動してUpgradeを選択

あとはGUIの案内に従いUpgradeを完了してください。Upgradeは10分ほどで完了しました。

↓のGIF動画をご参考ください

最後にUpgrade後のVersionをご確認ください。

この文書はVxRail 4.0.x -> 4.5.xへのUpgradeに関連する変更点や留意事項についてまとめています。

##VxRail: 4.0.x -> 4.5.x へのUpgradeに事前と事後の留意点について ##

Upgrade前の留意点

VxRail 4.0.xと4.5.xの差異についてのサマリ

もっとも大きな差異はvSphere のVersionが6.0から6.5になることです。

vSphereと連携するSolutionの互換性について事前の確認が必要になります。

Solutionの互換性以外では、vSphere 6.5へのUpgradeに伴い以下のような代表的な変更が発生します。

• VCSA/PSCがSUSEベースからPhoton OSベースに変わる
  • これまでのUpgradeと異なり、新しいVCSA/PSC VMを作成し、データがマイグレーションされます。ベースOSが異なりますのでSSHした時など若干使用感が異なります。
  • 古いVCSA/PSCはPowerOff状態で保持されます。（手動の削除が必要です。後述）
• vSANのVersionが6.6.1になる
  • vSAN EncryptionやiSCSI ターゲットなどの新機能が使用可能になります。
  • 新機能の使用にはDisk Format のVersion Upgradeが必要です。
  • vSANの管理疎通がマルチキャストからユニキャストに変わります。
  • その他vSAN 6.6の新機能は以下をご参照ください
    • What's New in VMware vSAN 6.6
• GUIの仕様が変わる
  • vSphere Client (Thick Client, C# clientとも呼ばれた)からアクセス不可となり、WebClient（Flash版）もしくはHTML5 Clientからのみアクセス可能です。
  • GUIのデザインも若干変更になっています。
• vDSのVersionが上がる
  • VxRail用VDSのVersionが6.0から6.5にUpgradeされます。
  • お客様にて追加されたVDSのVersionは上がりません

その他のvSphere 6.5の新機能については以下のVMware Documentをご参照ください。

https://www.vmware.com/content/dam/digitalmarketing/vmware/ja/pdf/whitepaper/vsphere/vmw-white-paper-vsphr-whats-new-6-5.pdf

詳細なUpgrade前後のVersionの確認方法について

Upgrade前後のSolutionの互換性を確認するにあたり、まずは詳細なvSphere コンポーネントのVersionを知る必要があります。

Upgrade前（VxRail 4.0.x）のVersionについてはVxRail のVersionがわかれば確認できます。

もしくは、WebClientなどから各コンポーネントのVersionをご確認いただくこともできます。

VxRailのVersionがわかる場合はRelease Noteから詳細なvSphere コンポーネントのVersionを確認可能です。

・VxRail 4.0.x リリースノート（英語のみ）

https://support.emc.com/docu80740_VxRail-Appliance-Software-4.0.x-Release-Notes.pdf

※VxRailのVersionはVxRail Manager GUIより確認可能です。以下の図をご参考にしてください

Upgrade後のVersion（ターゲットVersion：VxRail 4.5.x）のvSphere コンポーネントの詳細についてはVxRail 4.5.xのリリースノートをご参照いただけます。

・VxRail 4.5.x リリースノート（英語のみ）

https://support.emc.com/docu86659_VxRail-Appliance-Software-4.5.x-Release-Notes.pdf

vSphere と連携するソフトウェアの互換性について

お客様にてご使用中のvSphere と連携するVMware / 3rd Solutionがある場合、各Solutionのアップグレードが事前もしくは事後に必要になる可能性があります。

VxRail関連のバージョンにVMware Solutionが対応しているか否かは以下をご確認いただけます

https://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php

更新の順序については以下のVMware KBをご参照ください。

https://kb.vmware.com/kb/2148021

例：VDP 6.1.3以下をご利用の場合は4.5.xにUpgradeするまえにVDPを6.1.4以上にUpgradeする必要があります。

NSX 6.2をご利用の場合は4.5.xにUpgradeするまえに6.3以上にUpgradeする必要があります。

3rd Party Solutionにつきましては各ベンダに互換性をご確認ください。

VxRailのライセンスにバンドルされるソフトウェアコンポーネントに関する留意点

VxRailに含まれるソフトウェアコンポーネントのすべてがUpgrade作業によってUpgradeされるわけではありません。

VxRailのUpgrade作業によってUpgradeされるコンポーネントは以下です。

※VxRail Upgradeファイル以外の更新（個別のVIBやパッチを適用）を実施することはサポート外になりますのでご注意ください。

・ESXi（追加のVIBも含む）

・VSAN

・VCSA/PSC（外部VCの場合は除外）

・Firmware （BIOS,iDRAC,HBAなど、Versionやモデルに依存します。）

・VxRail Manager VM

Upgradeされないものは以下です。

※UpgradeはVersion管理（互換性など）はお客様管理になります。

・VDP （お客様作業になります。参考手順：https://community.emc.com/docs/DOC-65505）

・RP4VM  （別途サポート窓口にお問い合わせください）

・CloudArray （別途サポート窓口にお問い合わせください）

・Loginsight （お客様作業になります。 参考手順： https://community.emc.com/docs/DOC-65504）

・ESRS （お客様作業になります。 参考手順： VxRail: ESRSVE VMのUpdate 手順（参考資料））

・既存VMのHardwareVersion（Intel CPUの脆弱性の対応で必要です）

・ESRSの内部イメージ（内部イメージは出荷時から変わりません）

・ESXiのファクトリーイメージ（出荷時から変わりません）

※ その他vSphereと連携するDell EMC製品（UnityVSA、IsilonSD Edge、AvamaerVEなど）についてはサポート窓口にお問い合わせください。

※ その他vSphereと連携するSolution（NSX/VDI/vRangerなどその他3rdパーティ製品すべて） についてはすべてお客様作業範囲となります。

Upgrade時に準備いただくもの

4.0.x -> 4.5.xのUpgradeの際に以下をお客様にご準備いただきます。

・一時IPアドレス（１つ）

VxRailのUpgradeの際に一時的に利用されます。

VxRail 4.0.x -> 4.5.x のUpgradeの際にVCSAとPSCのVersionが6.0 -> 6.5にUpgradeされます。

このUpgradeは従来のOS内部の更新という形ではなく、新規VMの構築＆データ移行という形で実行されます。

そのため旧VCSA/PSC（6.0）から新VCSA/PSC（6.5）へのデータ移行する際に、新VCSA/PSCへ仮のIPアドレスを割り当てる必要があり、その際に使われる一時的なIPアドレスが、一時IPアドレスです。

Upgrade完了後はそれまでのVCSA/PSCのIPアドレスが使用されますので、一時IPアドレスがUpgrade後も使用されることはありません。

一時IPアドレスはVCSA/PSC/VxRail Managerと同じサブネットのIPアドレスでご用意ください。

一時IPアドレスの確保が難しい場合はLogInsight VMやESRSVE VMなどUpgrade時に必要のないSystem VMをShutdownし、そのIPアドレスを利用することができます。

※一時IP Addressは未使用でかつ同じサブネットでなくてはいけません。もしIPが使用されていた場合はUpgradeに失敗します。（KB#522181）

・お客様環境DNSサーバ（1つ以上2つまで）

VxRail 4.5からはお客様環境のDNS設定が必須となりました。（VxRail 4.0までは無くても構築可能）

したがってVxRail 4.5.xにUpgradeする前にお客様環境のDNSサーバをご準備いただく必要があります。

VxRail 4.0の構築時にご準備いただいたものがあればそれを流用可能です。

お客様にご準備いただくDNSサーバは以下の要件を満たす必要があります。

1. VxRail上に存在しないこと（VxRailが管理するESXi上のVMでないこと）
2. VxRailのコンポーネント(下記参照)からアクセス可能であり、各コンポーネントの名前解決ができること。

• VxRail Manager VM
• VCSA/PSC
• ESXi

Upgrade後の留意点

「vSAN ビルドに関する推奨事項エンジンの健全性」について

VCSAがインターネット経由でVMware社にアクセスできないことに起因しております。

Proxyサーバを設定することでも対処可能ですが、VCSAのインターネットへのアクセスを希望しない場合はこの警告を静観していただくか、もしくはこの項目自体を無効にする必要があります。

この項目のチェックを無効にする手順は下記のコミュニティ投稿をご参考にしてください

https://community.emc.com/message/1000585

古いVCSAおよびPSC VMの削除について

Upgrade前に使用していた古いVCSAが「VMware vCenter Server Appliance（legacy）」としてインベントリに残ります。

Upgradeが失敗した場合はロールバックとして使用する可能性があるものですが、完了後は基本的に不要です。

お客様のご判断にても不要であれば、Upgrade完了後に削除をお願いいたします。

PSC VMについても同様です。

Intel CPU脆弱性の対応について

VxRail 4.5.152以降にはIntel CPUのセキュリティ脆弱性についての修正が含まれております。

VMwareの環境では、Upgradeしただけでは修正が個々の仮想マシンに適用されません。

修正が必要な仮想マシンにたいして以下の対処を実施お願いいたします。

### 補足 ###

※セキュリティ対策が不要な場合は実施不要です。

※VxRail 4.0.402にはすでにセキュリティ脆弱性への修正が含まれております。4.0.402にUpgradeした際に同様の対応を実施していた場合は不要です。

※下記の説明文中SystemVMとは以下のVxRail によって自動デプロイされた以下のVMのことです。

• VxRail Manager
• VCSA（外部VC構成の場合は無）
• PSC（外部VC構成の場合は無）
• LogInsight （オプション）

##########

― すべてのお客様仮想マシンに対して以下の対処を実施ください  ※System VMを除く

1. GuestOSレベルでの修正を適用ください。修正についてはOSベンダにお問い合わせください

2. 仮想マシンハードウェアをVersion 9以上にしてください。

     ※すでにVersion 9 以上のものに関しては対応不要です。

3. 対象のVMをShutdownし、完全にPower Off状態となったのち、PowerONしてください。※RebootではなくPowerCycleが必要です。

― System VMに対して以下の作業を実施ください

1. 上記「すべてのお客様仮想マシンに対して」のStep2とStep3のみ（PowerCycle）を実行ください。Step1の実施は不要です。

※以下の順序で実施してください

① VxRail Manager

② vRealize Log Insight [if deployed]

③ vCenter Server Platform Service Controller (PSC) [if Internal]

④ vCenter Server Appliance (VCSA) [if Internal]

※PSC/VCSAをPower Offすると認証およびWebClientへのアクセスができなくなります。WebClientへのアクセスが失われた場合、これらのVMのPowerOn作業は各ESXiのHostClientにて実施する必要があります。そのため、PSC/VCSAについてはあらかじめどのNodeにて稼働しているのかをご確認いただくことをお勧めします。

ESRSVEのUpdateについて

ESRSVE VMについてIntel CPUのセキュリティ脆弱性についての対処をご希望の場合は以下を実施する必要があります。

1. ESRSVE VMのSnapshotを取得

2. ESRSVEを最新VersionへのUpdate （※手順は添付。Downloadはお客様のネットワーク環境に依存して2時間以上かかることがあります）

3. ESRSVE VMの仮想ハードウェアVersionを最新にする

4. Dell EMCへ接続性チェックを依頼。※このメールスレッドにてご依頼ください

5. 正常性を確認後、Snapshotを削除。※VSANデータストア上にVMについては必ずしも削除は必要ではありません

※上記はすべて以下のコミュニティ文書にて詳しく解説されていますのでご参照ください。

VxRail: ESRSVE VMのUpdate 手順（参考資料）

仮想分散スイッチのUpgrade

VxRailのVersionが4.0 -> 4.5になることでvSphereのVersionが6.0 -> 6.5になるため、VxRailが管理している最初の仮想分散スイッチについても自動的にVDS version 6.5にUpgradeされますが、お客様にて作成された分散スイッチは対象外となります。必要に応じて手動で分散スイッチのUpgradeを実施してください。

・仮想分散スイッチのUpgrade方法

Upgrade a vSphere Distributed Switch to a Later Version

Password有効期限の変更など、デフォルト値からの変更について

既存のVCSA/PSCに対してPasswordの有効期限の変更などを実施していた場合はUpgradeによって設定がデフォルトに戻ります。これはUpgradeの過程で新しいVCSA/PSC VMの作成→移行というプロセスを経ているためです。

ほとんどの場合はPassword有効期限に対する変更のみと思いますが、実施していた場合は再設定が必要になります。

CVE-2018-3646に関するアラートの対応（2018/12/25 update!）

Upgrade後、もしくはUpgrade中にWebClient GUI上に、CVE-2018-3646に関するアラートが表示される場合があります。

こちらもIntel CPUの脆弱性に関するものであり、下記のコミュニティ文書を参考に対応方針（修正の適用 or 静観）を蹴っていただき、必要であれば対応を実施していただく形になります。

https://community.emc.com/docs/DOC-69933

この記事ではVxRail Gen3以降に採用されているiDRACリセットの手順を紹介します。

※VxRailのプラットフォームに利用されているPowerEdgeの世代によりiDRACバージョンが異なります。

-iDRAC8(PowerEdge 13Gモデル)

1. iDRACにログイン(デフォルト:root/calvin)

2. 概要 > サーバー より"iDRACのリセット"をクリック

3. 警告ダイアログでOKを選択

4. iDRACリセットが開始される

※しばらくの間iDRACにアクセスできなくなります。

5. 対象のESXiホストにSSHログイン

VxRailのSSH有効化手順についてはこちら

VxRail: ESXi、vCenter、PSCのSSH有効化

6. 下記コマンドを実行(ESXiで稼働している"sensor"のステータス確認)

[esxi-example:~] /etc/init.d/sensord status

出力が下記の場合は、手順7の実施

[esxi-example:~] /etc/init.d/sensord status

sensord is not running.

※"sensord is running"の場合は手順7の実施は必要ございません

7. 下記コマンドを実行（"sensor"のサービススタート）

[esxi-example:~] /etc/init.d/sensord start

sensord started

 

[esxi-example:~] /etc/init.d/sensord status

sensord is running

"sensord is running"になっていることを確認

-iDRAC9(PowerEdge 14Gモデル)

1. iDRACにログイン(デフォルト:root/calvin)

2. メンテナンス> 診断 > iDRACのリセット

3. 警告ダイアログでOKを選択

4. 成功ダイアログでOKを選択すると、ページからログアウトされる

※しばらくの間iDRACにアクセスできなくなります。

5. 対象のESXiホストにSSHログイン

VxRailのSSH有効化手順についてはこちら

VxRail: ESXi、vCenter、PSCのSSH有効化

6. 下記コマンドを実行(ESXiで稼働している"sensor"のステータス確認)

[esxi-example:~] /etc/init.d/sensord status

出力が下記の場合は、手順7の実施

[esxi-example:~] /etc/init.d/sensord status

sensord is not running.

※"sensord is running"の場合は手順7の実施は必要ございません

7. 下記コマンドを実行（"sensor"のサービススタート）

[esxi-example:~] /etc/init.d/sensord start

sensord started

 

[esxi-example:~] /etc/init.d/sensord status

sensord is running

"sensord is running"になっていることを確認

-CLIからのiDRACリセット

1. 対象のESXiホストにSSHログイン

VxRailのSSH有効化手順についてはこちら

VxRail: ESXi、vCenter、PSCのSSH有効化

2. 下記コマンド実行

[esxi-example:~] /opt/dell/DellPTAgent/bin/ipmitool_static mc reset cold

Sent cold reset command to MC

**** もし /opt/dell/DellPTAgent/bin/ipmitool_static が見つからない時は以下のコマンドをお試しください。

# /scratch/dell/DellPTAgent/bin/ipmitool_static mc reset cold

# /opt/vxrail/tools/ipmitool mc reset cold

3. 下記コマンドを実行(ESXiで稼働している"sensor"のステータス確認)

[esxi-example:~] /etc/init.d/sensord status

出力が下記の場合は、手順4の実施

[esxi-example:~] /etc/init.d/sensord status

sensord is not running.

※"sensord is running"の場合は手順4の実施は必要ございません

4. 下記コマンドを実行（"sensor"のサービススタート）

[esxi-example:~] /etc/init.d/sensord start

sensord started

 

 

[esxi-example:~] /etc/init.d/sensord status

sensord is running

"sensord is running"になっていることを確認

-付録

※iDRACリセットに伴い、vSphere Web ClientやVxRail Manager GUIに後述のようなアラームが表示される場合があります。

- ネットワーク接続のアラーム

iDRACリセットによってiDRACポートがDown/Upしたことによる影響です。

iDRACリセット完了に伴いポートも復帰しますので、本記事の手順を実施したタイミングでこのアラームが発生した場合はWeb Client上のアラームを"緑にリセット"してください。

-VxRail Manager上の関連アラーム

下記のようなアラームがリセットの際に発生した場合も、iDRACリセットの影響ですので既読にするか無視してください。

以上

###関連記事

Dell Japan ナレッジベース

[iDRAC] リセット手順 | Dell 日本

Dell EMC ナレッジベース

VxRail: How can I reset iDRAC and restart PTagent ? (公開範囲が限定されています)

https://support.emc.com/kb/511713

VxRail: How to reset the internal Dell Remote Access Controller (iDRAC) on a PowerEdge server?

https://support.emc.com/kb/512561

VxRail: After resetting the iDRAC, ESXi sensord does not start automatically

https://support.emc.com/kb/526623