この文書では、vSANクラスターのディスクリバランス(再分散)の手順を紹介します。

vSANの健全性テスト結果で頻繁に目にする"vSANディスクバランス"の警告ですが、

GUIのボタンから手動でリバランス(再分散)を実施しても、またすぐに警告が再発してしまうことがあります。

これは、ディスクバランスの警告発生の閾値が"最大分散値30"に設定されていることに起因しています。

分散について:

VxRail、及びvSANクラスターでは、より良いバランスでクラスターを使用するために、各ディスクの使用率の差分が全体で30%以下となるよう閾値を設けています。

例えば、ディスク A の使用率が 45% で、ディスク B が 10% の場合、ディスク A と B の負荷分散は 35 で、閾値を超えたとみなします。この使用率の差分を"分散"とVMwareでは表現しています。

最大分散は、上記の分散値が最も高いディスクの組み合わせ(=クラスター内で最も使用されているディスクと最も使用されていないディスク)を元に取られています。

つまり、最大分散は下記の計算式で導出されています。

最も使用率の高いディスクの使用率(%) - 最も使用率の低いディスクの使用率(%) = 最大分散

vSANはクラスター内のディスクの使用率を監視しており、分散が30を超えるディスクの組み合わせが発生すると健全性テストにディスクリバランスの警告を表示します。

GUIから行うリバランスでは、分散がデフォルトの閾値である30を上回るディスクがなくなった時点でプロセスが自動で完了しますので、

一旦警告が消えても再発しやすい状態のままになってしまうことがあります。

警告の再発を抑止する目的で、閾値である最大分散値30を更に下回った状態(例えば20、10等)のレベルにまでリバランスを実施する場合は、GUIからではなくCLIからリバランスを実施する必要があります。

※ただし、30を大きく下回る値にまでリバランスを実施する場合は、その分大量のデータの移行が発生し、処理により長い時間を要します。

よってこの様な大きなリバランスを行う際は、数日間かけてリバランスを複数回行う、または一晩リバランスを行った後に進捗を確認し、継続して行うか検討する、等ある程度計画的に実施することを推奨いたします。

※vSANディスクバランスの警告は、一般的には障害や不具合の発生を示すものではありません。通常運用内でvSANがI/Oを行った結果発生する場合が大半です。

また、一度警告が発生しても、その後に更にI/Oが行われた結果各ディスクの使用率が均等になり、警告が消える場合もあります。

**vSANディスクバランスの警告に関する包括的な内容については下記の記事を参照ください

VxRail: 「Virtual SAN ディスク バランス」の警告の詳細と対処

・CLIによるvSANリバランス手順

GUIでリバランスを実施した後すぐに警告が再発してしまった・ディスクバランスの警告の表示を可能な限り抑制したい・等の場合は、下記の手順でCLIでのリバランスを実施してください。

