3.2. バックアップと移行

3.2.1. Red Hat Virtualization Manager のバックアップと復元

3.2.1.1. Red Hat Virtualization Manager のバックアップ - 概要

engine-backup ツールを使用して、定期的に Red Hat Virtualization Manager のバックアップを作成します。このツールを使用すると、エンジンデータベースおよび設定ファイルが 1 つのファイルにバックアップされ、ovirt-engine サービスを中断することなく実行できます。

3.2.1.2. engine-backup コマンドの構文

engine-backup コマンドは、次の 2 つの基本モードのいずれかで機能します。

# engine-backup --mode=backup

# engine-backup --mode=restore

これらの 2 つのモードは、バックアップの範囲とエンジンデータベースのさまざまな認証情報を指定できる一連のオプションによってさらに拡張されます。オプションとその機能の完全なリストについては、engine-backup --help を実行してください。

基本オプション

--mode

コマンドがバックアップ操作と復元操作のどちらを実行するか指定します。使用可能なオプションは、backup (デフォルトで設定)、restore、および verify です。verify または restore 操作の mode オプションを定義する必要があります。

--file

バックアップモードでバックアップが保存され、リストアモードでバックアップデータとして読み取られるファイルのパスと名前 (たとえば、file_name .backup) を指定します。パスはデフォルトで /var/lib/ovirt-engine-backup/ と定義されます。

--log

バックアップまたは復元操作のログが書き込まれるファイルのパスと名前 (たとえば、log_file_name) を指定します。パスはデフォルトで /var/log/ovirt-engine-backup/ と定義されます。

--scope

バックアップまたは復元操作の範囲を指定します。4 つのオプションがあります。all は、すべてのデータベースおよび設定データをバックアップまたは復元します (デフォルトで設定)。files は、システム上のファイルのみをバックアップまたは復元します。db は、Manager データベースのみをバックアップまたは復元します。dwhdb は、Data Warehouse データベースのみをバックアップまたは復元します。

--scope オプションは、同じ engine-backup コマンドで複数回指定できます。

Manager データベースのオプション

次のオプションは、restore モードで engine-backup コマンドを使用する場合にのみ使用できます。以下のオプション構文は、Manager データベースの復元に適用されます。Data Warehouse データベースを復元するための同じオプションがあります。Data Warehouse オプションの構文は、engine-backup --help を参照してください。

--provision-db: 復元先の Manager データベースバックアップ用の PostgreSQL データベースを作成します。これは、PostgreSQL データベースがまだ設定されていないリモートホストまたは新規インストールで、バックアップを復元する場合に必要なオプションです。このオプションを復元モードで使用すると、--restore-permissions オプションがデフォルトで追加されます。
--provision-all-databases: アーカイブに含まれるすべてのメモリーダンプのデータベースを作成します。有効にすると、これがデフォルトになります。
--change-db-credentials: バックアップ自体に保存されている認証情報以外の認証情報を使用して、Manager データベースを復元するための代替認証情報を指定できます。このオプションで必要な追加パラメーターについては、engine-backup --help を参照してください。
--restore-permissions または --no-restore-permissions: データベースユーザーのパーミッションを復元したり、復元しなかったりします。バックアップを復元する場合は、これらのオプションのいずれかが必要です。復元モードで --provision-* オプションを使用すると、デフォルトで --restore-permissions が適用されます。
注記
バックアップに追加のデータベースユーザーの許可が含まれている場合、--restore-permissions および --provision-db (または --provision-dwh-db) オプションを使用してバックアップを復元すると、ランダムなパスワードを持つ追加のユーザーが作成されます。追加のユーザーが復元したシステムにアクセスする必要がある場合は、これらのパスワードを手動で変更する必要があります。バックアップから Red Hat Virtualization を復元した後に追加のデータベースユーザーにアクセス権を付与する方法を参照してください。

3.2.1.3. engine-backup コマンドを使用してバックアップを作成

Manager がアクティブなときに、engine-backup コマンドを使用して Red Hat Virtualization Manager をバックアップできます。次のいずれかの値を --scope オプションに追加して、バックアップする対象を指定します。

all: Manager 上のすべてのデータベースおよび設定ファイルの完全バックアップ。これは --scope オプションのデフォルト設定です。
files: システム上のファイルのみのバックアップ
db: Manager データベースのみのバックアップ
dwhdb: データウェアハウスデータベースのみのバックアップ
cinderlibdb: Cinderlib データベースのみのバックアップ
grafanadb: Grafana データベースのみのバックアップ

--scope オプションは複数回指定できます。

追加のファイルをバックアップするように engine-backup コマンドを設定することもできます。バックアップしたものすべてを復元します。

重要

データベースを Red Hat Virtualization Manager の新規インストールに復元するには、データベースのバックアップだけでは不十分です。Manager には、設定ファイルへのアクセスも必要です。all 以外のスコープを指定する場合は、--scope=files も含めるか、ファイルシステムをバックアップする必要があります。

engine-backup コマンドの詳細は、Manager マシンで engine-backup --help と入力してください。

手順

Manager マシンにログインします。
バックアップを作成します。
```
# engine-backup
```

次の設定がデフォルトで適用されます。

--scope=all

--mode=backup

このコマンドは、/var/lib/ovirt-engine-backup/file_name.backup にバックアップを生成し、/var/log/ovirt-engine-backup/log_file_name にログファイルを生成します。

file_name.tar を使用して、環境を復元します。

次の例は、いくつかの異なるバックアップシナリオを示しています。

例3.1 完全バックアップ

# engine-backup

例3.2 Manager データベースのバックアップ

# engine-backup --scope=files --scope=db

例3.3 データウェアハウスデータベースのバックアップ

# engine-backup --scope=files --scope=dwhdb

例3.4 バックアップに特定ファイルを追加

engine-backup コマンドの設定のカスタマイズを保存するディレクトリーを作成します。
```
# mkdir -p /etc/ovirt-engine-backup/engine-backup-config.d
```
ntp-chrony.sh という名前の新しいディレクトリーに次の内容のテキストファイルを作成します。
```
BACKUP_PATHS="${BACKUP_PATHS}
/etc/chrony.conf
/etc/ntp.conf
/etc/ovirt-engine-backup"
```
engine-backup コマンドを実行するときは、--scope=files を使用します。バックアップと復元には、/etc/chrony.conf、/etc/ntp.conf、および /etc/ovirt-engine-backup が含まれます。

3.2.1.4. engine-backup コマンドを使用したバックアップの復元

engine-backup コマンドを使用してバックアップを復元する場合、復元先によっては、バックアップを作成するよりも多くの手順が必要です。たとえば、Red Hat Virtualization の既存のインストールの他に、ローカルまたはリモートのデータベースを使用して Red Hat Virtualization の新規インストールにバックアップを復元するために、engine-backup コマンドを使用できます。

重要

バックアップの復元に使用される Red Hat Virtualization Manager のバージョン (4.4.8 など) は、バックアップの作成に使用される Red Hat Virtualization Manager のバージョン (4.4.7 など) 以降である必要があります。Red Hat Virtualization 4.4.7 以降、このポリシーは engine-backup コマンドによって厳密に適用されます。バックアップファイルに含まれている Red Hat Virtualization のバージョンを表示するには、バックアップファイルを解凍し、解凍されたファイルのルートディレクトリーにある version ファイルの値を読み取ります。

3.2.1.5. バックアップを新規インストールに復元

engine-backup コマンドを使用して、Red Hat Virtualization Manager の新規インストールにバックアップを復元できます。以下の手順は、ベースオペレーティングシステムと Red Hat Virtualization Manager に必要なパッケージがインストールされていて、engine-setup コマンドがまだ実行されていないマシンで実行する必要があります。この手順は、バックアップを復元するマシンから 1 つまたは複数のバックアップファイルにアクセスできることを前提としています。

手順

Manager マシンにログインします。エンジンデータベースをリモートホストに復元する場合は、そのホストにログオンして、関連するアクションを実行する必要があります。同様に、Data Warehouse をリモートホストにも復元する場合は、そのホストにログオンして、関連するアクションを実行する必要があります。
完全バックアップまたはデータベースのみのバックアップを復元します。
- 完全バックアップを復元します。
```
# engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db
```
  復元モードで --provision-* オプションを使用すると、デフォルトで --restore-permissions が適用されます。
  完全バックアップの一部として Data Warehouse も復元される場合は、追加のデータベースをプロビジョニングします。
```
engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --provision-dwh-db
```
- 設定ファイルとデータベースバックアップを復元して、データベースのみのバックアップを復元します。
```
# engine-backup --mode=restore --scope=files --scope=db --file=file_name --log=log_file_name --provision-db
```
  上記の例では、Manager データベースのバックアップを復元します。
```
# engine-backup --mode=restore --scope=files --scope=dwhdb --file=file_name --log=log_file_name --provision-dwh-db
```
  上記の例では、Data Warehouse データベースのバックアップを復元します。
  成功すると、次の出力が表示されます。
```
You should now run engine-setup.
Done.
```
次のコマンドを実行し、プロンプトに従って復元された Manager を設定します。
```
# engine-setup
```

Red Hat Virtualization Manager は、バックアップに保存されているバージョンに復元されました。新しい Red Hat Virtualization システムの完全修飾ドメイン名を変更するには、oVirt Engine Rename Tool を参照してください。

3.2.1.6. バックアップを復元して既存のインストールを上書き

engine-backup コマンドを使用すると、Red Hat Virtualization Manager がすでにインストールおよび設定されているマシンに、バックアップを復元できます。これは、環境のバックアップを作成し、その環境に変更を加えた後、バックアップから環境を復元して変更を元に戻したい場合に役立ちます。

バックアップ作成後に環境に加えられた、ホストの追加や削除などの変更は、復元された環境には表示されません。そのような変更はやり直す必要があります。

手順

Manager マシンにログインします。
設定ファイルを削除し、Manager に関連付けられているデータベースをクリーンアップします。
```
# engine-cleanup
```
engine-cleanup コマンドは、Manager データベースのみを削除します。データベースを削除したり、そのデータベースを所有しているユーザーを削除したりすることはありません。
完全バックアップまたはデータベースのみのバックアップを復元します。ユーザーとデータベースがすでに存在しているので、新規のデータベースを作成したり、データベースの認証情報を指定する必要はありません。
- 完全バックアップを復元します。
```
# engine-backup --mode=restore --file=file_name --log=log_file_name --restore-permissions
```
- 設定ファイルおよびデータベースバックアップを復元して、データベースのみのバックアップを復元します。
```
# engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb --file=file_name --log=log_file_name --restore-permissions
```
  注記
  Manager データベースのみを復元するには (たとえば、Data Warehouse データベースが別のマシンにある場合)、-scope=dwhdb パラメーターを省略できます。
  成功すると、次の出力が表示されます。
```
You should now run engine-setup.
Done.
```
Manager を再設定します。
```
# engine-setup
```

3.2.1.7. 異なる認証情報を使用したバックアップの復元

engine-backup コマンドは、Red Hat Virtualization Manager がすでにインストールされセットアップされているマシンにバックアップを復元できますが、バックアップ内のデータベースの認証情報は、バックアップを復元するマシン上のデータベースの認証情報とは異なります。これは、インストールのバックアップを取り、バックアップから別のシステムにインストールを復元する場合に役立ちます。

重要

バックアップを復元して既存のインストールを上書きする場合は、engine-backup コマンドを使用する前に、engine-cleanup コマンドを実行して既存のインストールをクリーンアップする必要があります。engine-cleanup コマンドは、エンジンデータベースをクリーンアップするだけで、データベースを削除したり、そのデータベースを所有しているユーザーを削除したりすることはありません。したがって、新規のデータベースを作成したり、データベースの認証情報を指定する必要はありません。ただし、エンジンデータベースの所有者の認証情報がわからない場合は、バックアップを復元する前に認証情報を変更する必要があります。

手順

