Adobe Flash Player終了に伴うVMware Horizonが受ける影響について

期間が大きく開いてしまいましたが、直近で確認した事をまとめておきます。

 

Adobe Flash Playerが12月末でサポート終了となります。
この"サポート終了"ですが、vmware製品のように
"自己責任で使用を継続できる"種のものではなく
"原則使用が強制シャットアウトされる" ため注意が必要です。

 

とは言っても、通常ブラウザを使用している場合であれば注意が表示されるので
"Flash Player自体が使えなくなる" という事自体は認知されている方が多いのではないかと思います。

 

f:id:pocmemo:20201206204717p:plain

 

 

今回は"Adobe Flash Player"のサポート終了に関する話をしていきたいと思います。

 

 

Adobe Flash Player終了に関するvmware製品の受ける影響について

まず先にKBを出しておくと...以下ページが既に公開されています。

VMware Flash End of Life and Supportability (78589)
https://kb.vmware.com/s/article/78589

 

まず最初にこのページについて確認しておくのがいいです。

 

Adobe Flash Playerがサポート終了する事について一行でまとめると
"これからはFlashじゃなくてHTML使ってね!" という話です。

 

 既にご検証されているブログも多くありますが、Flash Playerの最終リミットは
"2021年1月11日 23時59分" のようです。

 

管理端末の時刻を進めていくと、1月12日になったタイミングで
強制シャットアウトされていることがわかります。

 

1月11日 23時56分ごろ

f:id:pocmemo:20201206214047p:plain

 

1月12日 0時02分ごろ

f:id:pocmemo:20201206214057p:plain

※ 余談ですがこの"Fi"マーク...ご丁寧にFlash Playerのサポート終了を示すページにリンクされており、
クリックするとAdobe社のホームページにつながります。

 

 

 

話をKB 78589へ戻します。

VMware Flash End of Life and Supportability (78589)
https://kb.vmware.com/s/article/78589

 

このページに書かれている各種製品のうち、使用ユーザが多い(と思う)ものを
先に羅列しておきたいと思います。

 

~ vCenterの場合 ~

 

vCenterについては、v6.5以降が記事作成時点でサポートがされています。
v6.5 GAの時点で、代替となるHTML5は使用が可能です。

 

f:id:pocmemo:20201206205331p:plain

上記は6.5 GAのブラウザトップページになりますが
既に"HTML5"の選択肢を選ぶことが可能です。

既にご存じの方も多いと思いますが、HTML5を使用したGUIについては
当初からフル使用が可能なものではなく、バージョンを追うごとに
少しずつ機能が追加されていった歴史があります。

具体的には以下のページにまとめられておりますので確認しておくといいです。

 

vSphere Client の機能の更新
https://docs.vmware.com/jp/VMware-vSphere/6.5/rn/vsphere-client-65-html5-functionality-support.html

 

Flash Playerを使用した管理と同等の使用をしたい場合は
v6.5 U2d / v6.7 U2 への更新をすればいいことがわかります。
ただしこの機能更新はBugFixを加味していないものになるので
基本的にはできる限り最新のバージョンが推奨されます。

 

 

NSX-Vの場合 ~

 

既にNSX-Tへの移行がどんどん進んでいる製品になりますが
NSX-Vも勿論まだ健在です。

 

NSX-Vの NSX Managerについては、Flash Playerは使用していません。

 

NSX-Vですが、投稿時点ではv6.4.0以降がサポート対象バージョンとなり
このv6.4.0以降はHTML5 vCenterでの管理がサポートされています。

 

vCenter 6.5 GA + NSX-V 6.4.0 の組み合わせを使用して
vSphere Client上で管理項目が出ることを検証環境で確認しています。

f:id:pocmemo:20201206210105p:plain

 

ただしvCenterのHTML管理画面同様に バージョンが上がることで少しずつ
機能が追加されていってますので、出来る限り新しいバージョンへの更新が
推奨されています。

 

詳細は以下のKBページから追いかけるといいかと思います。

 

VMware NSX for vSphere の機能の更新-vSphere Client の
ユーザー インターフェイス プラグイン
https://docs.vmware.com/jp/VMware-NSX-Data-Center-for-vSphere/6.4/rn/nsx-vsphere-client-65-functionality-support.html

 

 

 

~ vRealize Operations Managerの場合 ~

 

vR Opsはv6.6.1からHTML5での使用に切り替わっています。

記事投稿時点ではv7.0以降がサポート対象バージョンになっていますので
サポート範囲内のバージョンを使用している場合は影響は発生しません。

 

 

Flash Playerがサポート終了してしまった時に、考えられる最悪のパターンは
"Flash Playerが終了する事またはFlash Player終了によって管理画面に影響が出ることを知らず、かつGUIベースでの管理が全く出来なくなってしまった"
状態となりますが、上述の3種類について、現在サポートされているバージョンは最低限HTML5GUI実装済のため基本的には最悪のパターンは回避できます。

 

 

では、今回のメインであるHorizonについて確認していきます。

 

 

~ Horizon の場合 ~

 

Horizon AdministratorのGUI画面は"Horizon Console" と名前を変えて
HTML5に対応した管理画面がローンチされています。

 

なおHorizonの場合、現在サポートされているバージョンでも上述した
"最悪のケース"に該当する可能性があります。

それは"Horizon 7.0 - 7.4 を使用の環境" です。

 

Flash Playerの代替は"HTMLを使用する事" と記載しましたが、
Horizon AdministratorでHTML5を使用する事ができるのは "7.5 以降" になります。

 

v7.0 - v7.4 の既存環境ではFlash Playerが終了した瞬間に
正規の手順では代替案が無くなる為、特に注意が必要です。

 

簡単にまとめてみます。

 

1. Horizon 7.0~7.4 :  HTML5 GUI未実装。
 → Adobe Flash Playerによる影響が即座に出る。

2. Horizon 7.5~7.13 : HTML5 GUI (Horizon Console)実装。
 → 従来のAdobeを使用したGUIHTML5 GUIが併用可能

3. Horizon 8 (2006) : HTML5 GUIのみ対応、Flash Player GUIはリタイア。

 

 

