目次
はじめに
前回のエントリ で、vSphere 6.7 の環境のうち、vCenter Server を 7.0 にアップグレードして、最新のパッチの適用も行いました。このエントリでは、ESXi を 7.0 にアップグレードし、パッチの適用も行います。
ESXi 6.7 から 7.0 へのアップグレード方法は、ドキュメントでも提示されている とおりにいくつかありますが、今回は、vSphere 7.0 からの新機能である、vSphere Lifecycle Manager（vLCM）を利用します。パッチの適用も vLCM を利用します。
対象の ESXi は、Intel の NUC（NUC8i5BEK）にインストールされています。VMware 的には非サポート（HCL に載っていない）ですが、気にせずできる範囲でやっていきます。
vSphere Lifecycle Manager
これまでも、vSphere 環境のライフサイクル管理の目的で、vSphere Update Manager（VUM）と呼ばれるツールが存在していました。vSphere 7.0 からは、これが vSphere Lifecycle Manager（vLCM）に置き換わっています。
VUM も vLCM も、vSphere 環境のバージョンやパッチの適用状態に任意の基準を決めて、実環境のその基準からの逸脱を確認し、基準に準拠させる修正作業も実行できる、というざっくりした説明の限りでは大きな違いはありませんが、その基準の考え方に、従来どおりの『ベースライン』に加えて、『イメージ』という概念が新しく登場しています。この『イメージ』こそが vLCM の大きな特徴なようです。
考え方
これまでの『ベースライン』による管理では、例えば、ある特定のパッチの適用状態を管理できた一方で、そのパッチ以外のパッケージ構成やバージョンについては、何ら関知しませんでした。つまり、同じベースラインを複数のホストに添付して管理したとしても、その全ホストのパッケージ構成が完全に一致していることは保証できませんでした。
これに対し、vLCM で新しく登場した『イメージ』では、
- ベースイメージ
- VMware がバージョンごとにリリースする ESXi そのもので、ブート可能で完全な状態を構成するコンポーネントの集まり
- ベンダアドオン（任意）
- OEM ベンダが提供する追加のドライバやパッチ、追加機能など
- ファームウェアやドライバアドオン（任意）
- ハードウェアベンダが提供するファームウェアやドライバなど
- コンポーネント（任意）
- サードパーティ製の追加ドライバや追加機能など
をまとめて管理するようです。つまり、ESXi を構成する全コンポーネントのあるべき状態（Desired State）を（任意でファームウェアまで含めて）宣言的に『イメージ』として定義できます。イマドキな考え方ですね。詳しくはドキュメントに書いてあります。
vLCM では、従来通りの『ベースライン』による管理と『イメージ』による管理のいずれも利用できますが、
- 『イメージ』による管理は、ホストクラスタに対してのみ有効化できる
- クラスタの全台が ESXi 7.0 以降である必要がある
- クラスタの全台がステートフル（Auto Deploy でなくディスクからブートする）である必要がある
- クラスタの全体が同一ベンダのハードウェアである必要がある
- 『ベースライン』管理から『イメージ』管理には切り替えられるが、いちど『イメージ』管理にすると『ベースライン』管理には戻せない
- 7.0 の時点では、NSX や vSphere with Kubernetes を含むクラスタは『イメージ』での管理は行えない
- 『イメージ』を利用したホストの修正を行うと、それらのエージェントが削除される
- ファームウェアの管理まで行う場合、ハードウェアベンダから提供される Hardware Support Manager プラグインの導入が必要
- 現時点では Dell か HPE のみの模様
- Dell であれば OpenManage Integration for VMware vCenter （OMIVV）、HPE であれば iLO Amplifier が必要で、それぞれ仮想アプライアンスとして構築する
などなど、種々の注意事項や制約があるようです。ドキュメントをしっかり読まないとハマりそうですね。
なお、従来はパッチやドライバの最小単位は VIB でしたが、7.0 からはコンポーネントなる概念に代わっています。コンポーネントには、一つ以上の VIB を論理的にグループにしたものです。この辺もドキュメントに書いてあるので、作業中の用語に混乱しそうな場合は確認しておくとよさそうです。
今回の作業
今回は、最終的に『ESXi 7.0 を vLCM でイメージ管理できる』状態を目標に、以下を行っていきます。
- ベースラインを利用して、ESXi 6.7 を 7.0 にアップグレードする
- イメージでの管理に切り替える
- その過程で、最新のパッチをベースにしたイメージを作成する
- イメージを利用して最新のパッチを適用する
ESXi 6.7 の 7.0 へのアップグレード
まずは ESXi を 6.7 から 7.0 にアップグレードします。イメージによる管理は ESXi 7.0 以降でないと行えないため、アップグレードはベースラインを利用して行うことになります。
vLCM のメニュは、vSphere Client に完全に統合されています。というか、もともと VUM だった項目が vLCM になっています。
まずは、アップグレード用のベースラインを作る準備として、[インポートされた ISO] タブから、元になる ISO ファイルをインポートします。
インポートできました。
続いて、ベースラインを作成します。[ベースライン] タブで [新規] > [ベースライン] から、インポートした ISO ファイルを利用したアップグレードベースラインを作ります。
できました。
作成したベースラインをクラスタ（かホスト）に添付します。
デフォルトでは、事前定義された二つのベースライン（重要なホストパッチ、ホストセキュリティパッチ）が最上位の vCenter Server オブジェクトに添付されていて、クラスタやホストにもこれが継承されていますが、今回は事前に分離してから作業しています。
添付すると、アップグレード前なので、非準拠と判定されます。
ここから、ベースラインに合わせる修正作業をしていきます。今回はクラスタに対してまとめて修正を実行しましたが、一台ずつ実施したい場合はホスト単位でももちろん構いません。
修正のための設定をして、続行します。
今回は [今すぐ] にしたので、直ちに適用が始まりました。クラスタ内のホストで 1 台ずつ、
- 対象ホスト上の稼働中の仮想マシンの移行
- 対象ホストのメンテナンスモードへの切り替え
- アップグレード
- 対象ホストのメンテナンスモードの終了
が行われていきます。サポートされていないハードウェア（NUC8i5BEK）を使っていますが、特に問題なくすんなりとアップグレードされて起動してきました。
仮想マシンが共有ストレージ上にない場合は、Storage vMotion まではしてくれないので、そのホストのアップグレードはスキップされます。その場合、手動で仮想マシンを逃がすなど対処してから再度修正処理を実行します。
最終的に、クラスタ内の全台がベースラインに準拠した状態になったら、アップグレードは完了です。
なお、アップグレードが完了した段階で、ESXi のライセンスが評価モードに切り替わっています。必要に応じて、新しく vSphere 7.0 のライセンスキーを追加し、ホストに適用してください。
ベースラインからイメージへの切り替え
クラスタのホスト全台が ESXi 7.0 以上になったので、ベースライン管理からイメージ管理に切り替えます。
事前準備として、ベースイメージを取り込みます。オフラインバンドルの ZIP を取り込んでもよいですが、今回はインタネットから取得するため、vLCM の設定画面から、以下の URL の利用を有効化します。
https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
有効化後、[アクション] > [更新の同期] を実行して、[デポのイメージ] タブにベースイメージのリストが表示されていることを確認します。執筆時点では 7.0.0b と 7.0.0bs がありますが、違いは VMware のブログ でも説明されています。下部では、ベンダアドオンなども確認できますね。
デポにイメージが表示されたら、クラスタをベースラインからイメージに切り替えていきます。
クラスタの [アップデート] > [イメージ] で、[イメージのセットアップ] からウィザードを開始します。
今回は、アップグレードの残骸（古い fdm の VIB、おそらく今は無効にしている HA をかつて有効にしていた影響）がスタンドアロン VIB として検出されてしまいました。もし今後もこの VIB を導入したままにしたい場合は、この VIB を含むコンポーネントをイメージに含める必要がありますが、今回はただの残骸で不要なので無視します。
ここで ESXi のベースイメージと、任意でベンダアドオンやファームウェアなども選択します。Dell や HPE など、きちんとサポートされるハードウェアを使っている場合は、このあたりから必要な追加コンポーネントを指定することになります。
サポートされているハードウェアを使っていて、かつ、Harware Support Manager が事前に構成されている場合は、あらかじめハードウェアとファームウェアの組み合わせなどを定義しておくことで、ここでファームウェアなどの構成もイメージに含められるようです。
今回はもちろんないので、ミニマムで ESXi のバージョン（執筆時点で最新の 7.0.0b）だけを指定して保存します。
イメージを保存すると、コンプライアンスの確認が走ります。今回は、次の 2 点が検出されていますが、どちらも想定内です。
- ホストのバージョンがイメージと異なる
- スタンドアロンの VIB（前述した残骸）がインストールされている
どちらも、このあとの適用作業で修正されます。後者はつまり削除されるわけですが、このように、イメージに含まれない余計なモノが入っていると削除される点は、かつてのベースラインでの管理とは異なる、イメージでの管理の特徴的なところの一つだと思います。
続行すると、イメージ管理への切り替えは完了です。
イメージに準拠するようホストを修正する
クラスタの [アップデート] > [イメージ] の画面で、イメージのコンプライアンスの確認や、事前チェック、修正時の動作に関する設定、実際の修正などが行えます。
修正の実行前には、事前チェックをしておくとよさそうです。修正の失敗の原因になる諸々をチェックして教えてくれます。例えば今回の環境だと、DRS が無効で、かつ vCSA が動作しているホストで問題が検出されました。一台ずつ対応すればよいだけなので、気にしないことにします。
クラスタの全台を修正する場合は [すべて修正] を、ホスト単位で修正する場合はホスト名の左の […] から [修正] を実行します。
確認画面が出て、続行すると修正が開始されます。ホストで何が行われるのか見せてくれるのは、わかりやすくてよいですね。
進捗は元の画面で逐次表示されていきます。これもわかりやすくてよいですね。
途中、停止状態の vCenter Server 6.7（前回のエントリ で作業した残骸で不要なヤツ）が乗っているホストで、vCenter Server が稼働中かつ DRS が無効だから適用できない旨の怒られが発生しました。停止状態でも vCenter Server が居ると（移行できなければ）ダメなようで、不思議な仕様だなあと思いつつ一時的にインベントリから削除して回避しています。
そんなこんなで順次修正が完了し、イメージを遵守できた状態になりました。めでたしめでたし。
まとめ
vSphere 7.0 からの新機能である vLCM を使って、ESXi のアップグレードと、イメージ管理によるパッチ適用を行いました。
NSX や vSphere with Kubernetes を構成するホストでは利用できないなど、制約はまだあるものの、イメージによる管理は VUM よりも素直でわかりやすい印象を受けました。
今回は試しませんでしたが、API を使って JSON ベースでの管理もできるようで、構成管理の負荷を下げる余地はまだまだありそうです。今後の機能追加やサポート範囲の拡大にも期待できそうですね。