Red Hat Virtualization Manager マシンにログインします。
次のコマンドを実行し、プロンプトに従って Manager の設定ファイルを削除し、Manager のデータベースをクリーンアップします。
```
# engine-cleanup
```
engine データベースの所有者のパスワードがわからない場合は、そのユーザーのパスワードを変更します。
1. postgresql コマンドラインを入力します。
```
# su - postgres -c 'psql'
```
2. engine データベースを所有するユーザーのパスワードを変更します。
```
postgres=# alter role user_name encrypted password 'new_password';
```
  必要に応じて、ovirt_engine_history データベースを所有するユーザーに対してこれを繰り返します。
--change-db-credentials パラメーターを使用して完全バックアップまたはデータベースのみのバックアップを復元し、新しいデータベースの認証情報を渡します。Manager に対してローカルなデータベースの database_location は localhost です。
注記
次の例では、パスワードを指定せずにデータベースごとに --*password オプションを使用します。これにより、データベースごとにパスワードの入力を求められます。別の方法として、データベースごとに --*passfile=password_file オプションを使用して、対話型プロンプトを必要とせずに、パスワードを engine-backup ツールに安全に渡すことができます。
- 完全バックアップを復元します。
```
# engine-backup --mode=restore --file=file_name --log=log_file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password --no-restore-permissions
```
  Data Warehouse も完全バックアップの一部として復元される場合は、追加のデータベースの改訂された認証情報を含めます。
```
engine-backup --mode=restore --file=file_name --log=log_file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password --change-dwh-db-credentials --dwh-db-host=database_location --dwh-db-name=database_name --dwh-db-user=ovirt_engine_history --dwh-db-password --no-restore-permissions
```
- 設定ファイルおよびデータベースバックアップを復元して、データベースのみのバックアップを復元します。
```
# engine-backup --mode=restore --scope=files --scope=db --file=file_name --log=log_file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password --no-restore-permissions
```
  上記の例では、Manager データベースのバックアップを復元します。
```
# engine-backup --mode=restore --scope=files --scope=dwhdb --file=file_name --log=log_file_name --change-dwh-db-credentials --dwh-db-host=database_location --dwh-db-name=database_name --dwh-db-user=ovirt_engine_history --dwh-db-password --no-restore-permissions
```
  上記の例では、Data Warehouse データベースのバックアップを復元します。
  成功すると、次の出力が表示されます。
```
You should now run engine-setup.
Done.
```
次のコマンドを実行し、プロンプトに従ってファイアウォールを再設定し、ovirt-engine サービスが正しく設定されていることを確認します。
```
# engine-setup
```

3.2.1.8. セルフホスト型エンジンのバックアップおよび復元

セルフホスト型エンジンをバックアップして、新しいセルフホスト環境に復元できます。この手順は、環境を別のストレージタイプの新しいセルフホスト型エンジンストレージドメインに移行するなどのタスクに使用します。

デプロイメント中にバックアップファイルを指定すると、バックアップは、新しいセルフホスト型エンジンストレージドメインを使用して、新しい Manager 仮想マシンに復元されます。古い Manager が削除されます。また、古いセルフホスト型エンジンストレージドメインの名前が変更され、新しい環境が正しく機能していることが確認された後で、これを手動で削除できます。新規ホストにデプロイすることを強く推奨します。デプロイメントに使用されたホストがバックアップ環境に存在している場合、新しい環境で競合を回避するために、復元されたデータベースから削除されます。新しいホストにデプロイする場合は、ホストに一意の名前を割り当てる必要があります。バックアップに含まれる既存ホストの名前を再利用すると、新しい環境で競合が発生する可能性があります。

バックアップと復元の操作には、次の主要なアクションが含まれます。

この手順の前提として、移行元の Manager に対するアクセス権があり、変更を加えることできる必要があります。

前提条件

Manager とホスト用に用意された完全修飾ドメイン名。正引き (フォワードルックアップ) と逆引き (リバースルックアップ) の記録は、両方とも DNS で設定する必要があります。新しい Manager は、元の Manager と同じ完全修飾ドメイン名を持っている必要があります。
元の Manager を最新のマイナーバージョンに更新する。バックアップの復元に使用される Red Hat Virtualization Manager のバージョン (4.4.8 など) は、バックアップの作成に使用される Red Hat Virtualization Manager のバージョン (4.4.7 など) 以降である必要があります。Red Hat Virtualization 4.4.7 以降、このポリシーは engine-backup コマンドによって厳密に適用されます。アップグレードガイド の Red Hat Virtualization Manager の更新を参照してください。
注記
バックアップを復元する必要があるが、新しいアプライアンスがない場合、復元プロセスを一時停止し、SSH 経由で一時的な Manager マシンにログインしてチャンネルの登録、サブスクライブ、設定を適宜行い、Manager パッケージをアップグレードしてから復元プロセスを再開できます。
更新されたストレージバージョンとの互換性を確保するために、データセンターの互換性レベルを最新バージョンに設定する必要があります。
環境内に少なくとも 1 つの標準ホストが存在する必要があります。このホスト (およびその他の通常のホスト) は、SPM ロールおよび実行中の仮想マシンをホストするためにアクティブなままになります。標準ホストがまだ SPM ではない場合、標準ホストを選択し、Management Select as SPM をクリックして、SPM のロールを移動してからバックアップを作成します。
標準ホストが利用できない場合に 1 つを追加する方法は 2 つあります。
- セルフホスト型エンジン設定をノードから削除します (ただし、環境からノードは削除しないでください)。セルフホスト型エンジン環境からのホストの削除を参照してください。
- 新しい標準ホストを追加します。Manager ホストタスクへの標準ホストの追加を参照してください。

3.2.1.8.1. 元の Manager のバックアップ

engine-backup コマンドを使用して元の Manager をバックアップし、バックアップファイルを別の場所にコピーして、処理中にいつでもアクセスできるようにします。

engine-backup --mode=backup オプションの詳細は、管理ガイド の Red Hat Virtualization Manager のバックアップと復元を参照してください。

手順

セルフホスト型エンジンノードの 1 つにログインし、環境をグローバルメンテナンスモードに移行します。
```
# hosted-engine --set-maintenance --mode=global
```
元の Manager にログインし、ovirt-engine サービスを停止します。
```
# systemctl stop ovirt-engine
# systemctl disable ovirt-engine
```
注記
元の Manager の実行を停止することは必須ではありませんが、バックアップの作成後に環境を変更しないように推奨しています。さらに、元の Manager と新しい Manager が既存リソースを同時に管理しないようにします。
作成するバックアップファイルの名前と、バックアップログを保存するログファイルの名前を指定して、engine-backup コマンドを実行します。
```
# engine-backup --mode=backup --file=file_name --log=log_file_name
```
ファイルを外部サーバーにコピーします。以下の例の storage.example.com は、必要になるまでバックアップを保存するネットワークストレージサーバーの完全修飾ドメイン名です。/backup/ は指定のフォルダーまたはパスです。
```
# scp -p file_name log_file_name storage.example.com:/backup/
```
Manager マシンを他の目的で必要としない場合は、Red Hat Subscription Manager から登録を解除します。
```
# subscription-manager unregister
```
セルフホスト型エンジンノードの 1 つにログインし、元の Manager 仮想マシンをシャットダウンします。
```
# hosted-engine --vm-shutdown
```

Manager のバックアップ後に、新しいセルフホスト型エンジンをデプロイし、新しい仮想マシンにバックアップを復元します。

3.2.1.8.2. 新しいセルフホスト型エンジンでのバックアップの復元

hosted-engine スクリプトを新規ホストで実行し、デプロイメント中に --restore-from-file=path/to/file_name オプションを使用して Manager バックアップを復元します。

重要

iSCSI ストレージを使用し、イニシエーターの ACL に従い iSCSI ターゲットフィルターを使用して接続をフィルタリングすると、デプロイメントは STORAGE_DOMAIN_UNREACHABLE エラーで失敗する可能性があります。これを回避するには、セルフホストエンジンのデプロイメントを開始する前に iSCSI 設定を更新する必要があります。

既存のホストに再デプロイする場合は、/etc/iscsi/initiatorname.iscsi でホストの iSCSI イニシエーター設定を更新する必要があります。イニシエーター IQN は、iSCSI ターゲットで以前にマッピングされていたものと同じか、必要に応じて新しい IQN に更新する必要があります。
新規ホストにデプロイする場合は、iSCSI ターゲット設定を更新して、ホストからの接続を受け入れる必要があります。

IQN はホスト側 (iSCSI イニシエーター) またはストレージ側 (iSCSI ターゲット) で更新できることに注意してください。

手順

バックアップファイルを新規ホストにコピーします。以下の例では、host.example.com はホストの FQDN、/backup/ は指定されたフォルダーまたはパスです。
```
# scp -p file_name host.example.com:/backup/
```
新しいホストにログインします。
Red Hat Virtualization Host にデプロイする場合、ovirt-hosted-engine-setup はすでにインストールされているため、この手順を省略します。Red Hat Enterprise Linux にデプロイする場合は、ovirt-hosted-engine-setup パッケージをインストールします。
```
# dnf install ovirt-hosted-engine-setup
```
ネットワークやターミナルが切断された場合などにセッションが失われないように、tmux ウィンドウマネージャーを使用してスクリプトを実行します。
tmux をインストールし、実行します。
```
# dnf -y install tmux
# tmux
```
バックアップファイルへのパスを指定して hosted-engine スクリプトを実行します。
```
# hosted-engine --deploy --restore-from-file=backup/file_name
```
任意のタイミングでスクリプトをエスケープするには、CTRL+D を使用してデプロイメントを中止します。
Yes を選択してデプロイメントを開始します。
ネットワークを設定します。スクリプトにより、環境の管理ブリッジとして使用する NIC 候補が検出されます。
仮想マシンのインストールにカスタムアプライアンスを使用する場合は、OVA アーカイブへのパスを入力します。使用しない場合は、このフィールドを空欄のままにして RHV-M Appliance を使用します。
Manager の root パスワードを入力します。
root ユーザーとして Manager にログインできる SSH 公開鍵を入力し、root ユーザーの SSH アクセスを有効にするかどうかを指定します。
仮想マシンの CPU およびメモリー設定を入力します。
Manager 用仮想マシンの MAC アドレスを入力するか、無作為に生成される MAC アドレスを適用します。Manager 用仮想マシンへの IP アドレス割り当てに DHCP を使用する場合は、この MAC アドレスに有効な DHCP 予約があることを確認してください。デプロイメントスクリプトは、DHCP サーバーの設定は行いません。
仮想マシンのネットワーク情報を入力します。Static を指定する場合は、Manager の IP アドレスを入力します。
重要
静的 IP アドレスは、ホストと同じサブネットに属している必要があります。たとえばホストが 10.1.1.0/24 内にある場合、Manager 用仮想マシンの IP は同じサブネット範囲 (10.1.1.1-254/24) になければなりません。
Manager 用仮想マシンおよびベースホストのエントリーを、仮想マシンの /etc/hosts ファイルに追加するかどうかを指定します。ホスト名は解決可能でなければなりません。
SMTP サーバーの名前と TCP ポート番号、メール通知を送信するメールアドレス、メール通知を受信するメールアドレス (複数ある場合はコンマ区切りリスト) を指定します。
管理ポータルにアクセスする際に使用する admin@internal ユーザーのパスワードを入力します。
スクリプトにより仮想マシンが作成されます。RHV-M Appliance をインストールする必要がある場合は、時間がかかることがあります。
注記
必要なネットワークがないなどの理由でホストが動作しなくなると、デプロイが一時停止し、次のようなメッセージが表示されます。
```
[ INFO  ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
[ INFO  ] changed: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]
```
プロセスを一時停止すると、以下が可能になります。
- 提供された URL を使用して管理ポータルに接続します。
- 状況を評価し、ホストが動作していない理由を調べ、必要に応じて修正します。たとえば、このデプロイメントがバックアップから復元され、ホストクラスターに 必要なネットワーク がバックアップに含まれている場合は、ネットワークを設定し、関連するホスト NIC をこれらのネットワークに接続します。
- すべてが正常に見え、ホストのステータスが Up になったら、上記のメッセージに表示されているロックファイルを削除します。デプロイメントは続行されます。
使用するストレージのタイプを選択します。
- NFS の場合は、バージョン、完全なアドレス、ストレージへのパスおよびマウントオプションを入力します。
  警告
  仮想マシンのデータが失われるリスクがあるため、古いセルフホスト型エンジンストレージドメインのマウントポイントを新しいストレージドメインに使用しないでください。