本記事の最初に取り上げたKB 78589 では Horizonの最小推奨更新先は
Horizon 7.10 と記載されていますが、
個人的には 7.13がいいのでは、と考えています。

 

理由1:Horizon Consoleが標準推奨とされたバージョンはv7.11である

 

これはリリースノートに明記されています。

VMware Horizon 7 バージョン 7.11 リリース ノート
https://docs.vmware.com/jp/VMware-Horizon-7/7.11/rn/horizon-711-view-release-notes.html

===========
Horizon Console が、Horizon 7 で推奨の基本 Web インターフェイスになりました。既存の Flash ベースの Horizon Administrator Web インターフェイスはサポートを継続しますが、2020 年初めには廃止される予定です。
===========

 

理由2:Horizon 7.11 / 7.12はサポート終了間近である

 

こちらも投稿時点のマトリクスになりますが、実はHorizon7については
大部分がサポート終了間近です。

Horizon7.12までのバージョンについては、あと3-4か月程度で
正式にサポートが終了します。

f:id:pocmemo:20201206213522p:plain

 

"Flash Playerへの対処を行うためにHorizon 7.11に更新したのはいいが、
結局数か月後にまた更新をしなければいけない" という事態になりかねないので
特段の事情が無い限りHorizon 7.13 (またはHorizon 8)への更新がいいと思います。

 

 

Horizon 7.13とHorizon 8 どちらを選択するか、についてですが
こちらはSQLの整合性なども鑑みると考慮事項が多いので
簡単にHorizon 8で"使えなくなった機能" を記載しておきます。

 

・ Linked Clone

vR Ops for Horizon

・Security Server

 

上記の3つが使用できない状態となります。
個人的には、かなり攻めた機能削減だなという印象です。
詳しくは以下を見てみるといいかと思います。

 

VMware Horizon バージョン 2006 リリース ノート
https://docs.vmware.com/jp/VMware-Horizon/2006/rn/horizon-2006-release-notes.html#deprecatedfeatures
・このリリースで廃止された機能
・今回のリリースでサポート対象外になった機能

 

 

なおLinked Cloneのサポート終了ですが、厳密には
Horizon 8 GA(2006)ではView Composerが準備されています。

ただしこのバージョンが最終リリースである事がほのめかされており
Composerに関するBugFixは絶望的です。

これは"使用を促す"リリースではなく、"Horizon 8を使用したいけど、どうしても
今だけはLinked Cloneを使わなきゃいけない!" という方向けの
かなり後ろ向きなリリースであると覚悟しておくべきかなと思います。

 

 

Flash Player リタイア後にどうしてもFlash Playerを使用したい場合...

 

実際問題、環境によってはどうしても一時的に使いたい瞬間が出てくる事も多いと思います。

KB78589を閲覧すると、下部に代替案が記載されています。
こちらは推奨しないと記載がありますが、一応手順について確認してみます。

 

検証環境: Google Chrome 87.0.4280.66 (in Windows 10 1809)
                    Horizon Administrator 7.4

 

作業は全てブラウザが導入されている管理端末上で行います。

 

早速、 user\AppData\Local\Google\Chrome\User Data\Default\Pepper Data\Shockwave Flash へ移動します。

この配下に"System"フォルダがあるかどうかを確認します。

 

と、私の環境はありませんでした。以下2つのフォルダがあるのみ...。
無い場合は作ってしまえばOKです。

f:id:pocmemo:20201213153739p:plain

 

さて、作ったら次にmms.cfgファイルを作成します。
AllowListUrlPattern にHorizon AdministratorのURLを入れていけばOKですが
Horizon Administratorの場合、Adobeを使用するのは<FQDN>/admin 以下なので
このcfgファイルにも" /admin/ "を忘れずに入れておきましょう。

 

f:id:pocmemo:20201213153749p:plain

 

cfgファイルを作成後、ブラウザを再起動して開いてみると...
無事、1月12日以降の環境でFlash Playerを使用する事が出来ました。

作業にすると2-3分で終わりますね。

f:id:pocmemo:20201213153757p:plain

 

注意点としてはvmware社が推奨していない事と、管理端末が複数ある場合は
その端末全てで実施をしなければいけないという事ですね。
(あくまで接続しに行くClient側からのアプローチなので)

 

またこの作業、画像を見てもわかりますが、単に"ブラウザの設定"を変更するものであって"vmwareの製品に即した手順" という訳ではありません。

その為今後の各ブラウザのアップデートによって作業内容が変わったり
作業の実施自体ができなくなる可能性もありますが
その場合は各ブラウザをリリースしているベンダーへの確認が必要になるので
自己責任として緊急時の一時的なソリューションとして使用いただくことを
個人的にも推奨します。

 

 

 

 

 

 

 

 

 

vSAN File Service DEEP DIVE (1)

vSAN7.0のdebutと共に、大きな新機能として公開されている"vSAN File Service"について
確認した内容を備忘録としてまとめます。

※ DEEP DIVE と銘打ってますが、ほとんどは基礎的な内容です。
  期待を煽る内容で申し訳ないですが暖かい目で見ていただければ幸いです。

 

簡単な構築並びにマウントまでのデモ・VIT(vSAN iSCSI Target Service)との比較や
ログバンドルからの状態確認等をしていきたいと思います。

 

■検証環境
vCSA 7.0 build: 16189207
ESXi 7.0 build: 16324942
vSAN 4node cluster (All Flash)
iSCSI/NFSマウント用VMWindows Server2016 (IP: 10.10.35.54)

 

vSAN File Serviceとは?

基礎的な内容らしく、vSAN File Serviceとは何か、から抑えたいと思います。
既に色々なBlogでまとめられていますので、簡単に記載するにとどめておきます。

 

 

・vSAN File Serviceとは、vSAN datastoreをNFSストレージとして提供する機能である。

・vSAN Enterprise / Enterprise Plusエディションで使用可能な機能である。
※ VITは全エディションで使用可能。

・有効化する事で各Host上にvSAN File Service提供用のVMが構築される(FS VM)。
 このVMは4CPU/ 4GB RAM / 12GBの仮想Diskを保持する。
 固定IP + DNS登録が必要となり、全FSVMが同じIPサブネットに属する必要がある。

