検索

1.2. Red Hat Virtualization 4.2 から 4.3 へのセルフホストエンジンのアップグレード

download PDF

セルフホストエンジン環境をバージョン 4.2 から 4.3 にアップグレードする手順は、以下のとおりです。

1.2.1. 前提条件

  • 仮想マシンで必要となるダウンタイムについて計画している。アップグレードプロセスでクラスターの互換バージョンを更新した後、それぞれの仮想マシンを再起動すると新しいハードウェア設定が自動的に適用されます。すべての実行中またはサスペンド中の仮想マシンを直ちに再起動して、設定変更を適用する必要があります。
  • お使いの環境が Red Hat Virtualization 4.4 の要件を満たしている。すべての前提条件の一覧は、プランニングおよび前提条件ガイドの 前提条件 を参照してください。
  • Red Hat Virtualization Manager をアップグレードする場合には、既存ホストのいずれかを使用することが推奨される。新規ホストの使用を選択する場合は、アップグレード手順を開始する前に、新規ホストに一意の名前を割り当ててから、既存のクラスターに追加する必要があります。

1.2.2. 環境の分析

更新の実行やトラブルシューティングを行う前に、Log Collection Analysis ツールおよび Image Discrepancies ツールを実行することが推奨されます。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。

1.2.3. Log Collection Analysis ツール

更新の実行前に Log Collection Analysis ツールを実行し、トラブルシューティングを行います。このツールは、お使いの環境を分析し、更新の実行を妨げる可能性のある既知の問題を表示して、推奨される解決方法を提供します。ツールはシステムに関する詳細情報を収集し、それを HTML ファイルとして提示します。

前提条件

  • Manager マシンで正しいリポジトリーが有効になっていることを確認します。Red Hat Virtualization 4.2 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。

    Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。

手順

  1. Manager マシンに Log Collection Analysis ツールをインストールします。

    # yum install rhv-log-collector-analyzer
  2. ツールを実行します。

    # rhv-log-collector-analyzer --live

    詳細なレポートが表示されます。

    デフォルトでは、レポートは analyzer_report.html という名前のファイルに保存されます。

    ファイルを特定の場所に保存するには --html フラグを使用して場所を指定します。

    # rhv-log-collector-analyzer --live --html=/directory/filename.html
  3. ELinks テキストモードの Web ブラウザーを使用して、ターミナル内のアナライザーレポートを読み取ることができます。ELinks ブラウザーをインストールするには、以下を実行します。

    # yum install -y elinks
  4. ELinks を起動し、analyzer_report.html を開きます。

    # elinks /home/user1/analyzer_report.html

    レポート内を移動するには、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 で導入されました。
  • データ収集は異なる場所で同時に実行され、アトミックではないため、ストレージドメインを変更する可能性のある環境内のすべてのアクティビティーを停止する。つまり、スナップショットの作成や削除、ディスクの編集、移動、作成、削除は行わないでください。行った場合、不一致の誤検出が発生する可能性があります。プロセス中、仮想マシンは正常に動作し続けることができます。

手順

  1. ツールを実行するには、RHV Manager で次のコマンドを入力します。

    # rhv-image-discrepancies
  2. ツールが不一致を検出したら、再実行して結果を確認します。ツールの実行中に一部の操作が実行された可能性がある場合、特に注意が必要です。
注記

このツールには Export および ISO ストレージドメインが含まれており、そのストレージドメインの不一致が報告される可能性があります。報告された場合、これらのストレージドメインは RHV データベースにはこれらのストレージドメインのイメージエントリーがないため、無視できます。

結果について

このツールは以下を報告します。

  • ストレージに表示されているがデータベースにはないボリュームがある場合、またはデータベースに表示されているがストレージにはないボリュームがある場合
  • 一部のボリューム属性がストレージとデータベースで異なる場合

出力サンプル

 Checking storage domain c277ad93-0973-43d9-a0ca-22199bc8e801
    Looking for missing images...
    No missing images found
    Checking discrepancies between SD/DB attributes...
    image ef325650-4b39-43cf-9e00-62b9f7659020 has a different attribute capacity on storage(2696984576) and on DB(2696986624)
    image 852613ce-79ee-4adc-a56a-ea650dcb4cfa has a different attribute capacity on storage(5424252928) and on DB(5424254976)

 Checking storage domain c64637b4-f0e8-408c-b8af-6a52946113e2
    Looking for missing images...
    No missing images found
    Checking discrepancies between SD/DB attributes...
    No discrepancies found