- iSCSI の場合は、ポータルの詳細を入力し、自動検出された一覧からターゲットおよび LUN を選択します。デプロイメント時に選択できる iSCSI ターゲットは 1 つだけですが、マルチパスがサポートされているので、同じポータルグループのポータルをすべて接続できます。
  注記
  複数の iSCSI ターゲットを指定するには、セルフホスト型エンジンをデプロイする前にマルチパスを有効にする必要があります。詳細は、Red Hat Enterprise Linux DM マルチパス を参照してください。Multipath Helper ツールを使用して、さまざまなオプションでマルチパスをインストールおよび設定するスクリプトを生成することもできます。
- Gluster ストレージの場合は、完全なアドレスおよびストレージへのパスならびにマウントオプションを入力します。
  警告
  仮想マシンのデータが失われるリスクがあるため、古いセルフホスト型エンジンストレージドメインのマウントポイントを新しいストレージドメインに使用しないでください。
  重要
  レプリカ 1 およびレプリカ 3 Gluster ストレージのみがサポートされます。必ず以下のようにボリュームを設定します。
  gluster volume set VOLUME_NAME group virt gluster volume set VOLUME_NAME performance.strict-o-direct on gluster volume set VOLUME_NAME network.remote-dio off gluster volume set VOLUME_NAME storage.owner-uid 36 gluster volume set VOLUME_NAME storage.owner-gid 36 gluster volume set VOLUME_NAME network.ping-timeout 30
- ファイバーチャネルの場合は、自動検出されたリストから LUN を選択します。ホストのバスアダプターが設定および接続されている必要があります。また、LUN には既存のデータが含まれないようにする必要があります。既存の LUN を再利用するには、管理ガイド の LUN の再利用を参照してください。
Manager のディスクサイズを入力します。
スクリプトはデプロイメントが完了するまで続行されます。
デプロイメントプロセスでは Manager の SSH キーが変更されます。クライアントマシンが SSH エラーなしで新規の Manager にアクセスできるようにするには、元の Manager にアクセスするクライアントマシンの .ssh/known_hosts ファイルから元の Manager のエントリーを削除します。

デプロイメントが完了したら、新しい Manager 仮想マシンにログインし、必要なリポジトリーを有効にします。

3.2.1.8.3. Red Hat Virtualization Manager リポジトリーの有効化

ログインして、Red Hat Subscription Manager で Manager マシンを登録し、Red Hat Virtualization Manager のサブスクリプションをアタッチして Manager のリポジトリーを有効にする必要があります。

手順

コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
```
# subscription-manager register
```
注記
IPv6 ネットワークを使用している場合は、IPv6 移行メカニズムを使用して、コンテンツ配信ネットワークおよびサブスクリプションマネージャーにアクセスします。
Red Hat Virtualization Manager のサブスクリプションプールを見つけ、プール ID を記録します。
```
# subscription-manager list --available
```
上記のプール ID を使用して、サブスクリプションをシステムにアタッチします。
```
# subscription-manager attach --pool=pool_id
```
注記
現在アタッチされているサブスクリプションを表示するには、以下のコマンドを実行します。
```
# subscription-manager list --consumed
```
有効なリポジトリーをすべてリスト表示するには、以下のコマンドを実行します。
```
# dnf repolist
```

リポジトリーを設定します。

# subscription-manager repos \
    --disable='*' \
    --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms \
    --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \
    --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \
    --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

RHEL のバージョンを 8.6 に設定します。
```
# subscription-manager release --set=8.6
```
pki-deps モジュールを有効にします。
```
# dnf module -y enable pki-deps
```
postgresql モジュールのバージョン 12 を有効にします。
```
# dnf module -y enable postgresql:12
```
nodejs モジュールのバージョン 14 を有効にします。
```
# dnf module -y enable nodejs:14
```
インストール済みパッケージを同期して、利用可能な最新バージョンに更新します。
```
# dnf distro-sync --nobest
```

関連情報

モジュールおよびモジュールストリームの詳細は、ユーザー空間コンポーネントのインストール、管理、および削除 の以下のセクションを参照してください。

Manager とそのリソースは、新しいセルフホスト環境で実行されています。セルフホスト型エンジンノードは、セルフホスト型エンジン設定を更新するために Manager に再インストールする必要があります。標準ホストは影響を受けません。セルフホスト型エンジンノードごとに次の手順を実行します。

3.2.1.8.4. ホストの再インストール

管理ポータルから Red Hat Virtualization Host (RHVH) および Red Hat Enterprise Linux ホストを再インストールします。この手順には、ホストの停止および再起動が含まれます。

警告

ホストのオペレーティングシステムのインストールまたは再インストールを行う場合、Red Hat では、ホストにアタッチされている既存の OS 以外のストレージを最初にデタッチすることを強く推奨しています。これは、ディスクを誤って初期化してデータが失われる可能性を避けるためです。

前提条件

クラスターの移行が有効化されている場合、仮想マシンはそのクラスター内の別のホストに自動的に移行できます。したがって、使用量が比較的低い間にホストを再インストールします。
ホストによるメンテナンスの実行に必要なメモリーがクラスターにあることを確認します。クラスターにメモリーがない場合、仮想マシンの移行はハングして失敗します。メモリー使用量を減らすには、ホストをメンテナンスに移行する前に、一部またはすべての仮想マシンをシャットダウンします。
再インストールを実行する前に、クラスターに複数のホストが含まれていることを確認してください。すべてのホストを同時に再インストールしようとしないでください。Storage Pool Manager (SPM) タスクを実行するには、1 台のホストは使用可能な状態でなければなりません。

手順

Compute Hosts をクリックし、ホストを選択します。
Management Maintenance をクリックしてから OK をクリックします。
Installation Reinstall をクリックします。Install Host ウィンドウが表示されます。
Hosted Engine タブをクリックし、ドロップダウンリストから DEPLOY を選択します。
OK をクリックして、ホストを再インストールします。

ホストを再インストールし、そのステータスが Up に戻れば、仮想マシンをホストに戻すことができます。

重要

Red Hat Virtualization Host を Red Hat Virtualization Manager に登録し、これを再インストールした後、管理ポータルでそのステータスが誤って Install Failed と表示される場合があります。Management Activate をクリックすると、ホストのステータスが Up に変わり、使用できるようになります。

セルフホスト型エンジンノードを再インストールした後に、いずれかのノードで以下のコマンドを実行して、新しい環境のステータスを確認できます。

# hosted-engine --vm-status

復元中に、古いセルフホスト型エンジンのストレージドメインの名前が変更されましたが、復元に問題があった場合に備えて、新しい環境からは削除されませんでした。環境が正常に実行されていることを確認したら、古いセルフホスト型エンジンストレージドメインを削除できます。

3.2.1.8.5. ストレージドメインの削除

データセンターに、仮想化環境から削除するストレージドメインがあります。

手順

Storage Domains をクリックします。
ストレージドメインをメンテナンスモードに移動し、デタッチします。
1. ストレージドメインの名前をクリックします。詳細ビューが開きます。
2. Data Center タブをクリックします。
3. Maintenance をクリックしてから OK をクリックします。
4. Detach をクリックしてから OK をクリックします。
Remove をクリックします。
オプションで Format Domain, i.e. Storage Content will be lost! チェックボックスを選択して、ドメインのコンテンツを消去します。
OK をクリックします。

ストレージドメインが環境から完全に削除されます。

3.2.1.9. 既存のバックアップからのセルフホスト型エンジンの復元

修復できない問題が原因でセルフホスト型エンジンが使用できない場合は、問題が発生する前に作成したバックアップを使用して、新しいセルフホスト環境でエンジンを復元できます (使用可能な場合)。

セルフホスト型エンジンの復元には、次の主要なアクションが含まれます。

この手順は、元の Manager にアクセスできず、新しいホストがバックアップファイルにアクセスできることを前提としています。

前提条件

Manager とホスト用に用意された完全修飾ドメイン名。正引き (フォワードルックアップ) と逆引き (リバースルックアップ) の記録は、両方とも DNS で設定する必要があります。新しい Manager は、元の Manager と同じ完全修飾ドメイン名を持っている必要があります。

3.2.1.9.1. 新しいセルフホスト型エンジンでのバックアップの復元

重要

既存のホストに再デプロイする場合は、/etc/iscsi/initiatorname.iscsi でホストの iSCSI イニシエーター設定を更新する必要があります。イニシエーター IQN は、iSCSI ターゲットで以前にマッピングされていたものと同じか、必要に応じて新しい IQN に更新する必要があります。
新規ホストにデプロイする場合は、iSCSI ターゲット設定を更新して、ホストからの接続を受け入れる必要があります。

IQN はホスト側 (iSCSI イニシエーター) またはストレージ側 (iSCSI ターゲット) で更新できることに注意してください。

手順

バックアップファイルを新規ホストにコピーします。以下の例では、host.example.com はホストの FQDN、/backup/ は指定されたフォルダーまたはパスです。
```
# scp -p file_name host.example.com:/backup/
```
新しいホストにログインします。
Red Hat Virtualization Host にデプロイする場合、ovirt-hosted-engine-setup はすでにインストールされているため、この手順を省略します。Red Hat Enterprise Linux にデプロイする場合は、ovirt-hosted-engine-setup パッケージをインストールします。
```
# dnf install ovirt-hosted-engine-setup
```
ネットワークやターミナルが切断された場合などにセッションが失われないように、tmux ウィンドウマネージャーを使用してスクリプトを実行します。
tmux をインストールし、実行します。
```
# dnf -y install tmux
# tmux
```
バックアップファイルへのパスを指定して hosted-engine スクリプトを実行します。
```
# hosted-engine --deploy --restore-from-file=backup/file_name
```
任意のタイミングでスクリプトをエスケープするには、CTRL+D を使用してデプロイメントを中止します。
Yes を選択してデプロイメントを開始します。
ネットワークを設定します。スクリプトにより、環境の管理ブリッジとして使用する NIC 候補が検出されます。
仮想マシンのインストールにカスタムアプライアンスを使用する場合は、OVA アーカイブへのパスを入力します。使用しない場合は、このフィールドを空欄のままにして RHV-M Appliance を使用します。
Manager の root パスワードを入力します。
root ユーザーとして Manager にログインできる SSH 公開鍵を入力し、root ユーザーの SSH アクセスを有効にするかどうかを指定します。
仮想マシンの CPU およびメモリー設定を入力します。
Manager 用仮想マシンの MAC アドレスを入力するか、無作為に生成される MAC アドレスを適用します。Manager 用仮想マシンへの IP アドレス割り当てに DHCP を使用する場合は、この MAC アドレスに有効な DHCP 予約があることを確認してください。デプロイメントスクリプトは、DHCP サーバーの設定は行いません。
仮想マシンのネットワーク情報を入力します。Static を指定する場合は、Manager の IP アドレスを入力します。
重要
静的 IP アドレスは、ホストと同じサブネットに属している必要があります。たとえばホストが 10.1.1.0/24 内にある場合、Manager 用仮想マシンの IP は同じサブネット範囲 (10.1.1.1-254/24) になければなりません。
Manager 用仮想マシンおよびベースホストのエントリーを仮想マシンの /etc/hosts ファイルに追加するかどうかを指定します。ホスト名は解決可能でなければなりません。
SMTP サーバーの名前と TCP ポート番号、メール通知を送信するメールアドレス、メール通知を受信するメールアドレス (複数ある場合はコンマ区切りリスト) を指定します。
管理ポータルにアクセスする際に使用する admin@internal ユーザーのパスワードを入力します。
スクリプトにより仮想マシンが作成されます。RHV-M Appliance をインストールする必要がある場合は、時間がかかることがあります。
注記
必要なネットワークがないなどの理由でホストが動作しなくなると、デプロイが一時停止し、次のようなメッセージが表示されます。
```
[ INFO  ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
[ INFO  ] changed: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]
```
プロセスを一時停止すると、以下が可能になります。
- 提供された URL を使用して管理ポータルに接続します。
- 状況を評価し、ホストが動作していない理由を調べ、必要に応じて修正します。たとえば、このデプロイメントがバックアップから復元され、ホストクラスターに 必要なネットワーク がバックアップに含まれている場合は、ネットワークを設定し、関連するホスト NIC をこれらのネットワークに接続します。
- すべてが正常に見え、ホストのステータスが Up になったら、上記のメッセージに表示されているロックファイルを削除します。デプロイメントは続行されます。
使用するストレージのタイプを選択します。
- NFS の場合は、バージョン、完全なアドレス、ストレージへのパスおよびマウントオプションを入力します。
  警告
  仮想マシンのデータが失われるリスクがあるため、古いセルフホスト型エンジンストレージドメインのマウントポイントを新しいストレージドメインに使用しないでください。