・このVMはEAM (ESX Agent Manager)が管理元となり、DRSの影響を受けない。
 (1Host 1FSVMである事が求められているのでDRSの影響を受ける必要が無い)

・vSAN FSVMのストレージポリシーは初期状態から変更してはいけない。

・分散スイッチは6.6.0以降である必要がある。
 また、強い推奨としてvSAN FSVM専用の分散ポートグループ設定が求められる。

・寄稿時点ではNFS3 / NFS4.1プロトコルでの提供がサポートされている。

・ESXi自体にNFSストレージとしてマウントする事も可能であるが、
 vmware社としてその構成をサポートしていない。

・最低3ノードのvSANクラスタ上で構成可能であり、ストレッチクラスタ
   2ノードvSANでは寄稿時点で使用出来ない。

 

 

vSAN iSCSI Target Serviceとの併用・比較について

vSAN iSCSI Target ServiceとvSAN File Serviceを併用する事は、
結論から言えば全く問題ありません。

 

以下、vSAN iSCSI Target Serviceを有効化するまでの簡単なキャプチャです。

 

vSAN上でVITを有効化させ、IQNを発行しています。

f:id:pocmemo:20200815235611p:plain

 

 

LUN単位での切り出しをするので、事前に容量定義が必要です。

今回はテスト用に10GBの容量を定義してみました。

f:id:pocmemo:20200815235722p:plain

 

 

Windows上で切り出された容量と同じだけのiSCSI接続デバイスが表示されている事がわかります。

f:id:pocmemo:20200816001117p:plain

 

 

この状態で、更にvSAN File Serviceを有効化していきたいと思います。

事前準備として、FS VM構築に必要なAD DNSに登録を済ませておきます。

 

f:id:pocmemo:20200816001703p:plain

 

 

構築にあたって入力する必要がある内容は以下KBにもまとめられています。

https://docs.vmware.com/jp/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-CA9CF043-9434-454E-86E7-DCA9AD9B0C09.html

 

FS VMのOVFは初期有効化画面でダウンロードする事が可能です。

このダウンロードを一回しておけば、一旦無効化した後も
再度同じOVFを使いまわす事が出来ます。

インターネット接続がされていない場合は、手動でOVFアップロードをする事も可能です。

 

ただ、例えばDownloadが始まったものの上手くいかなかった等の場合も
次回再有効化する時にそのOVFを使いまわすような表記が出てしまい
例えばOVFを手動でアップロードしたり、Downloadしなおす選択肢が出ない事を確認しました。

そんなときは事前に以下作業をする事で、再度OVFのDownload または手動Uploadが
出来る事を確認しています。

 

■ vCenterへログインしOVFを削除する作業

vCenterにログインし、/storage/updatemgr/vsan/fileservice 配下にダウンロードしたOVFが格納されているような状況でしたので、
シンプルにrmコマンドで削除をしています。

 

f:id:pocmemo:20200816002157p:plain

f:id:pocmemo:20200816002333p:plain

一応この後service-controlコマンドで全サービス再起動もしていたのですが、
もしかしたらその必要も無いかもしれません。

 

 

 

・全て入力が終わり、有効化を押すとFSVMのDeploymentが始まります。
 検証環境で何度か有効/無効を繰り返していますが、
 いずれも大体15分程度でDeployが完了しました。

 Deploymentのタスクを追いかけていましたが、どうやら1台FSVMが作成された後
   そのFSVMをクローンする形で残りのFSVMを作成しているように見えました。

 

Deploymentが完了するとこんな感じでFSVMが作成されます。
各Hostに1台ずつ、計4台のFSVMが作成されています。

f:id:pocmemo:20200816124859p:plain

 


FSVMの作成が完了後、VITとvSANFSが問題なく併用出来ている事がわかります。

 

f:id:pocmemo:20200816124953p:plain

 

 

テストマウント用VMNFS Clientを導入し、実際にマウントした図がこちら。

 

f:id:pocmemo:20200816125307p:plain

 

 

vSAN File Serviceで閲覧できている残容量はvSANの容量と(ほぼ)同義です。

f:id:pocmemo:20200816130159p:plain

 

 

VITでは先にLUNを切り出す必要がある為、最初に設定した容量で
空き領域が反映しているのに対して
vSAN File ServiceではvSAN容量の全てが表示されている事がわかります。

一旦アンマウントの後vSAN File Serviceを再設定し、
そのうえでHard Quotaを設定して再マウントしてみましたが
マウントしているVM側から見る限り容量値にほぼ変化はありません。

※ このHard Quotaは、Nutanix機能で言う所のAdvertised Capacityに非常に近いものと捉えていただいて問題ないと思います。

 

f:id:pocmemo:20200816130300p:plain

 

 

 

Hard Quota設定後の再マウントも見えてくる容量の結果は変わらず。

f:id:pocmemo:20200816130358p:plain

 

 

また、Hostのパフォーマンス項目を確認するとVITに関連する項目はありますが
vSAN File Serviceに関するPerformance項目はありません。

これはVITが物理ホストを使用してサービスを提供しているのに対して
vSAN File ServiceはFSVMが機能を提供している事による差異だと思われます。

 <Performance Chart >

f:id:pocmemo:20200816133903p:plain

 

 

vSAN File Serviceの使用量について

使用を検討した時、恐らく一番最初に気になるであろう "実容量確認方法" ですが
特別な手順を踏む事なくvCenter上で確認が可能です。

 

f:id:pocmemo:20200816132956p:plain

 

試しにファイルを少し入れてみました。

 

テキストファイルとフォルダ内のファイルは合計16KBのファイルです。

f:id:pocmemo:20200816133207p:plain

 

ファイルが認識されると、vCenter上でも実行容量が確認出来ています。

f:id:pocmemo:20200816133223p:plain

 

 

vSAN File Serviceとして配置されるデータのObject処理について

※ こちらは残念ながら検証環境が小さい関係で一部検証が出来ておらず
 推察による考察部分が大きいので、実際の仕様と異なる可能性があります。
 参考としていただければ幸いです。

 

 

