Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
4.4. virsh を使用した KVM のライブ移行
virsh コマンドを使用すると、ゲスト仮想マシンを別のホスト物理マシンに移行できます。migrate コマンドは、以下の形式のパラメーターを受け付けます。
# virsh migrate --live GuestName DestinationURL
ライブマイグレーションが望ましくない場合は、
-live
オプションが削除される可能性があることに注意してください。追加オプションは、「virsh migrate コマンドの追加オプション」 に一覧表示されています。
GuestName
パラメーターは、移行するゲスト仮想マシンの名前を表します。
DestinationURL
パラメーターは、移行先ホストの物理マシンの接続 URL です。移行先システムで同じバージョンの Red Hat Enterprise Linux を実行し、同じハイパーバイザーを使用し、libvirt を実行している必要があります。
注記
通常の移行およびピアツーピア移行の
DestinationURL
パラメーターには、以下のセマンティクスがあります。
- 通常の移行:
DestinationURL
は、ソースゲスト仮想マシンから見たターゲットホスト物理マシンの URL です。 - ピアツーピアの移行:
DestinationURL
は、移行元ホストの物理マシンから表示されるターゲットホストの物理マシンの URL です。
コマンドを入力すると、インストール先システムの root パスワードを求められます。
重要
移行を成功させるには、移行元サーバーの
/etc/hosts
ファイルに移行先ホストの物理マシンのエントリーが必要です。次の例に示すように、宛先ホストの物理マシンの IP アドレスとホスト名をこのファイルに入力し、宛先ホストの物理マシンの IP アドレスとホスト名を置き換えます。
10.0.0.20 host2.example.com
例:virsh を使用したライブマイグレーション
この例では、host1.example.com
から host2.example.com
に移行します。使用環境に合わせて、ホストの物理マシン名を変更します。この例では、guest1-rhel6-64
という名前の仮想マシンを移行します。
この例では、共有ストレージを完全に設定し、すべての前提条件 (ここでは 移行の要件) を満たしていることを前提としています。
ゲスト仮想マシンが実行していることを確認します。
移行元システムで、host1.example.com
を実行し、guest1-rhel6-64
が実行していることを確認します。[root@host1 ~]# virsh list Id Name State ---------------------------------- 10 guest1-rhel6-64 running
ゲスト仮想マシンの移行
次のコマンドを実行して、ゲスト仮想マシンを移行先host2.example.com
にライブ移行します。リンク先の URL の末尾に/system
を追加し、フルアクセスが必要であることを libvirt に指示します。# virsh migrate --live
guest1-rhel6-64 qemu+ssh://host2.example.com/system
コマンドを入力すると、インストール先システムの root パスワードを求められます。待機
負荷やゲスト仮想マシンのサイズによっては、移行に時間がかかる場合があります。virsh はエラーのみを報告します。ゲスト仮想マシンは、完全に移行するまで、移行元ホストの物理マシンで実行し続けます。注記移行中、完了率インジケーターの数は、プロセスが完了する前に複数回減少する可能性があります。これは、移行の開始後に変更されたソースメモリーページを再度コピーする必要があるため、全体的な進行状況の再計算が原因で発生します。したがって、この動作は予期されたものであり、移行に問題があることを示すものではありません。ゲスト仮想マシンが移行先ホストに到達していることを確認する
宛先システムhost2.example.com
から、guest1-rhel6-64
が実行されていることを確認します。[root@host2 ~]# virsh list Id Name State ---------------------------------- 10 guest1-rhel6-64 running
これで、ライブマイグレーションが完了しました。
注記
libvirt は、TLS/SSL ソケット、UNIX ソケット、SSH、暗号化されていない TCP など、さまざまなネットワーク方式をサポートしています。他の方法の使用に関する詳細は、5章ゲストのリモート管理 を参照してください。
注記
実行されていないゲスト仮想マシンは、virshmigrate コマンドを使用して移行できません。実行していないゲスト仮想マシンを移行するには、以下のスクリプトを使用する必要があります。
virsh dumpxml Guest1 > Guest1.xml virsh -c qemu+ssh://<target-system-FQDN> define Guest1.xml virsh undefine Guest1
4.4.1. virsh を使用した移行に関する追加のヒント
複数の同時ライブマイグレーションを実行できます。各移行は、個別のコマンドシェルで実行されます。ただし、これは慎重に行ってください。各移行インスタンスでは、双方 (ソースおよびターゲット) から 1 つの MAX_CLIENT を使用するため、注意して計算を行う必要があります。デフォルト設定は 20 であるため、設定を変更せずに 10 インスタンスを実行できます。設定を変更する必要がある場合は、手順 手順4.1「libvirtd.conf の設定」 を参照してください。
- 手順4.1「libvirtd.conf の設定」 の説明に従って、libvirtd.conf ファイルを開きます。
- Processing controls のセクションを探します。
################################################################# # # Processing controls # # The maximum number of concurrent client connections to allow # over all sockets combined. #max_clients = 20 # The minimum limit sets the number of workers to start up # initially. If the number of active clients exceeds this, # then more threads are spawned, upto max_workers limit. # Typically you'd want max_workers to equal maximum number # of clients allowed #min_workers = 5 #max_workers = 20 # The number of priority workers. If all workers from above # pool will stuck, some calls marked as high priority # (notably domainDestroy) can be executed in this pool. #prio_workers = 5 # Total global limit on concurrent RPC calls. Should be # at least as large as max_workers. Beyond this, RPC requests # will be read into memory and queued. This directly impact # memory usage, currently each request requires 256 KB of # memory. So by default upto 5 MB of memory is used # # XXX this isn't actually enforced yet, only the per-client # limit is used so far #max_requests = 20 # Limit on concurrent requests from a single client # connection. To avoid one client monopolizing the server # this should be a small fraction of the global max_requests # and max_workers parameter #max_client_requests = 5 #################################################################
max_clients
およびmax_workers
パラメーターの設定を変更します。両方のパラメーターの番号が同じであることが推奨されます。max_clients
は、移行ごとに 2 つのクライアント (各側に 1 つ) を使用します。max_workers
は、実行フェーズ中に移行元で 1 つのワーカーと、移行先で 0 のワーカーを使用し、終了フェーズ中に移行先でワーカーを 1 つ使用します。重要max_clients
パラメーターおよびmax_workers
パラメーターの設定は、libvirtd サービスへのゲスト仮想マシンのすべての接続の影響を受けます。つまり、同じゲスト仮想マシンを使用しているユーザーで、同時に移行を実行しているすべてのユーザーは、max_clients
およびmax_workers
パラメーター設定で設定される制限にも古いことになります。このため、同時ライブマイグレーションを実行する前に、最大値を慎重に検討する必要があります。- ファイルを保存し、サービスを再起動します。注記起動したにもかかわらず認証されていない ssh セッションが多すぎるために、移行接続が切断する場合があります。デフォルトでは、
sshd
で許可されるセッションは 10 セッションのみで、常に "pre-authenticated state" となります。この設定は、sshd 設定ファイル (ここでは/etc/ssh/sshd_config
) のMaxStartups
パラメーターで制御されます。これには調整が必要な場合があります。この制限は DoS 攻撃 (および一般的なリソースの過剰使用) を防ぐために設定されているため、このパラメーターの調整は慎重に行ってください。この値を高く設定しすぎると、目的が無効になります。このパラメーターを変更するには、ファイル/etc/ssh/sshd_config
を変更し、MaxStartups 行の先頭から#を削除して、10
(デフォルト値) をより大きな数値に変更します。必ず保存して、sshd
サービスを再起動してください。詳細は、sshd_config
の man ページを参照してください。