SeamlessMigrate
新機能GPU ワークロードとネットワークカットオーバー:0.4.0-rc.1 のテクノロジープレビュー

オープンソースの VM 移行:VMware・OpenStack から RHOSO 18.0 またはコミュニティ版 OpenStack へ。 VM は稼働したまま。
カットオーバーは数分で。

Seamless Migrate は、RHOSP 17.1、OpenStack、VMware vSphere の VM を RHOSO 18.0 またはコミュニティ版 OpenStack へ移行します。 VM がサービスを提供している間にディスクをコピーし、VM を停止するのは最終差分の転送時だけです。

Apache 2.0 デモにクラウドの認証情報は不要

ダウンタイム

1台の VM、3つの移行方式。

200 GiB のボリューム(使用量 120 GiB)、ゲストの書き込み 2 MiB/s、125 MiB/s の回線の場合、コントロールプレーンの計画モデルは各方式のダウンタイムを次のように見積もります。

  • コールドコピー cold

    20分53秒 ダウンタイム

    使用済み領域のコピーが終わるまで、VM は停止したままです。

  • ウォーム移行 warm

    11分20秒 ダウンタイム

    VM がサービスを提供している間に3回のコピーを実行し(31分32秒)、VM を停止するのは最終差分の転送時だけです。

  • ストレージハンドオーバー storage_handover

    4分20秒 ダウンタイム

    データはコピーしません。共有の Ceph または NetApp ONTAP 上で、Cinder が各ボリュームを移行先に引き渡します。

プラットフォーム

移行元はさまざま。移行先はあなたが選ぶ。

計画、ウェーブ、承認のモデルは、すべての移行元で共通です。Seamless は各クラウドの公開 API を介して通信し、データの移動には内部で os-migrate Ansible コレクションを使用します。

  • Red Hat OpenStack Platform 17.1

    TripleO ベースの最後のリリースです。インプレース移管が適さない場合は、新旧環境を並行させて移行します。

    • cold
    • warm
    • storage_handover
  • コミュニティ版 OpenStack と Kolla-Ansible

    Keystone v3、Nova 2.60 以降、Cinder v3、Neutron v2 を備えた任意のリリースに対応します。

    • cold
    • warm
    • storage_handover
  • VMware vSphere 7.0U3 と 8.x

    vCenter で管理される環境です。Changed Block Tracking でウォーム移行し、virt-v2v で変換します。

    • vmware_cold
    • vmware_warm

移行先

  • RHOSO 18.0

    Red Hat OpenStack Services on OpenShift。移行先のプラットフォームです。リリースのラボ検証は未実施です。Seamless は OpenStack の公開 API を使用し、OpenShift のリソースには一切触れません。

  • コミュニティ版 OpenStack

    2023.1 Antelope から 2026.2 Hibiscus までのすべてのリリースシリーズに対応します。Kolla-Ansible、OpenStack-Ansible、その他どのツールでデプロイされていても、同じコードパスで移行します。プロバイダーチェックが、そのシリーズ、サポートティア、ポリシープロファイルを報告します。

  • ネットワーク、サブネット、ルーター、セキュリティグループを再作成
  • フレーバー、イメージ、キーペア、プロジェクト、ユーザーを引き継ぎ
  • 移行先のネットワーク(ML2/OVN の Geneve を含む)に照らして MTU を確認
  • 全エンドポイントの TLS をデフォルトで検証

主要なゲスト OS すべてに対応

OpenStack からの移行では KVM ゲストを KVM へ移すため、RHEL、CentOS、Rocky、AlmaLinux、Oracle Linux、Ubuntu、Debian、SLES、Windows など、移行元で起動するゲストは移行先でも起動します。VMware からの移行では、RHEL 9 の変換ホスト上で virt-v2v がゲストを変換します。古いリリースを黙ってブロックすることはなく、対処方法を添えて警告します。

移行方式

5つの移行方式から、VM ごとに1つを選択。

Seamless は、VM ごとに適用可能なすべての方式を見積もり、ダウンタイムが最も短い方式を選びます。同等の場合は、よりシンプルな方式を優先します。この選択は上書きできます。