vSAN File Serviceとして配置されるデータについて、Object増減の推移を確認してみます。

 

■ vSAN File Serviceのルートとして記載されているObjectについて

 

先程配置したテスト用データを全て削除し、vSAN File Serviceで展開しているNFSについて
中身を空にした状態でのObjectはこのような状態です。

f:id:pocmemo:20200816142131p:plain

 

f:id:pocmemo:20200816142207p:plain

 

RVCのobj_status_reportでも同様の結果です。

f:id:pocmemo:20200816144858p:plain

 

一応Object Infoも確認しておきます。

f:id:pocmemo:20200816153226p:plain

 

f:id:pocmemo:20200816153324p:plain

 

この状態で、テスト用のファイルを改めて格納してみます。

f:id:pocmemo:20200816153017p:plain

 

vmware側のGUIでも正常に反映がされています。

f:id:pocmemo:20200816153505p:plain

※ 余談ですが"割り当てを超える使用量"という日本語はすこし不自然ですね...

  この値はこの後の検証での増減を見るに"HardQuotaの単純使用率"という認識でいいと思います。

 

 

 

格納後改めてObject Infoを確認していますが、USAGEに特段の反映はありませんでした。

 

f:id:pocmemo:20200816153613p:plain

 

あくまでこのObjectはvSAN File Serviceを展開する為だけのObjectなのかなと思います。

 

 

■ データの実体はどこにあるか

 

さて、問題のファイル実体オブジェクトはどこにいるのかという事で、
確認しやすくするために新しいStorage Policyを作っておきました。
"vSANFS-Dedicated-Policy-FTT1"と便宜上名付けています。

 

f:id:pocmemo:20200816155124p:plain

 

 

 

このオブジェクトはvm_object_infoでは出てこないので、
diskのobject_infoから検索したところ無事発見する事が出来ました。
(やはりポリシー名は細かく分けておくに限りますね。)

 

f:id:pocmemo:20200816155316p:plain

 

 

 

さて、このオブジェクトについてさらに確認をする為、100MB程度のファイルを
たくさん突っ込んでみます。

 

f:id:pocmemo:20200816163731p:plain

 

 

GUIへの反映も、一応都度確認しておきます。

f:id:pocmemo:20200816163746p:plain

 

 

この状態で、Objectがどうなるかを確認してみます。

f:id:pocmemo:20200816164014p:plain

 

 

 

配置されたファイル毎にオブジェクトが作成される訳ではなく、一つのオブジェクトが
足されたファイルの分だけ肥大している事がわかります。

恐らくこちらは容量が255GBを超えると通常のvSAN同様に
オブジェクトがStripeされるのだろうと想定されます。

一つのファイル毎にWitnessが作成される訳では無いため、ファイルの数だけメタデータが作られないという意味では
容量効率の良い構造だと言えると思います。

 

GUIで閲覧できる使用率や初回設定するHard Quotaの値等はFTT計算前の値になるので
実際はGUIに表示される使用量以上のデータがvSAN datastoreに配置されます。

サイジングについては運用上要注意ですね。

 

 

vSAN File ServiceのLoggingについて

 

vSAN File Serviceのログ出力についても簡単に確認をしてみます。

例えばVITを動作させると、iSCSI Connection等を司る"vitd"サービスのログ出力が開始されます。

vSAN File Serviceについて確認をしてみたところ、/var/run/log 配下でいくつか動きのあるファイルがいたので記載しておきます。

・vdfstool

・vsanfs.mgmt

・vsanfs.vdfsop

何か問題があった時はこの辺りから確認してみると良さそうです。

 

また、ESXi Hostを見るとvSAN DatastoreだけでなくVDFS Datastoreが作成されています。

f:id:pocmemo:20200816171615p:plain

 

CLIであればどのようなファイルが格納されているか、等もESXi側から確認が出来そうです。

f:id:pocmemo:20200816171946p:plain



 

 

以上、備忘録でした。

疑似障害を発生させた時の挙動はまた次のタイミングで検証したいと思います。

 

 

 

 

 

 

NSX-TのCLI Referenceについて

NSX-TのCLIの簡単な使い方やログバンドルの取得について
備忘録として記載しておきたいと思います。

※ 既にNSX-T 3.0がリリースされておりますが、本記事はNSX-T v2.4環境で確認をしています。

 

NSX-T 2.4 CLI reference guide ( vmware{code} )

https://vdc-download.vmware.com/vmwb-repository/dcr-public/0aa6ceb3-9f71-44f5-bef6-d4acab570b55/382a3731-d45e-43c1-ba0b-f98b64899e9c/nsxt_24_cli.html

 

 

◆Referenceを確認する時のポイントについて

 Referenceを確認する際に<Availability>と<Mode>の概念について記載しておきます。

 

【Availability項目】

 

このReference Guideですが、コマンドが通る対象がそれぞれに記載されています。

例として、"clear banner"コマンドを見てみます。

 

f:id:pocmemo:20200712170422p:plain

 

何が対象になっているか...については赤枠で囲った"Availability"を確認すればOKです。

 

例えば"get dataplane flow-cache config"コマンドの場合は
対象に"Manager"が含まれていません。

 

f:id:pocmemo:20200712170649p:plain

 

そのためこのコマンドはNSX Manager上で入力をしても
結果が返ってこないことがわかります。

 

【Mode項目】

Availabilityの他に確認するべき項目は"Mode"です。

NSX-Tでは事前にModeを変更しておく必要があるコマンドが存在します。

(必要な理由は少し違いますが、イメージとしてはSwitchの"Configure Terminal"を想像するとわかりやすいかなと。)

 

Reference Guideの内部にも以下の記載があります。

 

CLI Command Modes
The commands available to you at any given time depend on the mode you are currently in.

Basic. Basic mode provides commands to manage and view the status of the NSX-T appliance.

VRF. VRF mode, available on NSX Edge appliances, provides commands to view properties of a VRF (Virtual Routing and Forwarding) context.

Tier0_sr. Tier0_sr mode, available on NSX Edge appliances, provides commands to view properties of a tier 0 service router VRF (Virtual Routing and Forwarding) context.