1.2.4. グローバルメンテナンスモードの有効化

Manager 用仮想マシンの設定またはアップグレード作業を実施する前に、セルフホスト型エンジン環境をグローバルメンテナンスモードに切り替える必要があります。

手順

  1. セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを有効にします。

    # hosted-engine --set-maintenance --mode=global
  2. 作業を進める前に、環境がグローバルメンテナンスモードにあることを確認します。

    # hosted-engine --vm-status

    クラスターがグローバルメンテナンスモードにあることを示すメッセージが表示されるはずです。

1.2.5. Red Hat Virtualization Manager の更新

前提条件

  • Manager マシンで正しいリポジトリーが有効化になっている。Red Hat Virtualization 4.2 に必要なリポジトリーの一覧は、Red Hat Virtualization Manager リポジトリーの有効化 を参照してください。

    Red Hat Virtualization Manager の更新は、コンテンツ配信ネットワーク (CDN) 経由でリリースされます。

手順

  1. Manager マシンで、更新されたパッケージが利用可能かどうかを確認します。

    # engine-upgrade-check
  2. setup パッケージを更新します。

    # yum update ovirt\*setup\* rh\*vm-setup-plugins
  3. engine-setup スクリプトで Red Hat Virtualization Manager を更新します。engine-setup スクリプトにより、設定に関する質問への回答が求められます。その後、ovirt-engine サービスの停止、更新パッケージのダウンロード/インストール、データベースのバックアップ/更新、インストール後設定の実施を経てから、ovirt-engine サービスが起動します。

    # engine-setup

    スクリプトが正常に完了すると、以下のメッセージが表示されます。

    Execution of setup completed successfully
    注記

    engine-setup スクリプトは、Red Hat Virtualization Manager のインストールプロセス中にも使用され、指定した設定値が保存されます。更新時に、設定をプレビューすると保存された値が表示されますが、インストール後に engine-config を使用して設定を更新した場合、この値は最新ではない可能性があります。たとえば、インストール後に engine-config を使用して SANWipeAfterDeletetrue に更新した場合、engine-setup は設定プレビューに "Default SAN wipe after delete: False" を出力します。ただし、更新された値が engine-setup によって上書きされることはありません。

    重要

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

  4. Manager にインストールされているベースオペレーティングシステムと、オプションパッケージを更新します。

    # yum update --nobest
    重要

    更新中に必要な Ansible パッケージの競合が発生した場合は、RHV Manager で yum update を実行できない (ansible の競合) を参照してください。

    重要

    いずれかのカーネルパッケージが更新された場合には、マシンを再起動して更新を完了してください。

1.2.6. Red Hat Virtualization Manager の 4.2 から 4.3 へのアップグレード

アップグレードしているマシンにログインする必要があります。

重要

アップグレードに失敗すると、engine-setup コマンドは Red Hat Virtualization Manager のインストールを以前の状態に復元しようとします。このため、アップグレードが完了するまで、以前のバージョンのリポジトリーを削除しないでください。アップグレードに失敗すると、engine-setup スクリプトによりインストールの復元方法を説明します。

手順

  1. 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

    その他のリポジトリーはすべて、Red Hat Virtualization リリース全体を通して同じになります。

  2. setup パッケージを更新します。

    # yum update ovirt\*setup\* rh\*vm-setup-plugins
  3. engine-setup を実行し、プロンプトに従って Red Hat Virtualization Manager をアップグレードします。

    # engine-setup

    スクリプトが正常に完了すると、以下のメッセージが表示されます。

    Execution of setup completed successfully
  4. 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
  5. ベースオペレーティングシステムを更新します。

    # yum update
    重要

    更新中に必要な Ansible パッケージの競合が発生した場合は、RHV Manager で yum update を実行できない (ansible の競合) を参照してください。

    重要

    いずれかのカーネルパッケージが更新された場合には、マシンを再起動してアップグレードを完了してください。

Manager はバージョン 4.3 にアップグレードされました。

1.2.7. グローバルメンテナンスモードの無効化

