ホストの修正方法は、添付するベースラインのタイプおよびホストがクラスタ内にあるかどうかによって異なります。

クラスタ内のホストの修正

クラスタ内の複数の ESXi ホストは、デフォルトで順次修正されます。Update Manager では、ホストの修正を並行して実行することもできます。

ホストのクラスタを順次修正する場合、ホストの 1 台がメンテナンス モードに入れないと、Update Manager はエラーを報告し、プロセスが停止して失敗します。クラスタ内で修正されたホストは、修正後のアップデート レベルが維持されます。ホストの修正に失敗した後、修正されなかったホストはアップデートが適用されません。DRS 対応クラスタ内のホストで Update Manager または vCenter Server がインストールされた仮想マシンが実行されている場合、DRS は修正を正常に行うため、最初に vCenter Server または Update Manager を実行している仮想マシンを別のホストに移行します。仮想マシンを別のホストに移行できない場合、そのホストの修正は失敗しますが、プロセスは停止しません。Update Manager は、クラスタにある次のホストの修正に進みます。

クラスタ内の ESXi ホストのアップグレード修正は、クラスタ内のすべてのホストがアップグレード可能な場合にのみ続行されます。

クラスタ内のホストを修正する場合は、VMware DPM、HA アドミッション コントロールなどのクラスタ機能を一時的に無効にする必要があります。さらに、ホストのいずれかの仮想マシンで Fault Tolerance が有効な場合は、それをオフにし、ホストの仮想マシンに接続されているリムーバブル デバイスを切断して、vMotion で移行できるようにします。修正プロセスを開始する前に、クラスタ機能が有効になっているクラスタ、ホスト、または仮想マシンを示すレポートを生成できます。詳細については、修正の事前チェック レポートを参照してください。

注: 2 台以下のホストで構成されたクラスタで修正を実行する場合、修正を確実に成功させるには、HA のアドミッション コントロールを無効にするだけでは不十分な可能性があります。クラスタで vSphere Availability (HA) を無効にしなければならない可能性があります。HA を有効なまま維持した場合は、HA がいずれかのホストをメンテナンス モードにするための推奨情報を Update Manager に提供できないため、クラスタ内のホストを修復しようとしても失敗します。これは、2 台のホストのいずれかがメンテナンス モードになった場合、クラスタで使用可能なフェイルオーバー ホストがなくなることが原因です。2 ノードのクラスタで修正を確実に成功させるには、クラスタで HA を無効にするか、またはホストを手動でメンテナンス モードにしてから、クラスタ内の 2 台のホストに修正を実行します。

ホストのクラスタを並行して修正する場合、Update Manager は同時に複数のホストを修正します。並行修正中にホストの修正エラーが発生すると、Update Manager はそのホストを無視し、クラスタ内の他のホストに対して修正を続行します。Update Manager は、DRS 設定に影響を与えずに同時に修正できるホストの最大数を継続的に評価します。同時に修正されるホスト数は、特定の数に指定できます。

vSAN クラスタの一部であるホストの場合、並行して修正するオプションを選択しても、Update Manager はホストを順次修正します。これは、vSAN クラスタの設計上、同時に 1 台のホストしかメンテナンス モードにできないためです。

1 つのデータセンターに複数のクラスタがある場合、修正プロセスは並行して実行されます。データセンターのいずれかのクラスタで修正プロセスが失敗しても、残りのクラスタは引き続き修正されます。

複数のベースラインまたはベースライン グループに対する修正

vCenter Server 6.7 Update 2 以降では、複数のベースラインを最初にベースライン グループにグループ分けするのではなく、選択します。アップグレード ベースラインおよびパッチまたは拡張機能のベースラインを含む複数のベースラインまたはベースライン グループに対してホストを修正する場合は、まずアップグレードが実行されます。

ホストのアップグレードの修正