- iSCSI の場合は、ポータルの詳細を入力し、自動検出された一覧からターゲットおよび LUN を選択します。デプロイメント時に選択できる iSCSI ターゲットは 1 つだけですが、マルチパスがサポートされているので、同じポータルグループのポータルをすべて接続できます。
  注記
  複数の iSCSI ターゲットを指定するには、セルフホスト型エンジンをデプロイする前にマルチパスを有効にする必要があります。詳細は、Red Hat Enterprise Linux DM マルチパス を参照してください。Multipath Helper ツールを使用して、さまざまなオプションでマルチパスをインストールおよび設定するスクリプトを生成することもできます。
- Gluster ストレージの場合は、完全なアドレスおよびストレージへのパスならびにマウントオプションを入力します。
  警告
  仮想マシンのデータが失われるリスクがあるため、古いセルフホスト型エンジンストレージドメインのマウントポイントを新しいストレージドメインに使用しないでください。
  重要
  レプリカ 1 およびレプリカ 3 Gluster ストレージのみがサポートされます。必ず以下のようにボリュームを設定します。
  gluster volume set VOLUME_NAME group virt gluster volume set VOLUME_NAME performance.strict-o-direct on gluster volume set VOLUME_NAME network.remote-dio off gluster volume set VOLUME_NAME storage.owner-uid 36 gluster volume set VOLUME_NAME storage.owner-gid 36 gluster volume set VOLUME_NAME network.ping-timeout 30
- ファイバーチャネルの場合は、自動検出されたリストから LUN を選択します。ホストのバスアダプターが設定および接続されている必要があります。また、LUN には既存のデータが含まれないようにする必要があります。既存の LUN を再利用するには、管理ガイド の LUN の再利用を参照してください。
Manager のディスクサイズを入力します。
スクリプトはデプロイメントが完了するまで続行されます。
デプロイメントプロセスでは Manager の SSH キーが変更されます。クライアントマシンが SSH エラーなしで新規の Manager にアクセスできるようにするには、元の Manager にアクセスするクライアントマシンの .ssh/known_hosts ファイルから元の Manager のエントリーを削除します。

デプロイメントが完了したら、新しい Manager 仮想マシンにログインし、必要なリポジトリーを有効にします。

3.2.1.9.2. Red Hat Virtualization Manager リポジトリーの有効化

手順

コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
```
# subscription-manager register
```
注記
IPv6 ネットワークを使用している場合は、IPv6 移行メカニズムを使用して、コンテンツ配信ネットワークおよびサブスクリプションマネージャーにアクセスします。
Red Hat Virtualization Manager のサブスクリプションプールを見つけ、プール ID を記録します。
```
# subscription-manager list --available
```
上記のプール ID を使用して、サブスクリプションをシステムにアタッチします。
```
# subscription-manager attach --pool=pool_id
```
注記
現在アタッチされているサブスクリプションを表示するには、以下のコマンドを実行します。
```
# subscription-manager list --consumed
```
有効なリポジトリーをすべてリスト表示するには、以下のコマンドを実行します。
```
# dnf repolist
```

リポジトリーを設定します。

# subscription-manager repos \
    --disable='*' \
    --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms \
    --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \
    --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \
    --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

RHEL のバージョンを 8.6 に設定します。
```
# subscription-manager release --set=8.6
```
pki-deps モジュールを有効にします。
```
# dnf module -y enable pki-deps
```
postgresql モジュールのバージョン 12 を有効にします。
```
# dnf module -y enable postgresql:12
```
nodejs モジュールのバージョン 14 を有効にします。
```
# dnf module -y enable nodejs:14
```
インストール済みパッケージを同期して、利用可能な最新バージョンに更新します。
```
# dnf distro-sync --nobest
```

関連情報

3.2.1.9.3. ホストの再インストール

警告

前提条件

クラスターの移行が有効化されている場合、仮想マシンはそのクラスター内の別のホストに自動的に移行できます。したがって、使用量が比較的低い間にホストを再インストールします。
ホストによるメンテナンスの実行に必要なメモリーがクラスターにあることを確認します。クラスターにメモリーがない場合、仮想マシンの移行はハングして失敗します。メモリー使用量を減らすには、ホストをメンテナンスに移行する前に、一部またはすべての仮想マシンをシャットダウンします。
再インストールを実行する前に、クラスターに複数のホストが含まれていることを確認してください。すべてのホストを同時に再インストールしようとしないでください。Storage Pool Manager (SPM) タスクを実行するには、1 台のホストは使用可能な状態でなければなりません。

手順

Compute Hosts をクリックし、ホストを選択します。
Management Maintenance をクリックしてから OK をクリックします。
Installation Reinstall をクリックします。Install Host ウィンドウが表示されます。
Hosted Engine タブをクリックし、ドロップダウンリストから DEPLOY を選択します。
OK をクリックして、ホストを再インストールします。

ホストを再インストールし、そのステータスが Up に戻れば、仮想マシンをホストに戻すことができます。

重要

# hosted-engine --vm-status

3.2.1.9.4. ストレージドメインの削除

データセンターに、仮想化環境から削除するストレージドメインがあります。

手順

Storage Domains をクリックします。
ストレージドメインをメンテナンスモードに移動し、デタッチします。
1. ストレージドメインの名前をクリックします。詳細ビューが開きます。
2. Data Center タブをクリックします。
3. Maintenance をクリックしてから OK をクリックします。
4. Detach をクリックしてから OK をクリックします。
Remove をクリックします。
オプションで Format Domain, i.e. Storage Content will be lost! チェックボックスを選択して、ドメインのコンテンツを消去します。
OK をクリックします。

ストレージドメインが環境から完全に削除されます。

3.2.1.10. 既存のバックアップからのセルフホスト型エンジンの上書き

セルフホスト型エンジンにアクセスできるが、データベースの破損や設定エラーなどロールバックが難しい問題が発生した場合、問題が発生する前に取ったバックアップがあれば、それを使用して以前の状態に環境を復元することができます。

セルフホスト型エンジンを以前の状態に復元するには、次の手順が必要です。

engine-backup --mode=restore オプションの詳細は、Manager のバックアップおよび復元を参照してください。

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

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

手順

セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを有効にします。
```
# hosted-engine --set-maintenance --mode=global
```
作業を進める前に、環境がグローバルメンテナンスモードにあることを確認します。
```
# hosted-engine --vm-status
```
クラスターがグローバルメンテナンスモードにあることを示すメッセージが表示されるはずです。

3.2.1.10.2. バックアップを復元して既存のインストールを上書き

手順

Manager マシンにログインします。
設定ファイルを削除し、Manager に関連付けられているデータベースをクリーンアップします。
```
# engine-cleanup
```
engine-cleanup コマンドは、Manager データベースのみを削除します。データベースを削除したり、そのデータベースを所有しているユーザーを削除したりすることはありません。
完全バックアップまたはデータベースのみのバックアップを復元します。ユーザーとデータベースがすでに存在しているので、新規のデータベースを作成したり、データベースの認証情報を指定する必要はありません。
- 完全バックアップを復元します。
```
# engine-backup --mode=restore --file=file_name --log=log_file_name --restore-permissions
```
- 設定ファイルおよびデータベースバックアップを復元して、データベースのみのバックアップを復元します。
```
# engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb --file=file_name --log=log_file_name --restore-permissions
```
  注記
  Manager データベースのみを復元するには (たとえば、Data Warehouse データベースが別のマシンにある場合)、-scope=dwhdb パラメーターを省略できます。
  成功すると、次の出力が表示されます。
```
You should now run engine-setup.
Done.
```
Manager を再設定します。
```
# engine-setup
```

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

手順

Manager 用仮想マシンにログインし、シャットダウンします。
セルフホスト型エンジンノードのいずれかにログインして、グローバルメンテナンスモードを無効にします。
```
# hosted-engine --set-maintenance --mode=none
```
グローバルメンテナンスモードを終了すると、ovirt-ha-agent が Manager 用仮想マシンを起動し、続いて Manager が自動的に起動します。Manager が起動するまでに最大で 10 分程度かかる場合があります。
環境が動作していることを確認します。
```
# 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"}
```
このような場合は、数分間待ってからやり直してください。

環境が再び実行している場合は、停止した仮想マシンを起動して、環境内のリソースが期待どおりに動作していることを確認できます。

3.2.2. データウェアハウスを別のマシンに移行

このセクションでは、Data Warehouse データベースおよびサービスを Red Hat Virtualization Manager マシンから別のマシンに移行する方法を説明します。Data Warehouse サービスを別のマシンでホストすると、各個別マシンの負荷が削減され、CPU やメモリーリソースを他のプロセスと共有することで競合が生じる可能性を回避できます。

注記

Data Warehouse データベース、Data Warehouse サービス、Grafana はそれぞれ別々のマシンにインストールできますが、Red Hat はこれらの各コンポーネントをすべて同じマシンにインストールする場合のみサポートします。

以下の移行オプションがあります。

Manager マシンから Data Warehouse サービスを移行し、既存の Data Warehouse データベース (ovirt_engine_history) に接続できます。
Manager マシンから Data Warehouse データベースを移行してから、Data Warehouse サービスを移行することができます。

3.2.2.1. 別のマシンへの Data Warehouse データベースの移行

Data Warehouse サービスを移行する前に、Data Warehouse データベース (ovirt_engine_history) を移行します。engine-backup を使用してデータベースのバックアップを作成し、それを新規データベースマシンで復元します。engine-backup の詳細は、engine-backup --help を実行して確認してください。

注記

新規データベースサーバーに Red Hat Enterprise Linux 8 がインストールされている必要があります。

新規データベースサーバーで必要なリポジトリーを有効にします。

3.2.2.1.1. Red Hat Virtualization Manager リポジトリーの有効化

ログインして、Red Hat Subscription Manager で Data Warehouse マシンを登録し、Red Hat Virtualization Manager のサブスクリプションをアタッチして Manager のリポジトリーを有効にする必要があります。

手順

コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
```
# subscription-manager register
```
注記
IPv6 ネットワークを使用している場合は、IPv6 移行メカニズムを使用して、コンテンツ配信ネットワークおよびサブスクリプションマネージャーにアクセスします。
Red Hat Virtualization Manager のサブスクリプションプールを見つけ、プール ID を記録します。
```
# subscription-manager list --available
```
上記のプール ID を使用して、サブスクリプションをシステムにアタッチします。
```
# subscription-manager attach --pool=pool_id
```
注記
現在アタッチされているサブスクリプションを表示するには、以下のコマンドを実行します。
```
# subscription-manager list --consumed
```
有効なリポジトリーをすべてリスト表示するには、以下のコマンドを実行します。
```
# dnf repolist
```

リポジトリーを設定します。

# subscription-manager repos \
    --disable='*' \
    --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms \
    --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \
    --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \
    --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

RHEL のバージョンを 8.6 に設定します。
```
# subscription-manager release --set=8.6
```
postgresql モジュールのバージョン 12 を有効にします。
```
# dnf module -y enable postgresql:12
```
nodejs モジュールのバージョン 14 を有効にします。
```
# dnf module -y enable nodejs:14
```
インストール済みパッケージを同期して、利用可能な最新バージョンに更新します。
```
# dnf distro-sync --nobest
```

関連情報

3.2.2.1.2. 別のマシンへの Data Warehouse データベースの移行

手順

