KVMライブマイグレーション本番設計｜共有ストレージなし構成での帯域制御と中断時の仮想機復旧

物理ホスト間で仮想機を無停止で移動させるライブマイグレーションは、KVM環境の保守・負荷分散に不可欠な機能です。NFS・Ceph・iSCSIなどの共有ストレージを前提とした構成がよく紹介されますが、コストや既存ネットワーク構成の制約から、ローカルストレージだけを持つホスト間でのマイグレーションが必要になる場面もあります。この場合、ディスクイメージ自体もネットワーク越しに転送する「ブロックマイグレーション」を使います。メモリだけを転送する通常のライブマイグレーションと比べて転送データ量が増えるため、帯域制御の設計と中断時の復旧手順をあらかじめ固めておくことが本番運用の前提となります。

ブロックマイグレーションの仕組みと前提条件

通常のKVMライブマイグレーションは、ディスクイメージを共有ストレージ上に置いた状態でメモリ状態だけを移送します。ブロックマイグレーションはこれとは異なり、ディスクイメージの実体もネットワーク越しに転送先ホストへコピーします。libvirtでは virsh migrate の --copy-storage-all または --copy-storage-inc フラグで有効化されます。

--copy-storage-all はディスクイメージ全体を転送先にコピーします。--copy-storage-inc は、転送元と転送先で一部のストレージが共有されている場合（たとえばベースイメージはNFSだがデルタはローカルのqcow2など）に差分のみを転送するオプションです。ローカルストレージのみの構成では --copy-storage-all を使うことになります。

実行前に確認すべき前提条件は以下のとおりです。

• 転送元・転送先の両ホストにlibvirt（libvirtdまたはvirtqemud）とQEMUがインストールされ、サービスが起動していること
• 転送先ホストのlibvirtに接続するためのSSH鍵認証が通っていること（qemu+ssh:// トランスポート利用時）
• 転送先ホストに同名のストレージプールが定義されており、仮想ディスクの論理サイズ以上の空き容量があること
• 仮想機のディスクがrawまたはqcow2形式であること
• QEMU 4.0以降・libvirt 5.0以降であること（2026年現行のRocky Linux 9・Ubuntu 24.04では標準パッケージで満たされる）

マイグレーションの通信経路はデフォルトでQEMUのマイグレーションポート（TCP 49152〜49215番）を使います。ファイアウォールが存在する場合はこの範囲を許可しておく必要があります。

virsh migrateコマンドの構成とpre-copy/post-copyの選択

基本的なブロックマイグレーションのコマンド構成は次のとおりです。

# 転送元ホストで実行
virsh migrate --live \
  --copy-storage-all \
  --persistent \
  vm-name \
  qemu+ssh://dest-host/system

--live は実行中の仮想機を対象にすることを指定します。--persistent は転送先にもドメインの永続定義を作成するオプションで、転送後に転送先で仮想機を再起動できるようにするために付けておくのが一般的です。

マイグレーションの方式には「pre-copy」と「post-copy」の2種類があります。

pre-copy（デフォルト）は、仮想機を転送元で動作させながらメモリページを繰り返し転送先へコピーし、ダーティページが閾値を下回った時点で短時間の停止（ダウンタイム）を挟んで最終同期・切り替えを行います。転送中の仮想機は転送元で動作し続けるため、マイグレーションに失敗しても転送元の仮想機はそのまま動作します。

post-copy（--postcopy フラグ）は、先に仮想機の実行権を転送先へ渡し、不足しているメモリページを転送元から都度フェッチしながら転送先で仮想機を動かし続けます。切り替え後のダウンタイムは極めて短くなりますが、切り替え後にネットワーク障害が起きると転送先の仮想機がクラッシュします。本番でpost-copyを使う場合は、このリスクを設計に織り込む必要があります。

ブロックマイグレーション（ディスク転送を伴う）の場合、ディスクコピーにかかる時間がメモリ転送よりも支配的になることが多いため、pre-copyが終わらず長時間の「収束しないマイグレーション」になるケースに注意が必要です。帯域制御はこの問題に直接関係します。

帯域制御の実装：migrate-setspeedとダウンタイム調整

帯域制御を行わずにブロックマイグレーションを実行すると、ディスク転送が本番トラフィックのネットワーク帯域を圧迫します。転送速度の上限はマイグレーション開始前または実行中に動的に設定できます。

転送速度の上限を設定するには virsh migrate-setspeed を使います。単位はMiB/sです。

# 上限を 200 MiB/s に設定（マイグレーション実行中でも変更可）
virsh migrate-setspeed vm-name 200

# 現在の設定を確認
virsh migrate-getspeed vm-name

0を指定すると制限なし（無制限）になります。業務時間帯は低速・メンテナンスウィンドウは高速という使い分けをスクリプト化しておくと、本番ネットワークへの影響を抑えながら転送を完了させやすくなります。

もうひとつ調整が必要なのが、最終同期時の最大許容ダウンタイムです。デフォルト値は環境によって異なりますが、一般に数百ミリ秒に設定されています。ダーティページレートが高い仮想機（メモリ書き込みの多いDBなど）では、この値を大きくしないとマイグレーションが収束しません。

# 最大ダウンタイムを 500 ミリ秒に設定
virsh migrate-setmaxdowntime vm-name 500