[1]. vCenter Server Appliance にSSHにてログイン後、Shellに遷移(プロンプトのマーカが#になっている状態)

    ※vCSAのSSHを無効化している場合は、下記手順にて有効化が必要です。

    ESXi、vCenter、PSCのSSH有効化

Command> shell.set --enabled True

Command> shell

Shell access is granted to root

root@vc [ ~ ]#

[2]. vCenter Server Appliance 上で、下記のコマンドでRuby vSphere Consoleにログイン

# rvc

Install the "ffi" gem for better tab completion.

Host to connect to (user@host): administrator@vsphere.local@localhost  < vCenter SSO ユーザー名@localhostを入力

password:                                                                                          < vCenter SSO パスワードを入力

0 /

1 localhost/

>

[3]. RVCにログイン後、一般的なUnixベースOSと同じ要領でlsコマンド、cdコマンドが使えるので、

/localhost/データセンター名/computers/ まで移動し、lsでvSANクラスターのリソースについているインデックスを確認

(例) ※画像はクリックで拡大してください

[4].下記コマンドを実施

vsan.proactive_rebalance

(例)

/localhost/データセンター名/computers/> vsan.proactive_rebalance 0 -sv 0.3

vsan.proactive_rebalanceはリバランスを手動で実行するコマンド、0は対象のvSANクラスタリソースのインデックスです。

-sオプションでリバランス開始、-vオプションでどこまでリバランスを実施するかの閾値を指定します。

-vの後に指定する数字がリバランスの閾値(=最大分散値)で、例では0.3、つまりデフォルトの30%を指定しています。

更に均等なリバランスを実行したい場合は、0.2、0.1等小さい数字を指定してください。

また、-tオプションを追加で指定することで、リバランスを実行する期間(秒単位)を設定できます。

ディスクのリバランスは大量のIOが発生するため、仮想マシンのパフォーマンスに影響を与える惧れがありますが、

-tオプションによって、終業後にコマンドを実行してリバランスを開始し、始業時間の前にリバランスを自動で停止する等、ユーザー環境に合わせて業務に影響のないペースでオペレーションを実施することができます。

-tオプションを指定しなかった場合は、デフォルトの24時間リバランスが実施されます。

例えば、最大分散値20までのリバランスを14時間(5万4百秒=終業時刻18時から翌日始業前の8時までを想定)実施したい場合は、下記のようなオプションを指定します。

> vsan.proactive_rebalance 0 -sv 0.2 -t 50400

[5].下記コマンドでリバランスの状態を確認

> vsan.proactive_rebalance_info 0

(例)

/localhost/データセンター名/computers/> vsan.proactive_rebalance_info 0

 

Proactive rebalance start: 2018-06-28 03:06:07 UTC                                    ←リバランス開始時刻

Proactive rebalance stop: 2018-06-28 17:06:07 UTC                                     ←リバランス完了予定時刻

Max usage difference triggering rebalancing: 10.00%                                       ←リバランス目標の分散閾値(※この例では0.1=10%に設定)

Average disk usage: 10.00%                                                                                                                               

Maximum disk usage: 20.00% (18.00% above minimum disk usage)                                                                   

Imbalance index: 8.00%                                                                                                               

Disks to be rebalanced:                                                                             ↓リバランス対象となっているディスクの一覧 +----------------------+----------------+----------------------------+--------------+                                                       

| DisplayName                      | Host                      | Disk usage above threshold           | Data to move      | 

+----------------------+----------------+----------------------------+--------------+                                                                       

| naa.xxxxxxxxxxxxxxxx         | sds-01.sds.lab         | 4.00%                                          | 44.7122 GB        |

| naa.xxxxxxxxxxxxxxxx         | sds-01.sds.lab         | 2.00%                                          | 22.3561 GB        |

+----------------------+----------------+----------------------------+--------------+                                                       

| naa.xxxxxxxxxxxxxxxx         | sds-03.sds.lab        | 3.00%                                           | 33.5341 GB        |

| naa.xxxxxxxxxxxxxxxx         | sds-03.sds.lab         | 8.00%                                          | 89.4244 GB        |

+----------------------+----------------+----------------------------+--------------+                                                                   

| naa.xxxxxxxxxxxxxxxx         | sds-04.sds.lab         | 1.00%                                          | 11.1780 GB        |        

+----------------------+----------------+----------------------------+--------------+

[5].下記のコマンド、またはGUIの[リバランスの中止]ボタンでいつでもリバランス処理の停止が可能です。

> vsan.proactive_rebalance 0 -o

以上

関連記事:

VxRail: 「Virtual SAN ディスク バランス」の警告の詳細と対処

参考文献:

rvcコマンドの詳細については、下記リファレンスを参照ください(リバランス関連の項目はp59,61)。

VMware® Ruby vSphere Console Command Reference for Virtual SAN

VMware ドキュメント

vSAN クラスタのリバランスについて

VMware ナレッジベース

vSAN 健全性サービス -クラスタの健全性 - vSAN ディスク バランス (2147613)

vSAN のプロアクティブなリバランス (2152028)

「Virtual SAN ディスク バランス」の概要

Virtual SAN（vSAN）では、各ディスクの使用率が均等であることが推奨されています。

通常、新しいVM（vmdkファイル等）がvSAN データストア上に作成される際に、各ディスクの使用率からバランスのとれた容量使用率となるように分散される形でvSAN Object（vmdkファイル等）が作成されますが、障害やvmdkファイルの拡張の不均衡などによって、vSANで使用されるDiskの容量使用率が徐々に不均等になり、閾値（30%）を超えると警告が発報され、vSANのヘルスチェック画面で「Virtual SAN ディスクバランス」の警告が表示されます。

この警告は仮想マシンの稼働やデータの可用性への影響はありませんが、容量使用率の不均衡があまりにも大きくなると、障害時のリスク増加や、パフォーマンス問題につながることがございます。

特に最大ディスク使用率が80％に達したときに、自動的にリバランス（データの再配置）が作動する仕組みとなっているため、予期せぬタイミングで自動リバランスが行われ、業務時間中であればパフォーマンス影響が出る可能性があります。

そのような事態を未然に防ぐため、最大分散が30％以上になったというアラームにより、業務影響のない時間帯に手動リバランスを実施したほうが良いことを知らせています。

以下が参考 KB です。

vSAN 健全性サービス - 物理ディスクの健全性 - ディスク容量 (2148593)

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

vSAN のプロアクティブなリバランス (2152028)

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

手動でのリバランス方法

GUIを使用した手動リバランス

自動リバランスは開始などの制御ができないため、vSAN Health Check時に最大分散(Maximum Variance)が30％を超えた場合にアラートを表示します。

まずは下図を参考に、vSANのヘルスチェック画面を開いてください。

Health Checkテスト名の ”クラスタ” を展開するとVirtual SAN ディスクバランスが表示されます。

警告が出ている場合、下記の”ディスクの再分散”のボタン（英語だとProactive Rebalance Disks）が有効になります。

※最大分散が30％で警告が出ていない場合はボタンはグレーアウトして押せません。

ディスクの再分散ボタンを押すと下図のようなポップアップが出ますが大したことは書かれていませんのでOKをおして進めてください。

実行が完了すると下図のように最近のタスクのペインにタスクが表示されます。

リバランスの進捗に関わらず常に5％で表示されます。

GUIから手動で開始したリバランスタスクは24時間稼働したのち停止します。

“ディスクのリバランスの中止” （英語だとStop Proactive Rebalance Disks）により、手動でリバランスタスクを停止することも可能です。

手動で停止した場合は下図のようにリバランスの中止タスクが生成され、中止タスクが完了したのちにリバランスタスクが完了となり、停止します。

rvcを使用したコマンドでの手動リバランス方法

※類似文書として下記もご参照ください。

VxRail: CLIによるvSANリバランス

rvc(Ruby vSphere Console)コマンドを使用することにより詳細な実行設定が可能です。

vsan.proactive_rebalance_info や vsan.proactive_rebalanceといったコマンドにより操作します。

vsan.proactive_rebalanceには、実行時間(-t単位：分)や1時間当たりのデータ移動量(-r 単位：MB)などのオプション指定があり運用管理に合わせて設定可能です。

例えば、 40ＧＢを指定する場合は 40960 という値で指定を実施します。

また、GUIからの実行では最大分散が30％の閾値に収まるようにリバランスされますが、より均等にリバランスしたい場合は、30％より小さい値を指定して実行することで可能となります。

下記のコマンドの場合は、最大分散が20％以下になるように、30時間リバランスを実行し、データ移動量を１時間あたり40ＧＢに指定する場合のコマンドとなります

vsan.proactive_rebalance -s -v 0.20 -t 108000 -r 40960 0

• 実行例

以下のコマンドリファレンスや、このコミュニティの他の Document を参考にしていただけます。

VMware Ruby vSphere Console Command Reference for Virtual SAN

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vsan/vmware-ruby-vsphere-console-command-reference-for-virtual-san.pdf

VxRail: CLIによるvSANリバランス

Virtual SAN ディスクバランスの警告を静観・抑止する場合

このセクションでは警告の発報を抑止する手順を紹介しています。

しかしながら、先に記載した通りディスクバランスに関しては自動リバランスによる予期せぬ業務影響の可能性がありますので、お勧めできません。

従いまして、最大分散や最大ディスク使用率をお客様にて確認していただき、手動リバランス実施の有無の判断をしていただくことをお勧めします。

Virtual SANディスクバランスのHealth Checkをスキップする方法

最大分散が30％以上でアラームが出ないようにする方法ですはVxRail 4.5 (vSAN 6.6, vSphere 6.5) であれば下記リンクのようなの手順にて項目をスキップできます。

VxRail 4.5(vSAN 6.6, vSphere 6.5)のvSAN健全性テストの警告について

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

しかし、VxRail 4.0では同様の手順は確認できませんでしたので、VxRail 4.0 (vSphere 6.0/vSAN 6.2) に関しては続く「アラーム定義を無効にする方法」をご検討ください。

なお、アラーム定義を無効にする方法」 はVxRail 4.5 (vSAN 6.6, vSphere 6.5)  でも使用可能です。

アラート定義を無効にする方法

VxRail 4.0 (vSphere 6.0/vSAN 6.2) ではHealth Checkを無効にすることはできませんが、アラート定義を無効にすることで、インベントリでの警告アイコンや、サマリタブでのメッセージを抑止できますのでパッと見、Cleanになります。

※この方法はVxRail 4.5 (vSAN 6.6, vSphere 6.5)  でも使用可能です。

※この方法を実施した後でも、vSAN健全性テストの項目にはディスクバランスの警告は表示されます。

まず下図を参考にVirtual SAN ディスクバランスのアラーム定義の編集ボタンを押してください。

編集ボタンを押すと編集ウインドウが出ますので、「このアラームを有効にする」のチェックを外してください。

警告メッセージを消す方法

アラーム定義の無効化や、vSAN ヘルスチェックのスキップを実施した後に、まだ警告メッセージが残存している場合は、下図を参考にクラスタの警告メッセージを確認してください。

”Virtual SAN ディスクバランス” の警告メッセージを確認したら、右クリック > 緑にリセット を選択し、メッセージを消してください。

留意事項

• リバランス処理が完了した後も、使用率の低いディスクが1つでも存在する場合には他のディスクとの使用率の差分が閾値に達し、警告メッセージが消えない場合も想定されます。
• リバランスに関する挙動（移動するデータの選定や完了時刻見込み、データの移動先）に関しては情報が公開されていません。

本記事では、nodeの停止/起動(メンテナンスモードの終了) 手順 についてご紹介します。

はじめに

ホストの保守作業などの関係でESXiの停止/起動を行う際には、必ずメンテナンスモード を経由する必要があります。

メンテナンスモードへの切り替えを挟む事で、安全な停止/起動を実現します。

VxRail Managerを利用したnode停止/起動(メンテナンスモードの終了)

Dell Model VxRailでは、VxRail Managerから1node単位で停止/起動(メンテナンスモードの終了)が可能です。

停止

※ 注意 ※

VxRail Managerからのnode停止におけるメンテナンスモードオプションは、

"他のホストからデータアクセスできることを確認する(アクセシビリティの確保)"のオプションにあたります。

60分以内にメンテナンスモードを解除しなければ、再同期が開始されます。

再同期が開始されるdefault60分を延長したい場合、以下VMware KBに則り設定時間を変更しておきます。

   - VSAN におけるホスト障害時の修復遅延時間の変更 (2147736)

     https://kb.vmware.com/kb/2147736

1.[稼働状態] > [物理]タブ > [対象node] > 背面アイコン > "シャットダウン"を選択します。

2.チェックを入れて"確認"をクリック

3.事前チェックが走ります。

   pass後、 "続行"をクリックすれば メンテナンスモードの移行 並びに シャットダウンが開始されます。

4.以下のようにステータスが遷移していきます。

※ 注1 ※

vSphere Standard Editionライセンスを利用している場合 DRSが利用できないため、

web clientから事前に手動でvMotionし 仮想マシンを他nodeへ移行 または シャットダウンしておく必要があります。

操作が完了するまで、事前チェックでエラーが出力されシャットダウンが出来ません。

※ 注2 ※

DRSが ONでも"自動化レベル"が"手動"の場合、事前チェックはpassするものの

本設定では自動でDRSが作動しないためにメンテナンスモードが19％で止まったままの状態となります

(vmotion待ちの状態)。そのため、web clientから適宜手動でvMotionを実施する必要があります。

起動(メンテナンスモードの終了)

1.電源ボタン または BMCより電源ON(参考:VxRail:BMCを利用した電源制御  )します。

2.ESXiが正常に起動完了後、”メンテナンスモードの終了"を選択します。

停止/起動ができないケース

VxRail Managerで対象nodeが "消失(Lost)"でmissing表示となっている場合、

vSphere WEB Clientからnode 停止/起動(メンテナンスモードの終了)を実施する必要があります(手順は後記)。

**Memo**

VxRail Managerからnode 停止を実施すると、自動的にクラスタ 正常稼働モニタリングがミュートします。

ミュート状態 = その時点での各node情報を保持し、情報を更新しない状態 となります。

本ミュートを解除(OFF)してしまうと対象のnode情報を更新するようになるため、

シャットダウン(またはメンテナンスモード)状態の情報を更新してしまい、"消失(Lost)"でmissing表示となります。

結果、VxRail Manager上で”メンテナンスモードの終了"が実施できなくなります。

ミュートがONの場合、VxRail Manager画面上部に黄色警告でその旨が表示されます。

web Clientを利用したnode 停止/起動(メンテナンスモードの終了)

Quanta Model VxRail 環境、またはVxRail Manager で対象nodeがmissing表示であるDell Model VxRail環境である場合、

vSphere WEB Clientから操作が必要です。

停止

1.vSphere Standard Editionライセンスを利用している場合、DRSが利用できないため

    事前に手動でvMotionし、仮想マシンを他nodeへ移行しておきます。

    リソースに余裕がない場合は必要に応じて仮想マシンをシャットダウンします。

2.対象のnodeを右クリックし、[メンテナンスモード] >> [メンテナンスモードの切り替え]を選択

2.以下いずれかのオプションにチェックを入れて、メンテナンスモードへ移行します。

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

   VxRail4.5.xxx(vSAN6.6)                                                       VxRail4.0.xxx(vSAN6.2)

   全てのデータを他のホストに退避する                           =    全データの移行

   他のホストからデータアクセスできることを確認する  =    アクセシビリティの確保

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

前者を選択すると、後者よりデータ移行に時間が掛かります。

後者を選択すると、前者より早くメンテナンスモードへ移行出来ますが、

60分以内にメンテナンスモードを解除しなければ再同期が開始されます。

再同期が開始されるdefault60分を延長したい場合、以下VMware KBに則り設定時間を変更しておきます。

   - VSAN におけるホスト障害時の修復遅延時間の変更 (2147736)

      https://kb.vmware.com/kb/2147736

3.メンテナンスモードへの移行完了後、対象のnodeを右クリックして[電源] >> [シャットダウンを選択します。

起動(メンテナンスモードの終了)

1.電源ボタン または BMCより電源ON(参考:VxRail:BMCを利用した電源制御)します。

2.ESXiが正常に起動完了後、対象のnodeを右クリックし [メンテナンスモード] >> [メンテナンスモードの終了]を選択します。

この文書ではvSphere Web Client/vSphere Host Client上に表示される題記の警告、またIntel社製CPU脆弱性問題:通称L1 Terminal Fault(L1TF)/Foreshadowへの対応について説明します。

※VxRailにおけるL1TF問題への対応全般についての情報をお求めの場合は、"L1 Terminal Fault(L1TF)とは"の項目以下を参照してください。

Ⅰ.警告が発生する原因について

vCenter が6.0 U3hまたは6.5 U2c以上にUpgradeされており、且つESXiホストに対しCVE-2018-3646の対策(ESXi SCA Scheduler:ESXi サイドチャネル対応スケジューラ)が有効化されていない環境で発生します。

VxRailをご利用のユーザにおいては、下記の条件でCVE-2018-3646の対策(ESXi SCA Scheduler:ESXi サイドチャネル対応スケジューラ)が有効化されていない場合が該当します。

Ⅱ. L1 Terminal Fault(L1TF)とは

Intel社からCVE-2018-3615、CVE-2018-3620、CVE-2018-3646の3つのCPUに関する脆弱性が公開されており、総称してL1 Terminal Fault(L1TF)、またはForeshadowと呼称されています。

このうち、VxRailとして対応が必用なものはCVE-2018-3620、CVE-2018-3646の2つです。

L1TF問題の概要については下記のページをご参照ください。

・Japan Vulnerability Notes: Intel 製 CPU の投機的実行機能に対するサイドチャネル攻撃 (L1TF, L1 Terminal Fault)

https://jvn.jp/vu/JVNVU97646030/

 

・Intel社公式ページ:Q3 2018 Speculative Execution Side Channel Update(英語)

INTEL-SA-00161

L1TF問題の詳細な技術情報については下記に掲載されています。

・Intel社公式ページ: "Deep Dive: Intel Analysis of L1 Terminal Fault"(英語)

https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-l1-terminal-fault

また、Intel社から内容が簡潔にまとまった動画(英語)も公開されています。

Ⅲ.L1TF/Foreshadow問題に対するVMwareからの案内

VMwareとしては、L1TF問題について下記のようにアナウンスしています。

・Intel プロセッサの「L1 Terminal Fault」(L1TF) 投機的実行の脆弱性に対する VMware の対応の概要 CVE-2018-3646、CVE-2018-3620、CVE-2018-3615 (55636)

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

     公開されている3つの脆弱性の内、VxRailとして対応の必用のある項目はCVE-2018-3620、CVE-2018-3646です。

     CVE-2018-3620については、VxRailのサービスVM(VxRail Manager、VCSA、PSC)への対処はVxRailが4.0.520、または4.5.218以上にUpgradeされた時点で完了します。

     お客様の仮想マシンについては、ゲストOSごとの対処を行う必要があります。

CVE-2018-3646への対応処置は、VMware KB 55806に詳述されています。

・vSphere 用 Intel プロセッサにおける「L1 Terminal Fault」(L1TF - VMM) 投機的実行の脆弱性に対する VMware の対応 CVE-2018-3646 (55806)

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

上記KBの"Resolution"セクションに、CVE-2018-3646に対する大まかな対応フローが図説されています。

CVE-2018-3646の対策(ESXi SCA Scheduler:ESXi サイドチャネル対応スケジューラ)を実施する手順は、"スケジューラ有効化フェーズ： ESXi サイドチャネル対応スケジューラの有効化"の項目に掲載されています。

ただし、該当処置を行うに際しCPUパフォーマンス影響を伴う場合があります。

パフォーマンス影響の側面については下記記事に詳述されています。

CVE-2018-3646への対応で、パフォーマンス影響を伴う対策(ESXi SCA Scheduler:ESXi サイドチャネル対応スケジューラ)の実施是非を判断する際は、特にこの記事を精読する必要があります。

・「L1 Terminal Fault - VMM」(L1TF - VMM) の軽減策によって VMware が受けるパフォーマンス面の影響の説明 CVE-2018-3646 (55767)

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

ESXi SCA Scheduler(ESXi サイドチャネル対応スケジューラ)の適用に際する影響を測定する参考ツールとして、VMwareから下記が提供されています。

記事内の"Attachments"からダウンロードすることできます。

・HTAware 軽減策ツールの概要および使用法 (56931)

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

Ⅳ.VxRailとして必要な処置

CVE-2018-3620について

CVE-2018-3620はゲストOSレベルの脆弱性です。

VxRailのサービスVM(VxRail Manager、VCSA、PSC)への対処は、VxRailが4.0.520・または4.5.218以上にアップグレードされた時点で完了します。

お客様の仮想マシンについては、ゲストOSごとの対処を行う必要があります。

外部vCenterをご利用のお客様は、外部vCenterを6.0u3hまたは6.5u2c以上にアップグレードする必要があります。

CVE-2018-3646について

CVE-2018-3646はハイパーバイザレベルの脆弱性です。

対処には、VxRailを4.0.520・または4.5.218以上アップグレードした後、ESXi SCA Scheduler(ESXiサイドチャネル対応スケジューラ)を有効化する必要があります。

ESXi SCA Scheduler(ESXiサイドチャネル対応スケジューラ)の有効化には、CPUパフォーマンスへの影響を伴う場合があります。

Ⅴ.お客様に取っていただくアクション

1. お客様のセキュリティコンプライアンス、ポリシーを確認いただき、ポリシーに準拠したL1TF問題に対する対応方針を策定いただく

2. VxRailを4.0.520、または4.5.218以上にアップグレードいただく

    →この時点でサービスMVに対してCVE-2018-3620の対処が完了します。

3.  L1TF/Foreshadow問題に対するVMwareからの案内の項目で紹介している記事を一読のうえ、内容を理解いただく

4. ご利用のVxRailのクラスターのCPUリソース使用状況をご確認いただき、CVE-2018-3646の対策(ESXi SCA Scheduler:ESXi サイドチャネル対応スケジューラ)適用に際する影響を確認いただく

5. 上記で確認・検討いただいた内容を元にESXi SCA Scheduler(ESXi サイドチャネル対応スケジューラ)の適用の是非を検討いただき、必用に応じて適用いただく

最終的に客様に取り得る対応方針は一般的に下記のいずれかであると考えられます。

A. セキュリティ脆弱性を受け入れ、CVE-2018-3646への対応をしないまま運用する(VMwareとしては非推奨)

     メリット:  パフォーマンス影響を回避できる

     デメリット: VxRailがCVE-2018-3646に対して脆弱な状態となる

B. CVE-2018-3646の対応(ESXiサイドチャネル対応スケジューラ)を実施し、セキュリティ対策を実行する

     メリット: CVE-2018-3646の脆弱性が回避される

     デメリット: パフォーマンス影響が発生する惧れがある

C. クラスターに十分な量のCPUリソースを追加したうえで、CVE-2018-3646の対応(ESXiサイドチャネル対応スケジューラ)を実行する

     メリット: セキュリティ面での安全性とパフォーマンスの両方を維持することができる

     デメリット: CPU追加(VxRailにおいてはノード追加)のためのコストが発生する

Ⅵ. 警告の抑制

上記を確認・検討のうえ、ご利用のVxRailにCVE-2018-3646に対する処置を実施する必要がないと判断された場合は、下記の方法で警告の表示を抑止することが可能です。

vSphere Web Clientにアクセス: ホストを選択 > サマリ > 警告の抑制

※WebClientにて、「警告の抑制」の表示がない場合は以下のKBを参照し抑制を実施してください。

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

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

Dell/EMC/VMware のうちどのベンダーも、当該問題についてお客様に取っていただくべき対応方針を案内・推奨・手引きすることはできません。

当該問題により発生し得るお客様ビジネス・セキュリティコンプライアンスへのリスク、及び問題への対処に必要なクラスターリソースを確認いただいた上で、お客様自身で対応方針を策定いただく必要があります。

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

参考資料:

Dell EMC ナレッジベース

VxRail: After upgrading to 4.5.218, an alert is reported on the hosts: esx.problem.hyperthreading.unmitigated

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

DSA-2018-176: Dell EMC VxRail Security Update for Multiprocessor L1 Terminal Fault Vulnerabilities

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

DTA 525859に関してご質問をいただいておりますので、情報を記載いたします

※情報は常に更新されますので差分などがある場合、DTA 525859およびVMware KB:58715の記載を正としてください

【事例要約】

vSAN 6.6以降の環境にて不具合が確認され、データの不整合が発生する場合があるものとなります

発生事象としては、VMware vSAN バージョン6.6以降でVMDKファイルの拡張を実施した際にデータの不整合が発生する場合があります

詳細は下記をご確認ください

■EMC DTA

     DTA 525859: VxRail: Virtual Machines (VM) running VxRail 4.5.x may report in-guest data consistency issues following a disk extend operation, which may result in potential data integrity issues

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

■Vmware KB

     Virtual Machines running on VMware vSAN 6.6 and later report guest data consistency concerns following a disk extend operation (58715)

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

【対象筐体】

全てのVxRail のModelが対象(Gen2,Gen3/Quanta model, PowerEdge model)で、

ご使用のVxRail versionが 4.5.070 から 4.5.218 をご使用の筐体が対象となります

【対応方針】

VxRail 4.5.225へのアップグレードを実施することで対応可能です

このコードは修正パッチが含まれているESXi 6.5 EP9 へアップグレードされます

詳細は下記のRelease Notesをご確認ください

■VxRail Release Notes

     VxRail Appliance Software 4.5.x Release Notes

     https://support.emc.com/docu86659_VxRail_Appliance_Software_4.5.x_Release_Notes.pdf?language=en_US

■ESXi Patch Release

     VMware ESXi 6.5, Patch Release ESXi650-201810001 (58852)

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

     VMware ESXi 6.5, Patch Release ESXi650-201810401-BG - Updates esx-base, esx-tboot, vsan, and vsanhealth VIBs (58855)

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

また早期のUpgrade対応の実施が難しい場合、ワークアラウンドとしてClomEnableInplaceExpansionの設定値変更が提供されております

(詳細はDTA525859 (又は VMware KB:58715) の記載をご確認ください)

※ワークアラウンドを実施した場合、VxRail 4.5.225へのアップグレード実施後に

ClomEnableInplaceExpansionの値をDefault 値の"1"に戻してください

VMware KB:58855に記載がございます

【その他】

vCenterが外部Networkに接続している環境では、vSAN Health Check(vSAN健全性)の

"オンライン健全性"にて"vSAN Critical Alert - Patch available for critical vSAN issue"の項目で、

Failed(失敗)のステータスが表示される場合がございます

また、"vSAN online health alarm VSAN Critical Alert - Patch available for critical vSAN issue"といった

アラームも検知されます

上記はDTA525859(又は VMware KB:58715)へのアップグレードまたはワークアラウンドの対応を促すものとなります

"Ask VMware"ボタンを押すと、KB:58715が案内されます

【よくある質問】

■DTAの対応は誰が実施可能でしょうか

お客様にてワークアラウンド(設定値変更)は実施可能でございます

 

VxRail 4.5.225へのアップグレードをご希望される方は弊社担当窓口までお問い合わせください

■Upgradeを希望する場合はどのように対応を進めればよいでしょうか

弊社にご連絡いただければ、Upgradeに関するやり取りを実施させていただきます

作業時間などの詳細情報もその際にご案内いたします

■ClomEnableInplaceExpansionの値を変更した場合、VMDKサイズの拡張は可能でしょうか

はい、値を変更後もVMDKの拡張は可能です

■ClomEnableInplaceExpansionは何のパラメータですか

VMDKの拡張(インプレース拡張)に関するパラメータでございますが、詳細情報はVMware社より開示されていません

■ClomEnableInplaceExpansionの変更時の作業影響を教えてください

ESXiのリブートやサービスの再起動は必要ございません

作業は全てのESXiのSSHをOpenにしていただき、全てのESXiにて設定コマンド("1"から"0"へ変更)を実施するのみとなります

本記事では、VxRail ManagerからCluster Shutdownが正常に動作しない場合などに、マニュアルでVxRailをShutdownする手順についてご紹介します。

はじめに

本コミュニティの手順はVxRailの正規手順のShutdown方法ではなく、Workaroundであることをご注意ください。

また、VMware KB 2142676に基づいた手順となっております。

最新の手順は、VMware KB 2142676をご参照ください。

A. 手動でのCluster shutdown 手順

1. 仮想マシンのShutdown実施

vSphere Web Clientにログインを実施し、ご使用されている全ての仮想マシンのShutdownを実施

VxRail ManagerのShutdownも実施し、Log insightおよびESRSをご使用の場合は併せてShutdownを実施してください

稼働している仮想マシンは上記のように、vCenter Server Appliance（VCSA）および、vCenter Server Platform Services Controller（PSC）のみの状態にしてください

2. VCSA及びPSCの稼働Hostの確認

仮想マシンのvCenter Server Appliance（VCSA）を選択し、summary欄にある"Host"を確認してVCSAがどのHost上で稼働しているかをメモ

vCenter Server Platform Services Controller（PSC）も同様にどのHost上で稼働しているかをメモしてください

※可能な場合、VCSA及びPSCの2つの仮想マシンをNode-1のHostにvMotionを実施することで、Cluster Power ON時に仮想マシンを見つけやすくなります

3. コンポーネントの再同期が発生の有無の確認

vSANのコンポーネントの再同期(Re-sync)が発生していないかを確認

発生していた場合、全ての再同期が完了を待つ必要があります。待たずにCluster Shutdownを実施するとデータ破損などが発生しうる可能性がありますのでご注意ください

vCenter Web Client にLoginし、"Host and Clusters"を選択

左側の最上部に位置するvSAN Clusterを選択し

Monitor > vSAN > Resyncing Componentsの項目を選択し、青矢印（更新ボタン）を押して下さい

下記は、コンポーネントの再同期が発生していない場合の表示です

下記は、コンポーネントの再同期が発生している場合の表示です

その場合は完了を待つようにしてください

4. VCSA及びPSCのShutdown

起動状態のvCenter Server Appliance（VCSA）及びvCenter Server Platform Services Controller（PSC）の停止を実施

仮想マシンのvCenter Server Platform Services Controller（PSC）を選択し、shutdownの実施をしてください

PSCのShutdownのオペレーションを実施後すぐに、vCenter Server Appliance（VCSA）もshutdownするようにしてください

5. 全てのESXi ShellをEnableの実施

仮想コンソールを使用する、またはNodeにKVMを接続してDCUI(Direct Console User Interface)へアクセスを実施

※仮想コンソールの使用方法は、VxRail:BMCの仮想コンソール機能を利用してDCUIを操作するをご確認ください

DCUIにアクセスしたら[F2]を押して、ESXiのroot userでLoginを実施します

※password入力時は、"Login name"の部分で正しくキーボード入力されるか確認してから実施すると良いです

　仮想コンソールのキーボード設定によって"@"などの位置が違う場合がございます

下記のようなSystem Configuration Menu が表示されたら、"Troubleshooting Options"を選択

画面右側で、"ESXi Shell is Enabled"となるように、画面左側の"Enable ESXi Shell"を押してShellのEnable実施をしてください

※上記のキャプチャの状態にしてください

上記を実施した状態で、[Alt] + [F1]を押してESXi Shellの画面を表示、root userでLoginしてください

※VxRail のvSAN Clusterの全てのESXiにて実施してください

ESXi Shell の使用はVMware KB:2004746も併せてご確認ください

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

また、補足手順にvSphere Web Clientより実施する手順を記載しておりますので、Step 4実施前にGUI上からESXi ShellをEnableにしておくことも可能です

6. ESXiをメンテナンスモードへの移行を実施

esxcliコマンドを使用して、ESXiをメンテナンスモードに移行

"esxcli system maintenanceMode get"にて、メンテナンスモードかどうかの確認（Enableの場合、メンテナンスモード状態）

"esxcli system maintenanceMode set -e true -m noAction"にて、No Actionのオプションでメンテナンスモードへ移行実施

[root@VxRail-esxi01:~] esxcli system maintenanceMode get

Disabled

[root@VxRail-esxi01:~] esxcli system maintenanceMode set -e true -m noAction

[root@VxRail-esxi01:~]

[root@VxRail-esxi01:~] esxcli system maintenanceMode get

Enabled

※VxRail のvSAN Clusterの全てのESXiにて実施してください

7. ESXiのShutdownを実施

vSphere Host Client または、DCUIよりESXiのShutdownを実施

下記はDCUIでの操作を例にします

ESXi shellの画面にいる場合、[Alt] + [F2]を押してESXiの画面に移動してから、[F12] を押しESXiのroot userでLoginを実施

"Shutdown/Restart"のMenuが表示されるので、[F2] Shut Downを選択してESXiのShutdownを実施してください

VxRail のvSAN Clusterの全てのESXiにて実施してください。

電源ボタンなどが消灯しますので、必要に応じて電源ケーブルの抜線等実施してください。

B. 手動でのCluster Power ON 手順

1. ESXiの起動を実施

ESXiを起動

電源ケーブルを抜いている場合は接続し、iDRAC/BMC経由、又は物理的に電源ボタンを押してNodeを起動してください

2. ESXiのメンテナンスモード解除

vSphere Host ClientまたはESXi Shellを使用してメンテナンスモードの解除を実施

a. vSphere Host Clientの場合

     vSphere Host Client(https://<ESXi IP>/ui)にLoginを実施

     Action > Exit maintenance mode を選択

b. ESXi shellの場合

     下記のコマンドを実施してメンテナンスモードを抜ける

[root@VxRail-esxi01:~] esxcli system maintenanceMode get

Enabled

[root@VxRail-esxi01:~] esxcli system maintenanceMode set -e false

[root@VxRail-esxi01:~]

[root@VxRail-esxi01:~] esxcli system maintenanceMode get

Disabled

VxRail のvSAN Clusterの全てのESXiにて実施してください

※全てのESXiでメンテナンスモードの解除を実施する前に次のステップを実行すると仮想マシンの破損が発生する可能性がございます

3. VCSA及びPSCのPower On

Cluster Shutdown時のStep2でメモした、vCenter Server Appliance（VCSA）とvCenter Server Platform Services Controller（PSC）がいるESXiのvSphere Host ClientにLogin

左側のMenuのVirtual Machinesを選択

vCenter Server Platform Services Controllerを選択し、Power ONを実施

その後、vCenter Server Applianceも同様にPower ONを実施

4. Health Checkの実施

VCSA及びPSCのPower Onが完了したら、vSANのHealth Checkを実施

vSphere Web ClientへLoginを実施

VxRail: Health Check 方法のvSAN ヘルスチェック を実施しエラーがないことを確認します

5. 仮想マシンのPower ONの実施

VxRail ManagerやESRSを含めた、その他の仮想マシンの起動を実施

### 補足手順

i) ESXi Shellのenable (disable)に関して

DCUIに接続をしなくてもvSphere Web Clientより各ESXiのShellをEnableにすることができます

vCenter Web Client にLoginし、"Host and Clusters"を選択し、ShellをEnableにするHostを選択

Configure > system欄のSecurity Profile > Services欄の"ESXi Shell"のステータスを確認

Stoppedであれば、Editボタンを押す(Runningの場合は、すでにEnableになっています)

Edit Security ProfileのMenuが表示されますので、

"ESXi Shell"を選択 > 下部の"Start"ボタンを押し、OKを押す

"ESXi Shell"のステータスがRunningになったことを確認

他のESXiでも有効にする場合は、同様の手順でその他のESXiの設定を変更してください

### 参考文献

・Shutting down and powering on a vSAN 6.x Cluster when vCenter Server is running on top of vSAN (2142676)

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

・Using ESXi Shell in ESXi 5.x and 6.x (2004746)

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

This document is a detail page for the VMware vExpert Directory.

Expert Information

View all vExpert entries

本文書ではVxRailのESRS調査時に利用可能な、ESRS tunneling through proxy 機能と条件を説明しています。

### ESRS tunneling through proxy とは ###

ESRS tunneling through proxyの概要

ESRS tunneling through proxyとはVxRail Manager VMを踏み台（中継サーバ）として、vCenterやESXiなどにアクセスする機能です。技術詳細としては、VxRail Manager（Linux）からvCenterやESXiに対するSSH接続や、SSH TCP Port forwardingによって実現されます。

本機能とそれを実現する手法はDell EMCの公式手順書（SolveDesktop）に記載のあるDell EMC公式のRemote接続機能です。

通常の保守契約の範囲でご利用可能であり、無償で提供されています。

ESRS tunneling through proxyのメリット・デメリット

ESRS tunneling through proxyが無い場合（デフォルト）

本機能を利用しない場合、Dell EMCのサポートエンジニアがESRS経由で実施できることは非常に限定的となります。

• Dell EMCサポートエンジニアがアクセス可能なもの
  • VxRail ManagerへのSSH接続
• Dell EMCサポートエンジニアができること
  • VxRail Managerのログ採取
  • VxRail Managerの機能を利用した調査、および解析

上記からわかるようにVxRail Manager関連の調査しかできず、vCenterやESXi、vSANといった主要コンポーネントでの障害が発生した際はログ採取や調査を実施することができません。

したがって、その場合はWebExを利用した調査もしくはお客様にログを取得いただきログベースでの調査となります。

ESRS経由で直接調査する場合と異なり調査・解決に時間がかかる傾向があります。

まとめると、

• メリット
  • デフォルトなので追加の承認や確認は不要
• デメリット
  • Remote調査時にWebEXやログ採取などのお客様負担が発生

ESRS tunneling through proxyがある場合

本機能が利用可能な場合、前述の制限から解放され、アクセス可能な対象と作業可能事項が大きく広がります。

• Dell EMCサポートエンジニアがアクセス可能なもの
  • VxRail ManagerへのSSH接続
  • VxRail ManagerへのGUI接続
  • vCener/PSCへのSSH接続
  • vCenter/PSCへのGUI接続（TCP:5480）
  • vSphere WebClientへの接続
  • ESXiへのSSH接続
  • ESXi Host Client (GUI)への接続
  • (Dell Model Only) iDRAC GUIへの接続 ※VxRail Managerからアクセス可能な場合に限る
  • (Dell Model Only) iDRAC 仮想コンソールへの接続 ※VxRail Managerからアクセス可能な場合に限る。HTML5を利用
  • (Quanta Model Only) BMC GUIへの接続 ※VxRail Managerからアクセス可能な場合に限る
  • (option) vRealize LogInsightへの接続
  • (option) vSphere Data Protection への接続 ※VxRail Managerからアクセス可能な場合に限る

• Dell EMCサポートエンジニアができること
  • 調査に必要となるログ採取全般（VxRail Manager/VCSA/PSC/ESXi）
  • 障害調査および復旧のために必要となる操作全般

Quanta ModelのBMC仮想コンソールなど一部例外はありますが、おおむね調査や作業に必要なコンポーネントへのアクセスが可能となります。

ただし、WebExと異なりお客様に認証情報を入力していただくことができないため、ログインに必要な認証情報はDell EMCに開示していただく必要があります。

追加のネットワーク設定変更（ポート開放など）は基本的に不要ですが、アクセス対象が広がるため明示的に許可をいただく必要があります。またデフォルトで無効になっているVxRail Manager OS（Linux）のSSH Port forwardingの有効化も許可いただく必要がございます。

したがって、

• メリット
  • Remote調査作業におけるお客様負荷の軽減が可能
  • 障害の解決の加速が見込まれる
  • 複雑なログ採取をDell EMCサポートエンジニアにて実施してもらえる
• デメリット
  • 認証情報の開示が必要
    • 開示可能な範囲で構いません。最低限VxRail Managerのrootおよびmystic(保守ユーザ)のパスワードは必要となります

• 事前にお客様による追加のコンポーネントへの接続希望の意思提示が必要（提示のみでお客様作業は無し）
• アクセス対象はお客様でご指定いただけます。（vCenterはOK、ESXiはNGなど）
• ご希望いただいた場合、以後はDell EMCサポートが必要に応じてアクセスします。
• Policy Managerがある場合は、別途接続都度に承認作業を実施いただく必要があります。
• SSH Port Forwarding機能の有効化承認が必要（許可のみでお客様作業は無し）
  • ※有効化は作業時のみで、作業（調査）完了後は無効状態に戻します。

ESRS tunneling through proxyの利用をご希望される場合

障害解決の迅速化や、お客様負荷軽減などを理由に本機能の利用をご希望される場合は以下を明示の上、Dell EMCサポート担当者にご連絡をお願いします。

・本コミュニティ文書のURL

・開示可能な認証情報

※各コンポーネントのroot認証情報およびvSphere SSO認証情報等

※VxRail Managerのrootとmystic(保守用ユーザ)のパスワードは必須

・追加でアクセス許可をいただけるコンポーネント一覧

・SSH Port Forwardingの有効化承認

※有効化は作業時のみで、作業（調査）完了後は無効状態に戻します。

ご留意事項

本機能が利用可能な場合でもWebExをお願いする場合がございます。

例：

• VxRail のUpgrade作業および事前チェック作業
• ネットワーク遅延や動作不良などにより本機能の使用が妥当でない場合
• 上位エンジニアやVMwareサポートと連携が必要な場合
• その他Dell EMC サポートエンジニアが必要と判断した場合

本機能が利用可能な場合でもお客様にログ採取をお願いする場合があります。

例：

• ESRS経由でのログ取得に問題がある場合
• VxRailに含まれない範囲のログが必要な場合（NSX ManagerログバンドルやUSVMログバンドルなど）
  • ※NSXはNSX for vShield Endpoint（無償ライセンス）のみDell EMCにてサポート可能です。
  • ※NSX for vSphere（有償ライセンス）については購入元のサポートにお問い合わせいただく必要がございます。

vCenterのvSAN健全性チェックにて日本語で表示されているために、KB(Knowledge Base)検索でどのような英語の文字列で検索すれば良いのか分からない場合は下記の対応表を元にチェック項目の確認を実施してください。

vSAN Health Check Information (2114803)

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

vSAN 6.2 (VxRail 4.0)

vSAN 6.6 (VxRail 4.5)

テスト結果(Test Result)

英語表記	日本語表記

Warning(警告)やFailed(失敗)が出ている際にはそのテスト項目を選択（クリック）することで、

より詳細な情報を確認することができます。

下記は"vSAN ビルドに関する推奨事項エンジンの健全性”のテスト項目にWarning(警告)が出ている例になります。

下記は、HTML5版の結果となり、CEIPの設定がDisableでCheck項目がSilence（項目のスキップ）状態の例となります。

サポートチームからLogの取得を依頼され、FTPサイトへファイルをアップロードする際に

容量制限にかかってしまう、アップロードに時間を要してタイムアウトしてしまう場合があります。

そういった場合は下記の手順にてログを分割することにより、1つのファイル容量を小さくすることで問題を解消できます。

### 分割方法 ###

■7.zipを使用したログ分割方法

ここでは、7-Zipというフリーソフトを使用した方法を記載いたします

1. 分割したいファイルを右クリックして "7-Zip" > "圧縮" を選択

2. ファイル圧縮のメニュー画面が表示されたら "書庫をサイズで分割" の欄に、

希望する分割後のサイズを入力し"OK"を選択

※画像例の場合は、200 MB毎にファイルを分割していきます

3. "圧縮中"というステータス画面が表示されます

4. "圧縮中"のステータスが完了すると、分割されたファイル(赤枠)と元ファイル(青枠)が存在しますので

分割されたファイル(赤枠)をFTPサイトへアップロードを実施してください

■Splitコマンド(Linux)を使用したログ分割方法

Linuxのsplitコマンドが使用できる場合、Linux上でもファイル分割は可能です

1. 分割したいファイルが存在するDirectoryへ移動する(分割する際には、空き容量が十分にある事を確認してから実施してください)

※今回は"vc-support.tgz"というファイルを分割します

2. Splitコマンドを実行してファイルを分割する

下記のようなコマンドにて実行すると、

分割ファイルを200Mで "vc-support.tgz-" という文字列を接頭辞にし、ファイルの末尾を00のように数字(-d オプション) にして分割ファイルを作成していきます

split -b サイズ -d <分割したいファイル名> <分割後の接頭辞に使用する文字列>

例)

split -b 200M -d vc-support.tgzvc-support.tgz-

      

上記のように、200Mの分割ファイルが作成されます

分割されたファイルをFTPサイトへアップロードを実施してください

### 結合方法 ###

■7.zipを使用して分割されたファイルの結合方法

1. 分割されたファイルを全て同じDirectoryに配置し、

"<ファイル名>.001"を右クリックし"7-Zip" > "開く" を選択

2. 7-zipのFile Manager画面に結合されたファイルが表示されるので

ファイルを右クリックし、コピーを選択

3. コピー先を選択し、"OK"を選択

■Splitコマンドを使用して分割されたファイルの結合方法

・Linux上で結合する場合

1. 分割されたファイルが存在するDirectoryへ移動する

2. cat コマンドを使用してファイルを結合する

下記のようなコマンドにて実行すると、分割ファイルを結合することができます

分割時に分割ファイルが連番になっているため、ワイルドカードの"*"を使用しています

cat 分割ファイル名 > 結合後のファイル名

例)

