FastLinQ CNA(QL41xxx/QL45xxx)のvib updateについて
以前とある方より情報をいただいたvib updateに関する内容について、
改めて検証を踏まえ、備忘録として記しておきたいと思います。
Marvell社のCNA driverについて
Marvell(旧Qlogic)社からReleaseされているFastLinQ CNAは
プロトコル毎にvibが存在しており、具体的には
qedentv (Ethernet) / qedf (FCoE) / qedil or qedi (iSCSI) / qedrntv (RoCE)の4種類。
このVIBは、Marvell社で定められている整合性に遵守されていないと
新規導入時やUpdate時に依存性のエラーを起こしてしまいます。
ちなみに、ESXi6.7U3での関連vibはデフォルトだとおおよそこんな状態です。
ESXi7.0GAはこんな感じ。qedrntvが追加されていますね。
その為、カスタマイズされているメディアを使用されている場合等を除くと
基本的には使用したいプロトコルに合わせてvibを新規導入していく形になりますが、
軽い気持ちで導入を試すと、ほとんどの場合エラーで弾かれてしまいます。
以下はqedfをインストールしようとしてみた図。
あえて失敗するバージョンを入れようとしています。
出力されているエラー自体はとてもシンプルで
元々導入されているqedentvとコンパチが合ってない為に
インストールが拒否されている事が確認出来ます。
このCNAに関するvibの依存関係については、vmware社のページではなく
Marvell社のページから確認をする事が可能です。
なおこの整合性については、所謂 "or lator" 的な概念は無いので
完全一致の組み合わせのみ導入が可能です。
ここの組み合わせについては色々検証しがいがあるのですが、
ユースケースがかなり稀だと思うので一旦割愛します。
VIBの更新について
vibの導入(新規インストール)については都度CLIから導入が可能なんですが、
問題はvibの更新時です。
基本的にqedentvしか使用していない場合は他のvib同様に、
適宜コマンドラインから個別アップデートという形を取って問題ないですが
このCNAに関する複数のvibが導入されている場合、個別にupdateを試みると
先程検証した際と同様の[DependancyError]が発生してしまいます。
(仮に後でupdateするつもりでも、更新した瞬間の整合性のズレを許容しないという事です。)
これは、例えば既知の問題等によりqedentv "だけ" 更新が必要な場合でも、
このCNAに関するvibはMarvell社の定める整合性に沿って
全て一括でupdateする必要がある事を意味します。
update時に発生する条件としては恐らく以下2種類のどちらかになると思います。
1. qedentv + qedi or qedrntvのどちらか、または双方を使用している環境で
vmware社からダウンロードできるzipファイルを解凍してからデータストアに配置し、
直接vibファイルを指定して更新を試みている
2. qedfがインストールされている
vmwareからダウンロードできるqedentvのzipファイルは、qedi並びにqedrntvが内包されています。
その為qedfが導入されていない場合は、このzipファイルを対象にupdateをかけてやればOKです。
qedfが導入されている場合、このzipバンドルを使用しても
qedfとqedentvで整合性が異なる場合はインストールが弾かれてしまいます。
qedfをqedentvを同時にインストールする際、ワンライナーで複数vibを指定しても
結果は同じになってしまいます。
(ワンライナーで指定しても、結局一つ目のvib更新を試みた時にコンパチから外れてしまう為)
そこでどうするべきか、という問題が出てきます。
実施するべきワークアラウンドについては、
Marvell社の上述したKBの下部に記載されているように
Packaging Toolsを使用して、このCNAに関するvibを複数一括で導入する事が可能です。
流れとしてはこのPackaging Toolsを使用してvibバンドルをカスタマイズし、
カスタマイズ作成したzipバンドルをコマンドラインで導入する作業想定となります。
Packaging Toolsの事前準備
事前準備するもの：
・管理者権限 (一般ユーザで検証した所zipファイルの作成が出来ませんでした。)
・ESXi-CPT-v2.4.exe
・Marvell社の定める整合性リストに沿った各vib
※ 事前にesxcli software vib list等で、どのvibが入っているか確認する必要があります。
この各VIBは、ディレクトリ名は何でもいいので指定しやすい場所に作成し、
こんな感じでvib群だけを入れておくと作業しやすいです。
ESXi-CPT-v2.4.exeのダウンロード先：
https://www.v-front.de/p/esxi-community-packaging-tools.html
リンク先の"Download Latest version"を選択
ダウンロードされたexeファイルを実行してみると、こんな感じでPathの指定が求められます。
ここは深い意味は無いので、作業しやすいディレクトリを選択すればOKです。
展開したディレクトリを確認すると、いくつかファイルが確認出来ますが
"vib2zip.cmd"を管理者権限で実行しましょう。
実行するとこんな感じでポップアップが開かれます。
Name, version, Vendor等色々入力を求められますが、正直何でもいいです。
重要なのは参照先で、これは先程準備した、vibが収められているディレクトリを指定しましょう。
何がどのように反映されたかわかりやすいようにしておくため、こんな感じで指定しました。
Run! を選択。
5分もかからずに、作成が完了します。
先程zipファイルの格納先をvibの参照先と同一にしておいたので、
作成完了後同じディレクトリにzipファイルが出来上がってます。
先程指定したNameとVersionはそのままzipファイルの名前になるみたいですね。
このzipファイルをESXi上で指定して導入すれば晴れて作業完了です！
参考までにこんな感じの出力になりました。
#esxcli software vib update -d /vmfs/volumes/xxxxxxxxxxxxxxxxxxxxxxxxx/Name-Version-offline_bundle.zip
Installation Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: QLC_bootbank_qedentv_3.11.16.0-1OEM.670.0.0.8169922, QLC_bootbank_qedf_1.3.41.0-1OEM.600.0.0.2768847, QLC_bootbank_qedi_2.10.19.0-1OEM.670.0.0.8169922, QLC_bootbank_qedrntv_3.11.16.0-1OEM.670.0.0.8169922
VIBs Removed: QLC_bootbank_qedentv_3.0.7.5-1OEM.650.0.0.4598673, QLC_bootbank_qedf_1.2.24.0-1OEM.600.0.0.2768847, QLC_bootbank_qedrntv_3.0.7.5.1-1OEM.650.0.0.4598673, QLC_bootbank_scsi-qedil_1.0.19.0-1OEM.600.0.0.2494585
VIBs Skipped:
vib updateは慣れてしまえば手軽に実行できる反面、思いもよらないポイントで弾かれると
結構焦るので、備えあれば患いなしという事で備忘録でした。
vSAN Observerのオフラインバンドル取得について
"名前は聞いたことある"という方も多い vSAN Observer について、
備忘録を兼ねて採取手順をメモしておきます。
実行環境
■ ESXi, vCenter 6.7 U3
※ vSAN observerはvCenterにバンドルされているため、
ツールを新規インストールする必要はありません。
■ バンドル閲覧ブラウザ：Opera browser
採取手順
vSAN Observerをバンドル化し手元の環境で閲覧するためには
RVC (Ruby vSphere Console) からの操作が必要となります。
(vSAN Informationバンドル等もRVCから取得可能ですね。)
まずは通常の手順でRVCにログイン。
(RVCにログインできない際、多くの場合は末尾の"@localhost" 忘れによるものなので
普段RVCに積極的にログインしない方は気をつけておきましょう)
今更いいかなとも思いましたが、RVCにログインすると、数字を選択していくことで配下のディレクトリに
移動することができます。
これから実行するコマンドはログイン直後のディレクトリでもpathが通っているので、
特段特殊なアクションは必要ないです。
実際にコマンドの入力と、出力される直後は以下のような感じです。
このオプションについては
> vsan.observer localhost/<DC名>/computers/<vSAN Cluster名> となりますが
太字部分の "localhost" , "computers" は通常の環境であれば固定になります。
DC名とクラスタ名は何を入れればいいか...参考程度にGUIでキャプチャしてきました。
検証した手持ちの環境の場合、DC名 = "test-DC" , Clsuter名 = "test-vSAN" となります。
オプションで指定している "--run-webserver" ですが、これは単に"リアルタイム取得" を示しています。
多くの場合はこのオプションを付けての採取になるかなーと思います。
"--force" はイメージそのまま、エラーが出ても採取を続ける選択肢です。
"-g" は HTMLバンドルとしてエクスポートする選択肢になります。
今回はvSAN上で採取したものを手持ちの管理端末で閲覧したかった為、この選択肢を追加しています。
※ 余談ですが非省略形は"--generate-html-bundle"
今回入力した "-g /tmp" というオプションは
"今回の採取結果をHTMLバンドル化し、vCenter上の/tmpに保存する" という意味合いになります。
"--interval" はイメージ通り、採取調査間隔となります。
指定する数値は <sec> 単位となります。
※ 今回指定している "--interval 15" は "15秒おきのスポット取得" となります。
今回は指定していないですが、"--max-runtime" オプションを入力する事で
最大何時間採取するかを指定することが可能です。
指定する数値は <hour> 単位となります。
※ 後述しますがリアルタイム統計採取はいつでも中断が可能な上、
デフォルト(オプション無し) では2時間の採取となるので、特殊な状況でない限りは
あまり指定しなくていいかなと...。
ちなみに "-e" を指定すると、明示的にユーザが採取を止めるまで無限に採取を続けます。
このオプションを指定する必要がある場合はくれぐれも中断忘れにご注意を...。
実際に取得を始めると、おおよそ事前に指定したIntervalおきに、
以下のような感じで取得が進みます。
採取終了方法は "Ctrl + C" の入力です( CLI上にも都度都度その旨が表示されます)。
※ 中断されると、その時点までのログバンドルが作成されます。
中断するとHTML化がキャンセルされるわけではありません。
以下、Ctrl＋Cを押下した後の出力。
※ Ctrl + C押下がわかりにくかったので赤枠で囲んでます。
プロンプトが戻ってくる直前の最終行に、ログの保管場所が指定されていることがわかります。
ちなみにご経験された事にある方も多いと思いますが、vCSAのAppliance Shellはデフォルトで
WinSCPなどが使えません。
vCSA上でBASHシェルをデフォルト化するなど対処策も多く共有がされていますが、
今回私は vCSA > ESXiへSCPコマンドでバンドルを送付し、
Host Client GUIからダウンロードしています。
今回のように小さいファイルであれば、BASHシェルをデフォルト化するよりも工数が少ないので
Tips程度のテクニックですが覚えておいて損は無いと思います。
管理端末まで引っ張ってきた後に解凍すると、以下のようなファイル群が見受けられます。
(今回私は数分間のテスト実行でしたので、一般的にはこれより大きなサイズになるかと思います。)
フォルダの中に存在する"stats.html"をブラウザで読み込ませるとグラフが出てくるようになります。
が、残念ながらデフォルト設定のままでは、多くのブラウザでグラフが出てこないと思います。
読み込ませる手順として、Google Chromeや今回使用したOpera Browserでは
以下のようにブラウザを開く事でグラフを閲覧する事が可能になります。
(Users配下のブラウザは都合により黒塗りしています。)
キーとなるのが "--allow-file-access-from-files" の追加です。
これで開かれたブラウザに対してstats.htmlファイルを読み込ませると...
無事にグラフが出てきました。
ちなみに”Full size graphs”を押してみると、さらに見やすいグラフで出てきます。
実際にグラフを見てみるとIOPSやLatency、Outstanding IOなどのパフォーマンス項目ばかりなので
トラブルシュートとして使用されることは少ないかなと思いますが、
異常が起きた際の再現テスト時などに裏でObserverを動かしておくと
解決の糸口が見つかるかもしれませんね。
vSAN環境で特定Hostを一時的に切り離す手順
以前手持ちの環境で、一時的に管理IPのお引越しが必要になってしまい
その最中でvSANを一時的に切り離して設定変更が必要となりました。
管理IPの変更以外でも、緊急性を問わず "少しだけvSANから切り離したい" 場面が
出てくる可能性があったので、その手順を備忘録としてメモしておきたいと思います。
作業の内容
実際に今回作業した背景は管理IPのお引越し作業となります。
各Hostのみ、事情によりDNSのスコープ外としております。
今回は赤枠に囲ったHostの管理IPを"10.10.35.23"へ変更する作業となります。
(結果構成変更の反映がされたことがわかりやすくていいか...と思っています。汗)
環境はvCSA, ESXi ともに6.7U3環境、HTML5 GUI上で実施しています。
今回の作業はざっくり分けると以下6工程で実施をしております。
1. 該当Hostのメンテナンスモード移行
2. Hostの切断
3. vCenterの管理下から外す
4. DCUI上で管理IPを変更する
5. vCenterに登録しなおす
6. vDSへ再登録する
1. 該当Hostのメンテナンスモード移行
この辺は言わずもがなですが、一応。
裏でDNSのIP移行もしていた関係上、vSAN環境下のVMは全台停止させていますが
一台ずつのローリング作業であればVMは起動していてもOKです。
2. Hostの切断
今回のテスト環境は管理IPもvDSに属している環境となり、
メンテナンスモードに移行させた後に直接vmk0の管理IPを変更しようとしても
vDSとの兼ね合いで構成変更が失敗し、自動でロールバックして戻ってきてしまいます。
それを避けるため、一旦Hostを切断します。
Hostの切断後は以下状態になります。
VMを起動させながら作業を実行する場合はメンテナンスモード移行の際にvMotionさせている想定としておりますので
勿論起動させながらでも切断する事による影響はありません。
3. vCenterの管理下から外す
vCenterのインベントリから、このHostを除去します。
Hostのインベントリ削除が完了し、反映されているHostは2台のみとなりました。
4. DCUI上で管理IPを変更する
DCUI上でF2 キーを押下してManagement IPを変更します。
IP変更が反映されたら、vCenter上での作業に戻ります。
なお私の環境ではHostがDNSへ反映されておりませんが、ほとんどの環境はDNS登録をしていると思いますので
このタイミングでDNS上のA/PTRレコードも変更しておきましょう。
5. vCenterに登録しなおす
管理IPの変更が完了したら、Hostを改めてvCenterに登録していきます。
6. vDSへ再登録する
さて、最後にvDSへ再登録すれば作業は完了となります。
vSphere Clientのネットワーク画面からvDSを選択し、ホストを追加していきます。
追加するホストは、先ほど改めて追加したホストを選択します。
vDSに割り当てるvmnicを選択します。
今回vmkの構成を変更した作業は無いため、各vmkの設定はそのままでOKです。
最終的にvSphere Clientでタスクが完了したら、メンテナンスモードを解除して
作業は終了となります。
そこまで複雑な作業ではないですが、ご参考になれば。
VCAP - DTM Design (3V0-753) 受験体験記
私事ではございますがブログの更新をしばしお休みし、VCAP試験を受験してまいりました。
今回はそのVCAP - DTMの試験に関する体験記として、
受験の準備・当日の様子などを記したいと思います。
これから受験を考えていらっしゃる方のご参考となれば幸いです。
注：本記事で紹介している例文などは実際に出題された問題のご紹介ではありません。
目次：
・RCARについて
・出題範囲・出題傾向について
・学習リソースについて
・vSANについて
RCARについて
RCARについてまとめておきたいと思います。
VCAP - Design試験を受けた事のある方はよくご存知かと思いますが、RCARとは
・Requirement
・Constraint
・Assumption
・Risk
の頭文字を取った略語となります。
VMwareの導入段階における、実際の顧客とのやり取りを想定した問題が出題されます。
顧客からのメッセージを上記4種類に分類せよ、みたいな問題が出てきます。
上記のうち、一番わかりやすいのは"Risk"です。
IT業界、とりわけインフラ系に従事されている方であれば、パッと思いつくリスクが
大体そのまま答えになってくれる事がほとんどです。
例文1：「顧客のL3スイッチは冗長化される予定が無い」
例文2：「顧客の筐体は保守が切れているがそのまま使用する予定である」
...はい。そのまんま"Risk"ですね。
次に想像しやすいのは"Requirement"です。
"Requirement"というワード、そのまま"要求"と捉えてOKです。
例文1：「Windows7からWindows10への移行をする必要がある」
例文2：「顧客はハードウェアの刷新と共にセキュリティ強化をする必要がある」
"要求"である為、英文でテストを受験する際、"should"や"must"が入っている選択肢を
Requirementとして選ぶのではダメか...とたまに質問を受ける事があります。
確かに結果として回答がRequirementである事は多いのですが、出題文の本質を見極める必要があるので
個人的にはこの解き方はオススメ致しません。
should / must で終わる文章でもRequirement以外が回答となる事もあります。
このRCARにおいて一番悩ましいのが、"Assumption"と"Constraint"かなと思います。
・Assumption：仮定
・Constraint：制約
日本語に訳すると上記となりますが、この2点については日本語の"仮定" / ”制約”として
選択肢を考えるのは危険です。
往々にして、日本語の持つイメージと結びつきません。
こういうときは、英英辞典を頼ってみましょう。
Assumption：something that you think is true although you have no definite proof
Constaint：something that limits your freedom to do what you want
なんとなく、言葉の持つ意義がわかってきた方は素晴らしいです。
Assumption：true / Constaint：limit というワードが出てきました。
ここで一つ例文を出してみます。AssumptionかConstraintか、考えてみてください。
例文：予算は最大で$100,000である
日本語の"仮定", "制約"という面から捉えてしまうと、
途端にどっちだかわからなくなってしまいます。
この"予算は最大で$100,000である" という例文、
見た時に導入に携わるIT担当は何を思うでしょうか。
「あとこれだけ予算があればストレージを増強できる」
「さすがにこれではEnterpriseライセンスの購入は無理だ」 などなど...
背景を考えると、"true"というよりも"limit"の側面が強いセンテンスかなと感じる事が出来れば
RCARのマスターへの道はすぐそくです。
Answer： Constraint
もう一つ例文を出してみます。
例文：クラスタは6台構成だが、去年導入したばかりなのでリプレースの必要がない
こちらについてはいかがでしょうか。
先程の問題もそうでしたが、日本語の"仮定", "制約" という面から捉えてしまうと、間違いなく
"どっちでもない！"という回答になってしまいます。
このセンテンスについてわかる事は、"去年導入した"という事実であり、真実です。
また、リプレースの必要が無いのであれば何かを"limit"してしまう背景もありません。
Answer： Assumption
このRCARについては、VCAP-DCV Design試験でも多数出題されるため、
学習の際にはVCAP-DCVの学習リソースなどを参考にいただくのがいいかなと思います。
(実際YoutubeなどでもVCAP-DCV向けとしてRCARに関する動画が多数投稿されておりますが
DTM試験でも完全に応用が可能なので、見ておいて損は無いです。)
なおVCAP-DCV試験ではRCAR概念の他に"Functional / Non-Functional"等
他の概念も出題されましたが
私がDTM試験を受験した際はこういった概念の話はRCARのみに留まりました。
出題傾向
RCARの話はほどほどに、一番気にされるのは出題の傾向かなと思います。
あくまで体感値となりますが、参考程度に共有したいと思います。
まず本文ですが...非常に問題文が長いです。
VCP試験と比べると異質なくらい文章が長いですので、英語で受験される方は覚悟が必要です。
(10行程度の問題文である事もざらですので、英語を読むだけで時間が取られてしまいます。)
出題数・傾向(体感)：
Horizon View > Identity Manager(現WS1 access) > UEM(現DEM) > RCARなど、構築・設計一般・計算問題 > UAG
やはり、一番多かったのはHorizon View関連です。
VCPではほとんど出題されなかったCloud Pod Architectureをはじめとして
ケーススタディ形式のライセンスやClone方式の選択問題、
VCPの類似問題ともいえるようなポート番号・プロトコルを問う問題も出題されました。
Horizon Viewについては、VCP同様幅広く事前に勉強しておく必要があると感じられますので
VCPを受験されてから日の経っている方は、まずVCPで出題された問題を思い出して
VCPレベルの対策を始めていただく事を取っ掛かりとしていただければ問題ないと思います。
ただしどのDesign試験にも当てはまりますが、一問一答形式の問題が少ないです。
問題文を読み、消去できるものは消去をして、そこから更により正しいと思われるものを選んでいくスタイルで回答していくパターンが多いと思います。
例えば問題文に"Windows 8で構築したい"という文言がある場合、回答選択肢の中から
"Instant Cloneを使用する"選択肢が消去できます。
更に問題文に"可能な限り容量を節約したい" と記載がある場合Writable Volumeを使用する選択肢と使用しない選択肢ではどちらがより最適か...と考えていく解法になります。
次に多かったのはIDM関連問題という印象です。
ユーザのケーススタディ形式問題が多い兼ね合いで、様々な認証系の要求に応えていく問題が多いです。
SAMLやKerberos、TrueSSOなども合わせて必ず確認しておいた方がいいかなと思います。
また、IDMについてはその特性を確認しておくといいと思います。
IDMはどのようなときに使われるか？ 一例：リモートアクセス・クラウドへの接続... などなど
学習リソースについて
他のVCAP DTM試験の体験記でも記載されている事が多いですが、海外の有志が
試験範囲のPDFをまとめて下さっていますので、ご確認いただくといいかなと思います。
http://www.euc-kiwi.com/2017/11/27/vcap7-dtm-design-exam-study-guide-part-1/
現に私もこちらでまとめられているPDFを主な学習リソースとしました。
このHorizon ViewとIDM関連の問題で、おおよそ70%弱くらいを占めている...そんなイメージでした。
また私が個人的につまずいたポイントとして、"SQL Server"が肝になりました。
お恥ずかしい話WindowsのSQLはほとんど構築経験が無かったために、勉強の随所でつまずきました。
SQL ServerのQuery詳細等、細かいSQLの問題は出題されませんでしたが
どのような構成でSQLを構築するべきか? Oracle DBはどのコンポーネントなら使用可能か？
どのようにSQLを立てるか? などについても可能な限り確認しておくといいと思います。
またこれはテストの為の勉強という感じであまり気が乗らなかった部分もあるのですが、
色々なコンポーネントの旧名について、確認しておいた方がいいです。
(現にDEMも、全てUEMとして出題されますし、WS1 accessも全てIDMとして出題されます。)
答えはUAGのはずが、選択肢には"Horizon Access Point Appliance"とあったり...
回答は出せるのに、知らない事で正答を選べない状況は勿体ないです。
vSANについて
VCAP-DTMの特徴として、vSANの基礎知識があると望ましいです。
コンポーネントをvSAN上に配置する事によるリソース計算がどのように変わるのか、や
vSAN上にコンポーネントを配置する事による注意点なども軽く触れておくといいかなと思います。
例えばvSANはFTT=1の場合最小3ノードでクラスタ構成が可能ですが
1ノード障害による冗長性を確保する為には最低4ノード必要となります。
これくらいの前提知識でいいので、vSANを全く触れた事の無い方は確認しておくといいと思います。
逆にvSAN知識が無いと解けない問題も数問出題されますので
vSANを捨てる事は個人的にはオススメできません。
ここまで散々偉そうに体験記として記載している中恐縮ですが
結果は300点以上が合格でまさかの300点ピッタリによる合格でした。
非常に綱渡りな合格ではありましたが、一度で合格できて一安心...といったところです。
折を見て、DTMのDeploy試験にも挑戦予定ですので、合格した際には
体験記として共有出来たらいいなと思います。
vmware環境におけるTLS無効化について(vCenter for Windows版手順)
本記事ではインターネットの暗号化プロトコルであるTLSの無効化についてまとめます。
これから無効化を検討されている方の助けとなれば幸いです。
TLS無効化にあたる考慮事項について
TLS無効化にあたる考慮のKBは以下となります。
実際の手順についても記載はありますが、全て目を通しておくといいかなと思います。
https://kb.vmware.com/articleview?docid=2147469
ESXi各バージョンごとの対応
・ESXi 6.5 または 6.0U3以前のバージョン：明確な無効化はサポートされない
※ ただし出来るだけ新しいバージョンでの接続を自動で試みる
・ESXi 6.5 U1 - U3：明確な無効化が可能である。デフォルトでは全て(1.0-1.2)有効の状態
・ESXi 6.7以降：TLS1.2のみデフォルトで有効化されており、TLSv1.0/1.1はデフォルトで無効化されている
各バージョンごとにTLS有効化の仕様も異なるため、まずは自身の環境がどれに合致し、
どのような作業が必要になるか...を確認する事が大切です。
今回は実際作業を検討されるであろうパターンのうち、一番多いと思われる
"vSphere6.5 U1-U3の間でvCenterとESXiクラスタ双方のTLSv1.0無効化"をやっていきます。
実際の手順について(vCenter for Windowsの場合)
1. vCenterで再構成ユーティリティを導入する
(My vmware上でvCenterのダウンロードページにあります。
vCSAの場合はrpm拡張子 / vCenter for Windowsの場合はmsi拡張子)
2. vCenter上で古いTLSの無効化を実行する
3. ESXi上で古いTLSの無効化を実行する
なお今回の検証ではTLS1.0のみを無効化していく手順として実行していますが
TLS1.0 / 1.1双方無効にする場合でもコマンドのオプションでバージョン指定をする事が可能なので
後述するコマンドのサブオプションを適宜変更いただければOKです。
再構成ユーティリティ導入前のフォルダ状態：
msiファイルを実行後のフォルダ状態：
"VMware"配下に"CIS"フォルダができている事が確認できます。
msiファイルを実行し、上記のフォルダが出来たことを確認したら、
コマンドプロンプトで作業を実行していきます。
なお、最短であればvCenterのTLS無効化はコマンド一行で完了しますが
念のため事前にバックアップが取得できるかどうか確認しておきましょう。
> reconfigureVc backup
実行時の出力：
実際の設定更新コマンド：
> reconfigureVc update -p TLSv1.1 TLSv1.2
vCenterを再起動するけど続けるか？という質問が間に入ります。
問題ないのでこのまま"Y"を押下して進めていきます。
このコマンドを実行後、先ほど取得したバックアップの処理が改めて最初に走ります。
その後、以下のようなテーブルが表示されます。
この時点ではTLSv1.0がまだ表示されていますが、とりあえず問題ありません。
この表示が出力された後、各vCenterサービスの再起動が開始されます。
ESXi 6.5 U1の検証環境で再起動されたサービス一覧(停止順、変動の可能性有)：
・perfcharts
・vmware-psc-client
・vmonapi
・vmsyslogcollector
・vsan-health
・eam
・content-library
・sps
・vapi-endpoint
・VMwareDNSService
・vsm
・vpxd
・cis-license
・vsphere-client
・vsphere-ui
・vpxd-svcs
・vmware-vpostgres
・sca
・cm
・rhttproxy
・vmon
・VMwareSTS
・VMWareIdentityMgmtService
・VMWareCertificateService
・VMWareDirectoryService
・VMWareAfdService
・vmware-cis-config
上記のサービスが一度全て停止され、その後順に立ち上がってきます。
再起動後、vCenterでのTLS状況を確認してみます。
> reconfigureVc scan
無事TLSv1.0が表示されていない状況を確認したら、vCenter側は終了です。
ESXiでのTLS無効化について
vCenterの作業が終了したらESXi側に移ります。
コマンド入力に当たる今回の環境は以下です。
・vCenter管理ユーザ：administrator@vsphere.local
・対象Cluster名：Test-CLST
実際の作業は
コマンド例：reconfigureESX vCenterCluster -c <クラスタ名> -u <管理者ユーザ名> -p <有効化させておくバージョン>
今回の環境の場合、以下になります。
・-c：Test-CLST
・-u：administrator@vsphere.local
・-p：TLSv1.1, TLSv1.2 (今回はTLSv1.0のみを無効化させるため)
> reconfigureESX vCenterCluster -c Test-CLST -u administrator@vsphere.local -p TLSv1.1 TLSv1.2
管理者ユーザのパスワードを入力すると後は自動で進んでいきます。
※ 今回Clusterに属しているHostが2台(.141 / .142)です。
事前に確認していたように、ESXは自動再起動されませんが、設定反映の為には
再起動が必要となります。
以下、上記コマンド入力直後のWeb Client表記です。
その後は通常のHost再起動同様にメンテナンスモード > 再起動でOKです。
再起動後、ESXiでもきちんと無効化されているかどうか"openssl"コマンドで確認する事が可能です。
TLSv1.0(今回無効化したバージョン)の場合：
> openssl s_client -connect <hostIP>:443 -tls1
TLSv1.0(今回有効化したままバージョン)の場合：
> openssl s_client -connect <hostIP>:443 -tls1_2
有効化されているままのバージョンではServer Cerificate等が表示されているのがわかります。
以上で作業は終了となります。
TLS Reconfiguratorを使う為、環境の特殊なメンテナンスが必要かどうかなど
結構不安に思う方もいるかもしれませんが、作業自体はシンプルに完了できますね。
VMware環境におけるL1TF(CVE-3646, CVE-3620, CVE-3615 /esx.problem.hyperthreading.unmitigated )への対処について
ご存知の方も多いと思いますが、2018年後半に
Intel社より重要な脆弱性の報告がありました。
上記の問題に対し現在もご質問を受ける事が多い為、今一度情報をまとめてみます。
対象のCVE番号
今回記事の対象としているCVE番号は以下の3つです。
・CVE-2018-3646 (今回主に紹介する脆弱性、foreshadow-VMMとなります)
・CVE-2018-3620 (foreshadow-OS)
・CVE-2018-3615 (foreshadow)
一連のCVEに関する問題
本問題に気付かれるタイミングとして、以下のどちらかが多い印象です。
・定期的なセキュリティ診断時
・ESXiアップデート完了に後出現した警告 ( esx.problem.hyperthreading.unmitigated )
では実際に本問題の脆弱性とはどのようなものなのでしょうか。
本問題は"L1TF (L1 Terminal Fault)" と総称されております。
※ この"L1"とは CPUのL1 Cacheを指しております。
参考程度にテスト用筐体のsmBiosDump情報を持ってきました。
Processor Info: #1024
Payload length: 0x2a
Socket: "CPU1"
Socket Type: 0x2b (Socket LGA2011-3)
Socket Status: Populated
Type: 0x03 (CPU)
Family: 0xb3 (Xeon)
Manufacturer: "Intel"
Version: "Intel(R) Xeon(R) CPU E5-4610 v4 @ 1.80GHz"
Processor ID: XXXXXXXXXXXXXXX
Status: 0x01 (Enabled)
Voltage: 1.3 V
External Clock: 6400 MHz
Max. Speed: 4000 MHz
Current Speed: 1800 MHz
L1 Cache: #1792
L2 Cache: #1793
L3 Cache: #1794
Core Count: #10
Core Enabled Count: #10
Thread Count: #20
Cache Info: #1792
Level: L1
State: Enabled
Mode: 0x01 (Write Back)
Location: 0x00 (Internal, Not Socketed)
ECC: 0x04 (Parity)
Type: 0x05 (Unified)
Associativity: 0x07 (8-way Set-Associative)
Max. Size: 640 kB
Current Size: 640 kB
Supported SRAM Types: 0x0002 (Unknown)
Current SRAM Type: 0x0002 (Unknown)
CVE-3615として報告されている内容の実演があります。
このCVE-3615は"foreshadow" と命名され、このCVE-3615のいわば"亜種"として
CVE-3620 / CVE-3646が報告されています。
脆弱性の内容について報告されているリンクは以下となります。
CVE-3615：
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3615
| Systems with microprocessors utilizing speculative execution and Intel software guard extensions (Intel SGX) may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via a side-channel analysis. |
CVE-3620：
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3620
| Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access via a terminal page fault and a side-channel analysis. |
CVE-3646：
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3646
| Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access with guest OS privilege via a terminal page fault and a side-channel analysis. |
今回問題の根幹となっている"投機的実行"とは一体どのようなものなのでしょうか。
この"投機的実行"とは、ざっくり言うと
"ある計算の実行中に、推測される実行結果後の作業を前もってやっておく"
"前もって作業した結果のうち、当てはまらなかった分岐の作業は破棄する"
文字で読んで何となく想像できるように、この機能はCPUの効率的な使用と
パフォーマンスの向上に一役買っている機能となります。
本問題に関する対処について
本問題についてはそれぞれ以下のレイヤで対処が必要となります。
1. ハードウェアレイヤ (BIOS)
2. ハイパーバイザ
3. GuestOS
本問題の対処について、本記事ではハードウェア・ESXiに焦点を当て確認します。
1. ハードウェアレイヤ (BIOS)
こちらはサーバ・クライアント製品をご使用されている各ベンダーにて
確認が必要です。
例えばDELL EMC社からは以下外部KBが公開されております。https://www.dell.com/support/article/jp/ja/jpbsd1/sln318303/ja
PowerEdge等のサーバ製品・Precision等のPC製品について、
必要なマイクロコードはBIOSのアップデートが必要です。
サーバ製品向け：
https://www.dell.com/support/article/jp/ja/jpbsd1/sln309851/ja
クライアント製品向け：
https://www.dell.com/support/article/jp/ja/jpbsd1/sln309853/ja
2. ハイパーバイザ(ESXi)
ESXiレイヤで作業をする事で対処可能な脆弱性はCVE-3646 となります。
Security Advisoriesページは以下となります。
https://www.vmware.com/security/advisories/VMSA-2018-0020.html
URL内の表に "Replace_with/Apply_Patch" 行がありますので
当てはまる製品において、最低でもこのバージョンへのアップデートが必要です。
ESXiでの対処全般については以下に記載があります。
上記のAdvisoryページと合わせて確認をしましょう。
https://kb.vmware.com/s/article/55636
・CVE-2018-3646 (L1 Terminal Fault - VMM)
Mitigation of CVE-2018-3646 requires Hypervisor-Specific Mitigations for hosts running on Intel hardware.
・CVE-2018-3620 (L1 Terminal Fault - OS)
Mitigation of CVE-2018-3620 requires Operating System-Specific Mitigations.
・CVE-2018-3615 (L1 Terminal Fault - SGX)
CVE-2018-3615 does not affect VMware products and/or services. See KB54913 for more information.logical processor of the hyperthreading-enabled processor core.
CVE-3646の詳細については以下KBに記載がされています。
https://kb.vmware.com/s/article/55806
CVE-3646で報告されている攻撃方法は以下の二つです。
・Sequential-context attack vector:
a malicious VM can potentially infer recently accessed L1 data of a previous context (hypervisor thread or other VM thread) on either logical processor of a processor core.
・Concurrent-context attack vector:
a malicious VM can potentially infer recently accessed L1 data of a concurrently executing context (hypervisor thread or other VM thread) on the other logical processor of the hyperthreading-enabled processor core.
このCVE-3646は以下を満たしてしまうことで危険に晒されるものとなります。
・同一コアに2つのVMが同時に存在する
・そのうち片方が悪意あるVMである
本来ESXiは"vCPU"の形でコアごとに分割して割り当てるため、
一見問題は無いように見受けられますが
ハイパースレッディング機能がこの条件を満たしてしまうと報告されています。
一つの物理コアが、ハイパースレッディング機能により論理コアに分割され
その論理コアを最小単位としてVMに割り当ててしまうことができる為
一つの物理コアを、二つのVMが同時に掴んでしまう状況が発生しうる...という事です。
片方の悪意あるVMがL1TFを意図的に引き起こすことで保護機能が一時的に停止し、
もう片側のVMに関するL1 Cache情報を抜き取る事が出来てしまいます。
ESXiレイヤで対処をするためには上記2つへの攻撃対処が必要となり、
基本はアップデートが対処策となります。
しかしながらアップデートだけで作業は終わりではありません。
まず"Sequential-context attack vector"ですが、こちらはESXiのアップデートにより
自動で対処完了の状態となります。
※ アップデートバージョンについては上述のAdvisoryページを確認ください。
問題は"Concurrent-context attack vector" です。
このConcurrent-context attack vectorに関する対処をする際、パフォーマンスの大きな低下が想定されるケースが存在すると
vmware社公式の見解として発表されています。
参考：https://kb.vmware.com/articleview?docid=55767
理由は単純で、ハイパースレッディング機能を無効にするのと非常に近しい設定を
ESXi上で設定する事が理由です。
パフォーマンスの低下が見込まれる以上、アップデートで自動有効にされていないのも頷ける状況です。
KB55806にも以下記載があるように、あくまで使用者で責任をもって有効無効を決定し
vmware社はその決定に責任を負わない事が明記されています。
This is NOT RECOMMENDED and VMware cannot make this decision on behalf of an organization.
なおKB55806の中には2種類の記載があります。
これはESXi 6.7U2未満であるか否かにより手順が変わると記載されているものです。
a. Enable the ESXi Side-Channel-Aware Scheduler in ESXi 5.5, 6.0, 6.5, and 6.7 prior to 6.7u2.
b. Enable the ESXi Side-Channel-Aware Scheduler (SCAv1) or the ESXi Side-Channel-Aware Scheduler v2 (SCAv2) in ESXi 6.7u2 (13006603) or later
ESXi6.7 U2未満はaを、6.7U2を含むそれ以降はbを確認する必要があります。
なおどちらの手順であってもHostの再起動が必要となります。
他方、パフォーマンス低下を容認せず、対処をしない選択をする事も可能です。
その場合はこのアラートをサイレンス処理する事も可能です。
参考となる外部公開KBは以下です。
https://kb.vmware.com/articleview?docid=57374
具体的には、"UserVars.SuppressHyperthreadWarning" の値を
各VMで"0"から"1"へ変えておきます。
この詳細設定の変更はESXiの再起動を必要としませんが、各ホストの台数分作業が
必要となるので気を付けておきましょう。
VCP-DTM horizon 7.7 受験体験記
最近Horizonの学習を続けていたのですが
自分のマイルストーンとしてVCP-DTMを受験して来ました。
無事合格する事が出来ましたので、受験の体験記として投稿したいと思います。
Horizonは日本語の受験体験記が少ないので、
これから受験される方にとって少しでも参考になれば幸いです。
※ 守秘義務の為、実際に出題された問題や実際の問題に関するご質問は
承っておりません。ご了承ください。
今回受験した科目のURLはコチラです。
Blue Printについても以下に置かれています。
https://www.vmware.com/education-services/certification/vcp-dtm-2019-exam.html
VCP-DTM(7.7)の試験範囲について
まず試験範囲ですが、DCVやNVを受験された方にとっては
この範囲自体がハードルになるのでは...と思うくらい範囲が広いです。
・Horizon View Administrator
・UAG (Unified Access Gateway)
・UEM(現DEM、User Environment Manager)
・App Volumes
・ThinApp
・WorkSpace ONE (IDM等を含む)
・そのほかADやGPO等、Windows OSの知識
Horizon Mirageについては既にEOSLと言うこともあり出題はされませんでした。
※ 投稿日時時点でのVCAPでは出題範囲として残っておりますのでご注意ください。
試験時間は65問、105分で他のVCPと同様(のはず)です。
日本語が選択出来ましたが、vmware社のPDFが英語のみのものもあることから、
いつもと同じく英語で受験しました。
個人の体感として、出題された問題の多さで並べてみると、以下のような感じでした。
Horizon View > App Volumes > UEM > Windows OS関連 > WS1等、その他
メインソリューションであるHorizon Viewがやはり圧倒的に多かったです。
Linked CloneとInstant Cloneの違いや接続ポート、Horizon Agentの問題など
さすがにこの辺は幅広く、かつ満遍なく出題された印象です。
CLIを問う設題はほとんどありませんでしたが、基本的なvdmadminコマンドや
Icmaintコマンドくらいは使い方を覚えておくと後悔しないと思います。
CPA (Cloud Pod Architecture)に関する設題は、私が覚えている限りは
出題されておりませんが、出題される可能性があります。
※ VCAP Designでは多数設題に含まれている事が想像に難くないので、
VCAP受験を目指されている方はこの段階で学習しておくといいと思います。
その次に多かったのはApp VolumesとUEMですね。
Viewの勉強だけして受験に臨んでも合格は難しいと思われるくらい多かったです。
※ 体感ですが、App VolumesとUEMを足して30%くらい出題された感覚です。
どちらもアーキテクチャに含まれるコンポーネントがが多いので、
それぞれどんな働きをするか事前に確認しておくべきと思います。
・Management Console：管理を行うGUIを含めたコンポーネント。
構成情報はCentral Config Shareに記述される
・Endpoint：RDSHやVDIのデスクトップ + FlexEngine
・Active Directory：言わずと知れたWindowsの機能。
・Network Share：Central Config Share / User Share
・Application Profiler：スタンドアロンのアプリケーション。
Flex構成ファイルや事前定義等を簡単にする目的がある。
・Help Desk Support Tool：プロファイルのアーカイブなどが可能なツール。
・Self-Support Tool：ユーザ構成を管理・リストアが出来るツール。
・SyncTool：オフラインや帯域幅の絞られた環境でワークするユーザ向けツール。
【App Volumesのアーキテクチャに含まれるコンポーネント】
・App Volumes Manager：GUI管理機能を含めた各種構成に使用する根幹ツール。
・App Volumes Agent：Appstack / Writable Volumesを受け取るWinOSに対して
事前に導入するソフトウェア。
・Appstack：アプリケーションコンテナ。読み取り専用でマウントされる。
・Writable Volume：ユーザごとに個別で使用可能なボリューム。
Writable Volumeは複数ユーザで共有されない。
App VolumesやUEMであればvmware Hands-On-Labに配置されておりますので
環境をお持ちでない方は積極的に使用してみるといいかなと思います。
学習における重要なポイント
個人的な感想ですが、受験に向けた学習をする上で一番のハードルは
「圧倒的な設定項目の多さ」だと感じています。
この点はDCV, NV, vSANとは一線を画すくらい多いので
Horizon初学者の方はこの設定項目の確認に多くの時間を割いてもいいと思います。
Horizon View Administratorの各項目だけでなく、UEMやApp Volumes等についても
一通りどこにどのような設定項目があるか復習しておくといいかなと思います。
余談ですが私が受験した時、JMPコンソールの設題はありませんでした。
(<FQDN>/newadmin で表示される新しいコンソールですね)
ただしこちらも先述したCPA同様私が出会わなかっただけの可能性もあるので
JMPコンソールとView Admin コンソール、どちらも確認しておくといいと思います。
VMware社のHands on Labも例によって何度も活用させていただきましたが、
このHands On LabにはVIew Composerが存在していないため注意です。
余裕のあるリソースをお持ちの方はLinked Clone環境を作成してもいいと思います。
(Connection ServerやAD, SQLなど、事前構築が必要なコンポーネントが多いですが...)
Linked CloneそのものだけではなくView ComposerやEventDBに関する問題も
複数出題されたため、 "どのようにLinked Cloneを学習するか？"についても
事前に考えておく必要がありますね。
Windows OSに関する知識について
このポイントも私にとっては少々ハードルが高かったポイントで、
"デスクトップ仮想化"というジャンル上避けられない部分ではあるのですが
SysprepやAD, GPO等、Windows OSに関する知識も保持している必要があります。
また各HorizonのコンポーネントにはWindows OSとの整合性が定められているので
"どのコンポーネントはどのWinOSと組み合わせて使用可能か？" についても
必ず全て確認しておくといいと思います。
※ この点で要注意な点：既にWIndows 2008R2やWindows7はEOSLですが
本日時点で、試験では正解の選択肢として残存している点です。
Windows7はEOSLだ！とお気づきになられた方は、そのアンテナは素晴らしいですが
試験の際には"サポート範囲か"ではなく"仕様上使用可能か"を判断基準にしたほうが
失敗しないかなと思います。
例えばInstant CloneではWindows7とWindows10のみを対象としているため
現在のサポート対象でいえばWindows10のみですが、
試験中はWindows7も含める必要があります。
※ 試験中、どう考えてもWindows7を選ばないといけない設問があり、
そこで試験中に私も気付きました。
EOSLに惑わされ、サポートしていないOSを選択しないよう注意しましょう。
Horizon ClientはWindowsOSだけではなくiOSやAndroid, Desktop向けLinuxOS等
幅広く導入が可能ですが、iOS専用の問題・android専用の問題などは
私が受験する限りでは出会いませんでした。
ここは出題されたとしても1問かなと思いますので、わざわざiOSを購入してまで
Horizon Clientの学習をする必要はないかなと思います。
※ 私もiOSは持っておらず、iOSを持っている知り合いに
Horizon Client導入させてくれと頼もうか悩みましたが...
それだけのために依頼するのが申し訳ないのと対効果が薄いかなと思いやめました。
出題ジャンルについて
各コンポーネントごとではなく、出題ジャンルごとに比較すると、
体感では以下の感じでした。
仕様を問う設題 > 設定項目を問う設題 > 構築時に関する設題 > トラブルシュート
ここは他のVCP同様の出題比率だなという感想です。
Horizonの接続ポートや使用可能なSQLの種類など、仕様に関する問題が一番多く
僅差ですが次点で各コンポーネントの設定項目を問う設題が多かったです。
この2種類でおおよそ65％-75%くらいの体感です。
"構築時に関する設題"ですが、例えば構築した後に再設定ができない項目や
GPOの導入など、運用前の注意点などをここに含めております。
トラブルシュートについては他のVCP同様比率は低かったです。
ただしHorizonはbuild-to-losslessなどに代表されるように
パフォーマンスの向上がトラブルシュートに繋がるケースも少なくないため
GPO等で設定可能なパフォーマンスチューニング項目などについても
しっかり事前の確認をしておいたほうがいいかと思います。
かくかくしかじかではありますが、これによって無事VCPが取得出来ましたので
現在はVCAPのDesign, Deployの取得を目指して精進する所存です。
どちらも並行して学習を進めておりますのでどちらから受験するかは未定ですが、
VCAPについても合格次第体験記として共有できたらと思います。