Manager で Data Warehouse データベースおよび設定ファイルのバックアップを作成します。
```
# engine-backup --mode=backup --scope=grafanadb --scope=dwhdb --scope=files --file=file_name --log=log_file_name
```
そのバックアップファイルを Manager マシンから新たなマシンにコピーします。
```
# scp /tmp/file_name root@new.dwh.server.com:/tmp
```
engine-backup を新しいマシンにインストールします。
```
# dnf install ovirt-engine-tools-backup
```
PostgreSQL サーバーパッケージをインストールします。
```
# dnf install postgresql-server postgresql-contrib
```
PostgreSQL データベースを初期化し、postgresql サービスを開始して、このサービスが起動時に開始されることを確認します。
```
# su - postgres -c 'initdb'
# systemctl enable postgresql
# systemctl start postgresql
```
新しいマシンで Data Warehouse データベースを復元します。file_name は、Manager からコピーされたバックアップファイルです。
```
# engine-backup --mode=restore --scope=files --scope=grafanadb --scope=dwhdb --file=file_name --log=log_file_name --provision-dwh-db
```
復元モードで --provision-* オプションを使用すると、デフォルトで --restore-permissions が適用されます。

これで、Manager がホストされるマシンとは別のマシンで、Data Warehouse データベースがホストされるようになりました。Data Warehouse データベースを正常に復元したら、engine-setup コマンドの実行を指示するプロンプトが表示されます。このコマンドを実行する前に、Data Warehouse サービスを移行します。

3.2.2.2. 別のマシンへの Data Warehouse サービスの移行

Red Hat Virtualization Manager にインストールおよび設定した Data Warehouse サービスは、別のマシンに移行することができます。Data Warehouse サービスを別のマシンでホストすることは、Manager マシンの負荷を削減する上で役立ちます。

この手順では、Data Warehouse サービスのみを移行することに注意してください。

Data Warehouse サービスを移行する前に Data Warehouse データベース (ovirt_engine_history) を移行するには、Data Warehouse のデータセットの別のマシンへの移行を参照してください。

注記

前提条件

Manager と Data Warehouse が同じマシン上にインストールおよび設定されている。
新たな Data Warehouse マシンを設定するには、以下を満たしている必要があります。
- Manager の /etc/ovirt-engine/engine.conf.d/10-setup-database.conf ファイルからのパスワード。
- Data Warehouse マシンから Manager データベースマシンの TCP ポート 5432 へのアクセス許可。
- Manager の /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf ファイルからの Data Warehouse データベースのユーザー名とパスワード。
  Data Warehouse データセットの別のマシンへの移行で説明されている手順を使用して ovirt_engine_history データベースを移行した場合、バックアップには、そのマシンでのデータベースのセットアップ中に定義したこれらの認証情報が含まれます。

このシナリオのインストールでは、以下の 4 つのステップを実施する必要があります。

新たな Data Warehouse マシンの準備
Manager マシンでの Data Warehouse サービスの停止
新たな Data Warehouse マシンの設定
Manager マシンでの Data Warehouse パッケージの無効化

3.2.2.2.1. 新たな Data Warehouse マシンの準備

Red Hat Virtualization のリポジトリーを有効にし、Red Hat Enterprise Linux 8 マシンに Data Warehouse セットアップパッケージをインストールします。

必要なリポジトリーを有効にします。
1. コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
```
# subscription-manager register
```
2. Red Hat Virtualization Manager のサブスクリプションプールを見つけ、プール ID を記録します。
```
# subscription-manager list --available
```
3. 上記のプール ID を使用して、サブスクリプションをシステムにアタッチします。
```
# subscription-manager attach --pool=pool_id
```
4. リポジトリーを設定します。
```
# subscription-manager repos \
    --disable='*' \
    --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms \
    --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms

# subscription-manager release --set=8.6
```
pki-deps モジュールを有効にします。
```
# dnf module -y enable pki-deps
```
現在インストールされている全パッケージを最新の状態にします。
```
# dnf upgrade --nobest
```
ovirt-engine-dwh-setup パッケージをインストールします。
```
# dnf install ovirt-engine-dwh-setup
```

3.2.2.2.2. Manager マシンでの Data Warehouse サービスの停止

手順

Data Warehouse サービスを停止します。
```
# systemctl stop ovirt-engine-dwhd.service
```
データベースがリモートマシンでホストされる場合は、postgres.conf ファイルを編集して手動でアクセス権限を付与する必要があります。/var/lib/pgsql/data/postgresql.conf ファイルを編集し、listen_addresses 行を変更して以下と一致するようにします。
```
listen_addresses = '*'
```
その行が存在しない、またはコメントアウトされている場合は、手動で追加します。
Manager マシンでデータベースがホストされていて、そのデータベースが Red Hat Virtualization Manager のクリーンセットアップ中に設定された場合は、デフォルトでアクセス権限が付与されます。
postgresql サービスを再起動します。
```
# systemctl restart postgresql
```

3.2.2.2.3. 新たな Data Warehouse マシンの設定

このセクションで示すオプションまたは設定の順序は、お使いの環境によって異なる場合があります。

ovirt_engine_history データベースと Data Warehouse サービスの両方を同じマシンに移行する場合は、以下のコマンドを実行します。移行しない場合は、次のステップに進みます。

# sed -i '/^ENGINE_DB_/d' \
        /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf

# sed -i \
     -e 's;^\(OVESETUP_ENGINE_CORE/enable=bool\):True;\1:False;' \
     -e '/^OVESETUP_CONFIG\/fqdn/d' \
     /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

apache/grafana PKI ファイルを削除して、engine-setup によって正しい値で再生成されるようにします。

# rm -f \
  /etc/pki/ovirt-engine/certs/apache.cer \
  /etc/pki/ovirt-engine/certs/apache-grafana.cer \
  /etc/pki/ovirt-engine/keys/apache.key.nopass \
  /etc/pki/ovirt-engine/keys/apache-grafana.key.nopass \
  /etc/pki/ovirt-engine/apache-ca.pem \
  /etc/pki/ovirt-engine/apache-grafana-ca.pem

engine-setup コマンドを実行し、マシンでの Data Warehouse の設定を開始します。
```
# engine-setup
```
Enter キーを押して自動検出されたホスト名をそのまま使用するか、別のホスト名を入力して Enter キーを押します。
```
Host fully qualified DNS name of this server [autodetected host name]:
```
Enter キーを押して､ファイアウォールを自動設定するか、No と入力し､Enter キーを押して、既存の設定を維持します。
```
Setup can automatically configure the firewall on this system.
Note: automatic configuration of the firewall may overwrite current settings.
Do you want Setup to configure the firewall? (Yes, No) [Yes]:
```
ファイアウォールの自動設定を選択した場合に、ファイアウォール管理機能がアクティブ化されていなければ、サポートされているオプション一覧から、選択したファイアウォール管理機能を指定するように要求されます。ファイアウォール管理機能の名前を入力して、Enter キーを押してください。この操作は、オプションが 1 つしかリストされていない場合でも必要です。

Manager の完全修飾ドメイン名およびパスワードを入力します。その他のフィールドについては、Enter キーを押してそれぞれのデフォルト値をそのまま使用します。

Host fully qualified DNS name of the engine server []: engine-fqdn
Setup needs to do some actions on the remote engine server. Either automatically, using ssh as root to access it, or you will be prompted to manually perform each such action.
Please choose one of the following:
1 - Access remote engine server using ssh as root
2 - Perform each action manually, use files to copy content around
(1, 2) [1]:
ssh port on remote engine server [22]:
root password on remote engine server engine-fqdn: password

Manager データベースマシンの完全修飾ドメイン名 (FQDN) およびパスワードを入力します。その他のフィールドについては、Enter キーを押してそれぞれのデフォルト値をそのまま使用します。
```
Engine database host []: manager-db-fqdn
Engine database port [5432]:
Engine database secured connection (Yes, No) [No]:
Engine database name [engine]:
Engine database user [engine]:
Engine database password: password
```

インストールの設定を確認します。

Please confirm installation settings (OK, Cancel) [OK]:

これで、Data Warehouse サービスがリモートマシンに設定されました。次は、Manager マシンの Data Warehouse サービスを無効にします。

3.2.2.2.4. Manager マシンでの Data Warehouse サービスの無効化

前提条件

Manager マシンの Grafana サービスが無効になっている。
```
# systemctl disable --now grafana-server.service
```

手順

Manager マシンで Manager を再起動します。
```
# service ovirt-engine restart
```

以下のコマンドを実行して /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf ファイルを変更し、オプションを False に設定します。

# sed -i \
     -e 's;^\(OVESETUP_DWH_CORE/enable=bool\):True;\1:False;' \
     -e 's;^\(OVESETUP_DWH_CONFIG/remoteEngineConfigured=bool\):True;\1:False;' \
     /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

# sed -i \
     -e 's;^\(OVESETUP_GRAFANA_CORE/enable=bool\):True;\1:False;' \
     /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

Data Warehouse サービスを無効にします。
```
# systemctl disable ovirt-engine-dwhd.service
```

Data Warehouse に関するファイルを削除します。

# rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/*.conf /var/lib/ovirt-engine-dwh/backups/*

これで、Data Warehouse サービスが Manager とは別のマシンでホストされるようになりました。

3.2.3. バックアップストレージドメインを使用した仮想マシンのバックアップと復元

3.2.3.1. バックアップストレージドメインの説明

バックアップストレージドメインは、災害復旧、移行、その他のバックアップ/復旧使用モデルにおけるバックアップと復元を目的として、仮想マシンおよび仮想マシンテンプレートの保存と移行に特化して使用できます。バックアップドメインは、バックアップドメイン上のすべての仮想マシンがパワーダウン状態にあるという点で、非バックアップドメインとは異なります。仮想マシンはバックアップドメインで実行できません。

任意のデータストレージドメインをバックアップドメインとして設定できます。Manage Domain ダイアログボックスのチェックボックスを選択または選択解除することで、この設定を有効または無効にできます。この設定を有効にできるのは、そのストレージドメイン上のすべての仮想マシンが停止した後でのみです。

バックアップドメインに保存されている仮想マシンを起動することはできません。Manager は、これと、バックアップを無効にする可能性のあるその他の操作をブロックします。ただし、仮想マシンのディスクがバックアップドメインの一部でない場合は、バックアップドメインに保存されているテンプレートに基づいて仮想マシンを実行できます。

他のタイプのストレージドメインと同様に、バックアップドメインをデータセンターに接続したり、データセンターから切り離したりできます。そのため、バックアップの保存に加え、バックアップドメインを使用してデータセンター間で仮想マシンを移行できます。

メリット

エクスポートドメインではなくバックアップドメインを使用するいくつかの理由を以下に示します。

データセンターで、エクスポートドメインを 1 つだけ持つのではなく、複数のバックアップストレージドメインを持つことができます。
バックアップストレージドメインをバックアップと障害復旧専用として使用できます。
仮想マシン、テンプレート、またはスナップショットのバックアップをバックアップストレージドメインに転送できます。
多数の仮想マシン、テンプレート、または OVF ファイルの移行は、エクスポートドメインよりもバックアップドメインの方が圧倒的に高速に行えます。
バックアップドメインは、エクスポートドメインよりも効率的にディスクスペースを使用します。
バックアップドメインは、ファイルストレージ (NFS、Gluster) とブロックストレージ (ファイバーチャネルと iSCSI) の両方をサポートします。これは、ファイルストレージのみをサポートするエクスポートドメインとは対照的です。
制限を考慮して、ストレージドメインのバックアップ設定を動的に有効または無効にできます。

制約

_backup ドメイン上のすべての仮想マシンまたはテンプレートは、同じドメイン上にすべてのディスクを持っている必要があります。
ストレージドメインをバックアップドメインとして設定する前に、ストレージドメイン上のすべての仮想マシンの電源を切る必要があります。
バックアップドメインに保存されている仮想マシンは実行できません。実行すると、ディスクのデータが操作される可能性があるためです。
メモリーボリュームはアクティブな仮想マシンでのみサポートされているため、バックアップドメインをメモリーボリュームのターゲットにできません。
バックアップドメインでは仮想マシンをプレビューできません。
仮想マシンはバックアップドメインにライブ移行できません。
バックアップドメインは master ドメインとして設定できません。
セルフホスト型エンジンのドメインはバックアップドメインとして設定できません。
デフォルトのストレージドメインをバックアップドメインとして使用しないでください。