cat vc-support.tgz-* > vc-support.tgz

・Windows上で結合する場合

1. 分割されたファイルが存在するDirectoryへ移動し、ウィンドウ上でShift + 右クリックにて

"コマンド ウィンドウをここで開く"を選択

"dir"コマンドを発行して、分割ファイルがいることを確認

2. copyコマンドを使用してファイルを結合する

下記のようなコマンドにて実行すると、分割ファイルを結合することができます

分割時に分割ファイルが連番になっているため、ワイルドカードの " * " を使用しています

/Bをファイル名の後ろに着けることでバイナリファイルとして扱う事が出来ます

copy 分割ファイル名 /B  結合後のファイル名 /B

例)

copy vc-support.tgz-* /B vc-support.tgz /B

      

VxRailのサポートにおいては、いくつかの種類のログの取得が必要になります。
ここでは、それぞれのログ取得手順のまとめと、そのログの概要についてご紹介いたします。

VxRailログバンドルとvc-support/vm-supportはほとんどの場合で必要なログです。

TSRログ、VSANログ、PSCログバンドルは発生している症状に応じて必要となる場合があるログです。

NSXや, Log Insight, vDP, USVM Guest Introspectionなど関連製品との調査の場合はそれぞれのログが必要となります。

※ESRS経由での確認では、VxRail: VxRailログバンドル作成相当の確認のみとなる場合がある(Versionによって異なります)ため、
　ESRS接続環境を構築いただいているお客様の場合でも、上記ログ取得をお願いさせていただく場合や、

