環境から4.4へのアップグレード

始める前に

環境をアップグレードする前に、次の点を考慮してください:

必要な仮想マシンのダウンタイムを計画します。クラスタ互換バージョンを更新すると、再起動後に新しいハードウェア構成が各仮想マシンに自動的に適用されます。構成の変更を適用するには、実行中の仮想マシンまたは中断された仮想マシンをできるだけ早くリブートする必要があります。
環境が4.4の要件を満たしていることを確認します。「Oracle Linux Virtualization Manager: リリース・ノート」の要件とスケーラビリティの制限を参照してください。
エンジンをアップグレードするときは、Oracleでは既存のホストのいずれかを使用することをお勧めします。新しいホストを使用する場合は、アップグレードする前に、新しいホストに一意の名前を割り当ててから既存のクラスタに追加する必要があります。

エンジンまたは自己ホスト・エンジンの4.3への更新

4.4にアップグレードする前に、エンジンまたは自己ホスト・エンジンを最新バージョンの4.3に更新する必要があります。

「(自己ホスト型エンジンのみ)」仮想マシンを移行し、グローバル・メンテナンス・モードを有効にします。
- 自己ホスト・エンジンの仮想マシンを含むホストから、その他すべての仮想マシンを移行します。仮想マシンを同じクラスタ内の別のホストに移動します。アップグレード中、ホストには自己ホスト・エンジンの仮想マシンのみを含めることができます(ほかの仮想マシンはホスト上に存在できません)。ライブ移行を使用して、仮想マシンのダウンタイムを最小限に抑えます。「ホスト間での仮想マシンの移行」を参照してください。
- グローバル・メンテナンス・モードの有効化:
  1. 自己ホスト・エンジン・ホストにログインし、グローバル・メンテナンス・モードを有効にします:
```
# hosted-engine --set-maintenance --mode=global
```
  2. 続行する前に、環境がグローバル・メンテナンス・モードであることを確認します:
```
# hosted-engine --vm-status
```
  3. 次のメッセージが表示されます。
```
!! Cluster is in GLOBAL MAINTENANCE mode !!
```
oracle-ovirt-release-el7.rpmをインストールして最新バージョンに更新します。このパッケージには、必要なリポジトリが含まれます。
エンジン・マシンで、更新されたパッケージを確認します:
```
# engine-upgrade-check
```
設定パッケージを更新します:
```
# dnf update ovirt\*setup\*
```
エンジンを更新します:
```
# engine-setup
```
重要:

更新プロセスには時間がかかる場合があります。プロセスが完了する前に停止しないでください。

engine-setupスクリプト:
- 構成に関する質問のプロンプト
- ovirt-engineサービスを停止
- 更新されたパッケージをダウンロードしてインストール
- データベースのバックアップと更新
- インストール後の構成を実行
- ovirt-engineサービスを起動
スクリプトが正常に完了すると、次が表示されます:
```
Execution of setup completed successfully
```
ノート:

engine-setupスクリプトは、初期エンジン・インストール・プロセス中に指定された構成値を表示します。初期インストール後にengine-configを使用した場合、これらの値は最新ではない可能性があります。ただし、engine-setupでは、更新された値は上書きされません。

たとえば、インストール後にSANWipeAfterDeleteをtrueに更新するためにengine-configを使用した場合、engine-setupには「削除後にデフォルトのSAN消去」と表示されます: 構成プレビューでのFalse。ただし、この値は適用されません。 SANWipeAfterDeleteをtrue設定のままにします。
基本オペレーティング・システムおよびエンジンにインストールされているオプション・パッケージを更新します:
```
# dnf update
```
カーネル・パッケージが更新された場合は、マシンをリブートして更新を完了します。
エンジンまたは自己ホスト・エンジンを4.4にアップグレードできるようになりました。

エンジンまたは自己ホスト・エンジンのアップグレード

4.4エンジンは、Oracle Linux 8.5以降でのみサポートされています。 4.3エンジンの実行に使用したものと同じ物理マシンを使用している場合でも、Oracle Linux 8.5以降と4.4エンジンのクリーン・インストールが必要です。

