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 という名前の仮想マシンを移行します。

この例では、共有ストレージを完全に設定し、すべての前提条件 (ここでは 移行の要件) を満たしていることを前提としています。
  1. ゲスト仮想マシンが実行していることを確認します。

    移行元システムで、host1.example.com を実行し、guest1-rhel6-64 が実行していることを確認します。
    [root@host1 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 guest1-rhel6-64     running
    
  2. ゲスト仮想マシンの移行

    次のコマンドを実行して、ゲスト仮想マシンを移行先 host2.example.com にライブ移行します。リンク先の URL の末尾に /system を追加し、フルアクセスが必要であることを libvirt に指示します。
    # virsh migrate --live guest1-rhel6-64 qemu+ssh://host2.example.com/system
    コマンドを入力すると、インストール先システムの root パスワードを求められます。
  3. 待機

    負荷やゲスト仮想マシンのサイズによっては、移行に時間がかかる場合があります。virsh はエラーのみを報告します。ゲスト仮想マシンは、完全に移行するまで、移行元ホストの物理マシンで実行し続けます。
    注記
    移行中、完了率インジケーターの数は、プロセスが完了する前に複数回減少する可能性があります。これは、移行の開始後に変更されたソースメモリーページを再度コピーする必要があるため、全体的な進行状況の再計算が原因で発生します。したがって、この動作は予期されたものであり、移行に問題があることを示すものではありません。
  4. ゲスト仮想マシンが移行先ホストに到達していることを確認する

    宛先システム 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 の設定」 を参照してください。
  1. 手順4.1「libvirtd.conf の設定」 の説明に従って、libvirtd.conf ファイルを開きます。
  2. 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
    
    #################################################################
    
  3. max_clients および max_workers パラメーターの設定を変更します。両方のパラメーターの番号が同じであることが推奨されます。max_clients は、移行ごとに 2 つのクライアント (各側に 1 つ) を使用します。max_workers は、実行フェーズ中に移行元で 1 つのワーカーと、移行先で 0 のワーカーを使用し、終了フェーズ中に移行先でワーカーを 1 つ使用します。
    重要
    max_clients パラメーターおよび max_workers パラメーターの設定は、libvirtd サービスへのゲスト仮想マシンのすべての接続の影響を受けます。つまり、同じゲスト仮想マシンを使用しているユーザーで、同時に移行を実行しているすべてのユーザーは、max_clients および max_workers パラメーター設定で設定される制限にも古いことになります。このため、同時ライブマイグレーションを実行する前に、最大値を慎重に検討する必要があります。
  4. ファイルを保存し、サービスを再起動します。
    注記
    起動したにもかかわらず認証されていない ssh セッションが多すぎるために、移行接続が切断する場合があります。デフォルトでは、sshd で許可されるセッションは 10 セッションのみで、常に "pre-authenticated state" となります。この設定は、sshd 設定ファイル (ここでは /etc/ssh/sshd_config) の MaxStartups パラメーターで制御されます。これには調整が必要な場合があります。この制限は DoS 攻撃 (および一般的なリソースの過剰使用) を防ぐために設定されているため、このパラメーターの調整は慎重に行ってください。この値を高く設定しすぎると、目的が無効になります。このパラメーターを変更するには、ファイル/etc/ssh/sshd_configを変更し、MaxStartups 行の先頭から#を削除して、10 (デフォルト値) をより大きな数値に変更します。必ず保存して、sshd サービスを再起動してください。詳細は、sshd_config の man ページを参照してください。