　WebEXでの対応をお願いさせていただく場合があります。

This document is to assist with upgrading on-premises VMware Identity Manager appliances, including both the full on-premises appliance (commonly known as the Single Virtual Appliance - or SVA) and the on-premises standalone connector for a SaaS VMware Identity Manager tenant.  It should be used with the official VMware Identity Manager upgrade documentation (NOTE: Select the version of the appliance you are upgrading to from the drop down menu).

Please note there are links embedded throughout the document below in reference to the documented procedures or other information.

NOTE:  Document updated for VMware Identity Manager 2.9.x, 3.x, and 19.03 as well as references for 2.8.x and older appliances.

Index:

You will find the following info within this document.

Prerequisites:

Prerequisites for an online upgrade

Documentation:

• SaaS On-Premises Connector
• 2.8 Upgrade Docs
• 2.9.1 Upgrade Docs
• 2.9.2 Upgrade Docs
• 3.1 Upgrade Docs
• 3.2 Upgrade Docs
• 3.3 Upgrade Docs
• 19.03 Upgrade Docs
• If on VMware Identity Manager 2.7.x or older and attempting to upgrade to 3.0, upgrade to 2.8.x/2.9.x prior to upgrading to 3.0.
  • Upgrading from 2.7.x or earlier directly to 3.0 is not supported.