アップグレード・プロセスでは、4.3エンジンのバックアップ・ファイルを4.4エンジン・マシンにリストアする必要があります。

ノート:

接続されたホストと仮想マシンは、エンジンのアップグレード中に引き続き機能します。

前提条件

注意:

アップグレード・プロセスを開始する前に、4.3の最新バージョンに「エンジンまたは自己ホスト・エンジンを更新しました」があることを確認してください。

標準環境と自己ホスト・エンジン環境の両方に共通するアップグレードの前提条件があります。自己ホスト・エンジン環境には、追加の前提条件があります。

すべての環境用:

エンジンは、最新バージョンの4.3に更新する必要があります。
環境内のすべてのデータ・センターおよびクラスタは、クラスタ互換性レベルをバージョン4.2または4.3に設定する必要があります。
環境内のすべての仮想マシンでは、クラスタ互換性レベルをバージョン4.3に設定する必要があります。
外部CAを使用してHTTPS証明書に署名する場合は、「Oracle Linux Virtualization Manager Apache SSL証明書の置換」のステップに従います。バックアップおよびリストアには3rd-party証明書が含まれているため、アップグレード後に管理ポータルにログインできます。 virt-viewerの外部メニューが機能するように、すべてのクライアントのシステム全体のトラスト・ストアにCA証明書が追加されていることを確認します。

さらに、自己ホスト・エンジン環境の場合:

DHCPを使用し、同じIPアドレスを使用する場合は、自己ホスト・エンジンのMACアドレスをノートにとります。デプロイ・スクリプトによって、この情報の入力を求められます。
デプロイメント中、エンジン・マシンに新しい記憶域ドメインを指定する必要があります。デプロイメント・スクリプトは、4.3記憶域ドメインの名前を変更し、そのデータを保持してディザスタ・リカバリを有効にします。
アップグレード中に仮想マシンの自動移行を回避するには、クラスタのスケジューリング・ポリシーをcluster_maintenanceに設定します。

注意:

複数の高可用性自己ホスト・エンジン・ノードがある環境では、エンジンを4.4にアップグレードした後、バージョン4.3エンジンをホストする記憶域ドメインをデタッチする必要があります。 4.4自己ホスト・エンジンのデプロイメントに専用の記憶域ドメインを使用します。

エンジンのアップグレード

重要:

自己ホスト型のエンジン環境がある場合は、「自己ホスト・エンジンのアップグレード」を参照してください。

「前提条件」を確認します。
エンジン・マシンにログインします。

4.3エンジン環境をバックアップします。

# engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log

Oracle Linux Virtualization Manager環境外の記憶域デバイスにバックアップ・ファイルをコピーします。
「Oracle Linux Virtualization Manager: スタート・ガイド」のエンジンのインストールを参照してください。

Oracle Linux 8.5以上をインストールし、コマンドdnf install ovirt-engineの実行など、4.4エンジンをインストールするステップを完了しますが、engine-setupは実行しません。
バックアップ・ファイルを4.4エンジン・マシンにコピーし、リストアします。
```
# engine-backup --mode=restore --file=backup.bck --provision-all-databases
```
バックアップに余分なデータベース・ユーザーに対する権限が含まれている場合、このコマンドでは、ランダム・パスワードを使用して余分なユーザーが作成されます。追加のユーザーがリストアされたシステムへのアクセスを必要とする場合は、これらのパスワードを手動で変更する必要があります。
4.3エンジン・マシンにインストールされている場合は、オプションの拡張パッケージをインストールします。
```
# dnf install ovirt-engine-extension-aaa-ldap ovirt-engine-extension-aaa-misc
```
バックアップおよびリストア・プロセスは、構成設定を移行しません。これらのパッケージ拡張の構成を手動で再適用する必要があります。
engine-setupコマンドを実行してエンジンを構成します:
```
# engine-setup
```
4.4エンジンに別のマシンが使用されている場合は、4.3エンジン・マシンを廃止します。 2つの異なるエンジンが同じホストまたは記憶域を管理してはいけません。
これで、KVMホストを更新できます。「ホストおよび仮想マシンの移行」に進みます。

自己ホスト・エンジンのアップグレード

重要:

