FreeBSD 15.1 で実現した bhyve ゲストのライブマイグレーション（稼働中移行）

本プロジェクトは、FreeBSD 15.1において bhyve のゲストを起動したままホスト間で移動させるライブマイグレーション実装を発表します。TCP を介して動作中の

amd64

ゲストを 2 つのホスト間で転送でき、移行中はサービスを維持し、最終的な「停止コピーフェーズ」のみで一時停止します。

この機能は bhyve の実験的スナップショット機能の上に構築されており、以下の技術的改修がなされています。

• vmm カーネルモジュール：ダーティページ（汚染済みページ）の追跡機能を実装
• bhyve および bhyvectl：移行プロトコルの導入

---

開発の背景と目的

以前の記事「FreeBSD と bhyve：VM のライブマイグレーションへの道はどれか？」にて、現状・歴史的経緯・制約および重要性について議論しました。

• 実践的な目標：抽象論ではなく、実際に実装してテストし改善すること
• 現状の公開形態：より詳細な実演（YouTube）と共に、次のステップを明確にするためのWIP RFC（作業中提案書）として公開されています。

---

なぜライブマイグレーションが必要なのか

エンタープライズ仮想化において重要な機能であり、以下の運用シーンでワークロードへの影響を軽減します。

• ホストの保守
• ハードウェア置換
• 負荷分散
• 故障ドメイン管理

シーン別での重要性

• Sylve プロジェクト：FreeBSD 向けのプロクソモックス（Proxmox）代替ソリューションにおいて、クラスタ化運用を実現するための必須機能。
• BoxyBSD プロジェクト：無料の BSD ベース VPS を提供する個人プロジェクトにおいて、ホスト作業時にゲストをダウンタイムさせるのを防ぐための信頼性の高い移行経路。

---

実装仕組み

プリコピーフェーズ（ソース側）

1. まず、書き込まれたゲストメモリを送信。
2. 次に、前回のスキャン以降に変更されたページ（ダーティページ）のビットマップを取得し、その部分のみ送信を繰り返す。
3. ダーティセットがダウンタイム目標に適合するか、収縮が停止するか、ラウンド数に到達するまで繰り返す。
4. 条件を満たした時点で bhyve はゲストとデバイスを一時停止。
5. 最終的なダーティページ、vCPU、カーネル状態、エミュレーションデバイスに対するスナップショットを送信。

復元フェーズ（宛先側）

1. VM の基本ジオメトリを検証。
2. メモリと状態を受信し復元。
3. 準備完了を報告。
4. ソース側から 「GO」（コミット点）メッセージを受信待ち。

注意点：GO 受信前に失敗した場合、ソースゲストの再開が可能ですが、宛先側はこのメッセージを受信しない限りゲストを起動しません。また、フォールバック手段としてウォーム停止コピーモードも用意されています。

---

現在の機能実装状況

• プリコピーとウォームマイグレーション
  • ダウントタイムと最大ラウンド数の制御が可能。
  • 明示的な停止コピーマイグレーションもサポート。
• マルチ-vCPU プロトコルサポート
  • 移行ハンドシェイクにゲスト vCPU 数が含まれる。
  • 宛先側は不一致数を拒否し、移行中すべての vCPU を一時停止・再開する。
  • ※現在はシングル vCPU ゲストの検証のみ実施済み。マルチ vCPU に対するストレステストとレース条件テストが不足しています。
• メモリエンティビティチェック
  • ゲストおよびマッピングされたエミュレーションライスのダーティ状態を追跡（vmm ライトホールドは別途記録）。
  • テストワークロードではメモリの書き換え/検証を行い、不一致ページを報告。
  • 連続したピンポン（ping-pong）マイグレーションでもエラーなしに継続できることを確認。
• ディスクライティバリデーション
  • ファイルの繰り返し書き込みおよび

    fsync

    、チェックサム検証を実行。
  • コールドリブート後に再検証し、デバイス一時停止・ドレイン・復元パスを演習。
• 障害処理
  • 宛先拒否、到達不能なターゲット、通信途絶などのケースでのテスト済み。
  • コミット前の失敗時は、一時停止したゲストの再開が可能。
