Seamless Migrate

Seamless Migrate

Website · Downtime calculator · Migration tools compared

Move virtual machines from Red Hat OpenStack Platform 17.1, community OpenStack or VMware vSphere into Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 or community OpenStack 2023.1 Antelope – 2026.2 Hibiscus — with minutes of downtime, predictable before it starts, approved by the right people, and reversible until you finalize.

Independent project. Seamless Migrate is not affiliated with, sponsored by, or endorsed by Red Hat, Inc., the Open Infrastructure Foundation (OpenStack), or Broadcom Inc. (VMware). Product names are used only to describe compatibility. See Trademarks and affiliation.

Seamless Migrate 0.1.0 extends the os-migrate Ansible collection (this repository's root, which stays the data mover) with a warm migration path, a control plane with a REST/SSE API and CLI, a dashboard, and optional AI assistance (Jev for bounded judgments, agentmemory for lessons learned). It runs on OpenShift or Kubernetes, or on a single host with Docker Compose: a Linux server's own Docker Engine (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, Fedora; no Colima needed), a Mac with a dedicated Colima profile, or Podman.

What you get

• One workflow for every source: providers, plans, waves (pilot first), pre-flight findings, downtime estimates and an automatic strategy choice per VM (SDD §3, §9).
• Safe by construction: approval and change-window gates, per-VM rollback until finalize, finalize needs an approver and the typed VM name, resumable after a control-plane restart, audit trail for every action (SDD §5, §8, §13).
• Assisted, never autonomous: Jev may break ties between eligible strategies, classify workloads into risk tiers and review post-cutover evidence — always inside deterministic bounds, and everything works with Jev off (SDD §14). agentmemory recalls similar past incidents on failures.
• One dashboard for every hypervisor: add and edit OpenStack Community, Kolla-Ansible, Red Hat OpenStack 17.1, VMware vCenter and RHOSO 18.0 providers from the UI with platform presets, write-only credentials kept in the platform secret store (never in the database) or a named secret managed outside Seamless, the conversion-host SSH key, and a one-click connection test.
• Every common guest OS: RHEL 5–10, CentOS, Rocky, AlmaLinux, Oracle Linux, Ubuntu (every LTS and interim release), Debian 7–14, SLES/openSUSE, Windows Server 2003–2025 and Windows 7–11 are identified, shown with their support state and migrated — legacy releases get warnings with remediation, never a silent block. Windows guests are verified on RDP/WinRM ports instead of the serial console, and a storage handover keeps UEFI, machine-type and bus settings (SDD §9.5). See Guest OS support below.
• Operable: live dashboard (WCAG 2.2 AA), Prometheus metrics (incl. orchestrator tick timing), structured JSON logs (uvicorn's access lines included), /health and a /ready probe that answers 503 while the database or the orchestrator loop is down, audit log export and retention (seamless events export|prune; the dashboard's Events page reads the trail back to its start and exports it), per-address lockout after repeated failed authentications, a per-step wall-clock ceiling (SEAMLESS_STEP_TIMEOUT_S) so a hung playbook never holds a stopped source, cleanup of the data path when a pass is cancelled, PostgreSQL 16 as the system of record (SDD §11, §12, §16, §18).

 Operators ─HTTPS─►  seamless control plane (FastAPI REST+SSE · orchestrator FSM · planner · advisor)
 Dashboard / CLI        │ PostgreSQL                │ ansible-playbook              │ Jev MCP · agentmemory
                        ▼                           ▼
                   plans · events        os-migrate collection (this repo)
                                          │ snapshot ► tmp volume ► src conversion host
                                          │             blocksync ──SSH──► dst conversion host ► new volumes
                                          ▼                                                     ▼
                         Source: RHOSP 17.1 / OpenStack / vCenter                  RHOSO 18.0 or community OpenStack
                                                                                   (boots the VM)

Destination platforms

RHOSO 18.0 is the validated destination. Community OpenStack destinations run on the same code path — the OpenStack Community and Kolla-Ansible presets are offered for the destination role — and 0.2.0 validates them by the support tiers of SDD §21, which follow the upstream lifecycle on releases.openstack.org:

A destination below the capability floor - Compute 2.60, Block Storage 3.0 - is refused whatever its tier (DST_CAPABILITY_MISSING), and a gap only one strategy has makes that strategy ineligible (SDD §21.4). Mind the policy defaults: under the secure-RBAC defaults (upstream's default from 2023.2) a VM that keeps a fixed IP on another project's network needs the service or admin role on the destination — advsvc no longer does —, and the validation judges each destination by its policy profile (SDD §21.5). Conversion host images: the RHEL family (RHEL, CentOS Stream 9 and 10, Rocky Linux 9, AlmaLinux 9) and Ubuntu 24.04 (SDD §21.6). The lab validation of community destinations (plan task T10) is planned for 0.2.0.

Guest OS support

OpenStack sources (RHOSP 17.1, community, Kolla) move KVM guests to KVM: every guest that boots on the source boots on the destination, because the volumes keep their boot properties. VMware sources are converted by virt-v2v on the RHEL 9 conversion host, which is where vendor support differs (SDD §9.5, Red Hat's virt-v2v support matrix):

Legacy releases are flagged (GUEST_OS_LEGACY), never blocked. Set os_distro/os_version image properties or run VMware Tools so every guest is identified (GUEST_OS_UNKNOWN otherwise).

GPU workloads (Technology Preview, validated in simulation)

0.3.0 migrates VMs with an NVIDIA vGPU, time-sliced or MIG-backed, or with a GPU passed through whole to the guest, instead of blocking them (SDD §22). No GPU state moves: the disks move as for any VM, and the VM boots on the destination as it would after a shutdown.

• Read: a VM's GPUs come from its OpenStack flavor (resources:VGPU, pci_passthrough:alias) or from vCenter (a vGPU profile such as grid_a100-4c, a DirectPath I/O device such as 10de:20b5), shown in the Inventory's GPU column.
• Mapped, never matched: the plan names the destination GPU flavor - mappings.gpus by vGPU profile or device id for a VMware VM, mappings.flavors by flavor for an OpenStack VM. The mapping is the opt-in: an unmapped GPU VM stays blocked.
• Capacity: the validation reads the destination's free GPUs from Placement, and the cutover gate reads them again before the source stops. While the pool is full, the source keeps running and the migration waits (migration.gpu_wait). Placement does not show a PCI alias's capacity, which DST_GPU_CAPACITY_UNKNOWN says.
• Verified: the server is created with the GPU flavor, and the verification checks its flavor and the GPU units Placement holds for it (gpu_flavor, gpu_allocation).
• The guest's side: GUEST_GPU_DRIVER and GUEST_GPU_LICENSE name the NVIDIA driver the guest needs on the destination and the license server its vGPU must reach.

In the demo (make seamless-demo, simulated clouds). A demo database seeded before 0.3.0 holds none of this: make seamless-reset CONFIRM=yes deletes the stack's containers and volumes, and the next make seamless-demo seeds it afresh.

1. Inventory. vCenter DC2 holds dc2-ml-01 (vGPU grid_a100-4c), dc2-ml-02 (MIG-backed vGPU grid_a100-3-20c) and dc2-cuda-01 (passthrough 10de:20b5, powered off). RHOSO 18.0 lists the GPU flavors g1.a100-4c, g1.a100-3-20c and p1.a100, and its GPU capacity: A100-4C 4 free on 1 GPU, A100-3-20C 2 free on 1, and the class VGPU 6 free on 2. Each vGPU VM that cuts over takes one unit of its pool.
2. The seeded plans. The finance plan maps gpu-ml-01's flavor g1.vgpu to g1.a100-4c, and the VMware plan maps dc2-ml-01's grid_a100-4c to it. Both validate with MAP_GPU_FLAVOR, GUEST_GPU_DRIVER and GUEST_GPU_LICENSE, and nothing blocks. Each migrates in its plan's last wave, and its verification passes gpu_flavor and gpu_allocation.
3. A wait for GPU capacity. Plan dc2-ml-02 from vCenter DC2 to RHOSO 18.0. The plan form's GPU mappings lists its key grid_a100-3-20c, with nothing prefilled: choose g1.a100-3-20c. Validate and start the plan - if it asks for approval, one person requests the cutover and an approver approves it. The validation finds room. The gate's first two reads find the pool full, as if another tenant held its vGPUs. The migration's GPU panel says "Waiting for GPU capacity", and the event log shows "dc2-ml-02: its cutover waits for GPU capacity - VGPU CUSTOM_NVIDIA_A100_3_20C of RHOSO 18.0 has 0 units free, and flavor 'g1.a100-3-20c' needs 1; the source VM keeps running".
4. The wait ends. The third read, a few seconds later at the demo's speed, finds 2 units free: "RHOSO 18.0 has the GPU capacity its cutover needs". The VM cuts over and passes its GPU checks, and A100-3-20C reads 1 free.
5. Passthrough. Plan dc2-cuda-01 and map its key 10de:20b5 to p1.a100. Only vmware_cold takes it, while it is powered off: vSphere snapshots no running VM with a DirectPath I/O device (SDD §22.6). DST_GPU_CAPACITY_UNKNOWN warns that Placement does not show the alias's capacity, so the gate does not wait, and the verification skips gpu_allocation: "PCI alias a100 not checked: nova.conf sets its resource class, which no API shows".

Not yet run on GPU hosts. Everything above runs against simulated clouds and recorded API answers. The lab cases LAB-GPU01…LAB-GPU08 (QASuite §7.2) have not run yet. They need a vSphere 8 host with an NVIDIA GPU under the vGPU manager (a time-sliced and a MIG-backed profile) and one with a DirectPath I/O GPU, and a RHOSO 18.0 and a Tier 1 community destination with Nova's vGPU and a PCI alias configured. The Technology Preview label goes when they pass (SDD §22.14).

Network cut-over (Technology Preview, validated in simulation)

0.4.0 lets a migration take the VM's network identity along (SDD §23). Each part is opt-in per plan (network_cutover), and a plan without it migrates as before.

• Hooks: an admin registers playbook and webhook hooks on the Hooks page (/hooks). A plan runs them at pre_stop, post_create, post_verify, on_rollback and on_finalize, each with a timeout, an idempotency key and an optional revert. A failure before the stop keeps the source running; one after it follows auto_rollback. A hook runs code with the control plane's reach, so only an admin registers one (Security.md C2-09). Mount hook playbooks read-only where the control plane reads them.
• Floating IPs that keep their address (floating_ips: keep_address, both clouds on one external network): the address is reserved at the destination during pre-staging, moves after the source stops, and goes back to the source on a rollback before the source starts. With auto, os-migrate's way, MAP_FIP_ADDRESS_CHANGE warns of a new address.
• DNS: a DNS target per VM - a Designate zone, or an RFC 2136 server with a TSIG key - swaps the VM's record by a compare-and-swap at post_create, and swaps it back on a rollback. NET_DNS_TTL_LONG warns of a TTL longer than the downtime SLO, and the estimate shows that DNS tail apart from the downtime.
• Reachability: the verification waits until each moved address answers, and counts the wait in the downtime. Seamless speaks no BGP.
• Octavia: a plan maps a source pool to a destination pool the operator created. The member helper drains the VM's source member before its stop and joins the migrated VM after its verification.
• Findings and runbooks: the pre-flight names Heat stacks and autoscaling groups (SRC_VM_AUTOSCALED blocks until the plan acknowledges it), Octavia memberships and pools that waves split, address pairs, announced prefixes that waves split, and DNS the destination cannot publish. Operations.md §8 holds the runbooks for what stays the operator's: Heat stacks, Octavia load balancers, Designate zones and Manila shares.

In the demo (make seamless-demo), the finance plan keeps web-01's floating IP with its address, swaps ledger-web-01's record in the destination's Designate zone after a NIC override changes its address, maps the portal pool to the destination's, and acknowledges the autoscaling group's app-01 and app-02 (SDD §10).

Not yet run on the lab's clouds. Everything above runs against simulated clouds. The lab cases LAB-NET01…LAB-NET09 (QASuite §7.2) have not run yet. They need two clouds on one external VLAN, a BGP fabric with the OVN BGP agent, Designate and BIND with TSIG, Octavia's amphora and OVN providers, and a Heat autoscaling group. The Technology Preview label goes when they pass (SDD §23.10).

Quick start — Linux server with Docker (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux)

On Linux the stack runs on the machine's own Docker Engine: no Colima and no Node.js (the image builds the dashboard itself). You need Docker Engine 20.10+ with the Compose plugin v2.20+, git, make, curl and openssl, and about 4 CPUs, 6 GiB of RAM and 20 GiB of disk for the images and the database.

1. Install Docker Engine from Docker's own repository (the distributions' own packages often lack the Compose v2 plugin):

# RHEL 8/9/10, Rocky Linux, AlmaLinux - Docker's RHEL repository
sudo dnf -y install dnf-plugins-core git make openssl   # curl is there already (curl or RHEL 9's curl-minimal)
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo
sudo dnf -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Ubuntu 22.04/24.04/26.04 or Debian: set up Docker's apt repository as Docker's guide shows
# (https://docs.docker.com/engine/install/ubuntu/ or /debian/), then:
sudo apt-get install -y git make curl openssl docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Other distributions (Fedora, SLES, …): Docker's install guides. Remove Podman's podman-docker shim first if it is installed, since it takes the docker command.

2. Start Docker now and at every boot, and use it without sudo:

sudo systemctl enable --now docker
sudo usermod -aG docker "$USER"     # then log out and back in; check with: docker info
docker compose version              # v2.20 or newer

The docker group grants root-level rights on the machine: add only the account that runs Seamless. Run every make target as that account, not with sudo, because the files compose-init.sh writes belong to it.

3. Start Seamless:

git clone https://github.com/imransetiadi/seamless-vms-migration.git
cd seamless-vms-migration
scripts/compose-init.sh          # writes deploy/compose/.env and tokens.yaml; prints the admin API token ONCE - store it now
make seamless-up                 # builds the image and starts PostgreSQL and the control plane (bring your own clouds)
# make seamless-demo             # the same stack with simulated clouds and seeded plans, to try it first
curl -fsS http://127.0.0.1:8080/api