• If on VMware Identity Manager 3.0/3.1 and attempting to upgrade to 3.3, upgrade to 3.2.0.1 prior to upgrading to 3.3.
  • NOTE: You may use the online upgrade documentation to upgrade to a specific version rather than having to download and do an offline upgrade to said version.
    • Performing an Online Upgrade to a Specific Version (for SVA)
      
    • Performing an Online Upgrade to a Specific Version (for Standalone SLES Connector)
• Verify that at least 4 GB of disk space is available on the primary root partition of the virtual appliance.
• Take a snapshot of your virtual appliance to back it up. For information about how to take snapshots, see the vSphere documentation.
• If you are using an external database, take a snapshot or backup of the database.
  • This is only necessary when upgrading the Service (SVA) nodes. It is not necessary when upgrading a standalone connector.
  • See the Microsoft SQL documentation on how to conduct a manual backup of a SQL database.
• Verify that VMware Identity Manager is properly configured.
• Verify that the virtual appliance can resolve and reach vapp-updates.vmware.com on port 80 over HTTP.
• If an HTTP proxy server is required for outbound HTTP access, configure the proxy server settings for the virtual appliance. See Configure Proxy Server Settings for the VMware Identity Manager Appliance.
• Confirm that a VMware Identity Manager upgrade exists. Run the appropriate command to check for upgrades. See Check for the Availability of a VMware Identity Manager Upgrade Online.
• If using a cluster AND upgrading to a version prior to 2.9.1, prepare the RabbitMQ Server before upgrading - See the Preparing RabbitMQ Server Before Upgrade procedure.
• If using a cluster AND upgrading to 2.9.1 or newer, note that RabbitMQ is disabled in 2.9.1 and higher. See the Upgrading a Cluster procedure.

Prerequisites for an offline upgrade

Documentation:

• SaaS On-Premises Connector
• 2.8 Upgrade Docs
• 2.9.1 Upgrade Docs
• 2.9.2 Upgrade Docs
• 3.1 Upgrade Docs
• 3.2 Upgrade Docs
• 3.3 Upgrade Docs
• 19.03 Upgrade Docs
• Verify that at least 2.5 GB of disk space is available on the primary root partition of the virtual appliance.
• Take a snapshot of your virtual appliance to back it up. For information about how to take snapshots, see the vSphere documentation.
• If you are using an external database, take a snapshot or backup of the database.
• Verify that VMware Identity Manager is properly configured.
• Confirm that a VMware Identity Manager upgrade exists. Check the My VMware site at my.vmware.com for upgrades.
• Prepare a local Web server to host the upgrade file. See Prepare a Local Web Server for Offline Upgrade.

Post-requisites:

Documentation:

• SaaS On-Premises Connector
• 2.8 Upgrade Docs
• 2.9.1 Upgrade Docs
• 2.9.2 Upgrade Docs
• 3.1 Upgrade Docs
• 3.2 Upgrade Docs
• 3.3 Upgrade Docs
• 19.03 Upgrade Docs

The following are settings to configure after the upgrade completes successfully. If you have set up a VMware Identity Manager cluster for failover, updating it to three nodes is recommended. This is because of a limitation of Elasticsearch, a search and analytics engine embedded in the VMware Identity Manager appliance. You may continue to use two nodes but you should be aware of a few limitations related to Elasticsearch. See "Configuring Failure and Redundancy" in Installing and Configuring VMware Identity Manager for more information.

• Enable the new portal user interface.
  • In the administration console, click the arrow on the Catalog tab and select Settings.
  • Select New End User Portal UI in the left pane and click Enable New Portal UI.
• Transport Layer Security (TLS) protocol 1.0 is disabled by default in VMware Identity Manager 2.8 and higher. TLS 1.1 and 1.2 are supported.
  • External product issues are known to occur when TLS 1.0 is disabled. Updating your other product configurations to use TLS 1.1 or 1.2 is recommended. However, if your version of products such as Horizon, Horizon Air, Citrix, or load balancers have a dependence on TLS 1.0, you can enable TLS 1.0 in VMware Identity Manager by following the instructions in Knowledge Base article 2144805.
• After upgrading to 2.8.x, 2.9.x, or 3.x, set the thread count in the system config parameter, /SAAS/jersey/manager/api/systemconfigparameter/bulkSyncSharedThreadCount in all nodes and restart the node.

Tips and Best Practices:

Backup of IFCFG-ETH0
Make a copy of the IFCFG-ETH0 file before upgrading.

1. Login to the appliance console or remote in as SSHUSER and then SU to root.
2. Run the following command to make a backup of IFCFG-ETH0.
   cp /etc/sysconfig/networking/devices/ifcfg-eth0 /etc/sysconfig/networking/devices/ifcfg-eth0.bak
3. Exit the console or SSH session.
   exit

VM Snapshot Backup

Make a VM snapshot before upgrading (no memory state needed unless you want one).

1. Login to vSphere or vCenter.
2. Browse to the VM in question.
3. Right click on the VM and select options to create a new snapshot.

Database Backups or Snapshots

When upgrading the full VMware Identity Manager on-premises single virtual appliance (SVA), when taking a VM snapshot of appliance(s), it is also good practice to take a backup of the database or VM snapshot of the database server.

Online Updates and Proxy Settings

When doing an online update, you may need to set an outbound proxy within the appliance in order for it to reach the Internet and download the update packages.  Essentially the appliance must be able to reach vapp-updates.vmware.com on TCP port 80 (HTTP).  The latest instructions for setting a proxy for online upgrade can be found in the VMware Identity Manager Documentation online.

The procedure for setting a proxy is as follows:

1. Log in to the VMware Identity Manager virtual appliance as the root user.
2. Enter YaST on the command line to run the YaST utility.
3. Select Network Services in the left pane, then select Proxy.
4. Enter the proxy server URLs in the HTTP Proxy URL and HTTPS Proxy URL fields.
5. Select Finish and exit the YaST utility.
6. Restart the Tomcat server on the VMware Identity Manager virtual appliance to use the new proxy settings by typing the following command:
   service horizon-workspace restart

Post-Update Apply Hot Patches

Apply any necessary hot patches after upgrading.

The Upgrade Process

The short version of the over-the-air procedure is…

1. Login to the appliance console and make a backup of IFCFG-ETH0.
2. Make a backup of /etc/sysconfig/networking/devices/ifcfg-eth0.
   1. Login to the appliance console or remote in as SSHUSER and then SU to root.
   2. Run the following command to make a backup of IFCFG-ETH0.
      cp /etc/sysconfig/networking/devices/ifcfg-eth0 /etc/sysconfig/networking/devices/ifcfg-eth0.bak
   3. Exit the console or SSH session.
      exit
3. Make a VM snapshot (no memory state needed unless you want one).
   1. Login to vSphere or vCenter.
   2. Browse to the VM in question.
   3. Right click on the VM and select options to create a new snapshot.
4. If you have a cluster of on-premises VMware Identity Manager full appliances (SVA) version 2.8 or older, you will need to prepare the RabbitMQ server on each. NOTE: Skip this step for VMware Identity Manager On-premises Connectors.
   • If using a cluster AND upgrading to a version prior to 2.9.1, prepare the RabbitMQ Server before upgrading - See the Preparing RabbitMQ Server Before Upgrade procedure.