Tier1_sr. Tier0_sr mode, available on NSX Edge appliances, provides commands to view properties of a tier 1 service router VRF (Virtual Routing and Forwarding) context.

Path. Path mode, available on NSX Edge appliances, provides commands to view properties of the logical router interfaces and logical switch ports in the path between a logical router interface and an IP address.

 

要は、"Basic"に属するコマンドなら何も考慮はいらないよ!という事ですね。
問題はそれ以外のModeへどう変更するか?という事ですので
それぞれのMode変更方法について、軽く記載しておきます。

 

 

VRF/Tier0_sr/Tier1_sr

この3つは全て同一の手順です。
Edge-VM上で使用する事がほとんどかなと思います。

VRF(Virtual Routing and Forwarding)は文字通りRouterの仮想化を提供し、Routing Tableを複数保持することが可能となる機能です。

それぞれのVRFにはIDがついていますので、このIDを指定する事で
VRF毎に情報の取得・入力・削除などが可能になります。

 

実際にModeを変更するには"vrf <id>"コマンドを使用します。

この指定IDによって、ModeがVRF/Tier0_sr/Tier1_srのいずれかになります。

 

例えば以下の例ではVRFIDを確認し、ModeをTier0_srへ変更させています。

f:id:pocmemo:20200712173453p:plain

VRFIDは環境毎に設定が違うため、必ずしもVRF:0を指定するとTier0_srへと遷移するわけではありませんが、このVRFIDの指定番号によって、Modeが変わるという事だけ覚えておけば問題ないと思います。

 

※ 余談ですがNSX-3.0ではVRF-Liteが実装されました。

https://docs.vmware.com/jp/VMware-NSX-T-Data-Center/3.0/rn/VMware-NSX-T-Data-Center-30-Release-Notes.html

 

 

path

pathモードもほとんどはEdgeVM上で行われます。
各Interfaceの詳細な状態を把握する事などを目的に指定するモードです。

先程のVRF Modeなどは"get logical-router"コマンドでリストしていましたが
pathモードは"get logical-router interfaces"コマンドでリストします。

 

f:id:pocmemo:20200712182001p:plain

 

f:id:pocmemo:20200712182149p:plain

 

ちなみにこのpathモードには"UP", "DOWN"のコマンドがありますが
これは所謂NICのUP/DOWNを指示するコマンドではなく、
リストされている選択可能なpathを変更するコマンドになります。

それぞれの情報を取得するために、いちいちexit > pathコマンドの打ち直しする必要を無くすために実装されているものですね。

 

先程のpathコマンドでは"...9b16"のuuidを指定していましたが、その状態で"DOWN"を入力すると、選択可能なもう片方のpathへ移動していることがわかります。

 

f:id:pocmemo:20200712182456p:plain

 

勿論これは構成によっては多数のpathが表示されることが想定されますので
場合によってはDOWNと何回も入力するよりUUIDを指定しなおした方が早そうな場合もありますが、とりあえずこれはInterfaceを落としたり再復活させるコマンドではない、という事だけ覚えておけばいいかなと思います。

 

 

 

◆Tips的コマンド

 

 

基本的にはNSX-V同様に、NSX-TもGUI上で実行できることはとても多いので
CLIで頻繁に作業をする事は無いかなと思いますが
CLIでの作業に備えていくつかご紹介まで。

 

set cli-timeout 0

NSX-Tの各ApplianceにはCLIタイムアウト値が設定されています。

 

f:id:pocmemo:20200712183249p:plain

上記のように、NSX-Managerはデフォルトで600秒が指定されています。
実際に何も入力せずPutty上で600秒放置してみましたが、
Puttyのセッションは勝手に閉じられていました。

CLIで作業する際、少し画面から離れてしまう度にSessionの張り直しをするのは
少々面倒かなと思いますので、ログイン後 > set cli-timeout 0 と入力して
セッションタイムアウトをしないようにしておくといいかなと思います。
(もちろん作業後は値を再設定しておけば戻すこともできます。)

 

st en

NSX-TのApplianceに対して、root権限アカウントへ移行するためのコマンドです。

 

f:id:pocmemo:20200712183626p:plain

このコマンドを使用した後はプロンプトが"#"に変更され、lsコマンドなども通るようになります。

exitで抜けることができます。

 

set user <username> password

このコマンドはパスワードのリセットをするコマンドです。

f:id:pocmemo:20200712183912p:plain

近しいsyntaxで、パスワード期限切れの日にちを変えることもできます。
(この数値の単位は [day] です。)

f:id:pocmemo:20200712183956p:plain

このコマンド自体はほとんど使用しないかな、と思いますが
実はこんなIssueの報告がされています。

 

NSX-T Manager および Edge ノードのログ ローテーションが停止する (76114)

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

 

上記への対処として実行が必要なコマンドですので、覚えておくといいかなと思います。

 

 

 

以上

 

VCAP- DTM Deploy(3V0-653) 受験体験記

少し古い試験ではございますが、先日VCAP DTM Deploy試験に合格しましたので
対策内容等をメモしておきたいと思います。

個人的には"温故知新"という言葉がフィットするテストで、
試験自体は確かに古いのですが、現在に至るまでのDTM関連ソリューションの
"進化の軌跡"を追えるような意義のある試験だったと感じています。

 

試験概要並びにBluePrint:

https://www.vmware.com/jp/education-services/certification/vcap6-dtm-deploy-exam.html

 

【Deploy試験とは?】
そもそもvmwareが提供するdeploy試験とはどういったものか、からメモしておきます。

"VCAPはVCPのワンランク上の試験である"という事はこのページを訪れたほとんどの方が理解されていると思いますが
そのうちdeployと位置付けられる試験は"LAB-based"の試験となります。


テストセンターで試験が開始されるといきなりWindowsのデスクトップ画面が表示され、
右側に問題文が表示されています。
画面はvmware hands-on-lab(以下"HOL")を起動させた時の画面に酷似しています。

 

HOLを起動させると右側にマニュアルが書かれていますが、ここが問題文に変わっています。
画面右上には残り時間と試験終了ボタンがあり、左上にはSEND TEXTボタンがあります。
イメージが難しい方はこのURLで気になったものを開いてみるといいかなと思います。
https://labs.hol.vmware.com/HOL/catalogs/

 

