5.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.comguest1-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.comguest1-rhel6-64 が実行中であることを確認します。
    [root@host2 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 guest1-rhel6-64     running
これでライブマイグレーションが完了しました。

注記

libvirt では、TLS/SSL、UNIX ソケット、SSH、および暗号化されていない TCP などの各種のネットワーク方式に対応しています。他の方式を利用する方法についての詳細は、6章ゲストのリモート管理 を参照してください。

注記

稼働していないゲスト仮想マシンの移行は virsh migrate では行えません。稼働していないゲスト仮想マシンを移行するには、次のスクリプトを使用してください。
virsh dumpxml Guest1 > Guest1.xml
virsh -c qemu+ssh://<target-system-FQDN>  define Guest1.xml
virsh undefine Guest1

5.4.1. virsh を使用した移行に関するヒント

複数の移行を別々のコマンドシェルで実行する同時ライブマイグレーションが可能です。ただし、それぞれの移行インスタンスは (ソースと移行先) それぞれの MAX_CLIENT 値を使用するため、この移行は慎重に計算した上で行なわなければなりません。デフォルトの設定値は 20 なので、10 インスタンスまでは設定を変更せずに行なうことができます。設定値を変更する必要がある場合は、手順5.1「libvirtd.conf の設定」の手順を参照してください。
  1. 手順5.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_clientsmax_workers のパラメーター設定値を変更します。この 2 つのパラメーターの数字を同一にしておくことを推奨しています。max_clients は移行ごとに 2 つのクライアントを使用し (ソース側と移行先に 1 つずつ)、max_workers は実行フェーズではソース側で 1 worker、移行先で 0 worker を使用し、終了フェーズでは移行先で 1 worker を使用します。

    重要

    max_clientsmax_workers のパラメーター設定値は、全ゲスト仮想マシンの libvirtd サービスへの接続により生じます。つまり、同じゲスト仮想マシンを使用し、同時に移行を行なっているユーザーはすべて max_clientsmax_workers パラメーターに設定された制限値に影響を受けます。このため、同時ライブマイグレーションを行なう際は、まず最大値を注意深く検討する必要があります。
  4. ファイルを保存してサービスを再起動します。

    注記

    移行中に接続が中断される場合がありますが、これは開始後に認証が行なわれていない SSH セッションが多すぎる場合に発生します。デフォルトでは、sshd で認証前の状態が許可されるのは 10 セッションのみです。この設定は sshd 設定ファイル (/etc/ssh/sshd_config) 内の MaxStartups パラメーターで制御されています。このパラメーターは調整する必要がある場合があります。DoS 攻撃 (リソースの過剰な消費) などを防ぐ目的でこの制限が設けられているため、このパラメーターを調整する際は注意が必要です。この値を高く設定しすぎると、当初の目的が意味がなくなってしまいます。パラメーターを変更する場合は、/etc/ssh/sshd_config を編集して MaxStartups 行の先頭にある # を削除し、 10 (デフォルト値) の値をさらに大きな数値に変更します。ファイルを保存して sshd サービスを再起動するのを忘れないようにしてください。詳細は、sshd_config の man ページを参照してください。