SeamlessMigrate

GUIDE · RED HAT OPENSTACK PLATFORM 17.1 TO RHOSO 18.0

RHOSP 17.1 to RHOSO 18.0 migration, side by side

When an in-place adoption doesn't fit, Seamless Migrate moves each workload from Red Hat OpenStack Platform 17.1 into Red Hat OpenStack Services on OpenShift 18.0 with a cold, warm or storage handover strategy, and keeps the source VM until you finalize.

Try the local demo View on GitHub (opens in a new tab)
Source
Red Hat OpenStack Platform 17.1 (TripleO)
Destination
RHOSO 18.0, OpenStack on OpenShift
Strategies
Cold, warm and storage handover
200 GiB VM
11m 20s warm, 20m 53s cold, 4m 20s handover
Carried over
Networks, security groups, flavors, images, keypairs, projects, users
License
Open source, Apache 2.0

Adoption or side-by-side migration?

RHOSP 17.1 is the last TripleO-based release of Red Hat OpenStack Platform. RHOSO 18.0 runs the OpenStack control plane as pods on OpenShift, with RHEL 9 compute nodes in the data plane. Red Hat's adoption procedure converts a 17.1 deployment into 18.0 in place.

Side-by-side migration is the other road: build a new RHOSO cloud, then move the workloads into it. Teams take it when they change hardware, move to a new storage backend, redesign the network (for example ML2/OVS to ML2/OVN with new physnets) or consolidate several clouds. Seamless Migrate is built for that road and can run alongside an adoption project.

  • Adoption: you keep the hardware, the storage backend and the network design, and convert the deployment in place.
  • Side by side: you change at least one of them, or merge clouds, and move VM by VM with a rollback for each.

The same side-by-side move also leads out of the Red Hat stack: a community OpenStack cloud from 2023.1 Antelope to 2026.2 Hibiscus is a destination too, as the OpenStack to OpenStack guide describes.

Three strategies for RHOSP 17.1 VMs

  • warm

    Warm

    Snapshot passes copy the disks while the VM runs; after the first pass only the chunks whose BLAKE2b digest changed move. At cutover the VM stops for the final delta only.

    Downtime:
    the final delta and a scan of the largest disk
    Needs:
    conversion hosts in both clouds, no multi-attach volumes
  • storage_handover

    Storage handover

    No data is copied: Cinder unmanages each volume at the source and manages it at RHOSO, on the same Ceph cluster or NetApp ONTAP SVM.

    Downtime:
    metadata operations, a few minutes whatever the size
    Needs:
    admin on both clouds, shared storage, every volume type mapped; no encrypted volumes
  • cold

    Cold

    The VM stops, the os-migrate conversion hosts copy its used data over SSH, and it boots on RHOSO.

    Downtime:
    the whole copy of the used data
    Needs:
    conversion hosts in both clouds

Seamless estimates every eligible strategy for each VM and picks the least downtime; when two tie, the simpler one wins, in the order cold, storage handover, warm. You can override the choice per VM.

How long each VM is down

Warm downtime is bounded by a fixed overhead and a scan of the largest disk, so a large VM stops for minutes instead of hours. A storage handover stays at a few minutes whatever the size.

VM (one volume, 60 % used)WarmStorage handoverCold
50 GiB6m 12s4m 20s8m 36s
200 GiB11m 20s4m 20s20m 53s
500 GiB21m 34s4m 20s45m 28s
1 TiB39m 27s4m 20s1h 28m

OpenStack sources. Estimated downtime from the stop to the verified boot, with the planning model's defaults: 125 MiB/s link, 2 MiB/s of guest writes. The control plane recalibrates both after the first delta pass.

Try your own VM in the downtime calculator.

What moves with each VM

  • Networks, subnets, routers and security groups, recreated on RHOSO.
  • Flavors, images, keypairs, projects and users, carried over.
  • Ports recreated on the mapped RHOSO networks, keeping their fixed IPs.
  • MTU checked against Geneve on ML2/OVN: a 1500 source on a 1442 tenant network raises NET_MTU_SHRINK with its fix.
  • TLS verified on every endpoint by default. Seamless uses RHOSO's public OpenStack APIs and never touches OpenShift resources.