OpenStack から

  • cold

    コールドコピー

    停止し、使用済み領域を SSH でコピーして、移行先で起動します。

  • warm

    ウォーム

    VM の稼働中にスナップショットでコピーを繰り返し、停止後は最終差分だけを転送します。

  • storage_handover

    ストレージハンドオーバー

    移行元で Cinder がボリュームを unmanage し、移行先で manage します。データはコピーしません。

    要件: 両クラウドが同じ Ceph クラスターまたは NetApp ONTAP SVM を使用していること。

VMware から

  • vmware_cold

    VMware コールド

    フルコピーの後、virt-v2v で変換します。

  • vmware_warm

    VMware ウォーム

    Changed Block Tracking でコピーを繰り返し、最終差分を転送してからインプレース変換します。

    要件: VM で Changed Block Tracking が有効になっていること。

テクノロジープレビュー

GPU 搭載 VM も移行。アドレスも引き継げる。

リリース候補であり、本番環境の認証ではありません。リリースのラボ試験はまだ記録されていません。 0.4.0-rc.1 の新機能。どちらもプランごとのオプトインで、シミュレーションで検証済みです。デモで動作しますが、GPU ホストや実際のクラウドでのラボテストはまだ実施していません。テストに合格した時点でこのラベルを外します。

  • GPU ワークロード

    テクノロジープレビュー(シミュレーションで検証済み)

    NVIDIA vGPU(タイムスライス方式または MIG ベース)を持つ VM や、GPU を丸ごとパススルーした VM も、ブロックされずに移行できるようになりました。ディスクは通常の VM と同じように移動します。GPU の状態は移動せず、VM は移行先でシャットダウン後と同じように起動します。

    • GPU は OpenStack のフレーバーまたは vCenter から読み取り、インベントリに表示
    • 各 GPU はプランで移行先の GPU フレーバーにマッピング。サイズや名前で自動照合することはなく、マッピングのない GPU VM はブロックされたまま
    • 空き容量は検証時と、移行元を停止する直前に Placement から再度読み取り。プールが満杯のあいだ、移行元は稼働を続ける
    • 検証で GPU フレーバーと Placement の割り当てを確認。ゲストに必要なドライバーとライセンスサーバーは検出結果で通知
  • ネットワークカットオーバー

    テクノロジープレビュー(シミュレーションで検証済み)

    移行に VM のネットワーク上の識別情報を引き継げます。各機能はプランごとのオプトインで、使わないプランはこれまでどおりに移行します。

    • フック:管理者が登録する Ansible Playbook と HTTPS Webhook を pre_stop、post_create、post_verify、on_rollback、on_finalize で実行。それぞれにタイムアウトと任意の取り消し処理
    • すべての OpenStack 移行方式で Floating IP のアドレスを維持。移行元の停止後に移し、ロールバック時は元に戻す
    • Designate または RFC 2136 サーバーで DNS レコードを compare-and-swap で切り替え、ロールバック時は元に戻す
    • 到達確認の待ち時間をダウンタイムに計上。Octavia ヘルパーが移行元メンバーをドレインし、移行後の VM をプールに参加させる

Heat スタックとオートスケーリンググループ、ウェーブで分断される Octavia プール、アドレスペアを持つポート、移行先で公開できない DNS 名など、運用者に残る作業は事前検証が指摘し、ランブックで手順を示します。

次期リリース:0.5.0

予定:メール、Slack、署名付き Webhook による通知。データパスでの SSH ホスト鍵のピン留め。さらにテクノロジープレビューとして、高可用性コントロールプレーン、テナントごとの認証情報、Ceph RBD ボリュームのウォーム移行で最終パスからディスクスキャンをなくす変更エクステント追跡。

0.4.0-rc.1 のリリースノート (新しいタブで開きます)

仕組み

ひとつの流れ。すべての工程を、自分たちの手で。

