アップグレードガイド
Red Hat Virtualization の更新およびアップグレード作業
概要
Red Hat Virtualization のアップグレードの概要 リンクのコピーリンクがクリップボードにコピーされました!
本書では、以下の環境を Red Hat Virtualization 4.3 または 4.4 にアップグレードする方法について説明します。
- セルフホストエンジン、ローカルデータベース: Data Warehouse データベースおよび Manager データベースの両方が Manager にインストールされている。
- スタンドアロンマネージャー、ローカルデータベース: Data Warehouse データベースおよび Manager データベースの両方が Manager にインストールされている。
- スタンドアロンマネージャー、リモートデータベース: Data Warehouse データベースまたは Manager データベース、またはその両方が別のマシン上にある。
アップグレード手順のチェックリストについては、RHV Upgrade Helper を使用することができます。このアプリケーションは、アップグレードパスと現在の環境のチェックリストを入力し、該当するアップグレード手順を表示するよう要求します。
必要なダウンタイムを事前に計画します。アップグレードプロセスでクラスターの互換バージョンを更新した後、それぞれの仮想マシンを再起動すると新しいハードウェア設定が自動的に適用されます。すべての実行中またはサスペンド中の仮想マシンを直ちに再起動して、設定変更を適用する必要があります。
以下の表から、お使いの環境に適した手順を選択します。Manager のバージョンとホストのバージョンが異なる場合 (以前に Manager をアップグレードしていてもホストではない場合)、Manager のバージョンに一致する手順に従います。
| 現在の Manager バージョン | ターゲット Manager のバージョン | 関連セクション |
|---|---|---|
| 4.3 | 4.4 | セルフホストエンジン、ローカルデータベース環境: Red Hat Virtualization 4.3 から 4.4 へのセルフホストエンジンのアップグレード ローカルデータベース環境: Red Hat Virtualization 4.3 から 4.4 へのアップグレード リモートデータベース環境: Red Hat Virtualization 4.3 から 4.4 へのリモートデータベース環境のアップグレード |
| 4.2 | 4.3 | セルフホストエンジン、ローカルデータベース環境: Red Hat Virtualization 4.2 から 4.3 へのセルフホストエンジンのアップグレード ローカルデータベース環境: Red Hat Virtualization 4.2 から 4.3 へのアップグレード リモートデータベース環境: Red Hat Virtualization 4.2 から 4.3 へのリモートデータベース環境のアップグレード |
第1章 セルフホストエンジン環境のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
1.1. Red Hat Virtualization 4.3 から 4.4 へのセルフホストエンジンのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
セルフホストエンジン環境をバージョン 4.3 から 4.4 にアップグレードするステップは、以下のとおりです。
アップグレードに関する考慮事項
- アップグレードを計画する場合は、Red Hat Virtualization 4.4 のアップグレードに関する考慮事項および既知の問題 を参照してください。
Open Virtual Network (OVN) および Open vSwitch (OvS) 2.11 から OVN 2021 および OvS 2.15 にアップグレードする場合、以下の条件が満たされている限り、このプロセスはユーザーからは見えません。
- Manager が最初にアップグレードされている。
- OVN/OvS バージョン 2.11 のホスト間で機能することが予想されるすべての OVN ネットワークに対して、ホストのアップグレード前に ovirt-provider-ovn セキュリティーグループを無効にしている。
- ホストは、OVN バージョン 2021 以降および OvS バージョン 2.15 になるようにアップグレードされる。OVN を適切に再設定し、証明書を更新することができるように、管理ポータルでこの手順を完了する必要があります。
- ホストがアップグレード後に再起動される。
プロバイダーと OVN がホストで正常に設定されたかどうかを確認するには、ホストの General タブで OVN configured フラグを確認します。OVN Configured が No に設定されている場合は、 → をクリックします。この設定は、REST API でも利用可能です。機能の更新に失敗した場合は、Manager 4.4 以降からホストを再インストールして OVN を設定できます。
- 正しいリポジトリーを有効にするなど、前提条件を満たしていることを確認する
- Log Collection Analysis ツールおよび Image Discrepancies ツールを使用して、アップグレードの正常な完了を妨げる問題がないか確認する
- Manager 用仮想マシンと同じホストで実行されている仮想マシンを、同じクラスターの別のホストに移行する
- 環境をグローバルメンテナンスモードに切り替える
- 4.3 Manager を最新バージョンの 4.3 に更新する
- Manager を 4.3 から 4.4 にアップグレードする
- 仮想マシンのダウンタイムを削減しつつ、セルフホストエンジンノードおよび通常のホストをアップグレードする
- (オプション) ローカルストレージを保持した状態で RHVH をアップグレードする
- クラスターの互換バージョンを更新する
- 実行中またはサスペンド中の仮想マシンをすべて再起動して、設定を更新する
- データセンターの互換バージョンを更新する
1.1.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンで必要となるダウンタイムについて計画されていること。アップグレードプロセスでクラスターの互換バージョンを更新した後、それぞれの仮想マシンを再起動すると新しいハードウェア設定が自動的に適用されます。すべての実行中またはサスペンド中の仮想マシンを直ちに再起動して、設定変更を適用する必要があります。
- お使いの環境が Red Hat Virtualization 4.4 の要件を満たしていること。すべての前提条件の一覧は、Planning and Prerequisites Guide の Requirements を参照してください。
- Red Hat Virtualization Manager をアップグレードする場合には、既存ホストのいずれかを使用することが推奨されます。新規ホストの使用を選択する場合は、アップグレード手順を開始する前に、新規ホストに一意の名前を割り当ててから、既存のクラスターに追加する必要があります。
1.1.2. 環境の分析 リンクのコピーリンクがクリップボードにコピーされました!
更新の実行やトラブルシューティングを行う前に、Log Collection Analysis ツールおよび Image Discrepancies ツールを実行することが推奨されます。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。
1.1.3. ログコレクション分析ツール リンクのコピーリンクがクリップボードにコピーされました!
更新の実行前に Log Collection Analysis ツールを実行し、トラブルシューティングを行います。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。ツールはシステムに関する詳細情報を収集し、それを HTML ファイルとして提示します。
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.3 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンに Log Collection Analysis ツールをインストールします。
yum install rhv-log-collector-analyzer
# yum install rhv-log-collector-analyzerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ツールを実行します。
rhv-log-collector-analyzer --live
# rhv-log-collector-analyzer --liveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細なレポートが表示されます。
デフォルトでは、レポートは
analyzer_report.htmlという名前のフィアルに保存されます。ファイルを特定の場所に保存するには
--htmlフラグを使用して場所を指定します。rhv-log-collector-analyzer --live --html=/directory/filename.html
# rhv-log-collector-analyzer --live --html=/directory/filename.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELinks テキストモードの Web ブラウザーを使用して、ターミナル内のアナライザーレポートを読み取ることができます。ELinks ブラウザーをインストールするには、以下を実行します。
yum install -y elinks
# yum install -y elinksCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELink を起動し、
analyzer_report.htmlを開きます。elinks /home/user1/analyzer_report.html
# elinks /home/user1/analyzer_report.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow レポート内を移動するには、ELinks で以下のコマンドを使用します。
-
Insertでスクロールアップ -
Deleteでスクロールダウン -
PageUpでページアップ -
PageDownでページダウン -
left Bracketで左にスクロール -
right Bracketで右にスクロール
-
1.1.3.1. イメージ不一致ツールを使用したスナップショットの状態の監視 リンクのコピーリンクがクリップボードにコピーされました!
RHV Image Discrepancies ツールは、ストレージドメインと RHV データベースのイメージデータを分析します。ボリュームとボリューム属性に不一致が見つかった場合は警告しますが、それらの不一致は修正されません。このツールは、次のようなさまざまなシナリオで使用します。
- バージョンをアップグレードする前に、壊れたボリュームまたはチェーンを新しいバージョンに持ち越さないようにします。
- 失敗したストレージ操作に続いて、不良状態のボリュームまたは属性を検出します。
- バックアップから RHV データベースまたはストレージを復元した後。
- 定期的に、問題が悪化する前に潜在的な問題を検出します。
- スナップショットまたはライブストレージの移行に関連する問題を分析し、これらのタイプの問題を修正した後、システムの状態を確認します。
前提条件
-
必要なバージョン: このツールは、
rhv-log-collector-analyzer-0.2.15-0.el7evの RHV バージョン 4.3.8 で導入されました。 - データ収集は異なる場所で同時に実行され、アトミックではないため、ストレージドメインを変更する可能性のある環境内のすべてのアクティビティーを停止します。つまり、スナップショットを作成または削除したり、ディスクを編集、移動、作成、または削除したりしないでください。そうしないと、不整合が誤って検出される可能性があります。プロセス中、仮想マシンは正常に実行されたままになります。
手順
ツールを実行するには、RHV Manager で次のコマンドを入力します。
rhv-image-discrepancies
# rhv-image-discrepanciesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ツールが不一致を見つけた場合、特にツールの実行中に一部の操作が実行された可能性がある場合は、ツールを再実行して結果を確認します。
このツールには Export および ISO ストレージドメインが含まれており、そのストレージドメインの不一致を報告する可能性があります。その場合、これらのストレージドメインには RHV データベースにイメージのエントリーがないため、無視することができます。
結果について
このツールは次のことを報告します。
- ストレージに表示されているがデータベースにはないボリュームがある場合、またはデータベースには表示されているがストレージにはないボリュームがある場合。
- 一部のボリューム属性がストレージとデータベースで異なる場合。
出力サンプル
1.1.4. セルフホストエンジンホストからの仮想マシンの移行 リンクのコピーリンクがクリップボードにコピーされました!
ホストのアップグレードが終了するまで、Manager 用仮想マシンのみがホストに留まる必要があります。Manager 用仮想マシン以外の仮想マシンを、同じクラスターの別のホストに移行します。
ライブマイグレーションを使用して、仮想マシンのダウンタイムを最小限に抑えることができます。詳細は、仮想マシン管理ガイド の ホスト間での仮想マシンの移行 を参照してください。
1.1.5. グローバルメンテナンスモードの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Manager 用仮想マシンの設定またはアップグレード作業を実施する前に、セルフホスト型エンジン環境をグローバルメンテナンスモードに切り替える必要があります。
手順
セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを有効にします。
hosted-engine --set-maintenance --mode=global
# hosted-engine --set-maintenance --mode=globalCopy to Clipboard Copied! Toggle word wrap Toggle overflow 作業を進める前に、環境がグローバルメンテナンスモードにあることを確認します。
hosted-engine --vm-status
# hosted-engine --vm-statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターがグローバルメンテナンスモードにあることを示すメッセージが表示されるはずです。
次に、Manager を最新バージョンの 4.3 に更新してください。
1.1.6. Red Hat Virtualization Manager の更新 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.3 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンで、更新されたパッケージが利用可能かどうかを確認します。
engine-upgrade-check
# engine-upgrade-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupスクリプトで Red Hat Virtualization Manager を更新します。engine-setupスクリプトにより、設定に関する質問への回答が求められます。その後、ovirt-engineサービスの停止、更新パッケージのダウンロード/インストール、データベースのバックアップ/更新、インストール後設定の実施を経てから、ovirt-engineサービスが起動します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記engine-setupスクリプトは、Red Hat Virtualization Manager のインストールプロセス中にも使用され、指定した設定値が保存されます。更新時に、設定のプレビュー時に保存された値が表示され、engine-configがインストール後に設定の更新に使用される場合は最新ではない可能性があります。たとえば、インストール後にengine-configを使用してSANWipeAfterDeleteをtrueへと更新した場合、engine-setupは設定プレビューに Default SAN wipe after delete: False と出力します。ただし、更新された値はengine-setupによって上書きされることはありません。重要更新プロセスに時間がかかる場合があります。完了する前にプロセスを停止しないでください。
Manager にインストールされているベースオペレーティングシステムと、オプションパッケージを更新します。
yum update --nobest
# yum update --nobestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動して更新を完了してください。
次に、Manager を 4.4 にアップグレードしてください。
1.1.7. Red Hat Virtualization Manager 4.3 から 4.4 へのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization Manager 4.4 は、Red Hat Enterprise Linux バージョン 8.2 から 8.6 でのみサポートされます。RHV Manager 4.3 セルフホストエンジンの実行に使用する物理マシンと同じマシンを使用する場合でも、セルフホストエンジンホスト上の Red Hat Enterprise Linux 8.6 または Red Hat Virtualization Host のクリーンインストールを実行する必要があります。
アップグレードプロセスでは、Red Hat Virtualization Manager 4.3 バックアップファイルを Red Hat Virtualization Manager 4.4 の仮想マシンに復元する必要があります。
前提条件
- 環境内のすべてのデータセンターおよびクラスターにおいて、クラスターの互換レベルがバージョン 4.2 または 4.3 に設定されていること。
- 環境のすべての仮想マシンでは、クラスターの互換レベルがバージョン 4.3 に設定されている必要があります。
- DHCP を使用し、同じ IP アドレスを使用する必要が場合は、セルフホストエンジンの MAC アドレスを書き留めておくこと。デプロイスクリプトにより、この情報の入力が求められます。
- デプロイメント時に、Manager マシンの新しいストレージドメインが提供されていること。デプロイメントスクリプトは 4.3 ストレージドメインの名前を変更し、そのデータを保存して障害復旧を有効にします。
アップグレード時の自動仮想マシンの移行を防ぐために、クラスタースケジューリングポリシーを
cluster_maintenanceに設定します。Important複数の高可用性セルフホストエンジンノードで設定される環境では、Manager を 4.4 にアップグレードした後にバージョン 4.3 Manager をホストするストレージドメインをデタッチする必要があります。4.4 セルフホストエンジンのデプロイメントに専用のストレージドメインを使用します。
- 外部 CA を使用して HTTPS 証明書に署名する場合は、Administration Guide の Replacing the Red Hat Virtualization Manager CA Certificate の手順に従うこと。バックアップおよび復元にはサードパーティーの証明書が含まれるので、アップグレード後に管理ポータルにログインできるはずです。virt-viewer の外部メニューが機能するように、CA 証明書がすべてのクライアントのシステム全体のトラストストアに追加されていることを確認します。詳細は、BZ#1313379 を参照してください。
接続されたホストと仮想マシンは、Manager のアップグレード中も引き続き動作可能です。
手順
Manager 用仮想マシンにログインし、エンジンサービスをシャットダウンします。
systemctl stop ovirt-engine
# systemctl stop ovirt-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Virtualization Manager 4.3 環境のバックアップを作成します。
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log
# engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow - バックアップファイルを RHV 環境外のストレージデバイスにコピーします。
セルフホストエンジンをシャットダウンします。
shutdown
# shutdownCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記セルフホストエンジンの仮想マシンを再利用して Red Hat Virtualization Manager 4.4 をデプロイする場合は、シャットダウンする前にセルフホストエンジンネットワークインターフェイスの MAC アドレスをメモします。
セルフホストエンジンがシャットダウンしていることを確認します。
hosted-engine --vm-status | grep -E 'Engine status|Hostname'
# hosted-engine --vm-status | grep -E 'Engine status|Hostname'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ホストのいずれかが
detailフィールドをUpとして報告する場合は、そのホストにログインしてhosted-engine --vm-shutdownコマンドでシャットダウンします。Manager 用仮想マシンを実行している既存のノードに RHVH 4.4 または Red Hat Enterprise Linux 8.6 をインストールして、セルフホストエンジンのデプロイメントホストとして使用します。詳細は、セルフホストエンジン用デプロイメントホストのインストール を参照してください。
注記既存ホストのいずれかを使用することが推奨されます。新規ホストの使用を選択する場合は、アップグレード手順を開始する前に、新規ホストに一意の名前を割り当ててから、既存のクラスターに追加する必要があります。
セルフホストエンジンのデプロイメントツールをインストールします。
yum install ovirt-hosted-engine-setup
# yum install ovirt-hosted-engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow - バックアップファイルをホストにコピーします。
Manager ホストにログインし、バックアップファイルを使用してセルフホストエンジンをデプロイします。
hosted-engine --deploy --restore-from-file=/path/backup.bck
# hosted-engine --deploy --restore-from-file=/path/backup.bckCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記tmuxを使用すると、サーバーへの接続が中断された場合にデプロイメントスクリプトが続行できるようになります。これにより、再接続してデプロイメントにアタッチし、続行することができます。これ以外の場合は、デプロイメント中に接続が中断されると、デプロイメントに失敗します。tmuxを使用してデプロイメントスクリプトを実行するには、デプロイメントスクリプトを実行する前にtmuxコマンドを入力します。tmux hosted-engine --deploy --restore-from-file=backup.bck
# tmux # hosted-engine --deploy --restore-from-file=backup.bckCopy to Clipboard Copied! Toggle word wrap Toggle overflow デプロイメントスクリプトは自動的にグローバルメンテナンスモードを無効にし、HA エージェントを呼び出してセルフホストエンジンの仮想マシンを起動します。4.4 セルフホストエンジンのアップグレードされたホストは、HA モードがアクティブであると報告しますが、他のホストは、以前のセルフホストエンジンのストレージに接続されたままであるため、グローバルメンテナンスモードが依然として有効化されていると報告します。
- Manager 4.3 マシンをホストするストレージドメインをデタッチします。詳細は、Administration Guideの Detaching a Storage Domain from a Data Center を参照してください。
Manager 用仮想マシンにログインし、エンジンサービスをシャットダウンします。
systemctl stop ovirt-engine
# systemctl stop ovirt-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.4 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
オプションの拡張機能パッケージが Red Hat Virtualization Manager 4.3 マシンにインストールされていた場合はインストールします。
yum install ovirt-engine-extension-aaa-ldap ovirt-engine-extension-aaa-misc
# yum install ovirt-engine-extension-aaa-ldap ovirt-engine-extension-aaa-miscCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ovirt-engine-extension-aaa-ldapは非推奨になりました。新規インストールの場合は、Red Hat Single Sign On を使用します。詳細は、管理ガイド の Red Hat Single Sign-On のインストールおよび設定 を参照してください。注記バックアップおよび復元プロセスの一部として移行されないため、これらの拡張機能パッケージの設定は手動で再適用する必要があります。
engine-setupコマンドを実行して Manager を設定します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスターの互換バージョンが、既存のバージョンに応じて 4.2 または 4.3 に設定されている状態で、Red Hat Virtualization Manager 4.4 がインストールされるようになりました。
次に、セルフホストエンジンノードを更新し、続いて通常のホストを更新してください。手順は、両方のホストタイプで同じです。
1.1.8. ホストおよび仮想マシンの RHV 4.3 から 4.4 への移行 リンクのコピーリンクがクリップボードにコピーされました!
ホストおよび仮想マシンを Red Hat Virtualization 4.3 から 4.4 に移行し、環境内の仮想マシンのダウンタイムを最小限に抑えることができます。
このプロセスでは、すべての仮想マシンを 1 つのホストから移行する必要があります。これにより、そのホストが RHV 4.4 にアップグレードできるようにします。アップグレード後に、ホストを Manager に再度アタッチすることができます。
ホストのオペレーティングシステムのインストールまたは再インストールを行う場合、Red Hat では、ホストにアタッチされている既存の OS 以外のストレージを最初にデタッチすることを強く推奨しています。これは、ディスクを誤って初期化してデータが失われる可能性を避けるためです。
CPU パススルー仮想マシンは、RHV 4.3 から RHV 4.4 に適切に移行しない可能性があります。
RHV 4.3 および RHV 4.4 は、それぞれ RHEL 7 および RHEL 8 をベースにしています。これには、CPU フラグおよびコンストラクターが異なるカーネルバージョンがあります。これにより、CPU パススルーの仮想マシンの移行で問題が発生する可能性があります。
前提条件
- RHV 4.4 のホストには、Red Hat Enterprise Linux バージョン 8.2 から 8.6 が必要です。RHV 4.3 のホストの実行に使用する物理マシンと同じものを使用している場合でも、Red Hat Enterprise Linux 8.6 以降または Red Hat Virtualization Host 4.4 のクリーンインストールが必要です。
- Red Hat Virtualization Manager 4.4 がインストールされ、実行中である。
- ホストが属するデータセンターおよびクラスターの互換性レベルが 4.2 または 4.3 に設定されていること。手順の開始前に、環境内のすべてのデータセンターおよびクラスターにおいて、クラスターの互換レベルがバージョン 4.2 または 4.3 に設定されていること。
手順
- アップグレードするホストを選択し、そのホストの仮想マシンを同じクラスター内の別のホストに移行します。ライブマイグレーションを使用して、仮想マシンのダウンタイムを最小限に抑えることができます。詳細は、仮想マシン管理ガイド の ホスト間での仮想マシンの移行 を参照してください。
- ホストをメンテナンスモードにし、Manager からホストを削除します。詳細は、Administration Guide の Removing a Host を参照してください。
- Red Hat Enterprise Linux 8.6 または RHVH 4.4 をインストールします。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization 用ホストのインストール を参照してください。
- 適切なパッケージをインストールして、RHV 4.4 のホストを有効にします。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization 用ホストのインストール を参照してください。
- このホストを Manager に追加し、これを同じクラスターに割り当てます。次に、仮想マシンをこのホストに移行してください。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization Manager への通常のホストの追加 を参照してください。
これらのステップを繰り返して仮想マシンを移行し、同じクラスター内の残りのホストを 1 つずつアップグレードします。すべてが Red Hat Virtualization 4.4 を実行するまでこれを続けます。
1.1.9. ローカルストレージを保持した状態での RHVH のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
ローカルストレージが他のストレージドメインと共有されないため、ローカルストレージを使用する環境は、別のクラスターのホストに仮想マシンを移行できません。ローカルストレージドメインを持つ RHVH 4.3 ホストをアップグレードには、ローカルストレージを保持しながらホストを再インストールし、4.4 環境で新しいローカルストレージドメインを作成してから、以前のローカルストレージを新しいドメインにインポートします。
前提条件
- Red Hat Virtualization Manager 4.4 がインストールされ、実行中である。
- ホストが属するデータセンターおよびクラスターの互換レベルが、4.2 または 4.3 に設定されていること。
手順
このプロセスを開始する前に、RHVH 4.3 ホストのローカルストレージ上のローカルストレージがメンテナンスモードにあることを確認します。以下のステップを実行します。
- データセンター タブを開きます。
- 詳細 ペインの ストレージ タブをクリックし、結果一覧でストレージドメインを選択します。
- メンテナンス をクリックします。
インストールガイド の Red Hat Virtualization Host のインストール に記載されているとおりに、Red Hat Virtualization Host を再インストールします。
重要インストール先 画面で RHVH をインストールするデバイスを選択する場合は、仮想マシンを保存するデバイスを選択しないでください。オペレーティングシステムをインストールするデバイスのみを選択します。
キックスタートを使用してホストをインストールする場合は、キックスタートファイルに以下を追加して、仮想マシンを含むデバイスを保存するようにしてください。ここでの `device` は、適切なデバイスに置き換えてください。
clearpart --all --drives=device
# clearpart --all --drives=deviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow キックスタートの使用方法は、Red Hat Enterprise Linux 8 高度な RHEL インストールの実行 の キックスタートの参照 を参照してください。
再インストールしたホストで、以前の環境を復元するディレクトリー (
/dataなど) を作成します。mkdir /data
# mkdir /dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいディレクトリーに以前のローカルストレージをマウントします。この例では、
/dev/sdX1がローカルストレージになります。mount /dev/sdX1 /data
# mount /dev/sdX1 /dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいディレクトリーに以下のパーミッションを設定します。
chown -R 36:36 /data chmod -R 0755 /data
# chown -R 36:36 /data # chmod -R 0755 /dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat では、サーバーの再起動が必要となる場合に備えて、
/etc/fstab経由でローカルストレージを自動的にマウントすることも推奨します。blkid | grep -i sdX1 vi /etc/fstab
# blkid | grep -i sdX1 /dev/sdX1: UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" TYPE="ext4" # vi /etc/fstab UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" /data ext4 defaults 0 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルでデータセンターを作成し、ストレージタイプ ドロップダウンメニューで ローカル を選択します。
- 新しいデータセンターでクラスターを設定します。詳細は、Administration Guide の Creating a New Cluster を参照してください。
- Manager にホストを追加します。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization Manager への通常のホストの追加 を参照してください。
ホスト上で、最初のローカルストレージドメインの作成に使用する新しいディレクトリーを作成します。たとえば、以下のような設定です。
mkdir -p /localfs chown 36:36 /localfs chmod -R 0755 /localfs
# mkdir -p /localfs # chown 36:36 /localfs # chmod -R 0755 /localfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルで ストレージ タブを開き、新規ドメイン をクリックして新しいローカルストレージドメインを作成します。
-
名前を
localfsに設定し、パスを/localfsに設定します。 -
ローカルストレージがアクティブになったら、ドメインのインポート をクリックして、ドメインの詳細を設定します。たとえば、
Dataを名前として、Local on Hostをストレージタイプとして、/dataをパスとして定義します。 - ストレージドメインがデータセンターにすでにアタッチされていることを知らせるメッセージが表示されるので、 をクリックして確定します。
新しいストレージドメインをアクティブ化します。
- データセンター タブを開きます。
- 詳細ペインの ストレージ タブをクリックし、結果一覧で新しいデータストレージドメインを選択します。
- アクティブ化 クリックします。
新規ストレージドメインがアクティブになったら、仮想マシンとそのディスクをインポートします。
- ストレージ タブで、データ を選択します。
- 詳細ペインで 仮想マシンのインポート タブを選択し、仮想マシンを選択して インポート をクリックします。詳細は、仮想マシン管理ガイド の データドメインからの仮想マシンのインポート を参照してください。
-
すべての仮想マシンが正常にインポートされ、適切に機能していることを確認したら、
localfsをメンテナンスモードに移行できます。 ストレージ タブをクリックし、結果一覧で localfs を選択します。
- 詳細ペインの データセンター タブをクリックします。
- メンテナンスをクリックしてから をクリックし、ストレージドメインをメンテナンスモードに移動します。
- デタッチ をクリックします。デタッチストレージの確認ウィンドウが開きます。
- をクリックします。
これで、ホストのバージョン 4.4 へのアップグレード、新しいローカルストレージドメインの作成、4.3 ストレージドメインおよびその仮想マシンのインポートが完了しました。
1.1.10. クラスターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization のクラスターには互換バージョンがあります。クラスターの互換バージョンは、そのクラスター内の全ホストがサポートする Red Hat Virtualization の機能を示します。クラスターの互換バージョンは、そのクラスター内で最も機能性の低いホストオペレーティングシステムのバージョンに応じて設定されます。
前提条件
- クラスターの互換レベルを変更するには、まず、クラスター内の全ホストを更新して、必要な互換性レベルをサポートするレベルにする必要があります。更新が利用可能であることを示すアイコンがホストの横にあるかどうかを確認します。
制限事項
クラスター互換性レベルを 4.6 にアップグレードした後、VirtIO NIC は別のデバイスとして列挙されます。したがって、NIC の再設定が必要になる場合があります。Red Hat は、クラスターをアップグレードする前に、仮想マシンでクラスター互換性レベルを 4.6 に設定し、ネットワーク接続を確認することにより、仮想マシンをテストすることをお勧めします。
仮想マシンのネットワーク接続に失敗した場合は、クラスターをアップグレードする前に、現在のエミュレーションする仮想マシンに一致するカスタムのエミュレーションする仮想マシン (例: 4.5 互換バージョンの場合は pc-q35-rhel8.3.0) で仮想マシンを設定します。
手順
- 管理ポータルで、 → をクリックします。
- 変更を行うクラスターを選択し、 をクリックします。
- 全般 タブで 互換バージョン を必要な値に変更します。
- をクリックします。クラスターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
一部の仮想マシンおよびテンプレートが不適切に設定されていることを警告するエラーメッセージが表示される場合があります。このエラーを修正するには、それぞれの仮想マシンを手動で編集します。仮想マシンの編集 ウィンドウには、修正すべき項目を確認することのできる新たな検証および警告が表示されます。問題が自動的に修正され、仮想マシンの設定を再度保存するだけで十分な場合もあります。それぞれの仮想マシンを編集したら、クラスターの互換バージョンを変更することができます。
1.1.11. 仮想マシンのクラスター互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの互換バージョンを更新したら、実行中またはサスペンド中のすべての仮想マシンについてクラスターの互換バージョンを更新する必要があります。そのためには、管理ポータルから再起動するか、REST API を使用して、またはゲストオペレーティングシステム内から更新する必要があります。再起動が必要な仮想マシンには、変更が保留されていることを示すアイコン (
) が付きます。
Manager 用仮想マシンを再起動する必要はありません。
別途適切な時期に仮想マシンを再起動することもできますが、仮想マシンで最新の設定が使用されるように、直ちに再起動することを強く推奨します。再起動していない仮想マシンは以前の設定で動作し、さらに仮想マシンの設定が変更された場合には、保留中のクラスターの互換バージョンが上書きされる場合があります。
手順
- 管理ポータルで → をクリックします。
再起動が必要な仮想マシンを確認します。Vms: 検索バーに以下のクエリーを入力します。
next_run_config_exists=True
next_run_config_exists=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 検索結果に、変更が保留中の仮想マシンがすべて表示されます。
- それぞれの仮想マシンを選択し、再起動 をクリックします。あるいは、必要な場合は、仮想マシン自体から仮想マシンを再起動することができます。
仮想マシンが起動すると、新しい互換バージョンが自動的に適用されます。
プレビュー状態にある仮想マシンスナップショットについては、クラスターの互換バージョンを変更することができません。まずコミットするか、プレビューを取り消す必要があります。
1.1.12. データセンターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization データセンターには、互換バージョンがあります。互換バージョンとは、データセンターが互換性を持つ Red Hat Virtualization のバージョンを指します。データセンター内のクラスターは、すべて指定の互換性レベルをサポートする必要があります。
前提条件
- データセンターの互換レベルを変更するには、事前にデータセンター内のクラスターおよび仮想マシンの互換バージョンがすべて更新されている必要があります。
手順
- 管理ポータルで → をクリックします。
- 変更を行うデータセンターを選択し、 をクリックします。
- 互換バージョン を必要な値に変更します。
- をクリックします。データセンターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
1.2. Red Hat Virtualization 4.2 から 4.3 へのセルフホストエンジンのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
セルフホストエンジン環境をバージョン 4.2 から 4.3 にアップグレードするステップは、以下のとおりです。
- 正しいリポジトリーを有効にするなど、前提条件を満たしていることを確認する
- Log Collection Analysis ツールおよび Image Discrepancies ツールを使用して、アップグレードの正常な完了を妨げる問題がないか確認する
- 環境をグローバルメンテナンスモードに切り替える
- 4.2 Manager を最新バージョンの 4.2 に更新する
- Manager を 4.2 から 4.3 にアップグレードする
- グローバルメンテナンスモードを無効にする
- セルフホストエンジンノードおよび通常のホストをアップグレードする
- クラスターの互換バージョンを更新する
- 実行中またはサスペンド中の仮想マシンをすべて再起動して、設定を更新する
- データセンターの互換バージョンを更新する
- 以前に SHA-1 証明書を SHA-256 証明書に置き換えずに 4.2 にアップグレードした場合は、ここで証明書を置き換える
1.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンで必要となるダウンタイムについて計画されていること。アップグレードプロセスでクラスターの互換バージョンを更新した後、それぞれの仮想マシンを再起動すると新しいハードウェア設定が自動的に適用されます。すべての実行中またはサスペンド中の仮想マシンを直ちに再起動して、設定変更を適用する必要があります。
- お使いの環境が Red Hat Virtualization 4.4 の要件を満たしていること。すべての前提条件の一覧は、Planning and Prerequisites Guide の Requirements を参照してください。
- Red Hat Virtualization Manager をアップグレードする場合には、既存ホストのいずれかを使用することが推奨されます。新規ホストの使用を選択する場合は、アップグレード手順を開始する前に、新規ホストに一意の名前を割り当ててから、既存のクラスターに追加する必要があります。
1.2.2. 環境の分析 リンクのコピーリンクがクリップボードにコピーされました!
更新の実行やトラブルシューティングを行う前に、Log Collection Analysis ツールおよび Image Discrepancies ツールを実行することが推奨されます。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。
1.2.3. ログコレクション分析ツール リンクのコピーリンクがクリップボードにコピーされました!
更新の実行前に Log Collection Analysis ツールを実行し、トラブルシューティングを行います。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。ツールはシステムに関する詳細情報を収集し、それを HTML ファイルとして提示します。
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.2 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンに Log Collection Analysis ツールをインストールします。
yum install rhv-log-collector-analyzer
# yum install rhv-log-collector-analyzerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ツールを実行します。
rhv-log-collector-analyzer --live
# rhv-log-collector-analyzer --liveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細なレポートが表示されます。
デフォルトでは、レポートは
analyzer_report.htmlという名前のフィアルに保存されます。ファイルを特定の場所に保存するには
--htmlフラグを使用して場所を指定します。rhv-log-collector-analyzer --live --html=/directory/filename.html
# rhv-log-collector-analyzer --live --html=/directory/filename.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELinks テキストモードの Web ブラウザーを使用して、ターミナル内のアナライザーレポートを読み取ることができます。ELinks ブラウザーをインストールするには、以下を実行します。
yum install -y elinks
# yum install -y elinksCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELink を起動し、
analyzer_report.htmlを開きます。elinks /home/user1/analyzer_report.html
# elinks /home/user1/analyzer_report.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow レポート内を移動するには、ELinks で以下のコマンドを使用します。
-
Insertでスクロールアップ -
Deleteでスクロールダウン -
PageUpでページアップ -
PageDownでページダウン -
left Bracketで左にスクロール -
right Bracketで右にスクロール
-
1.2.3.1. イメージ不一致ツールを使用したスナップショットの状態の監視 リンクのコピーリンクがクリップボードにコピーされました!
RHV Image Discrepancies ツールは、ストレージドメインと RHV データベースのイメージデータを分析します。ボリュームとボリューム属性に不一致が見つかった場合は警告しますが、それらの不一致は修正されません。このツールは、次のようなさまざまなシナリオで使用します。
- バージョンをアップグレードする前に、壊れたボリュームまたはチェーンを新しいバージョンに持ち越さないようにします。
- 失敗したストレージ操作に続いて、不良状態のボリュームまたは属性を検出します。
- バックアップから RHV データベースまたはストレージを復元した後。
- 定期的に、問題が悪化する前に潜在的な問題を検出します。
- スナップショットまたはライブストレージの移行に関連する問題を分析し、これらのタイプの問題を修正した後、システムの状態を確認します。
前提条件
-
必要なバージョン: このツールは、
rhv-log-collector-analyzer-0.2.15-0.el7evの RHV バージョン 4.3.8 で導入されました。 - データ収集は異なる場所で同時に実行され、アトミックではないため、ストレージドメインを変更する可能性のある環境内のすべてのアクティビティーを停止します。つまり、スナップショットを作成または削除したり、ディスクを編集、移動、作成、または削除したりしないでください。そうしないと、不整合が誤って検出される可能性があります。プロセス中、仮想マシンは正常に実行されたままになります。
手順
ツールを実行するには、RHV Manager で次のコマンドを入力します。
rhv-image-discrepancies
# rhv-image-discrepanciesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ツールが不一致を見つけた場合、特にツールの実行中に一部の操作が実行された可能性がある場合は、ツールを再実行して結果を確認します。
このツールには Export および ISO ストレージドメインが含まれており、そのストレージドメインの不一致を報告する可能性があります。その場合、これらのストレージドメインには RHV データベースにイメージのエントリーがないため、無視することができます。
結果について
このツールは次のことを報告します。
- ストレージに表示されているがデータベースにはないボリュームがある場合、またはデータベースには表示されているがストレージにはないボリュームがある場合。
- 一部のボリューム属性がストレージとデータベースで異なる場合。
出力サンプル
1.2.4. グローバルメンテナンスモードの有効化 リンクのコピーリンクがクリップボードにコピーされました!
Manager 用仮想マシンの設定またはアップグレード作業を実施する前に、セルフホスト型エンジン環境をグローバルメンテナンスモードに切り替える必要があります。
手順
セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを有効にします。
hosted-engine --set-maintenance --mode=global
# hosted-engine --set-maintenance --mode=globalCopy to Clipboard Copied! Toggle word wrap Toggle overflow 作業を進める前に、環境がグローバルメンテナンスモードにあることを確認します。
hosted-engine --vm-status
# hosted-engine --vm-statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターがグローバルメンテナンスモードにあることを示すメッセージが表示されるはずです。
1.2.5. Red Hat Virtualization Manager の更新 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.2 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンで、更新されたパッケージが利用可能かどうかを確認します。
engine-upgrade-check
# engine-upgrade-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupスクリプトで Red Hat Virtualization Manager を更新します。engine-setupスクリプトにより、設定に関する質問への回答が求められます。その後、ovirt-engineサービスの停止、更新パッケージのダウンロード/インストール、データベースのバックアップ/更新、インストール後設定の実施を経てから、ovirt-engineサービスが起動します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記engine-setupスクリプトは、Red Hat Virtualization Manager のインストールプロセス中にも使用され、指定した設定値が保存されます。更新時に、設定のプレビュー時に保存された値が表示され、engine-configがインストール後に設定の更新に使用される場合は最新ではない可能性があります。たとえば、インストール後にengine-configを使用してSANWipeAfterDeleteをtrueへと更新した場合、engine-setupは設定プレビューに Default SAN wipe after delete: False と出力します。ただし、更新された値はengine-setupによって上書きされることはありません。重要更新プロセスに時間がかかる場合があります。完了する前にプロセスを停止しないでください。
Manager にインストールされているベースオペレーティングシステムと、オプションパッケージを更新します。
yum update --nobest
# yum update --nobestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動して更新を完了してください。
1.2.6. Red Hat Virtualization Manager の 4.2 から 4.3 へのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
アップグレードしているマシンにログインする必要があります。
アップグレードに失敗すると、engine-setup コマンドは Red Hat Virtualization Manager のインストールを以前の状態に復元しようとします。このため、アップグレードが完了するまで、以前のバージョンのリポジトリーを削除しないでください。アップグレードに失敗すると、engine-setup スクリプトによりインストールの復元方法を説明します。
手順
Red Hat Virtualization 4.3 のリポジトリーを有効にします。
subscription-manager repos \ --enable=rhel-7-server-rhv-4.3-manager-rpms \ --enable=jb-eap-7.2-for-rhel-7-server-rpms# subscription-manager repos \ --enable=rhel-7-server-rhv-4.3-manager-rpms \ --enable=jb-eap-7.2-for-rhel-7-server-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow その他のリポジトリーはすべて、Red Hat Virtualization リリース全体を通して同じになります。
setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupを実行し、プロンプトに従って Red Hat Virtualization Manager をアップグレードします。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Virtualization 4.2 のリポジトリーを無効にして、このシステムで 4.2 のパッケージが使用されないようにします。
subscription-manager repos \ --disable=rhel-7-server-rhv-4.2-manager-rpms \ --disable=jb-eap-7-for-rhel-7-server-rpms# subscription-manager repos \ --disable=rhel-7-server-rhv-4.2-manager-rpms \ --disable=jb-eap-7-for-rhel-7-server-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow ベースオペレーティングシステムを更新します。
yum update
# yum updateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動してアップグレードを完了してください。
Manager はバージョン 4.3 にアップグレードされました。
1.2.7. グローバルメンテナンスモードの無効化 リンクのコピーリンクがクリップボードにコピーされました!
手順
- Manager 用仮想マシンにログインし、シャットダウンします。
セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを無効にします。
hosted-engine --set-maintenance --mode=none
# hosted-engine --set-maintenance --mode=noneCopy to Clipboard Copied! Toggle word wrap Toggle overflow グローバルメンテナンスモードを終了すると、ovirt-ha-agent が Manager 用仮想マシンを起動し、続いて Manager が自動的に起動します。Manager が起動するまでに最大で 10 分程度かかる場合があります。
環境が動作していることを確認します。
hosted-engine --vm-status
# hosted-engine --vm-statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 情報の一覧に、Engine status が含まれます。Engine status の値は、以下のようになるはずです。
{"health": "good", "vm": "up", "detail": "Up"}{"health": "good", "vm": "up", "detail": "Up"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記仮想マシンが起動中で Manager がまだ動作していない場合、Engine status は以下のようになります。
{"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}{"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow このような場合には、数分間待ってからやり直してください。
次に、セルフホストエンジンノードを更新し、続いて通常のホストを更新してください。手順は、両方のホストタイプで同じです。
1.2.8. クラスター内の全ホストの更新 リンクのコピーリンクがクリップボードにコピーされました!
ホストを個別に更新するのではなく、クラスター内の全ホストを更新することができます。この手法は、Red Hat Virtualization を新しいバージョンにアップグレードする際に特に役立ちます。更新の自動化に使用する Ansible ロールの詳細は、oVirt クラスターアップグレード を参照してください。
クラスターは一度に 1 つずつ更新します。
制限事項
-
RHVH の更新時には、
/etcおよび/varディレクトリーに変更されたコンテンツのみを保持します。他のパスに含まれる変更されたデータは更新時に上書きされます。 - クラスターの移行が有効化されている場合には、仮想マシンはそのクラスター内の別のホストに自動的に移行されます。
- セルフホスト型エンジン環境では、Manager 用仮想マシンは同一クラスター内のセルフホスト型エンジンノード間でのみ移行が可能です。通常のホストに移行することはできません。
- ホストが属するクラスターには、ホストがメンテナンスを実行するのに十分なメモリーが確保されている必要があります。確保されていないと、仮想マシンの移行がハングして失敗してしまいます。ホストを更新する前に一部またはすべての仮想マシンをシャットダウンしておくと、ホスト更新によるメモリー使用量を低減することができます。
- ホストに固定された仮想マシン (vGPU を使用している仮想マシンなど) を別のホストに移行することはできません。ホストの更新をスキップしない限り、そのホストに固定された仮想マシンは更新中にシャットダウンされます。
手順
- 管理ポータルで → をクリックし、クラスターを選択します。ステータスのアップグレード 列には、クラスターの任意のホストでアップグレードが利用可能かどうかが表示されます。
- アップグレード をクリックします。
- 更新するホストを選択し、次に Next をクリックします。
オプションを設定します。
- 固定された仮想マシンの停止: クラスター内のホストに固定された仮想マシンをシャットダウンします。このオプションは、デフォルトで選択されています。このチェックボックスの選択を解除すると、固定された仮想マシンが動作を続けられるように、それらのホストの更新をスキップすることができます (固定された仮想マシンが重要なサービスまたはプロセスを実行中で、更新中の予期せぬ時にシャットダウンされるのを避けたい場合など)。
-
Upgrade Timeout (Minutes): このオプションで設定した時間内に個々のホストの更新が完了しない場合には、クラスターのアップグレードはタイムアウトで失敗します。デフォルトは
60です。60 分では不十分と思われる大規模なクラスターの場合には、時間を延長することができます。また、ホストの更新が短時間で完了する小規模なクラスターでは、短縮することができます。 - Check Upgrade: アップグレードプロセスを実行する前に、それぞれのホストで更新が利用可能かどうかを確認します。このオプションは、デフォルトでは選択されていません。ただし、Manager がホストの更新を確認する頻度をデフォルトより低く設定している状況などで、最新の更新を確実に含める必要がある場合には、このオプションを選択することができます。
- Reboot After Upgrade: ホストの更新後に、それぞれのホストを再起動します。このオプションは、デフォルトで選択されています。ホストの再起動を必要とする保留中の更新がないことが明らかであれば、このチェックボックスの選択を解除してプロセスを迅速化することができます。
-
Use Maintenance Policy: 更新時のクラスターのスケジューリングポリシーを
cluster_maintenanceに設定します。このオプションはデフォルトで選択されています。したがって、許可される動作は限定的で、仮想マシンは高可用性でない限り起動することができません。更新中も使用を続けたいカスタムのスケジューリングポリシーがある場合には、このチェックボックスの選択を解除することができます。ただし、これにより想定外の結果を招く可能性があります。このオプションを無効にする前に、カスタムのポリシーがクラスターのアップグレード操作に対応していることを確認してください。
- Next をクリックします。
- 影響を受けるホストおよび仮想マシンの概要を確認します。
- アップグレード をクリックします。
以下で、ホスト更新の進捗状況を追跡できます。
- → ビュー (ステータスのアップグレード 列は アップグレード中 と表示される)
- → ビュー
-
通知ドロワー の イベント セクション (
)
仮想マシン移行の進捗を、 → ビューの ステータス 列で個々に追跡することができます。大規模な環境では、特定の仮想マシングループの結果を表示するために、結果を絞り込まなければならない場合があります。
1.2.9. クラスターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization のクラスターには互換バージョンがあります。クラスターの互換バージョンは、そのクラスター内の全ホストがサポートする Red Hat Virtualization の機能を示します。クラスターの互換バージョンは、そのクラスター内で最も機能性の低いホストオペレーティングシステムのバージョンに応じて設定されます。
前提条件
- クラスターの互換レベルを変更するには、まず、クラスター内の全ホストを更新して、必要な互換性レベルをサポートするレベルにする必要があります。更新が利用可能であることを示すアイコンがホストの横にあるかどうかを確認します。
制限事項
クラスター互換性レベルを 4.6 にアップグレードした後、VirtIO NIC は別のデバイスとして列挙されます。したがって、NIC の再設定が必要になる場合があります。Red Hat は、クラスターをアップグレードする前に、仮想マシンでクラスター互換性レベルを 4.6 に設定し、ネットワーク接続を確認することにより、仮想マシンをテストすることをお勧めします。
仮想マシンのネットワーク接続に失敗した場合は、クラスターをアップグレードする前に、現在のエミュレーションする仮想マシンに一致するカスタムのエミュレーションする仮想マシン (例: 4.5 互換バージョンの場合は pc-q35-rhel8.3.0) で仮想マシンを設定します。
手順
- 管理ポータルで、 → をクリックします。
- 変更を行うクラスターを選択し、 をクリックします。
- 全般 タブで 互換バージョン を必要な値に変更します。
- をクリックします。クラスターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
一部の仮想マシンおよびテンプレートが不適切に設定されていることを警告するエラーメッセージが表示される場合があります。このエラーを修正するには、それぞれの仮想マシンを手動で編集します。仮想マシンの編集 ウィンドウには、修正すべき項目を確認することのできる新たな検証および警告が表示されます。問題が自動的に修正され、仮想マシンの設定を再度保存するだけで十分な場合もあります。それぞれの仮想マシンを編集したら、クラスターの互換バージョンを変更することができます。
1.2.10. 仮想マシンのクラスター互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの互換バージョンを更新したら、実行中またはサスペンド中のすべての仮想マシンについてクラスターの互換バージョンを更新する必要があります。そのためには、管理ポータルから再起動するか、REST API を使用して、またはゲストオペレーティングシステム内から更新する必要があります。再起動が必要な仮想マシンには、変更が保留されていることを示すアイコン (
) が付きます。
Manager 用仮想マシンを再起動する必要はありません。
別途適切な時期に仮想マシンを再起動することもできますが、仮想マシンで最新の設定が使用されるように、直ちに再起動することを強く推奨します。再起動していない仮想マシンは以前の設定で動作し、さらに仮想マシンの設定が変更された場合には、保留中のクラスターの互換バージョンが上書きされる場合があります。
手順
- 管理ポータルで → をクリックします。
再起動が必要な仮想マシンを確認します。Vms: 検索バーに以下のクエリーを入力します。
next_run_config_exists=True
next_run_config_exists=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 検索結果に、変更が保留中の仮想マシンがすべて表示されます。
- それぞれの仮想マシンを選択し、再起動 をクリックします。あるいは、必要な場合は、仮想マシン自体から仮想マシンを再起動することができます。
仮想マシンが起動すると、新しい互換バージョンが自動的に適用されます。
プレビュー状態にある仮想マシンスナップショットについては、クラスターの互換バージョンを変更することができません。まずコミットするか、プレビューを取り消す必要があります。
1.2.11. データセンターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization データセンターには、互換バージョンがあります。互換バージョンとは、データセンターが互換性を持つ Red Hat Virtualization のバージョンを指します。データセンター内のクラスターは、すべて指定の互換性レベルをサポートする必要があります。
前提条件
- データセンターの互換レベルを変更するには、事前にデータセンター内のクラスターおよび仮想マシンの互換バージョンがすべて更新されている必要があります。
手順
- 管理ポータルで → をクリックします。
- 変更を行うデータセンターを選択し、 をクリックします。
- 互換バージョン を必要な値に変更します。
- をクリックします。データセンターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
以前に SHA-1 証明書を SHA-256 証明書に置き換えずに 4.2 にアップグレードした場合は、ここで置き換える必要があります。
1.2.12. SHA-1 証明書の SHA-256 証明書への置き換え リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization 4.4 では SHA-256 署名が使用され、SHA-1 よりセキュアに SSL 証明書に署名することができます。新たにインストールしたシステムでは、Red Hat Virtualization の公開鍵インフラストラクチャー (PKI) が SHA-256 署名を使用できるようにするための特別な手順は必要ありません。
証明書の有効期限が 切れない ようにしてください。有効期限が切れると、環境は応答しなくなり、復元でエラーが発生しやすくなり、時間がかかるプロセスになります。証明書の更新は、Administration Guide の Renewing certificates before they expire を参照してください。
ブラウザーでの警告メッセージ表示の防止
- Manager マシンに root ユーザーとしてログインします。
/etc/pki/ovirt-engine/openssl.conf に
default_md = sha256の行が含まれているかどうかを確認します。cat /etc/pki/ovirt-engine/openssl.conf
# cat /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow まだ
default_md = sha1が含まれており、既存の設定をバックアップし、デフォルトをsha256に変更します。cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.conf
# cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" # sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow 署名し直す必要のある証明書を定義します。
names="apache"
# names="apache"Copy to Clipboard Copied! Toggle word wrap Toggle overflow セルフホストエンジンノードのいずれかにログインして、グローバルメンテナンスを有効にします。
hosted-engine --set-maintenance --mode=global
# hosted-engine --set-maintenance --mode=globalCopy to Clipboard Copied! Toggle word wrap Toggle overflow Manager で、
/etc/ovirt-engine/engine.conf.dディレクトリーと/etc/pki/ovirt-engineディレクトリーのバックアップを保存し、証明書を再署名します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - このパスワード値を変更しないでください。
httpd サービスを再起動します。
systemctl restart httpd
# systemctl restart httpdCopy to Clipboard Copied! Toggle word wrap Toggle overflow セルフホストエンジンノードのいずれかにログインして、グローバルメンテナンスを無効にします。
hosted-engine --set-maintenance --mode=none
# hosted-engine --set-maintenance --mode=noneCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルに接続して、警告が表示されなくなったことを確認します。
-
以前に CA または https 証明書をブラウザーにインポートしている場合は、その証明書を探してブラウザーから削除し、新しい CA 証明書をインポートし直します。ブラウザーから提供される手順に従って、認証局の証明書をインストールしてください。認証局の証明書を取得するには、
http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CAに移動し、your-manager-fqdn を完全修飾ドメイン名 (FQDN) に置き換えます。
すべての署名済み証明書を SHA-256 に置き換える
- Manager マシンに root ユーザーとしてログインします。
/etc/pki/ovirt-engine/openssl.conf に
default_md = sha256の行が含まれているかどうかを確認します。cat /etc/pki/ovirt-engine/openssl.conf
# cat /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow まだ
default_md = sha1が含まれており、既存の設定をバックアップし、デフォルトをsha256に変更します。cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.conf
# cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" # sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow CA 証明書のバックアップを作成して ca.pem.new に新しい証明書を作成し、CA 証明書を署名し直します。
cp -p /etc/pki/ovirt-engine/private/ca.pem /etc/pki/ovirt-engine/private/ca.pem."$(date +"%Y%m%d%H%M%S")" openssl x509 -signkey /etc/pki/ovirt-engine/private/ca.pem -in /etc/pki/ovirt-engine/ca.pem -out /etc/pki/ovirt-engine/ca.pem.new -days 3650 -sha256
# cp -p /etc/pki/ovirt-engine/private/ca.pem /etc/pki/ovirt-engine/private/ca.pem."$(date +"%Y%m%d%H%M%S")" # openssl x509 -signkey /etc/pki/ovirt-engine/private/ca.pem -in /etc/pki/ovirt-engine/ca.pem -out /etc/pki/ovirt-engine/ca.pem.new -days 3650 -sha256Copy to Clipboard Copied! Toggle word wrap Toggle overflow 既存の証明書を新しい証明書に置き換えます。
mv /etc/pki/ovirt-engine/ca.pem.new /etc/pki/ovirt-engine/ca.pem
# mv /etc/pki/ovirt-engine/ca.pem.new /etc/pki/ovirt-engine/ca.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 署名し直す必要のある証明書を定義します。
names="engine apache websocket-proxy jboss imageio-proxy"
# names="engine apache websocket-proxy jboss imageio-proxy"Copy to Clipboard Copied! Toggle word wrap Toggle overflow アップグレード後に Red Hat Virtualization Manager SSL 証明書を置き換えている場合は、上記のコマンドの代わりに以下のコマンドを実行します。
names="engine websocket-proxy jboss imageio-proxy"
# names="engine websocket-proxy jboss imageio-proxy"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細は、Administration Guide の Replacing the Red Hat Virtualization Manager CA Certificate を参照してください。
セルフホストエンジンノードのいずれかにログインして、グローバルメンテナンスを有効にします。
hosted-engine --set-maintenance --mode=global
# hosted-engine --set-maintenance --mode=globalCopy to Clipboard Copied! Toggle word wrap Toggle overflow Manager で、
/etc/ovirt-engine/engine.conf.dディレクトリーと/etc/pki/ovirt-engineディレクトリーのバックアップを保存し、証明書を再署名します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - このパスワード値を変更しないでください。
以下のサービスを再起動します。
systemctl restart httpd systemctl restart ovirt-engine systemctl restart ovirt-websocket-proxy systemctl restart ovirt-imageio
# systemctl restart httpd # systemctl restart ovirt-engine # systemctl restart ovirt-websocket-proxy # systemctl restart ovirt-imageioCopy to Clipboard Copied! Toggle word wrap Toggle overflow セルフホストエンジンノードのいずれかにログインして、グローバルメンテナンスを無効にします。
hosted-engine --set-maintenance --mode=none
# hosted-engine --set-maintenance --mode=noneCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルに接続して、警告が表示されなくなったことを確認します。
-
以前に CA または https 証明書をブラウザーにインポートしている場合は、その証明書を探してブラウザーから削除し、新しい CA 証明書をインポートし直します。ブラウザーから提供される手順に従って、認証局の証明書をインストールしてください。認証局の証明書を取得するには、
http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CAに移動し、your-manager-fqdn を完全修飾ドメイン名 (FQDN) に置き換えます。 ホストで証明書を登録します。それぞれのホストについて以下の手順を繰り返します。
- 管理ポータルで → をクリックします。
- ホストを選択し、 → をクリックしてから をクリックします。
- ホストがメンテナンスモードに変わったら、 → をクリックします。
- → をクリックします。
第2章 スタンドアロンの Manager ローカルデータベース環境のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
2.1. Red Hat Virtualization 4.3 から 4.4 へのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
お使いの環境を 4.3 から 4.4 にアップグレードするステップは、以下のとおりです。
アップグレードに関する考慮事項
- アップグレードを計画する場合は、Red Hat Virtualization 4.4 のアップグレードに関する考慮事項および既知の問題 を参照してください。
Open Virtual Network (OVN) および Open vSwitch (OvS) 2.11 から OVN 2021 および OvS 2.15 にアップグレードする場合、以下の条件が満たされている限り、このプロセスはユーザーからは見えません。
- Manager が最初にアップグレードされている。
- OVN/OvS バージョン 2.11 のホスト間で機能することが予想されるすべての OVN ネットワークに対して、ホストのアップグレード前に ovirt-provider-ovn セキュリティーグループを無効にしている。
- ホストは、OVN バージョン 2021 以降および OvS バージョン 2.15 になるようにアップグレードされる。OVN を適切に再設定し、証明書を更新することができるように、管理ポータルでこの手順を完了する必要があります。
- ホストがアップグレード後に再起動される。
プロバイダーと OVN がホストで正常に設定されたかどうかを確認するには、ホストの General タブで OVN configured フラグを確認します。OVN Configured が No に設定されている場合は、 → をクリックします。この設定は、REST API でも利用可能です。機能の更新に失敗した場合は、Manager 4.4 以降からホストを再インストールして OVN を設定できます。
- 正しいリポジトリーを有効にするなど、前提条件を満たしていることを確認する
- Log Collection Analysis ツールおよび Image Discrepancies ツールを使用して、アップグレードの正常な完了を妨げる問題がないか確認する
- 4.3 Manager を最新バージョンの 4.3 に更新する
- Manager を 4.3 から 4.4 にアップグレードする
- 仮想マシンのダウンタイムを削減しつつ、ホストおよび仮想マシンを移行する
- (オプション) ローカルストレージを保持した状態で RHVH をアップグレードする
- クラスターの互換バージョンを更新する
- 実行中またはサスペンド中の仮想マシンをすべて再起動して、設定を更新する
- データセンターの互換バージョンを更新する
2.1.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンで必要となるダウンタイムについて計画されていること。アップグレードプロセスでクラスターの互換バージョンを更新した後、それぞれの仮想マシンを再起動すると新しいハードウェア設定が自動的に適用されます。すべての実行中またはサスペンド中の仮想マシンを直ちに再起動して、設定変更を適用する必要があります。
- お使いの環境が Red Hat Virtualization 4.4 の要件を満たしていること。すべての前提条件の一覧は、Planning and Prerequisites Guide の Requirements を参照してください。
- Red Hat Virtualization Manager をアップグレードする場合には、既存ホストのいずれかを使用することが推奨されます。新規ホストの使用を選択する場合は、アップグレード手順を開始する前に、新規ホストに一意の名前を割り当ててから、既存のクラスターに追加する必要があります。
2.1.2. 環境の分析 リンクのコピーリンクがクリップボードにコピーされました!
更新の実行やトラブルシューティングを行う前に、Log Collection Analysis ツールおよび Image Discrepancies ツールを実行することが推奨されます。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。
2.1.3. ログコレクション分析ツール リンクのコピーリンクがクリップボードにコピーされました!
更新の実行前に Log Collection Analysis ツールを実行し、トラブルシューティングを行います。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。ツールはシステムに関する詳細情報を収集し、それを HTML ファイルとして提示します。
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.3 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンに Log Collection Analysis ツールをインストールします。
yum install rhv-log-collector-analyzer
# yum install rhv-log-collector-analyzerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ツールを実行します。
rhv-log-collector-analyzer --live
# rhv-log-collector-analyzer --liveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細なレポートが表示されます。
デフォルトでは、レポートは
analyzer_report.htmlという名前のフィアルに保存されます。ファイルを特定の場所に保存するには
--htmlフラグを使用して場所を指定します。rhv-log-collector-analyzer --live --html=/directory/filename.html
# rhv-log-collector-analyzer --live --html=/directory/filename.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELinks テキストモードの Web ブラウザーを使用して、ターミナル内のアナライザーレポートを読み取ることができます。ELinks ブラウザーをインストールするには、以下を実行します。
yum install -y elinks
# yum install -y elinksCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELink を起動し、
analyzer_report.htmlを開きます。elinks /home/user1/analyzer_report.html
# elinks /home/user1/analyzer_report.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow レポート内を移動するには、ELinks で以下のコマンドを使用します。
-
Insertでスクロールアップ -
Deleteでスクロールダウン -
PageUpでページアップ -
PageDownでページダウン -
left Bracketで左にスクロール -
right Bracketで右にスクロール
-
2.1.3.1. イメージ不一致ツールを使用したスナップショットの状態の監視 リンクのコピーリンクがクリップボードにコピーされました!
RHV Image Discrepancies ツールは、ストレージドメインと RHV データベースのイメージデータを分析します。ボリュームとボリューム属性に不一致が見つかった場合は警告しますが、それらの不一致は修正されません。このツールは、次のようなさまざまなシナリオで使用します。
- バージョンをアップグレードする前に、壊れたボリュームまたはチェーンを新しいバージョンに持ち越さないようにします。
- 失敗したストレージ操作に続いて、不良状態のボリュームまたは属性を検出します。
- バックアップから RHV データベースまたはストレージを復元した後。
- 定期的に、問題が悪化する前に潜在的な問題を検出します。
- スナップショットまたはライブストレージの移行に関連する問題を分析し、これらのタイプの問題を修正した後、システムの状態を確認します。
前提条件
-
必要なバージョン: このツールは、
rhv-log-collector-analyzer-0.2.15-0.el7evの RHV バージョン 4.3.8 で導入されました。 - データ収集は異なる場所で同時に実行され、アトミックではないため、ストレージドメインを変更する可能性のある環境内のすべてのアクティビティーを停止します。つまり、スナップショットを作成または削除したり、ディスクを編集、移動、作成、または削除したりしないでください。そうしないと、不整合が誤って検出される可能性があります。プロセス中、仮想マシンは正常に実行されたままになります。
手順
ツールを実行するには、RHV Manager で次のコマンドを入力します。
rhv-image-discrepancies
# rhv-image-discrepanciesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ツールが不一致を見つけた場合、特にツールの実行中に一部の操作が実行された可能性がある場合は、ツールを再実行して結果を確認します。
このツールには Export および ISO ストレージドメインが含まれており、そのストレージドメインの不一致を報告する可能性があります。その場合、これらのストレージドメインには RHV データベースにイメージのエントリーがないため、無視することができます。
結果について
このツールは次のことを報告します。
- ストレージに表示されているがデータベースにはないボリュームがある場合、またはデータベースには表示されているがストレージにはないボリュームがある場合。
- 一部のボリューム属性がストレージとデータベースで異なる場合。
出力サンプル
次に、Manager を最新バージョンの 4.3 に更新してください。
2.1.4. Red Hat Virtualization Manager の更新 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.3 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンで、更新されたパッケージが利用可能かどうかを確認します。
engine-upgrade-check
# engine-upgrade-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupスクリプトで Red Hat Virtualization Manager を更新します。engine-setupスクリプトにより、設定に関する質問への回答が求められます。その後、ovirt-engineサービスの停止、更新パッケージのダウンロード/インストール、データベースのバックアップ/更新、インストール後設定の実施を経てから、ovirt-engineサービスが起動します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記engine-setupスクリプトは、Red Hat Virtualization Manager のインストールプロセス中にも使用され、指定した設定値が保存されます。更新時に、設定のプレビュー時に保存された値が表示され、engine-configがインストール後に設定の更新に使用される場合は最新ではない可能性があります。たとえば、インストール後にengine-configを使用してSANWipeAfterDeleteをtrueへと更新した場合、engine-setupは設定プレビューに Default SAN wipe after delete: False と出力します。ただし、更新された値はengine-setupによって上書きされることはありません。重要更新プロセスに時間がかかる場合があります。完了する前にプロセスを停止しないでください。
Manager にインストールされているベースオペレーティングシステムと、オプションパッケージを更新します。
yum update --nobest
# yum update --nobestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動して更新を完了してください。
次に、Manager を 4.4 にアップグレードしてください。
2.1.5. Red Hat Virtualization Manager 4.3 から 4.4 へのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization Manager 4.4 は、Red Hat Enterprise Linux バージョン 8.2 から 8.6 でのみサポートされます。RHV Manager 4.3 の実行に使用する物理マシンと同じマシンを使用する場合でも、Red Hat Enterprise Linux 8.6 および Red Hat Virtualization Manager 4.4 のクリーンインストールを実行する必要があります。
アップグレードプロセスでは、Red Hat Virtualization Manager 4.3 バックアップファイルを Red Hat Virtualization Manager 4.4 マシンに復元する必要があります。
前提条件
- 環境内のすべてのデータセンターおよびクラスターにおいて、クラスターの互換レベルがバージョン 4.2 または 4.3 に設定されていること。
- 環境のすべての仮想マシンでは、クラスターの互換レベルがバージョン 4.3 に設定されている必要があります。
- 外部 CA を使用して HTTPS 証明書に署名する場合は、Administration Guide の Replacing the Red Hat Virtualization Manager CA Certificate の手順に従うこと。バックアップおよび復元にはサードパーティーの証明書が含まれるので、アップグレード後に管理ポータルにログインできるはずです。virt-viewer の外部メニューが機能するように、CA 証明書がすべてのクライアントのシステム全体のトラストストアに追加されていることを確認します。詳細は、BZ#1313379 を参照してください。
接続されたホストと仮想マシンは、Manager のアップグレード中も引き続き動作可能です。
手順
- Manager マシンにログインします。
Red Hat Virtualization Manager 4.3 環境のバックアップを作成します。
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log
# engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow - バックアップファイルを RHV 環境外のストレージデバイスにコピーします。
- Red Hat Enterprise Linux 8.6 をインストールします。詳細は、標準的な RHEL インストールの実行 を参照してください。
-
コマンド
yum install rhvmの実行など、Red Hat Virtualization Manager 4.4 のインストール手順を完了します (engine-setupは実行しないでください)。詳細は、Red Hat Virtualization のインストール ガイドのいずれかを参照してください。 バックアップファイルを Red Hat Virtualization Manager 4.4 マシンにコピーし、復元します。
engine-backup --mode=restore --file=backup.bck --provision-all-databases
# engine-backup --mode=restore --file=backup.bck --provision-all-databasesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記バックアップに追加のデータベースユーザーへの権限付与が含まれていた場合、このコマンドにより、無作為にパスワードが設定された追加のユーザーが作成されます。追加のユーザーが復元したシステムにアクセスする必要がある場合は、これらのパスワードを手動で変更する必要があります。https://access.redhat.com/articles/2686731 を参照してください。
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.4 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
オプションの拡張機能パッケージが Red Hat Virtualization Manager 4.3 マシンにインストールされていた場合はインストールします。
yum install ovirt-engine-extension-aaa-ldap ovirt-engine-extension-aaa-misc
# yum install ovirt-engine-extension-aaa-ldap ovirt-engine-extension-aaa-miscCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ovirt-engine-extension-aaa-ldapは非推奨になりました。新規インストールの場合は、Red Hat Single Sign On を使用します。詳細は、管理ガイド の Red Hat Single Sign-On のインストールおよび設定 を参照してください。注記バックアップおよび復元プロセスの一部として移行されないため、これらの拡張機能パッケージの設定は手動で再適用する必要があります。
engine-setupコマンドを実行して Manager を設定します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat Virtualization Manager 4.4 に別のマシンを使用している場合は、Red Hat Virtualization Manager 4.3 マシンを廃止します。2 つの異なる Manager が同じホストまたはストレージを管理することはできません。
engine-setupを実行して Manager を設定します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスターの互換バージョンが、既存のバージョンに応じて 4.2 または 4.3 に設定されている状態で、Red Hat Virtualization Manager 4.4 がインストールされるようになりました。続いて、環境内のホストを RHV 4.4 にアップグレードする必要があります。その後、クラスターの互換バージョンを 4.4 に変更することができます。
追加のリソース
次に、ホストを更新してください。
2.1.6. ホストおよび仮想マシンの RHV 4.3 から 4.4 への移行 リンクのコピーリンクがクリップボードにコピーされました!
ホストおよび仮想マシンを Red Hat Virtualization 4.3 から 4.4 に移行し、環境内の仮想マシンのダウンタイムを最小限に抑えることができます。
このプロセスでは、すべての仮想マシンを 1 つのホストから移行する必要があります。これにより、そのホストが RHV 4.4 にアップグレードできるようにします。アップグレード後に、ホストを Manager に再度アタッチすることができます。
ホストのオペレーティングシステムのインストールまたは再インストールを行う場合、Red Hat では、ホストにアタッチされている既存の OS 以外のストレージを最初にデタッチすることを強く推奨しています。これは、ディスクを誤って初期化してデータが失われる可能性を避けるためです。
CPU パススルー仮想マシンは、RHV 4.3 から RHV 4.4 に適切に移行しない可能性があります。
RHV 4.3 および RHV 4.4 は、それぞれ RHEL 7 および RHEL 8 をベースにしています。これには、CPU フラグおよびコンストラクターが異なるカーネルバージョンがあります。これにより、CPU パススルーの仮想マシンの移行で問題が発生する可能性があります。
前提条件
- RHV 4.4 のホストには、Red Hat Enterprise Linux バージョン 8.2 から 8.6 が必要です。RHV 4.3 のホストの実行に使用する物理マシンと同じものを使用している場合でも、Red Hat Enterprise Linux 8.6 以降または Red Hat Virtualization Host 4.4 のクリーンインストールが必要です。
- Red Hat Virtualization Manager 4.4 がインストールされ、実行中である。
- ホストが属するデータセンターおよびクラスターの互換性レベルが 4.2 または 4.3 に設定されていること。手順の開始前に、環境内のすべてのデータセンターおよびクラスターにおいて、クラスターの互換レベルがバージョン 4.2 または 4.3 に設定されていること。
手順
- アップグレードするホストを選択し、そのホストの仮想マシンを同じクラスター内の別のホストに移行します。ライブマイグレーションを使用して、仮想マシンのダウンタイムを最小限に抑えることができます。詳細は、仮想マシン管理ガイド の ホスト間での仮想マシンの移行 を参照してください。
- ホストをメンテナンスモードにし、Manager からホストを削除します。詳細は、Administration Guide の Removing a Host を参照してください。
- Red Hat Enterprise Linux 8.6 または RHVH 4.4 をインストールします。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization 用ホストのインストール を参照してください。
- 適切なパッケージをインストールして、RHV 4.4 のホストを有効にします。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization 用ホストのインストール を参照してください。
- このホストを Manager に追加し、これを同じクラスターに割り当てます。次に、仮想マシンをこのホストに移行してください。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization Manager への通常のホストの追加 を参照してください。
これらのステップを繰り返して仮想マシンを移行し、同じクラスター内の残りのホストを 1 つずつアップグレードします。すべてが Red Hat Virtualization 4.4 を実行するまでこれを続けます。
2.1.7. ローカルストレージを保持した状態での RHVH のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
ローカルストレージが他のストレージドメインと共有されないため、ローカルストレージを使用する環境は、別のクラスターのホストに仮想マシンを移行できません。ローカルストレージドメインを持つ RHVH 4.3 ホストをアップグレードには、ローカルストレージを保持しながらホストを再インストールし、4.4 環境で新しいローカルストレージドメインを作成してから、以前のローカルストレージを新しいドメインにインポートします。
前提条件
- Red Hat Virtualization Manager 4.4 がインストールされ、実行中である。
- ホストが属するデータセンターおよびクラスターの互換レベルが、4.2 または 4.3 に設定されていること。
手順
このプロセスを開始する前に、RHVH 4.3 ホストのローカルストレージ上のローカルストレージがメンテナンスモードにあることを確認します。以下のステップを実行します。
- データセンター タブを開きます。
- 詳細 ペインの ストレージ タブをクリックし、結果一覧でストレージドメインを選択します。
- メンテナンス をクリックします。
インストールガイド の Red Hat Virtualization Host のインストール に記載されているとおりに、Red Hat Virtualization Host を再インストールします。
重要インストール先 画面で RHVH をインストールするデバイスを選択する場合は、仮想マシンを保存するデバイスを選択しないでください。オペレーティングシステムをインストールするデバイスのみを選択します。
キックスタートを使用してホストをインストールする場合は、キックスタートファイルに以下を追加して、仮想マシンを含むデバイスを保存するようにしてください。ここでの `device` は、適切なデバイスに置き換えてください。
clearpart --all --drives=device
# clearpart --all --drives=deviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow キックスタートの使用方法は、Red Hat Enterprise Linux 8 高度な RHEL インストールの実行 の キックスタートの参照 を参照してください。
再インストールしたホストで、以前の環境を復元するディレクトリー (
/dataなど) を作成します。mkdir /data
# mkdir /dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいディレクトリーに以前のローカルストレージをマウントします。この例では、
/dev/sdX1がローカルストレージになります。mount /dev/sdX1 /data
# mount /dev/sdX1 /dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいディレクトリーに以下のパーミッションを設定します。
chown -R 36:36 /data chmod -R 0755 /data
# chown -R 36:36 /data # chmod -R 0755 /dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat では、サーバーの再起動が必要となる場合に備えて、
/etc/fstab経由でローカルストレージを自動的にマウントすることも推奨します。blkid | grep -i sdX1 vi /etc/fstab
# blkid | grep -i sdX1 /dev/sdX1: UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" TYPE="ext4" # vi /etc/fstab UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" /data ext4 defaults 0 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルでデータセンターを作成し、ストレージタイプ ドロップダウンメニューで ローカル を選択します。
- 新しいデータセンターでクラスターを設定します。詳細は、Administration Guide の Creating a New Cluster を参照してください。
- Manager にホストを追加します。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization Manager への通常のホストの追加 を参照してください。
ホスト上で、最初のローカルストレージドメインの作成に使用する新しいディレクトリーを作成します。たとえば、以下のような設定です。
mkdir -p /localfs chown 36:36 /localfs chmod -R 0755 /localfs
# mkdir -p /localfs # chown 36:36 /localfs # chmod -R 0755 /localfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルで ストレージ タブを開き、新規ドメイン をクリックして新しいローカルストレージドメインを作成します。
-
名前を
localfsに設定し、パスを/localfsに設定します。 -
ローカルストレージがアクティブになったら、ドメインのインポート をクリックして、ドメインの詳細を設定します。たとえば、
Dataを名前として、Local on Hostをストレージタイプとして、/dataをパスとして定義します。 - ストレージドメインがデータセンターにすでにアタッチされていることを知らせるメッセージが表示されるので、 をクリックして確定します。
新しいストレージドメインをアクティブ化します。
- データセンター タブを開きます。
- 詳細ペインの ストレージ タブをクリックし、結果一覧で新しいデータストレージドメインを選択します。
- アクティブ化 クリックします。
新規ストレージドメインがアクティブになったら、仮想マシンとそのディスクをインポートします。
- ストレージ タブで、データ を選択します。
- 詳細ペインで 仮想マシンのインポート タブを選択し、仮想マシンを選択して インポート をクリックします。詳細は、仮想マシン管理ガイド の データドメインからの仮想マシンのインポート を参照してください。
-
すべての仮想マシンが正常にインポートされ、適切に機能していることを確認したら、
localfsをメンテナンスモードに移行できます。 ストレージ タブをクリックし、結果一覧で localfs を選択します。
- 詳細ペインの データセンター タブをクリックします。
- メンテナンスをクリックしてから をクリックし、ストレージドメインをメンテナンスモードに移動します。
- デタッチ をクリックします。デタッチストレージの確認ウィンドウが開きます。
- をクリックします。
これで、ホストのバージョン 4.4 へのアップグレード、新しいローカルストレージドメインの作成、4.3 ストレージドメインおよびその仮想マシンのインポートが完了しました。
2.1.8. Gluster ストレージを保持した状態での RHVH のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
Gluster をストレージとする環境では、Gluster ストレージのバックアップを取得し、RHVH のアップグレード後に復元することができます。アップグレードに必要な時間を短縮するため、Gluster ストレージを使用するすべての仮想マシンのワークロードを可能な限り軽量に維持してみてください。書き込み集約型のワークロードが非常に多い場合には、復元にかかる時間が長くなります。
GlusterFS Storage は非推奨になり、将来のリリースではサポートされなくなります。
前提条件
- ストレージドメインに geo レプリケーションスケジュールがある場合は、アップグレードの競合を回避するためにこれらのスケジュールを削除します。
- 現在、geo レプリケーション同期は実行されていません。
- 新しい RHVH 4.4 Manager デプロイメント用に新規ボリュームを作成するために、3 つのホストで追加の 100 GB のディスク領域が必要です。
- 手順を開始する前に、環境内のすべてのデータセンターおよびクラスターにはクラスターの互換レベル 4.3 が必要です。
制限
- Network-Bound Disk Encryption (NBDE) は、Red Hat Virtualization 4.4 を使用する新規デプロイメントでのみサポートされます。この機能はアップグレード時に有効にすることはできません。
手順
RHVH 4.4 Manager デプロイメント向けに新しい Gluster ボリュームを作成します。
- 新しい RHVH 4.4 セルフホストエンジンの仮想マシン (VM) 用に各ホストに新しいエンティティーを作成します。
- 設定にスペアディスクがある場合は、Web コンソールからのボリュームの作成を参照してください。
既存のボリュームグループ (VG) に新しい Manager 100 GB の対応のために十分な領域がある場合は、新しい Manager 論理ボリューム (LV) として使用できます。
特に明示的に指定しない限り、すべてのホストで以下のコマンドを実行します。
ボリュームグループ (VG) の空き容量を確認します。
vgdisplay <VG_NAME> | grep -i free
# vgdisplay <VG_NAME> | grep -i freeCopy to Clipboard Copied! Toggle word wrap Toggle overflow この VG に論理ボリュームを 1 つ以上作成します。
lvcreate -n gluster_lv_newengine -L 100G <EXISTING_VG>
# lvcreate -n gluster_lv_newengine -L 100G <EXISTING_VG>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しい論理ボリューム (LV) を XFS としてフォーマットします。
mkfs.xfs <LV_NAME>
# mkfs.xfs <LV_NAME>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいブリックのマウントポイントを作成します。
mkdir /gluster_bricks/newengine
# mkdir /gluster_bricks/newengineCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
/etc/fstabで新たに作成されたファイルシステムに対応するエントリーを作成し、ファイルシステムをマウントします。 ラボマウントポイントに SELinux ラベルを設定します。
semanage fcontext -a -t glusterd_brick_t /gluster_bricks/newengine
# semanage fcontext -a -t glusterd_brick_t /gluster_bricks/newengine restorecon -Rv /gluster_bricks/newengineCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター内のいずれかのホストで gluster コマンドを実行して、新しい gluster ボリュームを作成します。
gluster volume create newengine replica 3 host1:/gluster_bricks/newengine/newengine host2:/gluster_bricks/newengine/newengine host3:/gluster_bricks/newengine/newengine
# gluster volume create newengine replica 3 host1:/gluster_bricks/newengine/newengine host2:/gluster_bricks/newengine/newengine host3:/gluster_bricks/newengine/newengineCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新規作成されたボリュームに必要なボリュームオプションを設定します。クラスター内のいずれかのホストで以下のコマンドを実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新規作成した Gluster ボリュームを起動します。クラスター内のいずれかのホストで以下のコマンドを実行します。
gluster volume start newengine
# gluster volume start newengineCopy to Clipboard Copied! Toggle word wrap Toggle overflow
バックアップ Playbook を使用して、すべての RHVH 4.3 ノードで Gluster 設定をバックアップします。
バックアップ Playbook は RHVH 4.3 の最新バージョンで利用できます。この Playbook が利用できない場合は、Playbook とインベントリーファイルを作成します。
/etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/archive_config.yml
/etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/archive_config.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 正しい詳細でバックアップインベントリーファイルを編集します。
Common variables backup_dir -> Absolute path to directory that contains the extracted contents of the backup archive nbde_setup -> Set to false as the {virt-product-fullname} 4.3 setup doesn’t support NBDE upgrade -> Default value true . This value will make no effect with backupCommon variables backup_dir -> Absolute path to directory that contains the extracted contents of the backup archive nbde_setup -> Set to false as the {virt-product-fullname} 4.3 setup doesn’t support NBDE upgrade -> Default value true . This value will make no effect with backupCopy to Clipboard Copied! Toggle word wrap Toggle overflow ディレクトリーに切り替え、Playbook を実行します。
ansible-playbook -i archive_config_inventory.yml archive_config.yml --tags backupfiles
ansible-playbook -i archive_config_inventory.yml archive_config.yml --tags backupfilesCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
生成されたバックアップ設定 tar ファイルは、
RHVH-<HOSTNAME>-backup.tar.gzという名前の /root の下に生成されます。すべてのホストで、バックアップ設定 tar ファイルをバックアップホストにコピーします。
- Manager Administration Portal を使用して、最初のホストで実行されている仮想マシンをクラスター内の他のホストに移行します。
バックアップマネージャーの設定。
engine-backup --mode=backup --scope=all --file=<backup-file.tar.gz> --log=<logfile>
# engine-backup --mode=backup --scope=all --file=<backup-file.tar.gz> --log=<logfile>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記バックアップを作成する前に、以下の手順を実施します。
- セルフホストエンジン (SHE) の グローバルメンテナンス を有効にします。
- SSH を使用して Manager 仮想マシンにログインし、ovirt-engine サービスを停止します。
- バックアップファイルをセルフホストエンジンの仮想マシンからリモートホストにコピーします。
- Manager をシャットダウンします。
- すべてのレプリカ 3 ボリュームで、保留中の自己修復タスクを確認します。修復が完了するまで待ちます。
ホストのいずれかで以下のコマンドを実行します。
gluster volume heal <volume> info summary
# gluster volume heal <volume> info summaryCopy to Clipboard Copied! Toggle word wrap Toggle overflow glusterfsブリックプロセスを停止し、最初のホストですべてのラボをアンマウントして、ファイルシステムの整合性を維持します。最初のホストで以下を実行します。pkill glusterfsd; pkill glusterfs systemctl stop glusterd umount /gluster_bricks/*
# pkill glusterfsd; pkill glusterfs # systemctl stop glusterd # umount /gluster_bricks/*Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHVH 4.4 ISO でホストを再インストールし、OS ディスクのフォーマットのみを行います。
重要ラボがそれらのディスク上に作成されるため、インストールが他のディスクをフォーマットしないことを確認してください。
RHVH 4.4 のインストール再起動後にノードが稼働したら、インストールガイドで説明されているように RHVH 4.4 リポジトリーにサブスクライブするか、ダウンロードした RHVH 4.4 アプライアンスをインストールします。
yum install <appliance>
# yum install <appliance>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Gluster ブリックに使用されるデバイスを無効にします。
- 新しい SSH 秘密鍵と公開鍵のペアを作成します。
- フロントエンドネットワーク FQDN とバックエンドネットワーク FQDN を使用して、同じホストに SSH 公開鍵認証 (パスワードなし SSH) を確立します。
インベントリーファイルを作成します。
/etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/blacklist_inventory.yml
/etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/blacklist_inventory.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Playbook の実行
ansible-playbook -i blacklist_inventory.yml /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/tasks/gluster_deployment.yml --tags blacklistdevices*
ansible-playbook -i blacklist_inventory.yml /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/tasks/gluster_deployment.yml --tags blacklistdevices*Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- Manager のバックアップおよびホスト設定の tar ファイルをバックアップホストから新たにインストールしたホストにコピーし、scp を使用してコンテンツの展開を解除します。
Gluster 設定ファイルを復元します。
Gluster 設定ファイルの内容を抽出します。
mkdir /archive
# mkdir /archive # tar -xvf /root/ovirt-host-host1.example.com.tar.gz -C /archive/Copy to Clipboard Copied! Toggle word wrap Toggle overflow インベントリーファイルを編集して、設定ファイルの復元を行います。インベントリーファイルは
/etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/archive_config_inventory.ymlにあります。Playbook コンテンツの例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要Use only one host under ‘hosts’ section of restoration playbook.
Use only one host under ‘hosts’ section of restoration playbook.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Playbook を実行して設定ファイルを復元します。
ansible-playbook -i archive_config_inventory.yml archive_config.yml --tags restorefiles
ansible-playbook -i archive_config_inventory.yml archive_config.yml --tags restorefilesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Manager からバックアップアーカイブをポイントする
--restore-from-fileオプションを使用して Manager デプロイメントを実行します。この Manager デプロイメントは、hosted-engine --deployコマンドを使用して対話的に実行でき、新たに作成された Manager ボリュームに対応するストレージを提供します。また、自動化された手順でovirt-ansible-hosted-engine-setupを使用しても同じ操作を行うこともできます。以下の手順は、バックアップを使用して HostedEngine 仮想マシンをデプロイする自動方法です。新たにインストールしたホストに HostedEngine デプロイメントの Playbook を作成します。
/etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/he.yml- name: Deploy oVirt hosted engine hosts: localhost roles: - role: ovirt.hosted_engine_setup- name: Deploy oVirt hosted engine hosts: localhost roles: - role: ovirt.hosted_engine_setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow テンプレートファイルを使用して HostedEngine 関連の情報を更新します。
/etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment/he_gluster_vars.json例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要- 上記の he_gluster_vars.json には、he_restore_from_file および he_storage_domain_path という 2 つの重要な値があります。最初のオプション he_restore_from_file は、ローカルマシンにコピーされた Manager バックアップアーカイブの絶対ファイル名をポイントする必要があります。2 番目のオプション he_storage_domain_path は、新しく作成された Gluster ボリュームを参照しているはずです。
- また、Manager 仮想マシン内で実行されている以前のバージョンの RHVH Version はダウンし、破棄されることに注意してください。古い Manager 仮想マシンに対応する MAC アドレスと FQDN は、新しい Manager 用でも再利用できます。
静的 Manager ネットワーク設定の場合は、以下のようにオプションをさらに追加します。
“he_vm_ip_addr”: “<engine VM ip address>” “he_vm_ip_prefix”: “<engine VM ip prefix>” “he_dns_addr”: “<engine VM DNS server>” “he_default_gateway”: “<engine VM default gateway>”
“he_vm_ip_addr”: “<engine VM ip address>” “he_vm_ip_prefix”: “<engine VM ip prefix>” “he_dns_addr”: “<engine VM DNS server>” “he_default_gateway”: “<engine VM default gateway>”Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要利用可能な特定の DNS がない場合は、he_vm_etc_hosts: true と he_network_test: ping の 2 つのオプションを追加します。
Playbook を実行して HostedEngine Deployment をデプロイします。
cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment ansible-playbook he.yml --extra-vars "@he_gluster_vars.json"
# cd /etc/ansible/roles/gluster.ansible/playbooks/hc-ansible-deployment # ansible-playbook he.yml --extra-vars "@he_gluster_vars.json"Copy to Clipboard Copied! Toggle word wrap Toggle overflow セルフホストエンジンのデプロイメントが完了するまで待ちます。
重要セルフホストエンジンのデプロイメント中に問題が発生した場合は、
/var/log/ovirt-hosted-engine-setupでログメッセージを確認し、問題を修正します。ovirt-hosted-engine-cleanupコマンドを使用して失敗したセルフホストエンジンのデプロイメントをクリーンアップし、デプロイメントを再実行します。
- 新たにインストールした Red Hat Virtualization Manager で RHVH 4.4 管理ポータルにログインします。すべてのホストが up 状態にあることを確認し、Gluster ボリュームでの自己修復が完了するまで待ちます。
次のホストをアップグレードします。
- 管理ポータルから、次のホスト (通常は次のホスト) を Maintenance モードに移動します。このホストをメンテナンスモードに移行している間に Gluster サービスを停止します。
ホストのコマンドラインから Gluster ブリックをアンマウントします。
umount /gluster_bricks/*
# umount /gluster_bricks/*Copy to Clipboard Copied! Toggle word wrap Toggle overflow このホストを RHVH4.4 で再インストールします。
重要ラボがそれらのディスク上に作成されるため、インストールが他のディスクをフォーマットしないことを確認してください。
新たにインストールしたホストでマルチパス設定が利用できない場合は、Gluster デバイスを無効にします。インベントリーファイルは、Gluster ブリックに使用されるデバイスを無効にする手順 の一部として最初のホストにすでに作成されています。
- 最初のホストから新たにインストールしたホストに SSH 公開鍵認証を設定します。
- 新しいホスト名でインベントリーを更新します。
- Playbook を実行します。
- Gluster 設定の tar ファイルをバックアップホストから新規インストールしたホストにコピーし、コンテンツを展開解除します。
このホストで Gluster 設定ファイルを復元する手順で説明されているように Playbook を実行して、新たにインストールされたホストで Gluster 設定を復元します。
重要新たにインストールしたホストで Playbook を編集し、--restore-from-file… オプションを使用して手順 Perform manager deployment で説明されているように実行します。ホスト名を変更し、同じホストで実行しないようにしてください。
RHVH 管理ポータルでホストを再インストールします。RHVH 4.4 で最初にデプロイされたホストから認証キーをコピーします。
scp root@host1.example.com:/root/.ssh/authorized_keys /root/.ssh/
# scp root@host1.example.com:/root/.ssh/authorized_keys /root/.ssh/Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルで は、ホストはメンテナンスに置かれます。 → → → に移動します。
- New Host ダイアログボックスで HostedEngine タブで、deploy self-hosted engine deployment アクションを選択します。
- ホストが Up 状態になるまで待機します。
GFID の不一致に関連するエラーがないことを確認します。エラーがある場合は、解決します。
grep -i "gfid mismatch" /var/log/glusterfs/*
grep -i "gfid mismatch" /var/log/glusterfs/*Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- クラスター内のすべての RHVH について 次のホストをアップグレードします。
- (オプション)クラスター内に別の Gluster 論理ネットワークが存在する場合には、ホストごとにその Gluster 論理ネットワークを必要なインターフェイスにアタッチします。
古い Manager ストレージドメインを削除します。 → の下に一覧表示される、gold の星のない名前 hosted_storage で古い Manager ストレージドメインを特定します 。
- → → → タブに移動し、Maintenance を選択します。
- ストレージドメインがメンテナンスモードに移行するまで待ちます。
- ストレージドメインがメンテナンスモードに移動したら、 をクリックすると、ストレージドメインは 未接続 に移行します。
- 未接続ストレージドメインを選択し、 をクリックして を確定します。
古い Manager ボリュームを停止して削除します。
- → に移動して、古い Manager ボリュームを選択します。 をクリックし、 を確定します。
- 同じボリュームを選択し、 をクリックして を確定します。
クラスターの互換バージョンを更新します。
→ に移動し、クラスターの Default を選択し、 をクリックして Compatibility Version を 4.4 に更新し、 をクリックします。
重要互換バージョンを変更するための警告が表示されます。これには、クラスターの仮想マシンを再起動する必要があります。をクリックして確定します。
RHVH 4.4 で新しい Gluster ボリュームオプションを使用でき、それらのボリュームオプションをすべてのボリュームに適用します。クラスター内のノードの 1 つで以下のコマンドを実行します。
for vol in gluster volume list; do gluster volume set $vol group virt; done
# for vol in gluster volume list; do gluster volume set $vol group virt; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow - アーカイブを削除し、すべてのノードでバックアップ設定ファイルの内容を展開します。
Web コンソールを使用した追加の Gluster ボリュームの作成
- Manager Web コンソールにログインします。
- → に移動し、 をクリックします。
をクリックします。ボリュームの作成ウィンドウで、以下の手順を実施します。
-
Hosts タブで、未使用のディスクを持つ 3 つの異なる
ovirt-ng-nodesを選択し、 をクリックします。 - Volumes タブで、作成するボリュームの詳細を指定し、 をクリックします。
- Bricks タブで、ボリュームの作成に使用するディスクの詳細を指定し、 をクリックします。
- Review タブで、生成された設定ファイルで誤った情報を確認します。問題がなければ、 をクリックします。
-
Hosts タブで、未使用のディスクを持つ 3 つの異なる
次に、クラスターの互換バージョンを更新してください。
2.1.9. クラスターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization のクラスターには互換バージョンがあります。クラスターの互換バージョンは、そのクラスター内の全ホストがサポートする Red Hat Virtualization の機能を示します。クラスターの互換バージョンは、そのクラスター内で最も機能性の低いホストオペレーティングシステムのバージョンに応じて設定されます。
前提条件
- クラスターの互換レベルを変更するには、まず、クラスター内の全ホストを更新して、必要な互換性レベルをサポートするレベルにする必要があります。更新が利用可能であることを示すアイコンがホストの横にあるかどうかを確認します。
制限事項
クラスター互換性レベルを 4.6 にアップグレードした後、VirtIO NIC は別のデバイスとして列挙されます。したがって、NIC の再設定が必要になる場合があります。Red Hat は、クラスターをアップグレードする前に、仮想マシンでクラスター互換性レベルを 4.6 に設定し、ネットワーク接続を確認することにより、仮想マシンをテストすることをお勧めします。
仮想マシンのネットワーク接続に失敗した場合は、クラスターをアップグレードする前に、現在のエミュレーションする仮想マシンに一致するカスタムのエミュレーションする仮想マシン (例: 4.5 互換バージョンの場合は pc-q35-rhel8.3.0) で仮想マシンを設定します。
手順
- 管理ポータルで、 → をクリックします。
- 変更を行うクラスターを選択し、 をクリックします。
- 全般 タブで 互換バージョン を必要な値に変更します。
- をクリックします。クラスターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
一部の仮想マシンおよびテンプレートが不適切に設定されていることを警告するエラーメッセージが表示される場合があります。このエラーを修正するには、それぞれの仮想マシンを手動で編集します。仮想マシンの編集 ウィンドウには、修正すべき項目を確認することのできる新たな検証および警告が表示されます。問題が自動的に修正され、仮想マシンの設定を再度保存するだけで十分な場合もあります。それぞれの仮想マシンを編集したら、クラスターの互換バージョンを変更することができます。
次に、クラスター内の仮想マシンのクラスターの互換バージョンを更新してください。
2.1.10. 仮想マシンのクラスター互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの互換バージョンを更新したら、実行中またはサスペンド中のすべての仮想マシンについてクラスターの互換バージョンを更新する必要があります。そのためには、管理ポータルから再起動するか、REST API を使用して、またはゲストオペレーティングシステム内から更新する必要があります。再起動が必要な仮想マシンには、変更が保留されていることを示すアイコン (
) が付きます。
別途適切な時期に仮想マシンを再起動することもできますが、仮想マシンで最新の設定が使用されるように、直ちに再起動することを強く推奨します。再起動していない仮想マシンは以前の設定で動作し、さらに仮想マシンの設定が変更された場合には、保留中のクラスターの互換バージョンが上書きされる場合があります。
手順
- 管理ポータルで → をクリックします。
再起動が必要な仮想マシンを確認します。Vms: 検索バーに以下のクエリーを入力します。
next_run_config_exists=True
next_run_config_exists=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 検索結果に、変更が保留中の仮想マシンがすべて表示されます。
- それぞれの仮想マシンを選択し、再起動 をクリックします。あるいは、必要な場合は、仮想マシン自体から仮想マシンを再起動することができます。
仮想マシンが起動すると、新しい互換バージョンが自動的に適用されます。
プレビュー状態にある仮想マシンスナップショットについては、クラスターの互換バージョンを変更することができません。まずコミットするか、プレビューを取り消す必要があります。
次に、データセンターの互換バージョンを更新してください。
2.1.11. データセンターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization データセンターには、互換バージョンがあります。互換バージョンとは、データセンターが互換性を持つ Red Hat Virtualization のバージョンを指します。データセンター内のクラスターは、すべて指定の互換性レベルをサポートする必要があります。
前提条件
- データセンターの互換レベルを変更するには、事前にデータセンター内のクラスターおよび仮想マシンの互換バージョンがすべて更新されている必要があります。
手順
- 管理ポータルで → をクリックします。
- 変更を行うデータセンターを選択し、 をクリックします。
- 互換バージョン を必要な値に変更します。
- をクリックします。データセンターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
2.2. Red Hat Virtualization 4.2 から 4.3 へのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
お使いの環境を 4.2 から 4.3 にアップグレードするステップは、以下のとおりです。
- 正しいリポジトリーを有効にするなど、前提条件を満たしていることを確認する
- Log Collection Analysis ツールおよび Image Discrepancies ツールを使用して、アップグレードの正常な完了を妨げる問題がないか確認する
- 4.2 Manager を最新バージョンの 4.2 に更新する
- Manager を 4.2 から 4.3 にアップグレードする
- ホストを更新する
- クラスターの互換バージョンを更新する
- 実行中またはサスペンド中の仮想マシンをすべて再起動して、設定を更新する
- データセンターの互換バージョンを更新する
- 以前に SHA-1 証明書を SHA-256 証明書に置き換えずに 4.2 にアップグレードした場合は、ここで証明書を置き換える
2.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンで必要となるダウンタイムについて計画されていること。アップグレードプロセスでクラスターの互換バージョンを更新した後、それぞれの仮想マシンを再起動すると新しいハードウェア設定が自動的に適用されます。すべての実行中またはサスペンド中の仮想マシンを直ちに再起動して、設定変更を適用する必要があります。
- お使いの環境が Red Hat Virtualization 4.4 の要件を満たしていること。すべての前提条件の一覧は、Planning and Prerequisites Guide の Requirements を参照してください。
- Red Hat Virtualization Manager をアップグレードする場合には、既存ホストのいずれかを使用することが推奨されます。新規ホストの使用を選択する場合は、アップグレード手順を開始する前に、新規ホストに一意の名前を割り当ててから、既存のクラスターに追加する必要があります。
2.2.2. 環境の分析 リンクのコピーリンクがクリップボードにコピーされました!
更新の実行やトラブルシューティングを行う前に、Log Collection Analysis ツールおよび Image Discrepancies ツールを実行することが推奨されます。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。
2.2.3. ログコレクション分析ツール リンクのコピーリンクがクリップボードにコピーされました!
更新の実行前に Log Collection Analysis ツールを実行し、トラブルシューティングを行います。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。ツールはシステムに関する詳細情報を収集し、それを HTML ファイルとして提示します。
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.2 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンに Log Collection Analysis ツールをインストールします。
yum install rhv-log-collector-analyzer
# yum install rhv-log-collector-analyzerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ツールを実行します。
rhv-log-collector-analyzer --live
# rhv-log-collector-analyzer --liveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細なレポートが表示されます。
デフォルトでは、レポートは
analyzer_report.htmlという名前のフィアルに保存されます。ファイルを特定の場所に保存するには
--htmlフラグを使用して場所を指定します。rhv-log-collector-analyzer --live --html=/directory/filename.html
# rhv-log-collector-analyzer --live --html=/directory/filename.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELinks テキストモードの Web ブラウザーを使用して、ターミナル内のアナライザーレポートを読み取ることができます。ELinks ブラウザーをインストールするには、以下を実行します。
yum install -y elinks
# yum install -y elinksCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELink を起動し、
analyzer_report.htmlを開きます。elinks /home/user1/analyzer_report.html
# elinks /home/user1/analyzer_report.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow レポート内を移動するには、ELinks で以下のコマンドを使用します。
-
Insertでスクロールアップ -
Deleteでスクロールダウン -
PageUpでページアップ -
PageDownでページダウン -
left Bracketで左にスクロール -
right Bracketで右にスクロール
-
2.2.3.1. イメージ不一致ツールを使用したスナップショットの状態の監視 リンクのコピーリンクがクリップボードにコピーされました!
RHV Image Discrepancies ツールは、ストレージドメインと RHV データベースのイメージデータを分析します。ボリュームとボリューム属性に不一致が見つかった場合は警告しますが、それらの不一致は修正されません。このツールは、次のようなさまざまなシナリオで使用します。
- バージョンをアップグレードする前に、壊れたボリュームまたはチェーンを新しいバージョンに持ち越さないようにします。
- 失敗したストレージ操作に続いて、不良状態のボリュームまたは属性を検出します。
- バックアップから RHV データベースまたはストレージを復元した後。
- 定期的に、問題が悪化する前に潜在的な問題を検出します。
- スナップショットまたはライブストレージの移行に関連する問題を分析し、これらのタイプの問題を修正した後、システムの状態を確認します。
前提条件
-
必要なバージョン: このツールは、
rhv-log-collector-analyzer-0.2.15-0.el7evの RHV バージョン 4.3.8 で導入されました。 - データ収集は異なる場所で同時に実行され、アトミックではないため、ストレージドメインを変更する可能性のある環境内のすべてのアクティビティーを停止します。つまり、スナップショットを作成または削除したり、ディスクを編集、移動、作成、または削除したりしないでください。そうしないと、不整合が誤って検出される可能性があります。プロセス中、仮想マシンは正常に実行されたままになります。
手順
ツールを実行するには、RHV Manager で次のコマンドを入力します。
rhv-image-discrepancies
# rhv-image-discrepanciesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ツールが不一致を見つけた場合、特にツールの実行中に一部の操作が実行された可能性がある場合は、ツールを再実行して結果を確認します。
このツールには Export および ISO ストレージドメインが含まれており、そのストレージドメインの不一致を報告する可能性があります。その場合、これらのストレージドメインには RHV データベースにイメージのエントリーがないため、無視することができます。
結果について
このツールは次のことを報告します。
- ストレージに表示されているがデータベースにはないボリュームがある場合、またはデータベースには表示されているがストレージにはないボリュームがある場合。
- 一部のボリューム属性がストレージとデータベースで異なる場合。
出力サンプル
2.2.4. Red Hat Virtualization Manager の更新 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.2 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンで、更新されたパッケージが利用可能かどうかを確認します。
engine-upgrade-check
# engine-upgrade-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupスクリプトで Red Hat Virtualization Manager を更新します。engine-setupスクリプトにより、設定に関する質問への回答が求められます。その後、ovirt-engineサービスの停止、更新パッケージのダウンロード/インストール、データベースのバックアップ/更新、インストール後設定の実施を経てから、ovirt-engineサービスが起動します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記engine-setupスクリプトは、Red Hat Virtualization Manager のインストールプロセス中にも使用され、指定した設定値が保存されます。更新時に、設定のプレビュー時に保存された値が表示され、engine-configがインストール後に設定の更新に使用される場合は最新ではない可能性があります。たとえば、インストール後にengine-configを使用してSANWipeAfterDeleteをtrueへと更新した場合、engine-setupは設定プレビューに Default SAN wipe after delete: False と出力します。ただし、更新された値はengine-setupによって上書きされることはありません。重要更新プロセスに時間がかかる場合があります。完了する前にプロセスを停止しないでください。
Manager にインストールされているベースオペレーティングシステムと、オプションパッケージを更新します。
yum update --nobest
# yum update --nobestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動して更新を完了してください。
2.2.5. Red Hat Virtualization Manager の 4.2 から 4.3 へのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
アップグレードしているマシンにログインする必要があります。
アップグレードに失敗すると、engine-setup コマンドは Red Hat Virtualization Manager のインストールを以前の状態に復元しようとします。このため、アップグレードが完了するまで、以前のバージョンのリポジトリーを削除しないでください。アップグレードに失敗すると、engine-setup スクリプトによりインストールの復元方法を説明します。
手順
Red Hat Virtualization 4.3 のリポジトリーを有効にします。
subscription-manager repos \ --enable=rhel-7-server-rhv-4.3-manager-rpms \ --enable=jb-eap-7.2-for-rhel-7-server-rpms# subscription-manager repos \ --enable=rhel-7-server-rhv-4.3-manager-rpms \ --enable=jb-eap-7.2-for-rhel-7-server-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow その他のリポジトリーはすべて、Red Hat Virtualization リリース全体を通して同じになります。
setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupを実行し、プロンプトに従って Red Hat Virtualization Manager をアップグレードします。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Virtualization 4.2 のリポジトリーを無効にして、このシステムで 4.2 のパッケージが使用されないようにします。
subscription-manager repos \ --disable=rhel-7-server-rhv-4.2-manager-rpms \ --disable=jb-eap-7-for-rhel-7-server-rpms# subscription-manager repos \ --disable=rhel-7-server-rhv-4.2-manager-rpms \ --disable=jb-eap-7-for-rhel-7-server-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow ベースオペレーティングシステムを更新します。
yum update
# yum updateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動してアップグレードを完了してください。
Manager はバージョン 4.3 にアップグレードされました。
次に、ホストを更新してください。
2.2.6. クラスター内の全ホストの更新 リンクのコピーリンクがクリップボードにコピーされました!
ホストを個別に更新するのではなく、クラスター内の全ホストを更新することができます。この手法は、Red Hat Virtualization を新しいバージョンにアップグレードする際に特に役立ちます。更新の自動化に使用する Ansible ロールの詳細は、oVirt クラスターアップグレード を参照してください。
クラスターは一度に 1 つずつ更新します。
制限事項
-
RHVH の更新時には、
/etcおよび/varディレクトリーに変更されたコンテンツのみを保持します。他のパスに含まれる変更されたデータは更新時に上書きされます。 - クラスターの移行が有効化されている場合には、仮想マシンはそのクラスター内の別のホストに自動的に移行されます。
- セルフホスト型エンジン環境では、Manager 用仮想マシンは同一クラスター内のセルフホスト型エンジンノード間でのみ移行が可能です。通常のホストに移行することはできません。
- ホストが属するクラスターには、ホストがメンテナンスを実行するのに十分なメモリーが確保されている必要があります。確保されていないと、仮想マシンの移行がハングして失敗してしまいます。ホストを更新する前に一部またはすべての仮想マシンをシャットダウンしておくと、ホスト更新によるメモリー使用量を低減することができます。
- ホストに固定された仮想マシン (vGPU を使用している仮想マシンなど) を別のホストに移行することはできません。ホストの更新をスキップしない限り、そのホストに固定された仮想マシンは更新中にシャットダウンされます。
手順
- 管理ポータルで → をクリックし、クラスターを選択します。ステータスのアップグレード 列には、クラスターの任意のホストでアップグレードが利用可能かどうかが表示されます。
- アップグレード をクリックします。
- 更新するホストを選択し、次に Next をクリックします。
オプションを設定します。
- 固定された仮想マシンの停止: クラスター内のホストに固定された仮想マシンをシャットダウンします。このオプションは、デフォルトで選択されています。このチェックボックスの選択を解除すると、固定された仮想マシンが動作を続けられるように、それらのホストの更新をスキップすることができます (固定された仮想マシンが重要なサービスまたはプロセスを実行中で、更新中の予期せぬ時にシャットダウンされるのを避けたい場合など)。
-
Upgrade Timeout (Minutes): このオプションで設定した時間内に個々のホストの更新が完了しない場合には、クラスターのアップグレードはタイムアウトで失敗します。デフォルトは
60です。60 分では不十分と思われる大規模なクラスターの場合には、時間を延長することができます。また、ホストの更新が短時間で完了する小規模なクラスターでは、短縮することができます。 - Check Upgrade: アップグレードプロセスを実行する前に、それぞれのホストで更新が利用可能かどうかを確認します。このオプションは、デフォルトでは選択されていません。ただし、Manager がホストの更新を確認する頻度をデフォルトより低く設定している状況などで、最新の更新を確実に含める必要がある場合には、このオプションを選択することができます。
- Reboot After Upgrade: ホストの更新後に、それぞれのホストを再起動します。このオプションは、デフォルトで選択されています。ホストの再起動を必要とする保留中の更新がないことが明らかであれば、このチェックボックスの選択を解除してプロセスを迅速化することができます。
-
Use Maintenance Policy: 更新時のクラスターのスケジューリングポリシーを
cluster_maintenanceに設定します。このオプションはデフォルトで選択されています。したがって、許可される動作は限定的で、仮想マシンは高可用性でない限り起動することができません。更新中も使用を続けたいカスタムのスケジューリングポリシーがある場合には、このチェックボックスの選択を解除することができます。ただし、これにより想定外の結果を招く可能性があります。このオプションを無効にする前に、カスタムのポリシーがクラスターのアップグレード操作に対応していることを確認してください。
- Next をクリックします。
- 影響を受けるホストおよび仮想マシンの概要を確認します。
- アップグレード をクリックします。
以下で、ホスト更新の進捗状況を追跡できます。
- → ビュー (ステータスのアップグレード 列は アップグレード中 と表示される)
- → ビュー
-
通知ドロワー の イベント セクション (
)
仮想マシン移行の進捗を、 → ビューの ステータス 列で個々に追跡することができます。大規模な環境では、特定の仮想マシングループの結果を表示するために、結果を絞り込まなければならない場合があります。
2.2.7. クラスターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization のクラスターには互換バージョンがあります。クラスターの互換バージョンは、そのクラスター内の全ホストがサポートする Red Hat Virtualization の機能を示します。クラスターの互換バージョンは、そのクラスター内で最も機能性の低いホストオペレーティングシステムのバージョンに応じて設定されます。
前提条件
- クラスターの互換レベルを変更するには、まず、クラスター内の全ホストを更新して、必要な互換性レベルをサポートするレベルにする必要があります。更新が利用可能であることを示すアイコンがホストの横にあるかどうかを確認します。
制限事項
クラスター互換性レベルを 4.6 にアップグレードした後、VirtIO NIC は別のデバイスとして列挙されます。したがって、NIC の再設定が必要になる場合があります。Red Hat は、クラスターをアップグレードする前に、仮想マシンでクラスター互換性レベルを 4.6 に設定し、ネットワーク接続を確認することにより、仮想マシンをテストすることをお勧めします。
仮想マシンのネットワーク接続に失敗した場合は、クラスターをアップグレードする前に、現在のエミュレーションする仮想マシンに一致するカスタムのエミュレーションする仮想マシン (例: 4.5 互換バージョンの場合は pc-q35-rhel8.3.0) で仮想マシンを設定します。
手順
- 管理ポータルで、 → をクリックします。
- 変更を行うクラスターを選択し、 をクリックします。
- 全般 タブで 互換バージョン を必要な値に変更します。
- をクリックします。クラスターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
一部の仮想マシンおよびテンプレートが不適切に設定されていることを警告するエラーメッセージが表示される場合があります。このエラーを修正するには、それぞれの仮想マシンを手動で編集します。仮想マシンの編集 ウィンドウには、修正すべき項目を確認することのできる新たな検証および警告が表示されます。問題が自動的に修正され、仮想マシンの設定を再度保存するだけで十分な場合もあります。それぞれの仮想マシンを編集したら、クラスターの互換バージョンを変更することができます。
2.2.8. 仮想マシンのクラスター互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの互換バージョンを更新したら、実行中またはサスペンド中のすべての仮想マシンについてクラスターの互換バージョンを更新する必要があります。そのためには、管理ポータルから再起動するか、REST API を使用して、またはゲストオペレーティングシステム内から更新する必要があります。再起動が必要な仮想マシンには、変更が保留されていることを示すアイコン (
) が付きます。
別途適切な時期に仮想マシンを再起動することもできますが、仮想マシンで最新の設定が使用されるように、直ちに再起動することを強く推奨します。再起動していない仮想マシンは以前の設定で動作し、さらに仮想マシンの設定が変更された場合には、保留中のクラスターの互換バージョンが上書きされる場合があります。
手順
- 管理ポータルで → をクリックします。
再起動が必要な仮想マシンを確認します。Vms: 検索バーに以下のクエリーを入力します。
next_run_config_exists=True
next_run_config_exists=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 検索結果に、変更が保留中の仮想マシンがすべて表示されます。
- それぞれの仮想マシンを選択し、再起動 をクリックします。あるいは、必要な場合は、仮想マシン自体から仮想マシンを再起動することができます。
仮想マシンが起動すると、新しい互換バージョンが自動的に適用されます。
プレビュー状態にある仮想マシンスナップショットについては、クラスターの互換バージョンを変更することができません。まずコミットするか、プレビューを取り消す必要があります。
2.2.9. データセンターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization データセンターには、互換バージョンがあります。互換バージョンとは、データセンターが互換性を持つ Red Hat Virtualization のバージョンを指します。データセンター内のクラスターは、すべて指定の互換性レベルをサポートする必要があります。
前提条件
- データセンターの互換レベルを変更するには、事前にデータセンター内のクラスターおよび仮想マシンの互換バージョンがすべて更新されている必要があります。
手順
- 管理ポータルで → をクリックします。
- 変更を行うデータセンターを選択し、 をクリックします。
- 互換バージョン を必要な値に変更します。
- をクリックします。データセンターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
以前に SHA-1 証明書を SHA-256 証明書に置き換えずに 4.2 にアップグレードした場合は、ここで置き換える必要があります。
2.2.10. SHA-1 証明書の SHA-256 証明書への置き換え リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization 4.4 では SHA-256 署名が使用され、SHA-1 よりセキュアに SSL 証明書に署名することができます。新たにインストールしたシステムでは、Red Hat Virtualization の公開鍵インフラストラクチャー (PKI) が SHA-256 署名を使用できるようにするための特別な手順は必要ありません。
証明書の有効期限が 切れない ようにしてください。有効期限が切れると、環境は応答しなくなり、復元でエラーが発生しやすくなり、時間がかかるプロセスになります。証明書の更新は、Administration Guide の Renewing certificates before they expire を参照してください。
ブラウザーでの警告メッセージ表示の防止
- Manager マシンに root ユーザーとしてログインします。
/etc/pki/ovirt-engine/openssl.conf に
default_md = sha256の行が含まれているかどうかを確認します。cat /etc/pki/ovirt-engine/openssl.conf
# cat /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow まだ
default_md = sha1が含まれており、既存の設定をバックアップし、デフォルトをsha256に変更します。cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.conf
# cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" # sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow 署名し直す必要のある証明書を定義します。
names="apache"
# names="apache"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Manager で、
/etc/ovirt-engine/engine.conf.dディレクトリーと/etc/pki/ovirt-engineディレクトリーのバックアップを保存し、証明書を再署名します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - このパスワード値を変更しないでください。
httpd サービスを再起動します。
systemctl restart httpd
# systemctl restart httpdCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルに接続して、警告が表示されなくなったことを確認します。
-
以前に CA または https 証明書をブラウザーにインポートしている場合は、その証明書を探してブラウザーから削除し、新しい CA 証明書をインポートし直します。ブラウザーから提供される手順に従って、認証局の証明書をインストールしてください。認証局の証明書を取得するには、
http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CAに移動し、your-manager-fqdn を完全修飾ドメイン名 (FQDN) に置き換えます。
すべての署名済み証明書を SHA-256 に置き換える
- Manager マシンに root ユーザーとしてログインします。
/etc/pki/ovirt-engine/openssl.conf に
default_md = sha256の行が含まれているかどうかを確認します。cat /etc/pki/ovirt-engine/openssl.conf
# cat /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow まだ
default_md = sha1が含まれており、既存の設定をバックアップし、デフォルトをsha256に変更します。cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.conf
# cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" # sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow CA 証明書のバックアップを作成して ca.pem.new に新しい証明書を作成し、CA 証明書を署名し直します。
cp -p /etc/pki/ovirt-engine/private/ca.pem /etc/pki/ovirt-engine/private/ca.pem."$(date +"%Y%m%d%H%M%S")" openssl x509 -signkey /etc/pki/ovirt-engine/private/ca.pem -in /etc/pki/ovirt-engine/ca.pem -out /etc/pki/ovirt-engine/ca.pem.new -days 3650 -sha256
# cp -p /etc/pki/ovirt-engine/private/ca.pem /etc/pki/ovirt-engine/private/ca.pem."$(date +"%Y%m%d%H%M%S")" # openssl x509 -signkey /etc/pki/ovirt-engine/private/ca.pem -in /etc/pki/ovirt-engine/ca.pem -out /etc/pki/ovirt-engine/ca.pem.new -days 3650 -sha256Copy to Clipboard Copied! Toggle word wrap Toggle overflow 既存の証明書を新しい証明書に置き換えます。
mv /etc/pki/ovirt-engine/ca.pem.new /etc/pki/ovirt-engine/ca.pem
# mv /etc/pki/ovirt-engine/ca.pem.new /etc/pki/ovirt-engine/ca.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 署名し直す必要のある証明書を定義します。
names="engine apache websocket-proxy jboss imageio-proxy"
# names="engine apache websocket-proxy jboss imageio-proxy"Copy to Clipboard Copied! Toggle word wrap Toggle overflow アップグレード後に Red Hat Virtualization Manager SSL 証明書を置き換えている場合は、上記のコマンドの代わりに以下のコマンドを実行します。
names="engine websocket-proxy jboss imageio-proxy"
# names="engine websocket-proxy jboss imageio-proxy"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細は、Administration Guide の Replacing the Red Hat Virtualization Manager CA Certificate を参照してください。
Manager で、
/etc/ovirt-engine/engine.conf.dディレクトリーと/etc/pki/ovirt-engineディレクトリーのバックアップを保存し、証明書を再署名します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - このパスワード値を変更しないでください。
以下のサービスを再起動します。
systemctl restart httpd systemctl restart ovirt-engine systemctl restart ovirt-websocket-proxy systemctl restart ovirt-imageio
# systemctl restart httpd # systemctl restart ovirt-engine # systemctl restart ovirt-websocket-proxy # systemctl restart ovirt-imageioCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルに接続して、警告が表示されなくなったことを確認します。
-
以前に CA または https 証明書をブラウザーにインポートしている場合は、その証明書を探してブラウザーから削除し、新しい CA 証明書をインポートし直します。ブラウザーから提供される手順に従って、認証局の証明書をインストールしてください。認証局の証明書を取得するには、
http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CAに移動し、your-manager-fqdn を完全修飾ドメイン名 (FQDN) に置き換えます。 ホストで証明書を登録します。それぞれのホストについて以下の手順を繰り返します。
- 管理ポータルで → をクリックします。
- ホストを選択し、 → をクリックしてから をクリックします。
- ホストがメンテナンスモードに変わったら、 → をクリックします。
- → をクリックします。
第3章 スタンドアロンの Manager、リモートデータベース環境のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
3.1. Red Hat Virtualization 4.3 から 4.4 へのリモートデータベース環境のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
お使いの環境を 4.3 から 4.4 にアップグレードするステップは、以下のとおりです。
アップグレードに関する考慮事項
- アップグレードを計画する場合は、Red Hat Virtualization 4.4 のアップグレードに関する考慮事項および既知の問題 を参照してください。
Open Virtual Network (OVN) および Open vSwitch (OvS) 2.11 から OVN 2021 および OvS 2.15 にアップグレードする場合、以下の条件が満たされている限り、このプロセスはユーザーからは見えません。
- Manager が最初にアップグレードされている。
- OVN/OvS バージョン 2.11 のホスト間で機能することが予想されるすべての OVN ネットワークに対して、ホストのアップグレード前に ovirt-provider-ovn セキュリティーグループを無効にしている。
- ホストは、OVN バージョン 2021 以降および OvS バージョン 2.15 になるようにアップグレードされる。OVN を適切に再設定し、証明書を更新することができるように、管理ポータルでこの手順を完了する必要があります。
- ホストがアップグレード後に再起動される。
プロバイダーと OVN がホストで正常に設定されたかどうかを確認するには、ホストの General タブで OVN configured フラグを確認します。OVN Configured が No に設定されている場合は、 → をクリックします。この設定は、REST API でも利用可能です。機能の更新に失敗した場合は、Manager 4.4 以降からホストを再インストールして OVN を設定できます。
- 正しいリポジトリーを有効にするなど、前提条件を満たしていることを確認する
- Log Collection Analysis ツールおよび Image Discrepancies ツールを使用して、アップグレードの正常な完了を妨げる問題がないか確認する
- 4.3 Manager を最新バージョンの 4.3 に更新する
- Manager を 4.3 から 4.4 にアップグレードする
- リモート Data Warehouse サービスおよびデータベースをアップグレード
- 仮想マシンのダウンタイムを削減しつつ、ホストおよび仮想マシンを移行
- (オプション) ローカルストレージを保持した状態で RHVH をアップグレードする
- クラスターの互換バージョンを更新する
- 実行中またはサスペンド中の仮想マシンをすべて再起動して、設定を更新する
- データセンターの互換バージョンを更新する
3.1.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンで必要となるダウンタイムについて計画されていること。アップグレードプロセスでクラスターの互換バージョンを更新した後、それぞれの仮想マシンを再起動すると新しいハードウェア設定が自動的に適用されます。すべての実行中またはサスペンド中の仮想マシンを直ちに再起動して、設定変更を適用する必要があります。
- お使いの環境が Red Hat Virtualization 4.4 の要件を満たしていること。すべての前提条件の一覧は、Planning and Prerequisites Guide の Requirements を参照してください。
- Red Hat Virtualization Manager をアップグレードする場合には、既存ホストのいずれかを使用することが推奨されます。新規ホストの使用を選択する場合は、アップグレード手順を開始する前に、新規ホストに一意の名前を割り当ててから、既存のクラスターに追加する必要があります。
3.1.2. 環境の分析 リンクのコピーリンクがクリップボードにコピーされました!
更新の実行やトラブルシューティングを行う前に、Log Collection Analysis ツールおよび Image Discrepancies ツールを実行することが推奨されます。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。
3.1.3. ログコレクション分析ツール リンクのコピーリンクがクリップボードにコピーされました!
更新の実行前に Log Collection Analysis ツールを実行し、トラブルシューティングを行います。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。ツールはシステムに関する詳細情報を収集し、それを HTML ファイルとして提示します。
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.3 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンに Log Collection Analysis ツールをインストールします。
yum install rhv-log-collector-analyzer
# yum install rhv-log-collector-analyzerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ツールを実行します。
rhv-log-collector-analyzer --live
# rhv-log-collector-analyzer --liveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細なレポートが表示されます。
デフォルトでは、レポートは
analyzer_report.htmlという名前のフィアルに保存されます。ファイルを特定の場所に保存するには
--htmlフラグを使用して場所を指定します。rhv-log-collector-analyzer --live --html=/directory/filename.html
# rhv-log-collector-analyzer --live --html=/directory/filename.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELinks テキストモードの Web ブラウザーを使用して、ターミナル内のアナライザーレポートを読み取ることができます。ELinks ブラウザーをインストールするには、以下を実行します。
yum install -y elinks
# yum install -y elinksCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELink を起動し、
analyzer_report.htmlを開きます。elinks /home/user1/analyzer_report.html
# elinks /home/user1/analyzer_report.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow レポート内を移動するには、ELinks で以下のコマンドを使用します。
-
Insertでスクロールアップ -
Deleteでスクロールダウン -
PageUpでページアップ -
PageDownでページダウン -
left Bracketで左にスクロール -
right Bracketで右にスクロール
-
3.1.3.1. イメージ不一致ツールを使用したスナップショットの状態の監視 リンクのコピーリンクがクリップボードにコピーされました!
RHV Image Discrepancies ツールは、ストレージドメインと RHV データベースのイメージデータを分析します。ボリュームとボリューム属性に不一致が見つかった場合は警告しますが、それらの不一致は修正されません。このツールは、次のようなさまざまなシナリオで使用します。
- バージョンをアップグレードする前に、壊れたボリュームまたはチェーンを新しいバージョンに持ち越さないようにします。
- 失敗したストレージ操作に続いて、不良状態のボリュームまたは属性を検出します。
- バックアップから RHV データベースまたはストレージを復元した後。
- 定期的に、問題が悪化する前に潜在的な問題を検出します。
- スナップショットまたはライブストレージの移行に関連する問題を分析し、これらのタイプの問題を修正した後、システムの状態を確認します。
前提条件
-
必要なバージョン: このツールは、
rhv-log-collector-analyzer-0.2.15-0.el7evの RHV バージョン 4.3.8 で導入されました。 - データ収集は異なる場所で同時に実行され、アトミックではないため、ストレージドメインを変更する可能性のある環境内のすべてのアクティビティーを停止します。つまり、スナップショットを作成または削除したり、ディスクを編集、移動、作成、または削除したりしないでください。そうしないと、不整合が誤って検出される可能性があります。プロセス中、仮想マシンは正常に実行されたままになります。
手順
ツールを実行するには、RHV Manager で次のコマンドを入力します。
rhv-image-discrepancies
# rhv-image-discrepanciesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ツールが不一致を見つけた場合、特にツールの実行中に一部の操作が実行された可能性がある場合は、ツールを再実行して結果を確認します。
このツールには Export および ISO ストレージドメインが含まれており、そのストレージドメインの不一致を報告する可能性があります。その場合、これらのストレージドメインには RHV データベースにイメージのエントリーがないため、無視することができます。
結果について
このツールは次のことを報告します。
- ストレージに表示されているがデータベースにはないボリュームがある場合、またはデータベースには表示されているがストレージにはないボリュームがある場合。
- 一部のボリューム属性がストレージとデータベースで異なる場合。
出力サンプル
次に、Manager を最新バージョンの 4.3 に更新してください。
3.1.4. Red Hat Virtualization Manager の更新 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.3 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンで、更新されたパッケージが利用可能かどうかを確認します。
engine-upgrade-check
# engine-upgrade-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupスクリプトで Red Hat Virtualization Manager を更新します。engine-setupスクリプトにより、設定に関する質問への回答が求められます。その後、ovirt-engineサービスの停止、更新パッケージのダウンロード/インストール、データベースのバックアップ/更新、インストール後設定の実施を経てから、ovirt-engineサービスが起動します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記engine-setupスクリプトは、Red Hat Virtualization Manager のインストールプロセス中にも使用され、指定した設定値が保存されます。更新時に、設定のプレビュー時に保存された値が表示され、engine-configがインストール後に設定の更新に使用される場合は最新ではない可能性があります。たとえば、インストール後にengine-configを使用してSANWipeAfterDeleteをtrueへと更新した場合、engine-setupは設定プレビューに Default SAN wipe after delete: False と出力します。ただし、更新された値はengine-setupによって上書きされることはありません。重要更新プロセスに時間がかかる場合があります。完了する前にプロセスを停止しないでください。
Manager にインストールされているベースオペレーティングシステムと、オプションパッケージを更新します。
yum update --nobest
# yum update --nobestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動して更新を完了してください。
次に、Manager を 4.4 にアップグレードしてください。
3.1.5. Red Hat Virtualization Manager 4.3 から 4.4 へのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization Manager 4.4 は、Red Hat Enterprise Linux バージョン 8.2 から 8.6 でのみサポートされます。RHV Manager 4.3 の実行に使用する物理マシンと同じマシンを使用する場合でも、Red Hat Enterprise Linux 8.6 および Red Hat Virtualization Manager 4.4 のクリーンインストールを実行する必要があります。
アップグレードプロセスでは、Red Hat Virtualization Manager 4.3 バックアップファイルを Red Hat Virtualization Manager 4.4 マシンに復元する必要があります。
前提条件
- 環境内のすべてのデータセンターおよびクラスターにおいて、クラスターの互換レベルがバージョン 4.2 または 4.3 に設定されていること。
- 環境のすべての仮想マシンでは、クラスターの互換レベルがバージョン 4.3 に設定されている必要があります。
- 外部 CA を使用して HTTPS 証明書に署名する場合は、Administration Guide の Replacing the Red Hat Virtualization Manager CA Certificate の手順に従うこと。バックアップおよび復元にはサードパーティーの証明書が含まれるので、アップグレード後に管理ポータルにログインできるはずです。virt-viewer の外部メニューが機能するように、CA 証明書がすべてのクライアントのシステム全体のトラストストアに追加されていることを確認します。詳細は、BZ#1313379 を参照してください。
接続されたホストと仮想マシンは、Manager のアップグレード中も引き続き動作可能です。
手順
- Manager マシンにログインします。
Red Hat Virtualization Manager 4.3 環境のバックアップを作成します。
engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.log
# engine-backup --scope=all --mode=backup --file=backup.bck --log=backuplog.logCopy to Clipboard Copied! Toggle word wrap Toggle overflow - バックアップファイルを RHV 環境外のストレージデバイスにコピーします。
- Red Hat Enterprise Linux 8.6 をインストールします。詳細は、標準的な RHEL インストールの実行 を参照してください。
-
コマンド
yum install rhvmの実行など、Red Hat Virtualization Manager 4.4 のインストール手順を完了します (engine-setupは実行しないでください)。詳細は、Red Hat Virtualization のインストール ガイドのいずれかを参照してください。 バックアップファイルを Red Hat Virtualization Manager 4.4 マシンにコピーし、復元します。
engine-backup --mode=restore --file=backup.bck --provision-all-databases
# engine-backup --mode=restore --file=backup.bck --provision-all-databasesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記バックアップに追加のデータベースユーザーへの権限付与が含まれていた場合、このコマンドにより、無作為にパスワードが設定された追加のユーザーが作成されます。追加のユーザーが復元したシステムにアクセスする必要がある場合は、これらのパスワードを手動で変更する必要があります。https://access.redhat.com/articles/2686731 を参照してください。
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.4 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
オプションの拡張機能パッケージが Red Hat Virtualization Manager 4.3 マシンにインストールされていた場合はインストールします。
yum install ovirt-engine-extension-aaa-ldap ovirt-engine-extension-aaa-misc
# yum install ovirt-engine-extension-aaa-ldap ovirt-engine-extension-aaa-miscCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ovirt-engine-extension-aaa-ldapは非推奨になりました。新規インストールの場合は、Red Hat Single Sign On を使用します。詳細は、管理ガイド の Red Hat Single Sign-On のインストールおよび設定 を参照してください。注記バックアップおよび復元プロセスの一部として移行されないため、これらの拡張機能パッケージの設定は手動で再適用する必要があります。
engine-setupコマンドを実行して Manager を設定します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat Virtualization Manager 4.4 に別のマシンを使用している場合は、Red Hat Virtualization Manager 4.3 マシンを廃止します。2 つの異なる Manager が同じホストまたはストレージを管理することはできません。
クラスターの互換バージョンが、既存のバージョンに応じて 4.2 または 4.3 に設定されている状態で、Red Hat Virtualization Manager 4.4 がインストールされるようになりました。
続いて、環境内のリモートデータベースをアップグレードする必要があります。
engine-setup は、リモートの Data Warehouse マシン上の Data Warehouse サービスも停止します。
この手順の次のステップを延期する場合は、Data Warehouse マシンにログインして Data Warehouse サービスを起動します。
systemctl start ovirt-engine-dwhd.service
# systemctl start ovirt-engine-dwhd.service
3.1.6. リモート Data Warehouse サービスおよびデータベースのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
Data Warehouse サービスおよびデータベースを使用するリモートマシンでこの手順を実行します。
この手順の一部では、Red Hat Enterprise Linux 8.6 または Red Hat Virtualization Host 4.4 をインストールする必要があります。
前提条件
- Data Warehouse マシンにログインしている。
- RHV 環境外のストレージデバイス。
手順
Data Warehouse マシンをバックアップします。
注記Grafana は RHV 4.3 ではサポートされていませんが、RHV 4.4 では、このコマンドに Grafana サービスおよび Grafana データベースも含まれます。
engine-backup --file=<backupfile>
# engine-backup --file=<backupfile>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - バックアップファイルをストレージデバイスにコピーします。
Data Warehouse サービスを停止して無効にします。
systemctl stop ovirt-engine-dwhd systemctl disable ovirt-engine-dwhd
# systemctl stop ovirt-engine-dwhd # systemctl disable ovirt-engine-dwhdCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Red Hat Enterprise Linux 8.6 または Red Hat Virtualization Host 4.4 で Data Warehouse マシンを再インストールします。
- PostgreSQL データベースを準備します。詳細は、Red Hat Virtualization をリモートデータベースが設定されたスタンドアロン Manager としてインストール のリモート PostgreSQL データベースの準備を参照してください。
-
サーバーで正しいリポジトリーを有効にし、Data Warehouse サービスをインストールします。詳細な手順は、Red Hat Virtualization 4.4 の別のマシンへの Data Warehouse のインストールおよび設定 を参照してください。
dnf install ovirt-engine-dwh-setupコマンドおよびこれを含む手順の最大手順を実行します。次に、この手順の次のステップに進みます。 - バックアップファイルをストレージデバイスから Data Warehouse マシンにコピーします。
バックアップファイルを復元します。
engine-backup --mode=restore --file=backup.bck --provision-all-databases
# engine-backup --mode=restore --file=backup.bck --provision-all-databasesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Data Warehouse マシンで
engine-setupコマンドを実行します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow Manager マシンで Manager を再起動して、Data Warehouse データベースに接続します。
systemctl restart ovirt-engine
# systemctl restart ovirt-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次に、ホストを更新してください。
3.1.7. ホストおよび仮想マシンの RHV 4.3 から 4.4 への移行 リンクのコピーリンクがクリップボードにコピーされました!
ホストおよび仮想マシンを Red Hat Virtualization 4.3 から 4.4 に移行し、環境内の仮想マシンのダウンタイムを最小限に抑えることができます。
このプロセスでは、すべての仮想マシンを 1 つのホストから移行する必要があります。これにより、そのホストが RHV 4.4 にアップグレードできるようにします。アップグレード後に、ホストを Manager に再度アタッチすることができます。
ホストのオペレーティングシステムのインストールまたは再インストールを行う場合、Red Hat では、ホストにアタッチされている既存の OS 以外のストレージを最初にデタッチすることを強く推奨しています。これは、ディスクを誤って初期化してデータが失われる可能性を避けるためです。
CPU パススルー仮想マシンは、RHV 4.3 から RHV 4.4 に適切に移行しない可能性があります。
RHV 4.3 および RHV 4.4 は、それぞれ RHEL 7 および RHEL 8 をベースにしています。これには、CPU フラグおよびコンストラクターが異なるカーネルバージョンがあります。これにより、CPU パススルーの仮想マシンの移行で問題が発生する可能性があります。
前提条件
- RHV 4.4 のホストには、Red Hat Enterprise Linux バージョン 8.2 から 8.6 が必要です。RHV 4.3 のホストの実行に使用する物理マシンと同じものを使用している場合でも、Red Hat Enterprise Linux 8.6 以降または Red Hat Virtualization Host 4.4 のクリーンインストールが必要です。
- Red Hat Virtualization Manager 4.4 がインストールされ、実行中である。
- ホストが属するデータセンターおよびクラスターの互換性レベルが 4.2 または 4.3 に設定されていること。手順の開始前に、環境内のすべてのデータセンターおよびクラスターにおいて、クラスターの互換レベルがバージョン 4.2 または 4.3 に設定されていること。
手順
- アップグレードするホストを選択し、そのホストの仮想マシンを同じクラスター内の別のホストに移行します。ライブマイグレーションを使用して、仮想マシンのダウンタイムを最小限に抑えることができます。詳細は、仮想マシン管理ガイド の ホスト間での仮想マシンの移行 を参照してください。
- ホストをメンテナンスモードにし、Manager からホストを削除します。詳細は、Administration Guide の Removing a Host を参照してください。
- Red Hat Enterprise Linux 8.6 または RHVH 4.4 をインストールします。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization 用ホストのインストール を参照してください。
- 適切なパッケージをインストールして、RHV 4.4 のホストを有効にします。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization 用ホストのインストール を参照してください。
- このホストを Manager に追加し、これを同じクラスターに割り当てます。次に、仮想マシンをこのホストに移行してください。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization Manager への通常のホストの追加 を参照してください。
これらのステップを繰り返して仮想マシンを移行し、同じクラスター内の残りのホストを 1 つずつアップグレードします。すべてが Red Hat Virtualization 4.4 を実行するまでこれを続けます。
3.1.8. ローカルストレージを保持した状態での RHVH のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
ローカルストレージが他のストレージドメインと共有されないため、ローカルストレージを使用する環境は、別のクラスターのホストに仮想マシンを移行できません。ローカルストレージドメインを持つ RHVH 4.3 ホストをアップグレードには、ローカルストレージを保持しながらホストを再インストールし、4.4 環境で新しいローカルストレージドメインを作成してから、以前のローカルストレージを新しいドメインにインポートします。
前提条件
- Red Hat Virtualization Manager 4.4 がインストールされ、実行中である。
- ホストが属するデータセンターおよびクラスターの互換レベルが、4.2 または 4.3 に設定されていること。
手順
このプロセスを開始する前に、RHVH 4.3 ホストのローカルストレージ上のローカルストレージがメンテナンスモードにあることを確認します。以下のステップを実行します。
- データセンター タブを開きます。
- 詳細 ペインの ストレージ タブをクリックし、結果一覧でストレージドメインを選択します。
- メンテナンス をクリックします。
インストールガイド の Red Hat Virtualization Host のインストール に記載されているとおりに、Red Hat Virtualization Host を再インストールします。
重要インストール先 画面で RHVH をインストールするデバイスを選択する場合は、仮想マシンを保存するデバイスを選択しないでください。オペレーティングシステムをインストールするデバイスのみを選択します。
キックスタートを使用してホストをインストールする場合は、キックスタートファイルに以下を追加して、仮想マシンを含むデバイスを保存するようにしてください。ここでの `device` は、適切なデバイスに置き換えてください。
clearpart --all --drives=device
# clearpart --all --drives=deviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow キックスタートの使用方法は、Red Hat Enterprise Linux 8 高度な RHEL インストールの実行 の キックスタートの参照 を参照してください。
再インストールしたホストで、以前の環境を復元するディレクトリー (
/dataなど) を作成します。mkdir /data
# mkdir /dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいディレクトリーに以前のローカルストレージをマウントします。この例では、
/dev/sdX1がローカルストレージになります。mount /dev/sdX1 /data
# mount /dev/sdX1 /dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいディレクトリーに以下のパーミッションを設定します。
chown -R 36:36 /data chmod -R 0755 /data
# chown -R 36:36 /data # chmod -R 0755 /dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat では、サーバーの再起動が必要となる場合に備えて、
/etc/fstab経由でローカルストレージを自動的にマウントすることも推奨します。blkid | grep -i sdX1 vi /etc/fstab
# blkid | grep -i sdX1 /dev/sdX1: UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" TYPE="ext4" # vi /etc/fstab UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" /data ext4 defaults 0 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルでデータセンターを作成し、ストレージタイプ ドロップダウンメニューで ローカル を選択します。
- 新しいデータセンターでクラスターを設定します。詳細は、Administration Guide の Creating a New Cluster を参照してください。
- Manager にホストを追加します。詳細は、いずれかの Red Hat Virtualization のインストール ガイドの Red Hat Virtualization Manager への通常のホストの追加 を参照してください。
ホスト上で、最初のローカルストレージドメインの作成に使用する新しいディレクトリーを作成します。たとえば、以下のような設定です。
mkdir -p /localfs chown 36:36 /localfs chmod -R 0755 /localfs
# mkdir -p /localfs # chown 36:36 /localfs # chmod -R 0755 /localfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルで ストレージ タブを開き、新規ドメイン をクリックして新しいローカルストレージドメインを作成します。
-
名前を
localfsに設定し、パスを/localfsに設定します。 -
ローカルストレージがアクティブになったら、ドメインのインポート をクリックして、ドメインの詳細を設定します。たとえば、
Dataを名前として、Local on Hostをストレージタイプとして、/dataをパスとして定義します。 - ストレージドメインがデータセンターにすでにアタッチされていることを知らせるメッセージが表示されるので、 をクリックして確定します。
新しいストレージドメインをアクティブ化します。
- データセンター タブを開きます。
- 詳細ペインの ストレージ タブをクリックし、結果一覧で新しいデータストレージドメインを選択します。
- アクティブ化 クリックします。
新規ストレージドメインがアクティブになったら、仮想マシンとそのディスクをインポートします。
- ストレージ タブで、データ を選択します。
- 詳細ペインで 仮想マシンのインポート タブを選択し、仮想マシンを選択して インポート をクリックします。詳細は、仮想マシン管理ガイド の データドメインからの仮想マシンのインポート を参照してください。
-
すべての仮想マシンが正常にインポートされ、適切に機能していることを確認したら、
localfsをメンテナンスモードに移行できます。 ストレージ タブをクリックし、結果一覧で localfs を選択します。
- 詳細ペインの データセンター タブをクリックします。
- メンテナンスをクリックしてから をクリックし、ストレージドメインをメンテナンスモードに移動します。
- デタッチ をクリックします。デタッチストレージの確認ウィンドウが開きます。
- をクリックします。
これで、ホストのバージョン 4.4 へのアップグレード、新しいローカルストレージドメインの作成、4.3 ストレージドメインおよびその仮想マシンのインポートが完了しました。
次に、クラスターの互換バージョンを更新してください。
3.1.9. クラスターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization のクラスターには互換バージョンがあります。クラスターの互換バージョンは、そのクラスター内の全ホストがサポートする Red Hat Virtualization の機能を示します。クラスターの互換バージョンは、そのクラスター内で最も機能性の低いホストオペレーティングシステムのバージョンに応じて設定されます。
前提条件
- クラスターの互換レベルを変更するには、まず、クラスター内の全ホストを更新して、必要な互換性レベルをサポートするレベルにする必要があります。更新が利用可能であることを示すアイコンがホストの横にあるかどうかを確認します。
制限事項
クラスター互換性レベルを 4.6 にアップグレードした後、VirtIO NIC は別のデバイスとして列挙されます。したがって、NIC の再設定が必要になる場合があります。Red Hat は、クラスターをアップグレードする前に、仮想マシンでクラスター互換性レベルを 4.6 に設定し、ネットワーク接続を確認することにより、仮想マシンをテストすることをお勧めします。
仮想マシンのネットワーク接続に失敗した場合は、クラスターをアップグレードする前に、現在のエミュレーションする仮想マシンに一致するカスタムのエミュレーションする仮想マシン (例: 4.5 互換バージョンの場合は pc-q35-rhel8.3.0) で仮想マシンを設定します。
手順
- 管理ポータルで、 → をクリックします。
- 変更を行うクラスターを選択し、 をクリックします。
- 全般 タブで 互換バージョン を必要な値に変更します。
- をクリックします。クラスターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
一部の仮想マシンおよびテンプレートが不適切に設定されていることを警告するエラーメッセージが表示される場合があります。このエラーを修正するには、それぞれの仮想マシンを手動で編集します。仮想マシンの編集 ウィンドウには、修正すべき項目を確認することのできる新たな検証および警告が表示されます。問題が自動的に修正され、仮想マシンの設定を再度保存するだけで十分な場合もあります。それぞれの仮想マシンを編集したら、クラスターの互換バージョンを変更することができます。
次に、クラスター内の仮想マシンのクラスターの互換バージョンを更新してください。
3.1.10. 仮想マシンのクラスター互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの互換バージョンを更新したら、実行中またはサスペンド中のすべての仮想マシンについてクラスターの互換バージョンを更新する必要があります。そのためには、管理ポータルから再起動するか、REST API を使用して、またはゲストオペレーティングシステム内から更新する必要があります。再起動が必要な仮想マシンには、変更が保留されていることを示すアイコン (
) が付きます。
別途適切な時期に仮想マシンを再起動することもできますが、仮想マシンで最新の設定が使用されるように、直ちに再起動することを強く推奨します。再起動していない仮想マシンは以前の設定で動作し、さらに仮想マシンの設定が変更された場合には、保留中のクラスターの互換バージョンが上書きされる場合があります。
手順
- 管理ポータルで → をクリックします。
再起動が必要な仮想マシンを確認します。Vms: 検索バーに以下のクエリーを入力します。
next_run_config_exists=True
next_run_config_exists=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 検索結果に、変更が保留中の仮想マシンがすべて表示されます。
- それぞれの仮想マシンを選択し、再起動 をクリックします。あるいは、必要な場合は、仮想マシン自体から仮想マシンを再起動することができます。
仮想マシンが起動すると、新しい互換バージョンが自動的に適用されます。
プレビュー状態にある仮想マシンスナップショットについては、クラスターの互換バージョンを変更することができません。まずコミットするか、プレビューを取り消す必要があります。
次に、データセンターの互換バージョンを更新してください。
3.1.11. データセンターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization データセンターには、互換バージョンがあります。互換バージョンとは、データセンターが互換性を持つ Red Hat Virtualization のバージョンを指します。データセンター内のクラスターは、すべて指定の互換性レベルをサポートする必要があります。
前提条件
- データセンターの互換レベルを変更するには、事前にデータセンター内のクラスターおよび仮想マシンの互換バージョンがすべて更新されている必要があります。
手順
- 管理ポータルで → をクリックします。
- 変更を行うデータセンターを選択し、 をクリックします。
- 互換バージョン を必要な値に変更します。
- をクリックします。データセンターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
3.2. Red Hat Virtualization 4.2 から 4.3 へのリモートデータベース環境のアップグレード リンクのコピーリンクがクリップボードにコピーされました!
お使いの環境を 4.2 から 4.3 にアップグレードするステップは、以下のとおりです。
- 正しいリポジトリーを有効にするなど、前提条件を満たしていることを確認する
- Log Collection Analysis ツールおよび Image Discrepancies ツールを使用して、アップグレードの正常な完了を妨げる問題がないか確認する
- 4.2 Manager を最新バージョンの 4.2 に更新する
- データベースを PostgreSQL 9.5 から 10.0 にアップグレードする
- Manager を 4.2 から 4.3 にアップグレードする
- ホストを更新する
- クラスターの互換バージョンを更新する
- 実行中またはサスペンド中の仮想マシンをすべて再起動して、設定を更新する
- データセンターの互換バージョンを更新する
- 以前に SHA-1 証明書を SHA-256 証明書に置き換えずに 4.2 にアップグレードした場合は、ここで証明書を置き換える
3.2.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
- 仮想マシンで必要となるダウンタイムについて計画されていること。アップグレードプロセスでクラスターの互換バージョンを更新した後、それぞれの仮想マシンを再起動すると新しいハードウェア設定が自動的に適用されます。すべての実行中またはサスペンド中の仮想マシンを直ちに再起動して、設定変更を適用する必要があります。
- お使いの環境が Red Hat Virtualization 4.4 の要件を満たしていること。すべての前提条件の一覧は、Planning and Prerequisites Guide の Requirements を参照してください。
- Red Hat Virtualization Manager をアップグレードする場合には、既存ホストのいずれかを使用することが推奨されます。新規ホストの使用を選択する場合は、アップグレード手順を開始する前に、新規ホストに一意の名前を割り当ててから、既存のクラスターに追加する必要があります。
3.2.2. 環境の分析 リンクのコピーリンクがクリップボードにコピーされました!
更新の実行やトラブルシューティングを行う前に、Log Collection Analysis ツールおよび Image Discrepancies ツールを実行することが推奨されます。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。
3.2.3. ログコレクション分析ツール リンクのコピーリンクがクリップボードにコピーされました!
更新の実行前に Log Collection Analysis ツールを実行し、トラブルシューティングを行います。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。ツールはシステムに関する詳細情報を収集し、それを HTML ファイルとして提示します。
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.2 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンに Log Collection Analysis ツールをインストールします。
yum install rhv-log-collector-analyzer
# yum install rhv-log-collector-analyzerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ツールを実行します。
rhv-log-collector-analyzer --live
# rhv-log-collector-analyzer --liveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細なレポートが表示されます。
デフォルトでは、レポートは
analyzer_report.htmlという名前のフィアルに保存されます。ファイルを特定の場所に保存するには
--htmlフラグを使用して場所を指定します。rhv-log-collector-analyzer --live --html=/directory/filename.html
# rhv-log-collector-analyzer --live --html=/directory/filename.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELinks テキストモードの Web ブラウザーを使用して、ターミナル内のアナライザーレポートを読み取ることができます。ELinks ブラウザーをインストールするには、以下を実行します。
yum install -y elinks
# yum install -y elinksCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELink を起動し、
analyzer_report.htmlを開きます。elinks /home/user1/analyzer_report.html
# elinks /home/user1/analyzer_report.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow レポート内を移動するには、ELinks で以下のコマンドを使用します。
-
Insertでスクロールアップ -
Deleteでスクロールダウン -
PageUpでページアップ -
PageDownでページダウン -
left Bracketで左にスクロール -
right Bracketで右にスクロール
-
3.2.3.1. イメージ不一致ツールを使用したスナップショットの状態の監視 リンクのコピーリンクがクリップボードにコピーされました!
RHV Image Discrepancies ツールは、ストレージドメインと RHV データベースのイメージデータを分析します。ボリュームとボリューム属性に不一致が見つかった場合は警告しますが、それらの不一致は修正されません。このツールは、次のようなさまざまなシナリオで使用します。
- バージョンをアップグレードする前に、壊れたボリュームまたはチェーンを新しいバージョンに持ち越さないようにします。
- 失敗したストレージ操作に続いて、不良状態のボリュームまたは属性を検出します。
- バックアップから RHV データベースまたはストレージを復元した後。
- 定期的に、問題が悪化する前に潜在的な問題を検出します。
- スナップショットまたはライブストレージの移行に関連する問題を分析し、これらのタイプの問題を修正した後、システムの状態を確認します。
前提条件
-
必要なバージョン: このツールは、
rhv-log-collector-analyzer-0.2.15-0.el7evの RHV バージョン 4.3.8 で導入されました。 - データ収集は異なる場所で同時に実行され、アトミックではないため、ストレージドメインを変更する可能性のある環境内のすべてのアクティビティーを停止します。つまり、スナップショットを作成または削除したり、ディスクを編集、移動、作成、または削除したりしないでください。そうしないと、不整合が誤って検出される可能性があります。プロセス中、仮想マシンは正常に実行されたままになります。
手順
ツールを実行するには、RHV Manager で次のコマンドを入力します。
rhv-image-discrepancies
# rhv-image-discrepanciesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ツールが不一致を見つけた場合、特にツールの実行中に一部の操作が実行された可能性がある場合は、ツールを再実行して結果を確認します。
このツールには Export および ISO ストレージドメインが含まれており、そのストレージドメインの不一致を報告する可能性があります。その場合、これらのストレージドメインには RHV データベースにイメージのエントリーがないため、無視することができます。
結果について
このツールは次のことを報告します。
- ストレージに表示されているがデータベースにはないボリュームがある場合、またはデータベースには表示されているがストレージにはないボリュームがある場合。
- 一部のボリューム属性がストレージとデータベースで異なる場合。
出力サンプル
次に、Manager を最新バージョンの 4.2 に更新してください。
3.2.4. Red Hat Virtualization Manager の更新 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.2 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンで、更新されたパッケージが利用可能かどうかを確認します。
engine-upgrade-check
# engine-upgrade-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupスクリプトで Red Hat Virtualization Manager を更新します。engine-setupスクリプトにより、設定に関する質問への回答が求められます。その後、ovirt-engineサービスの停止、更新パッケージのダウンロード/インストール、データベースのバックアップ/更新、インストール後設定の実施を経てから、ovirt-engineサービスが起動します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記engine-setupスクリプトは、Red Hat Virtualization Manager のインストールプロセス中にも使用され、指定した設定値が保存されます。更新時に、設定のプレビュー時に保存された値が表示され、engine-configがインストール後に設定の更新に使用される場合は最新ではない可能性があります。たとえば、インストール後にengine-configを使用してSANWipeAfterDeleteをtrueへと更新した場合、engine-setupは設定プレビューに Default SAN wipe after delete: False と出力します。ただし、更新された値はengine-setupによって上書きされることはありません。重要更新プロセスに時間がかかる場合があります。完了する前にプロセスを停止しないでください。
Manager にインストールされているベースオペレーティングシステムと、オプションパッケージを更新します。
yum update --nobest
# yum update --nobestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動して更新を完了してください。
3.2.5. PostgreSQL 9.5 から 10 へのリモートデータベースのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization 4.3 では、PostgreSQL 9.5 ではなく PostgreSQL 10 が使われています。データベースをローカルにインストールしている場合は、アップグレードスクリプトによりバージョン 9.5 から 10 に自動的にアップグレードされます。ただし、データベース (Manager または Data Warehouse) のどちらかが別のマシンにインストールされている場合は、Manager をアップグレードする前にそれぞれのリモートデータベースで以下の手順を実施する必要があります。
マシンで実行しているサービスを停止します。
Manager データベースをアップグレードする場合は、Manager マシンで
ovirt-engineサービスを停止します。systemctl stop ovirt-engine
# systemctl stop ovirt-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow Data Warehouse データベースをアップグレードする場合は、Data Warehouse マシンで
ovirt-engine-dwhdサービスを停止します。systemctl stop ovirt-engine-dwhd
# systemctl stop ovirt-engine-dwhdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PostgreSQL 10 パッケージを取得するために必要なリポジトリーを有効にします。
Red Hat Virtualization Manager リポジトリーを有効にするか、
subscription-manager repos --enable=rhel-7-server-rhv-4.3-manager-rpms
# subscription-manager repos --enable=rhel-7-server-rhv-4.3-manager-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow あるいは、SCL リポジトリーを有効にします。
subscription-manager repos --enable rhel-server-rhscl-7-rpms
# subscription-manager repos --enable rhel-server-rhscl-7-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow PostgreSQL 10 パッケージをインストールします。
yum install rh-postgresql10 rh-postgresql10-postgresql-contrib
# yum install rh-postgresql10 rh-postgresql10-postgresql-contribCopy to Clipboard Copied! Toggle word wrap Toggle overflow PostgreSQL 9.5 サービスを停止し、無効にします。
systemctl stop rh-postgresql95-postgresql systemctl disable rh-postgresql95-postgresql
# systemctl stop rh-postgresql95-postgresql # systemctl disable rh-postgresql95-postgresqlCopy to Clipboard Copied! Toggle word wrap Toggle overflow PostgreSQL 9.5 データベースを PostgreSQL 10 にアップグレードします。
scl enable rh-postgresql10 -- postgresql-setup --upgrade-from=rh-postgresql95-postgresql --upgrade
# scl enable rh-postgresql10 -- postgresql-setup --upgrade-from=rh-postgresql95-postgresql --upgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow rh-postgresql10-postgresql.serviceを起動して有効にし、実行していることを確認します。systemctl start rh-postgresql10-postgresql.service systemctl enable rh-postgresql10-postgresql.service systemctl status rh-postgresql10-postgresql.service
# systemctl start rh-postgresql10-postgresql.service # systemctl enable rh-postgresql10-postgresql.service # systemctl status rh-postgresql10-postgresql.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような出力が表示されることを確認します。
rh-postgresql10-postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/rh-postgresql10-postgresql.service; enabled; vendor preset: disabled) Active: active (running) since ...
rh-postgresql10-postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/rh-postgresql10-postgresql.service; enabled; vendor preset: disabled) Active: active (running) since ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow pg_hba.confクライアント設定ファイルを PostgreSQL 9.5 環境から PostgreSQL 10 環境にコピーします。cp -p /var/opt/rh/rh-postgresql95/lib/pgsql/data/pg_hba.conf /var/opt/rh/rh-postgresql10/lib/pgsql/data/pg_hba.conf
# cp -p /var/opt/rh/rh-postgresql95/lib/pgsql/data/pg_hba.conf /var/opt/rh/rh-postgresql10/lib/pgsql/data/pg_hba.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow /var/opt/rh/rh-postgresql10/lib/pgsql/data/postgresql.confで以下のパラメーターを更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow PostgreSQL 10 サービスを再起動して設定の変更を適用します。
systemctl restart rh-postgresql10-postgresql.service
# systemctl restart rh-postgresql10-postgresql.serviceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次に、Manager を 4.3 にアップグレードしてください。
3.2.6. Red Hat Virtualization Manager の 4.2 から 4.3 へのアップグレード リンクのコピーリンクがクリップボードにコピーされました!
以下のいずれかをアップグレードする場合は、同じ手順に従います。
- Red Hat Virtualization Manager
- Data Warehouse サービスを使用するリモートマシン
アップグレードしているマシンにログインする必要があります。
アップグレードに失敗すると、engine-setup コマンドは Red Hat Virtualization Manager のインストールを以前の状態に復元しようとします。このため、アップグレードが完了するまで、以前のバージョンのリポジトリーを削除しないでください。アップグレードに失敗すると、engine-setup スクリプトによりインストールの復元方法を説明します。
手順
Red Hat Virtualization 4.3 のリポジトリーを有効にします。
subscription-manager repos \ --enable=rhel-7-server-rhv-4.3-manager-rpms \ --enable=jb-eap-7.2-for-rhel-7-server-rpms# subscription-manager repos \ --enable=rhel-7-server-rhv-4.3-manager-rpms \ --enable=jb-eap-7.2-for-rhel-7-server-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow その他のリポジトリーはすべて、Red Hat Virtualization リリース全体を通して同じになります。
setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupを実行し、プロンプトに従って Red Hat Virtualization Manager、リモートデータベース、またはリモートサービスをアップグレードします。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Manager のアップグレードプロセス中に、
engine-setupスクリプトにより、リモート Data Warehouse データベースへの接続が解除される場合があります。接続を切断して設定を続行する必要があります。スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Virtualization 4.2 のリポジトリーを無効にして、このシステムで 4.2 のパッケージが使用されないようにします。
subscription-manager repos \ --disable=rhel-7-server-rhv-4.2-manager-rpms \ --disable=jb-eap-7-for-rhel-7-server-rpms# subscription-manager repos \ --disable=rhel-7-server-rhv-4.2-manager-rpms \ --disable=jb-eap-7-for-rhel-7-server-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow ベースオペレーティングシステムを更新します。
yum update
# yum updateCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動してアップグレードを完了してください。
Manager はバージョン 4.3 にアップグレードされました。
3.2.6.1. リモート Data Warehouse データベースアップグレードの完了 リンクのコピーリンクがクリップボードにコピーされました!
リモート Data Warehouse データベースを PostgreSQL 9.5 から 10 にアップグレードするときに、これらの追加の手順を実行します。
手順
ovirt-engine-dwhdサービスが Manager マシンで実行されるようになりました。ovirt-engine-dwhdサービスがリモートマシンにある場合は、Manager マシンのovirt-engine-dwhdサービスを停止して無効にし、engine-setupが作成した設定ファイルを削除します。systemctl stop ovirt-engine-dwhd systemctl disable ovirt-engine-dwhd rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/*
# systemctl stop ovirt-engine-dwhd # systemctl disable ovirt-engine-dwhd # rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/*Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ovirt-engine-dwhdサービスをホストするマシンで、Manager を 4.3 にアップグレード する手順を繰り返します。
次に、ホストを更新してください。
3.2.7. クラスター内の全ホストの更新 リンクのコピーリンクがクリップボードにコピーされました!
ホストを個別に更新するのではなく、クラスター内の全ホストを更新することができます。この手法は、Red Hat Virtualization を新しいバージョンにアップグレードする際に特に役立ちます。更新の自動化に使用する Ansible ロールの詳細は、oVirt クラスターアップグレード を参照してください。
クラスターは一度に 1 つずつ更新します。
制限事項
-
RHVH の更新時には、
/etcおよび/varディレクトリーに変更されたコンテンツのみを保持します。他のパスに含まれる変更されたデータは更新時に上書きされます。 - クラスターの移行が有効化されている場合には、仮想マシンはそのクラスター内の別のホストに自動的に移行されます。
- セルフホスト型エンジン環境では、Manager 用仮想マシンは同一クラスター内のセルフホスト型エンジンノード間でのみ移行が可能です。通常のホストに移行することはできません。
- ホストが属するクラスターには、ホストがメンテナンスを実行するのに十分なメモリーが確保されている必要があります。確保されていないと、仮想マシンの移行がハングして失敗してしまいます。ホストを更新する前に一部またはすべての仮想マシンをシャットダウンしておくと、ホスト更新によるメモリー使用量を低減することができます。
- ホストに固定された仮想マシン (vGPU を使用している仮想マシンなど) を別のホストに移行することはできません。ホストの更新をスキップしない限り、そのホストに固定された仮想マシンは更新中にシャットダウンされます。
手順
- 管理ポータルで → をクリックし、クラスターを選択します。ステータスのアップグレード 列には、クラスターの任意のホストでアップグレードが利用可能かどうかが表示されます。
- アップグレード をクリックします。
- 更新するホストを選択し、次に Next をクリックします。
オプションを設定します。
- 固定された仮想マシンの停止: クラスター内のホストに固定された仮想マシンをシャットダウンします。このオプションは、デフォルトで選択されています。このチェックボックスの選択を解除すると、固定された仮想マシンが動作を続けられるように、それらのホストの更新をスキップすることができます (固定された仮想マシンが重要なサービスまたはプロセスを実行中で、更新中の予期せぬ時にシャットダウンされるのを避けたい場合など)。
-
Upgrade Timeout (Minutes): このオプションで設定した時間内に個々のホストの更新が完了しない場合には、クラスターのアップグレードはタイムアウトで失敗します。デフォルトは
60です。60 分では不十分と思われる大規模なクラスターの場合には、時間を延長することができます。また、ホストの更新が短時間で完了する小規模なクラスターでは、短縮することができます。 - Check Upgrade: アップグレードプロセスを実行する前に、それぞれのホストで更新が利用可能かどうかを確認します。このオプションは、デフォルトでは選択されていません。ただし、Manager がホストの更新を確認する頻度をデフォルトより低く設定している状況などで、最新の更新を確実に含める必要がある場合には、このオプションを選択することができます。
- Reboot After Upgrade: ホストの更新後に、それぞれのホストを再起動します。このオプションは、デフォルトで選択されています。ホストの再起動を必要とする保留中の更新がないことが明らかであれば、このチェックボックスの選択を解除してプロセスを迅速化することができます。
-
Use Maintenance Policy: 更新時のクラスターのスケジューリングポリシーを
cluster_maintenanceに設定します。このオプションはデフォルトで選択されています。したがって、許可される動作は限定的で、仮想マシンは高可用性でない限り起動することができません。更新中も使用を続けたいカスタムのスケジューリングポリシーがある場合には、このチェックボックスの選択を解除することができます。ただし、これにより想定外の結果を招く可能性があります。このオプションを無効にする前に、カスタムのポリシーがクラスターのアップグレード操作に対応していることを確認してください。
- Next をクリックします。
- 影響を受けるホストおよび仮想マシンの概要を確認します。
- アップグレード をクリックします。
以下で、ホスト更新の進捗状況を追跡できます。
- → ビュー (ステータスのアップグレード 列は アップグレード中 と表示される)
- → ビュー
-
通知ドロワー の イベント セクション (
)
仮想マシン移行の進捗を、 → ビューの ステータス 列で個々に追跡することができます。大規模な環境では、特定の仮想マシングループの結果を表示するために、結果を絞り込まなければならない場合があります。
3.2.8. クラスターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization のクラスターには互換バージョンがあります。クラスターの互換バージョンは、そのクラスター内の全ホストがサポートする Red Hat Virtualization の機能を示します。クラスターの互換バージョンは、そのクラスター内で最も機能性の低いホストオペレーティングシステムのバージョンに応じて設定されます。
前提条件
- クラスターの互換レベルを変更するには、まず、クラスター内の全ホストを更新して、必要な互換性レベルをサポートするレベルにする必要があります。更新が利用可能であることを示すアイコンがホストの横にあるかどうかを確認します。
制限事項
クラスター互換性レベルを 4.6 にアップグレードした後、VirtIO NIC は別のデバイスとして列挙されます。したがって、NIC の再設定が必要になる場合があります。Red Hat は、クラスターをアップグレードする前に、仮想マシンでクラスター互換性レベルを 4.6 に設定し、ネットワーク接続を確認することにより、仮想マシンをテストすることをお勧めします。
仮想マシンのネットワーク接続に失敗した場合は、クラスターをアップグレードする前に、現在のエミュレーションする仮想マシンに一致するカスタムのエミュレーションする仮想マシン (例: 4.5 互換バージョンの場合は pc-q35-rhel8.3.0) で仮想マシンを設定します。
手順
- 管理ポータルで、 → をクリックします。
- 変更を行うクラスターを選択し、 をクリックします。
- 全般 タブで 互換バージョン を必要な値に変更します。
- をクリックします。クラスターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
一部の仮想マシンおよびテンプレートが不適切に設定されていることを警告するエラーメッセージが表示される場合があります。このエラーを修正するには、それぞれの仮想マシンを手動で編集します。仮想マシンの編集 ウィンドウには、修正すべき項目を確認することのできる新たな検証および警告が表示されます。問題が自動的に修正され、仮想マシンの設定を再度保存するだけで十分な場合もあります。それぞれの仮想マシンを編集したら、クラスターの互換バージョンを変更することができます。
3.2.9. 仮想マシンのクラスター互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの互換バージョンを更新したら、実行中またはサスペンド中のすべての仮想マシンについてクラスターの互換バージョンを更新する必要があります。そのためには、管理ポータルから再起動するか、REST API を使用して、またはゲストオペレーティングシステム内から更新する必要があります。再起動が必要な仮想マシンには、変更が保留されていることを示すアイコン (
) が付きます。
別途適切な時期に仮想マシンを再起動することもできますが、仮想マシンで最新の設定が使用されるように、直ちに再起動することを強く推奨します。再起動していない仮想マシンは以前の設定で動作し、さらに仮想マシンの設定が変更された場合には、保留中のクラスターの互換バージョンが上書きされる場合があります。
手順
- 管理ポータルで → をクリックします。
再起動が必要な仮想マシンを確認します。Vms: 検索バーに以下のクエリーを入力します。
next_run_config_exists=True
next_run_config_exists=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 検索結果に、変更が保留中の仮想マシンがすべて表示されます。
- それぞれの仮想マシンを選択し、再起動 をクリックします。あるいは、必要な場合は、仮想マシン自体から仮想マシンを再起動することができます。
仮想マシンが起動すると、新しい互換バージョンが自動的に適用されます。
プレビュー状態にある仮想マシンスナップショットについては、クラスターの互換バージョンを変更することができません。まずコミットするか、プレビューを取り消す必要があります。
3.2.10. データセンターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization データセンターには、互換バージョンがあります。互換バージョンとは、データセンターが互換性を持つ Red Hat Virtualization のバージョンを指します。データセンター内のクラスターは、すべて指定の互換性レベルをサポートする必要があります。
前提条件
- データセンターの互換レベルを変更するには、事前にデータセンター内のクラスターおよび仮想マシンの互換バージョンがすべて更新されている必要があります。
手順
- 管理ポータルで → をクリックします。
- 変更を行うデータセンターを選択し、 をクリックします。
- 互換バージョン を必要な値に変更します。
- をクリックします。データセンターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
以前に SHA-1 証明書を SHA-256 証明書に置き換えずに 4.2 にアップグレードした場合は、ここで置き換える必要があります。
3.2.11. SHA-1 証明書の SHA-256 証明書への置き換え リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization 4.4 では SHA-256 署名が使用され、SHA-1 よりセキュアに SSL 証明書に署名することができます。新たにインストールしたシステムでは、Red Hat Virtualization の公開鍵インフラストラクチャー (PKI) が SHA-256 署名を使用できるようにするための特別な手順は必要ありません。
証明書の有効期限が 切れない ようにしてください。有効期限が切れると、環境は応答しなくなり、復元でエラーが発生しやすくなり、時間がかかるプロセスになります。証明書の更新は、Administration Guide の Renewing certificates before they expire を参照してください。
ブラウザーでの警告メッセージ表示の防止
- Manager マシンに root ユーザーとしてログインします。
/etc/pki/ovirt-engine/openssl.conf に
default_md = sha256の行が含まれているかどうかを確認します。cat /etc/pki/ovirt-engine/openssl.conf
# cat /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow まだ
default_md = sha1が含まれており、既存の設定をバックアップし、デフォルトをsha256に変更します。cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.conf
# cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" # sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow 署名し直す必要のある証明書を定義します。
names="apache"
# names="apache"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Manager で、
/etc/ovirt-engine/engine.conf.dディレクトリーと/etc/pki/ovirt-engineディレクトリーのバックアップを保存し、証明書を再署名します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - このパスワード値を変更しないでください。
httpd サービスを再起動します。
systemctl restart httpd
# systemctl restart httpdCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルに接続して、警告が表示されなくなったことを確認します。
-
以前に CA または https 証明書をブラウザーにインポートしている場合は、その証明書を探してブラウザーから削除し、新しい CA 証明書をインポートし直します。ブラウザーから提供される手順に従って、認証局の証明書をインストールしてください。認証局の証明書を取得するには、
http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CAに移動し、your-manager-fqdn を完全修飾ドメイン名 (FQDN) に置き換えます。
すべての署名済み証明書を SHA-256 に置き換える
- Manager マシンに root ユーザーとしてログインします。
/etc/pki/ovirt-engine/openssl.conf に
default_md = sha256の行が含まれているかどうかを確認します。cat /etc/pki/ovirt-engine/openssl.conf
# cat /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow まだ
default_md = sha1が含まれており、既存の設定をバックアップし、デフォルトをsha256に変更します。cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.conf
# cp -p /etc/pki/ovirt-engine/openssl.conf /etc/pki/ovirt-engine/openssl.conf."$(date +"%Y%m%d%H%M%S")" # sed -i 's/^default_md = sha1/default_md = sha256/' /etc/pki/ovirt-engine/openssl.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow CA 証明書のバックアップを作成して ca.pem.new に新しい証明書を作成し、CA 証明書を署名し直します。
cp -p /etc/pki/ovirt-engine/private/ca.pem /etc/pki/ovirt-engine/private/ca.pem."$(date +"%Y%m%d%H%M%S")" openssl x509 -signkey /etc/pki/ovirt-engine/private/ca.pem -in /etc/pki/ovirt-engine/ca.pem -out /etc/pki/ovirt-engine/ca.pem.new -days 3650 -sha256
# cp -p /etc/pki/ovirt-engine/private/ca.pem /etc/pki/ovirt-engine/private/ca.pem."$(date +"%Y%m%d%H%M%S")" # openssl x509 -signkey /etc/pki/ovirt-engine/private/ca.pem -in /etc/pki/ovirt-engine/ca.pem -out /etc/pki/ovirt-engine/ca.pem.new -days 3650 -sha256Copy to Clipboard Copied! Toggle word wrap Toggle overflow 既存の証明書を新しい証明書に置き換えます。
mv /etc/pki/ovirt-engine/ca.pem.new /etc/pki/ovirt-engine/ca.pem
# mv /etc/pki/ovirt-engine/ca.pem.new /etc/pki/ovirt-engine/ca.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 署名し直す必要のある証明書を定義します。
names="engine apache websocket-proxy jboss imageio-proxy"
# names="engine apache websocket-proxy jboss imageio-proxy"Copy to Clipboard Copied! Toggle word wrap Toggle overflow アップグレード後に Red Hat Virtualization Manager SSL 証明書を置き換えている場合は、上記のコマンドの代わりに以下のコマンドを実行します。
names="engine websocket-proxy jboss imageio-proxy"
# names="engine websocket-proxy jboss imageio-proxy"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細は、Administration Guide の Replacing the Red Hat Virtualization Manager CA Certificate を参照してください。
Manager で、
/etc/ovirt-engine/engine.conf.dディレクトリーと/etc/pki/ovirt-engineディレクトリーのバックアップを保存し、証明書を再署名します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - このパスワード値を変更しないでください。
以下のサービスを再起動します。
systemctl restart httpd systemctl restart ovirt-engine systemctl restart ovirt-websocket-proxy systemctl restart ovirt-imageio
# systemctl restart httpd # systemctl restart ovirt-engine # systemctl restart ovirt-websocket-proxy # systemctl restart ovirt-imageioCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 管理ポータルに接続して、警告が表示されなくなったことを確認します。
-
以前に CA または https 証明書をブラウザーにインポートしている場合は、その証明書を探してブラウザーから削除し、新しい CA 証明書をインポートし直します。ブラウザーから提供される手順に従って、認証局の証明書をインストールしてください。認証局の証明書を取得するには、
http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CAに移動し、your-manager-fqdn を完全修飾ドメイン名 (FQDN) に置き換えます。 ホストで証明書を登録します。それぞれのホストについて以下の手順を繰り返します。
- 管理ポータルで → をクリックします。
- ホストを選択し、 → をクリックしてから をクリックします。
- ホストがメンテナンスモードに変わったら、 → をクリックします。
- → をクリックします。
第4章 マイナーリリース間の更新 リンクのコピーリンクがクリップボードにコピーされました!
4.1. マイナーリリース間での Red Hat Virtualization の更新 リンクのコピーリンクがクリップボードにコピーされました!
4.4 を現行バージョンから最新のバージョンの 4.4 に更新するには、Manager を更新し、ホストを更新してから、クラスター、仮想マシン、およびデータセンターの互換バージョンを変更します。
RHVH でバージョン 4.4.9 からそれ以降のバージョンにアップグレードできない場合は、dnf reinstall redhat-virtualization-host-image-update コマンドを実行して問題を修正します。
アップグレードに関する考慮事項
- アップグレードを計画する場合は、Red Hat Virtualization 4.4 のアップグレードに関する考慮事項および既知の問題 を参照してください。
Open Virtual Network (OVN) および Open vSwitch (OvS) 2.11 から OVN 2021 および OvS 2.15 にアップグレードする場合、以下の条件が満たされている限り、このプロセスはユーザーからは見えません。
- Manager が最初にアップグレードされている。
- OVN/OvS バージョン 2.11 のホスト間で機能することが予想されるすべての OVN ネットワークに対して、ホストのアップグレード前に ovirt-provider-ovn セキュリティーグループを無効にしている。
- ホストは、OVN バージョン 2021 以降および OvS バージョン 2.15 になるようにアップグレードされる。OVN を適切に再設定し、証明書を更新することができるように、管理ポータルでこの手順を完了する必要があります。
- ホストがアップグレード後に再起動される。
プロバイダーと OVN がホストで正常に設定されたかどうかを確認するには、ホストの General タブで OVN configured フラグを確認します。OVN Configured が No に設定されている場合は、 → をクリックします。この設定は、REST API でも利用可能です。機能の更新に失敗した場合は、Manager 4.4 以降からホストを再インストールして OVN を設定できます。
4.1.1. 環境の分析 リンクのコピーリンクがクリップボードにコピーされました!
更新の実行やトラブルシューティングを行う前に、Log Collection Analysis ツールおよび Image Discrepancies ツールを実行することが推奨されます。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。
4.1.2. ログコレクション分析ツール リンクのコピーリンクがクリップボードにコピーされました!
更新の実行前に Log Collection Analysis ツールを実行し、トラブルシューティングを行います。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。ツールはシステムに関する詳細情報を収集し、それを HTML ファイルとして提示します。
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.4 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンに Log Collection Analysis ツールをインストールします。
yum install rhv-log-collector-analyzer
# yum install rhv-log-collector-analyzerCopy to Clipboard Copied! Toggle word wrap Toggle overflow ツールを実行します。
rhv-log-collector-analyzer --live
# rhv-log-collector-analyzer --liveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 詳細なレポートが表示されます。
デフォルトでは、レポートは
analyzer_report.htmlという名前のフィアルに保存されます。ファイルを特定の場所に保存するには
--htmlフラグを使用して場所を指定します。rhv-log-collector-analyzer --live --html=/directory/filename.html
# rhv-log-collector-analyzer --live --html=/directory/filename.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELinks テキストモードの Web ブラウザーを使用して、ターミナル内のアナライザーレポートを読み取ることができます。ELinks ブラウザーをインストールするには、以下を実行します。
yum install -y elinks
# yum install -y elinksCopy to Clipboard Copied! Toggle word wrap Toggle overflow ELink を起動し、
analyzer_report.htmlを開きます。elinks /home/user1/analyzer_report.html
# elinks /home/user1/analyzer_report.htmlCopy to Clipboard Copied! Toggle word wrap Toggle overflow レポート内を移動するには、ELinks で以下のコマンドを使用します。
-
Insertでスクロールアップ -
Deleteでスクロールダウン -
PageUpでページアップ -
PageDownでページダウン -
left Bracketで左にスクロール -
right Bracketで右にスクロール
-
4.1.2.1. イメージ不一致ツールを使用したスナップショットの状態の監視 リンクのコピーリンクがクリップボードにコピーされました!
RHV Image Discrepancies ツールは、ストレージドメインと RHV データベースのイメージデータを分析します。ボリュームとボリューム属性に不一致が見つかった場合は警告しますが、それらの不一致は修正されません。このツールは、次のようなさまざまなシナリオで使用します。
- バージョンをアップグレードする前に、壊れたボリュームまたはチェーンを新しいバージョンに持ち越さないようにします。
- 失敗したストレージ操作に続いて、不良状態のボリュームまたは属性を検出します。
- バックアップから RHV データベースまたはストレージを復元した後。
- 定期的に、問題が悪化する前に潜在的な問題を検出します。
- スナップショットまたはライブストレージの移行に関連する問題を分析し、これらのタイプの問題を修正した後、システムの状態を確認します。
前提条件
-
必要なバージョン: このツールは、
rhv-log-collector-analyzer-0.2.15-0.el7evの RHV バージョン 4.3.8 で導入されました。 - データ収集は異なる場所で同時に実行され、アトミックではないため、ストレージドメインを変更する可能性のある環境内のすべてのアクティビティーを停止します。つまり、スナップショットを作成または削除したり、ディスクを編集、移動、作成、または削除したりしないでください。そうしないと、不整合が誤って検出される可能性があります。プロセス中、仮想マシンは正常に実行されたままになります。
手順
ツールを実行するには、RHV Manager で次のコマンドを入力します。
rhv-image-discrepancies
# rhv-image-discrepanciesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - ツールが不一致を見つけた場合、特にツールの実行中に一部の操作が実行された可能性がある場合は、ツールを再実行して結果を確認します。
このツールには Export および ISO ストレージドメインが含まれており、そのストレージドメインの不一致を報告する可能性があります。その場合、これらのストレージドメインには RHV データベースにイメージのエントリーがないため、無視することができます。
結果について
このツールは次のことを報告します。
- ストレージに表示されているがデータベースにはないボリュームがある場合、またはデータベースには表示されているがストレージにはないボリュームがある場合。
- 一部のボリューム属性がストレージとデータベースで異なる場合。
出力サンプル
スタンドアロンの Manager を更新するには、マイナー更新のための標準手順に従います。
4.1.3. Red Hat Virtualization Manager の更新 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.4 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
注記RHV バージョン 4.4.0 から RHV バージョン 4.4.8 から 4.4.9 以降にアップグレードする場合は、サブスクリプションリポジトリー
jb-eap-7.4-for-rhel-8-x86_64-rpmsのリストに EAP 7.4 チャンネルを追加し、アップグレード後にjb-eap-7.3-for-rhel-8-x86_64-rpmsを削除する必要があります。Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンで、更新されたパッケージが利用可能かどうかを確認します。
engine-upgrade-check
# engine-upgrade-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupスクリプトで Red Hat Virtualization Manager を更新します。engine-setupスクリプトにより、設定に関する質問への回答が求められます。その後、ovirt-engineサービスの停止、更新パッケージのダウンロード/インストール、データベースのバックアップ/更新、インストール後設定の実施を経てから、ovirt-engineサービスが起動します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記engine-setupスクリプトは、Red Hat Virtualization Manager のインストールプロセス中にも使用され、指定した設定値が保存されます。更新時に、設定のプレビュー時に保存された値が表示され、engine-configがインストール後に設定の更新に使用される場合は最新ではない可能性があります。たとえば、インストール後にengine-configを使用してSANWipeAfterDeleteをtrueへと更新した場合、engine-setupは設定プレビューに Default SAN wipe after delete: False と出力します。ただし、更新された値はengine-setupによって上書きされることはありません。重要更新プロセスに時間がかかる場合があります。完了する前にプロセスを停止しないでください。
Manager にインストールされているベースオペレーティングシステムと、オプションパッケージを更新します。
yum update --nobest
# yum update --nobestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要いずれかのカーネルパッケージが更新された場合には、マシンを再起動して更新を完了してください。
4.1.4. セルフホスト型エンジンの更新 リンクのコピーリンクがクリップボードにコピーされました!
セルフホスト型エンジンを現在お使いのバージョンから最新のバージョンに更新するには、環境をグローバルメンテナンスモードに切り替え、続いてマイナーバージョン間の標準更新手順に従う必要があります。
グローバルメンテナンスモードの有効化
Manager 用仮想マシンの設定またはアップグレード作業を実施する前に、セルフホスト型エンジン環境をグローバルメンテナンスモードに切り替える必要があります。
手順
セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを有効にします。
hosted-engine --set-maintenance --mode=global
# hosted-engine --set-maintenance --mode=globalCopy to Clipboard Copied! Toggle word wrap Toggle overflow 作業を進める前に、環境がグローバルメンテナンスモードにあることを確認します。
hosted-engine --vm-status
# hosted-engine --vm-statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターがグローバルメンテナンスモードにあることを示すメッセージが表示されるはずです。
Red Hat Virtualization Manager の更新
前提条件
Manager マシンで正しいリポジトリーが有効になっていること。Red Hat Virtualization 4.4 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。
注記RHV バージョン 4.4.0 から RHV バージョン 4.4.8 から 4.4.9 以降にアップグレードする場合は、サブスクリプションリポジトリー
jb-eap-7.4-for-rhel-8-x86_64-rpmsのリストに EAP 7.4 チャンネルを追加し、アップグレード後にjb-eap-7.3-for-rhel-8-x86_64-rpmsを削除する必要があります。Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。
手順
Manager マシンで、更新されたパッケージが利用可能かどうかを確認します。
engine-upgrade-check
# engine-upgrade-checkCopy to Clipboard Copied! Toggle word wrap Toggle overflow setup のパッケージを更新します。
yum update ovirt\*setup\* rh\*vm-setup-plugins
# yum update ovirt\*setup\* rh\*vm-setup-pluginsCopy to Clipboard Copied! Toggle word wrap Toggle overflow engine-setupスクリプトで Red Hat Virtualization Manager を更新します。engine-setupスクリプトにより、設定に関する質問への回答が求められます。その後、ovirt-engineサービスの停止、更新パッケージのダウンロード/インストール、データベースのバックアップ/更新、インストール後設定の実施を経てから、ovirt-engineサービスが起動します。engine-setup
# engine-setupCopy to Clipboard Copied! Toggle word wrap Toggle overflow スクリプトが正常に完了すると、以下のメッセージが表示されます。
Execution of setup completed successfully
Execution of setup completed successfullyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記engine-setupスクリプトは、Red Hat Virtualization Manager のインストールプロセス中にも使用され、指定した設定値が保存されます。更新時に、設定のプレビュー時に保存された値が表示され、engine-configがインストール後に設定の更新に使用される場合は最新ではない可能性があります。たとえば、インストール後にengine-configを使用してSANWipeAfterDeleteをtrueへと更新した場合、engine-setupは設定プレビューに Default SAN wipe after delete: False と出力します。ただし、更新された値はengine-setupによって上書きされることはありません。重要更新プロセスに時間がかかる場合があります。完了する前にプロセスを停止しないでください。
Manager にインストールされているベースオペレーティングシステムと、オプションパッケージを更新します。
yum update --nobest
# yum update --nobestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要更新中に必要な Ansible パッケージの競合が発生した場合は、Cannot perform yum update on my RHV manager (ansible conflict) を参照してください。
重要カーネルパッケージが更新された場合は、以下を実行します。
- グローバルメンテナンスモードを無効にする
- マシンを再起動して更新を完了する
関連情報
グローバルメンテナンスモードの無効化
手順
- Manager 用仮想マシンにログインし、シャットダウンします。
セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを無効にします。
hosted-engine --set-maintenance --mode=none
# hosted-engine --set-maintenance --mode=noneCopy to Clipboard Copied! Toggle word wrap Toggle overflow グローバルメンテナンスモードを終了すると、ovirt-ha-agent が Manager 用仮想マシンを起動し、続いて Manager が自動的に起動します。Manager が起動するまでに最大で 10 分程度かかる場合があります。
環境が動作していることを確認します。
hosted-engine --vm-status
# hosted-engine --vm-statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 情報の一覧に、Engine status が含まれます。Engine status の値は、以下のようになるはずです。
{"health": "good", "vm": "up", "detail": "Up"}{"health": "good", "vm": "up", "detail": "Up"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記仮想マシンが起動中で Manager がまだ動作していない場合、Engine status は以下のようになります。
{"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}{"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow このような場合には、数分間待ってからやり直してください。
4.1.5. クラスター内の全ホストの更新 リンクのコピーリンクがクリップボードにコピーされました!
ホストを個別に更新するのではなく、クラスター内の全ホストを更新することができます。この手法は、Red Hat Virtualization を新しいバージョンにアップグレードする際に特に役立ちます。更新の自動化に使用する Ansible ロールの詳細は、oVirt クラスターアップグレード を参照してください。
クラスターは一度に 1 つずつ更新します。
制限事項
-
RHVH の更新時には、
/etcおよび/varディレクトリーに変更されたコンテンツのみを保持します。他のパスに含まれる変更されたデータは更新時に上書きされます。 - クラスターの移行が有効化されている場合には、仮想マシンはそのクラスター内の別のホストに自動的に移行されます。
- セルフホスト型エンジン環境では、Manager 用仮想マシンは同一クラスター内のセルフホスト型エンジンノード間でのみ移行が可能です。通常のホストに移行することはできません。
- ホストが属するクラスターには、ホストがメンテナンスを実行するのに十分なメモリーが確保されている必要があります。確保されていないと、仮想マシンの移行がハングして失敗してしまいます。ホストを更新する前に一部またはすべての仮想マシンをシャットダウンしておくと、ホスト更新によるメモリー使用量を低減することができます。
- ホストに固定された仮想マシン (vGPU を使用している仮想マシンなど) を別のホストに移行することはできません。ホストの更新をスキップしない限り、そのホストに固定された仮想マシンは更新中にシャットダウンされます。
手順
- 管理ポータルで → をクリックし、クラスターを選択します。ステータスのアップグレード 列には、クラスターの任意のホストでアップグレードが利用可能かどうかが表示されます。
- アップグレード をクリックします。
- 更新するホストを選択し、次に Next をクリックします。
オプションを設定します。
- 固定された仮想マシンの停止: クラスター内のホストに固定された仮想マシンをシャットダウンします。このオプションは、デフォルトで選択されています。このチェックボックスの選択を解除すると、固定された仮想マシンが動作を続けられるように、それらのホストの更新をスキップすることができます (固定された仮想マシンが重要なサービスまたはプロセスを実行中で、更新中の予期せぬ時にシャットダウンされるのを避けたい場合など)。
-
Upgrade Timeout (Minutes): このオプションで設定した時間内に個々のホストの更新が完了しない場合には、クラスターのアップグレードはタイムアウトで失敗します。デフォルトは
60です。60 分では不十分と思われる大規模なクラスターの場合には、時間を延長することができます。また、ホストの更新が短時間で完了する小規模なクラスターでは、短縮することができます。 - Check Upgrade: アップグレードプロセスを実行する前に、それぞれのホストで更新が利用可能かどうかを確認します。このオプションは、デフォルトでは選択されていません。ただし、Manager がホストの更新を確認する頻度をデフォルトより低く設定している状況などで、最新の更新を確実に含める必要がある場合には、このオプションを選択することができます。
- Reboot After Upgrade: ホストの更新後に、それぞれのホストを再起動します。このオプションは、デフォルトで選択されています。ホストの再起動を必要とする保留中の更新がないことが明らかであれば、このチェックボックスの選択を解除してプロセスを迅速化することができます。
-
Use Maintenance Policy: 更新時のクラスターのスケジューリングポリシーを
cluster_maintenanceに設定します。このオプションはデフォルトで選択されています。したがって、許可される動作は限定的で、仮想マシンは高可用性でない限り起動することができません。更新中も使用を続けたいカスタムのスケジューリングポリシーがある場合には、このチェックボックスの選択を解除することができます。ただし、これにより想定外の結果を招く可能性があります。このオプションを無効にする前に、カスタムのポリシーがクラスターのアップグレード操作に対応していることを確認してください。
- Next をクリックします。
- 影響を受けるホストおよび仮想マシンの概要を確認します。
- アップグレード をクリックします。
以下で、ホスト更新の進捗状況を追跡できます。
- → ビュー (ステータスのアップグレード 列は アップグレード中 と表示される)
- → ビュー
-
通知ドロワー の イベント セクション (
)
仮想マシン移行の進捗を、 → ビューの ステータス 列で個々に追跡することができます。大規模な環境では、特定の仮想マシングループの結果を表示するために、結果を絞り込まなければならない場合があります。
次に、クラスターの互換バージョンを更新してください。
4.1.6. クラスターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization のクラスターには互換バージョンがあります。クラスターの互換バージョンは、そのクラスター内の全ホストがサポートする Red Hat Virtualization の機能を示します。クラスターの互換バージョンは、そのクラスター内で最も機能性の低いホストオペレーティングシステムのバージョンに応じて設定されます。
前提条件
- クラスターの互換レベルを変更するには、まず、クラスター内の全ホストを更新して、必要な互換性レベルをサポートするレベルにする必要があります。更新が利用可能であることを示すアイコンがホストの横にあるかどうかを確認します。
制限事項
クラスター互換性レベルを 4.6 にアップグレードした後、VirtIO NIC は別のデバイスとして列挙されます。したがって、NIC の再設定が必要になる場合があります。Red Hat は、クラスターをアップグレードする前に、仮想マシンでクラスター互換性レベルを 4.6 に設定し、ネットワーク接続を確認することにより、仮想マシンをテストすることをお勧めします。
仮想マシンのネットワーク接続に失敗した場合は、クラスターをアップグレードする前に、現在のエミュレーションする仮想マシンに一致するカスタムのエミュレーションする仮想マシン (例: 4.5 互換バージョンの場合は pc-q35-rhel8.3.0) で仮想マシンを設定します。
手順
- 管理ポータルで、 → をクリックします。
- 変更を行うクラスターを選択し、 をクリックします。
- 全般 タブで 互換バージョン を必要な値に変更します。
- をクリックします。クラスターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
一部の仮想マシンおよびテンプレートが不適切に設定されていることを警告するエラーメッセージが表示される場合があります。このエラーを修正するには、それぞれの仮想マシンを手動で編集します。仮想マシンの編集 ウィンドウには、修正すべき項目を確認することのできる新たな検証および警告が表示されます。問題が自動的に修正され、仮想マシンの設定を再度保存するだけで十分な場合もあります。それぞれの仮想マシンを編集したら、クラスターの互換バージョンを変更することができます。
次に、クラスター内の仮想マシンのクラスターの互換バージョンを更新してください。
4.1.7. 仮想マシンのクラスター互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
クラスターの互換バージョンを更新したら、実行中またはサスペンド中のすべての仮想マシンについてクラスターの互換バージョンを更新する必要があります。そのためには、管理ポータルから再起動するか、REST API を使用して、またはゲストオペレーティングシステム内から更新する必要があります。再起動が必要な仮想マシンには、変更が保留されていることを示すアイコン (
) が付きます。
別途適切な時期に仮想マシンを再起動することもできますが、仮想マシンで最新の設定が使用されるように、直ちに再起動することを強く推奨します。再起動していない仮想マシンは以前の設定で動作し、さらに仮想マシンの設定が変更された場合には、保留中のクラスターの互換バージョンが上書きされる場合があります。
手順
- 管理ポータルで → をクリックします。
再起動が必要な仮想マシンを確認します。Vms: 検索バーに以下のクエリーを入力します。
next_run_config_exists=True
next_run_config_exists=TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 検索結果に、変更が保留中の仮想マシンがすべて表示されます。
- それぞれの仮想マシンを選択し、再起動 をクリックします。あるいは、必要な場合は、仮想マシン自体から仮想マシンを再起動することができます。
仮想マシンが起動すると、新しい互換バージョンが自動的に適用されます。
プレビュー状態にある仮想マシンスナップショットについては、クラスターの互換バージョンを変更することができません。まずコミットするか、プレビューを取り消す必要があります。
次に、データセンターの互換バージョンを更新してください。
4.1.8. データセンターの互換バージョンの変更 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Virtualization データセンターには、互換バージョンがあります。互換バージョンとは、データセンターが互換性を持つ Red Hat Virtualization のバージョンを指します。データセンター内のクラスターは、すべて指定の互換性レベルをサポートする必要があります。
前提条件
- データセンターの互換レベルを変更するには、事前にデータセンター内のクラスターおよび仮想マシンの互換バージョンがすべて更新されている必要があります。
手順
- 管理ポータルで → をクリックします。
- 変更を行うデータセンターを選択し、 をクリックします。
- 互換バージョン を必要な値に変更します。
- をクリックします。データセンターの互換バージョンを変更 の確認ダイアログが開きます。
- をクリックして確定します。
ホストを個別に更新することもできます。
4.1.9. 個々のホストの更新 リンクのコピーリンクがクリップボードにコピーされました!
ホストのアップグレードマネージャーを使用して、管理ポータルから直接個々のホストを更新します。
アップグレードマネージャーが確認するのは、ステータスが Up または Non-operational のホストだけです。ステータスが Maintenance のホストは確認されません。
制限事項
-
RHVH の更新時には、
/etcおよび/varディレクトリーに変更されたコンテンツのみを保持します。他のパスに含まれる変更されたデータは更新時に上書きされます。 - クラスターの移行が有効化されている場合には、仮想マシンはそのクラスター内の別のホストに自動的に移行されます。使用率が比較的に低い時間帯にホストを更新してください。
- セルフホスト型エンジン環境では、Manager 用仮想マシンは同一クラスター内のセルフホスト型エンジンノード間でのみ移行が可能です。通常のホストに移行することはできません。
- ホストが属するクラスターには、ホストがメンテナンスを実行するのに十分なメモリーが確保されている必要があります。確保されていないと、仮想マシンの移行がハングして失敗してしまいます。ホストを更新する前に一部またはすべての仮想マシンをシャットダウンしておくと、ホスト更新によるメモリー使用量を低減することができます。
- すべてのホストを同時に更新しないでください。Storage Pool Manager (SPM) のタスクを実行するために、1 台のホストは使用可能な状態でなければなりません。
- ホストに固定された仮想マシン (vGPU を使用している仮想マシンなど) を別のホストに移行することはできません。ホストを更新する前に、固定された仮想マシンをシャットダウンする必要があります。
手順
適切なリポジトリーが有効であることを確認します。現在有効なリポジトリーの一覧を表示するには、
dnf repolistを実行します。Red Hat Virtualization Host の場合:
subscription-manager repos --enable=rhvh-4-for-rhel-8-x86_64-rpms
# subscription-manager repos --enable=rhvh-4-for-rhel-8-x86_64-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Enterprise Linux ホストの場合:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記RHEL 8.6 EUS チャンネルは、RHEL 8.7 がリリースされるまで利用できない場合があります。
- 管理ポータルで → をクリックし、更新するホストを選択します。
→ をクリックしてから をクリックします。
通知ドロワー (
) を開き、イベント セクションを展開して結果を表示します。
- 更新が利用可能であれば、 → をクリックします。
をクリックしてホストを更新します。実行中の仮想マシンは、その移行ポリシーに従って移行されます。いずれかの仮想マシンの移行が無効になっている場合は、シャットダウンするよう求められます。
→ にホストの情報が更新され、ステータスが以下の順序で変わります。
Maintenance > Installing > Reboot > Up
注記更新が失敗すると、ホストのステータスは Install Failed に変わります。Install Failed のステータスから → を再度クリックすることができます。
Red Hat Virtualization 環境内のホストごとに同じ手順を繰り返してください。
管理ポータルからホストを更新する必要があります。ただし、管理ポータルの代わりに dnf upgrade を使用してホストを更新することもできます。
4.1.10. ホストの手動更新 リンクのコピーリンクがクリップボードにコピーされました!
この情報は、Red Hat では更新方法をサポートしていないけれども、ホストを手動で更新する必要がある上級システム管理者向けに提供されます。証明書の更新を含む重要な手順には高度な知識が必要と想定されることから、これらに関する情報は、このトピックで説明する手順には含まれていません。Red Hat は、管理ポータルを使用したホストの更新をサポートします。詳細は、Administration Guide の Updating individual hosts または Updating all hosts in a cluster を参照してください。
dnf コマンドを使用して、ホストを更新できます。セキュリティーやバグに関する修正がタイムリーに適用されるように、システムを定期的に更新してください。
制限事項
-
RHVH の更新時には、
/etcおよび/varディレクトリーに変更されたコンテンツのみを保持します。他のパスに含まれる変更されたデータは更新時に上書きされます。 - クラスターの移行が有効化されている場合には、仮想マシンはそのクラスター内の別のホストに自動的に移行されます。使用率が比較的に低い時間帯にホストを更新してください。
- セルフホスト型エンジン環境では、Manager 用仮想マシンは同一クラスター内のセルフホスト型エンジンノード間でのみ移行が可能です。通常のホストに移行することはできません。
- ホストが属するクラスターには、ホストがメンテナンスを実行するのに十分なメモリーが確保されている必要があります。確保されていないと、仮想マシンの移行がハングして失敗してしまいます。ホストを更新する前に一部またはすべての仮想マシンをシャットダウンしておくと、ホスト更新によるメモリー使用量を低減することができます。
- すべてのホストを同時に更新しないでください。Storage Pool Manager (SPM) のタスクを実行するために、1 台のホストは使用可能な状態でなければなりません。
- ホストに固定された仮想マシン (vGPU を使用している仮想マシンなど) を別のホストに移行することはできません。ホストを更新する前に、固定された仮想マシンをシャットダウンする必要があります。
手順
適切なリポジトリーが有効であることを確認します。
dnf repolistを実行して、現在有効なリポジトリーを確認することができます。Red Hat Virtualization Host の場合:
subscription-manager repos --enable=rhvh-4-for-rhel-8-x86_64-rpms
# subscription-manager repos --enable=rhvh-4-for-rhel-8-x86_64-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Enterprise Linux ホストの場合:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記RHEL 8.6 EUS チャンネルは、RHEL 8.7 がリリースされるまで利用できない場合があります。
- 管理ポータルで → をクリックし、更新するホストを選択します。
- → をクリックしてから をクリックします。
Red Hat Enterprise Linux ホストの場合:
Red Hat Enterprise Linux の現行バージョンを特定します。
cat /etc/redhat-release
# cat /etc/redhat-releaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow redhat-release パッケージの利用可能なバージョンを確認します。
dnf --refresh info --available redhat-release
# dnf --refresh info --available redhat-releaseCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドは、利用可能な更新をすべて表示します。たとえば、Red Hat Enterprise Linux 8.2.z から 8.3 にアップグレードする場合は、パッケージのバージョンを、現在インストールされているバージョンと比較します。
Available Packages Name : redhat-release Version : 8.3 Release : 1.0.el8 …
Available Packages Name : redhat-release Version : 8.3 Release : 1.0.el8 …Copy to Clipboard Copied! Toggle word wrap Toggle overflow Important通常、Red Hat Enterprise Linux Advanced Virtualization モジュールは、Red Hat Enterprise Linux y-stream よりも遅れてリリースされます。新しい Advanced Virtualization モジュールがまだ利用できない場合や、有効化した際にエラーが発生した場合は、ここで停止してアップグレードを取り消します。取り消さない場合は、ホストが破損するリスクがあります。
Red Hat Enterprise Linux 8.3 以降の Advanced Virtualization ストリームが利用できる場合は、
virtモジュールをリセットします。dnf module reset virt
# dnf module reset virtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Advanced Virtualization ストリームでこのモジュールがすでに有効になっている場合は、このステップは必要なく、マイナス要因となることもありません。
以下を入力してストリームの値を確認できます。
dnf module list virt
# dnf module list virtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のコマンドを使用して、Advanced Virtualization ストリームで
virtモジュールを有効にします。RHV 4.4.2 の場合
dnf module enable virt:8.2
# dnf module enable virt:8.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHV 4.4.3~4.4.5 に対応しています。
dnf module enable virt:8.3
# dnf module enable virt:8.3Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHV 4.4.6 から 4.4.10 の場合:
dnf module enable virt:av
# dnf module enable virt:avCopy to Clipboard Copied! Toggle word wrap Toggle overflow RHV 4.4 以降の場合:
dnf module enable virt:rhel
# dnf module enable virt:rhelCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記RHEL 8.6 以降、Advanced Virtualization パッケージは標準の
virt:rhelモジュールを使用します。RHEL 8.4 および 8.5 では、1 つの Advanced Virtualization ストリームrhel:avのみが使用されます。
nodejsモジュールのバージョン 14 を有効にします。dnf module -y enable nodejs:14
# dnf module -y enable nodejs:14Copy to Clipboard Copied! Toggle word wrap Toggle overflow ホストを更新します。
dnf upgrade --nobest
# dnf upgrade --nobestCopy to Clipboard Copied! Toggle word wrap Toggle overflow すべての更新が正常に適用されるように、ホストを再起動します。
注記imgbased ログを確認して、Red Hat Virtualization Host 向けの追加パッケージの更新に失敗したものがないかを確認します。更新後に一部のパッケージの再インストールに失敗した場合には、そのパッケージが /var/imgbased/persisted-rpms に記載されていることを確認します。足りないパッケージを追加してから
rpm -Uvh /var/imgbased/persisted-rpms/*を実行します。
Red Hat Virtualization 環境内のホストごとに同じ手順を繰り返してください。
付録A Red Hat Virtualization Manager をオフラインでインストールするためのローカルリポジトリーの更新 リンクのコピーリンクがクリップボードにコピーされました!
ローカルリポジトリーから FTP 経由でパッケージを受信するマシン上に Red Hat Virtualization Manager がホストされている場合には、そのリポジトリーを定期的に同期してコンテンツ配信ネットワークからパッケージの更新をダウンロードしてから、マシンの更新またはアップグレードを行う必要があります。更新パッケージは、セキュリティー問題、バグ修正、拡張機能の追加に対応します。
リポジトリーをホストするシステムで、リポジトリーを同期して利用可能な各パッケージの最新バージョンをダウンロードします。
reposync --newest-only /var/ftp/pub/rhevrepo
# reposync --newest-only /var/ftp/pub/rhevrepoCopy to Clipboard Copied! Toggle word wrap Toggle overflow このコマンドにより多数のパッケージがダウンロードされ、完了するまで長時間を要する場合があります。
- Manager マシンでリポジトリーが利用可能であることを確認してから、マシンを更新/アップグレードします。
付録B ローカルリポジトリーからの RHV ハイパーバイザーのインストール リンクのコピーリンクがクリップボードにコピーされました!
お使いのシステムで Red Hat Satellite がないプライベートの Red Hat Virtualization(RHV) 環境を使用する場合は、Red Hat がホストするコンテンツ配信ネットワーク (CDN) ではなく、ローカルの RHEL システムでホストされるリポジトリーから RHV ハイパーバイザー (RHV-H) をインストールする必要がある場合があります。
手順
オフラインリポジトリーをホストするシステムで、以下のような内容で
/etc/yum.repos.d/rhvh-mirror.repoという名前のファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 適切な証明書およびキーが含まれるファイルに対して、
sslclientcertおよびsslclientkeyフィールドに完全パス名を設定する必要があります。/etc/pki/entitlementディレクトリーには、証明書とキーファイルのペアが 1 つ以上含まれますが、1 つのペアには必要な RHV-H エンタイトルメントのみが含まれます。証明書ファイルを検索するには、次のコマンドを実行します。
/etc/pki/entitlementディレクトリーのファイルの一覧を表示します。ls -al /etc/pki/entitlement/
# ls -al /etc/pki/entitlement/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような出力が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHV -H エンタイトルメントを含むものを検索するには、各証明書で
rct cat-certコマンドを使用します。cd /etc/pki/entitlement/ rct cat-cert 5659494963772844103.pem | grep rhvh/4/ | grep URL
# cd /etc/pki/entitlement/ # rct cat-cert 5659494963772844103.pem | grep rhvh/4/ | grep URLCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような出力が表示されます。
URL: /content/beta/rhel/server/7/$basearch/rhvh/4/os URL: /content/dist/rhel/server/7/7Server/$basearch/rhvh/4/os URL: /content/beta/layered/rhel8/x86_64/rhvh/4/os URL: /content/dist/layered/rhel8/x86_64/rhvh/4/osURL: /content/beta/rhel/server/7/$basearch/rhvh/4/os URL: /content/dist/rhel/server/7/7Server/$basearch/rhvh/4/os URL: /content/beta/layered/rhel8/x86_64/rhvh/4/os URL: /content/dist/layered/rhel8/x86_64/rhvh/4/osCopy to Clipboard Copied! Toggle word wrap Toggle overflow
正しい証明書を特定し、前述の
.repoファイルのsslclientcertおよびsslclientkeyの値を入力します。sslclientcert = /etc/pki/entitlement/5659494963772844103.pem sslclientkey = /etc/pki/entitlement/5659494963772844103-key.pem
sslclientcert = /etc/pki/entitlement/5659494963772844103.pem sslclientkey = /etc/pki/entitlement/5659494963772844103-key.pemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 適切なディレクトリーで
reposyncコマンドを実行します。正しいパスを確認するには、'pwd' コマンドを使用します。
pwd
# pwdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような出力が表示されます。
/home/test/rhvh-reposync
/home/test/rhvh-reposyncCopy to Clipboard Copied! Toggle word wrap Toggle overflow reposyncコマンドを実行します。reposync --repo rhvh-4-for-rhel-8-x86_64-rpms
# reposync --repo rhvh-4-for-rhel-8-x86_64-rpmsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のような出力が表示されます。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Subscription Manager サブシステムが定期的に再生成されるため、
reposyncコマンドを実行するたびに証明書とキーファイルのペアを確認します。
付録C 法的通知 リンクのコピーリンクがクリップボードにコピーされました!
Copyright © 2022 Red Hat, Inc.
Licensed under the (Creative Commons Attribution–ShareAlike 4.0 International License).Derived from documentation for the (oVirt Project).If you distribute this document or an adaptation of it, you must provide the URL for the original version.
Modified versions must remove all Red Hat trademarks.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent.Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission.We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.