On a plan that opts in to the network cut-over, a Technology Preview validated in simulation, floating IPs keep their address, a DNS record follows a changed address through Designate or RFC 2136, a VM's Octavia pool member is drained at the source and joined to the mapped RHOSO pool, and hooks an admin registers run at fixed points of each migration.

Not migrated automatically: Heat stacks and autoscaling groups, Octavia load balancers, Manila shares and Designate zones. The pre-flight reports a VM's Heat stack, autoscaling group and Octavia memberships as findings, and the operations guide has the runbooks to follow by hand.

How a RHOSP 17.1 migration runs

  1. 01

    Connect RHOSP 17.1 and RHOSO 18.0

    Add both clouds with their presets and conversion hosts. Credentials are write-only; the connection check reports admin rights, the compute microversion and the network backend.

  2. 02

    Discover and map

    The inventory shows each VM's volumes, NICs, guest OS and readiness. Map networks, flavors, volume types and projects; for a storage handover, map each volume type to a RHOSO backend on the same pool.

  3. 03

    Plan waves

    The planner orders waves by risk with a small pilot first. A wave starts only when the one before it is complete.

  4. 04

    Validate

    Pre-flight checks report blockers such as missing quota and warnings such as an MTU shrink, each with its fix. Every VM gets an estimate per strategy and an automatic choice.

  5. 05

    Pre-copy, then cut over

    Warm VMs pre-copy while they run and wait, kept fresh, for their window. Each cutover needs a second approver, the change window and a free cutover slot.

  6. 06

    Verify, then finalize

    Seamless checks the server, its ports, TCP probes and console. A failed check rolls back on its own and starts the source VM again; finalize closes the migration.

FAQ

RHOSP 17.1 to RHOSO 18.0, answered.

What teams ask when adoption in place is not the whole answer.

Is RHOSP 17.1 the last TripleO-based release?

Yes. Red Hat OpenStack Platform 17.1 is the last release deployed with TripleO. Its successor, Red Hat OpenStack Services on OpenShift (RHOSO) 18.0, runs the OpenStack control plane as pods on OpenShift, with RHEL 9 compute nodes in the data plane.

Should I use adoption or a side-by-side migration?

Adoption converts a 17.1 deployment in place and fits when the hardware, the storage backend and the network design stay. A side-by-side migration fits when one of them changes, or when several clouds become one: the workloads move VM by VM into a new RHOSO cloud, each with a rollback until it is finalized.

How much downtime does a RHOSP 17.1 to RHOSO 18.0 migration need?

For a VM with one 200 GiB volume, 120 GiB used and 2 MiB/s of guest writes over 125 MiB/s, the planning model estimates 11m 20s for a warm migration, 20m 53s for a cold copy and 4m 20s for a storage handover on shared storage.

Do both clouds need the same storage?

No. Cold and warm migrations copy the data between any Cinder backends. Only a storage handover needs both clouds on the same Ceph cluster or NetApp ONTAP SVM, because it hands the volumes over instead of copying them.

What happens to networks when moving from ML2/OVS to ML2/OVN?

RHOSO 18.0 networking is ML2/OVN only, with Geneve tenant networks. Seamless Migrate recreates networks, subnets, routers and security groups on RHOSO, maps every NIC to a RHOSO network and warns with NET_MTU_SHRINK when the source MTU is larger than the Geneve network's, typically 1500 against 1442. OVS-specific port bindings are not copied.

Can Seamless Migrate run on the same OpenShift cluster as RHOSO?

Yes. It is one container image plus PostgreSQL 16 and ships OpenShift manifests: a hardened Deployment, an edge-TLS Route and default-deny NetworkPolicies. It reaches RHOSO only through the public OpenStack APIs and never touches OpenShift resources.

MORE GUIDES

GET STARTED

Big possibilities.
First, a small pilot.

The demo runs every phase, from pre-copy to cutover, verification and rollback, against simulated clouds on your laptop. No OpenStack needed to try it.

Get the code (opens in a new tab)Read the design document (opens in a new tab)

Docker on a Linux server, or Colima on a Mac

$ git clone https://github.com/imransetiadi/seamless-vms-migration$ cd seamless-vms-migration# macOS only: not needed on Linux$ make seamless-colima-up$ scripts/compose-init.sh# simulated clouds, every phase$ make seamless-demo

Open the local demo (opens in a new tab)Sign in at /login with the admin token compose-init.sh printed. Podman works too: SEAMLESS_ENGINE=podman.