手順

  1. Manager 用仮想マシンにログインし、シャットダウンします。
  2. セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを無効にします。

    # hosted-engine --set-maintenance --mode=none

    グローバルメンテナンスモードを終了すると、ovirt-ha-agent が Manager 用仮想マシンを起動し、続いて Manager が自動的に起動します。Manager が起動するまでに最大で 10 分程度かかる場合があります。

  3. 環境が動作していることを確認します。

    # hosted-engine --vm-status

    情報の一覧に、Engine status が含まれます。Engine status の値は、以下のようになるはずです。

    {"health": "good", "vm": "up", "detail": "Up"}
    注記

    仮想マシンが起動中で Manager がまだ動作していない場合、Engine status は以下のようになります。

    {"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}

    このような場合には、数分間待ってからやり直してください。

次に、セルフホストエンジンノードを更新し、続いて通常のホストを更新してください。手順は、両方のホストタイプで同じです。

1.2.8. クラスター内の全ホストの更新

ホストを個別に更新するのではなく、クラスター内の全ホストを更新することができます。この手法は、Red Hat Virtualization を新しいバージョンにアップグレードする際に特に役立ちます。更新の自動化に使用する Ansible ロールの詳細は、oVirt クラスターアップグレード を参照してください。

クラスターは一度に 1 つずつ更新します。

制限

  • RHVH を更新すると、/etc および /var ディレクトリー内の変更されたコンテンツのみ保持されます。他のパスに含まれる変更されたデータは、更新時に上書きされます。
  • クラスターの移行が有効な場合、仮想マシンはそのクラスター内の別のホストに自動的に移行されます。
  • セルフホスト型エンジン環境では、Manager 用仮想マシンは同一クラスター内のセルフホスト型エンジンノード間でのみ移行が可能です。通常のホストに移行することはできません。
  • ホストが属するクラスターには、ホストがメンテナンスを実行するのに十分なメモリーが確保されている必要があります。確保されていないと、仮想マシンの移行がハングして失敗してしまいます。ホストを更新する前に一部またはすべての仮想マシンをシャットダウンしておくと、ホスト更新によるメモリー使用量を減らすことができます。
  • ホストに固定された仮想マシン (vGPU を使用している仮想マシンなど) を別のホストに移行することはできません。ホストをスキップするよう選択した場合を除き、更新中は固定された仮想マシンはシャットダウンされます。

手順

  1. 管理ポータルで Compute Clusters をクリックし、クラスターを選択します。Upgrade status 列には、クラスターの任意のホストでアップグレードが利用可能かどうかが表示されます。
  2. Upgrade をクリックします。
  3. 更新するホストを選択し、次に Next をクリックします。
  4. オプションを設定します。

    • Stop Pinned VMs: クラスター内のホストに固定された仮想マシンをシャットダウンします。このオプションは、デフォルトで選択されています。このチェックボックスの選択を解除すると、固定された仮想マシンが動作を続けられるように、それらのホストの更新をスキップすることができます (固定された仮想マシンが重要なサービスまたはプロセスを実行中で、更新中の予期せぬ時にシャットダウンされるのを避けたい場合など)。
    • Upgrade Timeout (Minutes): このオプションで設定した時間内に個々のホストの更新が完了しない場合、クラスターのアップグレードはタイムアウトで失敗します。デフォルトは 60 です。60 分では不十分と思われる大規模なクラスターの場合は、時間を延長することができます。また、ホストの更新が短時間で完了する小規模なクラスターは、短縮することができます。
    • Check Upgrade: アップグレードプロセスを実行する前に、それぞれのホストで更新が利用可能かどうかを確認します。このオプションは、デフォルトでは選択されていません。ただし、Manager がホストの更新を確認する頻度をデフォルトより低く設定している状況などで、最新の更新を確実に含める必要がある場合は、このオプションを選択することができます。
    • Reboot After Upgrade: ホストの更新後に、それぞれのホストを再起動します。このオプションは、デフォルトで選択されています。ホストを再起動する必要のある保留中の更新がないことが明らかであれば、このチェックボックスの選択を解除してプロセスを迅速化することができます。
    • Use Maintenance Policy: 更新時にクラスターのスケジューリングポリシーを cluster_maintenance に設定します。このオプションはデフォルトで選択されています。したがって、許可される動作は限定的で、仮想マシンは高可用性でない限り起動できません。更新中も使用を続けたいカスタムのスケジューリングポリシーがある場合は、このチェックボックスの選択を解除できます。ただし、解除することで想定外の結果が生じる可能性があります。このオプションを無効にする前に、カスタムのポリシーがクラスターのアップグレード操作に対応していることを確認してください。
  5. Next をクリックします。
  6. 影響を受けるホストと仮想マシンの概要を確認します。
  7. Upgrade をクリックします。
  8. クラスターのアップグレードステータス画面が表示され、完了の割合を示す進行状況バーと、完了したアップグレードプロセスの手順のリストが表示されます。Go to Event Log をクリックして、アップグレードのログエントリーを開くことができます。この画面を閉じても、アップグレードプロセスは中断されません。

以下で、ホスト更新の進捗状況を追跡できます。

  • Compute Clusters ビュー (Upgrade Status 列に完了率を示す進捗バーが表示されます)
  • Compute Hosts ビュー
  • 通知ドロワーイベント セクション ( EventsIcon )

仮想マシン移行の進捗を、Compute Virtual Machines ビューの Status 列で個々に追跡できます。大規模な環境では、特定の仮想マシングループの結果を表示するために、結果を絞り込まなければならない場合があります。

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. 管理ポータルで、Compute Clusters をクリックします。
  2. 変更を行うクラスターを選択し、Edit をクリックします。
  3. General タブで Compatibility Version を必要な値に変更します。
  4. OK をクリックします。Change Cluster Compatibility Version の確認ダイアログが開きます。
  5. OK をクリックして確定します。
重要

一部の仮想マシンおよびテンプレートが不適切に設定されていることを警告するエラーメッセージが表示される場合があります。このエラーを修正するには、それぞれの仮想マシンを手動で編集します。Edit Virtual Machine ウィンドウには、修正が必要な項目を示す追加の検証および警告が表示されます。問題が自動的に修正され、仮想マシンの設定を再度保存するだけで十分な場合もあります。それぞれの仮想マシンを編集したら、クラスターの互換バージョンを変更することができます。

1.2.10. 仮想マシンのクラスター互換バージョンの変更

クラスターの互換バージョンを更新したら、実行中または一時停止中のすべての仮想マシンについてクラスターの互換バージョンを更新する必要があります。そのためには、管理ポータルから再起動するか、REST API を使用するか、ゲストオペレーティングシステム内から更新する必要があります。再起動が必要な仮想マシンには、変更が保留されていることを示すアイコン ( pendingchanges ) が付きます。

Manager 用仮想マシンを再起動する必要はありません。

別途適切な時期に仮想マシンを再起動することもできますが、仮想マシンで最新の設定が使用されるように、直ちに再起動することを強く推奨します。再起動していない仮想マシンは以前の設定で動作し、さらに仮想マシンの設定が変更された場合には、保留中のクラスターの互換バージョンが上書きされる場合があります。

手順

  1. 管理ポータルで Compute Virtual Machines をクリックします。
  2. 再起動が必要な仮想マシンを確認します。Vms: 検索バーに以下のクエリーを入力します。

    next_run_config_exists=True

    検索結果に、変更が保留中の仮想マシンがすべて表示されます。

  3. それぞれの仮想マシンを選択し、Restart をクリックします。あるいは、必要な場合は、仮想マシン自体から仮想マシンを再起動することができます。

仮想マシンが起動すると、新しい互換バージョンが自動的に適用されます。

注記

プレビュー状態にある仮想マシンスナップショットについては、クラスターの互換バージョンを変更することができません。まずコミットするか、プレビューを取り消す必要があります。

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

Red Hat Virtualization データセンターには、互換バージョンがあります。互換バージョンとは、データセンターが互換性を持つ Red Hat Virtualization のバージョンを指します。データセンター内のすべてのクラスターは、指定の互換性レベルをサポートする必要があります。

前提条件

  • データセンターの互換レベルを変更するには、データセンター内のクラスターおよび仮想マシンの互換バージョンが、事前にすべて更新されている必要があります。

手順

  1. 管理ポータルで Compute Data Centers をクリックします。
  2. 変更を行うデータセンターを選択し、Edit をクリックします。
  3. Compatibility Version を必要な値に変更します。
  4. OK をクリックします。Change Data Center Compatibility Version の確認ダイアログが開きます。
  5. OK をクリックして確定します。

以前に 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 署名を使用できるようにするための特別な手順は必要ありません。

警告

証明書の有効期限が 切れない ようにしてください。有効期限が切れると、環境は応答しなくなり、復元はエラーが発生しやすい時間のかかるプロセスになります。証明書の更新は、管理ガイド有効期限が切れる前の証明書更新 を参照してください。

ブラウザーでの警告メッセージ表示の防止
  1. Manager マシンに root ユーザーとしてログインします。
  2. /etc/pki/ovirt-engine/openssl.confdefault_md = sha256 の行が含まれているかどうかを確認します。

    # cat /etc/pki/ovirt-engine/openssl.conf

    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
  3. 署名し直す必要のある証明書を定義します。

    # names="apache"
  4. セルフホストエンジンノードのいずれかにログインして、グローバルメンテナンスを有効にします。

    # hosted-engine --set-maintenance --mode=global
  5. Manager で、/etc/ovirt-engine/engine.conf.d ディレクトリーと /etc/pki/ovirt-engine ディレクトリーのバックアップを保存し、証明書を再署名します。

    # . /etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf
    # for name in $names; do
        subject="$(
            openssl \
                x509 \
                -in /etc/pki/ovirt-engine/certs/"${name}".cer \
                -noout \
                -subject \
                -nameopt compat \
            | sed \
                's;subject=\(.*\);\1;' \
        )"
       /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
            --name="${name}" \
            --password=mypass \ <1>
            --subject="${subject}" \
            --san=DNS:"${ENGINE_FQDN}" \
            --keep-key
    done
    このパスワード値を変更しないでください。
  6. httpd サービスを再起動します。

    # systemctl restart httpd
  7. セルフホストエンジンノードのいずれかにログインして、グローバルメンテナンスを無効にします。

    # hosted-engine --set-maintenance --mode=none
  8. 管理ポータルに接続して、警告が表示されなくなったことを確認します。
  9. 以前に 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 に置き換える
  1. Manager マシンに root ユーザーとしてログインします。
  2. /etc/pki/ovirt-engine/openssl.confdefault_md = sha256 の行が含まれているかどうかを確認します。

    # cat /etc/pki/ovirt-engine/openssl.conf

    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
  3. 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
  4. 既存の証明書を新しい証明書に置き換えます。

    # mv /etc/pki/ovirt-engine/ca.pem.new /etc/pki/ovirt-engine/ca.pem
  5. 署名し直す必要のある証明書を定義します。

    # names="engine apache websocket-proxy jboss imageio-proxy"

    アップグレード後に Red Hat Virtualization Manager SSL 証明書を置き換えている場合は、上記のコマンドの代わりに以下のコマンドを実行します。

    # names="engine websocket-proxy jboss imageio-proxy"

    詳細は、管理ガイドRed Hat Virtualization Manager CA 証明書の置き換え を参照してください。

  6. セルフホストエンジンノードのいずれかにログインして、グローバルメンテナンスを有効にします。

    # hosted-engine --set-maintenance --mode=global
  7. Manager で、/etc/ovirt-engine/engine.conf.d ディレクトリーと /etc/pki/ovirt-engine ディレクトリーのバックアップを保存し、証明書を再署名します。

    # . /etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf
    # for name in $names; do
        subject="$(
            openssl \
                x509 \
                -in /etc/pki/ovirt-engine/certs/"${name}".cer \
                -noout \
                -subject \
                -nameopt compat \
            | sed \
                's;subject=\(.*\);\1;' \
        )"
       /usr/share/ovirt-engine/bin/pki-enroll-pkcs12.sh \
            --name="${name}" \
            --password=mypass \ <1>
            --subject="${subject}" \
            --san=DNS:"${ENGINE_FQDN}" \
            --keep-key
    done
    このパスワード値を変更しないでください。
  8. 以下のサービスを再起動します。

    # systemctl restart httpd
    # systemctl restart ovirt-engine
    # systemctl restart ovirt-websocket-proxy
    # systemctl restart ovirt-imageio
  9. セルフホストエンジンノードのいずれかにログインして、グローバルメンテナンスを無効にします。

    # hosted-engine --set-maintenance --mode=none
  10. 管理ポータルに接続して、警告が表示されなくなったことを確認します。
  11. 以前に CA または https 証明書をブラウザーにインポートしている場合は、その証明書を探してブラウザーから削除し、新しい CA 証明書をインポートし直します。ブラウザーから提供される手順に従って、認証局の証明書をインストールしてください。認証局の証明書を取得するには、http://your-manager-fqdn/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA に移動し、your-manager-fqdn を完全修飾ドメイン名 (FQDN) に置き換えます。
  12. ホストで証明書を登録します。それぞれのホストについて以下の手順を繰り返します。

    1. 管理ポータルで Compute Hosts をクリックします。
    2. ホストを選択し、Management Maintenance をクリックしてから OK をクリックします。
    3. ホストがメンテナンスモードに変わったら、Installation Enroll Certificate をクリックします。
    4. Management Activate をクリックします。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.