vLCM(vSphere Lifecycle Manager)がよくわからないのでまとめてみた

どうも、Tです。

vSphere7からの新機能vLCM(vSphere Lifecycle Manager)がクソほどわかりにくく、触りたく無いなぁと思っていたのですが、重い腰を上げまとめてみました。

ある程度、動作確認しつつ仕様をまとめていますが、実機(OEMカスタマイズ)の準備ができなかったので、がっつり検証ではありません。

環境

vCneter：7.0u2d
ESXi：7.0u2d(Nested ESXi)

vSphere Lifecycle Managerとは

vLCMの概要

vLCMは、VUM(vSphere Update Manager) の後継にになります。vSphere7のドキュメントからVUMはなくなり、vLCMのみ公開されています。

VUMがESXiのアップグレード・アップデートの管理を行っていたのに対して、vLCMはファームウェアなどハードウェアも含めたライフサイクル管理が行えるようになっています。

ライフサイクル管理とは、ソフトウェアをインストールし、アップデートやアップグレードによってメンテナンスを行い、運用を終了するプロセスを指します。
vSphere 環境の維持、特にクラスタとホストの維持という文脈では、ライフサイクル管理とは、新しいホストへの ESXi およびファームウェアのインストール、必要に応じた ESXi バージョンとファームウェアのアップデートまたはアップグレードなどのタスクを指します。

と言っても、ファームウェアのサポートはハードウェアベンダーがサポートしている場合のみ使用できます。主要な外資系ハードウェアベンダーは対応しているようですが、詳細はベンダーサイトから確認が必要です。

特定のハードウェアベンダーのファームウェアの更新は、ハードウェアサポートマネージャと呼ばれるソフトウェアモジュールを通じてアクセスする、ベンダーの特別なデポで入手できます。

vLCMはVUMを内包する

vLCMは、VUMの後継のため、VUMの機能を内包しています。ここが混乱した部分なのですが、vLCMは管理方法に「イメージ」「ベースライン」のどちらかを使用します。「イメージ」がvLCMが主軸とする機能であり、「ベースライン」はVUMの機能になります。

しかし機能名としては、vLCMで統一されており、管理方法の種別として「イメージ」「ベースライン」となりVUMの名称は消えています。

vSphere Lifecycle Manager には、以前の vSphere リリースで提供されていた Update Manager の機能が含まれていて、ESXi ライフサイクル管理のための新しい機能やオプションをクラスタレベルで追加することによって強化されています。

また、vLCMの管理画面が混乱を招きますが、下記のように機能によって扱う画面が異なります。

デポのイメージ：vLCM（イメージ）に関連する
アップデート：VUM（ベースライン）に関連する
インポートされたISO：VUM（ベースライン）に関連する
ベースライン：VUM（ベースライン）に関連する
設定：vLCM（イメージ）とVUM（ベースライン）に関連する

vSphere Lifecycle Manager イメージを操作する場合は、[イメージデポ] タブを使用します。vSphere Lifecycle Manager ベースラインを操作する場合は、[更新]、[インポートされた ISO]、[ベースライン] の各タブを使用します。

なぜvLCM？

そもそも、なぜこんな厄介な仕様にしているのだろうかと個人的に色々と考えました。HCIなども当たり前になった昨今、DELL EMC&VMwareの傑作であるVxRailなども考えるとハードウェアも絡めた管理を提供したい思惑もあったのでしょう。

しかし、下記のブログを読んでもう1つ「あぁ、そうか」と納得できました。

vLCM allows for customers to streamline OEM vendor components into the image. The vendor components and the ESXi image are disassembled in vLCM, making it easier to update the vendor specific components when a new vSphere release is issued.
vLCMを使用すると、顧客はOEMベンダーのコンポーネントをイメージに合理化できます。ベンダーコンポーネントとESXiイメージはvLCMで分解されるため、新しいvSphereリリースが発行されたときにベンダー固有のコンポーネントを簡単に更新できます

vSphere ESXiを扱う上でかなり面倒なので、OEMカスタマイズメディアの存在です。

OEMなどについては、下記にちょろっと記載しています。