1. Stop RabbitMQ nodes on each VMware Identity Manager appliance in the cluster.
   1. Type rabbitmqctl stop.
   2. Do this for each RabbiMQ node in the cluster before continuing.
2. Verify that RabbitMQ is detached from the cluster. Type rabbitmqctl cluster_status.
   
   NOTE: In the above image, we see the running_nodes lists only node 1, so this means nodes 2 and 3 are not running RabbitMQ (yet).
   
   

• If using a cluster AND upgrading to 2.9.1 or newer, note that RabbitMQ is disabled in 2.9.1 and higher. See the Upgrading a Cluster procedure.
  
  

Upgrade Issues and Troubleshooting Options:

Troubleshooting Upgrade Errors

UpdateInstaller Fails to Run on VMware Identity Manager On-Premises Full Appliance

Symptoms:
Update, Update Check, Update Installer fail to run and/or show any outcome.

Cause:

Not enough available inodes (number of allowed files).

Correction:

1. Run df. This will give you an idea of how much space you have.
2. Run df -i.  This will tell you how much inode space you have left.
   1. Example: If /varsays 100% and you see inodes has less than 200 then you may have this issue.
      NOTE: An upgrade from VMware Identity Manager 2.6 to 2.7 typically requires around 209 inodes.
3. The solution is to clear off enough files to free up enough inode space.
   NOTE: This can be done in any folder where there are enough files to make a difference.
   1. The recommendation is to use the /var/log folder as this is commonly the offender for inode consumption.