一問ごとに回答してコンソールを再起動する...みたいな作業は必要無いです。
全ての問題は全て同じ一つの環境上で回答出来るようになっています。
数問を除けばほとんどが独立している問題なので、例えば "問1を実施していないと
問2が出来ない" ような問題はほとんどありません。
時間がかかりそうなものは後回しにする、といった対応も可能です。

 

具体的な問題数は秘密保持の観点から明言は控えますが、このDTM試験においては
1問10分の計算では間に合わないです。
そこまで回答した全問に正解しても恐らく合格ライン届かないと思います。
個人的にはDCVで受験したdeploy試験より数倍時間が厳しかったです。

 

【COVID-19に関する内容について】

私は神奈川県のテストセンターを受講しましたが、このテストセンターでは
三密を避ける為の対策が徹底されていました。

 

テスト受講生の配置や換気消毒のご配慮に加え、
試験中はマスク着用義務もあったおかげで
テスト問題以外の部分で心配になる事は幸いありませんでした。

 

LAB-basedという事もあり、テストセンターへ伺う必要がありますので
ご心配な方は時期を見極めて受験されるといいかなと思います。

vmware社のCertification Managerでも周知がされていました。

f:id:pocmemo:20200629000231p:plain

 

LAB-basedだからといって、VCP試験より早めに行く必要がある等の制約は
特にありません。通常通りテストセンターへ向かいましょう。


【VCAP DTM Deploy試験のハードル】
個人的に得られるものはとても多かったのですが、
受験を目指すためにはハードルが高いと感じられる部分もありましたので
以下に内容を列挙してみます。


・Horizon Mirageが試験範囲に含まれている(既にサポートを終了している)
・Deployする為のコンポーネントが非常に多く、ある程度自前のテスト環境が必要とされる

 

最初のHorizon Mirageについてですが、こちらは既にEOSL製品と位置付けられていますが、こちらに関する問題が出題されます。
また問題数も1-2問では無いため、"Horizon Mirageは捨てる"という選択肢は実質無いものと考えた方がいいと思います。

 

ダウンロードリンクは投稿時点では使用可能ですので
以下からダウンロードして展開しましょう。
https://my.vmware.com/jp/web/vmware/downloads/info/slug/desktop_end_user_computing/vmware_mirage/5_0

またHorizon Mirageは少し特殊で、ESXi環境が必須ではありません。
その為相互に疎通が可能な場所に配置されていれば、vSphere環境外(Windows物理サーバなど)にdeployをしてもOKです。

 

【問題比率について】
あくまで私が受験した際の体感による比率となりますが、以下のような感じでした。
Horizon Administrator >> Horizon Mirage >> Identity Manager >>

   >>Thinapp,GPO >> その他V4H, Appstack等

 


さすがにHorizon Administrator上で実行する問題が一番多かったです。
Poolの作成やEntitlement、設定の変更やCPA関連に至るまで非常に広く出題されました。

全体の40-50%程度はこのHorizon Administratorに関する問題だった記憶があります。

 


その次が、意外でしたがHorizon Mirageに関する問題が多いです。

こちらもBase Layer/App Layerの作成等、基本的な内容は薄く広く出題されますので
Common Wizards項目は一通り確認しておいた方がいいかなと思います。

 

f:id:pocmemo:20200629010332p:plain

 

MirageについてはDeployするコンポーネントがいくつか存在するので
ESXi環境上に立てる場合はリソースの事前計算をしておく事を勧めます。 

 

ほとんど差はありませんが、Mirageと同じくらいの割合でIdentity Managerが出題されました。

Mirageとは違いvIDMはテンプレートからすぐDeploy出来ることや
実際の問題でADとの連携に関する問題が出題されたので、可能な限り手元にDeployする事を勧めます。

 

その他GPO等AD周りの問題やThinapp、Appstack、V4H等が数問出題されており、脇が固められている印象を受けました。

 

私は必要なコンポーネントは全て手元でDeployして検証して試験に臨みましたが
リソース等の兼ね合いで難しい方向けに、手元にDeployするべき製品等をグループ化してみました。

 

テスト環境でDeployするべき製品
・テスト環境用AD DNS
・Horizon Mirage製品
1. Horizon Mirage Server
2. Horizon Mirage Management Server
3. Horizon Mirage用のWindows SQL Server
4. Horizon Mirage Gateway VM
・Thinapp

理由:vmware Hands-on-LABで体験する事が出来ない為、
   自身でDeployする以外に検証する術がない。

 

VMware社のHands-on-Labで代用が可能であるもの
・Horizon Administrator
※ ただしHands-on-Labを使用する場合はLinked Clone・V4Hの環境が手に入らない為、
可能な限り手元でDeployしておく事をお勧めします。

手元でDeployする場合はView Composer並びにSQLServerをDeployしましょう。

・Identity Manager (現Workspace ONE access)
※ こちらもDeployした事の無い方は可能な限りご自身の環境上にDeployする事をお勧めします。

・AppStack

・vRealize Operations Manager

・vSAN Cluster

 

【時間との戦いについて】
まず覚悟が必要なのは、"回答する為にインストールするソフトウェアが多い"事です。
ほとんどのVMでview agentは未インストールですし、broker agentやhorizon client・
 appstack agent等も未インストールです。


また例えばMirageのlayer作成やV4Hの受信メトリクス表示など、
どうしても数分から10分程度待機が必要な問題も出てきます。
この待機時間に次の問題を見ておく等の時間管理は必須になると思いますので
冒頭でもお伝えした通り、"時間がかなり厳しい試験である"事は覚悟した方がいいでしょう。

※ 私も時間を割くべきではないと判断をし、回答を諦めた問題が2問程度ありました。

 

【"SEND TEXT"の活用について】

こちらはDTMだけでなくDCV等でのVCAP試験でも同様のTips的項目になりますが
GUI画面に直接文字を打とうとすると、英字キーボードの為特定の文字を受け付けない等の問題に遭遇します。