VUMでは、パッチなどのビルドバージョンの比較で管理されていましたが、中身のvibの差異(ベンダー事のカスタマイズの差異）までは考慮されていませんでした。vSphere7からは、vibも考え方も変わりvLCMを使うことによって、ベンダーの差異も含めて、ライフサイクル管理を厳密化できるようになっています。

vibについては、下記に詳しくまとめてくれている方がいらっしゃいました。

vLCMのここに注意(2021年10月時点)

NSXでは使えない？

初期のvLCMでは、NSXがサポートされておりませんでしたが、現在NSX-Tはサポートされていました。色々やることは多いですがとりあえず使えるっぽいです。なお、NSX-Vに関しては記載が見つかりませんでした。

vCenter Server 7.0 U1、 ESXi 7.0 U1、NSX-T 3.1.0 以降では、vSphere Lifecycle Manager が有効になっているクラスタで ESXi と NSX-T の VIB のインストールを管理できます。

試しにNSX-T稼働中のクラスタのvLCM(イメージ)を設定しようとしたら、NSX関連のvibで怒られました・・・・暇があればドキュメント見てちゃんとやってみたいと思います（多分やらない）

vSANでは使えない？

vSANも使えないような記事をちょろっとみましたが、2021年10月時点では使えるようです。こちらも注意事項色々ありそうなので、下記をご参照ください。

vSAN クラスタを管理するには、vSphere Lifecycle Manager ベースラインおよびベースライングループを使用するか、このクラスタに単一イメージを使用します。

イメージからベースラインの変更ができない

ここが一番注意しないといけないと思ったところです。

vLCMは、管理方法に「イメージ」「ベースライン」があります。特になにもしなければ「ベースライン」の状態で使えるようになっています。

ここで、「ベースライン」→「イメージ」の変更は比較的容易に変更できるのですが、「イメージ」→「ベースライン」への変更はできません。

最初読んだときはどんな仕様よ？と思いましたが、2021年10月時点はそうらしいです。

クラスタにイメージを使用するように切り替えると、ベースラインを使用するように戻せなくなります。ホストは、ベースラインを使用するクラスタにのみ移動できます。

「イメージ」へ変更する際に、下記のようなメッセージは出してくれますが、設定する前に要件などを確認の上実施するようにしましょう。

vCenterのリストアの考慮

「ベースラインからイメージに切り替えた後のリストア」「イメージで管理されるクラスタを修正したあとのリストア」する場合お注意事項がドキュメントに記載があるので読んでおきましょう。

vLCMが嫌いなわけ

話が脱線しますが、個人的には大規模で恩恵のない限り、こういった集中管理は好きではありません。本番環境で使うと問題が出てトラブル印象が強いからです。アップグレード・アップデートはvLCM以外にもコマンドラインからなど手動での方法もあるので、そちらを選びたいと思う性格です。

なお、vLCMの既知の問題だけでも下記があります。おそろしいです。

vSphere Lifecycle Manager の問題

vCenter Server サービスがカスタムポートにデプロイされると、NSX デポを vSphere Lifecycle Manager デポにアップロードできない
すべてのホストでのイメージのセットアップとアップデートをまとめて管理するためにすでに有効になっているクラスタでは、NSX-T を有効にすることはできない
vSphere 7.0 リリースの vSAN クラスタで、vSphere Lifecycle Manager と vSAN ファイルサービスの両方を有効にできない
ハードウェアサポートマネージャが使用できない場合、vSphere High Availability (HA) 機能に影響がある
vSphere Lifecycle Manager で修正プロセスを実行した後、I/OFilter がクラスタから削除されない
vSphere Lifecycle Manager で vSphere HA 対応のクラスタを修正しているときに vSphere HA を無効にしてから再度有効にすると vSphere HA エラー状態になる
大規模クラスタにおいて、vSphere Lifecycle Manager での推奨イメージの確認のパフォーマンスが低下する
大規模クラスタにおいて、vSphere Lifecycle Manager でのハードウェアの互換性の確認のパフォーマンスが低下する
vSphere Lifecycle Manager でクラスタを修正するときに、英語以外の言語で不完全なエラーメッセージが表示される
ベースラインを使用するクラスタを単一のイメージを使用するクラスタに変換するとき、vSphere HA VIB が削除されることを示す警告が表示される
プロキシサーバ経由でインターネットからパッチアップデートをダウンロードするように vSphere Update Manager が構成されている状態で、vSphere 7.0 へのアップグレードを行って Update Manager が vSphere Lifecycle Manager に変換された後、VMware パッチリポジトリからのパッチのダウンロードに失敗することがある
Java クライアントを使用して修正タスクを確認する際に、修正操作から結果を抽出できない
ROBO (Remote Office and Branch Office) 環境の一般的な vSphere Lifecycle Manager デポとローカルデポが同期しない場合がある
ロックダウンモードが有効になっている ESXi ホストで vSphere Lifecycle Manager を使用したクラスタの修正に失敗することがある
vCenter Server 7.0.0b へのアップグレード後、vSphere Client の vSphere Lifecycle Manager ホームビューに [ロールアップの更新のみを表示] トグルボタンが表示されない
vSphere Client で、vSphere Lifecycle Manager ホームビューのタブを開くと、[ロールアップの更新のみを表示] トグルボタンが常に有効になる
Update Planner を使用すると、vSphere Client で更新の取得中に予期しないエラーが発生することがある

ベースラインとイメージ設定箇所の違い

ベースラインとイメージで一番最初の認識のところです。ベースラインはVUM同様クラスタやホストに対して設定を行います。イメージは、クラスタに対して設定を行います。

クラスタの設定を見るとベースラインとイメージの項目があります。

ホストはベースラインしか表示されません。

なお、クラスタにイメージの設定を行うとベースラインの項目は表示されなくなります。

下記のように、vibの管理方法も異なりますがイメージの説明で後述します。

vSphere Lifecycle Manager イメージと vSphere Lifecycle Manager ベースラインの違いを理解するには、ソフトウェアベンダーがソフトウェアアップデートの作成と配布に使用する基本的なソフトウェアパッケージタイプ間の関係を理解しておく必要があります。

デポとは？

vLCMの使い方などを見ているとデポという言葉がよく出てきます。VUMでもありましたが、そこまで気にしていませんでした。いい機会なので、まとめてみます。

デポは、vSphere Lifecycle Manageが使用するソフトウェアの集まりです。アップデートに必要なパッチファイルをイメージするとわかりやすいでしょうか。

厳密には、Linuxにインストールして使用できるUMDS(Update Manager Download Service)などもデポに関連しますが、めんどくさいので割愛します。

vSphere Lifecycle Manager デポ（ローカルデポ）

ローカルデポは、vCenter内にあるデポになります。オンラインデポ、オフラインデポのコンテンツが含まれたものです。vLCMが使うのはローカルデポです。

オンラインデポ

オンラインデポは、VMware社やサードパーティベンダーが提供しているデポです。URLを指定してダウンロードを行うようになります。デフォルトで下記のようにVMware社のオンラインデポが指定されいます。

vSphere7からは、各社のコンポーネントがVMware社のデポに集められているため、デフォルトのURLでほぼ事足りるような構成になっています。ただ、ファームウェアについては、VMware社のデポに含まれないため別途設定が必要です。

オフラインデポ

オフラインデポは、人がインターネットからダウンロードし、手動でローカルデポにインポートする考え方です。オフラインバンドル(ZIPファイル)やISOファイルなどがあたります。

オフラインバンドルのインポートがわかりにくいですが、アクションの更新のインポートから行えます。

ベースライン（VUMだったもの）

できること

VUMと同様です。さして変わるところはないように思います。

ESXi ホストのアップグレードとパッチ適用。
ESXi ホストへのサードパーティ製ソフトウェアのインストールと更新。

要件

ベースラインを使う要件は、気にするレベルはありません。

ESXi 6.5、ESXi 6.7、および ESXi 7.0 であること

イメージ（vLCMの本当の目的）

できること

ベースラインの内容に加えハードウェアを含めたことができるようになります。

vSphere Lifecycle Manager イメージを使用して、以下のタスクを実行できます。
クラスタ内のすべてのホストに、必要な ESXi バージョンをインストールします。
クラスタ内のすべての ESXi ホストにサードパーティ製ソフトウェアをインストールして更新します。
クラスタ内のすべてのホストで ESXi バージョンをアップデートおよびアップグレードします。
クラスタ内のすべての ESXi ホストのファームウェアの更新。
推奨を生成し、クラスタに推奨イメージを使用します。
VMware 互換性ガイドと vSAN ハードウェア互換性リストを基準として、ホストとクラスタのハードウェア互換性をチェックします。

要件

要件はベースラインよりシビアです。特にクラスタ内のホストが同一ベンダー同一ハードウェアであることです。イメージはvibも含めたファームウェア、ドライバの管理をクラスタ単位で行うため、この要件が必要になります。イメージは設定をするとクラスタを新規作成しないといけなくなるので、計画的に使用しましょう。

クラスタ内のESXiホストバージョンが7.0以降であること
ESXiホストがステートフル(ローカルディスクブート)であること
クラスタ内のESXiホストが同一ベンダー、同一ハードウェアであること
クラスタ内には統合ソリューションのみが含まれていること（vSAN、HA、NSX-T、Tanzu）

イメージとは？

vLCM(イメージ)を理解するために、イメージという考え方がネックだったのでまとめます。

イメージは、「基本イメージ」「ベンダーアドオン」「コンポーネント」をまとめた概念です。イメージとして扱ったものをクラスタに設定することで、クラスタ内のESXiホストは、イメージと同じ状態である（あるべき姿）としてバージョンアップなどを行えます。

vSphere Clientのクラスタでは、このイメージを設定することになります。

※ファームウェアはめんどくさいので、図から割愛しています。ベンダーアドオンと同じ扱いでよいと考えています。

基本イメージ

基本イメージとは、完全でサーバを起動できるコンポーネントの集合になります。とドキュメント通りいうと難しいですが、VMware社が提供しているオフラインバンドルになります。

vSphere Clientでは、vLCMのESXiバージョンの画面の内容になります。

Customer Connectのダウンロードで言えば、ESXiをダウンロードする下記のOffline Bundleのことになります。ベンダーのカスタムISOではなく、VMware社のOffline Bundleです。

ベンダーアドオン

ベンダーアドオンは、ベンダーが基本イメージからカスタマイズ差分です。また、コンポーネント(後述）を集めた集合体でもあります。

基本イメージとベンダーアドオンを合わせたものが、みなさんがインストールで使っているカスタマイズISOになります。

vSphere Clientでは、vLCMのベンダーアドオンの画面の内容になります。

Customer Connectのダウンロードで言えば、ESXiをダウンロードする下記のOEMのアドオンタブに表示されるベンダー毎に公開されているファイルになります。

コンポーネント

コンポーネントは、VIBの集合体です。vsphere7から出た新しい概念です。vLCMでは、適用する最小単位をVIBファイルではなくコンポーネントとして扱いします。

ドキュメントを読んでいて困惑したのが、コンポーネントを個別に提供しないといいつつ、作成と配布をするといっているところ・・・・誤記かな？

VMware および OEM がコンポーネントを個別に提供することはありません。VMware は、コンポーネントをまとめて完全に機能し、起動可能な ESXi 基本イメージにバンドルします。OEM は、コンポーネントをベンダーアドオンにバンドルします。サードパーティソフトウェアベンダーは、ソフトウェア（ドライバやアダプタなど）を個別のコンポーネントとして作成および配布します。

vSphere Clientでは、vLCMのコンポーネントの画面の内容になります。ツールやドライバであることがわかります。

余談ですが、vsphere7ではコンポーネントを扱うコマンドがあります。

実行してみたところ、下記のように表示されました。「esxcli software vib list」コマンドと比べて用途(Display Name)が出てくるのがうれしいですね。また、vib listより若干表示数が少なかったので、どれかにvibがまとめられているのでしょう。ただ、ドライバは1vibファイル=1コンポーネントのように見受けられます。