自己ホスト・エンジン環境がない場合は、「エンジンのアップグレード」を参照してください。

「前提条件」を確認します。
エンジン・マシンにログインし、エンジン・サービスをシャットダウンします。
```
# systemctl stop ovirt-engine
```

4.3エンジン環境をバックアップします。

# engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log

Oracle Linux Virtualization Manager環境外の記憶域デバイスにバックアップ・ファイルをコピーします。
自己ホスト・エンジンを停止します。
```
# shutdown
```
自己ホスト・エンジン仮想マシンを再利用して4.4エンジンをデプロイする場合は、自己ホスト・エンジン・ネットワーク・インタフェースのMACアドレスをノートしてから停止します。
自己ホスト・エンジンが停止していることを確認します。
```
# hosted-engine --vm-status | grep 'Engine status|Hostname'
```
いずれかのホストがdetailフィールドをUpとしてレポートする場合、その特定のホストにログインし、hosted-engine --vm-shutdownコマンドを使用して停止します。
Oracle Linux 8.5以上を、現在エンジン仮想マシンを実行している既存のホストにインストールし、自己ホスト・エンジン・デプロイメント・ホストとして使用します。詳細は、「Oracle Linux Virtualization Manager: スタート・ガイド」の自己ホスト・エンジンのデプロイを参照してください。

ノート:

Oracleでは、既存のホストのいずれかを使用することをお勧めします。新しいホストを使用する場合は、アップグレード手順を開始する前に、新しいホストに一意の名前を割り当て、既存のクラスタに追加する必要があります。
自己ホスト・エンジンのデプロイメント・ツールをインストールします。
```
# dnf install ovirt-hosted-engine-setup
```
バックアップ・ファイルをホストにコピーします。
Engineホストにログインし、バックアップ・ファイルを使用して自己ホスト・エンジンをデプロイします:
```
# hosted-engine --deploy --restore-from-file=/path/backup.bck
```
tmuxを使用すると、サーバーへのアタッチが中断された場合にデプロイメント・スクリプトを続行できるため、再アタッチしてデプロイメントにアタッチし、続行できます。それ以外の場合、デプロイメント中に接続が中断されると、デプロイメントは失敗します。

tmuxを使用してデプロイメント・スクリプトを実行するには、デプロイメント・スクリプトを実行する前にtmuxコマンドを入力します:
```
# tmux
# hosted-engine --deploy --restore-from-file=backup.bck
```
デプロイメント・スクリプトは、グローバル・メンテナンス・モードを自動的に無効にし、HAエージェントをコールして自己ホスト・エンジンの仮想マシンを起動します。 4.4自己ホスト・エンジンのアップグレードされたホストは、HAモードがアクティブであることを報告しますが、ほかのホストは、以前の自己ホスト・エンジンの記憶域に接続されたまま、グローバル・メンテナンス・モードが有効であることを報告します。
4.3エンジン・マシンをホストする記憶域ドメインをデタッチします。詳細については、「データ・センターからの記憶域ドメインのデタッチ」を参照してください。
エンジン仮想マシンにログインし、エンジン・サービスをシャットダウンします。
```
# systemctl stop ovirt-engine
```
4.3エンジン・マシンにインストールされている場合は、オプションの拡張パッケージをインストールします。
```
# dnf install ovirt-engine-extension-aaa-ldap ovirt-engine-extension-aaa-misc
```
ノート:

これらのパッケージ拡張の構成は、バックアップおよびリストア・プロセスの一部として移行されないため、手動で再適用する必要があります。
engine-setupコマンドを実行してエンジンを構成します:
```
# engine-setup
```
4.4エンジンがインストールされ、クラスタの互換性バージョンが4.2または4.3(既存のクラスタ互換バージョンのいずれか)に設定されます。
これで、自己ホスト・エンジン・ホスト、次に標準ホストを更新できます。「ホストおよび仮想マシンの移行」に進みます。

ホストおよび仮想マシンの移行

環境内の仮想マシンの停止時間を最小限に抑えるために、ホストおよび仮想マシンを4.3から4.4に移行します。このプロセスでは、そのホストを4.4にアップグレードできるように、1つのホストからすべての仮想マシンを移行する必要があります。アップグレード後、ホストをエンジンに再接続できます。