3.2.3.2. データストレージドメインをバックアップドメインに設定

前提条件

ストレージドメイン上の仮想マシンまたはテンプレートに属するすべてのディスクは、同じドメイン上にある必要があります。
ドメイン上のすべての仮想マシンの電源を切る必要があります。

手順

管理ポータルで、Storage Domains を選択します。
新しいストレージドメインを作成するか、既存のストレージドメインを選択して、Manage Domain をクリックします。ドメインの管理ダイアログボックスが開きます。
Advanced Parameters で、Backup チェックボックスを選択します。

これで、ドメインはバックアップドメインになります。

3.2.3.3. バックアップドメインを使用した仮想マシンおよびスナップショットのバックアップと復元

電源がオフになっている仮想マシンまたはスナップショットをバックアップできます。その後、バックアップを同じデータセンターに保存して必要に応じて復元したり、別のデータセンターに移行したりできます。

手順: 仮想マシンのバックアップ

バックアップドメインを作成します。ストレージドメインをバックアップドメインとして設定するを参照してください。
バックアップする仮想マシンをベースに、新しい仮想マシンを作成します。
- スナップショットをバックアップするには、最初にスナップショットから仮想マシンを作成します。Virtual Machine Management Guide の Creating a Virtual Machine from a Snapshot を参照してください。
- 仮想マシンをバックアップするには、最初に仮想マシンのクローンを作成します。仮想マシン管理ガイド の仮想マシンのクローン作成を参照してください。続行する前に、クローンの電源がオフになっていることを確認してください。
新しい仮想マシンをバックアップドメインにエクスポートします。仮想マシン管理ガイド のデータドメインへの仮想マシンのエクスポートを参照してください。

手順: 仮想マシンの復元

仮想マシンのバックアップを保存するバックアップストレージドメインがデータセンターに接続されていることを確認してください。
バックアップドメインから仮想マシンをインポートします。データドメインからの仮想マシンのインポートを参照してください。

関連情報

3.2.4. バックアップおよびリストア API を使用した仮想マシンのバックアップおよび復元

3.2.4.1. バックアップおよびリストア API

バックアップおよびリストア API は、仮想マシンのフルバックアップまたはファイルレベルのバックアップと復元を実行可能にする機能のコレクションです。API は、ライブスナップショットや REST API などの Red Hat Virtualization コンポーネントをいくつか組み合わせて、独立したソフトウェアプロバイダーが提供するバックアップソフトウェアが含まれる仮想マシンに接続できる一時ボリュームを作成して操作します。

サポートされているサードパーティーのバックアップベンダーについては、Red Hat Virtualization Ecosystem を参照してください。

3.2.4.2. 仮想マシンのバックアップ

バックアップおよびリストア API を使用して、仮想マシンをバックアップします。この手順では、バックアップを作成する仮想マシンと、バックアップを管理するためのソフトウェアがインストールされている仮想マシンの 2 つの仮想マシンがあることを前提としています。

手順

REST API を使用して、バックアップを作成する仮想マシンのスナップショットを作成します。
```
POST /api/vms/{vm:id}/snapshots/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<snapshot>
    <description>BACKUP</description>
</snapshot>
```
注記
- ここで、{vm:id} を、スナップショットを作成している仮想マシンの VM ID に置き換えます。この ID は、管理ポータル および VM ポータル の New Virtual Machine ウィンドウと Edit Virtual Machine ウィンドウの General タブから利用できます。
- 仮想マシンのスナップショットを作成すると、スナップショットの下の initialization にある configuration 属性の data 属性に現在の設定データが格納されます。
重要
共有可能としてマークされたディスク、または直接 LUN ディスクに基づくディスクのスナップショットを作成することはできません。
スナップショットの下の data 属性から仮想マシンの設定データを取得します。
```
GET /api/vms/{vm:id}/snapshots/{snapshot:id} HTTP/1.1
All-Content: true
Accept: application/xml
Content-type: application/xml
```
注記
- ここで、{vm:id} を、以前にスナップショットを作成した仮想マシンの ID に置き換えます。{snapshot:id} をスナップショット ID に置き換えます。
- All-Content: true ヘッダーを追加して、応答内の追加の OVF データを取得します。XML 応答の OVF データは、VM 設定要素 <initialization><configuration> 内にあります。その後、このデータを使用して仮想マシンを復元します。

スナップショット ID を取得します。

GET /api/vms/{vm:id}/snapshots/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

スナップショットのディスク ID を特定します。

GET /api/vms/{vm:id}/snapshots/{snapshot:id}/disks HTTP/1.1
Accept: application/xml
Content-type: application/xml

スナップショットを、正しいインターフェイスタイプ (例: virtio_scsi) を使用して、アクティブディスクアタッチメントとしてバックアップ仮想マシンにアタッチします。
```
POST /api/vms/{vm:id}/diskattachments/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk_attachment>
	<active>true</active>
	<interface>_virtio_scsi_</interface>
	<disk id="{disk:id}">
	<snapshot id="{snapshot:id}"/>
	</disk>
</disk_attachment>
```
注記
ここで、{vm:id} を、以前にスナップショットを作成した仮想マシンではなく、バックアップ 仮想マシンの ID に置き換えます。{disk:id} をディスク ID に置き換えます。{snapshot:id} をスナップショット ID に置き換えます。
バックアップ仮想マシンのバックアップソフトウェアを使用して、スナップショットディスク上のデータをバックアップします。
バックアップ仮想マシンからスナップショットディスクアタッチメントを削除します。
```
DELETE /api/vms/{vm:id}/diskattachments/{snapshot:id} HTTP/1.1
Accept: application/xml
Content-type: application/xml
```
注記
ここで、{vm:id} を、以前にスナップショットを作成した仮想マシンではなく、バックアップ 仮想マシンの ID に置き換えます。{snapshot:id} をスナップショット ID に置き換えます。
必要に応じて、スナップショットを削除します。
```
DELETE /api/vms/{vm:id}/snapshots/{snapshot:id} HTTP/1.1
Accept: application/xml
Content-type: application/xml
```
注記
ここで、{vm:id} を、以前にスナップショットを作成した仮想マシンの ID に置き換えます。{snapshot:id} をスナップショット ID に置き換えます。

これで、別の仮想マシンにインストールされたバックアップソフトウェアを使用して、特定の時点における仮想マシンの状態をバックアップしました。

3.2.4.3. 仮想マシンの復元

バックアップおよびリストア API を使用してバックアップされた仮想マシンを復元します。この手順は、前のバックアップの管理に使用されたソフトウェアがインストールされているバックアップ仮想マシンがあることを前提としています。

手順

管理ポータルで、バックアップを復元するフローティングディスクを作成します。フローティングディスクの作成方法の詳細は、仮想ディスクの作成を参照してください。
ディスクをバックアップ仮想マシンに接続します。
```
POST /api/vms/{vm:id}/disks/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk id="{disk:id}">
</disk>
```
注記
ここで、{vm:id} を、以前にスナップショットを作成した仮想マシンではなく、この バックアップ 仮想マシンの ID に置き換えます。{disk:id} を、仮想マシンのバックアップ時に取得したディスク ID に置き換えます。
バックアップソフトウェアを使用して、バックアップをディスクに復元します。
バックアップ仮想マシンからディスクの割り当てを解除します。
```
DELETE /api/vms/{vm:id}/disks/{disk:id} HTTP/1.1
Accept: application/xml
Content-type: application/xml

<action>
    <detach>true</detach>
</action>
```
注記
ここで、{vm:id} を、以前にスナップショットを作成した仮想マシンではなく、この バックアップ 仮想マシンの ID に置き換えます。{disk:id} をディスク ID に置き換えます。

復元される仮想マシンの設定データを使用して、新しい仮想マシンを作成します。

POST /api/vms/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<vm>
    <cluster>
        <name>cluster_name</name>
    </cluster>
    <name>_NAME_</name>
      <initialization>
      <configuration>
  <data>
  <!-- omitting long ovf data -->
  </data>
      <type>ovf</type>
      </configuration>
      </initialization>
    ...
</vm>

注記

仮想マシンの作成時に ovf の任意の値を上書きするには、initialization 要素の前または後に要素を再定義します。initialization 要素内では定義しません。

ディスクを新規の仮想マシンにアタッチします。
```
POST /api/vms/{vm:id}/disks/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk id="{disk:id}">
</disk>
```
注記
ここで、{vm:id} を、以前にスナップショットを作成した仮想マシンではなく、新しい仮想マシンの ID に置き換えます。{disk:id} をディスク ID に置き換えます。

バックアップおよびリストア API を使用して作成されたバックアップを使用して、仮想マシンを復元しました。

3.2.5. 増分バックアップおよびリストア API を使用した仮想マシンのバックアップと復元

3.2.5.1. 増分バックアップおよび復元 API

Red Hat Virtualization は、QCOW2 または RAW 仮想ディスクの完全バックアップ、もしくは QCOW2 仮想ディスクの増分バックアップに、一時的なスナップショットなしで使用できる増分バックアップ API を提供します。バックアップされる仮想ディスクが QCOW2 であるか RAW であるかに関係なく、データは RAW 形式でバックアップされます。RAW ゲストデータ、および RAW または QCOW2 ディスクのいずれかを復元できます。増分バックアップ API は、RHV REST API の一部です。実行中または実行されていない仮想マシンをバックアップできます。

開発者は、API を使用してバックアップアプリケーションを開発できます。

機能

バックアップは、バックアップと復元 API を使用する場合よりも簡単、高速、堅牢です。増分バックアップ API は、バックアップアプリケーションとの統合を改善し、基盤となるディスクフォーマットに関係なく RAW ゲストデータのバックアップと復元を新たにサポートします。

無効なビットマップが原因でバックアップが失敗した場合は、バックアップチェーン内の特定のチェックポイントを削除できます。完全バックアップを実行する必要はありません。

制限事項:

RAW 形式のディスクではなく、QCOW2 形式のディスクのみを増分バックアップできます。バックアッププロセスでは、バックアップされたデータが RAW 形式で保存されます。
復元できるのは、RAW 形式でバックアップされたデータのみです。
増分リストアは、バックアップ時に存在していたスナップショットの復元をサポートしていません。増分リストアは、バックアップ時に存在していたスナップショット内のボリュームまたはイメージの構造ではなく、データのみを復元します。この制限は、他のシステムのバックアップソリューションでは一般的です。
バックアップソリューションの場合と同様に、増分リストアではデータのみが復元され、バックアップ時に存在していたスナップショットのボリュームやイメージの構造は復元されません。
原因が何であれ、仮想マシンのクリーンでないシャットダウンは、ディスク上のビットマップを無効にし、バックアップチェーン全体を無効にする可能性があります。無効なビットマップを使用して増分バックアップを復元すると、仮想マシンのデータが破損します。
バックアップを開始する以外に、無効なビットマップを検出する方法はありません。ディスクに無効なビットマップが含まれていると、操作は失敗します。

次の表に、増分バックアップをサポートするディスク設定を示します。

注記

管理ポータルを使用してディスクを作成するときは、ストレージタイプ、プロビジョニングタイプ、および増分バックアップを有効にするか無効にするかを設定します。これらの設定に基づいて、Manager は仮想ディスクの形式を決定します。

表3.1 増分バックアップでサポートされているディスク設定
ストレージタイプ	プロビジョニングタイプ	増分バックアップの場合	仮想ディスクの形式
block	thin	enabled	qcow2
block	preallocated	enabled	qcow2 (preallocated)
file	thin	enabled	qcow2
file	preallocated	enabled	qcow2 (preallocated)
block	thin	disabled	qcow2
block	preallocated	disabled	raw (preallocated)
file	thin	disabled	raw (sparse)
file	preallocated	disabled	raw (preallocated)
network	該当なし	disabled	raw
lun	該当なし	disabled	raw

3.2.5.1.1. 増分バックアップのフロー

増分バックアップ API を使用するバックアップアプリケーションは、次の順序に従って、増分バックアップがすでに有効になっている仮想マシンディスクをバックアップする必要があります。