ESXi 6.0 ホストと ESXi6.5 ホストを ESXi6.7 にアップグレードする場合、インストーラ ISO に VIB が含まれているかどうかにかかわらず、サポートされているすべてのカスタム VIB は、アップグレード後にホスト上でそのまま維持されます。これは、ESXi 6.x ホストがバイナリ互換であるためです。

ESXi 6.7 のサードパーティ製モジュールを含むカスタム ESXi イメージを使用して、ホストをアップグレードできます。この場合、ESXi6.7 と互換性があるサードパーティ製モジュールは、アップグレード後のホストでも利用できます。

Update Manager とホストが異なる場所に存在し、遅延が大きいネットワークでホストをアップグレードする場合は、アップグレード前にアップグレード ファイルが Update Manager サーバのリポジトリからホストにコピーされるため、数時間かかることがあります。その間、ホストはメンテナンス モードのままになります。

Update Manager 6.7 は、ESXi 6.0.x および ESXi6.5.x から ESXi6.7 へのアップグレードをサポートします。

重要: ホストを ESXi 6.7 にアップグレードすると、バージョン ESXi 6.0.x または ESXi 6.5.x のソフトウェアにロールバックできません。ホストのアップグレードを実行する前に、ホストの構成をバックアップしてください。アップグレードに失敗した場合は、アップグレード元の ESXi 6.0.x または ESXi 6.5.x ソフトウェアを再インストールし、ホスト構成をリストアできます。 ESXi 構成のバックアップとリストアの詳細については、『 vSphere のアップグレード』 を参照してください。

ホストのパッチの修正

Update Manager は、次の方法でホスト パッチを処理します。

  • パッチ ベースラインに、別のパッチの適用が必要となるパッチが含まれている場合、Update Manager はパッチ リポジトリ内の前提条件を検出し、選択したパッチとともに別のパッチを適用します。
  • パッチがホストにインストールされている他のパッチと競合する場合、競合するパッチはステージングまたはインストールされないことがあります。ただし、ベースラインの別のパッチによって競合が解決される場合、競合するパッチは適用されます。たとえば、パッチ A とパッチ C を含むベースラインがあり、パッチ A がすでにホストに適用されているパッチ B と競合するとします。パッチ C がパッチ B に置き代わり、パッチ A と競合しなくなると、修正プロセスによってパッチ A とパッチ C が適用されます。
  • Update Manager のパッチ リポジトリのパッチと競合するパッチがホストと競合しない場合、Update Manager はスキャン後にこのパッチを競合パッチとしてレポートします。このパッチは、ステージングしてホストに適用できます。
  • 同じパッチの複数のバージョンを選択すると、Update Manager は最新バージョンのパッチを適用し、それ以前のバージョンをスキップします。

パッチ修正中に、Update Manager はパッチの前提条件を自動的にインストールします。

Update Manager 6.7 では、手動でインポートしたオフライン バンドルに対して、ESXi 6.0ESXi6.5 のバージョンのホストを修正できます。

修正の前にパッチをステージングすることで、ホストのダウンタイムを短縮できます。

ホストの拡張機能の修正

Update Manager は、拡張機能の修正中にその前提条件を自動的にインストールしません。このため、一部の修正操作が失敗することがあります。不足している前提条件がパッチの場合は、不足しているパッチをパッチ ベースラインに追加できます。不足している前提条件が拡張機能の場合は不足している拡張機能を、同じ拡張機能ベースラインまたは別のベースラインに追加できます。その後に、前提条件と元の拡張機能を含む 1 つまたは複数のベースラインに対してホストを修正できます。

PXE ブートの ESXi ホストの修正

Update Manager では、PXE ブートの ESXi ホストを修正できます。Update Manager は、PXE ブートの ESXi ホストの再起動が必要なパッチは適用しません。

PXE ブートの ESXi ホストに追加のソフトウェアがインストールされている場合、ホストを再起動するとソフトウェアが失われることがあります。再起動後に追加のソフトウェアを維持するには、追加のソフトウェアを含めてイメージ プロファイルを更新します。