4. To clear off bz2 log files more than 90 days old, do the following:
   1. Login to the appliance console directly (via vCenter) or via SSH (and SU to root).
   2. Browse to the /var/log folder
      cd /var/log
   3. Find and delete bz2 files older than 90 days.  The below command deletes anything ending with the extension “bz2” which is older than 90 days from current date. You may need to delete more recent files to clear up enough inodes by changing the time frame to a lower range such as 45 days instead of 90 days.
      find ./*.bz2 -mtime +90 -exec rm {} \;
   4. Retest update installer, update check, and update.
      /usr/local/horizon/update/updatemgr.hzn updateinstaller
      /usr/local/horizon/update/updatemgr.hzn check
      /usr/local/horizon/update/updatemgr.hzn update

Reference:

Information courtesy of Wibowo Leksono

UpdateInstaller Reports No Updates on VMware Identity Manager On-Premises Connector Appliance Version 2016.11.1.0

Symptoms:

Update Installer runs on VMware Identity Manager On-Premises Connector Version 2016.11.1.0 but reports no updates are available.

Cause:

Known Issue with VMware Identity Manager Connector version 2016.11.1.0.

Correction:

1. Apply VMware KB 2149179

Reference:

https://kb.vmware.com/kb/2149179

No Networking Detected on Reboot After Upgrade

Link:  Networking Error after Upgrade

Symptoms:

The upgraded SUSE appliance shows NO NETWORKING DETECTED errors.  Logging in and looking at /etc/sysconfig/network (ls /etc/sysconfig/network -l -a) shows source file for ifcfg-eth0 is missing in /etc/sysconfig/networking/devices/ for /etc/sysconfig/network/ifcfg-eth0 link file.

Cause:

Known Issue with upgrade process wiping ifcfg-eth0 information

Correction:

1. Move the backup of ifcfg-eth0 taken during step 2.2 of The Upgrade Process back into place.
   1. Login to the appliance console or remote in as SSHUSER and then SU to root.
   2. Run the following command to move the backup of IFCFG-ETH0 into place
      mv /etc/sysconfig/networking/devices/ifcfg-eth0.bak /etc/sysconfig/networking/devices/ifcfg-eth0
   3. Exit the console or SSH session.
      exit
2. Alternately (instead of step 1.), manually create the file.
   1. Login to the appliance console or remote in as SSHUSER and then SU to root.
   2. Open the VI editor and create the file by typing the following command.
      vi /etc/sysconfic/network/ifcfg-eth0
   3. Type in all of the settings as shown in the below reference image. All lines except IPADDR=, NETMASK=, and BROADCAST= will be identical to what is in the image.  To find your IP address, either ping or attempt to resolve the FQDN of the appliance to get the IP address, or look within the vApp advanced options of the VM to get the exact IP address.  From there you should be able to fill in the below values.
      IPADDR=‘<your_appliance_ip_address>’
      NETMASK=‘<your_appliance_ip_subnet_address>’
      BROADCAST=‘<your_appliance_ip_broadcast_address>’
   4. Exit the INSERT mode by pressing the ESC key.
   5. Save the file and exit the VI editor by typing `:` (colon) then `x` (lower case "x") and then pressing the ENTER key.
3. Reboot the appliance by typing reboot and pressing ENTER.

Reference Image:

This post will walk you through basics and the setup of a 3rd Party IdP within Identity Manager. For this blog post, we will be using two separate VMware Identity Manager tenants as this allows for documentation of both sides for demonstration purposes.

This post assumes either VMware Identity Manager 2.8.x on-premises tenant or newer, or a VMware Identity Manager SaaS tenant.

Index:

You will find the following topics within this post:

• The Basics
  • 3rd Party IdP High Level Layout
• Configurations & Use Cases
  • VMware Identity Manager as a 3rd Party Identity Provider to another Primary Identity Provider
  • Another 3rd Party Identity Provider integrated with VMware Identity Manager
  • Bidirectional Identity Provider Integrations
  • Chaining More than 2 Identity Providers
• Logic Flows
• Setting up a 3rd Party IdP in VMware Identity Manager
• Resources

The Basics:

When setting up a 3rd party Identity Provider (IdP) with VMware Identity Manager, it is first important to understand the difference between Authentication and Authorization and which piece (i.e. “Who”) does what and when.

The basic logic flow when VMware Identity Manager is part of this starts with VMware Identity Manager acting solely as a Service Provider (it is providing a service with the application catalog for users to choose applications for launch).  VMware Identity Manager can also act as a 3rd Party Identity Provider but in this initial authentication flow, it is just a simple service provider.

1. The user browses to VMware Identity Provider.
2. VMware Identity Manager contacts the Primary Identity Provider (the one doing the authentication)
3. The Primary IdP requests the user enter their credentials. In Secure Addressable Markup Language (SAML) terms, this is the claim.
4. The Primary IdP validates this claim against a security provider (in this case, Active Directory).
5. The Primary IdP responds with an updated SAML assertion specific for the Service Provider allowing the user to utilize the Service Provider in question.

Figure 1 - Common logic flow for two Identity Providers.

For customers who are integrating with a 3rd party IdP such as Okta or Ping, it is important to first understand where the users will log in to (Which IdP will handle the Authentication) and where the applications are protected (Which IdP will hand the Authorization).   These are major points of understanding and must be comprehended first before proceeding as these can be either of the Identity Providers.  In the above (Figure 1) diagram - and in the following (Figure 2) diagram, we are showing VMware Identity Manager sitting in front of another Identity Provider, but these can be swapped as we will discuss in the next paragraphs.

Typically with VMware Identity Manager and Workspace ONE, VMware recommends the VMware Identity Manager / Workspace ONE portal be where a user goes first to start their authentication.  This means, VMware Identity Manager is the Service Provider and the customer's other identity solution is the Identity Provider for VMware Identity Manager.  This allows the most flexibility overall for customers.  In this method, VMware Identity Manager is actually seen as the 3rd Party IdP to the IdP which is protecting the applications.  In this method, it does not mean VMware Identity Manager cannot protect apps, it just means the IdP which is currently protecting apps is considered the "Primary Identity Provider (IdP)".  The IdP where users login to is considered the 3rd Party IdP.

Figure 2 - VMware Identity Manager acting as the 3rd Party Identity Provider to another Primary Identity Provider

It should be clarified, this does not mean customers are forced into using VMware Identity Manager first in the user authentication process.  As stated previously, with VMware Identity Manager and its support of 3rd party IdPs, customers have the flexibility of configuring this in various ways.  This includes making VMware Identity Provider the Primary IdP (application protector) and other Identity Providers as 3rd party IdPs.

Figure 3- VMware Identity Manager acting as the Primary Identity Provider supporting another 3rd Party Identity Provider

Configurations & Use Cases:

Setting up a 3rd Party IdP in Identity Manager can be done in both unidirectional and bidirectional fashions.  Images of these can be seen above in Figure 2 and Figure 3.

• In a Unidirectional flow, authentication happens first on the IdP which processes user logins, then authorization of applications (app launches) is handled by the IdP which is protecting the applications.
  • Using VMware Identity Manager as the User Authentication.
    NOTE: See Figure 2 above.
    
  • This is a good scenario for when a customer already has a 3rd party IdP in place such as Ping or Okta and this 3rd Party IdP is protecting applications already. VMware Identity Manager would then be inserted into the flow to handle User Authentication to the 3rd party IdP.
    • PROS:
      • Less/No work to reconfigure applications.
      • All applications protected by the 3rd Party may be presented in VMware Identity Manager.
    • CONS:
      • Users education will be necessary to redirect users to the new Identity Manager interface for login.
      • Can easily integrate other VMware solutions for SSO such as Horizon, ThinApp, Horizon Air, AirWatch, etc. as well as Citrix solutions.

• Using VMware Identity Manager for Application Authorization. 
  NOTE: See Figure 3 above.
  • This is an alternate scenario for when a customer already has a 3rd party IdP in place.  VMware Identity Manager would be inserted into the flow to handle application authorizations after the 3rd party IdP handled user authentication.
    • PROS:
      • Customers can keep their existing end user portal for authentication.
      • It is possible to redirect to the VMware Identity Manager web portal for a better user experience.
    • CONS:
      • Cannot work with Workspace ONE unless 3rd Party IdP has an authentication exception rule to route all mobile requests to VMware Identity Manager.
      • All SaaS Applications must be reconfigured to work with VMware Identity Manager.

• Does support support Horizon/Horizon Air/Citrix integrations.

Figure 4 - VMware Identity Manager configured with another Identity Provider in a bidirectional IdP trust

• A Bidirectional flow is simply two Unidirectional flows where both IdPs handle User Authentication and App Authorization for the “respective" other IdP.  The general scenario is if a user authenticates to either IdP, they can be automatically authenticated to the other IdP and all applications.
  • While many environments may need to operate utilizing this configuration, customers may wish to eventually migrate to a single identity management and single sign-on solution for simplicity sake.
  • PROS:
    • End Users are authenticated once and SSO is used to process further authentications to other IdPs.
    • Supports integration of other VMware solutions as well as Citrix (with VMware Identity Manager).
    • All applications protected by the 3rd Party may be presented in VMware Identity Manager.
    • Users can be slowly migrated from 3rd Party IdP portal to VMware Identity Manager.
    • Can work with Workspace ONE for all applications protected by VMware Identity Manager.
  • CONS:
    • Two user portals creating additional administrative overhead.
    • Complex setup and configuration.
    • PSO recommended for environment mapping.
    • User education required.
    • May not support or not fully support Horizon/Horizon Air/Citrix integrations.
    • May require complex authentication policies on one or both identity providers.

Figure 5 - Chaining together multiple Identity Providers, including VMware Identity Manager

• Chaining 3 or more Identity Providers (IdPs) is also an option.  However, when approaching this option, one should determine whether it is more beneficial to chain in serial or in a star logic-flow form.
  • Example: In a serial fashion (not shown on this slide), the 1st IdP authenticates users. A 2nd IdP protects applications and trusts the 1st IdP for authentication.  The 3rd IdP protects other applications and trusts the 2nd IdP for authentication.
    • This option would be slightly less complex than the next option during initial setup but potentially more administrative overhead.  Additionally it is not as flexible as a star logic flow configuration.
  • In a star logic-flow fashion, it would look something like this.  Each of the VMware Identity Manager tenants authenticates users. The backend Primary IdP tenant protects applications and trusts each of the VMware Identity Provider tenants as 3rd party IdPs for authentication.  The Primary IdP tenant protects other applications and trusts each of the VMware Identity Manager tenants for authentication.
    • This option would be slightly more complex during initial setup but potentially much less administrative overhead assuming the same A.D. users and groups are synced across all IdPs.  While some environments may have to operate with this configuration, typically this configuration would be recommended mainly for migrations.
    • PROS:
      • End Users are authenticated once and SSO is used to process further authentications to other IdPs.
      • Supports integration of other VMware solutions as well as Citrix (with VMware Identity Manager being the first authentication point).
      • All applications protected by the 3rd Party may be presented in VMware Identity Manager tenants.
      • Users can be slowly migrated from 3rd Party IdP portal to VMware Identity Manager.
      • Can work with Workspace ONE for all applications protected by VMware Identity Manager.
    • CONS:
      • Multiple user portals creating additional administrative overhead.
      • Complex setup and configuration requiring a high level of planning up front.
      • PSO recommended for environment mapping.
      • User education required.
      • May not support or not fully support Horizon/Horizon Air/Citrix integrations.
      • May require complex authentication policies on one or both identity providers.
      • Application management may be complex until all tenants brought together.

Logic Flows:

When incorporating a 3rd party Identity Provider, logic flows are altered based upon the end user story changes.

In the case where VMware is linking to another Identity Provider which is protecting an application, VMware is seen as the “3rd Party Identity Provider” to the other “Primary Identity Provider” (it being the one protecting the applications).  When doing this in conjunction to adding in Single Sign-On support for Horizon 6/7/Air/Hosted, ThinApp, Mobile Apps, or other solutions such as Citrix remote hosted desktops and apps with XenApp 5/6/7 and XenDesktop 7, VMware Identity Manager becomes the new, front-facing login portal for all users in order to provide a seamless end-user experience across all devices, applications, and services.

In the case where VMware Identity Manager is protecting applications such as Mobile apps but sits behind another Identity Provider, VMware Identity Manager is the Primary Identity Provider for any applications which it protects and the front-facing login portal which redirects to VMware Identity Manager is seen as the “3rd Party Identity Provider”.

Setting up a 3rd Party IdP in VMware Identity Manager:

In this procedure you will need two VMware Identity Manager tenants (either can be SaaS or On-Premises tenants). You will be setting up one VMware Identity Manager tenant as a 3rd Party Identity Provider within another VMware Identity Manager tenant which is acting as the Primary IdP.

1. First let us get our descriptions clarified.  When using two Identity Manager tenants together with one as a 3rd party Identity Provider (IdP) to the other, we need to ensure we know which one we are talking about in the following instructions.
   NOTE: Please reference Figure 2 and Figure 3 above when working through these procedures.
   1. 3rd Party Identity Provider - This is the “3rd Party" Identity Manager tenant which the user is browsing to in order to login and view the app catalog and launch the apps.  To note, when adding VMware Identity Manager to an existing IdP solution, this is how VMware recommends adding VMware Identity Manager to the solution since this allows incorporation with as little change as possible to the existing production environment while allowing incremental rollout to end users by having them authenticate to VMware Identity Manager to get all of their applications, desktops, mobile apps, and other services provided to them.
   2. Primary Identity Provider - This is the Identity Manager tenant (the IdP) which is providing authenticating and authorization to any of its application(s) and service(s) which it is protecting.  VMware supports VMware Identity Manager in this configuration as well with other 3rd party IdP solutions.
      
      
2. Since we are using two Identity Manager tenants, there are two sides to this configuration.  One part is the work done on the Primary Identity Provider tenant and the other part is the work done on the 3rd Party Identity Provider tenant. The first part is configuring the 3rd Party Identity Provider tenant as a 3rd party IdP within the Primary Identity Provider Provider.  This is done from the Primary Identity Manager tenant which provides the application protection in order for it to know who to accept authentication requests from.  For example, Office 365 is protected by the Primary Identity Provider tenant…the 3rd Party Identity Provider tenant is where the user authenticates…and then the user clicks on an application called Office 365 which points the user to the Primary Identity Provider tenant and specifically to the Office 365 application for execution. Along with that redirection, the 3rd Party Identity Provider tenant provides a SAML Assertion which holds the appropriate claim to authenticate the user to the Primary Identity Provider and allow it to authorize the user to launch the protected application…in this case, Office 365.
   
   
3. To get started, within the Primary Identity Provider Identity Manager tenant (i.e. The IdP which protects the applications), browse to the Admin Console from the Identity & Access Management > Manage > Identity Providers page and click on the Add Identity Provider button and select the Create Third Party IDP menu option.
   1. Fill in the necessary information in the New Identity Provider page.
      1. Identity Provider Name: A name for administrators to easily identify this new IdP.
      2. SAML Metadata: Provide the URL or XML of the 3rd Party IdP for trust.  When using another Identity Manager tenant as the 3rd party IdP, to obtain the SAML Metadata, login to the administrative console on the 3rd Party Identity Provider Identity Manager tenant and browse to Catalog > Settings > SAML Metadata and right-click the Identity Provider (IdP) metadata link and copy the link address.  The address will be as shown below, where <3RDIDPFQDN> is your 3rd Party Identity Provider Identity Manager tenant FQDN.
         https://<3RDIDPFQDN>/SAAS/API/1.0/GET/metadata/idp.xml
      3. Back in the Primary Identity Provider Identity Manager tenant (which protects the applications) where you are creating the new “3rd Party IdP”, paste or type the above URL into the SAML Metadata box and click the Process IdP Metadata button.  This will auto-populate most settings.
         1. NOTE: The four Name ID Values which show up after processing the IdP metadata are the attributes which will be used between the two IdPs for mapping user accounts.  Only one out of the four is needed (e.g. email) to match.
         2. NOTE: In this case, since we are using the same Active Directory between both Identity Manager tenants, we don't need to worry about account creation.  Had we decided to use different Active Directory environments (such as two different companies linking their Identity Manager tenants together) or two internally different directories (e.g. Active Directory users with one Identity Manager tenant and Open LDAP or Local Directory Identity Manager users with the other Identity Manager tenant), we would only need to ensure one of the attributes maps (and that no other attributes match a completely different account) with a user account on both sides (i.e. If using email address as the mapping attribute, the user account in Identity Manager tenant using active directory has the same email address defined in the general tab of the A.D. Users and Computers account properties as the email address within the Local Identity Manager user account).
         3. NOTE: If not using the same A.D. domain for both Identity Manager tenants and instead manually creating a test user, only the mapped attribute(s) defined need to have matching values between the two Identity Manager tenants.  Use the User and Groups tab in both Identity Manager tenants to compare your test account in each tenant to see if the mapped values match (for tenants using the same Active Directory domain, we know they will match so long as the test user account is synchronized to both Identity Manager tenants).
         4. NOTE: If some of the user attributes defined under the Name ID Value could potentially cross map to other user accounts, then remove them and stick with just the one or two attributes you know will be unique to each user (e.g. email or userPrincipalName).
      4. Name ID Policy is optional and not needed if doing Identity Manager to Identity Manager trusts.
      5. Just-In-Time User Provisioning is optional and would NOT be used if both IdPs are synchronized to the same Active Directory domain or if user account creation or synchronization is accomplished by some other fashion.
         1. If enabled, then an Identity Manager Directory name must be specified and it is recommended to provide a fully qualified domain (e.g. COMPANY.LOCAL, CUSTOMER.COM, etc.).
      6. Users: Select the user's directory/domain from the 3rd Party IdP which can authenticate to this Identity Manager tenant.
      7. Network: Select which network or network ranges the 3rd party IdP can be accessed from.
      8. Authentication Methods: Click the green “+” (plus) sign and add an Authentication Method. Give it a unique name and select urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport.
      9. Single Sign-Out Configuration: This is optional.  If enabled, provide a redirect URL for logout.
      10. Click the ADD button.
          
          
4. The second part is to create an authentication policy with fallback authentication for automatic SSO of users coming from the 3rd Party Identity Provider Identity Manager tenant.  This will allow the VMware Identity Manager tenant acting as the Primary Identity Provider to authenticate to the 3rd Party Identity Provider.
   
   Within the Primary Identity Provider Identity Manager tenant (i.e. The one which protects the applications), this is done within the Admin Console from the Identity & Access Management > Manage > Policies page by clicking on the default_access_policy_set and editing each of the authentication methods to add in the new fallback authentication created in step 1.1.7 (NOTE: The unique name should now appear as an authentication method).
   1. When opening the default_access_policy_set, you will see multiple authentication methods (by default you will see two - Identity Manager Client App and Web Browser).
      1. Edit all Policy Rules and add a new “Fallback Method” by clicking on the green fallback Method button.
         NOTE: DO NOT ADD A SECONDARY AUTHENTICATION METHOD TO THE NEW FALLBACK METHOD!
         
         
      2. From the new dropdown menu, select the newly defined method from the above procedure.
      3. Click the OK button.
         
         
   2. After all (or at least the desired) Policy Rules have been modified, click the SAVE button on the bottom of the default_access_policy_set page.
      
      The Primary Identity Provider Identity Manager Manager tenant is now trusting the 3rd Party Identity Provider Identity Manager tenant and ready to authenticate and authorize users.
      
      
5. The final part is to create a linked application from the 3rd Party Identity Provider Identity Manager tenant to the Primary Identity Provider Identity Manager tenant.  In this case, this is done on the 3rd Party Identity Provider Identity Manager tenant which is providing the initial authentication for user accounts (not the same tenant as the one used above in steps 3 and 4).
   
   NOTE: When using two Identity Manager tenants together with one as a 3rd party Identity Provider (IdP) to the other Primary Identity Provider, we can link to one of the applications from the Primary Identity Manager tenant or we can link directly to the Primary Identity Provider tenant CONSOLE or Application Catalog, using that as the “application" which the Primary IdP is protecting (this is the app catalog console which a user would see when logging directly into the Primary IdP Identity Manager tenant).
   
   Within the Service Provider Identity Manager tenant - where users will login to (i.e. NOT the same as the IdP Identity Manager tenant mentioned in the previous two major steps), this is done within the Admin Console from the Catalog > Manage > Application Catalog page by clicking on the Add Application button and selecting “…create a new one” from the Web Application menu.
   1. When adding a new application in Identity Manager, a new window will appear requesting the application details. The only two details we need for this first window are a Name (the user will see this as well as any description added) and an Authentication Profile of SAML 2.0 POST Profile.  It is recommended to add an icon which makes appropriate sense for end users to easily distinguish this application from others as well as a description but these are not absolutely required.
      
      Here we will use the Identity Manager IdP tenant catalog as the “application”.
      1. For Name, type "3rd Party Catalog”.
      2. For Description, type “Application Catalog of IdP Identity Manager Tenant <FQDN>” where FQDN is the actual FQDN of the IdP Identity Manager tenant.
      3. If you have a custom image you wish to use, click the Choose File button and browse to the image file and upload it.
      4. Ensure Authentication Profile is set to SAML 2.0 POST profile.
      5. Click the NEXT button.
      6. In RelayState type in the following address, replacing the <IDPFQDN> value with your IdP Tenant FQDN.
         https://<IDPFQDN>/catalog-portal/ui
         NOTE:  You may choose to use any actual application protected by the Primary FQDN tenant.  In that case, the RelayState URL pasted here is the Launch URL of the application from the Primary Identity Provider. For finding the Launch URL for non-SaaS/web based resources (e.g. Horizon, etc.), see further down.
         
      7. Leave Proxy Count and Login Redirection URL blank. Leave all check boxes and other options in their default state.
      8. In the Auto-discovery (meta-data) URL, type in the following address, replacing the <IDPFQDN> value with your IdP Tenant FQDN.  This is the Service Provider XML information of the 3rd party IdP as we are now addressing it as a Service Provider to the application we are creating.
         https://<IDPFQDN>/SAAS/API/1.0/GET/metadata/sp.xml
         NOTE: You can obtain this link from the Catalog > Settings > SAML Metadata page within the IdP Identity Manager Tenant Administrator Console.  It is listed as Identity Provider (IdP) metadata within the SAML Metadata section of the page.
      9. Click the SAVE button to process the IdP Metadata information.  Doing so will automatically process the metadata information and move to the Entitlements tab.
      10. In Entitlements page, add in the Group or Individual entitlements. Assuming both Identity Manager tenants (both the SP and IdP) are synching the same set of users, simply entitle this app to ALL USERS.  Set entitlement to AUTOMATIC (vs. User-Activated).  Click SAVE on the Add Entitlements pop-up screen to get back to the main window.
      11. In the main window, ensure you click the DONE button above the Entitlements section.
      12. You should now be able to see the application in the catalog of the Service Provider Identity Manager Tenant as a regular user.
   2. Browse to the 3rd party Identity Provider (i.e. the VMware Identity Manager tenant which is in front of the Primary Identity Provider).
      1. This will be something like the followingwhere <3RDIDPFQDN> is the FQDN of the first VMware Identity Manager tenant in Figure 2.
         https://<3RDIDPFQDN>
   3. Login as a standard user who was entitled in Step 5.A.10 above (assuming the built in All Users group was used to entitle users, then any user will see the app).
      1. This user should have access to and see the newly created application from the previous section.
   4. Launch the application.
      1. This user should see the launch of the above application kick over in the browser to the Primary Party IdP VMware Identity Manager tenant.
   5. Assuming everything is properly configured above, the user should see the web app catalog of the Primary VMware Identity Manager tenant (or the application it is protecting if specified as such in step 5.A.6) launch from the VMware Identity Manager tenant acting as the 3rd Party Identity Provider!

Finding the Launch URL:

SaaS/Web Apps

Finding the Launch URL for SaaS/Web is fairly straight forward.

1. Login as admin to your VMware Identity Manager tenant.
2. Browse to Catalog (drop down arrow) > Web Apps and select the desired web app.
3. Within the app details, you'll see the Launch URL shown.
4. Click the COPY URL to copy the link.

Non-SaaS/Web Apps (e.g. Horizon, Citrix, ThinApp, etc.)

While it is fairly easy to find the Launch URL for SaaS/Web resources within the VMware Identity Manager admin console, doing so for non-web resources is a bit trickier as the full URL is not listed.  It is, however, still pretty easy to do.

1. Login as admin to your VMware Identity Manager tenant.
2. Browse to Catalog (drop down arrow) > Web Apps and select any web app.
3. Within the app details, you'll see the Launch URL shown.
4. Click the COPY URL to copy the link.
5. Paste this link within a text editor.
6. Browse to Catalog (drop down arrow) > Virtual Apps and select the desired virtual app.
7. Select the resource's Details on the left side menu.
8. Within the app details, highlight and copy the External ID (SID) value.
   
9. Within the text editor, modify the pasted URL by replacing the GUID at the end of the Web App Launch URL with the GUID from the Horizon Resource External ID (SID).

Resources:

• VMware Identity Manager Documentation - This is the latest online VMware Identity Manager documentation.  Please note that you need to select the proper VMware Identity Manager version!  You will also need to search the respective version documentation for the topic, "Configuring a Third-Party Identity Provider Instance to Authenticate Users".
• VMware Identity Manager Integration Documentation - This is all of the latest VMware Identity Manager integration docs published by VMware.
• VMware Workspace ONE integration with Third Party Identity Providers - This provides integration information between VMware Workspace ONE (VMware Identity Manager) and Third Party Identity Providers. Please feel free to send any feedback to respective content authors.

This post will walk you through the very basics of using Postman to use the VMware Identity Manager REST APIs to either GET or POST data.

This post assumes either VMware Identity Manager 2.8.x on-premises tenant or newer or a VMware Identity Manager SaaS tenant.

NOTE: Some additional API calls may ONLY exist for on-premises tenants (e.g. node health status, etc.) which may not be accessible for VMware Identity Manager SaaS tenants.

The Basics:

On some occasions, customers may need to have a resource send a command to VMware Identity Manager but then redirect back. By default, VMware Identity Manager does not do redirects (this is by design), however, it can support them with a slight modification to trusts.  The changes are a one-time change per VMware Identity Manager tenant and remain from that point forward unless removed by an administrator.

In this example, we are showing the settings to both GET and POST updates to the "Allow Redirects" API, which tells the VMware Identity Manager what 3rd party sites the vIDM tenant is allowed to safely redirect a user to.

Warning/Notice!

Download 3rd party software at your own risk!  VMware does not assume responsibility or liability for your actions on any system or your use of 3rd party software or any damages which may be caused through the use of third party software.

Prerequisites:

• Postman - If you search for Postman, you'll likely come to the Download Postman App web page (This is the primary source as far as I can tell).
• A VMware Identity Manager tenant.  Preferably a test tenant (DO NOT TEST ON A PRODUCTION TENANT!).
• Admin credentials to the VMware Identity Manager (TEST) tenant

Getting the Bearer Token from the HZN Cookie in the Browser

The following are the instructions for grabbing the bearer token from the HZN cookie and then applying using Postman to access the APIs to update the settings for allowing redirects.

NOTE: Most modern browsers have an inspection mode.  Usually this is accessed by right-clicking on the web page and selecting INSPECT.

1. Open a browser such as Chrome and authenticate as admin account to your Workspace ONE tenant (Note: Make sure you have the option to view the Administrator console).
2. Open INSPECT mode in the browser by right-clicking on the page and selecting INSPECT from the context menu.
3. Select APPLICATION from the inspection window.
4. Select your Workspace ONE / VMware Identity Manager portal under cookies.
5. Find HZN under the name column and copy the value data to your clipboard.
6. In step 5.) of the below instructions, paste the token in for authentication as a Bearer Token.

Using PostMan to access Workspace ONE APIs to GET Values

When you define the parameters in PostMan, make sure the following are set.

1. Start with GET command to test URL.
2. URL to the API with correct FQDN of VMware Identity Manager tenant.  In this case, to read the “allowredirects” value from the Workspace ONE tenant, use the below URL.
   https://<FQDN>/SAAS/jersey/manager/api/authsettings/allowredirects
3. Open Authorization tab…
4. Set authentication type to BEARER TOKEN.
5. Paste in token from HZN cookie from browser (see above procedure to get token from HZN cookie).
6. When you press SEND, the Body value should appear as shown in the image below.

Using PostMan to access Workspace ONE APIs to POST Values

When you define the parameters in PostMan, make sure the following are set.

1. Start with POST command to test URL.
2. URL to the API with correct FQDN of VMware Identity Manager tenant.  In this case, to update the “allowredirects” value from the Workspace ONE tenant, use the below URL.
   https://<FQDN>/SAAS/jersey/manager/api/authsettings/allowredirects
   To note: Allowed redirects are per tenant (not per node within a tenant) so they only need to be set using the LB FQDN (e.g. portal.flaming.ws or workspace.mydomain.com).
3. Open Authorization tab…
4. Set authentication type to BEARER TOKEN.
5. Paste in token from HZN cookie from browser (see above procedure to get token from HZN cookie).
   
6. Switch to the HEADERS tab in Postman.
7. For updating the allowedredirects value we need to add in the “Accept” header with the following value:
   application/vnd.vmware.horizon.manager.authsettings.allowedredirects+json
8. For updating the allowedredirects value we need to add in the “Content-Type” header with the following value:
   application/vnd.vmware.horizon.manager.authsettings.allowedredirects+jsonNOTE: If you do not see the above image, you are likely in Bulk Edit mode.  If you’d like, you can just paste in the text per the next image, or shift to the Key-Value Edit mode in postman to see the above screen.
   
   
   
9. Within Postman, switch to the Body tab.
10. Select “raw” for the entry type. This allows you to type in whatever code you wish.
11. Select the code type.  This is optional as TEXT or TEXT PLAIN will also work.  The code we are entering is JSON so either TEXT/TEXT PLAIN or JSON will work.
12. Enter the following code.  PUT YOUR CAREGATE LOGOUT/LOGIN PAGE AND ANY OTHER PAGES IN COMMA SEPARATED FORMAT BETWEEN THE DOUBLE QUOTES.  ENSURE YOU ADD THE ASTERISK AT THE END OF EACH TO BE ABLE TO POINT TO ANY SUBPAGE.
    
    Single Site Code Example:
    { "allowedRedirects":["https://www.flaming.ws*"] }
    Multi-Site Code Example:
    { "allowedRedirects":["https://www.google.com*,https://www.flaming.ws*"] }
    
13. When you press SEND, the pages you define will show up under “allowedRedirects” within the Body outcome.
    

NOTE:  If you make an error, just correct it and repost the update.

If you wish to remove all redirects, simply delete all web sites between the quotes and POST the update.

Remove All Redirects Code Example:

Conclusion:

This should get you started with using Postman to use the REST APIs within VMware Identity Manager / Workspace ONE to help with better administering and programmatically calling for information and updates to/from Workspace ONE.

For a list of VMware Identity Manager APIs, see the VMware Identity Manager API explorer on code.vmware.com.

Summary

Up to 2.3.2-12839244

• Fix for configuration synchronizations for clustered vRO deployments
• Log instrumentation
• Fix of vRO scripting types literals (the type names was generated with proper capitalization)
• Fix REST host auto redirect feature persistence of REST Hosts
• -Fix of “newHostFromThis” of the REST Host type
• Adding support of HTTP parallel request by feature of the REST Host
• Fixing the actions getSupportedAcceptHeaderMediaTypes and getDefaultContentType
• Reduced plugin size
• Removed the exposed scripting methods that were exact duplicates of the exposed scripting attributes, attributes marked as read-only
• New methods for cookies management on RESTHost: getCookies(), clearCookies(), clearExpired(date)

2.3.3-13946087

• Added ability to create request operation with specified connection/operation timeout periods
• Fixed an issue where the api for creating workflows was producing flawed workflows
• Fixed an issue where vCloud Authentication loginUrl breaks the host url

The plugin build could be found at the attached file.

VMworld 2019 US conference will take place from 25 to 29 August 2019 in San Francisco. VMworld US conferences are designed to show VMware’s new products and what VMware company’s goals are for the future.

http://cmichal.com/bez-kategorii/vmworld-2019-us/

Michał

VMwareannounced the end of the vRealize Automation Development Kit availability. The current version of vRealize Automation is 7.6. The informationapplies to version 6.0.  The method of solving the problem isdescribed on the VMware KB website: 

https://kb.vmware.com/s/article/70832?lang=en_US

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

※留意事項※

本手順はDell EMC製品であるVxRailを対象としておりますが、一般的なLogInsightの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ファイル）をダウンロードください

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

※UpgradeファイルのダウンロードにはLogInsightもしくはvCenterのサブスクリプションが必要です。

※※VxRailのみを所有するお客様などはいずれのサブスクリプションも保持していない場合が多いと思いますので、Upgradeファイルをダウンロードできない場合はDell EMCサポートにご相談ください。

Snapshotを取得

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

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

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

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

２．管理画面へ移動

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

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

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

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

This document is a detail page for the VMware vExpert Directory.

Expert Information

View all vExpert entries