また正しく認識しない(一文字抜けたり同じ文字が2回押下されている事になっている)等がたまにあり
これがパスワード入力中とかだと弾かれてテスト中にかなり焦るので
出来るだけSEND TEXTボックスを使うようにするといいと思います。

このSEND TEXTボックスの使用感については、事前に何かのHand-on-Labで試しておくといいと思います。

 

 

 

体験記は以上です。
しばらくHorizonとにらめっこする時間が続いたので、
気分転換にVDIからは遠いソリューションを学んでみようかなと思います。

vmwareのCertification Manager上ではVCIX 2020になっているんですが
ACCLAIMだと2019になってましたので、2019版のロゴを掲載しています。)

 

f:id:pocmemo:20200629013009p:plain

 

vCenter7新機能:Update Plannerについて

最近は自前のテスト環境をvSphere7環境で動かしている事が多くなりましたが
vCenterの管理項目で新たに追加された"Update Planner"機能について備忘録として
記載しておきたいと思います。

 

Update Plannerとは

一言で表すとすれば、こういう良い方がいいかなと思います。

"管理しているvSphere環境をupdateする際に、整合性を確認してくれる機能"

 

今までは環境のアップグレードを検討する際、
VMware Product Interoperability Matricesを確認する必要がありました。

VMware Product Interoperability Matrices

 

管理下で動作しているVMwareの製品がvCenterとESXiくらいであれば
そこまで苦になる作業ではありませんが、それだけではなく
NSXやHorizon View, WorkSpace ONEやvRealize系など、
多岐にわたる製品を使用している環境では
マトリクスを確認するのも一苦労となる事がしばしばでした。

そのマトリクス確認を実施する手間が省けるようになった機能、と覚えていただければ
概ねvmware社の意図しているものと間違いないと思います。

 

機能を使用する為の要件は以下の2つですね。

1. 少なくともvCenterがCEIPへ参加している事

2. 有効なインターネット接続が可能である事

こちらはvSPhere6.7で登場したオンライン健全性確認と同じ要件になるので
既に6.7U3でオンライン健全性を利用していた方は、それ以上の考慮は必要なさそうです。
(vSANでもリリースカタログをオンラインで引っ張ってきて互換性を確認する機能がありましたが
 その動きと同じイメージでいいと思います。)

 

Update Planner画面について

 

実際にUpdate Plannerを開く前にvCenterのサマリ画面を見比べてみたいと思います。

 

こちらの画面は見慣れたvCenter6.7U3の画面です。

f:id:pocmemo:20200614232525p:plain

 

他方vCenter7.0ではこのような画面になっています。

 

f:id:pocmemo:20200614232708p:plain

 

ほとんど変わらないように思いますが、バージョン記載の右側に
小さく"使用可能な更新" と青く表示されている事がわかります。

実はこのボタンはマウスカーソルを合わせるとクリック出来るようになっており、
実際に押してみるとUpdate Plannerの画面に移行します。
(勿論タブから直接遷移してもOKです)

 

f:id:pocmemo:20200614232918p:plain

 

この画面で出来る事はこんな感じです。

・現在の整合性確認

・vCenterのアップデートを見据えた整合性確認

 

f:id:pocmemo:20200616054551p:plain

 

このうち、2番目のアップデートを見据えた整合性確認については
vCenter7.0 U1, U2がリリースされた後に本格的に使用する事になる機能かなと思います。

記事掲載時点ではvCenter7.0 のみリリースとなりますので
"現在の運用性確認" に焦点を置いて確認してみます。

 

まず、Update Plannerでは管理下の各ESXi HostやvSAN, NSX-Tについては
自動で導入されているか否か検知をしてくれます。

Horizon 7 やIdentity Manager (WS1 Access)、vRealize系製品は
別途手動で登録してあげる必要があります。

※ 試しにvSPhere7.0と整合性のあるHorizon Administrator 7.12を環境に導入し
  vCenterとの連結をしてみましたが、Update Plannerでは自動検知されませんでした。

 

まだこの環境にはvSANやNSXは導入しておりませんので、それぞれの表記を確認する為
手動でいくつか入れてみました。

 

f:id:pocmemo:20200616054728p:plain

 

ESXiについては自動で認識してくれています。
検証環境にはHostが5台いるので、(5)はHostの数を表していると考えられます。

VMware Horizonについては、先程記載したように本当は7.12が入ってますが、
あえて7.7.0としています。

既存のバージョンとvCenterの互換性が無い場合は互換性のあるバージョンを表示してくれている事が
わかりますね。

次にIdentity Managerを追加した行について。
こちらについては整合性が取れている事から緑色のチェックが付いています。

次はVIC (vSphere Integrated Container)の行について。
実はこの機能、現状ではまだvSphere7には対応しておりません。

その為、互換性のあるバージョン無し、と出力されています。

 

互換性のお話は、以下からも確認ができますね。

vSphere 7.0 へのアップグレードを行う前の重要な情報 (78487)
https://kb.vmware.com/s/article/78487?lang=ja

 

===============

これらの製品は、現在 vSphere 7.0 とは互換性がありません。

NSX Data Center for vSphere
vSphere Integrated Containers
vRealize Operations

===============

なおvRealize Operationsについてはその後v8.1がリリースされ、
晴れてvSphere7への対応が解禁されています。

恐らく掲載日の兼ね合いで情報が前後しているのだと思います。

vRealize Operations Manager 8.1 Release Notes

 

参考:

f:id:pocmemo:20200616062519p:plain

 

 

 

この機能については、"この画面で全てのアップデートが出来るようになる機能"ではなく
"アップデートのプランニングに一役買ってくれる"ものなので、派手な印象は受けませんが
これからvSphere7.0の新しいリリースが出るに従ってありがたみがどんどん感じられる
そんな機能になる予感ですね。

 

 

 

 

 

 

vCenter7.0のデベロッパーセンターについて

別件の検証をしている時に気付いたことのメモとして。

 

以前のvCenterではhttps://FQDN/apiexplorer を入力した際に
apiexplorer用のGUI画面へ遷移していましたが、7.0では少し変化しているようです。

 

vCenter6.7 U3との比較

今回はvCenter 6.7 U3とvCenter7.0GAで比較してみました。

 