バックアップアプリケーションは、REST API を使用して、バックアップに含める必要のある仮想マシンディスクを検索します。QCOW2 形式のディスクのみが含まれています。
バックアップアプリケーションは、完全バックアップまたは増分バックアップを開始します。API 呼び出しは、仮想マシン ID、オプションの以前のチェックポイント ID、およびバックアップするディスクのリストを指定します。API 呼び出しで以前のチェックポイント ID が指定されていない場合は、各ディスクの現在の状態に基づいて、指定されたディスク内のすべてのデータを含む完全バックアップが開始されます。
エンジンは、バックアップ用に仮想マシンを準備します。仮想マシンは、バックアップ中も実行を継続できます。
バックアップアプリケーションは、バックアップを開始する準備ができたことをエンジンが報告するまで、バックアップステータスについてエンジンをポーリングします。
バックアップを開始する準備ができると、バックアップアプリケーションは、バックアップに含まれるすべてのディスクに対してイメージ転送オブジェクトを作成します。
バックアップアプリケーションは、イメージ転送ごとに ovirt-imageio から変更されたブロックのリストを取得します。変更リストが利用できない場合、バックアップアプリケーションはエラーになります。
バックアップアプリケーションは、変更されたブロックを RAW 形式で ovirt-imageio からダウンロードし、バックアップメディアに保存します。変更されたブロックのリストが利用できない場合、バックアップアプリケーションはディスク全体のコピーにフォールバックできます。
バックアップアプリケーションは、すべてのイメージ転送を完了します。
バックアップアプリケーションは、REST API を使用してバックアップを完了します。

3.2.5.1.2. 増分リストアのフロー

増分バックアップ API を使用するバックアップアプリケーションは、次の手順に従って、バックアップされた仮想マシンディスクを復元する必要があります。

ユーザーは、バックアップアプリケーションを使用して、使用可能なバックアップに基づき復元ポイントを選択します。
バックアップアプリケーションは、復元されたデータを保持するために、新しいディスク、または既存のディスクを持つスナップショットを作成します。
バックアップアプリケーションは、format が raw であることを指定して、ディスクごとにアップロードイメージの転送を開始します。これにより、RAW データを QCOW2 ディスクにアップロードするときにフォーマット変換が可能になります。
バックアップアプリケーションは、API を使用してこの復元ポイントに含まれるデータを imageio に転送します。
バックアップアプリケーションは、イメージ転送を完了します。

3.2.5.1.3. 増分バックアップおよびリストア API タスク

増分バックアップおよび復元 API は、Red Hat Virtualization REST API ガイドに記載されています。バックアップおよび復元のフローには、以下のアクションが必要です。

3.2.5.1.4. 新しい仮想ディスクでの増分バックアップの有効化

仮想ディスクの増分バックアップを有効にして、仮想ディスクを増分バックアップに含まれるものとしてマークします。ディスクを追加する場合は、REST API または管理ポータルを使用して、すべてのディスクの増分バックアップを有効にできます。フルバックアップを使用するか、以前と同じ方法を適用して、増分バックアップが有効になっていない既存のディスクをバックアップできます。

注記

Manager では、ディスクを増分バックアップに含めるためにディスクを有効にする必要はありませんが、有効になっているディスクを追跡するために有効にすることができます。

増分バックアップではディスクを QCOW2 でフォーマットする必要があるため、RAW 形式ではなく QCOW2 形式を使用してください。

手順

新しい仮想ディスクを追加します。詳細は、仮想ディスクの作成を参照してください。
ディスクを設定するときは、Enable Incremental Backup チェックボックスをオンにします。

関連情報

API を使用したディスクの増分バックアップの有効化

3.2.5.1.5. 既存の RAW 仮想ディスクでの増分バックアップの有効化

増分バックアップは RAW 形式のディスクではサポートされていないため、増分バックアップを使用するには、すべての RAW 形式のディスクの上に QCOW2 形式のレイヤーが存在する必要があります。スナップショットを作成すると、QCOW2 レイヤーが生成され、スナップショットが作成された時点から、スナップショットに含まれるすべてのディスクで増分バックアップが有効になります。

警告

ディスクのベースレイヤーが RAW 形式を使用している場合、最後のスナップショットを削除し、最上位の QCOW2 レイヤーをベースレイヤーにマージすると、ディスクが RAW 形式に変換され、設定されている場合は増分バックアップが無効になります。増分バックアップを再度有効にするには、このディスクを含む新しいスナップショットを作成できます。

手順

管理ポータルで Compute Virtual Machines をクリックします。
仮想マシンを選択し、Disks タブをクリックします。
Edit ボタンをクリックします。Edit Disk ダイアログボックスが開きます。
Enable Incremental Backup チェックボックスを選択します。

関連情報

API を使用したディスクの増分バックアップの有効化

3.2.5.1.6. 増分バックアップの有効化

REST API リクエストを使用して、仮想マシンのディスクの増分バックアップを有効にできます。

手順

新しいディスクの増分バックアップを有効にします。たとえば、ID 123 の仮想マシンの新規ディスクでは、以下の要求を送信します。
```
POST /ovirt-engine/api/vms/123/diskattachments
```
要求の本文には、次のように、disk オブジェクトの一部として incremental に設定された backup を含める必要があります。
```
<disk_attachment>
    …
    <disk>
       …
       <backup>incremental</backup>
       …
    </disk>
</disk_attachment>
```

応答は次のとおりです。

<disk_attachment>
    …
    <disk href="/ovirt-engine/api/disks/456" id="456"/>
    …
</disk_attachment>

関連情報

RHV 用 REST API ガイド の DiskBackup 列挙型

3.2.5.1.7. 増分バックアップが有効になっているディスクの検索

指定した仮想マシンについて、増分バックアップが有効になっているディスクを、バックアッププロパティーに従ってフィルタリングして一覧表示できます。

手順

仮想マシンに接続されているディスクを一覧表示します。たとえば、ID 123 の仮想マシンの場合は、以下の要求を送信します。
```
GET /ovirt-engine/api/vms/123/diskattachments
```
応答にはすべての disk_attachment オブジェクトが含まれ、各オブジェクトには 1 つ以上の disk オブジェクトが含まれます。以下に例を示します。
```
<disk_attachments>
    <disk_attachment>
       …
       <disk href="/ovirt-engine/api/disks/456" id="456"/>
       …
    </disk_attachment>
    …
</disk_attachments>
```
disk サービスを使用して、前の手順のディスクプロパティーを表示します。たとえば、ID 456 のディスクの場合は、以下の要求を送信します。
```
GET /ovirt-engine/api/disks/456
```
応答には、ディスクのすべてのプロパティーが含まれます。backup は none または incremental に設定されています。以下に例を示します。
```
<disk href="/ovirt-engine/api/disks/456" id="456">
    …
    <backup>incremental</backup>
    …
</disk>
```

関連情報

3.2.5.1.8. フルバックアップの開始

フルバックアップの後、作成されたチェックポイント ID を次の増分バックアップの開始点として使用できます。

実行中の仮想マシンのバックアップを作成する場合、プロセスは、バックアップされるディスクと同じストレージドメインにスクラッチディスクを作成します。バックアッププロセスではこのディスクを作成して、バックアップ中に実行中の仮想マシンに新しいデータを書き込めるようにします。このスクラッチディスクは、バックアップ中に管理ポータルで確認できます。バックアップが終了すると自動的に削除されます。

フルバックアップを開始するには、本文を使用した要求呼び出しが必要であり、応答が含まれます。

手順

バックアップを作成する仮想マシンを指定する要求を送信します。たとえば、以下のように ID 123 の仮想マシンを指定します。
```
POST /ovirt-engine/api/vms/123/backups
```
要求の本文で、バックアップを作成するディスクを指定します。たとえば、ID 456 のディスクのフルバックアップを開始するには、以下の要求本文を送信します。
```
<backup>
    <disks>
       <disk id="456" />
       …
    </disks>
</backup>
```
応答本文は以下のようになります。
```
<backup id="789">
    <disks>
       <disk id="456" />
       …
       …
    </disks>
    <status>initializing</status>
    <creation_date>
</backup>
```
応答には以下が含まれます。
- バックアップ ID
- バックアップのステータス。バックアップが初期化中であることを示します。
ステータスが ready になるまでバックアップをポーリングします。応答には、to_checkpoint_id が含まれます。この ID をメモし、次の増分バックアップで from_checkpoint_id に使用します。

関連情報

RHV の REST API ガイド における VmBackups サービスの add メソッド

3.2.5.1.9. 増分バックアップの開始

特定の仮想ディスクのフルバックアップが完了すると、そのディスクの後続の増分バックアップには、最後のバックアップ以降の変更のみが含まれます。最新のバックアップの to_checkpoint_id の値を、要求本文の from_checkpoint_id の値として使用します。

増分バックアップまたは混合バックアップを開始するには、本文を使用した要求呼び出しが必要であり、応答が含まれます。

手順

バックアップを作成する仮想マシンを指定する要求を送信します。たとえば、以下のように ID 123 の仮想マシンを指定します。
```
POST /ovirt-engine/api/vms/123/backups
```
要求の本文で、バックアップを作成するディスクを指定します。たとえば、ID 456 のディスクの増分バックアップを開始するには、以下の要求本文を送信します。
```
<backup>
    <from_checkpoint_id>previous-checkpoint-uuid</from_checkpoint_id>
    <disks>
       <disk id="456" />
       …
    </disks>
</backup>
```
注記
要求本文に、前のチェックポイントに含まれていないディスクを含めると、要求はこのディスクの完全バックアップも実行します。たとえば、ID 789 のディスクはまだバックアップされていません。上記の要求本文に 789 のフルバックアップを追加するには、次のような要求本文を送信します。
```
<backup>
    <from_checkpoint_id>previous-checkpoint-uuid</from_checkpoint_id>
    <disks>
       <disk id="456" />
       <disk id="789" />
       …
    </disks>
</backup>
```
応答本文は以下のようになります。
```
<backup id="101112">
<from_checkpoint_id>previous-checkpoint-uuid</from_checkpoint_id>
<to_checkpoint_id>new-checkpoint-uuid</to_checkpoint_id>
    <disks>
       <disk id="456" />
       <disk id="789" />
       …
       …
    </disks>
    <status>initializing</status>
    <creation_date>
</backup>
```
応答には以下が含まれます。
- バックアップ ID
- バックアップに含まれていたディスクの ID。
- バックアップが初期化中であることを示すステータス。
ステータスが ready になるまでバックアップをポーリングします。応答には、to_checkpoint_id が含まれます。この ID をメモし、次の増分バックアップで from_checkpoint_id に使用します。

関連情報

RHV の REST API ガイド における VmBackups サービスの add メソッド

3.2.5.1.10. バックアップに関する情報の取得

新しい増分バックアップを開始するために使用できるバックアップに関する情報を取得できます。

VmBackups サービスの list メソッドは、バックアップに関する次の情報を返します。

バックアップされた各ディスクの ID
バックアップの開始チェックポイントおよび終了チェックポイントの ID
バックアップに含まれる各ディスクの、バックアップディスクイメージの ID。
バックアップのステータス
バックアップが作成された日付

<status> の値が ready になると、応答には <to_checkpoint_id> が含まれます。これは次の増分バックアップで <from_checkpoint_id> として使用され、仮想マシンストレージのバックアップにディスクのダウンロードを開始できます。

手順

ID 123 の仮想マシンの ID 456 のバックアップに関する情報を取得するには、以下のような要求を送信します。
```
GET /ovirt-engine/api/vms/456/backups/123
```
応答には、ID 456 のバックアップ (<from_checkpoint_id> 999 と <to_checkpoint_id> 666) が含まれます。バックアップに含まれるディスクは、<link> 要素で参照されます。
```
<backup id="456">
    <from_checkpoint_id>999</from_checkpoint_id>
    <to_checkpoint_id>666</to_checkpoint_id>
    <link href="/ovirt-engine/api/vms/456/backups/123/disks" rel="disks"/>
    <status>ready</status>
    <creation_date>
</backup>
```

関連情報

VmBackups サービスの list メソッド