注意:

ホストのオペレーティング・システムをインストールまたは再インストールする場合、Oracleでは、これらのディスクの誤った初期化による潜在的なデータ損失を回避するために、まずホストから既存の非OS記憶域を切り離すことを強くお勧めします。

Oracle Linux Virtualization Manager 4.3および4.4は、それぞれ異なるCPUフラグおよびマイクロコードを持つ異なるカーネル・バージョンを持つOracle Linux 7およびOracle Linux 8に基づいています。これにより、CPUパススルー仮想マシンの移行で問題が発生し、それらが正しく移行されない可能性があります。

手順

4.4エンジンがインストールされ、実行中であることを確認します。
環境内のすべてのデータ・センターおよびクラスタの互換性レベルが4.2または4.3であることを確認します。
ホストを選択して、そのホストの仮想マシンをアップグレードし、同じクラスタ内の別のホストに移行します。

ライブ移行を使用すると、仮想マシンのダウンタイムを最小限に抑えることができます。「ホスト間での仮想マシンの移行」を参照してください。
ホストをメンテナンス・モードにし、ホストをエンジンから削除します。

「ホストのメンテナンス・モードへの移動」および「ホストの削除」を参照してください。
Oracle Linux 8.5以降をインストールし、適切なパッケージをインストールして、4.4のホストを有効にします。 4.3と同じ物理マシンを使用している場合でも、4.4ホストにはOracle Linux 8.5以降のクリーン・インストールが必要です。

注意:

「インストールする前に」は、前提条件を確認し、「Oracle Linux Virtualization Manager: スタート・ガイド」の「KVMホストの構成」の手順に従います。インストールの基本環境として「最小インストール」を選択していることを確認します。そうしないと、ホストに不正なqemuおよびlibvirtバージョンがあり、正しくないリポジトリが構成され、仮想マシン・コンソールにアクセスできなくなります。
このホストをエンジンに追加し、同じクラスタに割り当てます。これで、仮想マシンをこのホストに移行できます。

「Oracle Linux Virtualization Manager: スタート・ガイド」のKVMホストの追加を参照してください。
これらのステップを繰り返して、同じクラスタ内の残りのホストの仮想マシンおよびアップグレード・ホストを、すべて4.4を実行するまで1つずつ移行します。
互換性バージョンを4.6に更新

「アップグレード後のデータ・センターとクラスタの互換バージョンの変更」を参照してください。

アップグレード後のデータ・センターとクラスタの互換バージョンの変更

Oracle Linux Virtualization Managerのデータ・センターおよびクラスタには互換バージョンがあります。データ・センターの互換バージョンは、データ・センターと互換性があるOracle Linux Virtualization Managerのバージョンを示しています。クラスタの互換バージョンは、クラスタ内のすべてのホストでサポートされる機能を示しています。クラスタの互換性は、クラスタ内の最小機能のホスト・オペレーティング・システムのバージョンに従って設定されています。

重要:

Oracle Linux Virtualization Managerバージョンは4.4ですが、対応する互換性バージョンは4.6です。

互換バージョンの制限

アップグレード後に互換バージョンに関する問題が発生しないように、これらの制限を考慮してください。

データ・センターの互換バージョン

データ・センターの互換性レベルとは、データ・センター内のすべてのクラスタに使用できる最小バージョンのことです。たとえば:

データ・センターの互換性レベルが4.6の場合、互換性レベルが4.6のクラスタのみを使用できます。
データ・センターの互換性レベルが4.3の場合、4.3および4.6の互換性レベル・クラスタを使用できます。

クラスタの互換性バージョン

クラスタの互換性レベルとは、クラスタに追加するホストの最小バージョンのことです。たとえば:

4.3互換バージョン・クラスタがある場合は、4.3または4.4ホストを追加できます。
4.6互換バージョン・クラスタがある場合は、4.4ホストのみを追加できます。

互換性バージョンの変更時に発生する可能性のあるエラー