まずはvCenter6.7U3から。

f:id:pocmemo:20200517125510p:plain

 

(このvCenterはADに入れてないのでFQDNではなく、IP入力になっていますが)

いつものようにapiexplorerへアクセス。

f:id:pocmemo:20200517125558p:plain

 

結果、いつもの画面にログイン。

(当たり前と言えば当たり前ですが、一応比較用として...)

f:id:pocmemo:20200517125646p:plain

 

 

 

一方、vCenter7.0側でのログイン。

 

f:id:pocmemo:20200517125723p:plain

 

同じようにブラウザでapiexplorerへのアクセスを試みる。 

f:id:pocmemo:20200517125752p:plain

 

いつもの画面に...と思いきや、vCenterのデベロッパーセンターへリダイレクトされました。

 

 

f:id:pocmemo:20200517125802p:plain

 

 

では、、、無理やりindex.htmlにログインを試みるとどうなるか...

f:id:pocmemo:20200517130018p:plain

 

やはり、同じようにデベロッパーセンターへリダイレクトされました。

f:id:pocmemo:20200517130056p:plain

 

 

ちなみにこのデベロッパーセンターはvCenter6.7U3にもあります。

f:id:pocmemo:20200517130141p:plain

 

さてこのデベロッパーセンター画面を比較してみたところ、
いくつか使いやすい追加機能がありましたのでついでに記載。

 

vCenter7.0のデベロッパーセンター画面について

 

vCenter 6.7U3でのデベロッパーセンター画面はこんな感じ。

※ 比較用に、双方ともvCenter関連APIの"VM"で見ています。

 

f:id:pocmemo:20200517130319p:plain

 

一方7.0のデベロッパーセンターはこんな感じ。

 

f:id:pocmemo:20200517130356p:plain

 

一目見ただけで情報量が全然違いますね。

試しにこの画面から GET (/rest)/vcenter/vm を投げてみます。

 

まずは6.7U3のレスポンス画面。

 

f:id:pocmemo:20200517130545p:plain

 

とりあえず期待通りの結果が返ってきている事はわかります。

この従来のTRY IT だけでも結構ありがたいのですが、7.0では強化されていました。

 

f:id:pocmemo:20200517130644p:plain

 

Response項目がマウスクリックできるようになっており、

クリックすると開かれていく...ような形に変わっていますね。

 

これが開発環境の場合はすぐjsonテキストが閲覧できた方がいいようにも思えますが
あくまでこのページはTRYするページという意味合いが強いので
こっちのほうが視覚的にもわかりやすいかなと思います。

 

ちなみにそれぞれの項目に二つアイコンがありますが、
左側の四角いアイコンは"クリップボードへのコピー(いわゆるCtrl+C)"、
下矢印アイコンはjsonファイルのダウンロードでした。

 

押下するとこんなポップアップが開かれます。

 

f:id:pocmemo:20200517131041p:plain

 

 

このデベロッパーセンターはv7.0で触る事で新しい気づきがありそうなので
色々遊んでみたいと思います。

 

 

vSphere Clientにログイン時、ユーザに同意を求める方法

vSphere Clientにログインする際、情報の共有だったり、
場合によっては何かを承諾させたい時に使えるTipsとして
意外と存じ上げない人もいるので共有として投稿します。

 

vSphere Client上でバナーを表示させたい

Linux OS等では一般的に/etc/motdを編集する事で、ログインしたユーザに対して
情報共有をかける事が可能ですが
vSphere Clientにも近しい機能が存在します。

"今日のメッセージ" 項目に好きな言葉を入れてGUI上で設定が可能です。

 

設定方法は簡単。

vSphere Clientでツリー最上位のvCenterを選択し、"設定" > "今日のメッセージ"

f:id:pocmemo:20200509135714p:plain

 

編集する為には管理者グループに属している必要があるので、
一般権限ユーザでログインしている場合はログアウトして入り直しましょう。

 

今回は私以外誰も触れない検証環境なので、軽い気持ちでトライ。

f:id:pocmemo:20200509140048p:plain

 

余談ですが今年の流行語大賞は"三密"か"STAY HOME"になるんじゃないかと
勝手に思ってます。

 

入力し、OKを押すと今日のメッセージ欄に設定が反映されました。

f:id:pocmemo:20200509140108p:plain

 

 

実際にこのバナーが有効になるのは、"設定後にログインしたユーザ"が対象なので
この登録の瞬間はGUIにも何も変更はありません。ログインし直してみましょう。

 

f:id:pocmemo:20200509140309p:plain

 

この画像だとすこしわかりにくいですが、GUIの一番上にバナーが出るようになりました。

勿論"今日のメッセージ"項目から移動してもバナーは常に表示されています。

 

ログインする瞬間に表示させる

vSphere Clientへログインする瞬間に何か情報共有を表示させるには
このバナーではダメなので、別の手段を使います。

Linux OSでいうと、/etc/motdではなく/etc/issue 上に設定させるイメージですね。

 

設定場所は、vSphere Clientの"管理"画面から。

f:id:pocmemo:20200509140815p:plain

 

場所は"管理"画面の "Single Sign-On" > "設定" > "ログインメッセージ"

f:id:pocmemo:20200509140858p:plain

 

デフォルトでは無効になっているので、設定を編集してみます。

メンテナンスが実行される事を想定して、注意を促すような設定としてみます。

f:id:pocmemo:20200509140957p:plain

 

設定後ログインし直してみると、ユーザ名・パスワードに加えて
チェックボックスが表示されている事がわかります。

このチェックボックスへのチェックを付ける事で、ログインが可能になります。
チェックボックスまでは不要、というような場合には
"承諾チェックボックス"をOFFにすればOKです。

 

f:id:pocmemo:20200509145904p:plain

 

タイトルを押してみると、簡単なポップアップが表示されます。

f:id:pocmemo:20200509150155p:plain

 

この機能はシンプルですが、例えば運用チーム内での最終リマインダや
ヒューマンエラーを無くすためのリマインド等、活用の幅は広いんじゃないかなと思います。

 

 

ON/OFFもシンプルに出来るので、初耳の機能!という方は是非使用してみてはいかがでしょうか。