どの移行元でもワークフローは同じです。各移行は明示的なステートマシンに沿って進み、コントロールプレーンが再起動してもチェックポイントから再開し、すべての操作について監査証跡を残します。

  1. 01

    両方のクラウドを接続

    RHOSP 17.1、コミュニティ版 OpenStack、Kolla-Ansible、vCenter のいずれかを移行元として、RHOSO 18.0 またはコミュニティ版 OpenStack クラウドを移行先として追加します。プラットフォームごとにプリセットがあります。認証情報は書き込み専用です。保存先はプラットフォームのシークレットストアで、データベースや API レスポンスに含まれることはありません。各接続と、その接続で利用できる機能をワンクリックで確認でき、移行先のリリースシリーズ、サポートティア、ポリシープロファイルも報告されます。

  2. 02

    パイロットから始めるウェーブ計画

    ディスク、NIC、ゲスト OS、移行準備状況のフラグを含むインベントリを検出します。VM を選択し、ネットワーク、フレーバー、ボリュームタイプ、プロジェクトをマッピングすると、プランナーが小規模なパイロットを最初に置き、リスクに応じてウェーブの順序を決めます。各ウェーブは、前のウェーブが完了してから開始します。

  3. 03

    移行を始める前に検証

    事前チェックが、ブロッカー・警告・情報を、それぞれの対処方法とともに報告します。各 VM には、適用可能な方式ごとの見積もりと、上書き可能な自動選択が示されます。

  4. 04

    VM を稼働させたままコピー

    ウォーム移行の VM は、サービスを提供したまま、スナップショットを使って繰り返しコピーされます。2回目以降は BLAKE2b ダイジェストが変化したチャンクだけを転送し、各回のコピーはマニフェストのダイジェストを検証して完了します。差分が収束した VM は、keep-warm 同期で最新の状態を保ちながら変更ウィンドウを待ちます。

  5. 05

    変更ウィンドウ内でカットオーバー

    カットオーバーを開始できるのは、別の承認者による承認があり、変更ウィンドウ内で、カットオーバー枠に空きがある場合だけです。VM を停止し、最終差分を同期して、移行先で起動します。ダウンタイムは、停止した時点から起動を検証した時点までを計測します。

  6. 06

    検証してから確定

    Seamless は、サーバーが ACTIVE であること、ポート、TCP プローブ、コンソールのパターンを確認します。チェックに失敗すると自動でロールバックし、移行先のインスタンスを削除してボリュームは保持し、移行元 VM を再び起動します。唯一取り消せない手順である確定には、承認者が必要で、VM 名を省略せずに入力しなければなりません。

ダッシュボード

すべての移行を、ひと目で。

ダッシュボードはコントロールプレーンに同梱されています。プランとウェーブ、SLO に対する各ダウンタイムの時計、承認、監査証跡を、server-sent events でライブに更新します。以下は、シミュレーションされたクラウドを使うデモで撮影した実際の画面です。

seamless.internal/

原寸で開く (新しいタブで開きます)
Overview ページ:KPI タイル、15 分の SLO に対するダウンタイム時計付きの停止中 VM 3 台、保留中の承認 4 件。

ロールアウト全体をひと目で

状態別の移行数、平均ダウンタイムと SLO 準拠率、いま停止中のすべての VM とその時計、そして人の判断を待つ承認(カットオーバー承認とアドバイザーの判断)。各項目は、判断を行う画面にリンクしています。

ポーリングではなく、ライブ
フェーズ変更、パス、承認、イベントは server-sent events で届きます。接続が切れても、ダッシュボードは最後に受け取ったイベントから再開します。
「できません」で終わらせない
viewer から admin まで 4 つのロール。いま実行できない操作も画面に残り、何を待っているのか(ロール、承認、変更ウィンドウ、フェーズ)を示します。
WCAG 2.2 AA
キーボード優先、進捗と結果をスクリーンリーダーに通知、44 px のターゲット、reduced motion を尊重、色だけで状態を伝えることはありません。
他のホストから何も読み込まない
フォントとスクリプトはコントロールプレーンに同梱され、サードパーティからは何も読み込みません。エアギャップ環境でも同じ表示になります。

安全性

確定するまで、元に戻せる

承認、変更ウィンドウ、ロールバックは、運用手順書上の取り決めではなく、コントロールプレーンのルールです。承認者が確定するまで、移行元 VM はそのまま残ります。

コントロールプレーンが強制するゲート
カットオーバーは、承認、変更ウィンドウ、カットオーバー枠の空きがすべて揃ったときにのみ開始します。
申請者と承認者の分離
カットオーバーを要求または強制実行した本人は、承認できません。別の承認者による承認が必要です。
確定まではロールバック可能
ロールバックでは、移行先のインスタンスを削除し、ボリュームは保持したまま、カットオーバーで移した Floating IP のアドレスや DNS レコードを戻して、移行元 VM を再び起動します。検証に失敗した場合は自動で実行されます。
取り消せない手順は、入力で確認
確定前に移行元のデータが削除されることはありません。確定には承認者が必要で、VM 名を省略せずに入力しなければなりません。
再起動後に再開
コントロールプレーンが復帰すると、実行中だった移行はチェックポイントから再開します。計画停止では、先にドレインすることもできます。プランを一時停止し、進行中のカットオーバーが完了するまでは何も停止しません。
移行元を止めたまま放置しない
各ステップには実時間の上限があるため、プレイブックがハングしても、停止中の VM がそのまま放置されることはありません。
すべての操作を記録
変更を伴う呼び出しはすべて監査されます。監査証跡はエクスポートでき、保持スケジュールに沿って削除することもできます。