• 基本的な宛先チェック
  • データ転送前にプロトコルバージョン、ページサイズ、メモリアレイメント、vCPU 数をチェック。
  • 移行ソケットは

    bhyvectl

    で開かれ、Capsicum サンドボックス内で安全に運用。
• サポート範囲
  • amd64 専用。
  • 実験的な

    BHYVE_SNAPSHOT

    サポートに依存（スナップショット対応デバイス必須）。
  • PCI パススルーは現在未対応。

---

観測結果

現在の二ホストテスト環境における検証結果です。

• 成功ケース：繰り返しライブマイグレーション、メモリライト、fsync 主体のディスクワークロードで完了。
• パフォーマンス数値：512 MiB ゲスト（ゆっくりダーティ化）の場合、ダウンタイムは138～171 msを記録。
• フォールバック動作：急速にダーティ化するゲストはプリコピーフェーズで収束しない場合もありますが、正しい停止コピー完了へ正常にフォールバックします。

※ これらは有望なエンジニアリング結果ですが、プロダクション環境でのサポート保証または完全な妥当性の証明ではありません。

---

上流統合前に解決すべき課題

以下の事項はプロトタイプの価値への批判ではなく、中立なエンジニアリング要件です。上流統合に向けてこれらに対処する必要があります。

• ダーティログの正当性強化
  • カーネル側のアルゴリズムにおいて、ダーティビット検証/クリア中に書き込みが失われないことを実証する必要がある。
  • 集中的な並行性、ペービング（ページング）、エミュレーションライティング、マルチ vCPU ストレスカバレッジ、レビュー可能なロックとメモリ順序付けの論理が必要。
• 完全な互換性契約の定義
  • メモリサイズ・vCPU 数の一致だけでは不十分。
  • 宛先側がゲストアイデンティティ、CPU 能力、bhyve/vmm およびスナップショット形式互換性、デバイストポロジー/能力、共有ストレージアイデンティティを検証してマイグレーションを受入れる仕組みが必要。
• トランスポートとプロトコルの強化
  • 現在：TCP で認証・暗号化なし、第 1 版ネイティブプロトコル。
  • 必要：明示的なワイヤーフォーマット、バウンデッドメッセージ処理、タイムアウト、バージョン交渉、認証または外部セキュアトランスポートモデル、運用ガイダンス。
• コミットおよびデバイス側影響の境界明確化
  • ソース/宛先ハンドオフをレビューし、コミット前に外部が見る作業を引き起こさないようにする。
  • コミット後の認識損失に備え、不確実な結果を運用上回復可能にする。
• ストレージおよびネットワークハンドオフの指定
  • 共有ストレージへの整合性、耐障害性、フェンシング仮定の定義。
  • ネットワークマイグレーションにおける tap/ブリッジ処理、MAC/IP 移動、トラフィック収束の明確化。
• ツリー内テスト戦略の構築
  • 自動化された回帰カバレッジの確保。
  • CPU 数、メモリサイズ、サポートデバイス、ホスト CPU、障害ケースにわたる文書化されたサポーマトリックスが必要。
• パッチの分離
  • ダーティページ追跡、スナップショット API リファクタリング、プロトコル/受信機作業、CLI 変更、テストを独立したレビュー可能パッチに分離。
  • これにより設計フィードバックを容易にし、結合変更による統合リスクを低減。

---

次のステップとアクセス先

Sylve Discord での議論を受けて、現状を実質化し広範なフィードバックを取り込みます。現在の焦点は性能向上ではなく、正当性・互換性検証・トランスポート安全性・再現可能なテストです。

一部の人々がすでにアクセス権を持っており、以下のリポジトリで提案として公開する予定です。

git.gyptazy.com/gyptazy/freebsd-bhyve-live-migration
github.com/gyptazy/freebsd-bhyve-live-migration

今後追加される予定の機能：

• 圧縮機能
• ゼロページ省略
• より広範なデバイスカバレッジ
• リッチなオーケストレーション
• パフォーマンスチューニング

bhyve を運用中の方、FreeBSD 仮想化に取り組んでおられる方、Sylve や BoxyBSD に興味をお持ちの方は、この RFC をテストし、設計フィードバックを提供することを推奨します。

ステータス

WIP RFC：FreeBSD 15.1 における最初の稼働可能な bhyve ライブマイグレーション実装に関する提案です。