3.2.5.1.11. バックアップ内のディスクに関する情報を取得

バックアップの各ディスクに使用されたバックアップモードなど、バックアップの一部であるディスクに関する情報を取得できます。これは、バックアップのダウンロードに使用するモードを決定するのに役立ちます。

VmBackupDisks サービスの list メソッドは、バックアップに関する次の情報を返します。

バックアップされた各ディスクの ID および名前。
バックアップに含まれる各ディスクの、バックアップディスクイメージの ID。
ディスクのフォーマット。
ディスクでサポートされているバックアップ動作。
ディスク用に作成されたバックアップタイプ (フル/増分)。

手順

ID 123 の仮想マシンの ID 456 のバックアップに関する情報を取得するには、以下のような要求を送信します。

GET /ovirt-engine/api/vms/456/backups/123/disks

応答には ID 789 のディスクが含まれ、ディスクイメージの ID は 555 です。

<disks>
    <disk id="789">
        <name>vm1_Disk1</name>
        <actual_size>671744</actual_size>
        <backup>incremental</backup>
        <backup_mode>full</backup_mode>
        <format>cow</format>
        <image_id>555</image_id>
        <qcow_version>qcow2_v3</qcow_version>
        <status>locked</status>
        <storage_type>image</storage_type>
        <total_size>0</total_size>
    </disk>
</disks>

関連情報

VmBackupDisks サービスの list メソッド

3.2.5.1.12. バックアップのファイナライズ

バックアップをファイナライズすると、バックアップが終了し、リソースのロックが解除され、クリーンアップが実行されます。バックアップサービスの finalize 方法を使用する

手順

ID が 123 の仮想マシンで ID が 456 のディスクのバックアップをファイナライズするには、次のような要求を送信します。
```
POST /vms/123/backups/456/finalize
```

関連情報

REST API ガイド で POST をファイナライズします。

3.2.5.1.13. 増分バックアップ用のイメージ転送オブジェクトの作成

バックアップをダウンロードする準備ができたら、バックアップアプリケーションは imagetransfer オブジェクトを作成する必要があります。これにより、増分バックアップの転送が開始されます。

イメージ転送オブジェクトを作成するには、本文を使用した要求呼び出しが必要です。

手順

次のような要求を送信します。
```
POST /ovirt-engine/api/imagetransfers
```
要求本文で、次のパラメーターを指定します。
- ディスク ID
- バックアップ ID
- download するディスクセットの方向
- raw に設定されたディスクのフォーマット
たとえば、ディスクの ID が 123 で、バックアップの ID が 456 であるディスクのバックアップを転送するには、次の要求本文を送信します。
```
<image_transfer>
    <disk id="123"/>
    <backup id="456"/>
    <direction>download</direction>
    <format>raw</format>
</image_transfer>
```

関連情報

RHV の REST API ガイド の imagetransfer オブジェクトを作成するための add メソッド。

3.2.5.1.14. 増分リストア用のイメージ転送オブジェクトの作成

増分バックアップ API を使用してバックアップされた raw データを QCOW2 フォーマットのディスクに復元できるようにするには、バックアップアプリケーションで imagetransfer オブジェクトを作成する必要があります。

転送フォーマットが raw で、基礎となるディスクフォーマットが QCOW2 の場合、アップロードされたデータは、ストレージへの書き込み時にオンザフライで QCOW2 フォーマットに変換されます。QCOW2 ディスクから RAW ディスクへのデータのアップロードはサポートされていません。

イメージ転送オブジェクトを作成するには、本文を使用した要求呼び出しが必要です。

手順

次のような要求を送信します。
```
POST /ovirt-engine/api/imagetransfers
```
要求本文で、次のパラメーターを指定します。
- ディスク ID またはスナップショット ID
- upload を行うディスクセットの方向
- raw に設定されたディスクのフォーマット
たとえば、ディスクの ID が 123 であるディスクのバックアップを転送するには、次の要求本文を送信します。
```
<image_transfer>
    <disk id="123"/>
    <direction>upload</direction>
    <format>raw</format>
</image_transfer>
```

関連情報

RHV の REST API ガイド の imagetransfer オブジェクトを作成するための add メソッド。

3.2.5.1.15. 仮想マシンのチェックポイントの一覧表示

要求呼び出しを送信することにより、各チェックポイントの情報を含む、仮想マシンのすべてのチェックポイントを一覧表示できます。

手順

仮想マシンを指定する要求を送信します。たとえば、以下のように ID 123 の仮想マシンを指定します。
```
GET /vms/123/checkpoints/
```

応答には、すべての仮想マシンのチェックポイントが含まれます。各チェックポイントには、次の情報が含まれています。

チェックポイントのディスク
親チェックポイントの ID
チェックポイントの作成日
所属する仮想マシン

以下に例を示します。

<parent_id>, <creation_date> and the virtual machine it belongs to <vm>:
<checkpoints>
    <checkpoint id="456">
         <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/>
         <parent_id>parent-checkpoint-uuid</parent_id>
         <creation_date>xxx</creation_date>
         <vm href="/ovirt-engine/api/vms/123" id="123"/>
    </checkpoint>
</checkpoints>

関連情報

RHV の REST API ガイド の仮想マシンチェックポイントを一覧表示する list メソッド

3.2.5.1.16. 仮想マシンの特定チェックポイントの一覧表示

要求呼び出しを送信することにより、仮想マシンの特定チェックポイントの情報を一覧表示できます。

手順

仮想マシンを指定する要求を送信します。たとえば、以下のように ID 123 の仮想マシンと ID 456 のチェックポイントを指定します。
```
GET /vms/123/checkpoints/456
```

応答には、チェックポイントに関する次の情報が含まれます。

チェックポイントのディスク
親チェックポイントの ID
チェックポイントの作成日
所属する仮想マシン

以下に例を示します。

<checkpoint id="456">
     <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/>
     <parent_id>parent-checkpoint-uuid</parent_id>
     <creation_date>xxx</creation_date>
     <vm href="/ovirt-engine/api/vms/123" id="123"/>
</checkpoint>

関連情報

RHV の REST API ガイド の仮想マシンチェックポイントを一覧表示する list メソッド

3.2.5.1.17. チェックポイントの削除

DELETE 要求を送信して、仮想マシンのチェックポイントを削除できます。仮想マシンが実行しているかどうかに関係なく、仮想マシン上のチェックポイントを削除できます。

手順

仮想マシンおよびチェックポイントを指定してリクエストを送信します。たとえば、以下のように ID 123 の仮想マシンと、ID 456 のチェックポイントを指定します。
```
DELETE /vms/123/checkpoints/456/
```

関連情報

VmCheckpoint の remove メソッド

3.2.5.1.18. imageio API を使用したバックアップデータの転送

イメージ転送 API は、イメージ転送を開始および停止します。結果は転送 URL です。

imageio API を使用して、転送 URL から実際にデータを転送します。

imageio API の使用方法に関する詳細は、ovirt-imageio Images API リファレンスを参照してください。

表3.2 増分バックアップと復元で使用される imageio Image API メソッド
API 要求	説明	imageio Image API リファレンスセクション
`OPTIONS /images/{ticket-id} HTTP/1.1`	サーバーオプションを取得して、サーバーがサポートする機能を確認します。	OPTIONS を参照してください。
`GET /images/{ticket-id}/extents`	ディスクイメージのコンテンツと割り当て、または増分バックアップ中に変更されたブロックに関する情報を取得します。この情報は、エクステント情報として知られています。	EXTENTS を参照してください。
`GET /images/{ticket-id}/extent?context=dirty`	イメージ転送を行うプログラムは、バックアップから変更をダウンロードする必要があります。これらの変更は、ダーティエクステントとして知られています。変更をダウンロードするには、次のようなリクエストを送信します。	EXTENTS→ Examples→ Request dirty extents を参照してください。
`PUT /images/{ticket-id}`	バックアップアプリケーションは、復元されたデータを保持するために、新しいディスク、または既存のディスクを持つスナップショットを作成します。	PUT を参照してください。

関連情報

Red Hat Virtualization Python SDK には、バックアップの転送を開始するために使用できるいくつかの実装例が含まれています。

3.2. バックアップと移行

3.2.1. Red Hat Virtualization Manager のバックアップと復元

3.2.1.1. Red Hat Virtualization Manager のバックアップ - 概要

3.2.1.2. engine-backup コマンドの構文

3.2.1.3. engine-backup コマンドを使用してバックアップを作成

3.2.1.4. engine-backup コマンドを使用したバックアップの復元

3.2.1.5. バックアップを新規インストールに復元

3.2.1.6. バックアップを復元して既存のインストールを上書き

3.2.1.7. 異なる認証情報を使用したバックアップの復元

3.2.1.8. セルフホスト型エンジンのバックアップおよび復元

3.2.1.8.1. 元の Manager のバックアップ

3.2.1.8.2. 新しいセルフホスト型エンジンでのバックアップの復元

3.2.1.8.3. Red Hat Virtualization Manager リポジトリーの有効化

3.2.1.8.4. ホストの再インストール

3.2.1.8.5. ストレージドメインの削除

3.2.1.9. 既存のバックアップからのセルフホスト型エンジンの復元

3.2.1.9.1. 新しいセルフホスト型エンジンでのバックアップの復元

3.2.1.9.2. Red Hat Virtualization Manager リポジトリーの有効化

3.2.1.9.3. ホストの再インストール

3.2.1.9.4. ストレージドメインの削除

3.2.1.10. 既存のバックアップからのセルフホスト型エンジンの上書き

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

3.2.1.10.2. バックアップを復元して既存のインストールを上書き

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

3.2.2. データウェアハウスを別のマシンに移行

3.2.2.1. 別のマシンへの Data Warehouse データベースの移行

3.2.2.1.1. Red Hat Virtualization Manager リポジトリーの有効化

3.2.2.1.2. 別のマシンへの Data Warehouse データベースの移行

3.2.2.2. 別のマシンへの Data Warehouse サービスの移行

3.2.2.2.1. 新たな Data Warehouse マシンの準備

3.2.2.2.2. Manager マシンでの Data Warehouse サービスの停止

3.2.2.2.3. 新たな Data Warehouse マシンの設定

3.2.2.2.4. Manager マシンでの Data Warehouse サービスの無効化

3.2.3. バックアップストレージドメインを使用した仮想マシンのバックアップと復元

3.2.3.1. バックアップストレージドメインの説明

3.2.3.2. データストレージドメインをバックアップドメインに設定

3.2.3.3. バックアップドメインを使用した仮想マシンおよびスナップショットのバックアップと復元

3.2.4. バックアップおよびリストア API を使用した仮想マシンのバックアップおよび復元

3.2.4.1. バックアップおよびリストア API

3.2.4.2. 仮想マシンのバックアップ

3.2.4.3. 仮想マシンの復元

3.2.5. 増分バックアップおよびリストア API を使用した仮想マシンのバックアップと復元

3.2.5.1. 増分バックアップおよび復元 API

3.2.5.1.1. 増分バックアップのフロー

3.2.5.1.2. 増分リストアのフロー

3.2.5.1.3. 増分バックアップおよびリストア API タスク

3.2.5.1.4. 新しい仮想ディスクでの増分バックアップの有効化

3.2.5.1.5. 既存の RAW 仮想ディスクでの増分バックアップの有効化

3.2.5.1.6. 増分バックアップの有効化

3.2.5.1.7. 増分バックアップが有効になっているディスクの検索

3.2.5.1.8. フルバックアップの開始

3.2.5.1.9. 増分バックアップの開始

3.2.5.1.10. バックアップに関する情報の取得

3.2.5.1.11. バックアップ内のディスクに関する情報を取得

3.2.5.1.12. バックアップのファイナライズ

3.2.5.1.13. 増分バックアップ用のイメージ転送オブジェクトの作成

3.2.5.1.14. 増分リストア用のイメージ転送オブジェクトの作成

3.2.5.1.15. 仮想マシンのチェックポイントの一覧表示

3.2.5.1.16. 仮想マシンの特定チェックポイントの一覧表示

3.2.5.1.17. チェックポイントの削除

3.2.5.1.18. imageio API を使用したバックアップデータの転送

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links