デプロイ

お使いのインフラに、自然になじむ。

構成はコンテナイメージ1つと PostgreSQL です。RHOSO と並べて OpenShift クラスターに、任意の Kubernetes に、または単一ホスト(Linux サーバー自身の Docker Engine、Mac 上の Colima、あるいは Podman)にデプロイできます。

  • Linux

    Docker Engine 20.10 以降と Compose v2.20 以降:Ubuntu、Debian、RHEL、Rocky Linux、AlmaLinux、Fedora

    $ scripts/compose-init.sh$ make seamless-up$ curl -fsS http://127.0.0.1:8080/api/v1/health$ ssh -L 8080:127.0.0.1:8080 you@your-server

    サーバー自身の Docker Engine で動作し、Colima も Node.js も不要です。ダッシュボードはイメージのビルド時に生成されます。コントロールプレーンは 127.0.0.1:8080 でのみ待ち受けるため、ファイアウォールのポートを開ける必要はなく、ダッシュボードには SSH トンネル経由でアクセスします。コンテナは再起動後に自動で復帰し、SELinux は enforcing のままで構いません。

  • macOS

    Colima、または名前付きコンテキストを指定した Docker Desktop

    $ make seamless-colima-up$ scripts/compose-init.sh$ make seamless-up$ make seamless-logs

    専用の Colima プロファイル(4 CPU、6 GiB、40 GiB)で動作し、使用中の Docker コンテキストは変更しません。Docker Desktop やその他のコンテキストを使う場合は、make の実行ごとに SEAMLESS_DOCKER_CONTEXT=desktop-linux を指定してください。

  • Podman

    4.7 以降

    $ scripts/compose-init.sh$ make seamless-up SEAMLESS_ENGINE=podman$ make seamless-logs SEAMLESS_ENGINE=podman

    podman compose で同じスタックを動かします。docker-compose がインストールされている場合は、それをプロバイダーとして使用します。SELinux ホストでは、トークンのマウントが自動で再ラベル付けされます。

  • Kubernetes

    1.28 以降:EKS、AKS、GKE、RKE2、k3s、kubeadm

    $ kubectl apply -k deploy/kubernetes$ kubectl -n seamless-migrate rollout status deploy/seamless$ kubectl -n seamless-migrate get ingress seamless

    OpenShift マニフェストに Ingress を加えた Kustomize オーバーレイです。事前に secret-example.yaml から Secrets を作成し、TLS シークレット seamless-tls も作成してください。

  • OpenShift

    4.16 以降

    $ oc apply -k deploy/openshift$ oc -n seamless-migrate rollout status deploy/seamless$ oc -n seamless-migrate get route seamless

    PostgreSQL 16、ハードニング済みの単一レプリカ Deployment、edge-TLS の Route、デフォルト拒否の NetworkPolicies。Secrets は kustomization に含めません。

よくある質問

疑問にお答えします。

チームが最初の VM を移行する前に尋ねる質問です。

Seamless Migrate とは何ですか?

Seamless Migrate は、Red Hat OpenStack Platform 17.1、コミュニティ版 OpenStack(Kolla-Ansible を含む)、VMware vSphere から Red Hat OpenStack Services on OpenShift(RHOSO)18.0、またはコミュニティ版 OpenStack クラウド(2023.1 Antelope から 2026.2 Hibiscus まで)へ仮想マシンを移行する、Apache License 2.0 で公開されているオープンソースのコントロールプレーンです。ウェーブを計画し、各 VM のダウンタイムを見積もり、VM を稼働させたままディスクをコピーします。各カットオーバーは承認と変更ウィンドウを条件に実行し、移行先のすべての VM を検証して、チェックに失敗した場合は自動でロールバックします。

VMware vSphere から OpenStack へ VM を移行するにはどうすればよいですか?