4.3互換バージョン・クラスタがある場合、データ・センターの互換性バージョンを4.3から4.6に変更しようとすると、次のエラーが発生します:
```
Cannot update Data Center compatibility version to a value that is greater than its 
cluster's version. The following clusters should be upgraded: [clustername]
```

4.3ホストが実行されているときに、クラスタの互換性バージョンを4.3から4.6に変更しようとすると、次のエラーが発生します:

Error while executing action: Cannot change Cluster Compatibility Version to higher version 
when there are active Hosts with lower version. -Please move Host [hostname] with lower 
version to maintenance first.

4.3ホストをメンテナンス・モードにすると、クラスタを変更してからデータ・センターの互換性バージョンを4.6に変更できます。ただし、次のイベントによる動作不能がホストに表示されます。
```
Host [hostname] is compatible with versions ([version levels]) and cannot join Cluster 
[clustername] which is set to version [version level].
```

ホストの追加時に発生する可能性のある問題

新しい4.3ホストを4.4エンジンに追加しようとすると、次のような不可解なログにエラー・メッセージが表示されることがあります:
```
ValueError: need more than 1 value to unpack.
```
このエラーを解決するには、ホストにrootでログオンし、次の2つのコマンドを実行した後、ホストをエンジンに再度追加してみてください。
```
# sed 's|enabled=1|enabled=0|g' /etc/yum/pluginconf.d/enabled_repos_upload.conf -i 
# sed 's|enabled=1|enabled=0|g' /etc/yum/pluginconf.d/package_upload.conf -i
```

ノート:

エンジンを4.4にアップグレードした後に優先されるアプローチは、すべてのホストを4.4にアップグレードしてから、クラスタの互換性を4.6に変更することです。その後、4.4のホストとして、新しいホストを追加できます。

クラスタの互換バージョンの変更

クラスタの互換バージョンを変更するには、まずクラスタ内のすべてのホストを、必要な互換レベルをサポートするレベルにアップグレードしておく必要があります。

すべてのホストで、目的の互換性レベルをサポートするバージョン・レベルが実行されていることを確認します。「互換バージョンの制限」を参照してください。
管理ポータルで、「計算」に移動して「クラスタ」をクリックします。
変更するクラスタを選択し、「編集」をクリックします。
「クラスタの編集」ダイアログ・ボックスで、「一般」を選択します。
「互換バージョン」で、目的の値を選択して「OK」をクリックします。
クラスタ互換バージョンの変更確認ウィンドウで、「OK」をクリックします。

重要:

一部の仮想マシンおよびテンプレートが間違って構成されていることを警告するエラー・メッセージが表示される場合があります。このエラーを修正するには、各仮想マシンを手動で編集します。「仮想マシンの編集」ウィンドウには、追加の検証結果および修正が必要な内容を示す警告が表示されます。問題が自動的に修正された場合は、仮想マシン構成の再保存のみが必要です。各仮想マシンの編集後、クラスタの互換バージョンを変更できます。
実行中または一時停止中のすべての仮想マシンのクラスタの互換バージョンを、管理ポータルから仮想マシンを再起動して更新します。

ノート:

仮想マシンは、再起動するまで、引き続き以前のクラスタの互換レベルで実行されます。 Next-Runアイコン(感嘆符付きの三角形)は、再起動が必要な仮想マシンを示します。ただし、自己ホスト・エンジンの仮想マシンを再起動する必要はありません。

プレビューされている仮想マシン・スナップショットのクラスタ互換性バージョンは変更できません。最初にプレビューをコミットまたは元に戻す必要があります。

データ・センターの互換バージョンの変更

データ・センター内のすべてのクラスタの互換性バージョンを更新した後、データ・センター自体の互換性バージョンを変更できます。

すべてのクラスタが適切な互換性バージョンであることを確認します。そうでない場合は、クラスタのバージョンを変更します。「クラスタの互換バージョンの変更」を参照してください。
管理ポータルで、「計算」に移動して「データ・センター」をクリックします。
変更するデータ・センターを選択し、「編集」をクリックします。
データ・センターの編集ダイアログ・ボックスで、「互換バージョン」を必要な値に変更し、「OK」をクリックします。
データ・センターの互換バージョンの変更確認ウィンドウで、「OK」をクリックします。