マイグレーションの進捗は virsh domjobinfo でリアルタイムに確認できます。出力には「Memory processed」「Memory remaining」「Disk processed」「Disk remaining」などの項目が含まれ、転送の進み具合を把握できます。

virsh domjobinfo vm-name

「Disk remaining」が長時間変化しない場合や、「Memory iteration」のカウントが増え続けている場合は、帯域不足またはダーティページレートが収束できていない状態のサインです。この場合、migrate-setspeed の値を上げるか、migrate-setmaxdowntime を緩める方向で調整します。

マイグレーション中断時の状態確認と仮想機復旧手順

マイグレーションはネットワーク瞬断・転送先ホストのリソース不足・タイムアウト・手動キャンセルなどで中断されます。中断時の対応は、どのフェーズで中断したかによって異なります。

pre-copyフェーズ（メモリ・ディスクの転送中）での中断

pre-copyの段階では仮想機の実行権は転送元にあります。マイグレーションが中断・失敗しても、転送元の仮想機はそのまま動作し続けます。virsh domstate vm-name を転送元で実行し「running」であることを確認してください。転送先に中途半端なディスクイメージが残っている場合は手動で削除します。

手動でマイグレーションをキャンセルするには virsh migrate-cancel を使います。

# 転送元ホストで実行
virsh migrate-cancel vm-name

切り替え（switchover）フェーズでの中断

最終同期・切り替えのタイミングで中断が起きた場合は、転送元・転送先の両方で virsh domstate を実行して状態を確認します。

# 転送元・転送先の両方で実行して状態を確認
virsh domstate vm-name

まれに両ホストで「running」と表示されるケースがあります。これはlibvirtの状態情報が実際のQEMUプロセスと乖離している場合に発生します。このときは virsh qemu-monitor-command vm-name --hmp info status でQEMUモニターを直接確認するか、プロセスリストでQEMUプロセスの存在を把握します。スプリットブレイン（両系同時起動）が確認された場合は、どちらのデータが新しいかをアプリケーションログで確認してから判断し、古い方を virsh destroy で停止させます。

post-copyフェーズでの中断（post-copy有効時のみ）

post-copyを有効にした場合、切り替え後はメモリを転送元からフェッチしながら転送先で仮想機が動作します。このフェーズでネットワーク障害が起きると転送先の仮想機はクラッシュします。QEMU 8.0以降ではpost-copy recovery機能が追加され、一時的なネットワーク障害から自動回復できるケースも増えましたが、完全な保証ではありません。クラッシュした場合は転送元に残っている仮想機の定義から再起動を試みるか、スナップショットが存在すればそこまでロールバックします。

2026年現行環境での留意点と設計チェックリスト

2026年時点のRocky Linux 9・AlmaLinux 9・Ubuntu 24.04 LTSでは、QEMU 8.x以降・libvirt 9.x〜10.x系が標準またはほぼ標準のパッケージとして利用できます。これらの環境では以下の点に注意が必要です。

libvirtdのsocket activationとデーモン名の変化

libvirt 7.0以降、モノリシックな libvirtd からドライバ別の分割デーモン（virtqemud・virtnetworkd など）への移行が進んでいます。多くのディストリビューションでは virtqemud がsystemdのsocket activationで起動する構成がデフォルトになりつつあります。転送先ホストの接続URI（qemu+ssh://host/system）は変わりませんが、デーモン状態を確認する際は systemctl status virtqemud または systemctl status virtqemud.socket を使う必要がある環境があります。運用ドキュメントのコマンドが古いままだと、接続失敗の原因を見誤ることがあります。

qcow2スパースイメージの転送量最適化

QEMU 8.1以降（libvirt 9.5以降）では、マイグレーション時にゼロブロックの転送を省略する最適化が改善されています。qcow2形式でスパースな領域が多いイメージでは、実際の転送量は論理サイズよりも大幅に少なくなることがあります。virsh domjobinfo の「Disk total」と「Disk processed」を比較することで、実効転送量の見積もりに役立てられます。帯域制御の値を設定する際の目安にもなります。

TLS対応のマイグレーション通信

QEMU 6.0以降・libvirt 7.0以降では --tls フラグを付けることでマイグレーション通信をTLSで暗号化できます。SSH経由（qemu+ssh トランスポート）での接続であればSSHトンネルが通信全体を保護しますが、TCP直結（qemu+tcp）を使う構成ではTLSを明示的に有効化することを検討してください。

本番設計で確認しておくべき項目を以下に整理します。

• 転送先ホストのストレージプールに仮想ディスクの論理サイズに加えてマージン分の空き容量があるか
• マイグレーション用ネットワークを業務NICと分離しているか（専用インターフェースまたはVLAN分離）
• virsh migrate-setspeed の値を業務時間帯・メンテナンスウィンドウで使い分けるスクリプトを用意しているか
• virsh domjobinfo を使った進捗監視の手順を運用ドキュメントに含めているか
• 中断時のロールバック手順（migrate-cancel → 転送先の残骸削除）を事前に検証済みか
• post-copyを使う場合、post-copy中の障害で仮想機がクラッシュするリスクを運用チームが理解しているか
• 転送先でのデーモン状態確認コマンドが最新環境（virtqemudまたはlibvirtd）に合わせてあるか

共有ストレージなしのブロックマイグレーションは、準備と帯域設計を適切に行えば本番環境でも十分に実用できます。中断時の動作フェーズを理解した上で復旧手順を整備しておくことが、安定した運用の基盤となります。