vCenter(vSphere 7.0U3 または 8.x)を移行元、RHOSO 18.0 またはコミュニティ版 OpenStack クラウドを移行先として追加し、ウェーブを計画して検証します。Changed Block Tracking(CBT、変更ブロック追跡)が有効な VM はウォーム移行になります。VM の稼働中に CBT を使ってディスクのコピーを繰り返し、カットオーバー時には最終差分だけを転送してから、virt-v2v でインプレース変換します。CBT が無効な VM はコールド移行になり、フルコピーの後に変換します。データは、os-migrate の vmware-migration-kit と、移行先クラウド内の VDDK を備えた変換ホストを経由して移動します。

インプレース移管を行わずに、RHOSP 17.1 から RHOSO 18.0 へワークロードを移行できますか?

はい。Red Hat の移管(adoption)手順は、17.1 のデプロイメントをインプレースで変換します。新しいハードウェア、新しいストレージバックエンド、ネットワークの再設計(ML2/OVS から ML2/OVN への切り替えなど)、複数クラウドの統合といった理由でそれが適さない場合は、Seamless Migrate が新旧環境を並行させてワークロードを移行します。RHOSO 上にネットワーク、セキュリティグループ、フレーバー、イメージ、キーペア、プロジェクト、ユーザーを再作成し、各 VM をコールド移行、ウォーム移行、またはストレージハンドオーバーで移行します。

RHOSO ではなく、コミュニティ版 OpenStack クラウドへ移行できますか?

はい。RHOSO 18.0 に加えて、2023.1 Antelope から 2026.2 Hibiscus までのすべてのコミュニティ版 OpenStack リリースシリーズを移行先にできます。Kolla-Ansible、OpenStack-Ansible、その他のどのツールでデプロイされたものでも構いません。OpenStack Community または Kolla-Ansible のプリセットで登録すれば、同じコールド移行、ウォーム移行、ストレージハンドオーバーの方式がそのまま使えます。プロバイダーチェックが各移行先のリリースシリーズ、サポートティア、ポリシープロファイルを報告し、事前検証が、不足している機能があれば移行を始める前にプランをブロックします。RHOSO 18.0 は基準となる移行先ですが、リリースのラボ検証は未実施です。アップストリームで保守されている各コミュニティ版シリーズのラボでの検証はまだ実施しておらず、正式リリースの前に行います。

移行にはどのくらいのダウンタイムが必要ですか?

移行方式と VM によって異なります。200 GiB のボリューム1つ(使用量 120 GiB)、ゲストの書き込み 2 MiB/s、125 MiB/s の回線の場合、計画モデルの見積もりは、コールドコピーが20分53秒、ウォーム移行が11分20秒、ストレージハンドオーバーが4分20秒です。ウォーム移行のダウンタイムは、フルコピーではなく、最終差分とディスクのスキャンによって決まります。

コールド移行、ウォーム移行、ストレージハンドオーバーの違いは何ですか?

コールド移行は VM を停止して使用済み領域をコピーするため、ディスクが大きいほどダウンタイムが長くなります。ウォーム移行は、VM を稼働させたままスナップショットを使ってディスクのコピーを繰り返し、VM を停止するのは最終差分の転送時だけです。ストレージハンドオーバーはデータを一切コピーしません。両クラウドが Ceph クラスターまたは NetApp ONTAP SVM を共有している場合、Cinder が各ボリュームを移行元で unmanage し、移行先で manage するため、ダウンタイムはサイズにかかわらず数分です。

GPU を搭載した VM も移行できますか?

はい。シミュレーションで検証済みのテクノロジープレビューとして対応しています。NVIDIA vGPU(タイムスライス方式または MIG ベース)を持つ VM や GPU を丸ごとパススルーした VM は、プランで各 GPU を移行先の GPU フレーバーにマッピングすれば移行できます。マッピングのない GPU VM はブロックされたままです。検証ではプランが必要とする GPU を Placement 上の移行先の空き容量と照合し、カットオーバーゲートが移行元を停止する前に再度確認します。空きがなければ移行は待機し、移行元は稼働を続けます。GPU をパススルーした VMware の VM は、電源をオフにしたうえでコールド移行のみで移動します。GPU ホストでのラボテストはまだ実施していません。

移行した VM の IP アドレスや DNS 名は維持されますか?

