SeamlessMigrate

GUIDE · COMMUNITY OPENSTACK AND KOLLA-ANSIBLE TO RHOSO 18.0

Migrate community OpenStack and Kolla-Ansible clouds to RHOSO 18.0

Seamless Migrate moves VMs from any OpenStack cloud with Keystone v3, Nova API 2.60 or later, Cinder v3 and Neutron v2, upstream or deployed with Kolla-Ansible, into Red Hat OpenStack Services on OpenShift 18.0, one wave at a time.

Try the local demo View on GitHub (opens in a new tab)
Source
Community OpenStack and Kolla-Ansible, Queens (2018) or later
APIs
Keystone v3, Nova 2.60+, Cinder v3, Neutron v2
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
License
Open source, Apache 2.0

From your own OpenStack to RHOSO

Many organizations run an OpenStack they built themselves, from upstream releases or with Kolla-Ansible. Moving to RHOSO 18.0 puts the control plane on OpenShift with Red Hat's life cycle, but the in-place adoption procedure exists only for Red Hat OpenStack Platform 17.1. From community OpenStack, the way in is side by side: build RHOSO, then move the workloads.

Both sides speak the same OpenStack APIs, so KVM guests move to KVM: whatever boots on the source boots on RHOSO, with its volumes, NICs and boot properties. The guest needs no conversion.

Moving to a new community cloud instead, Kolla-Ansible or any other upstream deployment from 2023.1 Antelope to 2026.2 Hibiscus? The same strategies apply: see the OpenStack to OpenStack guide.

Which OpenStack clouds can be a source

  • Keystone v3 for identity.
  • Nova API microversion 2.60 or later: OpenStack Queens (2018) and every release since.
  • Cinder v3 for volumes and Neutron v2 for networks.
  • A conversion host in each cloud for cold and warm copies. An existing one works too, through its SSH key.
  • Kolla-Ansible, community OpenStack and RHOSP 17.1 each have a preset in the dashboard.

Three ways to move each VM

  • warm

    Warm

    Snapshot passes copy the disks while the VM keeps serving traffic. After the first pass only changed chunks cross the wire, each pass ending with a verified digest; at cutover only the final delta remains.

    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

    When both clouds share a Ceph cluster or a NetApp ONTAP SVM, Cinder unmanages each volume at the source and manages it at RHOSO. Nothing is copied.

    Downtime:
    metadata operations, a few minutes whatever the size
    Needs:
    admin on both clouds, every volume type mapped to a RHOSO backend on the same pool
  • cold

    Cold

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

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

Cold copies run on the os-migrate Ansible collection, which stays the data mover underneath every OpenStack strategy.

How long each VM is down

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.

From any network backend to ML2/OVN

RHOSO 18.0 networking is ML2/OVN, with Geneve tenant networks whose MTU is typically 1442 on a 1500 underlay. Whatever mechanism driver the source uses, Seamless recreates networks, subnets, routers and security groups on RHOSO and maps every NIC to a RHOSO network; OVS-specific port bindings are not copied.

A source MTU larger than the Geneve network's raises NET_MTU_SHRINK before anything moves, with its fix: lower the guest MTU before the cutover.

How the migration runs

  1. 01

    Connect both clouds

    Add the source with the community OpenStack or Kolla-Ansible preset and RHOSO 18.0 as the destination. One click checks each connection and reports what it can do.

  2. 02

    Discover, map and plan

    Select VMs from the inventory, map networks, flavors, volume types and projects, and let the planner order waves by risk with a small pilot first.

  3. 03

    Validate

    Pre-flight findings come with their fix; every VM gets a downtime estimate for each eligible strategy and an automatic choice you can override.

  4. 04

    Copy while the VMs run

    Warm VMs pre-copy in snapshot passes and wait, kept fresh by keep-warm syncs, for their change window.

  5. 05

    Cut over with an approval

    A second approver, the change window and a free cutover slot gate every cutover. The VM stops, the final delta syncs and it boots on RHOSO.

  6. 06

    Verify, then finalize

    A failed check rolls the VM back on its own and starts the source again. Finalize needs an approver and the VM's name typed in full.

FAQ

OpenStack to RHOSO, answered.

What teams ask before they move a community or Kolla-Ansible cloud.

Which OpenStack releases can I migrate from?

Any release that exposes Keystone v3, Nova API microversion 2.60 or later, Cinder v3 and Neutron v2: OpenStack Queens, released in 2018, and every release since, whether deployed upstream, with Kolla-Ansible or as Red Hat OpenStack Platform 17.1.

Is there an in-place upgrade from community OpenStack to RHOSO?

No. Red Hat's adoption procedure converts Red Hat OpenStack Platform 17.1 deployments. From community OpenStack or Kolla-Ansible, the way to RHOSO 18.0 is side by side: build the RHOSO cloud, then move the workloads into it, VM by VM, with a rollback for each until it is finalized.

Can I migrate between two community OpenStack clouds?

Yes. A community OpenStack cloud is a destination like RHOSO 18.0: every release series from 2023.1 Antelope to 2026.2 Hibiscus, deployed with Kolla-Ansible, OpenStack-Ansible or any other tool, registered with the OpenStack Community or Kolla-Ansible preset. The source can be community OpenStack, Kolla-Ansible or RHOSP 17.1. The OpenStack to OpenStack guide covers that move.

Will my VMs keep their IP addresses?

Ports are recreated on the mapped RHOSO networks with their fixed IPs and MAC addresses. As a Technology Preview, validated in simulation, a plan can also keep each floating IP's address, moved after the source stops and given back on a rollback, swap a DNS record in Designate or an RFC 2136 server when an address changes, and run hooks an admin registers for the rest. The verification waits until each moved address answers, so a BGP announcement that follows the floating IP counts in the downtime.

How much downtime does an OpenStack to RHOSO 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 Ceph or NetApp ONTAP.

What does Seamless Migrate add to os-migrate?

os-migrate exports and imports tenant resources and copies workloads cold. Seamless Migrate keeps it as the data mover and adds a warm path, storage handover, plans and waves, downtime estimates, approvals and change windows, verification, rollback, a dashboard, a REST API and a CLI.

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.