ホスト間でゲストを移行することは複雑な問題です。考えられる解決策はたくさんあり、それぞれの解決策には独自の長所と短所があります。「ハイパーバイザー統合」と「管理者デプロイメント」の最大限の柔軟性を実現するために、libvirtはさまざまな移行オプションを実装しています。
データ転送方法
移行中に使用されるデータ送信には、2つのオプションがあります。ハイパーバイザーの「生の送信」、またはlibvirtd接続を介した「トンネル送信」です。
オリジナルの送信（ハイパーバイザーが提供）
「元の送信」は、問題のハイパーバイザーによっては必ずしも暗号化をサポートしていませんが、通常、関連するデータコピーの数を最小限に抑えることで、計算コストを最小限に抑えます。「元の送信」では、管理者がホストを展開するときに、追加の「ハイパーバイザー固有」のネットワーク構成手順を実行する必要もあります。一部のハイパーバイザーでは、複数の同時移行操作を可能にするために、ファイアウォールで多数のポートを開く必要がある場合があります。
トンネリング（libvirtが提供）
「トンネリング」は、libvirtのRPCプロトコルの組み込み機能を利用できるため、強力な暗号化を可能にします。ただし、「トンネリング」の欠点は、データがlibvirtdとHypervisorの間を移動するときに、追加のデータコピーがソースホストとターゲットホストの両方に含まれることです。RAMが非常に大きいゲストの場合、これはより重要な問題である可能性があり、メモリページがすぐに損傷します。展開に関しては、「トンネリング」はlibvirtdの追加のネットワーク構成を必要とせず、「リモートアクセス」には十分であり、複数の同時移行操作をサポートするには、ファイアウォールで1つのポートを開くだけで済みます。
通信制御フロー
仮想マシンを移行するには、「関係する2つのホスト」と「移行を呼び出す手順」を緊密に調整する必要があります。3つのホスト（ソースホスト、宛先ホスト、および3番目のホスト）が存在する場合があります。
管理の直接移行（クライアントを介して完了）
「直接移行の管理」を通じて、「libvirtクライアントプロセス」は移行のすべての段階を制御できます。「クライアント」は、「ソースホスト」と「ターゲットホスト」の両方でlibvirtdデーモンに接続して認証できる必要があります。2つのlibvirtdデーモンは相互に通信する必要はありません。「クライアント」は、移行プロセス中にクラッシュ（またはその他）が原因でlibvirtdとの接続を失った場合、移行を中止し、「ソースホスト」でゲストのCPUを再起動しようとします。この操作を安全に完了できない場合があります。その場合、ゲストは1つまたは2つのホストで一時停止されます。
管理されたピアツーピア移行（libvirtdを介して実行）
「ピアツーピア移行」を通じて、「libvirtクライアントプロセス」は「ソースホスト」上の「libvirtdデーモン」とのみ通信します。「ソースlibvirtdデーモン」は「ターゲットホストlibvirtd」に直接接続して、移行プロセス全体を制御します。「クライアントプログラム」がクラッシュした場合（またはそれ以外の場合）、libvirtdとの接続が失われた場合、移行プロセスは完了するまで中断されることなく続行されます。
「ソースlibvirtd」は、「ソースlibvirtd」資格情報への接続に使用される「クライアント」ではなく、「ターゲットlibvirtd」への接続に独自の資格情報（通常はルート）を使用することに注意してください。これらが異なる場合、通常は発生します。 「クライアント」は「ターゲットホスト」に直接接続できますが、「ソースホスト」はピアツーピア移行の接続を確立できません。
非管理の直接移行（ハイパーバイザーによって完了）
「非管理直接移行」を使用すると、「libvirtクライアント」または「libvirtdデーモン」は移行プロセスを制御しません。代わりに、ハイパーバイザーの管理サービス（存在する場合）に制御が与えられます。「libvirtクライアント」は、「ハイパーバイザー管理レイヤー」を介してのみ移行を開始します。libvirtクライアントまたはlibvirtdがクラッシュした場合、移行プロセスは完了するまで中断されることなく続行されます。
データセキュリティについて
移行データストリームにはゲストOSRAMの完全なコピーが含まれているため、移行データストリームを監視すると、ゲスト情報が損なわれる可能性があります。ホストに複数のネットワークインターフェイスがある場合、またはスイッチが「VLANタグ」をサポートしている場合は、「ゲストネットワークトラフィック」を「移行/管理トラフィック」から分離することが非常に望ましいです。
場合によっては、「個別のデータ移行ネットワーク」でも十分なセキュリティが提供されないことがあります。この場合、「移行データストリーム」を暗号化できます。ハイパーバイザー自体が暗号化を提供しない場合は、「libvirtトンネリング」を使用する必要があります。
「移行URI」に関する注記
「ゲスト仮想マシンの移行を開始する」では、「選択した制御フロー」と「使用するAPI」に応じて、「クライアントアプリケーション」で最大3つのURIを指定する必要があります。
最初のURIは、ゲストが現在実行されているマシンである「ソースホストのlibvirt」に接続されているURIです。
2番目のURIは、「ターゲットホストのlibvirt」、つまりゲストが移動されるホストに接続されたURIです（「ピアツーピア移行」では、これは「ソース」の観点からです）。 、「クライアント」ではありません）。
3番目のURIは「ハイパーバイザー固有の」URIであり、ゲスト仮想マシンの移行方法を制御するために使用されます。
「管理直接移行」移行フローでは、最初と2番目のURIが必須であり、3番目のURIはオプションです。「非管理直接移行」モードを使用すると、最初と3番目のURIは必須であり、2番目のURIは使用されません。
通常、「管理アプリケーション」は、一般的なlibvirt接続URI形式である最初と2番目のURIのみを考慮する必要があります。次に、Libvirtは、ターゲットホストで構成されているホスト名を検索することにより、「ハイパーバイザー固有のURI」を自動的に判別します。場合によっては、「管理アプリケーション」が3番目のURIを直接制御したい場合があります。
構成されたホスト名が正しくないか、DNSが破損しています。ホストのホスト名をIPアドレスに解決できない場合、libvirtは誤ったURIを生成します。この場合、「管理アプリケーション」は、「IPアドレス」または「正しいホスト名」を使用して「ハイパーバイザー固有のURI」を明確に指定する必要があります。
ホストには複数のネットワークインターフェイスがあります。ホストに複数のネットワークインターフェイスがある場合、セキュリティまたはパフォーマンス上の理由から、特定のインターフェイスを介して移行データストリームを送信する必要がある場合があります。この場合、「管理アプリケーション」は「使用するネットワークに関連付けられたIPアドレス」を使用して「ハイパーバイザー固有のURI」を指定する必要があります。
ファイアウォールは使用可能なポートを制限します。libvirtが移行URIを生成するとき、ハイパーバイザー固有のルールを使用してポート番号を選択します。一部のハイパーバイザーはファイアウォールでポートを開くだけで済みますが、他のハイパーバイザーは一連のポート番号を必要とします。後者の場合、管理アプリケーションは、ローカルファイアウォールポリシーに準拠するために、デフォルトの範囲外の特定のポート番号を選択したい場合があります。
構成ファイルの処理
libvirtでは、2つの新しいタイプの仮想マシンが知られています。
*一時的な状態：実行時にのみ存在し、構成ファイルはディスクに保存されません。 *永続的な状態：ゲストが実行されていない場合でも、構成ファイルはディスクに保存されます。
デフォルトでは、移行アクションは「宛先ホスト」と「ソースホスト」の構成ファイルを変更しません。管理者（またはアプリケーション）は、構成ファイルの配布を管理する責任があります。/ etc / libvirt /ディレクトリをホスト間で共有しないように注意してください。
ここにいくつかの典型的なシナリオがあります：
libvirtの外部では、一元化された構成ファイルは共有ストレージにあります。「クラスター対応管理アプリケーション」は、クラスターファイルシステム内のすべての「メインゲスト構成ファイル」を維持できます。ゲスト仮想マシンを起動しようとすると、構成が「クラスターファイルシステム」から読み取られ、「永続ゲスト仮想マシン」の展開に使用されます。移行するには、構成を「ターゲットホスト」にコピーし、「元のホスト」で削除する必要があります。
libvirtの外部では、一元化された構成ファイルがデータベースにあります。「データセンター管理アプリケーション」は、構成ファイルをまったく保存しない場合があります。代わりに、ゲスト仮想マシンの起動時にlibvirtXMLを動的に生成できます。通常、一時的なゲスト仮想マシンを使用するため、移行中に構成ファイルを考慮する必要はありません。
libvirtでの分散構成。各ゲスト仮想マシンの構成ファイルは、ゲスト仮想マシンを実行できる各ホストにコピーされます。移行後は、既存の構成を変更するだけで更新できます。
libvirt内の一時的な構成管理。すべてのゲストは特定のホストにバインドされており、移行することはめったにありません。移行が必要な場合、構成は1つのホストから別のホストに移動されます。
上記のように、デフォルトでは、libvirtは移行中に構成ファイルを変更しません。virshコマンドには、この動作を制御するための2つのフラグがあります。
* '' --undefine-source ''：移行が成功したら、「ソースホスト」の構成ファイルを削除します。 * '' --persist ''：移行が成功したら、「ターゲットホスト」に構成ファイルを作成します。
マニュアルには、さまざまな状況での構成ファイルの結果をまとめた表があります。「構成ファイルの処理」
一般的な移行シナリオ
＃ネイティブ移行、クライアントから1つのlibvirtdサーバーへ
APIレベルでは、virDomainMigrateToURIが必要であり、VIR_MIGRATE_PEER2PEERフラグは設定されておらず、パラメーターuriは「ハイパーバイザー固有のURI」の形式です。
「ターゲットホスト」に「libvirtdインスタンス」が存在することを使用しない/必要としない。この方法は通常、ハイパーバイザーに独自の「元の管理デーモン」があり、「ターゲットホスト」での着信移行の試行を処理する場合に使用されます。
＃！/ bin / sh ＃構文：virsh merge GUESTNAME HV-URI ＃たとえば、すべての接続に同じ libvirtURIを使用するvirshmigrate --direct web1 xenmigr：// desthost / ＃CLIENT-> SRC LIVBIRTD-> SRC HYPERVISOR-> DEST HYPERVISOR
サポートドライバー：Xen
＃ネイティブ移行、クライアントから2つのlibvirtdサーバーへ
APIレベルでは、VIR_MIGRATE_PEER2PEERフラグを設定せずにvirDomainMigrateを使用する必要があります。
「ターゲットホスト上のlibvirtdサービス」は、「メインホスト名」に基づいて「移行に使用される元のハイパーバイザーURI」を自動的に決定します。
＃！/ bin / sh ＃構文：virsh merge GUESTNAME DEST-LIBVIRT-URI [HV-URI] ＃たとえば、デフォルトのネットワークインターフェイスを 使用するvirshmigrate web1 qemu + ssh：// desthost / system virshmigrate web1 xen + tls：// desthost / system ＃例：セカンダリネットワークインターフェイスの使用 ＃代替ネットワークインターフェイスを介した移行を強制するには、「ハイパー バイザー固有のURI」を指定する必要がありますvirsh merge web1 qemu：// desthost / system tcp：//10.0.0.1/ virsh merge web1 xen + tcp：// desthost / system xenmigr：10.0.0.1 /
サポートドライバー：Xen、QEMU、VMware、VirtualBox
ネイティブ移行、クライアントから2つのlibvirtdサーバー間のpeer2peer
virDomainMigrate、VIR_MIGRATE_PEER2PEERフラグが設定され、パラメーターuriで使用されるlibvirtURI形式。
「ターゲットlibvirtdサービス」は、「プライマリホスト名」に基づいて「移行に使用される元のハイパーバイザーURI」を自動的に決定します。オプションのuriパラメーターは、「クライアントがターゲットホストへの接続に使用するのと同じアドレス」を使用してアクセスできない場合、または別の「暗号化/認証」スキームが必要な場合に、「ソースlibvirtd」が「ターゲットlibvirtd」に接続する方法を制御します。この方法を使用して、「元の移行」に代替ネットワークインターフェイスの使用を強制することはできません。
virshからこのモードを呼び出すことはできません
QEMUドライバーでサポート
＃ネイティブ移行、2つのlibvirtdサーバー間のpeer2peer
virDomainMigrateToURI、VIR_MIGRATE_PEER2PEERフラグが設定され、パラメーターuriはlibvirtURI形式を使用します。「ターゲットlibvirtdサービス」は、「プライマリホスト名」に基づいて移行用の「元のハイパーバイザーURI」を自動的に決定します。この方法を使用して、「元の移行」に代替ネットワークインターフェイスの使用を強制することはできません。ターゲットURIにアクセスするには、ソースlibvirtd資格情報を使用する必要があります（「ソースホスト」に接続するときのクライアントの資格情報と必ずしも同じではありません）。
＃！/ bin / sh ＃構文：virsh merge GUESTNAME DEST-LIBVIRT-URI [ALT-DEST-LIBVIRT-URI] ＃たとえば、すべての接続に同じ libvirtURIを使用するvirshmigrate --p2p web1 qemu + ssh：// desthost / system ＃例：peer2peer接続に異なるlibvirtURI認証スキームを 使用するvirshmigrate --p2p web1 qemu + ssh：// desthost / system qemu + tls：/ desthost / system ＃例：peer2peer接続に異なるlibvirtURIホスト名を 使用するvirshmigrate --p2p web1 qemu + ssh：// desthost / system qemu + ssh：//10.0.0.1/system
QEMUドライバーでサポート
2つのlibvirtdサーバー間のトンネル移行、クライアントおよびpeer2peer
virDomainMigrate、設定VIR_MIGRATE_PEER2PEERとVIR_MIGRATE_TUNNELLEDフラグを、パラメータのURIが使用するlibvirtのURI形式。「ターゲットlibvirtdサービス」は、「プライマリホスト名」に基づいて移行用の「元のHypervirosURI」を自動的に決定します。オプションのuriパラメーターは、「クライアントがターゲットホストへの接続に使用するのと同じアドレス」を使用してアクセスできない場合、または別の「暗号化/認証」スキームが必要な場合に、「ソースlibvirtd」が「ターゲットlibvirtd」に接続する方法を制御します。「元のハイパーバイザーURI」形式は使用されません。
virshからこのモードを呼び出すことはできません
QEMUドライバーでサポート
＃トンネル移行、2つのlibvirtdサーバー間のpeer2peer
virDomainMigrateToURIは、設定VIR_MIGRATE_PEER2PEERとVIR_MIGRATE_TUNNELLEDフラグ、およびパラメータURIはlibvirtのURIフォーマットを使用しています。「ターゲットlibvirtdサービス」は、「プライマリホスト名」に基づいて移行用の「元のハイパーバイザーURI」を自動的に決定します。オプションのuriパラメーターは、「クライアントがターゲットホストへの接続に使用するのと同じアドレス」を使用してアクセスできない場合、または別の「暗号化/認証」スキームが必要な場合に、「ソースlibvirtd」が「ターゲットlibvirtd」に接続する方法を制御します。「元のハイパーバイザーURI」形式は使用されません。ターゲットURIにアクセスするには、「ソースlibvirtd資格情報」（「ソース」に接続するときの「クライアント」資格情報と必ずしも同じではありません）を使用する必要があります。
＃！/ bin / sh ＃構文：virsh merge GUESTNAME DEST-LIBVIRT-URI [ALT-DEST-LIBVIRT-URI] ＃たとえば、すべての接続に同じ libvirtURIを使用するvirshmigrate --p2p --tunnelled web1 qemu + ssh：// desthost / system ＃例：peer2peer接続に異なるlibvirtURI認証スキームを 使用virshmigrate --p2p --tunnelled web1 qemu + ssh：// desthost / system qemu + tls：/ desthost / system ＃例：peer2peer接続に異なるlibvirtURIホスト名を使用 virsh merge --p2p --tunnelled web1 qemu + ssh：// desthost / system qemu + ssh：//10.0.0.1/system
QEMUドライバーでサポートされています。
関連記事
「QEMU、KVM、libvirt」-その他の
「KVM」-環境設定「KVM」-一般的な
エラーと注意事項
「KVM」-CPUモデルとトポロジ（未完成）
「KVM」-ネットワーキング