固定 IP と MAC アドレスはデフォルトで維持されます。さらにシミュレーションで検証済みのテクノロジープレビューとして、プランで各 Floating IP のアドレスを維持できます。アドレスは移行元の停止後に移し、ロールバック時には元に戻します。アドレスが変わる場合は、Designate または RFC 2136 サーバーの DNS レコードを切り替えられます。検証は移したアドレスがすべて応答するまで待ち、その待ち時間をダウンタイムに計上します。Seamless 自体は BGP を話しません。それ以外は、管理者が登録するフック(Ansible Playbook または HTTPS Webhook)で対応でき、Heat スタック、オートスケーリンググループ、Octavia プールなど運用者に残る作業は事前検証が指摘します。

移行はロールバックできますか?

はい、確定するまでは可能です。ロールバックでは移行先のインスタンスを削除し、ボリュームは保持したまま、移行元 VM を再び起動します。検証に失敗した場合は自動で実行されます。確定前に移行元のデータが削除されることはなく、確定には承認者が必要で、VM 名を省略せずに入力しなければなりません。

どのゲスト OS を移行できますか?

OpenStack からは KVM ゲストを KVM へ移すため、RHEL 5〜10、CentOS、Rocky、AlmaLinux、Oracle Linux、Ubuntu、Debian、SLES、openSUSE、Windows Server 2003〜2025、Windows 7〜11 など、移行元で起動するゲストは移行先でも起動します。VMware からは virt-v2v がゲストを変換します。RHEL 7〜10 と Windows Server 2016〜2025 は Red Hat のサポート対象です。その他のゲストは、テストコピーで動作を確認してから移行するか、先に virtio ドライバーをインストールする必要があります。

Seamless Migrate はどこで動作しますか?

コンテナイメージ1つと PostgreSQL 16 で構成されます。RHOSO と並べて OpenShift 4.16 以降に、Kubernetes 1.28 以降(EKS、AKS、GKE、RKE2、k3s、kubeadm)に、または単一ホストにデプロイできます。単一ホストの場合は、Linux サーバー自身の Docker Engine 20.10 以降と Compose v2.20(Ubuntu、Debian、RHEL、Rocky Linux、AlmaLinux、Fedora に対応し、Colima も Node.js も不要)、Colima を使う Mac、または Podman 4.7 以降が利用できます。運用スクリプト seamless-ctl.sh 1 本で、デプロイメントの起動、停止、再起動、スケーリングをどのプラットフォームでも同じ方法で行い、計画停止の前には実行中のプランをドレインします。シミュレートしたクラウドを使うデモはノート PC で動作し、クラウドの認証情報は不要です。

Seamless Migrate は無料ですか?

はい。Apache License 2.0 のオープンソースで、ソースコードは GitHub で公開されています。

Seamless Migrate は Red Hat の製品ですか?

いいえ。独立したオープンソースプロジェクトであり、Red Hat、OpenInfra Foundation、Broadcom のいずれとも提携しておらず、後援や推奨も受けていません。また、Red Hat のいかなるサブスクリプションの対象でもありません。アップストリームの os-migrate Ansible コレクションを基盤としており、データの移動は引き続き os-migrate が担います。

Seamless Migrate と os-migrate の違いは何ですか?

os-migrate は、テナントリソースのエクスポートとインポートを行い、ワークロードをコールドでコピーします。コピーの間、VM は停止したままです。Seamless Migrate は os-migrate を基盤として、OpenStack を移行元とするウォーム移行、ストレージハンドオーバー、VMware のウォーム移行のオーケストレーション、そして計画、ウェーブ、ダウンタイム見積もり、承認、検証、ロールバック、ダッシュボード、REST API、CLI を備えたコントロールプレーンを追加します。

はじめかた

大きな可能性。
まずは小さなパイロットから。

デモでは、事前コピーからカットオーバー、検証、ロールバックまで、すべてのフェーズをノート PC 上のシミュレートしたクラウドで実行します。試すのに OpenStack は不要です。

Linux サーバー上の Docker、または Mac 上の Colima

$ git clone https://github.com/imransetiadi/seamless-vms-migration$ cd seamless-vms-migration# macOS のみ:Linux では不要$ make seamless-colima-up$ scripts/compose-init.sh# シミュレートしたクラウドで全フェーズを実行$ make seamless-demo

ローカルデモを試す (新しいタブで開きます)compose-init.sh が出力した管理者トークンで、/login からログインします。Podman でも動作します: SEAMLESS_ENGINE=podman。